A good sa setup includes sa-update nowadays. The Fedora package could make it easier on users : 1. create the directory sa-updates saves keys in 2. prepopulate it with the official upstream key 3. drop an update cron in /etc/cron*, possibly commented and possibly including SARE channel. I use this one : 0 */4 * * * root /usr/bin/sa-update --channel updates.spamassassin.org --chann el saupdates.openprotect.com --gpgkey 265FA05B --gpgkey BDE9DC10 && /etc/init.d/ spamassassin restart
Created attachment 143268 [details] add sa-update cron (spec file)
Created attachment 143269 [details] logrotate setup file
Created attachment 143270 [details] cron entry file
Created attachment 143271 [details] cron script This script accesses to the network, so actual start time of sa-update is randomized. Is the daemon restart is requied?
1. please use correct mime types for your attachments (ie text/plain) that makes viewing them oh-so-much-easier 2. the daemon restart bit comes from the official sa wiki. That's why you should use the sa-update return value so it only occurs when the actual rule set was updated. (the system is designed so "is there an update" checks are wickedly light and can happen more often than actual updates) 3. IMHO if you really want to log sa-updates the traces belong in maillog 4. it seems you totally ignored the gpg handling in your files -- we want to do it and IIRC it will bite you at the first update attempt. That means creating the key directory with the right permissions in the spec and putting the official sa key in there 5. (style related, you can ignore it) can you use $() instead of `' squiggles in your script ?
(In reply to comment #5) Thank you for reviewing my idea. > 1. Sorry for my foolish that I trusted the "auto-detect" in Content Type section. > 2-5 is reflected to the following attachments.
Created attachment 143276 [details] cron entry file output of sa-update is both /var/log/sa-update.log and stdout (is mailed.)
Created attachment 143278 [details] cron script * `` is replaces to $(). * add GPG key check * add spamassassin daemon restart
(In reply to comment #6) > (In reply to comment #5) > > Thank you for reviewing my idea. > > > 1. > > Sorry for my foolish that I trusted the "auto-detect" in Content Type section. bugzilla sucks, I know :( > > 2-5 > is reflected to the following attachments. 1. You still have a `date' 2. part of the gpg stuff requires spec changes 3. I don't like the dedicated log file 4. I'm not too sure about adding saupdates.openprotect.com by default That being said, most of it could be described as policy decisions IE Warren should tell us what he likes best
A few comments: 1) Shouldn't that be "service spamassassin condrestart", not "service spamassassin restart"? 2) Adding SARE by default is a great idea IMHO, but it might be best to come up with some generic way of adding additional update channels. (One of my clients is considering setting up a private update channel for their local SA rules, for example.) 3) What about restarting amavisd? Or any other SA-using process, for that matter. It might be worth making that a configurable thing as well.
(In reply to comment #10) > A few comments: > > 1) Shouldn't that be "service spamassassin condrestart", not "service > spamassassin restart"? +1 Sure, if the sa service supports it > 2) Adding SARE by default is a great idea IMHO, but it might be best to come up > with some generic way of adding additional update channels. (One of my clients > is considering setting up a private update channel for their local SA rules, for example.) The way sa-update is setup it really wants a single command with all the channels stuffed in it, unless you want cascading service restarts after a long unsynchronization. But then, I'm sure a perl guru can come up with a smart solution > 3) What about restarting amavisd? Or any other SA-using process, for that > matter. It might be worth making that a configurable thing as well. I think all the modern sa users communicate with sa through smamc/spamd, so they should pick up changes as soon as spamd is restarted
I am extremely limited on time, and this must go in Thursday morning. Please quickly get these tasks done so I can quickly review and include this. 1) How does this differ from the current behavior of running sa-update with the package as is? 2) Could you please attach a spec.patch unidiff of how you suggest this be added to the package? 3) Then be sure that all files you suggest to be included are also attached. 4) Set the other attachments to Obsolete so they don't confuse me.
Created attachment 143598 [details] cron entry file updated cron entry file.
Created attachment 143599 [details] cron entry file updated cron entry file
Created attachment 143600 [details] cron entry file updated cron entry file
Created attachment 143601 [details] cron script updated cronscript use only updates.spamassassin.org. If anyone want to use other sites, please add the channel into this file.
(In reply to comment #12) > 1) How does this differ from the current behavior of running sa-update with the > package as is? New function: sa-update works once a day as a cron job. > 2) Could you please attach a spec.patch unidiff of how you suggest this be added > to the package? attachment 143268 [details] is unidiff-ed spec.patch. > 3) Then be sure that all files you suggest to be included are also attached. attachment 143269 [details] (spamassassin.logrotate) attachment 143600 [details] (sa-update.cron_entry) attachment 143601 [details] (sa-update.cron) > 4) Set the other attachments to Obsolete so they don't confuse me. confirmed. As I noticed at the comment #16, only updates.spamassassin.org is set as the channel. I think this channel is enough as the default. If other SpamAssassin rule is needed, users can edit sa-update.cron script.
Re comment #11: Not all SA clients use spamc/spamd. Some are Perl-based and use the underlying Mail::SpamAssassin classes directly. MIMEDefang is the one I use. It spawns its own Perl-based slaves that invoke SA. I'd recommend that the restart script not chain services that need to be restarted on one command line with &&. Is there some package-oriented producer/consumer scheme such that multiple services can register interest in an event like this? Perhaps the thing to do is to provide a directory somewhere where other packages can drop scripts that will be invoked when sa-update reports that new content has arrived. If spamd is enabled, a script to restart it can be dropped in this directory. This machinery should all be pushed upstream. See also http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5003 where the idea of breaking sa-update out into its own subpackage is being discussed.
Comment #18 makes good points. For these reasons I believe we should hold off on adding this to the RPM package.
(In reply to comment #19) > Comment #18 makes good points. For these reasons I believe we should hold off > on adding this to the RPM package. Given that sa is increasingly useless unless the rules are updated regularly, that would be grounds to ship the cron commented by default (or noreplace so people can comment it at need) (And I run rawhide, so I get the package updates faster than most users)
Red Hat is not fully comfortable with sa-update just yet, because it relies on an external data source. For this reason we don't want to officially endorse its use. How hard is it to make your own one-liner cron entry to run sa-update?
(In reply to comment #21) > Red Hat is not fully comfortable with sa-update just yet, because it relies on > an external data source. For this reason we don't want to officially endorse > its use. It's the same source that released the rules the initial package bundles, and last I've seen people trusted the Apache foundation > How hard is it to make your own one-liner cron entry to run sa-update? It wasn't hard for me, just annoying (create the key directory the package forget, locate the right gpg key, make it available for sa, find the right update command…) For your run-of-the-mill user though, it's way over the hassle ceiling, he'll just notice sa performance degrades quickly and fedora does not "just work" as it should. Given how spam is evolving if Red Hat is not comfortable with direct upstream rule feeds it will have to set up its own update server sooner or later (same applies for pyzor BTW)
(In reply to comment #22) > > How hard is it to make your own one-liner cron entry to run sa-update? > > It wasn't hard for me, just annoying (create the key directory the package > forget, locate the right gpg key, make it available for sa, find the right > update command…) Not to be picky, but running "sa-update" does all of this for you. The key is included in the standard distro, and sa-update will automatically do all the right things if its gpghome dir doesn't already exist. Generally, if people are starting out using sa-update, I suggest that they run "sa-update -D" to see what's going on for the first couple of times. Once used to the process, it's easy to just put in the cronjob.
felicity, it might be helpful to add -D to the sa-update --help output? =)
(In reply to comment #24) > felicity, it might be helpful to add -D to the sa-update --help output? =) Such as where it has: $ sa-update --help [...] -D, --debug [area=n,...] Print debugging messages ? :)
Re comment #21: WRT policy, how is this different from freshclam in the clamav package in Extras? That program does much the same thing, checking a DNS record to see if updates are available and downloading new virus data files when available. I do think that other SA update sources (eg. SARE) should be separate packages, to allow separation of policy based on update source. If the sources have to be listed on the sa-update command line, then the script should assemble the command line from package files in an appropriate directory, one per source. The potential SARE package can then drop its update source argument as a file in that directory.
spamassassin is Core and RHEL with possible liability concerns. clamav is Extras, maintained entirely by community.
(In reply to comment #23) > Not to be picky, but running "sa-update" does all of this for you. You just proved I'm as confused as everyone else by sa-update :). Which rather makes my point. Anyway apart from the fact it didn't just work here (bad user, no naked sa-update run at first, whatever) is it good policy not to create /etc content in the package and let upstream commands do it themselves post-install ? (In reply to comment #27) > spamassassin is Core… but Core and Extras are supposed to be merged, right?
Isn't it completely possible to put all of this sa-update functionality in a separate package that could go into extras, so no core changes are required?
I will include the commented out cron and cron script. It will use "service spamassassin condrestart" or some equivalent...
http://people.redhat.com/wtogami/temp/spamassassin-3.1.7-0.test.el4.src.rpm I did it slightly differently. Please review these changes. I have no idea why you wanted to move the updates to /var/spool/spamassassin when upstream has defaulted for /var/lib/spamassassin for a long time now.
(In reply to comment #31) > I have no idea why you wanted to move the updates to /var/spool/spamassassin > when upstream has defaulted for /var/lib/spamassassin for a long time now. See Bug 187974.