Jerry,
Let's back up a bit.
Let us see your distro via the command lsb_release -a
Also the version via uname -r
Additionally, how did you install spamassassin please ?
On 11/23/19 1:07 PM, Jerry Malcolm wrote:
Bob & John.... Thanks so much for the info. But as if I wasn't dazed
& confused enough already, I have discovered a new variable to the
whole thing. I have set up a couple of sandbox EC2 instances just to
play. I didn't realize it at first, but one is AWS Linux 1 and the
other is AWS Linux 2. And the whole startup file structure is
different between the two. The Linux 1 env does indeed have
/etc/init.d/spamassassin. But I don't see anything that looks like
it's setting a user to 'spamd'. In the Linux 2 env, I have:
/usr/lib/systemd/system/spamassassin.service that starts
/usr/bin/spamd using options file /etc/sysconfig/spamassassin
I read elsewhere that a "User=" parm can be added to a .service file.
But the one I have has nothing related to user. The usr/bin/spamd
file is nearly 4000 lines. It's setting the folders, logging, etc.
So it appears to be the main script. But from my understanding, the
user would already be set prior to this script being called.
Kris D suggested I add "-u spamd" to the options file. But I looked
in /etc/passwd and there is no spamd user. There is no user defined
that even remotely resembles an id that SA would have created. (This
is all on the Linux 2 instance, haven't checked the Linux 1 instance yet).
I can hack around and add a spamd user and add the parameters to make
spamd run as that id and then check the logs to see where SA is
looking now for bayes_*. But that seems to be a fairly wide departure
from an out-of-the-box experience. Does this seem right? I always
very cautious before claiming "bug". But it is possible some critical
items were left out of the AWS Linux 2 install package for SA? Should
I go ahead and add the spamd user?
Thx again.
Jerry
