Re: [suggest] Problems with spamassassin 3.2.5-1.el5.rf
Michael, On my system when I run spamassassin -D --lint, it shows that the rules directory is set to /usr/share/spamassassin, and suspect that in your system will show this result too, so in fact you might have now an newly installed duplicate set of rules :). I haven't looked into this in detail, but suspect this means that spamassassin rules directory was compiled with /usr/share/spamassassin, but sa-update was compiled with /var/lib/spamassassin therefore the problem. Here is the pertaining output from my system: ... [7037] dbg: config: using /usr/share/spamassassin for sys rules pre files [7037] dbg: config: using /usr/share/spamassassin for default rules dir [7037] dbg: config: read file /usr/share/spamassassin/10_default_prefs.cf [7037] dbg: config: read file /usr/share/spamassassin/20_advance_fee.cf [7037] dbg: config: read file /usr/share/spamassassin/20_body_tests.cf [7037] dbg: config: read file /usr/share/spamassassin/20_compensate.cf [7037] dbg: config: read file /usr/share/spamassassin/20_dnsbl_tests.cf [7037] dbg: config: read file /usr/share/spamassassin/20_drugs.cf [7037] dbg: config: read file /usr/share/spamassassin/20_dynrdns.cf [7037] dbg: config: read file /usr/share/spamassassin/20_fake_helo_tests.cf [7037] dbg: config: read file /usr/share/spamassassin/20_head_tests.cf [7037] dbg: config: read file /usr/share/spamassassin/20_html_tests.cf [7037] dbg: config: read file /usr/share/spamassassin/20_imageinfo.cf ... Please note that I am temporarily using sa-update with option --updatedir /usr/share/spamassassin to compensate for this problem, which by the way it's not recommended according to http://wiki.apache.org/spamassassin/RuleUpdates Regards, Ignacio Hi Ignacio, Hi Michael, I stand by what I said, if you do not have the time to run sa- update, there is no sense in stating that it is not true. Would someone (other than me):-) that has an installed spamassassin 3.2.5- 1.el5.rf please run sa-update, and corroborate wether or not a set of rules gets placed in folder /var/lib/spamassassin/version I run sa-update every night and use the spamassassin package from rpmforge on both el4 and el5 servers. The sa-update script is meant to update the rules and put them into /var/lib/spamassassin. The /usr/share/spamassassin directory is there to provide rules to admins they can use to copy/move into /var/lib/spamassassin. The fact the rules get packaged in /usr/share/spamassassin is irrelevant as SA doesn't use them from that location. In reply to your second statement, I am fully aware that SARE has been deprecated, but it is not a wildly known fact!. Plenty of proofs of this can be easily found by googling around using keywords spamassassin how to OR guide, and verify how widely rules-dujour installation is recommended, even in very recent installation guides. I'm on the SARE mailing list and occassionally (every 3 - 6 months) there's an email on that list and it's someone that asks about the rulesdujour script. The person is then told not use it any more but instead use sa-update. I would suspect that if rulesdujour was still widely used the SARE mailing list would be much more active than that. Besides none of these problems that are causing so much confussion would be around if rf's apmassassins rpm was not bundled with these rules. Much less locating them in an non-standard folder such as /usr/share/spamassassin, instead of using one of the default directories. Again, I stand by my reasonings. Many RPM packages supply tools, scripts, etc in the /usr/share/packagename for the administrator to use and copy/move if they need to. This is not isolated to the SA RPM from rpmforge. Please see: http://wiki.apache.org/spamassassin/WhereDoLocalSettingsGo http://wiki.apache.org/spamassassin/RuleUpdates At least you have to agree, that wether users are aware or not of the of the deprecated SARE rules, it is not evident to them that a bundled set of rules was installed with the the package. This is not customary prcatice, unless you somehow added information to the package name that will let the user know this. You have to expect that users will start adding their own sets of rules to /etc/mail/spamassassin totally oblivious to the fact there might be a set of duplicate rules on other directory in their system. sa-update will put the rules in /var/lib/spamassassin. Rules that go into /etc/mail/spamassassin are custom rules for users, and that is where they belong. SpamAssassin will read from both the /etc/mail/spamassassin and the /var/lib/spamassassin directories for the rules but will ignore the /usr/share/spamassassin. I personally do not see anything wrong with this. Regards, Michael. Regards, Ignacio Hi Ali, Hope I am not wrong, but... Just passing by to metion problems ralated to rpmforge's spamasassin for Centos/el5 (personally I am using x86_64.3.2.5-1.el5.rf). The problem in question is
[suggest] Re: suggest Digest, Vol 38, Issue 12
[EMAIL PROTECTED] wrote: -- Message: 2 Date: Wed, 20 Aug 2008 23:56:19 -0400 (EDT) From: Ignacio Bustamante [EMAIL PROTECTED] Subject: Re: [suggest] Problems with spamassassin 3.2.5-1.el5.rf To: Michael Mansour [EMAIL PROTECTED], suggest@lists.rpmforge.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain;charset=iso-8859-1 Hi Michael, I stand by what I said, if you do not have the time to run sa-update, there is no sense in stating that it is not true. Would someone (other than me):-) that has an installed spamassassin 3.2.5-1.el5.rf please run sa-update, and corroborate wether or not a set of rules gets placed in folder /var/lib/spamassassin/version In reply to your second statement, I am fully aware that SARE has been deprecated, but it is not a wildly known fact!. Plenty of proofs of this can be easily found by googling around using keywords spamassassin how to OR guide, and verify how widely rules-dujour installation is recommended, even in very recent installation guides. Besides none of these problems that are causing so much confussion would be around if rf's apmassassins rpm was not bundled with these rules. Much less locating them in an non-standard folder such as /usr/share/spamassassin, instead of using one of the default directories. Again, I stand by my reasonings. Please see: http://wiki.apache.org/spamassassin/WhereDoLocalSettingsGo http://wiki.apache.org/spamassassin/RuleUpdates At least you have to agree, that wether users are aware or not of the of the deprecated SARE rules, it is not evident to them that a bundled set of rules was installed with the the package. This is not customary prcatice, unless you somehow added information to the package name that will let the user know this. You have to expect that users will start adding their own sets of rules to /etc/mail/spamassassin totally oblivious to the fact there might be a set of duplicate rules on other directory in their system. Regards, Ignacio Guys? Please list the specific versions of the SpamAssassin RPM's that you're using, to help out anyone who wants to test this themselves. If SARE rules are this deprecated, but only known about on the mailing lists, then the Wiki's should be updated about this and the rulesdujour tool eliminated from the RPM or at least disabled. Right? ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Re: suggest Digest, Vol 38, Issue 12
Hi, Hi Michael, I stand by what I said, if you do not have the time to run sa-update, there is no sense in stating that it is not true. Would someone (other than me):-) that has an installed spamassassin 3.2.5-1.el5.rf please run sa-update, and corroborate wether or not a set of rules gets placed in folder /var/lib/spamassassin/version In reply to your second statement, I am fully aware that SARE has been deprecated, but it is not a wildly known fact!. Plenty of proofs of this can be easily found by googling around using keywords spamassassin how to OR guide, and verify how widely rules-dujour installation is recommended, even in very recent installation guides. Besides none of these problems that are causing so much confussion would be around if rf's apmassassins rpm was not bundled with these rules. Much less locating them in an non-standard folder such as /usr/share/spamassassin, instead of using one of the default directories. Again, I stand by my reasonings. Please see: http://wiki.apache.org/spamassassin/WhereDoLocalSettingsGo http://wiki.apache.org/spamassassin/RuleUpdates At least you have to agree, that wether users are aware or not of the of the deprecated SARE rules, it is not evident to them that a bundled set of rules was installed with the the package. This is not customary prcatice, unless you somehow added information to the package name that will let the user know this. You have to expect that users will start adding their own sets of rules to /etc/mail/spamassassin totally oblivious to the fact there might be a set of duplicate rules on other directory in their system. Regards, Ignacio Guys? Please list the specific versions of the SpamAssassin RPM's that you're using, to help out anyone who wants to test this themselves. I always use the latest spamassassin from rpmforge: spamassassin-3.2.5-1.el4.rf If SARE rules are this deprecated, but only known about on the mailing lists, then the Wiki's should be updated about this and the rulesdujour tool eliminated from the RPM or at least disabled. Right? Not really no. Not everyone is using the latest SA and/or sa-update to update their rules. For those people that won't/can't upgrade their SA version, then rulesdujour is still valid for them. My guess is that when those admins eventually do upgrade and then wonder why things don't work just right, they ask in the SARE mailing list and get told to not use rulesdujour but instead use sa-update. Regards, Michael. ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Problems with spamassassin 3.2.5-1.el5.rf
I haven't looked into this in detail, but suspect this means that spamassassin rules directory was compiled with /usr/share/spamassassin, but sa-update was compiled with /var/lib/spamassassin therefore the problem. Why did you not look at it. The spec ist here: http://svn.rpmforge.net/svn/trunk/rpms/spamassassin/spamassassin.spec financial.com AG Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553 ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Problems with spamassassin 3.2.5-1.el5.rf
Hi Ignacio,
Michael,
On my system when I run spamassassin -D --lint, it shows that the rules
directory is set to /usr/share/spamassassin, and suspect that in your
system will show this result too, so in fact you might have now an newly
installed duplicate set of rules :).
Hmm... I just checked my lint on el4, it has /var/lib/spamassassin, on el5 it
has /usr/share/spamassassin.
I just started up a clean el5 VM and tested this with a clean install of SA
3.2.5 from rpmforge. I ran an sa-update (without any parameters) and the
updates went into /var/lib/spamassassin.
So it seems on el4 the rpm is fine, on el5 it isn't.
I haven't looked into this in detail, but suspect this means that
spamassassin rules directory was compiled with
/usr/share/spamassassin, but sa-update was compiled with
/var/lib/spamassassin therefore the problem.
Yes that seems to be the case. Checking the (latest) spec there's this bit:
%build
export CFLAGS=%{optflags} -I/usr/kerberos/include
%{__perl} Makefile.PL \
%{!?_with_perl_5_6:DESTDIR=%{buildroot}} \
SYSCONFDIR=%{_sysconfdir} \
INSTALLDIRS=vendor \
ENABLE_SSL=yes /dev/null
%{__make} %{?_smp_mflags} OPTIMIZE=%{optflags}
%{__make} %{?_smp_mflags} spamc/libspamc.so LIBS=-ldl %{optflags} -fPIC
ie. from what I can see without specifically defining the
/var/lib/spamassassin directory the build on Makefile.PL will use the default
/usr/share/spamassassin directory.
From the SA doc this is what it says about this:
***
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.
***
So without those Makefile.PL overrides...
I think at this point Dag will need to comment as it's his spec :)
Here is the pertaining output from my system:
...
[7037] dbg: config: using /usr/share/spamassassin for sys rules
pre files [7037] dbg: config: using /usr/share/spamassassin for
default rules dir [7037] dbg: config: read file
/usr/share/spamassassin/10_default_prefs.cf
[7037] dbg: config: read file /usr/share/spamassassin/20_advance_fee.cf
[7037] dbg: config: read file
/usr/share/spamassassin/20_body_tests.cf [7037] dbg: config: read
file /usr/share/spamassassin/20_compensate.cf [7037] dbg: config:
read file /usr/share/spamassassin/20_dnsbl_tests.cf [7037] dbg:
config: read file /usr/share/spamassassin/20_drugs.cf [7037] dbg:
config: read file /usr/share/spamassassin/20_dynrdns.cf [7037] dbg:
config: read file /usr/share/spamassassin/20_fake_helo_tests.cf
[7037] dbg: config: read file
/usr/share/spamassassin/20_head_tests.cf [7037] dbg: config: read
file /usr/share/spamassassin/20_html_tests.cf [7037] dbg: config:
read file /usr/share/spamassassin/20_imageinfo.cf ...
Please note that I am temporarily using sa-update with option --updatedir
/usr/share/spamassassin to compensate for this problem, which by
the way it's not recommended according to
http://wiki.apache.org/spamassassin/RuleUpdates
Yes that's dangerous. I would personally run the sa-update and if there are
updates, get the cron to send me an email so I could manually copy the files
from /var/lib/spamassassin to /usr/share/spamassassin.
Of course the right way to fix it would seem to be to change the spec file so
it compiles with the /var/lib/spamassassin directory structure for el5.
Regards,
Michael.
Regards,
Ignacio
Hi Ignacio,
Hi Michael,
I stand by what I said, if you do not have the time to run sa-
update, there is no sense in stating that it is not true. Would
someone (other than me):-) that has an installed spamassassin 3.2.5-
1.el5.rf please run sa-update, and corroborate wether or not a set
of rules gets placed in folder /var/lib/spamassassin/version
I run sa-update every night and use the spamassassin package from rpmforge
on
both el4 and el5 servers.
The sa-update script is meant to update the rules and put them into
/var/lib/spamassassin.
The /usr/share/spamassassin directory is there to provide rules to admins
they
can use to copy/move into /var/lib/spamassassin. The fact the rules get
packaged in /usr/share/spamassassin is irrelevant as SA doesn't use them
from
that location.
In reply to your second statement, I am fully aware that SARE has
been deprecated, but it is not a wildly known fact!. Plenty of
proofs of this can be easily found by googling around using keywords
spamassassin how to OR guide, and verify how widely rules-dujour
installation is recommended, even in very recent installation guides.
Re: [suggest] Problems with spamassassin 3.2.5-1.el5.rf
Why thanks Christoph, But I am not a packager just a user, that took it upon itself to dig down a problem and report it. As stated in the initial message I have (very) superficial knowledge of packing rpms, and would not know where to begin (seriously). Oh BTW,the spec file you pointed at does not contains any data with regards to the rules paths used to compile spamassassin. Again I suspect ;) these configuration settings must be located within spamassassin source files. Regards, Ignacio I haven't looked into this in detail, but suspect this means that spamassassin rules directory was compiled with /usr/share/spamassassin, but sa-update was compiled with /var/lib/spamassassin therefore the problem. Why did you not look at it. The spec ist here: http://svn.rpmforge.net/svn/trunk/rpms/spamassassin/spamassassin.spec financial.com AG Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich â HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553 ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Problems with spamassassin 3.2.5-1.el5.rf
Am Donnerstag, den 21.08.2008, 10:10 +0200 schrieb Ignacio Bustamante: Again I suspect ;) these configuration settings must be located within spamassassin source files. Well wouldn't it be better to discuss this issue on the SA-devel lists? financial.com AG Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553 ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Problems with spamassassin 3.2.5-1.el5.rf
Hi Michael,
Yes that's dangerous. I would personally run the sa-update and if there
are updates, get the cron to send me an email so I could manually
copy the files from /var/lib/spamassassin to /usr/share/spamassassin.
I tried that, but the problem is that spamassassin will look into all
three directories for rule files (/etc/mail/spamassassin,
/var/lib/spamassassin/version and /usr/share/spamassassin), so in
reality you have to move, not copy the files to /usr/share/spamassassin.
In my case this aggravated by the fact that I had initially installed
spamassassin from centos base repo, added a bunch of rules from SARE to
/etc/mail/spamassassin along with rules dujour, and later upgraded to
spamassassin from rpmforge, only to end up with triplicate set of rules
:). To make the story short, spamassassin was taking 20-30 seconds to scan
each email message.
Regards,
Ignacio
Hi Ignacio,
Michael,
On my system when I run spamassassin -D --lint, it shows that the
rules
directory is set to /usr/share/spamassassin, and suspect that in your
system will show this result too, so in fact you might have now an newly
installed duplicate set of rules :).
Hmm... I just checked my lint on el4, it has /var/lib/spamassassin, on el5
it
has /usr/share/spamassassin.
I just started up a clean el5 VM and tested this with a clean install of
SA
3.2.5 from rpmforge. I ran an sa-update (without any parameters) and the
updates went into /var/lib/spamassassin.
So it seems on el4 the rpm is fine, on el5 it isn't.
I haven't looked into this in detail, but suspect this means that
spamassassin rules directory was compiled with
/usr/share/spamassassin, but sa-update was compiled with
/var/lib/spamassassin therefore the problem.
Yes that seems to be the case. Checking the (latest) spec there's this
bit:
%build
export CFLAGS=%{optflags} -I/usr/kerberos/include
%{__perl} Makefile.PL \
%{!?_with_perl_5_6:DESTDIR=%{buildroot}} \
SYSCONFDIR=%{_sysconfdir} \
INSTALLDIRS=vendor \
ENABLE_SSL=yes /dev/null
%{__make} %{?_smp_mflags} OPTIMIZE=%{optflags}
%{__make} %{?_smp_mflags} spamc/libspamc.so LIBS=-ldl %{optflags} -fPIC
ie. from what I can see without specifically defining the
/var/lib/spamassassin directory the build on Makefile.PL will use the
default
/usr/share/spamassassin directory.
From the SA doc this is what it says about this:
***
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.
***
So without those Makefile.PL overrides...
I think at this point Dag will need to comment as it's his spec :)
Here is the pertaining output from my system:
...
[7037] dbg: config: using /usr/share/spamassassin for sys rules
pre files [7037] dbg: config: using /usr/share/spamassassin for
default rules dir [7037] dbg: config: read file
/usr/share/spamassassin/10_default_prefs.cf
[7037] dbg: config: read file /usr/share/spamassassin/20_advance_fee.cf
[7037] dbg: config: read file
/usr/share/spamassassin/20_body_tests.cf [7037] dbg: config: read
file /usr/share/spamassassin/20_compensate.cf [7037] dbg: config:
read file /usr/share/spamassassin/20_dnsbl_tests.cf [7037] dbg:
config: read file /usr/share/spamassassin/20_drugs.cf [7037] dbg:
config: read file /usr/share/spamassassin/20_dynrdns.cf [7037] dbg:
config: read file /usr/share/spamassassin/20_fake_helo_tests.cf
[7037] dbg: config: read file
/usr/share/spamassassin/20_head_tests.cf [7037] dbg: config: read
file /usr/share/spamassassin/20_html_tests.cf [7037] dbg: config:
read file /usr/share/spamassassin/20_imageinfo.cf ...
Please note that I am temporarily using sa-update with option
--updatedir
/usr/share/spamassassin to compensate for this problem, which by
the way it's not recommended according to
http://wiki.apache.org/spamassassin/RuleUpdates
Yes that's dangerous. I would personally run the sa-update and if there
are
updates, get the cron to send me an email so I could manually copy the
files
from /var/lib/spamassassin to /usr/share/spamassassin.
Of course the right way to fix it would seem to be to change the spec file
so
it compiles with the /var/lib/spamassassin directory structure for el5.
Regards,
Michael.
Regards,
Ignacio
Hi Ignacio,
Hi Michael,
I stand by what I said, if you do not have the time to run sa-
update, there is no sense in stating that it is not true. Would
someone (other than me):-) that has an installed spamassassin 3.2.5-
1.el5.rf please run
[suggest] Re: suggest Digest, Vol 38, Issue 13
Michael wrote: Message: 2 Date: Thu, 21 Aug 2008 17:57:17 +1100 From: Michael Mansour [EMAIL PROTECTED] Subject: Re: [suggest] Re: suggest Digest, Vol 38, Issue 12 To: Nico Kadel-Garcia [EMAIL PROTECTED], suggest@lists.rpmforge.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 If SARE rules are this deprecated, but only known about on the mailing lists, then the Wiki's should be updated about this and the rulesdujour tool eliminated from the RPM or at least disabled. Right? Not really no. Not everyone is using the latest SA and/or sa-update to update their rules. For those people that won't/can't upgrade their SA version, then rulesdujour is still valid for them. My guess is that when those admins eventually do upgrade and then wonder why things don't work just right, they ask in the SARE mailing list and get told to not use rulesdujour but instead use sa-update. Regards, Michael. I've apparently made myself unclear. If you're using RPM management, you can delete those files in the .spec file, even if the tarball has them for reference and antique usages. That's package management safety. And in a later message: Of course the right way to fix it would seem to be to change the spec file so it compiles with the /var/lib/spamassassin directory structure for el5. It's a 'right' way, but now it's tricky. If people have been editing files in the old locations, and setting up local modifications, writing the .spec to transfer their files to the new location correctly, or to properly disable the old files and not tick off users who're expecting the old location, is awkward. ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Perl module request list
On Tuesday 19 August 2008 08:30:02 pm David Steinbrunner wrote: Dag Wieers wrote: perl-Crypt-OpenSSL I think the above should have been: perl-Crypt-OpenSSL-X509 Which I'm not seeing here: http://packages.sw.be/ I've added the package. kind regards, Dries ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Problems with spamassassin 3.2.5-1.el5.rf
Hi Ignacio,
Hi Michael,
Yes that's dangerous. I would personally run the sa-update and if there
are updates, get the cron to send me an email so I could manually
copy the files from /var/lib/spamassassin to /usr/share/spamassassin.
I tried that, but the problem is that spamassassin will look into all
three directories for rule files (/etc/mail/spamassassin,
/var/lib/spamassassin/version and /usr/share/spamassassin), so in
Are you sure about this? when running the -D --lint on SA do you see it load
the rules from:
/usr/share/spamassassin and then
/var/lib/spamassassin
?
reality you have to move, not copy the files to /usr/share/spamassassin.
In my case this aggravated by the fact that I had initially installed
spamassassin from centos base repo, added a bunch of rules from SARE
to /etc/mail/spamassassin along with rules dujour, and later
upgraded to spamassassin from rpmforge, only to end up with
triplicate set of rules :). To make the story short, spamassassin
was taking 20-30 seconds to scan each email message.
The right way to do this is to create a channels file for sare rules in
/etc/mail/spamassassin, then reference that file from the sa-update cron.
If you don't know what I mean here let me know and I'll explain further.
Regards,
Michael.
Regards,
Ignacio
Hi Ignacio,
Michael,
On my system when I run spamassassin -D --lint, it shows that the
rules
directory is set to /usr/share/spamassassin, and suspect that in your
system will show this result too, so in fact you might have now an newly
installed duplicate set of rules :).
Hmm... I just checked my lint on el4, it has /var/lib/spamassassin, on el5
it
has /usr/share/spamassassin.
I just started up a clean el5 VM and tested this with a clean install of
SA
3.2.5 from rpmforge. I ran an sa-update (without any parameters) and the
updates went into /var/lib/spamassassin.
So it seems on el4 the rpm is fine, on el5 it isn't.
I haven't looked into this in detail, but suspect this means that
spamassassin rules directory was compiled with
/usr/share/spamassassin, but sa-update was compiled with
/var/lib/spamassassin therefore the problem.
Yes that seems to be the case. Checking the (latest) spec there's this
bit:
%build
export CFLAGS=%{optflags} -I/usr/kerberos/include
%{__perl} Makefile.PL \
%{!?_with_perl_5_6:DESTDIR=%{buildroot}} \
SYSCONFDIR=%{_sysconfdir} \
INSTALLDIRS=vendor \
ENABLE_SSL=yes /dev/null
%{__make} %{?_smp_mflags} OPTIMIZE=%{optflags}
%{__make} %{?_smp_mflags} spamc/libspamc.so LIBS=-ldl %{optflags} -fPIC
ie. from what I can see without specifically defining the
/var/lib/spamassassin directory the build on Makefile.PL will use the
default
/usr/share/spamassassin directory.
From the SA doc this is what it says about this:
***
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.
***
So without those Makefile.PL overrides...
I think at this point Dag will need to comment as it's his spec :)
Here is the pertaining output from my system:
...
[7037] dbg: config: using /usr/share/spamassassin for sys rules
pre files [7037] dbg: config: using /usr/share/spamassassin for
default rules dir [7037] dbg: config: read file
/usr/share/spamassassin/10_default_prefs.cf
[7037] dbg: config: read file /usr/share/spamassassin/20_advance_fee.cf
[7037] dbg: config: read file
/usr/share/spamassassin/20_body_tests.cf [7037] dbg: config: read
file /usr/share/spamassassin/20_compensate.cf [7037] dbg: config:
read file /usr/share/spamassassin/20_dnsbl_tests.cf [7037] dbg:
config: read file /usr/share/spamassassin/20_drugs.cf [7037] dbg:
config: read file /usr/share/spamassassin/20_dynrdns.cf [7037] dbg:
config: read file /usr/share/spamassassin/20_fake_helo_tests.cf
[7037] dbg: config: read file
/usr/share/spamassassin/20_head_tests.cf [7037] dbg: config: read
file /usr/share/spamassassin/20_html_tests.cf [7037] dbg: config:
read file /usr/share/spamassassin/20_imageinfo.cf ...
Please note that I am temporarily using sa-update with option
--updatedir
/usr/share/spamassassin to compensate for this problem, which by
the way it's not recommended according to
http://wiki.apache.org/spamassassin/RuleUpdates
Yes that's dangerous. I would personally run the sa-update and if there
are
updates, get the cron to send me an email so I could manually copy the
Re: [suggest] tor-0.2.0.30
On Aug 21, 2008, at 6:13 PM, Greg Swallow wrote: http://archives.seul.org/or/talk/Jun-2008/msg00209.html ...saying to try removing the --enable-openbsd-malloc configure options in the spec file. yup! i can confirm that that works. trivial patch (hey, and it even works for SuSE! :) ) -steve tor-0.2.0.30.patch Description: Binary data --- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Problems with spamassassin 3.2.5-1.el5.rf
Hi Michael,
Hi Ignacio,
Hi Michael,
Yes that's dangerous. I would personally run the sa-update and if
there
are updates, get the cron to send me an email so I could manually
copy the files from /var/lib/spamassassin to /usr/share/spamassassin.
I tried that, but the problem is that spamassassin will look into all
three directories for rule files (/etc/mail/spamassassin,
/var/lib/spamassassin/version and /usr/share/spamassassin), so in
Are you sure about this? when running the -D --lint on SA do you see it
load
the rules from:
/usr/share/spamassassin and then
/var/lib/spamassassin
Yep,
If you would care to leave the copy of rules generated by sa-update with
no potions in /var/lib/spamassassin/version, as well as the copy
installed in /usr/share/spamassassin, then when you run spamassassin -D
--lint the output will show many lines similar to the following:
...
[30825] dbg: rules: __MO_OL_015D5 merged duplicates: __MO_OL_6554A
[30825] dbg: rules: __MO_OL_22B61 merged duplicates: __MO_OL_4F240
__MO_OL_ADFF7
[30825] dbg: rules: __MO_OL_812FF merged duplicates: __MO_OL_BC7E6
[30825] dbg: rules: __MO_OL_25340 merged duplicates: __MO_OL_4EEDB
__MO_OL_7533E
[30825] dbg: rules: __MO_OL_58CB5 merged duplicates: __MO_OL_B4B40
[30825] dbg: rules: __DOS_HAS_ANY_URI merged duplicates: __HAS_ANY_URI
[30825] dbg: rules: __XM_OL_C9068 merged duplicates: __XM_OL_EF20B
...
Which means that spamassassin is merging/resolving conflicts with
duplicate rules found. This in itself is not a big problem, but when you
have rules in a directory that have been updated, and not updated in
others, then with time you will experience a progressive slowdown in
performance by spamassassin.
Regards,
Ignacio
?
reality you have to move, not copy the files to /usr/share/spamassassin.
In my case this aggravated by the fact that I had initially installed
spamassassin from centos base repo, added a bunch of rules from SARE
to /etc/mail/spamassassin along with rules dujour, and later
upgraded to spamassassin from rpmforge, only to end up with
triplicate set of rules :). To make the story short, spamassassin
was taking 20-30 seconds to scan each email message.
The right way to do this is to create a channels file for sare rules in
/etc/mail/spamassassin, then reference that file from the sa-update cron.
If you don't know what I mean here let me know and I'll explain further.
Regards,
Michael.
Regards,
Ignacio
Hi Ignacio,
Michael,
On my system when I run spamassassin -D --lint, it shows that the
rules
directory is set to /usr/share/spamassassin, and suspect that in
your
system will show this result too, so in fact you might have now an
newly
installed duplicate set of rules :).
Hmm... I just checked my lint on el4, it has /var/lib/spamassassin, on
el5
it
has /usr/share/spamassassin.
I just started up a clean el5 VM and tested this with a clean install
of
SA
3.2.5 from rpmforge. I ran an sa-update (without any parameters) and
the
updates went into /var/lib/spamassassin.
So it seems on el4 the rpm is fine, on el5 it isn't.
I haven't looked into this in detail, but suspect this means that
spamassassin rules directory was compiled with
/usr/share/spamassassin, but sa-update was compiled with
/var/lib/spamassassin therefore the problem.
Yes that seems to be the case. Checking the (latest) spec there's this
bit:
%build
export CFLAGS=%{optflags} -I/usr/kerberos/include
%{__perl} Makefile.PL \
%{!?_with_perl_5_6:DESTDIR=%{buildroot}} \
SYSCONFDIR=%{_sysconfdir} \
INSTALLDIRS=vendor \
ENABLE_SSL=yes /dev/null
%{__make} %{?_smp_mflags} OPTIMIZE=%{optflags}
%{__make} %{?_smp_mflags} spamc/libspamc.so LIBS=-ldl %{optflags}
-fPIC
ie. from what I can see without specifically defining the
/var/lib/spamassassin directory the build on Makefile.PL will use the
default
/usr/share/spamassassin directory.
From the SA doc this is what it says about this:
***
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.
***
So without those Makefile.PL overrides...
I think at this point Dag will need to comment as it's his spec :)
Here is the pertaining output from my system:
...
[7037] dbg: config: using /usr/share/spamassassin for sys rules
pre files [7037] dbg: config: using /usr/share/spamassassin for
default rules dir [7037] dbg: config: read file
