Nsyslogd.
Index
-
-
-
-
-
So what does nsyslogd do for me that syslogd doesn't ? Well, it supports
TCP connections for a start, and with SSL allows for encrypted delivery of
syslog messages across the network. They're just two of the big changes
which have obvious benefits, especially for those setting up systems where
chroot'd areas are required (i.e. firewalls).
I have endevoured to make nsyslogd as compatible with system versions of
syslogd, meaning that you can start using it straight away and when you're
ready, migrate to the new configuration format to take advantage of its
strengths. It has been customised to run on the following systems:
- NetBSD
- FreeBSD
- BSD/OS
- OpenBSD
- Solaris
- IRIX
...there are still some teething problems with Linux and its /dev/klog.
An indirect result of this aim is that features available on one system's
syslogd are now available on all.
The design of nsyslogd, from the start, was to rewrite syslogd and provide
something new which could actually do something useful. To this end, it
was redesigned with the following thoughts on functional flow: a message
comes from a source, may go through some filters before being sent to its
final destination.
The final product also needed to be firewall-friendly - being able to specify
multiple equivalents of /dev/log (or /var/run/log) was a must.
Whilst filtering for IP addresses is built in, it filters data flowing
through nsyslogd, NOT new connections. To save on building yet another
method for controlling TCP connections, libwrap will be used if it is
detected when configuring for compilation.
That syslogd used UDP to transfer messages was also recognised as a problem,
along with all the pitfalls of that protocol such as the loss of the
originating host after a log packet has been relayed. To deal with this
issue, a TCP protocol has been built. The protocol is a binary protocol
so it is not easily communicated with using standard user programs such as
TELNET. The main advantage of this is non-ASCII data is more easily sent
between two daemons, not to mention being able transfer discrete message
blocks rather than lines which never have a line-feed or carriage return
and thus appear to never end.
The filtering needed to be powerful and yet simple. A desire to be able
to filter on network source was essential, so that external noise could
be removed from logs. Regular expressions which matched message content
was also deemed necessary.
version 4.00beta2 nsyslogd.tgz
version 4.00beta2 nsyslogd.tar.gz
If you have any comments, bugs to report, etc, then please email me
at:
darrenr@pobox.com