Jeff Johnson wrote:
On Sep 27, 2007, at 3:28 PM, Steven Stromer wrote:
Hi,
This question was asked in comp.mail.sendmail back in 2003, but was
never fully resolved. Since it refers to an rpm specific update, I'll
ask here.
I just updated sendmail using yum, and found a sendmail.cf.rpmnew
file. There are numerous changes in this .cf file that seem important,
but they will certainly be overwritten the next time the sendmail
service restarts and the .mc file is processed.
Are we expected to search our existing .mc files, and make them match
the newest changes from the sendmail.cf.rpmnew file? I don't even
believe that all of the changes could be made to match by revising the
.mc file alone.
Basically yes.
Wouldn't it make so much more sense for both new sendmail.cf.rpmnew
and a sendmail.mc.rpmnew files to have been distributed? Apologies if
this is a well documented faq that I missed in my search. My hopes are
that this is just a packaging error.
I can try to describe what is happening, but have little to say about
"sensible" or "packaging flaw".
rpm tries very hard not to clobber locally modified configuration files
on upgrade. This is done by marking files in packages with %config
and/or %config(noreplace).
There are two basic resolutions when upgrading modified configuration
files:
1) Rename the old file, and replace the file with new content.
FIles marked "%config" in *.rpm packages will have this behavior.
A modified file will be renamed (with extension .rpmsave iirc), and
the file is replace.
2) Keep the old file exactly as is, but save the new file next to the old.
FIles marked "%config(noreplace)" in *.rpm packages will have this
behavior, the new file is installed with extension ".rpmnew".
Its up to the system administrator to merge the new changes.
That explains how the *.rpmnew files arrived.
You've pointed out Yet Another Flaw with the %config handling in rpm.
The sendmail.cf should be paired with a corresponding sendmail.mc file.
But when one file is modified and the other is not, then the pairing
after an
rpm upgrade is wrong.
73 de Jeff
Jeff and Jos,
Thank you both for replying. I am painfully aware of how rpm handles
non-matching files during the update process, as well as the manual task
that admins are expected to perform when rpmnew, rpmsave, etc. files
appear. In truth, I have scripts configured on a beta server that bring
these to my attention when they appear, so I can prepare for the updates
in advance. All the same, your explanations are extremely clear and useful.
The fact that in sendmail, the .mc file is used to generate the .cf file
makes this a whole different kind of issue. I have a hard time believing
that providing an updated version of a file that is generated by another
file, and not that other file, could have been intentional.
Unless I'm wrong, many of the revisions CAN'T be made by editing the .mc
file. We'd have to edit the m4 script, and various other sendmail
configuration files that it accesses. If these source files had all been
updated with the new revisions, and we were left to make only the
changes applicable to the .mc file, that would be fine, but I can see
that this is not the case.
Any ideas how to work around this?
Steven
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
