When a yum update sets up an MTA ...

Andrew Lutomirski luto at mit.edu
Mon Apr 21 01:44:53 UTC 2014

On Sun, Apr 20, 2014 at 6:39 PM, Lars Seipel <lars.seipel at gmail.com> wrote:
> Nicely aligning with the current firewall thread I noticed that one of
> my machines was running the exim MTA for the last few days, dutifully
> listening on all interfaces.
> How did this happen? It turns out that smartmontools intermittently
> required 'MTA' which (presumably due to its nice and short name) pulls
> in exim when there's no MTA already installed. This dependency was
> replaced (with a file dep on %{_sbindir}/sendmail) in
> smartmontools-6.2-5.fc20.
> Ok, that's how it got installed. But why does it get run? Is the
> installation of exim tricking my system into believing it's Debian?
> We do have the presets functionality[0] for this, I thought. And indeed,
> a call to systemctl preset disables exim.service just like it's supposed
> to do.
> Looking at exim's spec file shows its %post is using the proper
> systemd_post macro which honors presets. In %postun, though, there's a
> direct call to systemctl enable, buried in the sysv conversion stuff. Is
> it really supposed to be there? But this shouldn't get executed on
> package install anyway, right?
> Would be glad if someone who knows a bit more about the interaction of
> RPM and systemd preset files could chime in and tell me where the bug
> report should go.

I think it's because upgrading installs a new package and uninstalls
an old package.  Sounds like a bug in exim.

So far, I know that this issue exists, in some form, in rpcbind,
nfs-utils, and exim.  Would it
make sense to audit all spec files to look for instances of
'systemctl.*enable'?  If so, is there an easy way to grab all the spec
files?  Scraping pkgs.fedoraproject.org is a bit painful.


More information about the devel mailing list