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

List:       syslog-ng
Subject:    RE: [syslog-ng] Testing log paths
From:       "Orth, Alan" <AOrth () exchange ! csuchico ! edu>
Date:       2006-06-19 20:32:42
Message-ID: 081C0D986938494A97DE9D50AB7D034F032BFC23 () ESCHE ! csuchico ! edu
[Download RAW message or body]

I apologize, list... that e-mail was obviously not meant to be delivered to the list! \
:)  
-- 
Alan Orth
Upward Bound - Systems Administrator
User Services - Field Technician
California State University, Chico
x6000

________________________________

From: syslog-ng-bounces@lists.balabit.hu on behalf of Orth, Alan
Sent: Mon 6/19/2006 1:30 PM
To: Syslog-ng users' and developers' mailing list
Subject: RE: [syslog-ng] Testing log paths


Orlando,
 
Actually, I'm sitting in an office in San Ramon as we speak.  I'm interning here at \
Chevron for the summer!  
Tell Moon Jee I say "hi"! I hope someone in the tech shop can help you guys...
 
-- 
Alan Orth
Upward Bound - Systems Administrator
User Services - Field Technician
California State University, Chico
x6000

________________________________

From: syslog-ng-bounces@lists.balabit.hu on behalf of Balazs Scheidler
Sent: Mon 6/12/2006 4:06 AM
To: Syslog-ng users' and developers' mailing list
Subject: Re: [syslog-ng] Testing log paths



On Thu, 2006-06-08 at 13:32 -0600, Ryan Owen wrote:
> I'm looking for a way to test a syslog-ng configuration to see if a
> given message (generated by the local machine) will be logged.  This
> is for automated policy compliance measurement.  For example, I need a
> program or script to be able to tell me if all authpriv messages with
> priority debug or higher are logged somewhere.
> 
> With the old syslog stuff, the config file was easy enough to parse
> that a program could fairly easily determine this.  Syslog-ng's
> extremely flexible configuration mechanism is somewhat more difficult,
> though.
> 
> My current thinking is to take the lex/yacc grammar from the source
> and use it to write a program that could accept a message and return
> where it would be logged, if at all.  This is still a pretty complex
> task, though, so I was hoping that perhaps there would be a simpler
> way.  I'm not allowed to generate bogus log entries, or else I'd try
> spoofing a message of whatever facility/priority/etc that I needed to
> test for.
> 
> Does anyone know of a better way to accomplish this?

Hm... I think it should be doable with syslog-ng's code by using some
kind of command line switch to trigger configuration file validation.
Something similar to the archaic "ipchains -C" switch:

       -C, --check
              Check  the given packet against the selected chain.
              This is extremely useful for testing, as  the  same
              kernel  routines used to check "real" network pack-
              ets are used to check this packet.  It can be  used
              to check user-defined chains as well as the builtin
              ones.  The same arguments used to specify  firewall
              rules  are  used  to  construct  the  packet  to be
              tested.  In particular, the -s (source), -d (desti-
              nation),  -p  (protocol),  and -i (interface) flags
              are compulsory.

Of course some changes would definitely be needed to the core.

--
Bazsi

_______________________________________________
syslog-ng maillist  -  syslog-ng@lists.balabit.hu
https://lists.balabit.hu/mailman/listinfo/syslog-ng
Frequently asked questions at http://www.campin.net/syslog-ng/faq.html


["winmail.dat" (application/ms-tnef)]

_______________________________________________
syslog-ng maillist  -  syslog-ng@lists.balabit.hu
https://lists.balabit.hu/mailman/listinfo/syslog-ng
Frequently asked questions at http://www.campin.net/syslog-ng/faq.html



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