RE: Re [syslog-ng] Ignoring previously handled/filtered messages

26 May 2000

      I like the configuration option as well.  I would like to be able to
duplicate some but not others.   Of course we all want as fine a grain of
control as we can get.  I do all the filtering and parsing and reporting on
a considerable amount of log information, and while several places need to
see some of the same logs, for the most part only the sysadmins are
interested in it.  I make the reports I generate from the logs available on
the local intranet for whoever is interested, but I don't get to make all of
it available.  The security people are funny about that.  For the stuff I
want duplicated I can easily add a second or a third or a ... destination()
to a log function and get my duplication that way.  Matter of fact I prefer
to do this as it gives ME the control over the logging.

Anyway just my $.02 worth.

Thanks
Drew
...
-----Original Message-----
From:	offset [SMTP:offset@privacyx.com]
Sent:	Thursday, May 25, 2000 7:31 PM
To:	syslog-ng@venus.terrasoft.hu
Subject:	Re [syslog-ng] Ignoring previously handled/filtered messages
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
_______________________________________________
syslog-ng maillist  -  syslog-ng@lists.balabit.hu
http://lists.balabit.hu/mailman/listinfo/syslog-ng

RE: Re [syslog-ng] Ignoring previously handled/filtered messages

Hamilton, Andrew Mr.