Martin Gregorie a écrit : >> put any custom rules in the database, and modify the spamd? start >> scripts to write the custom rules to flat files. modify your update >> program to signal a spamd reload every time you modify the rules, or, >> use unison. we use unison (not for our VPS spam clusters) but for >> syncing flat files used on our redundant web servers (any downloaded >> pdf's can be up to 15 mins behind the 'master') which is why we don't >> do that on our anti-spam clusters. >> > However you slice it, you'll need to introduce a cron job to pull down > any SA configuration updates and restart spamd if any are found. > Alternatively, you might want to modify the SA daemon start script to > pull down updates to your configuration before starting spamd. > > Consequently this exercise boils down to finding the easiest way to > graft update retrievals onto the cron job. I think there are a number of > ways to do this that are simpler than using an SQL database. For > starters, none of the following require text->SQL->text conversions. Try > using one of these: > > - CVS, or whatever version control system is favored at your site. > CVS is simple to set up, works entirely with text files and can > sync multiple local copies to a central repository regardless of > where the copies are on the network. It only distributes changed > files and its trivial to discover if any changes were distributed. > > - rsync can be used to distribute a flat file repository. Like CVS, > it will automatically distribute just the changed files, so its fast > and its fairly easy to find out if it pulled down any changes. > > - wget can retrieve updates from a repository that's distributed by > an internal web server, Apache for instance. >
and as an extension (clarification?) of the latter: - sa-update. "convert" your rules to a channel and use sa-update.
