RE: SA Ignoring Config In LOCAL_RULES_DIR
On 16/9/2015 12:05 AM, Bowie wrote:
> It sounds like it might be an issue with your init script. Check the init
> script for spamassassin and see if it is starting spamd with a
> '--siteconfigpath' option or similar.
> You may also need to check in /etc/sysconfig if your init script pulls
> anything from there.
Thanks Bowie for your response, that thought had crossed my mind at some point
also, sorry I failed to mention how it was starting up. I couldn't see any
differences between working and not-working systems here and so I've included
the advised files on how it's set up and how the process is running.
With that said, I've narrowed the issue to be symbolic links, which I had
thought I tested before sending my original message, but I guess not. I've got
a btsync folder in /home that I link my exim and SA configuration files to, it
would seem of the 5 servers configured this way, 3 SA's are having issues
following the symbolic links. All the file permissions seem fine/the same as
working and non-working systems. Although with this development, I've scripted
a copy command when the files in /home/btsync change to copy them to
"/etc/mail/spamassassin" and restart the SA service. This stream lines future
changes even further, so win win really.
I would be great to work out why symbolic links are stuffing up in 60% of my SA
installs, but I think my care level is running low now. Thank you again Bowie
for your support is has been greatly appreciated.
This still leaves one system in an interesting state, that seems to read
local.cf and addresses.cf files but ignores the latestspam.cf. I've tried
renaming it to a.cf created a new file called newspam.cf and pasted the
data into it, but it continues to ignore the data within. Yet moving this to
the local.cf file, no worries it blocks on this. I've confirmed that
"spamassassin --lint -D" sees the file but it doesn't seem to read it.
Sep 16 15:13:11.529 [10089] dbg: config: using "/etc/mail/spamassassin" for
site rules dir
Sep 16 15:13:11.529 [10089] dbg: config: read file
/etc/mail/spamassassin/addresses.cf
Sep 16 15:13:11.529 [10089] dbg: config: read file
/etc/mail/spamassassin/blocknathan.cf
Sep 16 15:13:11.539 [10089] dbg: config: read file
/etc/mail/spamassassin/latestspam.cf
Sep 16 15:13:11.539 [10089] dbg: config: read file
/etc/mail/spamassassin/local.cf
.
This is even further confirmed by creating a new file called blocknathan.cf
with only a single blacklist_from that is ignored also. Is there any further
debugging where you can see what it's read, or why it's not? What is making
addresses.cf special? and why can I move it to zzzaddresses.cf and it still
works :( I'm thinking a rebuild is due for this machine, as I can't back it up
live with VMware ESXi snapshot, as it was poorly imported, so unless anyone
else has any ideas I might just step up the migration.
Thanks again for reading, Nathan.
[root@avatar spamassassin]# ll
total 64
-rw-r--r--. 1 root root 1418 Sep 16 15:17 addresses.cf
drwxr-xr-x. 2 root root 4096 Feb 17 2013 channel.d
-rw-r--r--. 1 root root 1299 Nov 16 2012 init.pre
-rw-r--r--. 1 root root 7637 Sep 16 14:13 latestspam.cf
-rw-r--r--. 1 root root 10815 Sep 16 15:09 local.cf
drwx--. 2 root root 4096 Sep 16 01:10 sa-update-keys
-rw-r--r--. 1 root root62 Nov 16 2012 spamassassin-default.rc
-rwxr-xr-x. 1 root root35 Nov 16 2012 spamassassin-helper.sh
-rw-r--r--. 1 root root55 Nov 16 2012 spamassassin-spamc.rc
-rw-r--r--. 1 root root 2524 Nov 16 2012 v310.pre
-rw-r--r--. 1 root root 1194 Nov 16 2012 v312.pre
-rw-r--r--. 1 root root 2416 Nov 16 2012 v320.pre
-rw-r--r--. 1 root root 1237 Nov 16 2012 v330.pre
[root@mail2 ~]# ps aux | grep spamd
root 43121 0.0 4.5 244384 32116 ?Ss 05:05 0:06 /usr/bin/spamd
-d -c -m5 -H -r /var/run/spamd.pid
nobody 43128 2.4 8.1 255396 56804 ?R05:06 4:55 spamd child
root 43130 0.0 7.3 249660 51432 ?S05:06 0:12 spamd child
[root@mail2 ~]# cat /etc/sysconfig/spamassassin
# Options to spamd
SPAMDOPTIONS="-d -c -m5 -H"
[root@mail2 ~]# cat /etc/rc.d/init.d/spamassassin
#!/bin/sh
#
# spamassassin This script starts and stops the spamd daemon
#
# chkconfig: - 78 30
# processname: spamd
# description: spamd is a daemon process which uses SpamAssassin to check \
# email messages for SPAM. It is normally called by spamc \
# from a MDA.
# Source function library.
. /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 -c -m5 -H"
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
Re: SA Ignoring Config In LOCAL_RULES_DIR
On 9/16/2015 3:30 AM, Nathan wrote: On 16/9/2015 12:05 AM, Bowie wrote: It sounds like it might be an issue with your init script. Check the init script for spamassassin and see if it is starting spamd with a '--siteconfigpath' option or similar. You may also need to check in /etc/sysconfig if your init script pulls anything from there. Thanks Bowie for your response, that thought had crossed my mind at some point also, sorry I failed to mention how it was starting up. I couldn't see any differences between working and not-working systems here and so I've included the advised files on how it's set up and how the process is running. With that said, I've narrowed the issue to be symbolic links, which I had thought I tested before sending my original message, but I guess not. I've got a btsync folder in /home that I link my exim and SA configuration files to, it would seem of the 5 servers configured this way, 3 SA's are having issues following the symbolic links. All the file permissions seem fine/the same as working and non-working systems. Although with this development, I've scripted a copy command when the files in /home/btsync change to copy them to "/etc/mail/spamassassin" and restart the SA service. This stream lines future changes even further, so win win really. I would be great to work out why symbolic links are stuffing up in 60% of my SA installs, but I think my care level is running low now. Thank you again Bowie for your support is has been greatly appreciated. selinux? I'm not an expert in that area, but I know it can cause some really strange problems if it's not set up right. This still leaves one system in an interesting state, that seems to read local.cf and addresses.cf files but ignores the latestspam.cf. I've tried renaming it to a.cf created a new file called newspam.cf and pasted the data into it, but it continues to ignore the data within. Yet moving this to the local.cf file, no worries it blocks on this. I've confirmed that "spamassassin --lint -D" sees the file but it doesn't seem to read it. Sep 16 15:13:11.529 [10089] dbg: config: using "/etc/mail/spamassassin" for site rules dir Sep 16 15:13:11.529 [10089] dbg: config: read file /etc/mail/spamassassin/addresses.cf Sep 16 15:13:11.529 [10089] dbg: config: read file /etc/mail/spamassassin/blocknathan.cf Sep 16 15:13:11.539 [10089] dbg: config: read file /etc/mail/spamassassin/latestspam.cf Sep 16 15:13:11.539 [10089] dbg: config: read file /etc/mail/spamassassin/local.cf . This is even further confirmed by creating a new file called blocknathan.cf with only a single blacklist_from that is ignored also. Is there any further debugging where you can see what it's read, or why it's not? What is making addresses.cf special? and why can I move it to zzzaddresses.cf and it still works :( I'm thinking a rebuild is due for this machine, as I can't back it up live with VMware ESXi snapshot, as it was poorly imported, so unless anyone else has any ideas I might just step up the migration. [root@mail2 ~]# ps aux | grep spamd root 43121 0.0 4.5 244384 32116 ?Ss 05:05 0:06 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid Try running spamd manually in debug mode. That way you can see exactly what it's doing. Just remove the -d and add -D. # service spamassassin stop # /usr/bin/spamd -D -c -m5 -H -r /var/run/spamd.pid > /tmp/spamd-debug.log 2>&1 Run spamc with a test file from another window to confirm the problem still exists. Once you are done testing, kill the debug version with Ctrl-C and 'service spamassassin start' to get running normally again. Go check the log file to see what files it loaded and whether any errors were generated. -- Bowie
SA Ignoring Config In LOCAL_RULES_DIR
Hello, and thank you in advanced for looking into the below, I've been
pondering over this issue for the past number of days, and don't feel I'm
getting anywhere now.
I am a system administrator and have been using a Exim/ClamAV/SpamAssassin
setup for around 8 years, over which time I had felt I had learnt all the in's
and out of the system, but this one has struck me as straight out annoying. I
have got seven systems of different age, and operating systems (either Fedora
or CentOS). I'll base the below on one of these systems, but it's important to
note I'm having this issue on four of the seven machines. So therefore I have
compared the config files I would normally use between working and nonworking
systems to try and find the fault, but everything appears to be the same. All
systems are at different point of updates, and I've tried to "yum update" a
faulty machine to fix any bugs but not updated a working machine to see if it
breaks.
What I am finding is any config saved in the "/etc/mail/spamassassin/" folder
is loaded during a "spamassassin --lint -D" but ignored during operations. For
example I have a "addresses.cf" file for whitelist_to & from as well as
blacklisted_to & from and these are simply ignored, no 100 or -100 score is
added to the email header report. I've also got a "latestspam.cf" that I've
hand written to block the latest breed of spams that I find an "sa-update"
doesn't correct, again these are ignored.
I've managed to get my local rules going again by moving the contents of these
files into " /var/lib/spamassassin/3.003001/updates_spamassassin_org/local.cf"
so my users aren't screaming at me anymore, this is confirmed using a
"blacklist_from" and a 100 score is added. This is a fine temporary fix, but I
would love for this directory to start working correctly again and to separate
these data sets, for synchronization and update proposes.
Exim is talking to the spamassassin process by using 127.0.0.1:783, and I've
confirmed this connection, as when I stop the SA process, Exim complains it is
missing in action.
I have checked all the files in "/etc/mail/spamassassin/" in case something
isn't toggled correct but I'm wondering where SA looks initially for it
configuration folders. I.E. how does it know about the
"/var/lib/spamassassin/3.003001/updates_spamassassin_org/" folder? I feel as
if I'm missing a master configuration file somewhere. Or is anyone aware what
would be making SA ignore my local.cf file in the expected LOCAL_RULES_DIR as
listed in the "lint".
I feel I've had a good look online and through the
http://spamassassin.apache.org/ wiki and etc. I'm sorry if it is a simple
issue and I'm just doing something wrong. Thanks again.
[root@mail2 ~]# ss -tlp
State Recv-Q Send-Q
Local Address:Port
Peer Address:Port
LISTEN 0 128
127.0.0.1:783
*:*
users:(("spamd",18049,5),("spamd",20074,5),("spamd",35678,5))
[root@mail2 ~]# spamassassin -V
SpamAssassin version 3.3.1
running on Perl version 5.10.1
[root@mail2 ~]# exim -bV
Exim version 4.72 #1 built 10-Oct-2014 09:23:33
Copyright (c) University of Cambridge, 1995 - 2007
Berkeley DB: Berkeley DB 4.7.25: (September 9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc TCPwrappers OpenSSL
Content_Scanning DKIM Old_Demime
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz
dnsdb dsearch ldap ldapdn ldapm nis nis0 nisplus passwd sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
OpenSSL compile-time version: OpenSSL 1.0.1e-fips 11 Feb 2013
OpenSSL runtime version: OpenSSL 1.0.1e-fips 11 Feb 2013
Configuration file is /etc/exim/exim.conf
[root@mail2 ~]# service spamassassin stop
Stopping spamd:[ OK ]
==> /var/log/exim/main.log <==
2015-09-15 15:00:43 1ZbkEL-0009T1-Ob DKIM: d=icontactmail6.com s=default
c=relaxed/relaxed a=rsa-sha256 [verification succeeded]
2015-09-15 15:00:43 1ZbkEL-0009T1-Ob spam acl condition: warning - spamd
connection to 127.0.0.1, port 783 failed: Connection refused
2015-09-15 15:00:43 1ZbkEL-0009T1-Ob spam acl condition: all spamd servers
failed
2015-09-15 15:00:44 1ZbkEL-0009T1-Ob <=
bounces+1507538.10770803.82...@icpbounce.com H=drone058.ral.icpbounce.com
[64.132.109.50] P=esmtp S=13408
[root@mail2 ~]# service spamassassin start
Starting spamd:[ OK ]
==> /var/log/exim/main.log <==
2015-09-15 14:46:26 1Zbk0W-000Bcg-Bv
Re: SA Ignoring Config In LOCAL_RULES_DIR
On 9/15/2015 3:55 AM, Nathan wrote: What I am finding is any config saved in the "/etc/mail/spamassassin/" folder is loaded during a "spamassassin --lint -D" but ignored during operations. For example I have a "addresses.cf" file for whitelist_to & from as well as blacklisted_to & from and these are simply ignored, no 100 or -100 score is added to the email header report. I've also got a "latestspam.cf" that I've hand written to block the latest breed of spams that I find an "sa-update" doesn't correct, again these are ignored. I've managed to get my local rules going again by moving the contents of these files into " /var/lib/spamassassin/3.003001/updates_spamassassin_org/local.cf" so my users aren't screaming at me anymore, this is confirmed using a "blacklist_from" and a 100 score is added. This is a fine temporary fix, but I would love for this directory to start working correctly again and to separate these data sets, for synchronization and update proposes. Exim is talking to the spamassassin process by using 127.0.0.1:783, and I've confirmed this connection, as when I stop the SA process, Exim complains it is missing in action. I have checked all the files in "/etc/mail/spamassassin/" in case something isn't toggled correct but I'm wondering where SA looks initially for it configuration folders. I.E. how does it know about the "/var/lib/spamassassin/3.003001/updates_spamassassin_org/" folder? I feel as if I'm missing a master configuration file somewhere. Or is anyone aware what would be making SA ignore my local.cf file in the expected LOCAL_RULES_DIR as listed in the "lint". It sounds like it might be an issue with your init script. Check the init script for spamassassin and see if it is starting spamd with a '--siteconfigpath' option or similar. You may also need to check in /etc/sysconfig if your init script pulls anything from there. -- Bowie
