On Fri, 2010-04-16 at 10:08 -0700, Gary Smith wrote:
I have a need to run several different instances of SA on a single box (in
development). In production, we have 3 different SA environments (with 2+
servers each) that have different rule sets and specific routing rules
determine which
I'm sure it's possible, but rather than going through all the work of
trying to script and setup chroot environments, why not use VMs? You
can then quite literally match the production setup.
Since you are not worried about performance or memory you could give
each VM 128 MB of RAM and
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
-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
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
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
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:
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.
Do not even bother with your 2.55 local installation. It's a waste of
effort and time to try to make it work.
Besides, can't be done from within SpamAssassin. If you get REALLY
imaginative you might be able to do it with procmail. But that falls
back to the why bother? If the employer runs an
jdow writes:
Besides, can't be done from within SpamAssassin. If you get REALLY
imaginative you might be able to do it with procmail. But that falls
back to the why bother? If the employer runs an older version or an
ineffective version install a copy in a personal set of directories.
I
10 matches
Mail list logo
