Re: Logging with Syslog
sa-list wrote: > The current SA install was from my initial install of RHEL 4 and using > up2date to get the packages all current. I figured I would stop using > up2date from this point on and switch to CPAN upgrades in the future. Be sure to *uninstall* the RPM package before installing from CPAN - keeping the RPM install while you add a CPAN install of SA is known to cause strange behaviour. > The base RHEL4 with the latest service release only > installed SA 3.04. RH then jumped from 3.04 to 3.18 about 6 weeks ago > using the up2date system. This is largely normal; much like Debian's policy, packages are not just rolled out to the stable release tree whenever a new upstream version is released. RedHat has often been more lax in this repsect than Debian; it's truly rare to see more than a minor upstream version bump in a Debian package through the course of the stable release cycle. I use a third-party repository (Dag/RPMForge, http://dag.wieers.com/rpm/) for things like SpamAssassin that change more quickly that the OS release cycle. It's also useful for extra Perl modules that aren't provided by the upstream OS release. I prefer to only install software one way if at all possible; it keeps the system a little more organized. -kgd
Re: Logging with Syslog
The current SA install was from my initial install of RHEL 4 and using up2date to get the packages all current. I figured I would stop using up2date from this point on and switch to CPAN upgrades in the future. The CPAN method is what I had used before and it worked nicely, plus I can stay more current with CPAN. I never know when RH will be shipping updates for SA. The base RHEL4 with the latest service release only installed SA 3.04. RH then jumped from 3.04 to 3.18 about 6 weeks ago using the up2date system. I would rather not wait for RH to approve SA updates since this server is mainly a mail server and spammers don't wait around for RH to catch up with them. This server was upgraded from RHEL3. RH never released an update for SA beyond 2.x for RHEL3. If I had waited for them, I would have really been out of date. If RH behaves the same, now that RHEL5 has shipped they may stop keeping RHEL4 current on a lot of different packages. Plus, I'll be adding plugins as I go along and I have no idea what might get messed up with a RH package update. Do you know of any problems with switching from the RH package manager to using CPAN from this point forward? Kris Deugau writes: sa-list wrote: Thanks! Instead of messing with the /etc/sysconfig/spamassassin file, I just commented out those lines. Any reason to keep this configuration, other than wanting more headaches in the future when I try to figure this out again? Well, like I said, /etc/init.d/spamassassin will usually be overwritten on a package upgrade. That's why the files in /etc/sysconfig are provided for quite a few packages - if you have custom startup options to be passed to whichever daemon the file is for, you put them there so they stay set the way you want them when you upgrade the package. Debian does something very similar, except the options files are in /etc/default (I think). Editing the init script should really only be used as a last resort, because you will almost certainly have to go back and try to remember what you changed if you install a newer version of the package. -kgd
Re: Logging with Syslog
sa-list wrote: > Thanks! > Instead of messing with the /etc/sysconfig/spamassassin file, I just > commented out those lines. Any reason to keep this configuration, other > than wanting more headaches in the future when I try to figure this out > again? Well, like I said, /etc/init.d/spamassassin will usually be overwritten on a package upgrade. That's why the files in /etc/sysconfig are provided for quite a few packages - if you have custom startup options to be passed to whichever daemon the file is for, you put them there so they stay set the way you want them when you upgrade the package. Debian does something very similar, except the options files are in /etc/default (I think). Editing the init script should really only be used as a last resort, because you will almost certainly have to go back and try to remember what you changed if you install a newer version of the package. -kgd
Re: Logging with Syslog
Thanks! Instead of messing with the /etc/sysconfig/spamassassin file, I just commented out those lines. Any reason to keep this configuration, other than wanting more headaches in the future when I try to figure this out again? Kris Deugau writes: sa-list wrote: I can't seem to get SA & Syslog to log messages to a log file other than maillog. I changed the spamassassin start up script to add "-s local5" to the spamd start up options. [snip] ... on RHEL4. [snip] The top part of my /etc/init.d/spamassassin is: [snip] # Set default spamd configuration. SPAMDOPTIONS="-d -m5 -H -s local5" SPAMD_PID=/var/run/spamd.pid # Source spamd configuration. if [ -f /etc/sysconfig/spamassassin ] ; then . /etc/sysconfig/spamassassin fi This is the part of the init script that's tripping you up. Most RH-oriented init scripts are managed by the packaging system, and among other things will usually be overwritten by package upgrades. Thus the last three lines in that segment; it overrides the package default options with whatever you set in /etc/sysconfig/spamassassin. In this case, it also overrides the change you made in the previous lines. Add your "-s local5" to the SPAMDOPTIONS definition in /etc/sysconfig/spamassassin, and you should get your syslog output in the right place. ps x|grep spamd should show you the full command line of the currently-running spamd. -kgd
Re: Logging with Syslog
sa-list wrote: > I can't seem to get SA & Syslog to log messages to a log file other than > maillog. > I changed the spamassassin start up script to add "-s local5" to the > spamd start up options. [snip] > ... on RHEL4. [snip] > The top part of my /etc/init.d/spamassassin is: [snip] > # Set default spamd configuration. > SPAMDOPTIONS="-d -m5 -H -s local5" > SPAMD_PID=/var/run/spamd.pid > # Source spamd configuration. > if [ -f /etc/sysconfig/spamassassin ] ; then >. /etc/sysconfig/spamassassin > fi This is the part of the init script that's tripping you up. Most RH-oriented init scripts are managed by the packaging system, and among other things will usually be overwritten by package upgrades. Thus the last three lines in that segment; it overrides the package default options with whatever you set in /etc/sysconfig/spamassassin. In this case, it also overrides the change you made in the previous lines. Add your "-s local5" to the SPAMDOPTIONS definition in /etc/sysconfig/spamassassin, and you should get your syslog output in the right place. ps x|grep spamd should show you the full command line of the currently-running spamd. -kgd
Logging with Syslog
I can't seem to get SA & Syslog to log messages to a log file other than
maillog.
I changed the spamassassin start up script to add "-s local5" to the spamd
start up options. I modified syslog.conf to add local5 as an entity. I
restarted syslog, courier and spamd. I still get logging messages in
/var/log/maillog instead of the desired /var/log/spamd.log.
I tested the syslog change using:
logger -p local5.warning -t SpamAssassin "testing"
This gives me the appropriate message written into the /var/log/spamd.log
file so it makes me think the syslog changes actually work.
What am I doing wrong?
I am using Courier 0.54.2 on RHEL4. SA is 3.1.8.
My Courier maildroprc is:
import RECIPIENT
import SENDER
import HOME
import USER
{
exception {
xfilter "/usr/bin/spamc -u $USER"
}
}
This is working and I am getting email with the SA headers added.
The top part of my /etc/init.d/spamassassin is:
. /etc/rc.d/init.d/functions
prog="spamd"
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
# Set default spamd configuration.
SPAMDOPTIONS="-d -m5 -H -s local5"
SPAMD_PID=/var/run/spamd.pid
# Source spamd configuration.
if [ -f /etc/sysconfig/spamassassin ] ; then
. /etc/sysconfig/spamassassin
fi
[ -f /usr/bin/spamd -o -f /usr/local/bin/spamd ] || exit 0
PATH=$PATH:/usr/bin:/usr/local/bin
# By default it's all good
RETVAL=0
# See how we were called.
case "$1" in
start)
# Start daemon.
echo -n $"Starting $prog: "
daemon $NICELEVEL spamd $SPAMDOPTIONS -r $SPAMD_PID
RETVAL=$?
echo
if [ $RETVAL = 0 ]; then
touch /var/lock/subsys/spamassassin
fi
;;
My syslog.conf is:
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none;local5.none
/var/log/messages
# The authpriv file has restricted access.
authpriv.* /var/log/secure
# Log all the mail messages in one place.
mail.* -/var/log/maillog
# Log cron stuff
cron.* /var/log/cron
# Everybody gets emergency messages
*.emerg *
# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler
# Save boot messages also to boot.log
local7.*/var/log/boot.log
# Save Spamassassin messages to spamd.log
local5.*/var/log/spamd.log
