spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jerry Malcolm <>
Subject Re: Where is SA getting config info?
Date Fri, 22 Nov 2019 22:06:17 GMT
Well,  I thought I finally had everything resolved.  When I run 
spamassassin -D --lint I get the lines:

Nov 22 21:57:57.954 [13813] dbg: bayes: tie-ing to DB file R/O 
Nov 22 21:57:57.954 [13813] dbg: bayes: tie-ing to DB file R/O 
Nov 22 21:57:57.955 [13813] dbg: bayes: found bayes db version 3

So, I'm ready to start it up as a daemon and start using it... I checked 
/var/log/maillog and see this instead:

Nov 22 21:58:21 ip-172-31-47-84 spamd[13780]: bayes: no dbs present, 
cannot tie DB R/O: /tmp/spamd-13780-init/.spamassassin/bayes_toks

When running the same SA as a service, it's NOT looking for bayes in 
/root/.spamassassin.  Rather it's trying to find it in some random name 
temp folder.

What am I doing wrong this time?


On 11/22/2019 1:38 PM, Jerry Malcolm wrote:
> Kris,
> This was exactly the info I was looking for.  Thank you so much. I'm 
> down to one issue with the bayes_path parm.  From what you have 
> described, I assume what I put in is being overridden by some 
> other cf file.  I really don't care at this point what folder to use.  
> I just moved my bayes_toks file to the folder SA is saying it wants to 
> use.
> My last problem (for today) is figuring out how to get my old 
> bayes_toks into a format that the current SA likes.  I posted that in 
> a separate thread.  Thank you again.
> Jerry
> On 11/22/2019 1:17 PM, Kris Deugau wrote:
>> Jerry Malcolm wrote:
>>> I am trying to add bayes to SA.  I see in the docs that there is a 
>>> use_bayes parm and the path parm. I made the changes to 
>>> /usr/share/spamassassin/  But I see no change.  I am not 
>>> sure it's even loading that config file. I've got debug on, and the 
>>> log doesn't tell me that it's reading the file I'm changing.
>> SA's core rules used to be loaded from /usr/share/spamassassin, but 
>> it's mostly just a last-resort fallback at this point. Active core 
>> rules are loaded from /var/lib/spamassassin, and updated 
>> automatically with sa-update.  You're making changes to a file that 
>> may not even be looked at, and if it is it's overridden by files 
>> loaded later.
>> You shouldn't change files in either location, because they'll be 
>> overwritten without notice (on package upgrades, for the files in 
>> /usr/share/spamassassin;  on the next ruleset update by sa-update for 
>> /var/lib/spamassassin).
>>> I think I need to go back to the basics. I simply want a 100% 
>>> site-wide SA (no per-user anything). I've read of the config docs. 
>>> It describes every parameter. But it doesn't really put the big 
>>> picture together. Is there a "SpamAssassin for Dummies" doc that 
>>> describes the command line args for 'site-wide-only' and also which 
>>> config file ( in which folder I should be changing?
>> Your own local configuration for SA should be almost entirely in 
>> /etc/spamassassin or /etc/mail/spamassassin depending on how SA was 
>> packaged.  SA will load any file ending with .cf from this directory.
>> The first few lines of the debug output should show something like:
>> Nov 22 13:46:46.298 [26759] dbg: generic: Perl 5.020002, PREFIX=/usr, 
>> DEF_RULES_DIR=/usr/share/spamassassin, 
>> LOCAL_RULES_DIR=/etc/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin
>> SA will look for rules in DEF_RULES_DIR, LOCAL_STATE_DIR, then 
>> LOCAL_RULES_DIR, whatever they're set to.  Each later directory tree 
>> overrides anything set in an earlier one.
>>> The initial install of SA on AWS Linux EC2 has a SPAMDOPTIONS="-d -c 
>>> -m5 -H".  I was told a few months back in this forum that -H without 
>>> a parameter following is not even valid and it applies to per-user 
>>> stuff. So I removed the -H.  I read that -c creates a user pref file 
>>> which sounds like per-user.  So I removed that. But the log is 
>>> telling me it's loading files from /etc/mail which I thought the 
>>> docs said was per-user stuff.  Basically, I can't figure out how to 
>>> make any config changes that are actually seen by SA.
>> A few fragments for the spamd daemon arguments should be in 
>> /etc/sysconfig/spamassassin on Red Hat and derivatives like AW Linux. 
>> (The actual file might be spamd;  it's been a while since I used RH 
>> systems for SA.)
>> Make your local changes in this file;  like the SA rules, the init 
>> script in /etc/init.d will also be overwritten without notice on a 
>> package upgrade.
>>> So... questions:
>>>      -- first just to make SA run as 'site-wide-only', should the 
>>> command line args be "-d -m5"? (or do I really need to go back to 
>>> "-d -c -m5 -H"?
>> No, removing those options is OK for your use.  You will probably 
>> want to add -x to skip loading per-user configuration.
>> You may want to add "-u spamd" to make sure spamd is running as its 
>> own unprivileged user.  The specific user might be something else - 
>> for instance the Debian packages provide a "debian-spamd" user 
>> instead. You'll have to check /etc/passwd to see if one was created, 
>> and what it is.
>> Check the spamd man page for any other options you might want set.
>>>      -- What file should I be changing to adjust config?  If it's 
>>> indeed /usr/share/spamassassin/, is there something I can 
>>> change in there that I can force something in the log file to assure 
>>> me that config parms are really being pulled from here?
>> Your configuration can go in any .cf file in /etc/mail/spamassassin.  
>> By convention, should have your major options (sitewide 
>> Bayes, message tagging method, default "this is spam" threshold, 
>> etc), but there's nothing in the SA code that makes it special IIRC.
>> If you just have a few extra things to add, it's probably easiest to 
>> add them to this file.  If you have a long list of things (eg a long 
>> local blacklist and/or whitelist) you may want to put them in 
>> different .cf files for convenient management.
>>>      -- Shouldn't "use_bayes 1" cause something to appear in the 
>>> debug log saying something about bayes now in use (and something 
>>> about the bayes_toks file)?
>> Only if not overridden by a "later" file.  Initially most of the 
>> messages you'll see should indicate that Bayes has not been trained 
>> with enough messages.  For sitewide operation you'll need to set 
>> bayes_path or the related database-related options to force SA to use 
>> your sitewide Bayes database instead of a per-user one.
>>>      -- Finally, where should I put custom rule files such as 
>>> so they are used, but not erased with sa_update?
>> /etc/mail/spamassassin, alongside
>>> If all of this is explained in some user scenario docs, please point 
>>> me to them.  It's just really tough getting the big picture here 
>>> especially when I can't get ANY config changes to make any difference.
>> Spend a while reading the Mail::SpamAssassin::Conf manpage. Most of 
>> the SA configuration is documented here.
>> -kgd

View raw message