My opinion follows what already has been discussed. Lets get the core
built on a standard BSD/Linux - the decision on the final protocol
could have implications back to deeper levels of OS/kernel linkages.
These are just thoughts...
PROJECT NAME: syslog2
FINAL PROD NAME: syslogd
Why change the name... it just needs to be fixed. If anything maybe
even trim the name back to : logd
Suggested milestones are
1. Firming up a protocol document. (already suggested -- syslog.h)
2. Getting a core syslog2 built & working - multiplatform & localhost
3. Using extension agents around syslog2: encryption, etc...
I think the key is getting a local agent core built with other programs
to act as agents around syslog. The network layer may even be a separate
issue. Similar to sendmail and its various agents...
#2 will be harder to reach if the base protocol needs changes back at
the OS (BSD/LINUX) kernel level.
>> Extensibility:
>> * Easy to add new logging facilities and have all machines
>understand
>> them and without recompiling source code.
>
>I'm not even sure what this means.
Under Linux, syslog has a maximum of 24 facility names & codes...
#define LOG_NFACILITIES 24 /* current number of facilities */
#define LOG_FACMASK 0x03f8 /* mask to extract facility part */
/* facility of pri */
#define LOG_FAC(p) (((p) & LOG_FACMASK) >> 3)
#ifdef SYSLOG_NAMES
CODE facilitynames[] =
{
{ "auth", LOG_AUTH },
{ "authpriv", LOG_AUTHPRIV },
That structure in /usr/include/sys/syslog.h looks like you can hack
and add more facilities -- you would have to recompile the kernel.
As a suggestion...
This could be easily moved to the /etc/syslog.conf file
for HUP (re-read) or startup to identify 24 or any number of
pre-defined services. If syslog has a unidentified service
it can leave it un-named and shoved into a bit bucket -- dropped
off the face of the machine or logged as an unidentified log message.
Existing software would not have to be re-written, but additional
facilities can be added via the config file providing you have
enough machine resources to handle large numbers of facilities.
[This method would be much the same as adding a agent to /etc/inetd.conf
and reconfiguring inetd.]
In that same mechanism, lump several facilities into a single
facility. Or as an expansion detail later -- point it to a
remote logging device.
Back to the core -- we leave it empty. By looking at this, we
actually have taken an implementation detail away from the core
as it can be defined later.
Question? For those that want secure logging.
If local incomming messages are waiting on /dev/log. Is
it possible to have a secure-syslogd listening on another
/dev/log-secure to pass messages securely to remote machines?
/dev/log --> syslog --> /dev/log-syslog --> secure TCP program
sending data to remote machine; freeing syslog from dealing
with network troubles. The buffering done on the 'secure TCP'
application. If the network is indeed causing trouble, log
trouble back to /dev/log -- you would have to ensure that loop
recursion is not taking place.
The basic syslog in my estimation should just be simple
with other programs (agents) plugged into its stream of information.
The downside of this is the time it takes to hand-off information.
Rob
