Re: [AMaViS-user] sa-update (sa v 3.1.4)
Mark Martinec
> > I use a default build of sa (i.e. I change absolutely no config
> > variables) and the default definitions dir is /usr/share/spamassassin
> > running sa-update puts new definitions in *its* default of
> > /var/lib/spamassasin/<version number>/updates_spamassassin_org/
>
> > Now, am I missing something here? Should I then manually transfer these
> > updates to $DEF_RULES_DIR or should I have set $DEF_RULES_DIR to be the
> > default path for sa-update and if so how when the path changes with each
> > update?
Theo writes:
> Nope. You should read http://wiki.apache.org/spamassassin/RuleUpdates :)
...and the wiki says:
| After sa-update completes, do I have to move the files somewhere
| for them to be used?
| No. By default, sa-update and the SpamAssassin modules use the same
| location for updates. This means that after a successful update run,
| the new rules are available for use. ...
Well, this is not entirely true. It is not the SpamAssassin modules
that sets a default value for LOCAL_STATE_DIR => '/var/lib' in the
SA object, but it is the application program that does it: the
spamassassin, sa-update and spamd.
Which means that other application programs like amavisd-new
or other callers of SA modules won't see the rules updates
in /var/lib/spamassasin unless explicitly configured to do so ...
... which is unfortunate, as it would probably not be difficult
to change Mail::SpamAssassin to provide a suitable default
for LOCAL_STATE_DIR. Please consider this a feature request.
Currently, one has two choices:
- tell sa-update to place updates in the usual rules directory
(which is probably the easiest way):
# sa-update --updatedir /usr/local/share/spamassassin
- or patch the application. For amavisd-new one may apply:
--- amavisd~ Mon Apr 3 16:32:34 2006
+++ amavisd Thu Aug 3 15:13:19 2006
@@ -14562,2 +14562,3 @@
stop_at_threshold => 0,
+ LOCAL_STATE_DIR => '/var/lib',
# DEF_RULES_DIR => '/usr/local/share/spamassassin',
Mark
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
AMaViS-user mailing list
AMaVi...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
Mark Martinec
> > to change Mail::SpamAssassin to provide a suitable default
> > for LOCAL_STATE_DIR. Please consider this a feature request.
>
> http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4952 :)
Appreciated!
> > # sa-update --updatedir /usr/local/share/spamassassin
>
> Warning: This will break your installation -- there are files in
> def_rules_dir that aren't in the updates, and sa-update will be
> happy to delete all of the files in the directory for you.
> local_state_dir and def_rules_dir are not interchangeable.
Ouch, thanks. Sorry for spreading false suggestions.
Gary V
> Theo,
>> > to change Mail::SpamAssassin to provide a suitable default
>> > for LOCAL_STATE_DIR. Please consider this a feature request.
>>
>> http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4952 :)
> Appreciated!
>> > # sa-update --updatedir /usr/local/share/spamassassin
>>
>> Warning: This will break your installation -- there are files in
>> def_rules_dir that aren't in the updates, and sa-update will be
>> happy to delete all of the files in the directory for you.
>> local_state_dir and def_rules_dir are not interchangeable.
> Ouch, thanks. Sorry for spreading false suggestions.
> Mark
Observation and questions:
I though the rules provided with sa-update were additions to existing
rules, but I guess I have not paid much attention. Is it true then
that the rules downloaded through sa-update are a complete rule set in
themselves? If so, Stuart Johnston's suggestion of adding
LOCAL_STATE_DIR => '/var/lib',
(I added this below:
# LOCAL_RULES_DIR => '/etc/mail/spamassassin',)
does direct SpamAssassin to use the sa-update rules there. It no longer
will use rules in the DEF_RULES_DIR. If sa-update (with no --updatedir
override) has never been run, the rules in the DEF_RULES_DIR are
loaded. If 'sa-update --updatedir /usr/share/spamassassin' (this is
where Debian puts the default rules) has been run, it appears the default
rules are loaded, then the newer rules in the updates_spamassassin_org
subdirectory located there are loaded also (on top of them?).
Gary V
Mark Martinec
> I though the rules provided with sa-update were additions to existing
> rules, but I guess I have not paid much attention. Is it true then
> that the rules downloaded through sa-update are a complete rule set in
> themselves? If so, ...
> does direct SpamAssassin to use the sa-update rules there. It no longer
> will use rules in the DEF_RULES_DIR. If sa-update (with no --updatedir
> override) has never been run, the rules in the DEF_RULES_DIR are
> loaded. If 'sa-update --updatedir /usr/share/spamassassin' (this is
> where Debian puts the default rules) has been run, it appears the default
> rules are loaded, then the newer rules in the updates_spamassassin_org
> subdirectory located there are loaded also (on top of them?).
I'm not sure, better join the topic on the SA list, or experiment.
Seems to be that adding LOCAL_STATE_DIR => '/var/lib' is a way to go.
Mark
Stuart Johnston
> Mark wrote:
>
>> Theo,
>
>>>> to change Mail::SpamAssassin to provide a suitable default
>>>> for LOCAL_STATE_DIR. Please consider this a feature request.
>>> http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4952 :)
>
>> Appreciated!
>
>>>> # sa-update --updatedir /usr/local/share/spamassassin
>>> Warning: This will break your installation -- there are files in
>>> def_rules_dir that aren't in the updates, and sa-update will be
>>> happy to delete all of the files in the directory for you.
>>> local_state_dir and def_rules_dir are not interchangeable.
>
>> Ouch, thanks. Sorry for spreading false suggestions.
>
>> Mark
>
> Observation and questions:
>
> rules, but I guess I have not paid much attention. Is it true then
> that the rules downloaded through sa-update are a complete rule set in
> themselves?
I'm a little confused about this as well. When I run spamassassin -D, it shows rules being loaded
from /var/lib/spamassassin/3.001003 and /etc/mail/spamassassin but NOT /usr/share/spamassassin/
Also, doing a diff I don't see any rules that are in /usr/share/spamassassin/ but not in
/var/lib/spamassassin/3.001003. There are a few extra files though, [languages,
sa-update-pubkey.txt, triplets.txt, user_prefs.template]. I suppose you probably don't want those
to get deleted.
Gary V
> Gary,
>> I though the rules provided with sa-update were additions to existing
>> rules, but I guess I have not paid much attention. Is it true then
>> that the rules downloaded through sa-update are a complete rule set in
>> themselves? If so, ...
>> does direct SpamAssassin to use the sa-update rules there. It no longer
>> will use rules in the DEF_RULES_DIR. If sa-update (with no --updatedir
>> override) has never been run, the rules in the DEF_RULES_DIR are
>> loaded. If 'sa-update --updatedir /usr/share/spamassassin' (this is
>> where Debian puts the default rules) has been run, it appears the default
>> rules are loaded, then the newer rules in the updates_spamassassin_org
>> subdirectory located there are loaded also (on top of them?).
> I'm not sure, better join the topic on the SA list, or experiment.
> Seems to be that adding LOCAL_STATE_DIR => '/var/lib' is a way to go.
> Mark
There is this:
NOTE: Once the /var/lib/spamassassin/<spamassassin version>
directory exists, spamassassin expects to find all rules
underneath that directory, so make sure that the first time
you run sa-update it completes successfully <...>
>From the SA thread:
>> OK Now I am really confused. Do I assume that SpamAssassin looks in
>> /var/lib/spamassassin/<version>/ for rules definitions and not
>> /usr/share/spamassassin?
and Theo says:
> Right -- if the update directory exists, SA will use that instead of the
> default rules directory.
I'm using 3.1.3 from Debian. After setting LOCAL_STATE_DIR in amavisd
the rules in /var/lib/spamassassin are used as noted before. I
downgraded to 3.0.3 and it used the standard rules in
/usr/share/spamassassin so at least on the surface it appears the code
change of LOCAL_STATE_DIR => '/var/lib' will not affect older versions
of SpamAssassin. I'm going to try it on my production box.
Gary V
ama...@mikecappella.com
There might be different behaviors depending upon whether --updatedir was
used with sa-update, and where you perl installation is. In my case, perl
is in /usr/local, SpamAssassin default rules are in /usr/local/spamassassin,
there is no /var/lib/spamassassin, and the command:
sa-update --updatedir /usr/local/share/spamassassin
creates a non-versioned directory
/usr/local/share/spamassassin/updates_spamassassin_org, which contains all
the updated files. These are incorporated by inclusion via
/usr/local/share/spamassassin/updates_spamassassin_org.cf. The rules in the
updatedir override existing default rules. Debug shows first default rule
files loading, and then updated rules. I've tested and have verified this
by creating a duplicate rule with a changed score in the default rules and
verifying that the scores match the algorithm indicated above.
MrC
Gary V
> There might be different behaviors depending upon whether --updatedir was
> used with sa-update, and where you perl installation is. In my case, perl
> is in /usr/local, SpamAssassin default rules are in /usr/local/spamassassin,
or is that /usr/local/share/spamassassin? I'm not sure SA would look
in /usr/local/spamassassin unless told to do so.
> there is no /var/lib/spamassassin, and the command:
> sa-update --updatedir /usr/local/share/spamassassin
> creates a non-versioned directory
> /usr/local/share/spamassassin/updates_spamassassin_org, which contains all
> the updated files. These are incorporated by inclusion via
> /usr/local/share/spamassassin/updates_spamassassin_org.cf. The rules in the
> updatedir override existing default rules. Debug shows first default rule
> files loading, and then updated rules. I've tested and have verified this
> by creating a duplicate rule with a changed score in the default rules and
> verifying that the scores match the algorithm indicated above.
> MrC
I appreciate that.
Gary V
MrC
> --updatedir
> > was used with sa-update, and where you perl installation is. In my
> > case, perl is in /usr/local, SpamAssassin default rules are in
> > /usr/local/spamassassin,
>
> or is that /usr/local/share/spamassassin? I'm not sure SA
> would look in /usr/local/spamassassin unless told to do so.
>
Arg, yes, my typo: /usr/local/share/spamassassin it is.
MrC
Gary V
>> > There might be different behaviors depending upon whether
>> --updatedir
>> > was used with sa-update, and where you perl installation is. In my
>> > case, perl is in /usr/local, SpamAssassin default rules are in
>> > /usr/local/spamassassin,
>>
>> or is that /usr/local/share/spamassassin? I'm not sure SA
>> would look in /usr/local/spamassassin unless told to do so.
>>
> Arg, yes, my typo: /usr/local/share/spamassassin it is.
> MrC
Still testing LOCAL_STATE_DIR => '/var/lib',
I upgraded from Debian 3.1.3 to the CPAN 3.1.4 and prior to running
sa-update, this version is using default rules in
/usr/local/share/spamassassin where the Debian version was using
/usr/share/spamassassin for default rules. After sa-update it's using
/var/lib/spamassassin/3.001004/updates_spamassassin_org as expected.
The point being (at least with current versions of SA) the code change
does not seem to be a problem with older versions of SA, nor when SA
is upgraded. BTW mixing SA installation methods like this is usually
a really bad idea unless you understand how your system will react and
you know to fix your system afterwards (if necessary). This particular
test system is no stranger to this kind of abuse. (8-}
I would guess the only people this may have an adverse effect on would
be those who place custom rule sets in the default rules dir and also
use 'sa-update'. They shouldn't be doing that at any rate, I believe
custom rules go in the site rules dir.
Gary V
MrC
Yes, agreed. When Mark posted about Mail::SpamAssassin not finding the
updates, and I knew my installation did, I wondered why, and discovered it
was a side affect of having my updated rules installed into a subdir of the
default rules location. Since I manually update my server software (i.e. no
rpm, apt, etc.), I'm not really too concerned about where the updated rules
end up, as long as they are working correctly.
It looks like the patch going into SA 3.1.5 explains the details a little
better, and looks in an additional location for local_state_dir.
http://issues.apache.org/SpamAssassin/attachment.cgi?id=3624
MrC
Gary V
> On Thu, Aug 03, 2006 at 01:44:54PM -0600, Gary V wrote:
>>
>> I would guess the only people this may have an adverse effect on would
>> be those who place custom rule sets in the default rules dir and also
>> use 'sa-update'. They shouldn't be doing that at any rate, I believe
>> custom rules go in the site rules dir.
> My extra sare rules get loaded just fine from the default rules dir,
> when using sa-update.
> Only thing you have to remember is copy them back when upgrading
> SpamAssassin module..
> Cheers,
> Henrik
But have you set LOCAL_STATE_DIR => '/var/lib', which will read the
sa-update rules from /var/lib/spamassassin/<version> or did you run
'sa-update --updatedir <default_rules_dir>' so the sa-update rules are
placed in a subdirectory in /usr/local/share/spamassassin (or whatever
your default rules dir is) along with your custom rules in that same
directory? What I'm saying is that if LOCAL_STATE_DIR => '/var/lib',
is used, none of the rule sets in the default rules dir will be read.
Gary V