New Syslogd.
------------

This new "syslogd" has been built to recognise the old format syslog.conf
files as well as a new format.  The new format has 5 basic lines:
- comment
- source specification
- filter specification
- destination specification
- log specification

This implementation of syslogd uses the following paradigm:

a message will arrive from a source, may be put through a number of various
filters and will be delivered to a destination.  The filtering selects 
whether or not to let the message proceed to be delivered.

Comments are marked by the #.

A source is defined thus:

	source src { file /dev/klog; unix /dev/log; udp 0.0.0.0,514; };

This defines a single source of messages "src" to consist of three parts:
a file named /dev/klog, a unix domain socket /dev/log and a UDP port at
port number 514.  Any syslog message detected on one of those sources is
considered to be coming from "src".  It is possible to use the same source
of messages, more than once, in a single configuration.  Thus you might
have:

	source src { file /dev/klog; unix /dev/log; udp 0.0.0.0,514; };
	source skern { file /dev/klog; };

where src groups a message as being from any one of its 3 constituents and
skern only cares about messages from /dev/klog.  For those who are concerned,
each is only opened once and common references are made.

Likewise, filters and destinations can be setup with common parts or each
being distinct on its own.  This document doesn't attempt to (yet anyway)
describe all the available options.

In specifying a log action, at least a source and destination may be
givern and optionally, one or more filters.  Thus if I had:
	destniation klog { file /var/log/kern; };
	log { source skern; destination klog; };
in combination with the above examples, all messages from /dev/klog would
get logged to /var/log/kern regardless of their content/priority/facility.
If we wanted to log all errors to /var/adm/messages, we might use the
above with:

	destination errs { file /var/log/messages; };
	filter errors { priority err; };
	log { source src; filter errors; destination errs; };

If I also wanted to *include* all authentication syslog messages in the
file errs, I might use:

	filter authm { facility auth; };
	log { source src; filter errors; filter authm; destination errs; };

but if I was only interested in auth messages from login, I might have:

	filter login { match-prog login; };
	log { source src; filter errors; filter authm,login;
		destination errs; };

or as:

	filter authm { facility auth; match-prog login; };
	log { source src; filter errors; filter authm; destination errs; };

For destinations which are files, it is possible to adjust the sync rate
at which fsync() is called.  By changing errs to the below, it will call
fsync() after every thirthieth message has been save to /var/log/messages:

	destination errs { file /var/log/messages; sync 30; };

