CentOS - Jan 2019 - Mail server with both postfix and sendmail installed, active MTA gets switched.

Ok, so a bit of a long subject line there...

I'm running an email server using postfix, but a critical third-party 
package being used requires 'sendmail' the package.? No, I can't 
uninstall that package, please don't suggest that, and I don't have 
control of its requires.? So both postfix and sendmail are installed, 
and that's just the way it has to be.? Amavisd-new and clamav/clamd, 
from EPEL are also installed.

I have had updates twice now switch the active MTA to sendmail, and I 
have to manually 'systemctl disable sendmail; systemctl stop sendmail' 
and 'systemctl enable postfix;systemctl start postfix' afterwards.? I am
trying to find out what package update caused this to switch; or which 
logfile to look at to show me the systemctl messages that show the 
enable/disable sequence and points me to the correct package to file the 
bug against.

The packages updated today when this happened were:
# cat /var/log/yum.log
Jan 04 16:42:47 Updated: clamav-filesystem-0.101.0-1.el7.noarch
Jan 04 16:42:48 Updated: clamav-lib-0.101.0-1.el7.x86_64
Jan 04 16:42:48 Updated: clamav-update-0.101.0-1.el7.x86_64
Jan 04 16:42:48 Updated: clamd-0.101.0-1.el7.x86_64
Jan 04 16:42:48 Updated: clamav-server-systemd-0.101.0-1.el7.x86_64
Jan 04 16:42:48 Updated: clamav-scanner-systemd-0.101.0-1.el7.x86_64
Jan 04 16:42:49 Updated: clamav-0.101.0-1.el7.x86_64
Jan 04 16:42:54 Updated: clamav-data-0.101.0-1.el7.noarch
Jan 04 16:42:55 Updated: python2-certbot-apache-0.29.1-1.el7.noarch
#
Sendmail hasn't had updated packages in a long time, since August 2017.? 
None of the package scriptlets from the above packages look like they 
would affect the sendmail setup.? So, I'm looking for suggestions on 
where to start looking for the data to ferret this out; no clues are in 
/var/log/messages or /var/log/yum.log.

On 1/4/19 8:29 PM, Lamar Owen wrote:
> I have had updates twice now switch the active MTA to sendmail, and I 
> have to manually 'systemctl disable sendmail; systemctl stop
sendmail'
> and 'systemctl enable postfix;systemctl start postfix' afterwards.

Run "systemctl mask sendmail" as well.? That should permanently
disable
the service.

> I am trying to find out what package update caused this to switch; or 
> which logfile to look at to show me the systemctl messages that show 
> the enable/disable sequence and points me to the correct package to 
> file the bug against.

You could look for any package that refers to sendmail in a script or 
trigger:

rpm -qa | while read pkg
do
 ? rpm -q --scripts --triggers "$pkg" | grep -q sendmail &&
echo "$pkg"
done

> Sendmail hasn't had updated packages in a long time, since August 
> 2017. None of the package scriptlets from the above packages look like 
> they would affect the sendmail setup.? So, I'm looking for suggestions 
> on where to start looking for the data to ferret this out; no clues 
> are in /var/log/messages or /var/log/yum.log. 

If the problem is a trigger on the sendmail package, it could run 
without any changes to the sendmail package itself.

On 1/5/19 2:18 AM, Gordon Messmer wrote:
> On 1/4/19 8:29 PM, Lamar Owen wrote:
>> I have had updates twice now switch the active MTA to sendmail, and I 
>> have to manually 'systemctl disable sendmail; systemctl stop 
>> sendmail' and 'systemctl enable postfix;systemctl start
postfix'
>> afterwards.
> Run "systemctl mask sendmail" as well.? That should permanently 
> disable the service.
Worthwhile thing to do; still curious about what caused it, but if this 
will lock it out.....
>
>> I am trying to find out what package update caused this to switch; or 
>> which logfile to look at to show me the systemctl messages that show 
>> the enable/disable sequence and points me to the correct package to 
>> file the bug against.
> ...
> If the problem is a trigger on the sendmail package, it could run 
> without any changes to the sendmail package itself.
Ah, yes, indeed. Only three packages are output: sendmail itself, 
postfix, and the third party software; postfix did get an update 
recently, and after checking to see I didn't reboot after that update.? 
And the postfix scriptlets do twiddle with alternatives, using the 
--initscripts command to alternatives; and this is what I believe did me in.

So, it seems as part of my setup that I failed to set the alternatives 
properly, and that has been corrected, as well as setting 'systemctl 
mask sendmail' so we'll see how that rides...

Thanks, Gordon!