Mailing List Archive

are these the important folders which need to be backed up?

PREFIX=/usr,
DEF_RULES_DIR=/usr/share/spamassassin,
LOCAL_RULES_DIR=/etc/spamassassin,
LOCAL_STATE_DIR=/var/lib/spamassassin

and...
/var/lib/spamassassin/3.004002
does that match to SA version 3.4.2 ?
I see 3.00... and think, NO that is not 3.4 ... etc


data gotten from running
sa-update -D
Jan 20 11:44:02.212 [30368] dbg: logger: adding facilities: all
Jan 20 11:44:02.213 [30368] dbg: logger: logging level is DBG
Jan 20 11:44:02.213 [30368] dbg: generic: SpamAssassin version 3.4.2
Jan 20 11:44:02.213 [30368] dbg: generic: Perl 5.022001, PREFIX=/usr,
DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/spamassassin,
LOCAL_STATE_DIR=/var/lib/spamassassin
Jan 20 11:44:02.213 [30368] dbg: config: timing enabled
Jan 20 11:44:02.215 [30368] dbg: config: score set 0 chosen.
Jan 20 11:44:02.222 [30368] dbg: generic: sa-update version 3.4.2 /
svn1840377
Jan 20 11:44:02.222 [30368] dbg: generic: using update directory:
/var/lib/spamassassin/3.004002

>

On Tue, 19 Jan 2021 13:31:33 -0500
Steve Charmer wrote:


> SA was originally installed using apt-get (Ubuntu-16)

> BACKUP
> I would feel safer if I had a backup of the current spamassassin
> system. is there a recommended method to backup all files to a tar?
>
> I think I have identified these folders as worthy of backup:
>
> # define an array of folders to backup
> backup_dirs=( \
> '/etc/spamassassin' \
> '/usr/bin' \
> '/usr/sbin' \
> '/usr/share/perl5' \
> '/usr/share/spamassassin' \
> '/var/lib/spamassassin' \

I only ever backup the equivalent of /etc/spamassassin, and not
especially before upgrades. I'm more likely to break it than a package
upgrade is. An upgrade should only reinstall the *.sample files under
that directory.

If you are going to back-up installed files you need to back-up
practically everything, including the package database[s], so that you
can do a full roll-back. A partial restore of old installed files could
leave things in an inconsistent state - although you may get away with
it on Debian/Ubuntu.


> To upgrade to the latest version, 3.4.5
> do I just run:
>
> apt-get install spamassassin

I've not used Ubuntu or apt-get, but usually package managers have some
kind of upgrade command. Unless there's a good reason not to, I'd update
everything IIWY.

When upgrading SA to a different version you need to run sa-update to
populate the new rules directory and optionally run sa-compile if you
use it. spamd or any other daemon using the SA perl libraries (e.g.
amavisd) should be restarted.

I'm sorry, but I do not understand your message.

I thought an upgrade fixes bugs. Maybe you are thinking about an update,
which seems like it would updates rules in *.samples?

I would "like" to backup everything, for safety, that is why I included a
list of the directories (fodlers) which I thought had Spamassassin content,
to get feedback from other users if they are the correct folders to backup,
in case a restore is needed. Unfortunately, I don't feel any more
knowledgeable than before I read your message. By "package databases" did
you mean the bayes database?

So if anyone can assist with more advice on "exactly" what to backup and
how to run an "upgrade", please chime in.
Thank you.

on this documentation page:
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/UpgradingVersion

"If you install using a Linux package installer:
Debian unstable: apt-get install spamassassin
"
what is the meaning of "unstable" ?
it sounds scary, like the package should not be run in live mail systems,
but then why would it be in the package mgr and not in a development
package version?

On 21 Jan 2021, at 11:08, Steve Charmer wrote:

> I'm sorry, but I do not understand your message.
>
> I thought an upgrade fixes bugs. Maybe you are thinking about an
> update,
> which seems like it would updates rules in *.samples?

From the man page for 'apt-get':

update
Used to re-synchronize the package index files from their sources.
The
indexes of available packages are fetched from the location(s)
specified in
/etc/apt/sources.list(5). An update should always be performed
before an
upgrade or dist-upgrade.

upgrade
Used to install the newest versions of all packages currently
installed
on the system from the sources enumerated in
/etc/apt/sources.list(5).
Packages currently installed with new versions available are
retrieved and
upgraded; under no circumstances are currently installed packages
removed,
nor are packages that are not already installed retrieved and
installed.
New versions of currently installed packages that cannot be upgraded
without changing the install status of another package will be left
at
their current version. An update must be performed first so that
apt-get
knows that new versions of packages are available.

IN SHORT: "update" applies to the package index used by apt-get,
"upgrade" applies to the packages themselves.

> I would "like" to backup everything, for safety, that is why I
> included a
> list of the directories (fodlers) which I thought had Spamassassin
> content,
> to get feedback from other users if they are the correct folders to
> backup,
> in case a restore is needed. Unfortunately, I don't feel any more
> knowledgeable than before I read your message. By "package databases"
> did
> you mean the bayes database?

No. The 'apt-get' program needs to maintain an index of what packages
are installed, so it has its own database.

> So if anyone can assist with more advice on "exactly" what to backup
> and
> how to run an "upgrade", please chime in.
> Thank you.

Assuming that the packagers of SA for your platform have done their job
properly, upgrading the package with apt-get should not modify any of
your local config. It will only replace the files contained in the
package.


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

On 1/21/2021 11:25 AM, Bill Cole wrote:
> On 21 Jan 2021, at 11:08, Steve Charmer wrote:
>
>
>> I would "like" to backup everything, for safety, that is why I included a
>> list of the directories (fodlers) which I thought had Spamassassin content,
>> to get feedback from other users if they are the correct folders to backup,
>> in case a restore is needed. Unfortunately, I don't feel any more
>> knowledgeable than before I read your message. By "package databases" did
>> you mean the bayes database?
>
> No. The 'apt-get' program needs to maintain an index of what packages are
> installed, so it has its own database.
>
>> So if anyone can assist with more advice on "exactly" what to backup and
>> how to run an "upgrade", please chime in.
>> Thank you.
>
> Assuming that the packagers of SA for your platform have done their job properly,
> upgrading the package with apt-get should not modify any of your local config. It
> will only replace the files contained in the package.

I have never had an issue with a SpamAssassin update, but if you are worried about
it, a backup of your config directory should be sufficient.  This would be the
directory containing all of the .cf files.  This is /etc/mail/spamassassin on my
system, but I build SA from source.  The package may put them in a different location.

--
Bowie

Steve Charmer wrote:
> on this documentation page:
> https://cwiki.apache.org/confluence/display/SPAMASSASSIN/UpgradingVersion
>
> "If you install using a Linux package installer:
> Debian unstable: apt-get install spamassassin
> "
> what is the meaning of "unstable" ?
> it sounds scary, like the package should not be run in live mail systems,
> but then why would it be in the package mgr and not in a development
> package version?

You are both absolutely correct and also missing the key nature of
that bit of the documentation.

*If* you are running Debian Unstable *then* running "apt-get install
spamassassin" will install the latest packaged version. Since by your
response I deduce that you are not running Debian Unstable then this
bit of the documentation does not apply to your environment.
Therefore ignore it. Actually I read that you are running Ubuntu.
Therefore I recommend simply upgrading to the latest Ubuntu LTS and
letting it upgrade to the latest spamassassin packaged for it. You
mentioned Ubuntu 16.04 so upgrade first to 18.04 and get everything
working then continue the upgrade to 20.04 afterward. Always pass
through the major release points, never skip a release.

Background: Debian has three stages in the package lifecycle. I know
you said you are running Ubuntu but Ubuntu is a fork of Debian,
similar but different, and the document you refer to above is for
Debian, and specifically Debian Unstable. So this is about Debian
Unstable to answer your question about the meaning of "unstable".

Packages are build and uploaded to the "Unstable" repository. This is
the daily bleeding edge. People will swear that they have had no
problem running the daily bleeding edge of Unstable, until they do get
snagged by upgrading on a day with a broken set of packages.

Packages sit in Unstable for a ten day quarantine period. This allows
people running Unstable to test these and hopefully file bugs if there
are any problems with the newly uploaded package. If no RC release
critical bugs have been filed after the waiting period then the
package is migrated into the Testing repository. Testing is, more or
less, intended to be the always ready release candidate for the next
Stable release. In theory Testing might be more robust than Unstable
due to the RC bug reporting hold placed upon broken packages. However
when packages don't get a bug reported until after they have already
migrated to Testing and then get an RC bug reported against them that
means that Testing gets frozen with the broken version until the
Unstable one gets resolved. In some cases that can be basicaly
forever if the problem is not easily resolved.

Then the schedule calls for a Stable release to be made every two
years from the Testing repository. Stable is very robust and does not
change over the lifetime of it. Stable is where people who are
clueless say "Debian is too old" because Stable will never upgrade
from say Apache 2.2 to Apache 2.4 within a stable release cycle.
Those types of breaking changes must happen in the next release.

Therefore people who want the daily bleeding edge often run Unstable.
And swear it is awesome. Until Unstable is broken one day. And then
they need to figure it out and deal with it. And then it depends upon
their skill level dealing with Unstable. For the experienced and
skilled administrator this is usually very easy. For example by
downgrading from the Testing repository which holds a previous version
that migrated to Testing. But sometimes it is much more complicated
and one must scramble around looking at snapshot.debian.org or by
other things. It's pretty rare that someone must resort to hand
editing the /var/lib/dpkg/status file by hand to fix things. But not
unheard of needing. :-)

I run Unstable on my main desktop specifically to find bugs as early
as I can and report them so that I can either get them fixed or fix
them *before* they get released in Stable and make my life unpleasant
for the two year Stable lifecycle.

Meanwhile... There are many viewpoints on how software distributions
should release an operating system. This is Debian's flow. But
people come all different and many prefer different flows. There are
many available. Some people prefer a rolling release module instead
of the stable release model. There are several other software distros
that are based upon rolling releases such as Gentoo, Arch, Void, and
others. Therefore people should choose the one they want. It's a big
universe. I prefer the Stable release model.

Bob

Steve Charmer wrote:
> SA was originally installed using apt-get (Ubuntu-16)

I recommend upgrading from Ubuntu 16 to 18.04 and letting it upgrade
spamassassin as part of that upgrade. Then upgrade from 18.04 to
20.04 and again let it upgrade spamassassin along with everything
else. That's the best way when starting from Ubuntu 16.

> BACKUP
> I would feel safer if I had a backup of the current spamassassin system.
> is there a recommended method to backup all files to a tar?

I highly recommend the "etckeeper" package. It automatically keeps a
version history of all of /etc in a version repository. It supports
git, svn, others, but I prefer git and use etckeeper with a git
repository of /etc. The beauty is that after installing then it is
all fully automatic. The admin needs to know nothing about version
control. But then if one wants to see how /etc has been changed they
can always get help from a git person, or svn or whatever, to view the
history and retrieve older versions. It's not strickly disaster
recovery backup since it is local but it is good for viewing changes
due to software upgrades and the like.

> I think I have identified these folders as worthy of backup:
>
> # define an array of folders to backup
> backup_dirs=( \
> '/etc/spamassassin' \

That's the local configuration. Definitely good to snapshot.

> '/usr/bin' \
> '/usr/sbin' \
> '/usr/share/perl5' \
> '/usr/share/spamassassin' \

Those are all in the packages, since you said you were using a
packaged version from Ubuntu. Therefore not really useful to backup
since one should not ever restore those from backup on top of a
running system.

> '/var/lib/spamassassin' \

That's the dynamic daily downloads of rules that are updated
routinely. Maybe good for a deep dive by someone skilled in the art.
But otherwise on any new or different installation they will be
updated again "today" with the latest copy and so backing this up
seems less useful.

> and I can also backup the bayes database
> sa-learn --backup > "${bayes_backup_filename}"

Not a bad idea. I have never had the binary bayes databases corrupted
but also keep them in normal daily backups. I would pull the binary
out of the previous backup.

At major releases the format version of the bayes database is upgraded
to the next version and will need to be upgraded themselves after the
db libraries that use it are upgraded. That will need running a
program such as "db_upgrade" to upgrade to the current version of it.
That will be an a dbX.Y-util package.

> UPGRADE
> To upgrade to the latest version, 3.4.5
> do I just run:
>
> apt-get install spamassassin

If you are still running Ubuntu 16.04 then the version installed would
be 3.4.2 as that is in the 16.04 release.

If you have upgraded to Ubuntu 18.04 then the version installed would
still be 3.4.2 as that is in the 18.04 release.

If you have upgraded to Ubuntu 20.04 then the version installed would
be 3.4.4 as that is in the 20.04 release.

Only if you have upgraded to an Ubuntu nightly or installing a
backport would you get 3.4.5.

https://launchpad.net/ubuntu/+source/spamassassin

I am a little out of my depth with Ubuntu. Sorry.

> does it simply overwrite existing files?
> i.e. I don't need to uninstall the old version first?
>
> Will my local.cf file stay the same?

It is best to never make changes to local.cf. Counter intuitively I
know. Because then merges will be required upon package upgrades.
Instead I recommend using a local-local.cf file to be your "really
local" changes. Since that is not packaged as a "conffile" it will
never require merges. However if syntax changes then it will of
course need to be updated to match the new syntax.

I know, I know... Too much information! But you are doing system
administration and this is what you need to know to be doing it
successfully.

Bob

On 21 Jan 2021, at 17:05, Bob Proulx wrote:

> Only if you have upgraded to an Ubuntu nightly or installing a
> backport would you get 3.4.5.

Also required: a time machine.

3.4.5 is not yet released. There have been substantial fixes made to the
3.4 branch since the last pre-release snapshot that is available via
Launchpad. Release of 3.4.5 should be soon-ish.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Bill Cole wrote:
> Bob Proulx wrote:
> > Only if you have upgraded to an Ubuntu nightly or installing a
> > backport would you get 3.4.5.
>
> Also required: a time machine.
>
> 3.4.5 is not yet released. There have been substantial fixes made to the 3.4
> branch since the last pre-release snapshot that is available via Launchpad.
> Release of 3.4.5 should be soon-ish.

Oh! I see at least one place where I went wrong! I am not fully
clued in with Ubuntu but looking at the launchpad page and welcome
input on this.

https://launchpad.net/ubuntu/+source/spamassassin

I looked there and saw "Latest upload: 3.4.5~pre1-3". I know that is
a pre-released release-candidate and not the actual release. Looking
deeper now I see that this one is from 2020-10-23 when it was
uploaded. So for a pre-release it could benefit being refreshed for
the latest development. But I think that means that someone tracking
Hirsute Hippo would have that version available.

I think using the 20.04 bundled spamassassin 3.4.4 would make the most
sense for the easiest way forward. Especially if one is not
participating in the daily spamassassin development. Because being
part of 20.04 means that version will have a large user base and
therefore a large community to report bugs and for motivation to fix
things there as needed too. (Says me who is using 3.4.2 bundled with
Debian Stable 10 "Buster".)

Bob

On 21.01.21 11:10, Steve Charmer wrote:
>on this documentation page:
>https://cwiki.apache.org/confluence/display/SPAMASSASSIN/UpgradingVersion
>
>"If you install using a Linux package installer:
> Debian unstable: apt-get install spamassassin
>"
>what is the meaning of "unstable" ?

it's a debian question, not SA question:

https://www.debian.org/releases/

>it sounds scary, like the package should not be run in live mail systems,
>but then why would it be in the package mgr and not in a development
>package version?

because development versions are installed through package manager too.

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows found: (R)emove, (E)rase, (D)elete