[syslog-ng] Ignoring previously handled/filtered messages

Un L'Unique un@pebble.dhs.org
Fri, 02 Jun 2000 15:20:59 +0200


Un L'Unique wrote:
> 
> Balazs Scheidler wrote:
> >
> > > > Agreed.  What I'd like is a clause that means "log this only if not yet
> > > > handled".  That way, we get it both ways -- if you don't specify anything, you
> > > > get the current behavior, in which it would go to both logs.  Plus, with the
> > > > "not-yet-logged" clause, I could catch everything where I want it, and then do
> > > > the "not-yet-logged" clause just for the remaining facility(daemon), for
> > > > example.
> > >
> > > The DEFAULT filter exists for exactly this purpose. It may be buggy since I
> > > haven't touched that feature since 1.3.xx (when I implemented it), but the
> > > syntax looks like this:
> > >
> > > log { source(src); filter(DEFAULT); destination(dst); };
> > >
> > > DEFAULT filters all not-yet-handled messages. I'll check out the other not
> > > expression bugs as well.
> >
> > I tested this, and it seems to work. The configuration I tried:
> >
> > options { keep_hostname(yes); };
> >
> > source src { unix-stream("proba2"); internal(); };
> >
> > destination ftpd { file("ftplog"); };
> > destination named { file("namedlog"); };
> > destination daemon { file("daemonlog"); };
> >
> > filter f_ftpd { match("ftp"); };
> > filter f_named { match("named"); };
> > filter f_daemon { facility(daemon); };
> >
> > log { source(src); filter(f_ftpd); destination(ftpd); };
> > log { source(src); filter(f_named); destination(named); };
> > log { source(src); filter(f_daemon); filter(DEFAULT); destination(daemon); };
> >
> > The lines I logged:
> >
> > balabit:~/src/syslog-ng-1.4/src$ logger -u proba2 -p daemon.info "ftp"
> > balabit:~/src/syslog-ng-1.4/src$ logger -u proba2 -p daemon.info "named"
> > balabit:~/src/syslog-ng-1.4/src$ logger -u proba2 -p daemon.info "qqq"
> >
> > All of them went to the expected location.
> Well, not for me :-) ( V 1.4.3)
> 
> Since I can't make it work, I made a very simple configuration and found strange things:
> log
> {
>         source( local);
>         source( network);
> 
>         filter( f_bash);
>         destination( d_bash);
> };
> 
> log
> {
>         source( local);
>         source( network);
> 
>         filter( f_auth);
> #       filter( DEFAULT);
>         destination( d_auth);
> };
> 
> bash-log line appers in both file as expected.
> If I remove the comment, when, bash-log appers only in bash file, but some strange new things appers in the deamon file: some old kernel one ( few days old) and inedt one "Jun  2 12:36:18 ts inetd[188]: /usr/openwin/bin/Xaserver: Hangup"
> 
> Since filter directive are supposed to be ANDed, I am a bit confused.
> 
> I am still debugging...

So I thing have found what's wrong:

there is:
log
{
	source( local);
	source( network);

	destination( all);
};

at the begging of my log section, which get all message leaving nothing for the faclity( DEFAULT); statment.

So I remove it and put the DEFAULT in all "general" log {} but find a new strange beahvior: auth facility goes to user log !. Finaly I found this mistake too: the log {} user was the first one containing filter( DEFAULT); .

So my conclusion:

- filter( DEFAULT); don't allow to "duplicate those but don't duplicate thease"
- filter( DEFAULT); make forward every log to another host difficult to get
- filter( DEFAULT); have bug.
- filter( DEFAULT); is too hard to understand for me :-)

Could we have another way to "duplicate those but don't duplicate thease" quickly ? I hope there is not more important stuff in the corner...



Un