Description of problem: After installing the sendmail-cf-8.13.8-8.1.el5_7 packages thru yum it generates a new sendmail.cf in /etc/mail. Due to the installation of the sendmail package sendmail will be restarted as well. Version-Release number of selected component (if applicable): Red Hat Enterprise Linux Server release 5.7 (Tikanga) How reproducible: not tested Steps to Reproduce: 1. create custom /etc/mail/sendmail.cf 2. install sendmail-cf-8.13.8-8.1.el5 3. check /etc/mail/sendmail.cf Actual results: 1. Updated /etc/mail/sendmail.cf 2. sendmail no longer accepting mail Expected results: 1. /etc/mail/sendmail.cf should have been unchanged. Additional info:
I am unable to reproduce. Please note, the sendmail-cf package doesn't replace, nor contain the sendmail.cf. I used the following steps: # rpm -q sendmail sendmail-cf sendmail-8.13.8-8.1.el5_7 package sendmail-cf is not installed # rpm -qV sendmail # sed -i '/^O SmtpGreetingMessage=/ s/Sendmail/Sendmail-Test/' /etc/mail/sendmail.cf # rpm -qV sendmail S.5....T c /etc/mail/sendmail.cf # md5sum /etc/mail/sendmail.cf a05bc32796a3bdc67a04646cf71a6c66 /etc/mail/sendmail.cf # yum -q install -y sendmail-cf # rpm -q sendmail-cf sendmail-cf-8.13.8-8.1.el5_7 # md5sum /etc/mail/sendmail.cf a05bc32796a3bdc67a04646cf71a6c66 /etc/mail/sendmail.cf Maybe what happened there: timestamp of your sendmail.cf was older than timestamp of your sendmail.mc (i.e. your customized sendmail.mc was newer than your customized sendmail.cf). After installation of sendmail-cf and sendmail restart, your sendmail.cf was regenerated to match your sendmail.mc. Do you have more info/reproducer?
Starting situation: [root@zuckuss mail]# ls -la sendmail.* -rw-r--r-- 1 root root 58784 Dec 14 2010 sendmail.cf -rw-r--r-- 1 root root 7205 Jul 28 09:56 sendmail.mc .mc is indeed newer than the .cf file. [root@zuckuss mail]# rpm --force -ivh ~leonb/sendmail-8.13.8-8.1.el5_7.x86_64.rpm Preparing... ########################################### [100%] 1:sendmail ########################################### [100%] [root@zuckuss mail]# service sendmail restart Shutting down sm-client: [ OK ] Shutting down sendmail: [ OK ] Starting sendmail: [ OK ] Starting sm-client: [ OK ] [root@zuckuss mail]# ls -la sendmail.* -rw-r--r-- 1 root root 58265 Aug 17 13:05 sendmail.cf -rw-r--r-- 1 root root 58784 Dec 14 2010 sendmail.cf.bak -rw-r--r-- 1 root root 7205 Jul 28 09:56 sendmail.mc And we have the problem. Probably due to the presence of the -cf package the sendmail package succeeeds in building the sendmail.cf file. Because on other severs which don't have the sendmail-cf package. The sendmail.cf wasn't overwritten. I do however think this new sendmail.cf should have been named sendmail.cf.rpmnew or something. I don't think the sendmail package up until now did replace the sendmail.cf for me.
Thanks for info. Please note the behaviour is the same as in older versions of sendmail, nothing was changed. The functionality is coded in sendmail initscript and it works the following way: before start of sendmail it checks if the sendmail.mc needs rebuild. If so, it checks if there is sendmail-cf installed. If not, it write message that the sendmail-cf is needed for rebuild and nothing is changed. If the sendmail-cf if installed it builds sendmail.cf from sendmail.mc. The previous sendmail.cf is saved as sendmail.cf.bak thus your old config is backed up and can be restored. This thing is not handled by rpm, thus the rpmnew suffix is not good idea here. On default installation the sendmail.cf is newer than sendmail.mc, thus there is no rebuild. If you change only sendmail.cf, there is also no rebuild. I think that in your installation there have to be some inter-mixed edits/updates/copy(remote) of sendmail.cf/sendmail.mc (or clock skew during copy) that ends up in newer sendmail.mc. I think there is nothing to fix.
Closing as NOTABUG according to previous comments.
(In reply to comment #4) > Closing as NOTABUG according to previous comments. I disagree with the NOTABUG classification, and agree with the original reporter. sendmail.cf is a configuration file. Customized configuration files should not be overwritten by an upgrade. I typically build (or built, before this upgrade) my .cf files using the 'Build' script in /usr/share/sendmail-cf/cf, copying the result into /etc/mail/sendmail.cf I've been doing that for a number of years. The changes made in this package make that very difficult. I'm very sure this is new and undesired behavior.
(In reply to comment #5) >Customized configuration files should not be overwritten by an upgrade. > It is not overwritten by an upgrade. It is overwritten during sendmail restart because your mc (m4 source) file is newer than your cf (target conf) file. It is because your timestamps are somehow corrupted/non-consistent. It doesn't occur if your timestamps are consistent (on all our testing systems). Even so in such non-standard cases your old cf file is never lost, it is backed-up with the .bak suffix. >I'm very sure this is new and undesired behavior. > AFAIK it is really not new. See the attached diff, nothing relevant was changed. AFAIK it has been implemented this way for a long time.
Created attachment 522706 [details] Diff between sendmail-8.13.8-8 and sendmail-8.13.8-8.1
You may be right about the timing. I might be able to recreate a history for /etc/mail/sendmail.mc changes (which I think may have caused the sendmail.cf change), but it probably wouldn't be worth the time. The difference between "overwritten by an upgrade" and "overwritten during sendmail restart" (which is caused by an upgrade) is not a distinction worth discussing. (I appreciate the .bak though.) My comments are simply the result of two facts: 1) The RHEL5 Deployment Guide (section 11.1) states: "Configuration files in packages are preserved across upgrades, so you do not lose your customizations." 2) /etc/mail/sendmail.cf is reported as a configuration file by 'rpm -qic sendmail'. I've fixed my installations so that (I hope) this upgrade behavior won't break things here in the future. So it's not a huge issue with me. But you might want to check whether your understanding of the way things should work is the same as other Red Hat package maintainers.
(In reply to comment #8) > You may be right about the timing. I might be able to recreate a history for > /etc/mail/sendmail.mc changes (which I think may have caused the sendmail.cf > change), but it probably wouldn't be worth the time. > Your system was mis-configured. This behaviour is there at least since RHEL-4 (maybe longer). > The difference between "overwritten by an upgrade" and "overwritten during > sendmail restart" (which is caused by an upgrade) is not a distinction worth > discussing. (I appreciate the .bak though.) > But it is technically correct, you will get into the same situation after reboot. > My comments are simply the result of two facts: > > 1) The RHEL5 Deployment Guide (section 11.1) states: "Configuration files in > packages are preserved across upgrades, so you do not lose your > customizations." > > 2) /etc/mail/sendmail.cf is reported as a configuration file by 'rpm -qic > sendmail'. > Also please check the Deployment Guide section 25.3.1.2: <snip> Sendmail's lengthy and detailed configuration file is /etc/mail/sendmail.cf. Avoid editing the sendmail.cf file directly. To make configuration changes to Sendmail, edit the /etc/mail/sendmail.mc file, back up the original /etc/mail/sendmail.cf, and use the following alternatives to generate a new configuration file </snip> And I add: Do not edit sendmail.cf, then sendmail.mc, install sendmail-cf and then complain that your sendmail.cf was regenerated upon sendmail restart. I am open to any improvements, but sorry, I have no idea how to re-implement this time-proven solution better - the sendmail.cf needs to be conditionally regenerated on restart.