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!
-
Gordon Messmer -
Lamar Owen