On Sun, Apr 20, 2014 at 6:39 PM, Lars Seipel <lars.seipel@xxxxxxxxx> 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.
--Andy
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
