[syslog-ng] strange thing

[Stefan Seufert]

> > 1.) As you suggested:
> > > Newer libc's allow using unix-dgram /dev/log, try using that, client
> > > programs will never block then.
>
> RedHat patched their libc to send messages via dgram /dev/log. The patch
> IIRC was transparent, so one could use both unix-dgram and unix-stream as
> they choose to. Note that if you choose to use unix-dgram, the services will
> continue to run even if syslog-ng blocks, but logging will be shut down.
>
> > Only problem: what is a "newer libc"? Do you talk about glibc?
>
> IIRC the one included in RedHat 6.1 was patched, so 6.2 should be ok. I
> don't know whether this patch was accepted upstream though.

Ok, then my system is too old.

> > 2.) Running two syslog-ng processes, on with name resolution on
> (receiving all
> > that network-data) and one with name resolution off (reading
> /dev/log) which
> > should solve my problem, too.
>
> that should work.

Nice.

> >
> > 3.) Firewall port syslog at host level and putting all hosts allowed to get
> > through in the hosts file. Will syslog-ng use the hosts file (by using the
> > standart resolver library) or will it bypass it and only do ns lookups?
>
> syslog-ng uses gethostbyaddr(), so a private nsswitch.conf file should be
> ok.

since I have

hosts:  files dns

in my nsswitch.conf it should always use the host file first. The firewall
rules (ipchains/ipfw) gurantee that no host not explicetedly named in my
/etc/hosts can get a datagram through so syslog-ng will always get a hit from
my host file. No need of a private nsswitch.conf.
>
> > I'd really like to hear your opinion about these possibilities. Of
> > course I'd
> > prefer 1.) since I like things wich work by design an not because of some
> > "dirty tricks".
>
> I don't like 1), because it may lead to lost messages without notice.

Hm, haven't thought about this aspect. You are right.

> I like
> #2 or #3, but I don't know how to use a private nsswitch.conf file, however
> I know that this is possible, since sendmail uses one.

I think I'll use both, #2 and #3 in parallel which should give me a maximum of
reliablility. This solution should work fine for me because I do not need to
mix local and remote entries within one logfile.

But what about the following idea:

Some sort of "private" hosts file for syslog-ng? Let's say
/etc/syslog-ng/syslog-ng.hosts with an "ip\thost" format (even simpler than
/etc/hosts), e.g.:

127.0.0.1	localhost
192.168.1.1	host1
192.168.1.2	host2
192.168.1.3	host3
192.168.1.4	host4

It shouldn't be very hard to implement a new option which allows you to use
this file (and only this file) as the source of name resolution. If an IP is
found, great if not we'll resort to the ip. This makes us independent from any
name service problems (not only outages, syslog-ng will use the correct
hostname, even if someone spoofes your nameserver)

In my eyes, something worth thinking about. Maybe I'll have some free minutes
tomorrow giving this a try.


Stefan