Rob Cermak wrote:
> 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.
I don't think we're ready to jump into implementation just yet, but I do know
that designing a protocol without having a reference implementation that
proves the thing works, is easy to implement, etc. is asking for big trouble
(think OSI).
> [...]
>
> >> 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...
> [...]
> 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.
But, but, but... why should the facilities be integers in the first place?
They're just tags. Names. Strings. Why do I need a mapping between strings
and integers to maintain? Why can't I have something like:
submit_log_entry("mail/MTA", LOG_ALERT, "the log message")
in my program and
mail/MTA.* "/var/adm/syslog/${facility_name}.log"
in my configuration and then have the logger automagically create a named pipe
at /dev/logdev/mail/MTA and log the data to /var/adm/syslog/mail/MTA.log?
The only reason is that the creators of syslog didn't think of that. That's
not a good enough reason.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
