Hi, I should also apologize for the delay, I was on holidays.
Ad 1) If you add the string 'rsyslogd' to the list of supported syslog-type daemons, this problem is fixed. It's really simple, as Franck said. Ad 2) Michael wrote he has a patch already for this problem, so I consider this problem to be already solved too. Ad 3) I agree that the psad init script shouldn't check whether the kern.info messages are written to the psadfifo named pipe. It can cause only troubles if the default policy of psad of version 2.1.3 and higher is to parse directly the file /var/log/messages (or the file pointed to by IPT_SYSLOG_FILE). If this check is removed, I agree that even this third problem is solved. 4) However, I have one more question. Michael wrote: > 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. I haven't set ENABLE_SYSLOG_FILE to "N", it was set to "N" after installation by default. Franck explained that from version 2.1.3 kmsgsd isn't needed by default, because the default behaviour is to parse messages directly from IPT_SYSLOG_FILE (/var/log/messages by default). However, this isn't the case of my psad, even if I'm using the version 2.1.3-1.1 (the original version from the lenny stable release) and I haven't changed the default behaviour of psad. Both the init script and the man page psad(8) instructed me that I should configure my syslog-type daemon to write all kern.info messages to /var/lib/psad/psadfifo named pipe. The daemon kmsgsd than filtered these messages and sent all iptables messages to the file /var/log/psad/fwdata. I checked this behaviour and it was really like this, as also described in the man page psad(8). Do you have any idea why this behaviour differs from the behaviour described by Franck? As I already said, I'm using the version 2.1.3-1.1 and I haven't changed the default of ENABLE_SYSLOG_FILE in psad.conf, which is "N" by default. I installed psad a few months ago without using it and I don't know if there was any upgrade of psad since that time. Maybe there was some upgrade, but the old config file was used. Do you think this is possible? I'm not sure. But even my current man page psad(8) and the init script /etc/init.d/psad in psad version 2.1.3-1.1 tell me that I should configure syslog properly (to send all kern.info messages to /var/lib/psad/psadfifo named pipe). Lukas Michael Rash wrote: > 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
