Mailing List Archive

Update SA on CentOS
Hi list, I use spamassassin 3.40 on CentOS 7. I know it's an older version and I think the root cause for my increased spam. Years ago I installed SA with: yum install spamassassin Now I realized that with yum update the SA will not update to the newest version. Can someone help me to update SA to a newer version? Regards Olaf
Re: Update SA on CentOS [ In reply to ]
On Apr 3, 2021, at 12:26 PM, Olaf Sommer <WriteME@gmx.de> wrote:
>
> Can someone help me to update SA to a newer version?

The easiest way would probably be to build a local package from source, using the Fedora SRPM. Under a regular (not root) account, do the following:

# wget https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/s/spamassassin-3.4.5-1.fc35.src.rpm
rpm --nomd5 -i spamassassin-3.4.5-1.fc35.src.rpm

This should install a spec file into ~/rpmbuild/SPECS, though it may go elsewhere (e.g., /usr/src). You may need to make the rpmbuild directory.

# cd ~/rpmbuild/SPECS (or appropriate other directory)

# rpmbuild -ba spamassassin.spec

This should install the compiled RPM into ~/rpmbuild/RPMS/$HOSTTYPE/ -- the last few lines of the rpmbuild output will tell you (look for lines beginning with Wrote:).

# cd ~/rpmbuild/RPMS (or appropriate other directory)

# sudo yum localinstall spamassassin-3.4.5-1.el7.x86_64.rpm

(If you are on a different architecture than x86_64, adjust the above accordingly.)

You may need to install some other dependencies, and for that, the easiest would be to install the EPEL 7 repo if you have not already done so.

Hope this helps.

Cheers.

--- Amir
Re: Update SA on CentOS [ In reply to ]
----- Message from Olaf Sommer <WriteME@gmx.de> ---------
Date: Sat, 3 Apr 2021 20:26:42 +0200
From: Olaf Sommer <WriteME@gmx.de>
Subject: Update SA on CentOS
To: users@spamassassin.apache.org


> Hi list,
>  
> I use spamassassin 3.40 on CentOS 7. I know it's an older version and I
> think the root cause for my increased spam.
>  
> Years ago I installed SA with: yum install spamassassin
>  
> Now I realized that with yum update the SA will not update to the newest
> version.
>  
> Can someone help me to update SA to a newer version?
>  
> Regards
> Olaf


I had excellent results with standard CentOS packaged Spamassassin on
7, only very recently moving to RHEL8 with SA 3.4.2. I'd be surprised
if it is the version of SA which is causing your increased spam - more
likely to be your end to end email stack.

I found using postfix with postscreen, SPF, DKIM and DMARC tagging,
and having effective Bayes configuration (and teaching it when it
fails to get it right) resulted in excellent spam prevention on CentOS
7 with its standard packaged SA. And then you are not stepping away
from one of CentOS's main advantages - stable packages not built
outside of RPM.

Simon

--
Simon Wilson
M: 0400 12 11 16
Re: Update SA on CentOS [ In reply to ]
On Apr 3, 2021, at 9:15 PM, Simon Wilson <simon@simonandkate.net> wrote:
>
> And then you are not stepping away from one of CentOS's main advantages - stable packages not built outside of RPM.

For what it's worth, using the Fedora package has been exceedingly stable on my CentOS 7 system. SA is extensively tested by the dev team before release, and there is very little that is system-specific so building from the SRPM is easy and straightforward. Installing really is as simple as the four steps I included in the prior email, and I've been running SA that way on CentOS systems for years (from CentOS 5 onwards).

Granted, I am just one person and my setup is unique to me, so my experience may not translate to others. But I've found the SA package to be completely stable. (Note that it's still built "inside" the RPM, because it's built from the SRPM used for Fedora.)

Cheers.

--- Amir
Re: Update SA on CentOS [ In reply to ]
On Sat, 3 Apr 2021, Amir Caspi wrote:

> For what it's worth, using the Fedora package has been exceedingly
> stable on my CentOS 7 system.

Another CentOS 7 user here. I've been using self-compiled Fedora Rawhide
SRPMs in production for years with no issues.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
10 days until Thomas Jefferson's 278th Birthday
Re: Update SA on CentOS [ In reply to ]
----- Message from Amir Caspi <cepheid@3phase.com> ---------
Date: Sat, 3 Apr 2021 22:06:03 -0600
From: Amir Caspi <cepheid@3phase.com>
Subject: Re: Update SA on CentOS
To: simon@simonandkate.net
Cc: users@spamassassin.apache.org


> On Apr 3, 2021, at 9:15 PM, Simon Wilson <simon@simonandkate.net> wrote:
>>
>> And then you are not stepping away from one of CentOS's main
>> advantages - stable packages not built outside of RPM.
>
> For what it's worth, using the Fedora package has been exceedingly
> stable on my CentOS 7 system. SA is extensively tested by the dev
> team before release, and there is very little that is
> system-specific so building from the SRPM is easy and
> straightforward. Installing really is as simple as the four steps I
> included in the prior email, and I've been running SA that way on
> CentOS systems for years (from CentOS 5 onwards).
>
> Granted, I am just one person and my setup is unique to me, so my
> experience may not translate to others. But I've found the SA
> package to be completely stable. (Note that it's still built
> "inside" the RPM, because it's built from the SRPM used for Fedora.)
>
> Cheers.
>
> --- Amir


Sure - completely get that.

My point is installing the latest version of SA *on its own* without
understanding what is causing the increased spam volume is unlikely to
just fix anything...

Identify what is causing the increased spam, then assess whether there
is anything in SA 3.4.x which is designed to address that. If the
answer is yes a newer version will address it - then by all means
proceed down the path of packaging it if prepared to do so.

The first step (on CentOS at least) should not be to package up
non-CentOS releases - if that *is* your first step then CentOS is not
the distro you should be using...

CentOS / RHEL backport critical security fixes into the stock
versions... you lose that as soon as you go 'roll-your-own'. Not
insurmountable I know - but you need to have a far more rigorous
process for keeping aware and following through / re-packaging.

In other words - my comment to the original poster here is work out
what the problem is before assuming that a new version will fix it.

Simon.

--
Simon Wilson
M: 0400 12 11 16
Re: Update SA on CentOS [ In reply to ]
On 4 Apr 2021, at 0:19, Simon Wilson wrote:

> CentOS / RHEL backport critical security fixes into the stock
> versions... you lose that as soon as you go 'roll-your-own'.

Not a real feature IF you're keeping up with SA releases. Arguably an
anti-feature. Critical security fixes for SA are integrated into minor
version releases (such as in 3.4.5) and are not assured of being
backportable onto any version of SA older than the live 'HEAD' of the
development branch when the security fix is committed.

Put another way, RedHat cherry-picks code changes (security and bugfix)
that may not be fully independent of the other changes made between
releases. They may be creating versions that have subtle breakage that
no canonical release or even point-in-time development HEAD snapshot
shares.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Update SA on CentOS [ In reply to ]
----- Message from Bill Cole
<sausers-20150205@billmail.scconsult.com> ---------
   Date: Sun, 04 Apr 2021 15:16:32 -0400
   From: Bill Cole <sausers-20150205@billmail.scconsult.com>
Subject: Re: Update SA on CentOS
     To: users@spamassassin.apache.org

> On 4 Apr 2021, at 0:19, Simon Wilson wrote:
>
>> CentOS / RHEL backport critical security fixes into the stock
>> versions... you lose that as soon as you go 'roll-your-own'.
>
> Not a real feature IF you're keeping up with SA releases. Arguably
> an anti-feature. Critical security fixes for SA are integrated into
> minor version releases (such as in 3.4.5) and are not assured of
> being backportable onto any version of SA older than the live 'HEAD'
> of the development branch when the security fix is committed.
> Put another way, RedHat cherry-picks code changes (security and
> bugfix) that may not be fully independent of the other changes made
> between releases. They may be creating versions that have subtle
> breakage that no canonical release or even point-in-time development
> HEAD snapshot shares.

Hi Bill,

You may be absolutely correct - I don't know. Are there documented
examples of the breaks you speak of? Running 3.4.2 on RHEL8 I'd be
interested to know.

But that does somewhat miss my point - which for the topic posted was
that understanding *exactly what the problem is* and then working out
what may address it makes more sense than jumping *first* to a
roll-your-own on an OS with a design strategy such as CentOS. 

Simon.
___________
Simon Wilson
M: 0400 12 11 16