[prev in list] [next in list] [prev in thread] [next in thread] 

List:       annvix-dev
Subject:    Logging assurance, provenance, and non-repudiation (Re: [dev] more
From:       Charlie Brady <charlieb-annvix () budge ! apana ! org ! au>
Date:       2004-07-30 15:09:57
Message-ID: Pine.LNX.4.44.0407301059120.16037-100000 () e-smith ! charlieb ! ott ! istop ! com
[Download RAW message or body]


On Fri, 30 Jul 2004, Vincent Danen wrote:

> Ideally, what I think would be better (since I was never one much for 
> the multilog logging directories), is to have the STDOUT of a run 
> script log to syslog.

No, you really don't want to do that, for reasons mentioned in the subject
(and in articles referenced previously). You want to be certain that you
know where logs came from, and you want to know when log messages were
generated (you can't trust a syslog timestamp).

> I like the idea of logs being in a single directory (or a subdirectory)
> ...

If you want to look at combined logs, combine them, and then look at them:

cat /var/log/*/currrent | sort | tai64nlocal | less

or (say):

cat /var/log/{httpd,qmail}/current | sort | tai64nlocal | less

> Ideally, everything will do the logging itself, either to it's own 
> logfile (ie. apache) or logging to syslog (ie. sshd).  The multilog 
> output is just for debugging so having small arbitrary sizes, even if 
> they rotate themselves out in a day, is ok.  Those logs have helped me 
> find problems that syslog output didn't, however that doesn't mean I 
> want to use/depend on those logging directories for anything more than 
> a "what's this daemon up to right now?" type thing.  I'd still rather 
> use the "old-school" means of logging in tangent with logging 
> directories, rather than replace one in favour of the other.

I don't understand your reasoning.

> >> syslogd, however, runs as user syslogd, and not as root.
> >
> > I find it hard to believe that most distros run syslogd as root, and
> > nobody seems too concerned.
> 
> Especially considering there have been issues with syslogd in the past. 

Of course it has. All old, unnecessarily complex C programs have bugs.

> I'd like to have the 
> privs dropped on klogd as well, but had some issues with it not being 
> able to read /proc/kmsg which would cause both it and syslogd to eat 
> lots of CPU.  That's the only reason klogd runs as root.

It's a 2.6 kernel thing, I think.

With supervise+multilog, all we need to run as root is have klogd/run:

#! /bin/sh
exec dd if=/proc/kmsg

---
Charlie


_______________________________________________
dev mailing list
dev@annvix.org
http://annvix.org/mailman/listinfo/dev

[prev in list] [next in list] [prev in thread] [next in thread]