sendmail.cf.rpmnew, but no sendmail.mc.rpmnew?

[Steven Stromer]

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.

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.

Thanks for all responses,
Steven Stromer

[Jos Vos]

Post by Steven Stromer
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.

There are never .rpmnew files distributed.

If a file that is marked as a config file with the noreplace option
(this is defined by the package builder) is different from the file
in the previous version of the packages, the following rule applies:

- If the file on the system was not modified (so, it's exactly the
same as the one of the previous version of the package), the file
is (silently) replaced by the new version.

- If the file on the system was modified, that file is left untouched
and the version included in the new package is stored with an
.rpmnew suffix.

I don't know if this explains this particular situation, maybe it's
also a packaging error, but if there is no .mc.rpmnew file this
either means the .mc file in the package didn't change or the
.mc file on the system was unchanged (or both).

[Jeff Johnson]

Post by Steven Stromer
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.

Post by Steven Stromer
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

[Steven Stromer]

Post by Jeff Johnson

Post by Steven Stromer
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.

Post by Steven Stromer
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
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

[Philip Prindeville]

Post by Steven Stromer

Post by Jeff Johnson

Post by Steven Stromer
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.

Post by Steven Stromer
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
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

I'm not sure there's an issue here.

The .mc file gets processed by m4 and pulls in a bunch of m4 "source"
files that then cause a new generated .cf file to be created.

Since people rarely modify the .m4 files, these get transparently
updated with no generated .rpmnew files.

The resultant .cf file, however, may clash with edits you've made.

Unless you've not made edits, in which case, "yes", the original .cf
file should have been replaced with the new .cf file. Is this not
happening?

If your .mc file hadn't been modified and neither had your .cf file,
then running "make sendmail.cf" will cause your sendmail.cf to be
regenerated... and agree with your sendmail.mc file, which should always
be the case anyway.

-Philip

[Steven Stromer]

Post by Philip Prindeville

Post by Steven Stromer
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.
Wouldn't it make so much more sense for both new sendmail.cf.rpmnew
and a sendmail.mc.rpmnew files to have been distributed?
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.
Steven

I'm not sure there's an issue here.
The .mc file gets processed by m4 and pulls in a bunch of m4 "source"
files that then cause a new generated .cf file to be created.
Since people rarely modify the .m4 files, these get transparently
updated with no generated .rpmnew files.

Agreed, so far.

Post by Philip Prindeville
The resultant .cf file, however, may clash with edits you've made.
Unless you've not made edits, in which case, "yes", the original .cf
file should have been replaced with the new .cf file. Is this not
happening?

My .cf file was not replaced by the new .cf file; thus, the birth of
this thread. It would seem to me the 'clash' you describe is not only
inevitable, but desirable, due to the fact that my .cf file, by
definition, contains the mail settings I entered via my .mc file.

Post by Philip Prindeville
If your .mc file hadn't been modified and neither had your .cf file,
then running "make sendmail.cf" will cause your sendmail.cf to be
regenerated... and agree with your sendmail.mc file, which should always
be the case anyway.

I fully understand and agree that the two files should 'agree', but I
don't see how this clarifies or explains the fact that I see minor, but
certainly differing, lines in the .rpmnew file that do not appear in the
.cf file that is presently generated when I regenerate the file.

Maybe the real question here should be where the differences I see
really stem from. It just seems logical to me that if a .cf file is
being included with a package update, it must be that it contains
elements that no other files can provide to it during a regeneration.

However, maybe this is where I am off base! Does the .cf file get
completely written from scratch by other files during its regeneration,
or is it simply edited during this process? If it is entirely dependent
on outside 'sources' for the entirely of its content, with every line
being entirely system-specific, then why include it with a package
update at all, instead of just letting the end user generate his or her
own .cf file?

As I write, I am beginning to believe that my confusion steps from this
single factor! Why include a .cf file in the package update, at all, if
the .cf file is supposed to reflect the system it is located on?

Suddenly, I begin to feel the clouds part, I contemplate the simplicity
of 'rm /etc/mail/sendmail.cf.rpmnew', and a smile forms on my face...

Can anyone confirm that I am finally seeing the light?

[Jeff Johnson]

Post by Steven Stromer
Suddenly, I begin to feel the clouds part, I contemplate the
simplicity of 'rm /etc/mail/sendmail.cf.rpmnew', and a smile forms
on my face...
Can anyone confirm that I am finally seeing the light?

If you are happy with your existing configuration using the upgraded
sendmail binaries, then
rm -f *.rpmnew
is exactly what you want to do.

73 de Jeff

[Philip Prindeville]

Post by Steven Stromer

Post by Philip Prindeville
I'm not sure there's an issue here.
The .mc file gets processed by m4 and pulls in a bunch of m4 "source"
files that then cause a new generated .cf file to be created.
Since people rarely modify the .m4 files, these get transparently
updated with no generated .rpmnew files.

Agreed, so far.

I should have added that the .m4 files do have a not-insignificant
amount of churn from one release to the next, however.

Post by Steven Stromer

Post by Philip Prindeville
The resultant .cf file, however, may clash with edits you've made.
Unless you've not made edits, in which case, "yes", the original .cf
file should have been replaced with the new .cf file. Is this not
happening?

My .cf file was not replaced by the new .cf file; thus, the birth of
this thread. It would seem to me the 'clash' you describe is not only
inevitable, but desirable, due to the fact that my .cf file, by
definition, contains the mail settings I entered via my .mc file.

Ah, so you did edit your .mc file. I missed that originally.

Post by Steven Stromer

Post by Philip Prindeville
If your .mc file hadn't been modified and neither had your .cf file,
then running "make sendmail.cf" will cause your sendmail.cf to be
regenerated... and agree with your sendmail.mc file, which should always
be the case anyway.

I fully understand and agree that the two files should 'agree', but I
don't see how this clarifies or explains the fact that I see minor, but
certainly differing, lines in the .rpmnew file that do not appear in the
.cf file that is presently generated when I regenerate the file.
Maybe the real question here should be where the differences I see
really stem from. It just seems logical to me that if a .cf file is
being included with a package update, it must be that it contains
elements that no other files can provide to it during a regeneration.

The .m4 files might be identical, but the .m4 files in
/usr/share/sendmail-cf/m4/ that get included by sendmail.mc and
submit.mc might changed significantly, causing the resultant .cf files
to also be different.

Example:

% head /etc/mail/sendmail.mc
...
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
...

that, in turn, sets up definitions for other files that get pulled in
(like OSTYPE(), etc).

Post by Steven Stromer
However, maybe this is where I am off base! Does the .cf file get
completely written from scratch by other files during its regeneration,
or is it simply edited during this process? If it is entirely dependent
on outside 'sources' for the entirely of its content, with every line
being entirely system-specific, then why include it with a package
update at all, instead of just letting the end user generate his or her
own .cf file?

It is completely clobbered. From my /etc/mail/Makefile:

%.cf: %.mc
@if test -f /usr/share/sendmail-cf/m4/cf.m4; then \
umask 022; \
[ -e $@ ] && mv -f $@ $@.bak; \
m4 $< > $@; \
else \
echo -e "WARNING: '$<' is modified. Please install package sendmail-cf to update your configuration."; \
fi


m4 then processes the "include(...)" above and starts pulling in file
content and macro definitions.

Post by Steven Stromer
As I write, I am beginning to believe that my confusion steps from this
single factor! Why include a .cf file in the package update, at all, if
the .cf file is supposed to reflect the system it is located on?

Because not everyone wants to have the contents of
/usr/share/sendmail-cf/ on their system.

Still other people are foolish enough to edit their sendmail.cf by hand.

Post by Steven Stromer
Suddenly, I begin to feel the clouds part, I contemplate the simplicity
of 'rm /etc/mail/sendmail.cf.rpmnew', and a smile forms on my face...
Can anyone confirm that I am finally seeing the light?

Amen and hallelujah.

-Philip