fixed top-posting... On Tue, Jan 30, 2007 at 08:40:59AM -0800, Brian Hostetler wrote: > > > > On Mon, Jan 29, 2007 at 05:06:18PM -0800, Andrew > Sackville-West wrote: > > /var/log/mail.log > > > > Jan 29 10:32:36 bigmomma spamd[32442]: spamd: connection from bigmomma > > [127.0.0.1] at port 41420 > > Jan 29 10:32:36 bigmomma spamd[32442]: spamd: setuid to nobody > > succeeded > > Jan 29 10:32:36 bigmomma spamd[32442]: spamd: creating default_prefs: > > /nonexistent/.spamassassin/user_prefs > > Jan 29 10:32:36 bigmomma spamd[32442]: mkdir /nonexistent: Permission > > denied at /usr/share/perl5/Mail/SpamAssassin.pm line 1530 > > > Jan 29 10:32:36 bigmomma spamd[32442]: config: cannot write to > > /nonexistent/.spamassassin/user_prefs: No such file or directory > > Jan 29 10:32:36 bigmomma spamd[32442]: spamd: failed to create > > readable default_prefs: /nonexistent/.spamassassin/user_prefs > > Jan 29 10:32:36 bigmomma spamd[32442]: mkdir /nonexistent: Permission > > denied at /usr/share/perl5/Mail/SpamAssassin.pm line 1530 > > Jan 29 10:32:36 bigmomma spamd[32442]: spamd: checking message > > <[EMAIL PROTECTED]> for nobody:65534 > > Jan 29 10:32:49 bigmomma spamd[32442]: mkdir /nonexistent: Permission > > denied at /usr/share/perl5/Mail/SpamAssassin.pm line 1530 > > Jan 29 10:32:49 bigmomma spamd[32442]: locker: safe_lock: cannot > > create tmp lockfile > > /nonexistent/.spamassassin/auto-whitelist.lock.bigmomma. > > 32442 for /nonexistent/.spamassassin/auto-whitelist.lock: No such file > > or > directory > > Jan 29 10:32:49 bigmomma spamd[32442]: auto-whitelist: open of > > auto-whitelist file failed: locker: safe_lock: cannot create tmp > > lockfile /non > > existent/.spamassassin/auto-whitelist.lock.bigmomma.32442 for > > /nonexistent/.spamassassin/auto-whitelist.lock: No such file or > > directory > > Jan 29 10:32:49 bigmomma spamd[32442]: spamd: clean message (0.5/5.0) > > for nobody:65534 in 12.8 seconds, 6620 bytes. > > Jan 29 10:32:49 bigmomma spamd[32442]: spamd: result: . 0 - > > PLING_PLING > > scantime=12.8,size=6620,user=nobody,uid=65534,required_score=5.0,rhos > > t=bigmomma,raddr=127.0.0.1,rport=41420,mid=<[EMAIL PROTECTED]>,autolearn=no > > > > > > As I understand it, and frmo a little google, spamd changes its uid to > > 'nobody' when it get a message to scan. This causes a problem as it > > tries to update the AWL and bayes database files in > its $HOME with is > > nonexistent. One recommendation I found was to change the user for > > spamd from nobody to spamd, and create that user for just this > > purpose. This seems fine, but I don't like to migrate too far from > > default configs. Any other suggestions? is there something simple I'm > > missing here? (probably). is this new user, spamd, the way to go or > > should I be tweaking some other conf to make this work. > > okay solved to my satisfaction: > > modified /etc/default/spamassassin thus: > > OPTIONS="--create-prefs --max-children 5 --helper-home-dir -D > -x --virtual-config-dir=/srv/Mail/spamassassin" > > -x turns off the per-user configs, so its stops trying to create > /nonexistent... > > --virtual-config-dir=... does just that, point spamd to the specified > directory for its AWL files and bayes_* files. > > seems to work for me, though that -D sure puts up lots of nice > output > :) > > thanks all > > A > > > I've moved from Solaris to Debian and have a new >sendmail/spamassassin/milter installation (non-compiled) and I'm >getting these permissions errors as well. I keep a .spamassassin in my >home directory with a whitelist, userprefs, and bayes files. If I move >these to a central location, it's a requirement that user nobody has >read and write access or just read?
Essentially what happens is the default install of SA in Deb runs the child processes as 'nobody' when SA is called by root. This is what happens when SA is used in the ACL's of exim and probably in sendmail as well. sendmail calles SA as root, SA says "no can't be root" and forks a child with uid 'nobody'. SA also uses the "--create-prefs" option (see above OPTION line) which tells spamd to create the user's preference files in $HOME/.spamassassin/ but there is no $HOME for 'nobody'. Many people call SA from their local .procmailrc in which case SA is called as that user and spamd forks a child with that users uid and the prefs are created in $HOME/.spamassassin and all is well in that scenario. So you have a couple of options. 1) move your SA calls to some local-user-initiated setup such a procmail or whatever. In this case, as I said above, it calls SA as that user and all is fine. This however places the interfacing with SA in the hands of the user -- not ideal for *my* situation. 2) change the way spamd runs to use its own user (adduser spamd, for example). you do this with the -u flag in /etc/default/spamassassin. In this case spamd will always run as that user and the preferences will get stored in /home/spamd/.spamassassin... also not, for my case a great solution as its another user account to be maintained in some way. It does however provide site-wide SA control and centralized bayesian filters etc. 3) do what I did -- change the way spamd runs to tell it *NOT* to look for $HOME/.spamassassin (this is the -x flag above) and then tell it where to look for the prefs (this is the --virtual-config-dir above). This is the solution I settled on. It means I get site-wide spam control, no extra user/group to maintain, and centralised storage of the AWL, bayes_* etc. BTW, using 3 above, I left the '--create-prefs' in place and it did indeed create its prefs in /srv/Mail/spamassassin as confirmed here: [EMAIL PROTECTED]:~$ ls -l /srv/Mail/spamassassin/ total 576 -rw------- 1 root root 24576 2007-01-30 10:24 auto-whitelist -rw------- 1 nobody nogroup 24576 2007-01-30 10:24 bayes_seen -rw------- 1 nobody nogroup 651264 2007-01-30 10:24 bayes_toks note the uid/gid of the the bayes_* files. and apparently, the auto-whitelist is handled by the parent spamd which is running as root. interesting that. oh, I also setup the bayes_path in /etc/spamassassin/local.cf as # location for bayes filter database files # setup 1/2907 ASW, per spamassassin wiki bayes_path /srv/Mail/spamassassin/bayes There are surely multiple ways to do this. That's just what I figured out. and I'm a total SA newb, so take it with a grain of salt. A
signature.asc
Description: Digital signature
