On Tuesday 21 July 2009, Bowie Bailey wrote: >Gene Heskett wrote: >> On Tuesday 21 July 2009, Bowie Bailey wrote: >>> If permissions are 0700 and sa-update cannot read the directory, then >>> sa-update is not running as the user "saupdate". Double-check which >>> user sa-update runs as and chown the directory to that user. >> >> Here is the line, in the display of: >> su saupdate -c "crontab -e": >> 45 2 * * 2 /usr/bin/sa-update --gpghomedir /var/lib/spamassassin/keys >> >> So it should be running as saupdate. >> This is executed silently: >> >> [r...@coyote linux-2.6.30-rc8]# su saupdate -c "/usr/bin/sa-update >> --gpghomedir /var/lib/spamassassin/keys" [r...@coyote linux-2.6.30-rc8]# >> >> And I have not received an email from it, so I assume that 0700 fixed it. >> >> However, I haven't been impressed with the sa-learn operation recently, I >> have fed it at least 100 messages from one site, and still can't get a >> score over 3 for those. > >First off, sa-learn and sa-update have absolutely nothing to do with >each other. sa-update downloads new rules and sa-learn trains the Bayes >subsystem. Just wanted to clarify this since your last message seemed >to imply that you thought they were connected somehow. > I knew that, and was just making a comment that it wasn't 'taking'. Sorry I wasn't clearer.
>Are you getting BAYES_XX hits for the messages? Bayes needs to learn >from at least 200 ham and 200 spam before it will start scoring. Also, >make sure that you are running sa-learn as the same user SA is running >as. A classic mistake is to run SA as one user and then run sa-learn as >a different user. Aha! sa-learn is running from the root crontab, and is training the bayes for the user gene, and kmail then suck /var/spool/mail/gene for the input I'm reading. The script is a bit complex and designed to do its own msg haandling. ----------------------- #!/bin/bash PATH=/sbin:/root/bin:/usr/bin:/bin # make sure the database is free killall fetchmail # wait for the spamd pipes to drain sleep 60 # do this dastardly deed cp /root/Mail/ham/cur/* /home/gene/Mail/ham/cur/ cp /root/Mail/spam/cur/* /home/gene/Mail/spam/cur/ chown gene:gene /home/gene/Mail/ham/cur/* chown gene:gene /home/gene/Mail/spam/cur/* runuser -l gene -c "sa-learn --ham /home/gene/Mail/ham/cur/*" runuser -l gene -c "sa-learn --spam /home/gene/Mail/spam/cur/*" # now, this stuff is trash rm -f /home/gene/Mail/ham/cur/* rm -f /home/gene/Mail/spam/cur/* rm -f /root/Mail/spam/cur/* # Note, I leave the ham for moving where it really goes # and restore fetchmail # and for some reason, on wednesday morning 12/17/08, fetchmail.log # was owned by root:root! WTF??? # That is a long time for logrotate to take effect, which is the only # other thing that could do this # So: (and put it in rc.local too just for good measure) chown gene:gene /var/log/fetchmail.log # to let the disks synch sleep 6 runuser -l gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc" ------------------------ as can be seen, the mail delivery system all runs as the user gene. So, in light of this, I should be running saupdate as gene, not as a separate user. Thanks for the forehead slap Bowie, I needed that. :) >What happens is that you are not training the >database that is actually being used. Keep in mind that if SA is >running per-user, then you must run sa-learn for each user. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. <https://www.nrahq.org/nrabonus/accept-membership.asp> People humiliating a salami!
