RE: sysklogd: running multiple instances

Hi Paul

I beleive that sysklogd is one of the most patched packages out there
:-/

I had recently tried to patch the socket listening, but with poor luck,
primarily because syslog usually starts before the network starts. Thus
it cannot do anything but listening on all interfaces. For the same
reason it does not make much sence to change the main stream sysklogd
with such features.
Thus the only way forward there is to maintain your own patch.

Regarding the other stuff. You could patch that also now you have
started patching.
Or you could run it in a chroot jail.

/// Kjeld

-----Original Message-----
From: Paul Smith [mailto:paul_at_mad-scientist.us]
Sent: 21. januar 2009 19:17
To: infodrom-sysklogd_at_lists.infodrom.org
Subject: sysklogd: running multiple instances

I'm frustrated by the hard-coded and unchangeable aspects of sysklogd
configuration. I really want to use syslogd to listen for messages
logged over the network from a set of systems, but I want to run it as a
non-root user, with a different config file, and I don't want it to
interfere with the normal system logging (this second syslogd would not
read the normal /dev/log socket; that would be left to the standard
syslog).

For example, I cannot start a second syslogd that listens on a different
UDP port, because there's no command line option (or config option) to
change the port. It can only use the single value defined in
/etc/services.

Even if I ignore this problem, I can't start a second syslogd because
there's a static, unconfigurable pathname to store the syslogd PID file,
and if that file cannot be used then syslogd simply exits.

There may be more problems but this is where I'm stuck right now.

There are other things that would be nice such as restricting incoming
network logging to a specific network interface, although similar things
can be achieved (with more configuration effort) via ipchains I suppose.

Is there a reason for these restrictions that I don't see? Or is this
just a use-case that has not been considered before? Is it a use-case
that holds any interest for the sysklogd maintainers? Naively, it
doesn't seem like it would be much of a problem to provide this
flexibility.

--
To UNSUBSCRIBE, send an email to
infodrom-sysklogd-request_at_lists.infodrom.org
with a subject of "unsubscribe". Trouble? Contact
listmaster_at_lists.infodrom.org