Re: [bug-inetutils] some suggestions to syslog.conf

[melodramus]

On Tue, 17 Aug 2010 01:58:03 -0400
"Alfred M. Szmidt" <address@hidden> wrote:

> 
>    hello
> 
>    i found a syslog.conf manual on the net--to whatever syslogd
> package that may fit--that describes filters for 'programs' and
> 'hostnames', like:
> 
>     # Save ftpd transactions along with mail and news
>       !ftpd
>       *.*      /var/log/spoolerr
> 
> The above to me would log everything execpt ftpd messages to
> /var/log/spoolerr.  Wouldn't it be easier to just write:
> 
>  ftpd.*,mail.*,news.* /var/log/spoolerr
> 
> 
>     # Save forwards from hostname
>       +hostname
>       *.*      /var/log/hostname
> 
> What are forwards in this case?
>

the above examples are from the man page i found on the net. the style
of writing is not my idea, as you could have known if you hadn't cut
the rest of the message ;)

also, you got the intro wrong. '!ftpd' is not expressing 'not this
facility' but 'everything from this _program_'. the other example
expresses 'everything from this _host_'. 

>    what do you think?
> 
> I think it sounds complicated, I've used syslogd for years and years
> and never saw a need for something like this.  Could you explain to us
> what you are trying to solve exactly?

the point is that there is a syslog daemon (unknown to me but i found
the man page!) that can divert messages to log files on a per-program or
per-host base. for example, one could divert all messages from iptables
into an own log file. this specific syslogd even diverts all related
kernel messages into that file.

> You could easily solve this using M4 though.

easily??? is M4 easy compared to syslog.conf??? wow???

sorry, i'm stunned!

if syslogd already knows about the prog or host sending the message,
why not making use of that information in the already existing
syslog.conf file? why pushing this part into regex'es or macro's? the
point is that doing things outside syslogd that are already somehow
implemented inside syslogd is not a solution but a workaround for
shortcomings in the interface. also, doing it outside, especially with
shell scripting and lots of *nix tools, is far more complicated and
inefficient (resource hungry.) not doing it in syslogd also means that
meta context is lost and must be grep'ed or sed'ed somehow (by guess)
from text. what i'm talking about has nothing to do with big solutions
for filtering weblogs etc. it is just about the program or host sending
the message and being known to syslogd.

and, don't forget the grouping i mentioned. this makes handling longer
statements easier.

best wishes,
MeloDramus <address@hidden>