I like the idea of having syslog messages duplicated. In a very large enterprise you have multiple groups wanting access to the same information. System administration is looking for availability related logs Security administration is looking for security related logs. Groups above may having overlapping facility and level requirements. Such as SysAdmins needing kern.notice for kernel output, and SecAdmins needing this log to catch Solaris stack executable buffer overflow attempts. If I were in security parsing syslog output, I would not want the system administration group grabbing all the content with nothing left for the security administrators to pull from. This is especially true for environments where system administration and security administration for a server has been separated into different groups with different management reporting structures. Perhaps as a compromise, a configuration setting in syslog-ng that controls fall-through. -- offset -- John Goggan wrote:

ger wrote:

...

try filter f_daemon { facility(daemon) and not program(name);};

where "name" is whatever program you're trying to filter out.

Thanks to Ger and Ilya for their responses. While this does work, it really seems like a poor way to do it to me -- and, I believe, is also quite a bit different from the way standard syslog handles things. The problem is that it should just be easy to make it so that messages are handled only ONCE and then not sent to additional logs unless specifically desires. How many people really want the same syslog message sent to multiple logs most of the time? It just seems that the default (which does this) is the opposite of what most would want.

Plus, what needs to be done to get around this just doesn't make any sense. This means that if I want separate logs for imapd, named, telnetd, and ftpd (to name just a few common daemons) -- and I want any other daemons that pop up to still go to a daemon.log, I have to do this in my filter section:

filter f_imapd { program("imapd"); }; filter f_named { program("named"); }; filter f_telnetd { program("telnetd"); }; filter f_ftpd { program("ftpd"); }; filter f_auth { facility(auth) and not program("imapd") and not program("named") and not program("telnetd") and not program("ftpd"); }; filter f_daemon { facility(daemon) and not program("imapd") and not program("named") and not program("telnetd") and not program("ftpd"); }; filter f_messages { level(info..warn) and not facility(auth, authpriv, mail, news); and not program("imapd") and not program("named") and not program("telnetd") and not program("ftpd"); };

That just seems like a really bad design! I have to make sure that I keep all of the names updated in several different locations. If I want to add a log for just one more daemon, I have to add it to at least 3 other filters besides its own filter!

Aren't other people experiencing such problems? Or is no one out there using syslog-ng to filter out specific daemons while still catching the unlisted daemons in a daemon.log file?

There must be a better way...

- John...

_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu http://lists.balabit.hu/mailman/listinfo/syslog-ng

----------------------------------------------------------------

Link is external to the Privacyx.com System