You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Daryl C. W. O'Shea" <sp...@dostech.ca> on 2006/10/19 02:49:32 UTC
Re: sa-update of SARE channels returns multiple "Subroutine ... redefined
at ..." errors
OpenMacNews wrote:
> i've SA 317 installed on OSX 10.4.8.
>
> i currently use RDJ to update SARE rules w/o error.
>
> i use sa-update w/ channel=updates.spamassassin.org, also w/o error.
>
> i'm switching to SARE updates via sa-update & DOS's channels.
>
> on exec of sa-update + SARE channels, i get multiple errors (warnings?)
> of kind:
>
> "Subroutine ... redefined at ..."
>
> again, i see no such errors with RDJ updates.
>
> QUESTION:
>
> are these errors, in fact, a problem?
> if so, what/how needs fixing?
>
> thanks.
>
> verbose details follow here:
>
> after a clean install of SA 317, my DATADIR ((...)/SA/Dist/) contains:
What's this "DATADIR"? Are you referring to what would normally be
something like /var/lib/spamassassin/ ?
>
> 10_misc.cf 23_bayes.cf 30_text_fr.cf
> 20_advance_fee.cf 25_accessdb.cf 30_text_it.cf
> 20_anti_ratware.cf 25_antivirus.cf 30_text_nl.cf
> 20_body_tests.cf 25_body_tests_es.cf 30_text_pl.cf
> 20_compensate.cf 25_body_tests_pl.cf 30_text_pt_br.cf
> 20_dnsbl_tests.cf 25_dcc.cf 50_scores.cf
> 20_drugs.cf 25_dkim.cf 60_awl.cf
> 20_fake_helo_tests.cf 25_domainkeys.cf 60_whitelist.cf
> 20_head_tests.cf 25_hashcash.cf 60_whitelist_dk.cf
> 20_html_tests.cf 25_pyzor.cf 60_whitelist_dkim.cf
> 20_meta_tests.cf 25_razor2.cf 60_whitelist_spf.cf
> 20_net_tests.cf 25_replace.cf 60_whitelist_subject.cf
> 20_phrases.cf 25_spf.cf languages
> 20_porn.cf 25_textcat.cf sa-update-pubkey.txt
> 20_ratware.cf 25_uribl.cf triplets.txt
> 20_uri_tests.cf 30_text_de.cf user_prefs.template
>
> when i execute:
>
> sa-update \
> --channelfile (...)/SA/sa-update-channels.txt \
> --updatedir (...)/SA/Dist \
> --gpgkey 856AA88A
>
> i get @ console:
>
> Subroutine __HAS_RCVD_head_test redefined at
> /tmp/.spamassassin11389WRDnhPtmp/200510301100.cf, rule __HAS_RCVD, line 6.
Since, for some unknown reason, you're using an --updatedir that already
has a bunch of rules in it you've now got two copies of the rulesets in
the same directory that you are trying load. Not good.
Either don't try to override the --updatedir, or make sure that whatever
your "DATADIR" is (what should be something like /usr/share/spamassassin
maybe?) isn't the same as your --updatedir (which would normally be
/var/lib/spamassassin).
> after this update, my DATADIR ((...)/SA/Dist/) contains:
>
> 10_misc.cf
> 20_advance_fee.cf
> 20_anti_ratware.cf
> 20_body_tests.cf
> 20_compensate.cf
> 20_dnsbl_tests.cf
> 20_drugs.cf
> 20_fake_helo_tests.cf
> 20_head_tests.cf
> 20_html_tests.cf
> 20_meta_tests.cf
> 20_net_tests.cf
> 20_phrases.cf
> 20_porn.cf
> 20_ratware.cf
> 20_uri_tests.cf
> 23_bayes.cf
> 25_accessdb.cf
> 25_antivirus.cf
> 25_body_tests_es.cf
> 25_body_tests_pl.cf
> 25_dcc.cf
> 25_dkim.cf
> 25_domainkeys.cf
> 25_hashcash.cf
> 25_pyzor.cf
> 25_razor2.cf
> 25_replace.cf
> 25_spf.cf
> 25_textcat.cf
> 25_uribl.cf
> 30_text_de.cf
> 30_text_fr.cf
> 30_text_it.cf
> 30_text_nl.cf
> 30_text_pl.cf
> 30_text_pt_br.cf
> 50_scores.cf
> 60_awl.cf
> 60_whitelist.cf
> 60_whitelist_dk.cf
> 60_whitelist_dkim.cf
> 60_whitelist_spf.cf
> 60_whitelist_subject.cf
> 70_sare_adult_cf_sare_sa-update_dostech_net/
> 70_sare_adult_cf_sare_sa-update_dostech_net.cf
> 70_sare_bayes_poison_nxm_cf_sare_sa-update_dostech_net/
> 70_sare_bayes_poison_nxm_cf_sare_sa-update_dostech_net.cf
> 70_sare_evilnum0_cf_sare_sa-update_dostech_net/
> 70_sare_evilnum0_cf_sare_sa-update_dostech_net.cf
> 70_sare_evilnum1_cf_sare_sa-update_dostech_net/
> 70_sare_evilnum1_cf_sare_sa-update_dostech_net.cf
> 70_sare_genlsubj_cf_sare_sa-update_dostech_net/
> 70_sare_genlsubj_cf_sare_sa-update_dostech_net.cf
> 70_sare_genlsubj_eng_cf_sare_sa-update_dostech_net/
> 70_sare_genlsubj_eng_cf_sare_sa-update_dostech_net.cf
> 70_sare_header_cf_sare_sa-update_dostech_net/
> 70_sare_header_cf_sare_sa-update_dostech_net.cf
> 70_sare_header_eng_cf_sare_sa-update_dostech_net/
> 70_sare_header_eng_cf_sare_sa-update_dostech_net.cf
> 70_sare_html_cf_sare_sa-update_dostech_net/
> 70_sare_html_cf_sare_sa-update_dostech_net.cf
> 70_sare_obfu_cf_sare_sa-update_dostech_net/
> 70_sare_obfu_cf_sare_sa-update_dostech_net.cf
> 70_sare_oem_cf_sare_sa-update_dostech_net/
> 70_sare_oem_cf_sare_sa-update_dostech_net.cf
> 70_sare_random_cf_sare_sa-update_dostech_net/
> 70_sare_random_cf_sare_sa-update_dostech_net.cf
> 70_sare_specific_cf_sare_sa-update_dostech_net/
> 70_sare_specific_cf_sare_sa-update_dostech_net.cf
> 70_sare_spoof_cf_sare_sa-update_dostech_net/
> 70_sare_spoof_cf_sare_sa-update_dostech_net.cf
> 70_sare_stocks_cf_sare_sa-update_dostech_net/
> 70_sare_stocks_cf_sare_sa-update_dostech_net.cf
> 70_sare_unsub_cf_sare_sa-update_dostech_net/
> 70_sare_unsub_cf_sare_sa-update_dostech_net.cf
> 70_sare_uri_cf_sare_sa-update_dostech_net/
> 70_sare_uri_cf_sare_sa-update_dostech_net.cf
> 70_sc_top200_cf_sare_sa-update_dostech_net/
> 70_sc_top200_cf_sare_sa-update_dostech_net.cf
> 72_sare_bml_post25x_cf_sare_sa-update_dostech_net/
> 72_sare_bml_post25x_cf_sare_sa-update_dostech_net.cf
> 72_sare_redirect_post3_0_0_cf_sare_sa-update_dostech_net/
> 72_sare_redirect_post3_0_0_cf_sare_sa-update_dostech_net.cf
> 99_sare_fraud_post25x_cf_sare_sa-update_dostech_net/
> 99_sare_fraud_post25x_cf_sare_sa-update_dostech_net.cf
> languages
> sa-update-pubkey.txt
> triplets.txt
> updates_spamassassin_org/
> updates_spamassassin_org.cf
> updates_spamassassin_org.pre
> user_prefs.template
>
> which, i think, is what I should expect.
No, not at all. There should be no "plain" ruleset files in the
directory that contains all of the channel directories and .cf files.
Daryl
Re: How to do new sare update?
Posted by Jo Rhett <jr...@netconsonance.com>.
Steve Lake wrote:
> Ok, I'm going to take a huge guess that just dumping the new sare
> file into your rules directory (in my case, since I'm on freebsd, it's
> "/usr/local/share/spamassassin") doesn't work and you need to do some
> kind of update thingy.
>
> Someone got a guide on how to do this on freebsd? Many thanks.
On FreeBSD sa-update will put the files where SA expects them. That's
/var/lib/spamassassin/{version}/...
I think that the previous problem was someone overriding that and trying
to put the updates into his main rules directory.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: How to do new sare update?
Posted by Jo Rhett <jr...@netconsonance.com>.
DAve wrote:
> There is nothing special required for FreeBSD, the etc dir for user
> installed software is /usr/local/etc, so the local.cf is in
> /usr/local/etc/mail/spamassassin and that is the directory you should
> point RDJ to.
>
> Oh, and in case you are thinking about it, don't use the --update-dir
> switch on sa-update and try to be smarter than the SA developers. I did,
> and it will cause much grief. Just accept that sa-update and RDJ update
> two different directories and move along. You life will be easier. If
> you really want SARE rules updated the same as SA rules, then subscribe
> to a SARE channel.
I dunno about you, but I kindof prefer that sa-update has its own
directory (/var/lib/spamassassin) to play in. I run my servers with
/usr mounted read only :-)
Dave -- if you are a new site and you're not running RDJ today, might I
suggest that you simply use sa-update to get both sets of updates?
Here's a script you can run out of cron. Remove the backslash
continuers from the invocation line, and you probably want to eventually
replace "LOADED..." with a command line to restart your daemon (if
applicable)
#!/bin/sh
/usr/local/bin/sa-update \
--channelfile /var/lib/spamassassin/update-channels.txt \
--gpgkey 856AA88A
status=$?
if [ $status -eq 0 ]
then
echo "LOADED NEW FILES -- need to restart amavisd."
else
# Return code 1 means "no new updates", anything else is bad
if [ $status -ne 1 ]
then
echo "ERROR: SA-update appears to have failed."
fi
fi
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: How to do new sare update?
Posted by DAve <da...@pixelhammer.com>.
Matt Kettler wrote:
> Steve Lake wrote:
>> Ok, I'm going to take a huge guess that just dumping the new sare
>> file into your rules directory (in my case, since I'm on freebsd, it's
>> "/usr/local/share/spamassassin") doesn't work and you need to do some
>> kind of update thingy.
>>
> Well, you do NOT want to dump them into /usr/local/share/spamassassin.
> In fact, you do not ever want to edit anything in this directory, it
> will be obliterated when you upgrade SA.
>
> However, all you have to do is dump them into your
> /etc/mail/spamassassin directory, or whatever "etc" based instead of
> "share" based variant used with BSD.
>
> That said, if you want an auto-updater, look around for RulesDuJour.
>
>> Someone got a guide on how to do this on freebsd? Many thanks.
There is nothing special required for FreeBSD, the etc dir for user
installed software is /usr/local/etc, so the local.cf is in
/usr/local/etc/mail/spamassassin and that is the directory you should
point RDJ to.
Oh, and in case you are thinking about it, don't use the --update-dir
switch on sa-update and try to be smarter than the SA developers. I did,
and it will cause much grief. Just accept that sa-update and RDJ update
two different directories and move along. You life will be easier. If
you really want SARE rules updated the same as SA rules, then subscribe
to a SARE channel.
DAve
--
Three years now I've asked Google why they don't have a
logo change for Memorial Day. Why do they choose to do logos
for other non-international holidays, but nothing for
Veterans?
Maybe they forgot who made that choice possible.
Re: How to do new sare update?
Posted by Matt Kettler <mk...@verizon.net>.
Steve Lake wrote:
> Ok, I'm going to take a huge guess that just dumping the new sare
> file into your rules directory (in my case, since I'm on freebsd, it's
> "/usr/local/share/spamassassin") doesn't work and you need to do some
> kind of update thingy.
>
Well, you do NOT want to dump them into /usr/local/share/spamassassin.
In fact, you do not ever want to edit anything in this directory, it
will be obliterated when you upgrade SA.
However, all you have to do is dump them into your
/etc/mail/spamassassin directory, or whatever "etc" based instead of
"share" based variant used with BSD.
That said, if you want an auto-updater, look around for RulesDuJour.
> Someone got a guide on how to do this on freebsd? Many thanks.
>
>
How to do new sare update?
Posted by Steve Lake <st...@raiden.net>.
Ok, I'm going to take a huge guess that just dumping the new sare file
into your rules directory (in my case, since I'm on freebsd, it's
"/usr/local/share/spamassassin") doesn't work and you need to do some kind
of update thingy.
Someone got a guide on how to do this on freebsd? Many thanks.
Re: sa-update of SARE channels returns multiple "Subroutine ... redefined
at ..." errors
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
If you're seeing subroutine redefined warnings you're loading the same
rules more than once, period.
Run "spamassassin --lint -D" and make note of what directories it's
loading rules from. Then go and blow away those directories (be careful
not to delete things you don't have a copy of... like stuff in your
local site directory) and start over. I'd suggest not altering the
build defaults, but if you must, don't use the same directory for any
two things.
Daryl
Re: sa-update of SARE channels returns multiple "Subroutine ...
redefined at ..." errors
Posted by OpenMacNews <op...@gmail.com>.
following up with actual tests of each of the aforementioned cases:
(a) *not* define --updatedir
(b) define --updatedir=$DATADIR
(c) define --updatedir=$CONFDIR
(d) define --updatedir=$somewhereelse
for an sa-update run, given my build config of:
perl Makefile.PL \
PREFIX=/usr/local/spamassassin \
DATADIR=/var/SA/Dist \
CONFDIR=/var/SA/Local \
ENABLE_SSL="yes" \
LDDLFLAGS="-L/usr/local/ssl/lib -lssl -lcrypto" \
LDFLAGS="-bind_at_load -L/usr/local/ssl/lib -lssl -lcrypto
-ldl" \
INC="-I/usr/local/ssl/include"
and ensuring I clean/remove prior kruft installed in "updatedir/" and
"/tmp/" in each case,
results are:
CASE: (a) *not* define --updatedir
sa-update \
--channelfile /var/SA/sa-update-channels.txt \
--gpgkey 856AA88A
Subroutine __HAS_RCVD_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule __HAS_RCVD, line
6.
Subroutine __THEBAT_MUA_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule __THEBAT_MUA,
line 6.
Subroutine __AOL_FROM_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule __AOL_FROM, line
6.
Subroutine FROM_BLANK_NAME_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule FROM_BLANK_NAME,
line 6.
Subroutine __MIME_VERSION_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule __MIME_VERSION,
line 6.
Subroutine MSGID_SPAM_ALPHA_NUM_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule
MSGID_SPAM_ALPHA_NUM, line 6.
Subroutine MSGID_SPAM_CAPS_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule MSGID_SPAM_CAPS,
line 6.
Subroutine __FROM_EBAY_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200607251600.cf, rule __FROM_EBAY,
line 6.
Subroutine __TOCC_EXISTS_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200606040500.cf, rule __TOCC_EXISTS,
line 5.
Subroutine __CT_TEXT_PLAIN_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200606040500.cf, rule __CT_TEXT_PLAIN,
line 6.
Subroutine __CTYPE_HTML_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200606040500.cf, rule __CTYPE_HTML,
line 6.
Subroutine __NONEMPTY_BODY_body_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200606040500.cf, rule __NONEMPTY_BODY,
line 5.
Subroutine __SARE_SUB_OBFU_LQUOT_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_LQUOT, line 6.
Subroutine __SARE_SUB_OBFU_PERIOD_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_PERIOD, line 6.
Subroutine __SARE_SUB_OBFU_CARAT_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_CARAT, line 6.
Subroutine __SARE_SUB_OBFU_SCOLON_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_SCOLON, line 6.
Subroutine __SARE_SUB_OBFU_ASTER_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_ASTER, line 6.
Subroutine __SARE_SUB_OBFU_COLON_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_COLON, line 6.
Subroutine __SARE_SUB_OBFU_PIPE_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_PIPE, line 6.
Subroutine __SARE_SUB_OBFU_2PER_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_2PER, line 6.
Subroutine __SARE_SUB_OBFU_COMMA_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_COMMA, line 6.
Subroutine __SARE_SUB_OBFU_QUOTE_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_QUOTE, line 6.
Subroutine __SARE_SUB_OBFU_HTTP_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_HTTP, line 6.
Subroutine __SARE_SUB_OBFU_PLUS_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_PLUS, line 6.
Subroutine __SARE_SUB_OBFU_USCORE_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_USCORE, line 6.
Subroutine __SARE_SUB_OBFU_SLASH_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200512270000.cf, rule
__SARE_SUB_OBFU_SLASH, line 6.
Subroutine __RATWARE_0_TZ_DATE_head_test redefined at
/tmp/.spamassassin11590RpRcIytmp/200610182000.cf, rule
__RATWARE_0_TZ_DATE, line 6.
CASE: (b) define --updatedir=$DATADIR
sa-update \
--channelfile /var/SA/sa-update-channels.txt \
--updatedir /var/SA/Dist \
--gpgkey 856AA88A
RESULT: SAME AS ABOVE ...
CASE: (c) define --updatedir=$CONFDIR
sa-update \
--channelfile /var/SA/sa-update-channels.txt \
--updatedir /var/SA/Local \
--gpgkey 856AA88A
RESULT: SAME AS ABOVE ...
CASE: (d) define --updatedir=$somewherelse
sa-update \
--channelfile /var/SA/sa-update-channels.txt \
--updatedir /var/SA/UpdateDirTest \
--gpgkey 856AA88A
RESULT: SAME AS ABOVE ...
Re: sa-update of SARE channels returns multiple "Subroutine ...
redefined at ..." errors
Posted by OpenMacNews <op...@gmail.com>.
starting a clean build where my init dir contains only:
% ls -1R /var/SA
Local/
rules_du_jour.conf
sa-update-channels.txt
./Local:
ImageInfo.pm
init.pre
local.cf
local.cf.20061018
razor-agent.log
sa-update-keys/
./Local/sa-update-keys:
pubring.gpg
secring.gpg
trustdb.gpg
building a fresh co of SA 317 w/:
perl Makefile.PL \
PREFIX=/usr/local/spamassassin \
DATADIR=/var/SA/Dist \
CONFDIR=/var/SA/Local \
ENABLE_SSL="yes" \
LDDLFLAGS="-L/usr/local/ssl/lib -lssl -lcrypto" \
LDFLAGS="-bind_at_load -L/usr/local/ssl/lib -lssl -lcrypto -ldl" \
INC="-I/usr/local/ssl/include"
...
make install
mv /var/SA/Local/v310.pre /var/SA/Local/v310.preORIG
mv /var/SA/Local/v312.pre /var/SA/Local/v312.preORIG
then checking:
% ls -R /var/SA/
/var/SA/:
Dist/ Local/ rules_du_jour.conf sa-update-channels.txt
/var/SA/Dist:
10_misc.cf 23_bayes.cf 30_text_fr.cf
20_advance_fee.cf 25_accessdb.cf 30_text_it.cf
20_anti_ratware.cf 25_antivirus.cf 30_text_nl.cf
20_body_tests.cf 25_body_tests_es.cf 30_text_pl.cf
20_compensate.cf 25_body_tests_pl.cf 30_text_pt_br.cf
20_dnsbl_tests.cf 25_dcc.cf 50_scores.cf
20_drugs.cf 25_dkim.cf 60_awl.cf
20_fake_helo_tests.cf 25_domainkeys.cf 60_whitelist.cf
20_head_tests.cf 25_hashcash.cf 60_whitelist_dk.cf
20_html_tests.cf 25_pyzor.cf 60_whitelist_dkim.cf
20_meta_tests.cf 25_razor2.cf 60_whitelist_spf.cf
20_net_tests.cf 25_replace.cf 60_whitelist_subject.cf
20_phrases.cf 25_spf.cf languages
20_porn.cf 25_textcat.cf sa-update-pubkey.txt
20_ratware.cf 25_uribl.cf triplets.txt
20_uri_tests.cf 30_text_de.cf user_prefs.template
/var/SA/Local:
ImageInfo.pm local.cf razor-agent.log v310.preORIG
init.pre local.cf.20061018 sa-update-keys/ v312.preORIG
/var/SA/Local/sa-update-keys:
pubring.gpg secring.gpg trustdb.gpg
running an sa-update, per your instructions without --updatedir defined:
sa-update \
--channelfile /var/SA/sa-update-channels.txt \
--gpgkey 856AA88A
i get, yet once again, @ shell, the same as before:
Subroutine __HAS_RCVD_head_test redefined at
/tmp/.spamassassin15766jDBiWjtmp/200510301100.cf, rule __HAS_RCVD, line
6.
Subroutine __THEBAT_MUA_head_test redefined at
/tmp/.spamassassin15766jDBiWjtmp/200510301100.cf, rule __THEBAT_MUA,
line 6.
Subroutine __AOL_FROM_head_test redefined at
/tmp/.spamassassin15766jDBiWjtmp/200510301100.cf, rule __AOL_FROM, line
6.
Subroutine FROM_BLANK_NAME_head_test redefined at
/tmp/.spamassassin15766jDBiWjtmp/200510301100.cf, rule FROM_BLANK_NAME,
line 6.
etc
etc
...
as LOCALSATEDIR is, apparently, normally derived from $PREFIX:
'LOCALSTATEDIR', # normally determined based on $*PREFIX.
, which in my case is:
PREFIX=/usr/local/spamassassin
in the case above of --updatedir=(undef), i do note that, after
sa-update, i have now, as expected:
% ls /usr/local/spamassassin/var/spamassassin/3.001007
70_sare_adult_cf_sare_sa-update_dostech_net/
70_sare_random_cf_sare_sa-update_dostech_net.cf
70_sare_adult_cf_sare_sa-update_dostech_net.cf
70_sare_specific_cf_sare_sa-update_dostech_net/
70_sare_bayes_poison_nxm_cf_sare_sa-update_dostech_net/
70_sare_specific_cf_sare_sa-update_dostech_net.cf
70_sare_bayes_poison_nxm_cf_sare_sa-update_dostech_net.cf
70_sare_spoof_cf_sare_sa-update_dostech_net/
70_sare_evilnum0_cf_sare_sa-update_dostech_net/
70_sare_spoof_cf_sare_sa-update_dostech_net.cf
70_sare_evilnum0_cf_sare_sa-update_dostech_net.cf
70_sare_stocks_cf_sare_sa-update_dostech_net/
70_sare_evilnum1_cf_sare_sa-update_dostech_net/
70_sare_stocks_cf_sare_sa-update_dostech_net.cf
70_sare_evilnum1_cf_sare_sa-update_dostech_net.cf
70_sare_unsub_cf_sare_sa-update_dostech_net/
70_sare_genlsubj_cf_sare_sa-update_dostech_net/
70_sare_unsub_cf_sare_sa-update_dostech_net.cf
70_sare_genlsubj_cf_sare_sa-update_dostech_net.cf
70_sare_uri_cf_sare_sa-update_dostech_net/
70_sare_genlsubj_eng_cf_sare_sa-update_dostech_net/
70_sare_uri_cf_sare_sa-update_dostech_net.cf
70_sare_genlsubj_eng_cf_sare_sa-update_dostech_net.cf
70_sc_top200_cf_sare_sa-update_dostech_net/
70_sare_header_cf_sare_sa-update_dostech_net/
70_sc_top200_cf_sare_sa-update_dostech_net.cf
70_sare_header_cf_sare_sa-update_dostech_net.cf
72_sare_bml_post25x_cf_sare_sa-update_dostech_net/
70_sare_header_eng_cf_sare_sa-update_dostech_net/
72_sare_bml_post25x_cf_sare_sa-update_dostech_net.cf
70_sare_header_eng_cf_sare_sa-update_dostech_net.cf
72_sare_redirect_post3_0_0_cf_sare_sa-update_dostech_net/
70_sare_html_cf_sare_sa-update_dostech_net/
72_sare_redirect_post3_0_0_cf_sare_sa-update_dostech_net.cf
70_sare_html_cf_sare_sa-update_dostech_net.cf
99_sare_fraud_post25x_cf_sare_sa-update_dostech_net/
70_sare_obfu_cf_sare_sa-update_dostech_net/
99_sare_fraud_post25x_cf_sare_sa-update_dostech_net.cf
70_sare_obfu_cf_sare_sa-update_dostech_net.cf
updates_spamassassin_org/
70_sare_oem_cf_sare_sa-update_dostech_net/
updates_spamassassin_org.cf
70_sare_oem_cf_sare_sa-update_dostech_net.cf
updates_spamassassin_org.pre
70_sare_random_cf_sare_sa-update_dostech_net/
per your comment:
If you're seeing subroutine redefined warnings you're loading the same
rules more than once, period.
ok. "period".
from where?
again, per your suggestion:
Run "spamassassin --lint -D" and make note of what directories it's
loading rules from. Then go and blow away those directories (be
careful not to delete things you don't have a copy of... like stuff in
your local site directory) and start over. I'd suggest not altering
the build defaults, but if you must, don't use the same directory for
any two things.
i do so:
spamassassin --lint \
--debug \
--siteconfigpath=/var/SA/Dist \
--configpath=/var/SA/Local \
--nocreate-prefs >& lintout.txt
then:
% grep -i read lintout.txt
[15793] dbg: config: read file /var/SA/Local/init.pre
[15793] dbg: config: read file /var/SA/Local/local.cf
[15793] dbg: config: read file /var/SA/Dist/10_misc.cf
[15793] dbg: config: read file /var/SA/Dist/20_advance_fee.cf
[15793] dbg: config: read file /var/SA/Dist/20_anti_ratware.cf
[15793] dbg: config: read file /var/SA/Dist/20_body_tests.cf
[15793] dbg: config: read file /var/SA/Dist/20_compensate.cf
[15793] dbg: config: read file /var/SA/Dist/20_dnsbl_tests.cf
[15793] dbg: config: read file /var/SA/Dist/20_drugs.cf
[15793] dbg: config: read file /var/SA/Dist/20_fake_helo_tests.cf
[15793] dbg: config: read file /var/SA/Dist/20_head_tests.cf
[15793] dbg: config: read file /var/SA/Dist/20_html_tests.cf
[15793] dbg: config: read file /var/SA/Dist/20_meta_tests.cf
[15793] dbg: config: read file /var/SA/Dist/20_net_tests.cf
[15793] dbg: config: read file /var/SA/Dist/20_phrases.cf
[15793] dbg: config: read file /var/SA/Dist/20_porn.cf
[15793] dbg: config: read file /var/SA/Dist/20_ratware.cf
[15793] dbg: config: read file /var/SA/Dist/20_uri_tests.cf
[15793] dbg: config: read file /var/SA/Dist/23_bayes.cf
[15793] dbg: config: read file /var/SA/Dist/25_accessdb.cf
[15793] dbg: config: read file /var/SA/Dist/25_antivirus.cf
[15793] dbg: config: read file /var/SA/Dist/25_body_tests_es.cf
[15793] dbg: config: read file /var/SA/Dist/25_body_tests_pl.cf
[15793] dbg: config: read file /var/SA/Dist/25_dcc.cf
[15793] dbg: config: read file /var/SA/Dist/25_dkim.cf
[15793] dbg: config: read file /var/SA/Dist/25_domainkeys.cf
[15793] dbg: config: read file /var/SA/Dist/25_hashcash.cf
[15793] dbg: config: read file /var/SA/Dist/25_pyzor.cf
[15793] dbg: config: read file /var/SA/Dist/25_razor2.cf
[15793] dbg: config: read file /var/SA/Dist/25_replace.cf
[15793] dbg: config: read file /var/SA/Dist/25_spf.cf
[15793] dbg: config: read file /var/SA/Dist/25_textcat.cf
[15793] dbg: config: read file /var/SA/Dist/25_uribl.cf
[15793] dbg: config: read file /var/SA/Dist/30_text_de.cf
[15793] dbg: config: read file /var/SA/Dist/30_text_fr.cf
[15793] dbg: config: read file /var/SA/Dist/30_text_it.cf
[15793] dbg: config: read file /var/SA/Dist/30_text_nl.cf
[15793] dbg: config: read file /var/SA/Dist/30_text_pl.cf
[15793] dbg: config: read file /var/SA/Dist/30_text_pt_br.cf
[15793] dbg: config: read file /var/SA/Dist/50_scores.cf
[15793] dbg: config: read file /var/SA/Dist/60_awl.cf
[15793] dbg: config: read file /var/SA/Dist/60_whitelist.cf
[15793] dbg: config: read file /var/SA/Dist/60_whitelist_dk.cf
[15793] dbg: config: read file /var/SA/Dist/60_whitelist_dkim.cf
[15793] dbg: config: read file /var/SA/Dist/60_whitelist_spf.cf
[15793] dbg: config: read file /var/SA/Dist/60_whitelist_subject.cf
shows simply the files being read from the Distribution.
so, per your insistence that I'm loading the same rules more than once
-- which i'm open to learning -- can you please clarify what I should,
then, "blow away" here? where are the duplicate rules?
Re: sa-update of SARE channels returns multiple "Subroutine ... redefined
at ..." errors
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
OpenMacNews wrote:
>>> after a clean install of SA 317, my DATADIR ((...)/SA/Dist/)
>>> contains:
>>
>> What's this "DATADIR"? Are you referring to what would normally be
>> something like /var/lib/spamassassin/ ?
>
> DATADIR is what i've specified as my DATADIR @ build time.
Mmm... it's not too often that people report problems that have changed
the defaults.
>
> from (distro)/3.1/README:
>
> "File Locations:
>
> SpamAssassin will look in a number of areas to find the default
> configuration files that are used. The "__*__" text are variables
> whose value you can see by looking at the first several lines of the
> "spamassassin" or "spamd" scripts.
>
> They are set on install time and can be overridden with the Makefile.PL
> command line options DATADIR (for __def_rules_dir__) and CONFDIR (for
> __local_rules_dir__). If none of these options were given, FHS-compliant
> locations based on the PREFIX (which becomes __prefix__) are chosen.
> These are:
>
> __prefix__ __def_rules_dir__ __local_rules_dir__
>
> -------------------------------------------------------------------------
> /usr /usr/share/spamassassin /etc/mail/spamassassin
> /usr/local /usr/local/share/spamassassin /etc/mail/spamassassin
> /opt/$DIR /opt/$DIR/share/spamassassin /etc/opt/mail/spamassassin
> $DIR $DIR/share/spamassassin $DIR/etc/mail/spamassassin
> "
Well, the local state dir option doesn't seem to be documented (which is
probably a valid bug), but I believe you could set it with LOCALSTATEDIR.
>> unknown reason,
>
> The reason is that that's my understanding of the documentation.
I'm not entirely sure which documentation you are referring to. The
sa-update documentation doesn't seem to suggest that the default
--updatedir is the same as the default DATADIR.
The how-to for the SARE channels doesn't mention anything about using
--updatedir in the example sa-update command either.
> til now, with "just" sa-update of updates.spamassain.org, i've been using:
>
> sa-update \
> --channel updates.spamassassin.org \
> --updatedir /var/SA/Dist
>
> i.e., defining --updatedir=$DATADIR, and all's been working fine.
I'm not sure why it worked for you before. You're now seeing the
"official" rules being loaded twice too, not just the ones from the SARE
channels.
> It may well be incorrect.
>
> It may obvious to all others.
>
> Not to me.
>
> Hence, I'm asking a question.
>
>> you're using an --updatedir that
>> already has a bunch of rules in it you've now got two copies of the
>> rulesets in the same directory that you are trying load. Not good.
>
> ok.
>
>> Either don't try to override the --updatedir, or make sure that
>> whatever your "DATADIR" is (what should be something like
>> /usr/share/spamassassin maybe?) isn't the same as your --updatedir
>> (which would normally be /var/lib/spamassassin).
> ...
>> No, not at all. There should be no "plain" ruleset files in the
>> directory that contains all of the channel directories and .cf files.
>
> ok.
>
> given my build config of:
>
> perl Makefile.PL \
> PREFIX=/usr/local/spamassassin \
> DATADIR=/var/SA/Dist \
> CONFDIR=/var/SA/Local \
> ENABLE_SSL="yes" \
> LDDLFLAGS="-L/usr/local/ssl/lib -lssl -lcrypto" \
> LDFLAGS="-bind_at_load -L/usr/local/ssl/lib -lssl -lcrypto
> -ldl" \
> INC="-I/usr/local/ssl/include"
DATADIR isn't really variable... it should only contain the rules that
ship with the tarball, and never be updated. I'd stick with the
default, which follows FHS, of /usr/share/spamassassin or even use
/usr/local/share/spamassassin.
> and that i invoke sa-update with:
>
> sa-update \
> --channelfile /var/SA/sa-update-channels.txt \
> --updatedir /var/SA/Dist \
> --gpgkey 856AA88A
>
> can you please specifically clarify/suggest, should I:
>
> (a) *not* define --updatedir
That'll work. I'd do that.
> (b) define --updatedir=$DATADIR
That's what you're doing now, and won't work.
> (c) define --updatedir=$CONFDIR
That'd probably work, but isn't a good idea.
> (d) define --updatedir=$somewhereelse
That'll work too (as long as $somewhereelse != $DATADIR), but unless you
have a problem with the default of /var/lib/spamassassin, I don't see a
reason to change it.
> in other words, where _should_ the updates now go?
Well, according to FHS, they should go somewhere in /var. DATADIR
should be somewhere in /usr and CONFDIR somewhere in /etc, just like the
defaults.
Daryl
Re: sa-update of SARE channels returns multiple "Subroutine ...
redefined at ..." errors
Posted by OpenMacNews <op...@gmail.com>.
>> after a clean install of SA 317, my DATADIR ((...)/SA/Dist/)
>> contains:
>
> What's this "DATADIR"? Are you referring to what would normally be
> something like /var/lib/spamassassin/ ?
DATADIR is what i've specified as my DATADIR @ build time.
from (distro)/3.1/README:
"File Locations:
SpamAssassin will look in a number of areas to find the default
configuration files that are used. The "__*__" text are variables
whose value you can see by looking at the first several lines of the
"spamassassin" or "spamd" scripts.
They are set on install time and can be overridden with the Makefile.PL
command line options DATADIR (for __def_rules_dir__) and CONFDIR (for
__local_rules_dir__). If none of these options were given,
FHS-compliant
locations based on the PREFIX (which becomes __prefix__) are chosen.
These are:
__prefix__ __def_rules_dir__ __local_rules_dir__
-------------------------------------------------------------------------
/usr /usr/share/spamassassin /etc/mail/spamassassin
/usr/local /usr/local/share/spamassassin /etc/mail/spamassassin
/opt/$DIR /opt/$DIR/share/spamassassin
/etc/opt/mail/spamassassin
$DIR $DIR/share/spamassassin
$DIR/etc/mail/spamassassin
"
> unknown reason,
The reason is that that's my understanding of the documentation.
til now, with "just" sa-update of updates.spamassain.org, i've been
using:
sa-update \
--channel updates.spamassassin.org \
--updatedir /var/SA/Dist
i.e., defining --updatedir=$DATADIR, and all's been working fine.
It may well be incorrect.
It may obvious to all others.
Not to me.
Hence, I'm asking a question.
> you're using an --updatedir that
> already has a bunch of rules in it you've now got two copies of the
> rulesets in the same directory that you are trying load. Not good.
ok.
> Either don't try to override the --updatedir, or make sure that
> whatever your "DATADIR" is (what should be something like
> /usr/share/spamassassin maybe?) isn't the same as your --updatedir
> (which would normally be /var/lib/spamassassin).
...
> No, not at all. There should be no "plain" ruleset files in the
> directory that contains all of the channel directories and .cf files.
ok.
given my build config of:
perl Makefile.PL \
PREFIX=/usr/local/spamassassin \
DATADIR=/var/SA/Dist \
CONFDIR=/var/SA/Local \
ENABLE_SSL="yes" \
LDDLFLAGS="-L/usr/local/ssl/lib -lssl -lcrypto" \
LDFLAGS="-bind_at_load -L/usr/local/ssl/lib -lssl -lcrypto
-ldl" \
INC="-I/usr/local/ssl/include"
and that i invoke sa-update with:
sa-update \
--channelfile /var/SA/sa-update-channels.txt \
--updatedir /var/SA/Dist \
--gpgkey 856AA88A
can you please specifically clarify/suggest, should I:
(a) *not* define --updatedir
(b) define --updatedir=$DATADIR
(c) define --updatedir=$CONFDIR
(d) define --updatedir=$somewhereelse
in other words, where _should_ the updates now go?
/"\
\ / ASCII Ribbon Campaign
X against HTML email, vCards
/ \ & micro$oft attachments
[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6