Bug 1196342 - sendmail.mc is overwritten by sendmail after patching
Summary: sendmail.mc is overwritten by sendmail after patching
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sendmail
Version: 5.11
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jaroslav Škarvada
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-25 18:26 UTC by Stephen Murray
Modified: 2015-02-26 15:46 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-26 15:46:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Stephen Murray 2015-02-25 18:26:32 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Stephen Murray 2015-02-25 18:35:17 UTC
Description of problem: Updating from sendmail-8.13.8-8.el5 to sendmail-8.13.8-8.1.el5_7 results in sendmail.mc being overwritten. We had a customized version that the update destroyed. Upon restart of sendmail service, the associated sendmail.cf file was regenerated due to changed dates of the sendmail.mc file. The result was a broken sendmail.cf which was missing all of our customization. Ironically, the upgrade did save a copy of the original sendmail.cf but did NOT save a copy of the original sendmail.mc. If it is going to save anything, then sendmail.mc is correct. It is my opinion that a patch upgrade should never erase or replace an existing customized configuraion file.


Version-Release number of selected component (if applicable):
sendmail-8.13.8-8.1.el5_7 

How reproducible:
Create a sendmail.mc file using the old version then update to the new version.

Steps to Reproduce:
1.
2.
3.

Actual results:
sendmail.mc replaced with no backup.

Expected results:
Either do not replace sendmail.mc, or at least save it before erasing it.

Additional info:
Using a symlink for sendmail.mc instead of an actual file (eg ln -s somefile /etc/mail/sendmail.mc) works. The real data is not wiped out.

Comment 2 Jaroslav Škarvada 2015-02-26 14:13:04 UTC
This shouldn't happen, there is noreplace in the spec for both /etc/mail/sendmail.mc and /etc/mail/sendmail.cf, thus the distro sendmail.mc should be installed as /etc/mail/sendmail.mc.rpmnew and the old versions of the sendmail.mc should be preserved.

Comment 3 Stephen Murray 2015-02-26 14:28:12 UTC
Perhaps it "shouldn't happen", but it does. I reran the update, here are the results:

[root@benfcmtsl01 mail]# date
Thu Feb 26 09:20:01 EST 2015
[root@benfcmtsl01 mail]# rpm -qa | grep sendmail
sendmail-8.13.8-8.el5
sendmail-cf-8.13.8-8.el5
[root@benfcmtsl01 mail]# service sendmail status
sendmail (pid  3752) is running...
[root@benfcmtsl01 mail]# ls -al
total 276
drwxr-xr-x  2 root root  4096 Feb 26 09:19 .
drwxr-xr-x 96 root root 12288 Feb 25 04:02 ..
-rw-r--r--  1 root root   355 Jan 22  2010 access
-rw-r-----  1 root root 12288 Feb 26 09:16 access.db
-rw-r--r--  1 root root     0 Jan 22  2010 domaintable
-rw-r-----  1 root root 12288 Feb 26 09:16 domaintable.db
-rw-r--r--  1 root root  5521 Jan 22  2010 helpfile
-rw-r--r--  1 root root    64 Jan 22  2010 local-host-names
-rw-r--r--  1 root root     0 Jan 22  2010 mailertable
-rw-r-----  1 root root 12288 Feb 26 09:16 mailertable.db
-rw-r--r--  1 root root  1048 Jan 22  2010 Makefile
-rw-r--r--  1 root root 58914 Mar 13  2011 sendmail.cf
-rw-r--r--  1 root root  7205 Jan 22  2010 sendmail.mc
-r--r--r--  1 root root 41379 Jan 22  2010 submit.cf
-rw-r--r--  1 root root   940 Jan 22  2010 submit.mc
-rwxr-xr-x  1 root root   773 Feb 24 13:05 testme.sh
-rw-r--r--  1 root root   127 Jan 22  2010 trusted-users
-rw-r--r--  1 root root     0 Jan 22  2010 virtusertable
-rw-r-----  1 root root 12288 Feb 26 09:16 virtusertable.db
[root@benfcmtsl01 mail]# yum -y update sendmail sendmail-cf
Loaded plugins: downloadonly, rhnplugin, security
This system is receiving updates from RHN Classic or RHN Satellite.
Skipping security plugin, no data
Setting up Update Process
Resolving Dependencies
Skipping security plugin, no data
--> Running transaction check
---> Package sendmail.i386 0:8.13.8-8.1.el5_7 set to be updated
---> Package sendmail-cf.i386 0:8.13.8-8.1.el5_7 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package          Arch      Version               Repository               Size
================================================================================
Updating:
 sendmail         i386      8.13.8-8.1.el5_7      rhel-i386-server-5      624 k
 sendmail-cf      i386      8.13.8-8.1.el5_7      rhel-i386-server-5      306 k

Transaction Summary
================================================================================
Install       0 Package(s)
Upgrade       2 Package(s)

Total download size: 930 k
Downloading Packages:
(1/2): sendmail-cf-8.13.8-8.1.el5_7.i386.rpm             | 306 kB     00:00     
(2/2): sendmail-8.13.8-8.1.el5_7.i386.rpm                | 624 kB     00:00     
--------------------------------------------------------------------------------
Total                                           294 kB/s | 930 kB     00:03     
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating       : sendmail                                                 1/4 
warning: /etc/mail/sendmail.cf created as /etc/mail/sendmail.cf.rpmnew
  Updating       : sendmail-cf                                              2/4 
  Cleanup        : sendmail-cf                                              3/4 
  Cleanup        : sendmail                                                 4/4 

Updated:
  sendmail.i386 0:8.13.8-8.1.el5_7      sendmail-cf.i386 0:8.13.8-8.1.el5_7     

Complete!
[root@benfcmtsl01 mail]# date
Thu Feb 26 09:21:13 EST 2015
[root@benfcmtsl01 mail]# rpm -qa | grep sendmail
sendmail-8.13.8-8.1.el5_7
sendmail-cf-8.13.8-8.1.el5_7
[root@benfcmtsl01 mail]# ls -al
total 412
drwxr-xr-x  2 root root  4096 Feb 26 09:21 .
drwxr-xr-x 96 root root 12288 Feb 25 04:02 ..
-rw-r--r--  1 root root   355 Jul 28  2011 access
-rw-r-----  1 root root 12288 Feb 26 09:21 access.db
-rw-r--r--  1 root root     0 Jul 28  2011 domaintable
-rw-r-----  1 root root 12288 Feb 26 09:21 domaintable.db
-rw-r--r--  1 root root  5521 Jul 28  2011 helpfile
-rw-r--r--  1 root root    64 Jul 28  2011 local-host-names
-rw-r--r--  1 root root     0 Jul 28  2011 mailertable
-rw-r-----  1 root root 12288 Feb 26 09:21 mailertable.db
-rw-r--r--  1 root root  1048 Jul 28  2011 Makefile
-rw-r--r--  1 root root 58270 Feb 26 09:21 sendmail.cf
-rw-r--r--  1 root root 58914 Mar 13  2011 sendmail.cf.bak
-rw-r--r--  1 root root 58298 Jul 28  2011 sendmail.cf.rpmnew
-rw-r--r--  1 root root  7205 Jul 28  2011 sendmail.mc
-r--r--r--  1 root root 41379 Jul 28  2011 submit.cf
-rw-r--r--  1 root root   940 Jul 28  2011 submit.mc
-rwxr-xr-x  1 root root   773 Feb 24 13:05 testme.sh
-rw-r--r--  1 root root   127 Jul 28  2011 trusted-users
-rw-r--r--  1 root root     0 Jul 28  2011 virtusertable
-rw-r-----  1 root root 12288 Feb 26 09:21 virtusertable.db
[root@benfcmtsl01 mail]# 

As you can see, the update saves the sendmail.cf file (sendmail.cf.rpmnew) but not the sendmail.mc file. And it replaces the original sendmail.mc file, wiping out all customization in the process. Thanks to the date change, "service sendmail start" following patching determines that the sendmail.mc file is more recent than the sendmail.cf file and reruns "m4" to rebuild sendmail.cf, resulting in a destroyed sendmail.cf too.

The sendmail.mc file is replaced, which is bad, but if the original sendmail.cf file had a date newer than July 28th 2011 then it wasn't regenerated, so the problem is not always evident.

Comment 4 Stephen Murray 2015-02-26 14:56:22 UTC
I have determined what happened to us. The root cause is that the original sendmail.mc was not used to generate the in-use sendmail.cf. 

On certain servers we keep the customized sendmail.mc file in a separate configuration directory. The "m4" command is run from there, and the resulting sendmail.cf file is then copied into /etc/mail, leaving the original /etc/mail/sendmail.mc file intact.

Your note regarding "there is noreplace in the spec for both /etc/mail/sendmail.mc and /etc/mail/sendmail.cf" prompted me to retest the update, but this time copying the actual sendmail.mc and sendmail.cf files into /etc/mail. Under this scenario, the update worked as expected, the sendmail.mc file was NOT replaced, the sendmail.cf file was retained and the rpm copy was loaded as sendmail.cf.rpmnew.

I would flag this as "user configuration error" in that the sendmail.cf and sendmail.cf files in use in /etc/mail should be a matched pair.

Thank you for your help with this, your comments did help me find the true error.

Please close this case.

Comment 5 Stephen Murray 2015-02-26 15:08:23 UTC
FYI. Here is the update test when /etc/mail is configured correctly. It didn't create a sendmail.mc.rpmnew, but I am not concerned about that:

[root@benfcmtsl01 mail]# date
Thu Feb 26 09:46:55 EST 2015
[root@benfcmtsl01 mail]# rpm -qa | grep sendmail
sendmail-cf-8.13.8-8.el5
sendmail-8.13.8-8.el5
[root@benfcmtsl01 mail]# service sendmail status
sendmail (pid  4441) is running...
[root@benfcmtsl01 mail]# ls -al
total 276
drwxr-xr-x  2 root root  4096 Feb 26 09:46 .
drwxr-xr-x 96 root root 12288 Feb 25 04:02 ..
-rw-r--r--  1 root root   355 Jan 22  2010 access
-rw-r-----  1 root root 12288 Feb 26 09:44 access.db
-rw-r--r--  1 root root     0 Jan 22  2010 domaintable
-rw-r-----  1 root root 12288 Feb 26 09:44 domaintable.db
-rw-r--r--  1 root root  5521 Jan 22  2010 helpfile
-rw-r--r--  1 root root    64 Jan 22  2010 local-host-names
-rw-r--r--  1 root root     0 Jan 22  2010 mailertable
-rw-r-----  1 root root 12288 Feb 26 09:44 mailertable.db
-rw-r--r--  1 root root  1048 Jan 22  2010 Makefile
-rw-r--r--  1 root root 58914 Mar 13  2011 sendmail.cf
-rw-r--r--  1 root root  7202 Mar 13  2011 sendmail.mc
-r--r--r--  1 root root 41379 Jan 22  2010 submit.cf
-rw-r--r--  1 root root   940 Jan 22  2010 submit.mc
-rwxr-xr-x  1 root root   773 Feb 24 13:05 testme.sh
-rw-r--r--  1 root root   127 Jan 22  2010 trusted-users
-rw-r--r--  1 root root     0 Jan 22  2010 virtusertable
-rw-r-----  1 root root 12288 Feb 26 09:44 virtusertable.db
[root@benfcmtsl01 mail]# yum update sendmail sendmail-cf
Loaded plugins: downloadonly, rhnplugin, security
This system is receiving updates from RHN Classic or RHN Satellite.
Skipping security plugin, no data
Setting up Update Process
Resolving Dependencies
Skipping security plugin, no data
--> Running transaction check
---> Package sendmail.i386 0:8.13.8-8.1.el5_7 set to be updated
---> Package sendmail-cf.i386 0:8.13.8-8.1.el5_7 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package          Arch      Version               Repository               Size
================================================================================
Updating:
 sendmail         i386      8.13.8-8.1.el5_7      rhel-i386-server-5      624 k
 sendmail-cf      i386      8.13.8-8.1.el5_7      rhel-i386-server-5      306 k

Transaction Summary
================================================================================
Install       0 Package(s)
Upgrade       2 Package(s)

Total download size: 930 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): sendmail-cf-8.13.8-8.1.el5_7.i386.rpm             | 306 kB     00:00     
(2/2): sendmail-8.13.8-8.1.el5_7.i386.rpm                | 624 kB     00:00     
--------------------------------------------------------------------------------
Total                                           1.0 MB/s | 930 kB     00:00     
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating       : sendmail                                                 1/4 
warning: /etc/mail/sendmail.cf created as /etc/mail/sendmail.cf.rpmnew
  Updating       : sendmail-cf                                              2/4 
  Cleanup        : sendmail-cf                                              3/4 
  Cleanup        : sendmail                                                 4/4 

Updated:
  sendmail.i386 0:8.13.8-8.1.el5_7      sendmail-cf.i386 0:8.13.8-8.1.el5_7     

Complete!
[root@benfcmtsl01 mail]# date
Thu Feb 26 09:47:34 EST 2015
[root@benfcmtsl01 mail]# rpm -qa | grep sendmail
sendmail-cf-8.13.8-8.1.el5_7
sendmail-8.13.8-8.1.el5_7
[root@benfcmtsl01 mail]# service sendmail status
sendmail (pid  4527) is running...
[root@benfcmtsl01 mail]# ls -al
total 344
drwxr-xr-x  2 root root  4096 Feb 26 09:47 .
drwxr-xr-x 96 root root 12288 Feb 25 04:02 ..
-rw-r--r--  1 root root   355 Jul 28  2011 access
-rw-r-----  1 root root 12288 Feb 26 09:47 access.db
-rw-r--r--  1 root root     0 Jul 28  2011 domaintable
-rw-r-----  1 root root 12288 Feb 26 09:47 domaintable.db
-rw-r--r--  1 root root  5521 Jul 28  2011 helpfile
-rw-r--r--  1 root root    64 Jul 28  2011 local-host-names
-rw-r--r--  1 root root     0 Jul 28  2011 mailertable
-rw-r-----  1 root root 12288 Feb 26 09:47 mailertable.db
-rw-r--r--  1 root root  1048 Jul 28  2011 Makefile
-rw-r--r--  1 root root 58914 Mar 13  2011 sendmail.cf
-rw-r--r--  1 root root 58298 Jul 28  2011 sendmail.cf.rpmnew
-rw-r--r--  1 root root  7202 Mar 13  2011 sendmail.mc
-r--r--r--  1 root root 41379 Jul 28  2011 submit.cf
-rw-r--r--  1 root root   940 Jul 28  2011 submit.mc
-rwxr-xr-x  1 root root   773 Feb 24 13:05 testme.sh
-rw-r--r--  1 root root   127 Jul 28  2011 trusted-users
-rw-r--r--  1 root root     0 Jul 28  2011 virtusertable
-rw-r-----  1 root root 12288 Feb 26 09:47 virtusertable.db
[root@benfcmtsl01 mail]#

Comment 6 Jaroslav Škarvada 2015-02-26 15:46:54 UTC
Ok, thanks for info, closing per comment 4.


Note You need to log in before you can comment on or make changes to this bug.