Gary Smith wrote:
I'm not worried about it exploding as we don't allow user_prefs. The machines are processed via relays. I believe the bayes_sql_override_username will solve the last piece of the puzzle. I think I will test this out this weekend on the laptop, then our test environment.
'E
> If you're just trying to keep your Bayes table from exploding due to
> multiple users, use the bayes_sql_override_username option.
I'm not worried about it exploding as we don't allow user_prefs. The machines
are processed via relays. I believe the bayes_sql_override_username will solve
the
Gary Smith wrote:
Bayes is the only real concern here, as I know I can run multiple copies (and had forgot that I could run a single copy with user_prefs). So I think this will work either way. I just needed to put a little thought into it and
bounce off of people who might have already done so
> Why don't you just run 3 instances of spamd, each listening on different
> ports/sockets and each with their own configuration:
>
> spamd --siteconfigpath=/etc/spam1 --socketpath=/tmp/spam1.sock --port=783
> spamd --siteconfigpath=/etc/spam2 --socketpath=/tmp/spam2.sock --port=784
> spamd --site
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kris Deugau wrote:
> Gary Smith wrote:
>> Instead of running multiple SA servers, it is possible to run a single
consolidated SA server where only the userpref's are different for each
spamc caller (given that the local config will override the global
Gary Smith wrote:
Instead of running multiple SA servers, it is possible to run a single
consolidated SA server where only the userpref's are different for each spamc
caller (given that the local config will override the global config) AND still
use a single bayes DB? We use a clustered MySql
