On Jun 27, 2010, Franck Joncourt wrote:

> Hi,

Hi,

Apologies for the long delay.

> > Even if rsyslog is the default syslog-type logging daemon
> > under lenny ( I'm using debian version 5.0.4, i.e. the stable
> > release of debian now ), the psad rsyslogd support is
> > incomplete. I'm using the default configuration file
> > /etc/psad/psad.conf contained in the psad package.
> 
> As a matter of fact since 2.1.3 iptables log messages are parsed by default
> from /var/log/messages to avoid playing with the different logging daemons.
> 
> Here is the relevant part of the changelog:
> 
>  Updated to enable IPT_SYSLOG_FILE by default.  This is a relatively
>  important change since it changes the method of acquiring iptables log
>  data from reading it out of named pipe from syslog to just
>  parsing the /var/log/messages file.  This implies that kmsgsd does not
>  have to run, and that it is much easier to ensure that psad actually receives
>  iptables log messages. The most complex and error prone aspect of psad
>  in the past has been the reconfiguration of the various syslog daemons
>  out there (which have very different configuration syntax and features)
>  to write kern.info messages to the /var/lib/psad/psadfifo named pipe.

Indeed, this is the most important factor.  Lukas, have you set
ENABLE_SYSLOG_FILE to "N"?  I would recommend against this as it really
isn't necessary per the above.  Just point the IPT_SYSLOG_FILE variable
to whatever file your rsyslog daemon writes iptables log messages to.

> > 1)
> > The original psad configuration file /etc/psad/psad.conf
> > contains the SYSLOG_DAEMON variable, which ( according to
> > the description in psad.conf ) can have four different
> > types of variables - syslogd, syslog-ng, ulogd or metalog.
> > But the value rsyslogd is missing!!! Even if psad has
> > also an rsyslogd support.
> 
> [...]
> > I.e. we can see that psad has rsyslogd support and it's not
> > mentioned in the configuration file comment, which is also
> > the only (or the easy-to-find) documentation!!! I suggest
> > to add rsyslogd to the list of the supported syslog-type
> > servers.
> 
> That one is thus easy to fix :)
> 
> > 2)
> > If we define the syslog-type server as rsyslogd and move
> > the /etc/rsyslog.conf file so that it cannot be found,
> > we get an email with the following subject from psad:
> 
> > [psad-error] /etc/syslog.conf does not exist, check
> > SYSLOG_DAEMON setting
> 
> [...]
> 
> Indeed, there is some conditions missing somewhere in the source code.
> As it seems you have dig into the code, would you mind providing a patch?
> That would be easier.

I made a minor patch - the error above should really just reference
whatever syslog config file path is selected based on the value of the
SYSLOG_DAEMON variable.

http://trac.cipherdyne.org/trac/psad/changeset/2286

This is not a complete solution, but it really does not make sense to
try and support syslog daemon configs directly.  The proper strategy
(as pointed out by Franck above and implemented in psad since 2.1.3 as
he mentioned) is just for psad to parse iptables log messages out of
whatever file it is configured to parse (via the IPT_SYSLOG_FILE var).
Then, handling complex syslog configurations is not necessary.

> > 3)
> > Even if rsyslogd is installed and configured properly according
> > to psad(8), i.e. /etc/rsyslog.conf contains the line:
> > ...
> > kern.info       |/var/lib/psad/psadfifo
> > ...
> 
> > psad doesn't start if invoked using the startup script:
> > /etc/init.d/psad start
> > ERR: Syslog has not been configured to send messages to
> > /var/lib/psad/psadfifo. Please configure it as described in psad(8).
> 
> > The startup script /etc/init.d/psad should be changed so that it
> > supports also rsyslogd.
> 
> That is the old initscript. The latest one does not even care about checking
> thoses files since psad default's behaviour has changed, as mentionned at the
> beginning of this message.
> 
> I would definitely encourage you to use the default setup. If you supply a 
> patch
> for psad, and it does not require any further work, maybe Michael could merge 
> it to
> the current release.
> 
> I mean, if we start playing around the psadfifo settings, it is going to be
> bothering for everyone. The current psad release has still those options, but 
> I
> think it is more for backward compatibility.

Agreed.

> Micheal, if you think I should check for the psadfifo setup in the initscript,
> as Daniel did before, I will, just let me know if it worth. I only use(d) 
> syslog
> and rsyslog and I do not know if there is any difference with metalog, ulogd.

I don't think the init script should worry about the psadfifo setting
unless someone can supply a compelling reason.

Thanks,

--Mike

> Full discussion can be found at:
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586070
> 
> Regards,
> 
> -- 
> Franck Joncourt





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to