Currently, Enterprise Linux 7 deployments may run in to the following problem:
# systemctl enable clamd@amavisd.service The unit files have no [Install] section. They are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...).
This is an issue with a package originating from EPEL, for which a solution is unclear and not available in the foreseeable future.
Rather, we can make PyKolab's setup-kolab read in /lib/systemd/system/clamd\@.service, see if there's an [Install] section, and otherwise write out a copy to /etc/systemd/system/clamd\@.service that has the necessary corrections, before issuing a systemctl enable clamd@amavisd.service.
Functionally, not starting ClamAV has two possible consequences:
- No mail passes through Amavis
- No virus scanning is applied
Implementation Design Considerations
- A system may or may not use systemd.
- A dependency under the kolab-mta sub-package is responsible for pulling in either clamav-server-systemd or clamav-server-sysvinit.
The eligibility for clamav-server-sysvinit to not start clamd@amavisd successfully has not been determined.