For at least a year, the logwatch ebuild has apparently not modified the logwatch scripts to match the gentoo log system in which failed logins (e.g. by ssh) are recorded in /var/log/auth.log instead of the /var/log/secure that logwatch checks by default. I've worked round by modifying logwatch or symlinking, but I think it's important that logwatch should work properly: it is tempting to believe on the first times of using it that there _haven't_ been any unwelcome would-be visitors.
not really ... it depends on the logging daemon you use as to where the auth failures are stored what logging daemon are you using ?
(In reply to comment #1) Ahh -- I use sysklogd. I haven't ever tried to see what files the others use for auth.* . So I see why it's not so strange that perfect correspondence between logwatch and the logger hasn't been achieved. But still -- to make gentoo so that (as would seem sensible) one can emerge an arbitrary system logger and a logwatch program, and have them work properly together, I see two reasonable possibilities: * modify all loggers to have consistent default files, unless perhaps "vanilla" build is chosen in $USE. * modify logwatch so that if it doesn't find a particular file it tries other known names used by other loggers Of these the latter strikes me as better since only one program need change, and it's not a big change--it is just compatible with more variations of the system.
> * modify all loggers to have consistent default files, unless perhaps > "vanilla" build is chosen in $USE. no good ... the way each logger works can vary quite drastically > * modify logwatch so that if it doesn't find a particular file it tries > other known names used by other loggers this does sound like the best course of action
(In reply to comment #0) > For at least a year, the logwatch ebuild has apparently not modified the > logwatch scripts to match the gentoo log system in which failed logins (e.g. > by ssh) are recorded in /var/log/auth.log instead of the /var/log/secure > that logwatch checks by default. where exactly do you see references to either of these files ?
There is no reference to auth.log within logwatch, hence the problem, but it is seen in for example ` syslogd-listfiles -a `. The file /var/log/secure is referred to by several logwatch files, suggesting that secure, pam_unix, sudo, sshd and other services are all missed from logwatch when using sysklogd. See the grep output below: note that /etc/log.d/conf/logwatch.conf defines LogDir=/var/log, so the "secure" file is relative to this. $ grep -RHEn 'LogFile *= *secure.*' /etc/log.d /etc/log.d/conf/logfiles/secure.conf:14:LogFile = secure /etc/log.d/conf/services/ipop3d.conf:19:LogFile = secure /etc/log.d/conf/services/pam_unix.conf:19:LogFile = secure /etc/log.d/conf/services/pluto.conf:8:LogFile = secure /etc/log.d/conf/services/secure.conf:18:LogFile = secure /etc/log.d/conf/services/sshd.conf:18:LogFile = secure /etc/log.d/conf/services/stunnel.conf:18:LogFile = secure /etc/log.d/conf/services/sudo.conf:18:LogFile = secure /etc/log.d/conf/services/saslauthd.conf:18:LogFile = secure Regards, Nathaniel
is this still a problem w/ >7.3.2?
I believe this now works by default in 7.3.6 as the logfile group 'secure', which is used by the services listed above, now includes the following actual log files: # grep -RHEn 'LogFile' secure.conf secure.conf:14:LogFile = secure secure.conf:15:LogFile = authlog secure.conf:16:LogFile = auth.log secure.conf:17:LogFile = auth.log.0 (See /usr/share/logwatch/default.conf/logfiles/secure.conf)
this works in 7.3.6
