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
ent.
We currently have 6+ server running these. 3 sets of load balanced SA servers.
These servers 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
-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
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
>
> 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
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 wh
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
deve
> 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 direct
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
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 th
13 matches
Mail list logo
