Description of problem: In order to integrate with mail framework /usr/lib/tmpfiles.d/clamd.scan.conf has been updated to use different owner and group, but as it isn't noted as a config file in the rpm spec file, this update gets overwritten with every rpm update .. which is a regular occurrence. Version-Release number of selected component (if applicable): 0.102.2-4.el7.x86_64 How reproducible: Every update Steps to Reproduce: 1. change the owner and group in /usr/lib/tmpfiles.d/clamd.scan.conf 2. change the permissions of /run/clamd.scan to match 3. run an update Actual results: The conf file changes back, causing problems at reboot Expected results: The conf file remains as it is with the new permissions intact Additional info: The practical effect is that the mail framework can no longer talk to the clamd daemon and the mail pipeline stalls.
See "Configuration Directories and Precedence" in https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html Place your local custom config in /etc/tmpfiles.d/clamd.scan.conf.
I implemented the fix as above by adding a new file at /etc/tmpfiles.d/clamd.scan.conf This worked for a while until the next update, when the fact that "/run/clamd.scan" is part of the rpm package as well as having the tmpfile.d config file became significant. The directory reference in the rpm also hardwires the wrong (for me) permissions. The upshot was that clamd became inaccessible again and permission errors were thrown at restart. This jams up the mail server.
Ah, interesting. We might be able to work around this by invoking systemd-tmpfiles in %post - but honestly you might be better off by defining your own clamd instance.
FYI - I face the same issue as well and have worked around it locally by running an ansible playbook after upgrades. But I may just take my own advice above if I can't figure out a way to deal with this.
from https://src.fedoraproject.org/rpms/clamav/blob/master/f/clamav.spec#_585 [1] I wonder if `%ghost %dir %attr(0710,%scanuser,virusgroup) %scanstatedir` is incorrect and should be just `%ghost %dir %scanstatedir` ? [1] %files -n clamd (...) %ghost %scanstatedir/clamd.sock %if %{with tmpfiles} %_tmpfilesdir/clamd.scan.conf %ghost %dir %attr(0710,%scanuser,virusgroup) %scanstatedir %else %dir %attr(0710,%scanuser,virusgroup) %scanstatedir %endif
Not sure why I'm being cc'd here. I reported bug 1840725. Is there a connection?
https://bugzilla.redhat.com/show_activity.cgi?id=1821973
My propose https://src.fedoraproject.org/rpms/clamav/pull-request/17
FEDORA-2021-bfc4af9c9c has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-bfc4af9c9c
FEDORA-2021-47655cb90e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-47655cb90e
FEDORA-EPEL-2021-90fc336455 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-90fc336455
I think not running /bin/systemd-tmpfiles --create %_tmpfilesdir/clamd.scan.conf on post can fix this bug [1] please test it, thank you. [1] https://src.fedoraproject.org/rpms/clamav/c/7f94084fd5c606f94c20c0aff0c0d0fc19b404dc?branch=rawhide
FEDORA-EPEL-2021-c3dde95087 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c3dde95087
FEDORA-2021-bfc4af9c9c 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-bfc4af9c9c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-bfc4af9c9c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-47655cb90e 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-47655cb90e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-47655cb90e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-90fc336455 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-90fc336455 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-c3dde95087 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c3dde95087 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-47655cb90e has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-bfc4af9c9c has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2021-568f2e4092 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-568f2e4092 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-01e7b83241 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-01e7b83241 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-568f2e4092 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2021-01e7b83241 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.