Re: [logs] tbird rant: syslog.conf, tabs and spaces

robat_private

At 07:13 PM 5/7/2003, Darren Reed wrote:
>In some mail from Rob Scott, sie said:
> > My biggest pet peeve about traditional syslog daemons is that if the 
> system
> > admin (me, usually) forgets to actually create the target file called out
> > in a syslog rule then syslog will only tell you about it at start time
> > rather than simply create the file in question.  I admit that a truly
> > paranoid and control oriented admin may not wish a system utility like 
> this
> > to go about creating files.  However, I've always felt that if syslog can
> > detect that I haven't created a target log file why shouldn't it just go
> > ahead and create the fritzing thing rather than just whining about it.
>
>And who should own it and what permissions should it have on it ?
>And you would configure that in syslogd how ?

Syslog runs as root on most systems.  Take a look at /var/log in Linux, and 
you'll see that almost all of the log files already being used by syslog 
are owned by root with permission 600.  Makes sense (at least to me) that 
syslog would create the files with owner root and permissions 600.  I do 
note that Solaris seems to put permissions of 644 on most files in 
/var/adm, but I would favor 600 for those files that would be auto-created 
by syslog.  My point is that if creating a file syslog should adhere to 
local or religious standards of the *nix flavor that it's running on.

>Not to mention that the other aspect of not logging to a file that
>is not there vs creating it on demand, creates a control mechanism
>for logging outside of syslogd itself, independant of syslog.conf.

All of my comments are from my experiences with BSD 4.1/4.2, Sun/OS, 
Solaris and RedHat Linux.  Your *nix may vary.

I'm not sure that I get your point here.  If a log file target called out 
in a syslog doesn't exist, syslog throws away the log entries destined for 
that file.  Most implementations of syslog won't tell you that the file is 
missing when they start up, so if you haven't created the file before you 
start syslog you won't know that it's losing the messages destined for the 
file.

I would suggest that syslog either create the file (as suggested above) or 
perform a consistency check on the syslog.conf file to ensure that all of 
the targets exist and can be written.  As currently implemented the attempt 
to assess and open the target file doesn't usually occur until the first 
attempt to write to it.  If a target file did not exist or could not be 
written to, syslog could write a message to either the console or to the 
standard system log to announce the problem.

Cheers.
Rob

              It's never too late to have a happy childhood.
                    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                     Rob Scott, mailto:robat_private
        Langley, Washington on Whidbey Island (a suburb with a moat)

_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis