On Mon, 2013-10-21 at 13:59 -0700, Quanah Gibson-Mount wrote:
> --On Sunday, October 20, 2013 3:39 AM +0200 Karsten Bräckelmann wrote:
>
> > There is. Install SA, run sa-update. See the INSTALL file.
> >
> > On this topic it is worth pointing out, that the Mail-SpamAssassin
> > tarball contains everything necessary but the actual rules files. That
> > includes the most basic .pre files.
>
> Yes, but I was thinking if you didn't even have the .pre files, there's no
> way to bootstrap.
That... would be correct as stated.
There's a fundamental problem with that, though. sa-update requires
Mail::SpamAssassin. Which, at that stage, you did not install. If you
would have installed the core SA parts, you would also have the .pre
files.
You are getting that error message only, because some magic in the
sa-update BEGIN block picks up a relative located M::SA in your build
tree.
Again: First install SA. Then run sa-update.
> However, this has opened up a question to me as to whether or not my
> current configuration (which was designed by someone else long ago) is
> optimal.
>
> Currently, we store everything (.pre files and rules) in
> /opt/zimbra/conf/spamassassin:
>
> zimbra@zre-ldap001:~/conf/spamassassin$ ls
> 10_default_prefs.cf 20_freemail.cf 20_ratware.cf 25_pyzor.cf
[...]
> v340.pre
>
>
> And we have SA built with:
>
> my $DEF_RULES_DIR = '/opt/zimbra/conf/spamassassin';
> my $LOCAL_RULES_DIR = '/opt/zimbra/conf/spamassassin';
Ouch. Do NOT keep stock rules in the site-specific configuration dir.
Let me show what that configuration does. I'll stick to common defaults
for the dirs, trying to refer to synonyms and variables. Parts are
copied straight from the man page.
Default configuration data is loaded from the first existing directory
in:
/var/lib/spamassassin/3.00x00y # $LOCAL_STATE_DIR plus SA version
/usr/share/spamassassin # $DEF_RULES_DIR
The first one is populated by sa-update, the second is pre sa-update and
a suitable place for a stock rules package.
Site-specific configuration data is used to override any values which
had already been set. This is loaded from the first existing directory
in:
/etc/mail/spamassassin # $LOCAL_RULES_DIR
That is where the core .pre files are located, and any site-specific
configuration -- including custom rules, overriding stock scores, etc.
By setting $DEF_RULES_DIR to the same value as $LOCAL_RULES_DIR, placing
stock rules in what's supposed to be strictly for site-specific conf,
you override the fresh rules pulled by sa-update.
> I'm wondering if there's a better layout strategy than this. I.e., keep
> the .pre files in a specific location (/opt/zimbra/conf/spamassassin) and
> keep the rule files + updates in /opt/zimbra/data/spamassassin (our
> generalized data location for app specific data).
>
> Any opinions on that?
Yes, definitely.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
