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 instance it gets sent to. We need to mimic this in
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
Background:
I've been using SA for a long time, and for a verity of reasons, we run
different servers to support some minor changes in different rules. While
trying to setup a multi instance version on my laptop, I copied these rules
over into different directories, setup the startup/shutdown
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
are roughly 70% idle most of the time. Running them with user
preferences, instead of different instances, would allow us to remove 50% of
the hardware. Running them as multiple instances on the same box, means we
will still need to balance across the same number of servers.
I think
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.
My (large) employer runs SpamAssassin on all incoming mail. My local UNIX
account, managed by a separate technical support group, is on a machine which
also has spamassassin available. Running the local version removes the
headers added by the central version. While I can see good reasons for
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
13 matches
Mail list logo
