Bug 1992749

A scratch build for F36 is here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=73725171

Give it a quick look, just for sanity and if you cannot see anything overly broken, I can build properly and push to bodhi.

FEDORA-2021-93cf007a83 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-93cf007a83

FEDORA-2021-b9ca679007 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b9ca679007

FEDORA-2021-93cf007a83 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-93cf007a83`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-93cf007a83

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-b9ca679007 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b9ca679007`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b9ca679007

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

The old package had issues reading /var/lib/spamassassin and /etc/mail/spamassassin. Some of this still exists. This also is a problem with amavisd if it uses spamassassin.

Aug 11 08:43:13 HOST systemd[1]: Started spampd daemon.
Aug 11 08:43:14 HOST spampd[3277306]: config: cannot opendir /var/lib/spamassassin/3.004006: Permission denied
Aug 11 08:43:14 HOST spampd[3277306]: readdir() attempted on invalid dirhandle SA_CF_DIR at /usr/share/perl5/vendor_perl/Mail/SpamAssassin.pm line 2101.
Aug 11 08:43:14 HOST spampd[3277306]: closedir() attempted on invalid dirhandle SA_CF_DIR at /usr/share/perl5/vendor_perl/Mail/SpamAssassin.pm line 2103.
Aug 11 08:43:14 HOST spampd[3277306]: config: cannot opendir /var/lib/spamassassin/3.004006: Permission denied
Aug 11 08:43:14 HOST spampd[3277306]: readdir() attempted on invalid dirhandle SA_CF_DIR at /usr/share/perl5/vendor_perl/Mail/SpamAssassin.pm line 2101.
Aug 11 08:43:14 HOST spampd[3277306]: closedir() attempted on invalid dirhandle SA_CF_DIR at /usr/share/perl5/vendor_perl/Mail/SpamAssassin.pm line 2103.
Aug 11 08:43:14 HOST spampd[3277306]: config: path "/var/lib/spamassassin/3.004006/languages" is inaccessible: Permission denied
Aug 11 08:43:14 HOST spampd[3277306]: config: registryboundaries: no tlds defined, need to run sa-update
Aug 11 08:43:14 HOST spampd[3277306]: config: path "/var/lib/spamassassin/3.004006/triplets.txt" is inaccessible: Permission denied
Aug 11 08:43:14 HOST spampd[3277306]: 2021/08/11-08:43:14 SpamPD (type Net::Server::PreForkSimple) starting! pid(3277306)
Aug 11 08:43:14 HOST spampd[3277306]: Binding to TCP port 10026 on host 127.0.0.1 with IPv4
Aug 11 09:17:24 HOST spampd[3277306]: 2021/08/11-09:17:24 Server closing!

The above probably still persists, but my manual file permission changes probably hides it.

Aug 17 17:23:59 HOST spampd[1458729]: config: path "/var/lib/spamassassin/3.004006/languages" is inaccessible: Permission denied
Aug 17 17:24:00 HOST spampd[1458729]: config: registryboundaries: no tlds defined, need to run sa-update
Aug 17 17:24:00 HOST spampd[1458729]: config: path "/var/lib/spamassassin/3.004006/triplets.txt" is inaccessible: Permission denied
Aug 17 17:24:00 HOST spampd[1458729]: SpamPD v2.61 [Perl 5.32.1, Net::Server::PreForkSimple 2.009, SA 3.4.6, rules v(unknown)] starting with: --nodetach --u=spampd --g=spampd --a --L -->
Aug 17 17:24:00 HOST spampd[1458729]: 2021/08/17-17:24:00 Couldn't open pid file "/var/run/spampd.pid" [Permission denied].
Aug 17 17:24:00 HOST spampd[1458729]: 
Aug 17 17:24:00 HOST spampd[1458729]:  at line 177 in file /usr/share/perl5/vendor_perl/Net/Server.pm
Aug 17 17:24:00 HOST spampd[1458729]: 2021/08/17-17:24:00 Server closing!
Aug 17 17:24:00 HOST systemd[1]: spampd.service: Main process exited, code=exited, status=1/FAILURE
Aug 17 17:24:00 HOST systemd[1]: spampd.service: Failed with result 'exit-code'.

It appears that this is caused by no world write to /run. That and it must be running as another user.

I am guessing many of these are SELinux related. If yes, I think a bug should be opened to selinux-policy package to fix this. The easiest is to put SELinux into permissive mode and then determine what's required.

If these are pure permissions issues, I have have a look whether anything can be improved there.

I am surprised to see /var/run/spampd.pid on the list, to be honest. When service is started by systemd, there should be no PID file created.

Just installed spampd from updates-testing on F34 and started it with systemctl. Didn't get any permission problems.

Bojan, thank you. The F34 package works. Strange. However, I think the /var/lib/spamassassin problem persists.

drwxr-xr-x.  3 root         spampd       22 Aug 11 08:20 spamassassin

This originally was root:root. I do not know where any bayes files trained reside, but I believe it is in /var/lib/spamassassin. So, I think the solution may be to have a group spamassassin that has rw on /var/lib/spamassassin and full read on /etc/mail/spamassassin. I guess this should be filed as a spamassassin bug?

sa-update does this in /var/lib/spamassassin
drwx------. 3 root root 73 Aug 18 03:29 3.004006

So, that solution may not work.

I think those directories are 755 on my machine. I also have sa-update running. I don't remember customising anything, but I could be wrong. These things have been there for a long time.

I'll have to fire up a clean VM and double check.

For me these are fresh installs. The hard drive hosting several VMs died about three weeks ago. I had been keeping dspam working for various reasons, but no more. So, these are as packaged unless something funny is going on.

This is strange...

Aug 18 03:44:00 HOST spampd[251823]: config: path "/var/lib/spamassassin/3.004006/languages" is inaccessible: Permission denied
Aug 18 03:44:00 HOST spampd[251823]: config: registryboundaries: no tlds defined, need to run sa-update
Aug 18 03:44:00 HOST spampd[251823]: config: path "/var/lib/spamassassin/3.004006/triplets.txt" is inaccessible: Permission denied

languages but not triplets is found one level deeper in updates_spamassassin_org

Aug 18 03:38:56 HOST spampd[126867]: plugin: eval failed: bayes: (in learn) locker: safe_lock: cannot create tmp lockfile /var/spool/spamassassin/spampd/bayes.lock.HOST.126867 for /var/spool/spamassassin/spampd/bayes.lock: No such file or directory

Yes, /var/spool/spamassassin wasn't created by spamassassin rpm.

I just tried this on a fresh VM. The /var/lib/spamassassin and directories underneath were created with 755 permissions, so I did not see above errors. But, I only started spampd - didn't actually use it for anything. I guess the errors related to the lock file are probably the result of trying to learn spam.

The sa-update script does need SELinux policy like this, however:
-----
require {
                type admin_home_t;
                type systemd_unit_file_t;
                type spamd_update_t;
                type init_t;
                class dir write;
                class service start;
                class file getattr;
                class system status;
}
 
#============= spamd_update_t ==============
allow spamd_update_t admin_home_t:dir write;
allow spamd_update_t init_t:system status;
allow spamd_update_t systemd_unit_file_t:file getattr;
allow spamd_update_t systemd_unit_file_t:service start;
-----

So, that is something that will need to be fixed in spamassassin, I guess.

What I did notice is that perl(Net::Server) did not get pulled in as a dependency for spampd. So, I will have to add this and rebuild.

Yes, /var/lib/spamassassin is correct. However, please look below that, especially after sa-update. Those are 700.

On my VM, these were also 755 after sa-update.service ran.

I stand utterly corrected. The problem is if you run sa-update directly all permissions are wrong. If you use the service file, things are ok.

I am still seeing this.

plugin: eval failed: bayes: (in learn) locker: safe_lock: cannot create tmp lockfile /var/spool/spamassassin/spampd/bayes.lock.*

I look into that as well. Maybe lock file in the wrong place or something like that.

Thank you for testing!

Looks like this may have something to do with --homedir option, which is new in 2.40. I'll have to dig into the code to find out what happens exactly, but I would not be surprised to see that lock file created there.

FEDORA-2021-b9ca679007 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b9ca679007

FEDORA-2021-93cf007a83 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-93cf007a83

FEDORA-2021-b9ca679007 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b9ca679007`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b9ca679007

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-93cf007a83 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-93cf007a83`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-93cf007a83

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I do not have /var/spool/spamassassin on my brand new VM at all, so I am not getting these lock errors. I tried sending some mail through Postfix with spampd checking for spam and I see SpamAssassin headers added. Strace is showing spampd processed doing things. Not quite sure how to replicate this.

I do not have that directory either. As stated, this system is rebuilt recently (fresh install). I am testing the update.

The lock file errors - are they just debugging messages? Or do you get spamassassin failures?

I haven't yet tried relearning anything (bayes), due to the fact I am just changing over from dspam.. But a locking error there will lead to corruption. Did the homedir setting end up changing anything?

I haven't tried that option, but I would think that you should create those directories where lock files should go, with appropriate ownership and permissions first. If that is indeed what the leaning code wants to use.

      userstate_dir        =>
        '/var/spool/spamassassin/spampd',         # home directory for SA files and plugins (--homedir option)

Since this is not in package (/var/spool/spamassassin) and we do have /var/spool/spampd, can /etc/sysconfig/spampd be updated to use --homedir"?

I mean in package.

Yeah, probably. When I'm online tomorrow, I'll build -3 with that and you can give it a try. If you override locally now, you should be able to test without a new package as well.

The change to /etc/sysconfig/spampd described above solves the issue. Thank you.

FEDORA-2021-b9ca679007 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b9ca679007

FEDORA-2021-93cf007a83 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-93cf007a83

FEDORA-2021-b9ca679007 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b9ca679007`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b9ca679007

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

This solves it. Thank you.

FEDORA-2021-93cf007a83 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-93cf007a83`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-93cf007a83

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-b9ca679007 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-93cf007a83 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.