> 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. Martin