On 07/28/2015 06:00 AM, Fred Smith wrote:
On Tue, Jul 28, 2015 at 05:33:06AM -0500, Johnny Hughes wrote:
On 07/28/2015 04:09 AM, Nico Kadel-Garcia wrote:
On Mon, Jul 27, 2015 at 7:52 PM, Fred Smith fredex@fcshome.stoneham.ma.us wrote:
On Mon, Jul 27, 2015 at 01:23:07PM -0700, Akemi Yagi wrote:
On Mon, Jul 27, 2015 at 12:38 PM, Fred Smith fredex@fcshome.stoneham.ma.us wrote:
FYI, I ran all the (then current) updates from the CR repo this morning, and found that it stepped on my sendmail.cf. (presumably the sendmail rpm was the culprit.)
I wouldn't think that was the desired beavhior, would you? I'd expect it to drop either a rpm.old or rpm.new file instead.
luckily, easy to fix once I figured out why incoming mail was busticated.
If you look into the /etc/mail directory, don't you see sendmail.cf.bak? At least in my case, that file was created by sendmail* update.
Akemi
Yes, I do.
Nevertheless, it seems kinda rude of it to break a working configuration...
But I'm no expert, what do I know? :)
Sounds like you edited sendmail.cf directly. That's not the standard configuration file for local changes, those usually live in sendmail.mc and are processed with the m4 macro language. As I remember sendmail from.... oh, a very long time ago, you need to use the "sendmail.fc" or "frozen configuration" config file if you want to protect it from rebuilds based on sendmail.mc.
Personally, I gave up on sendmail in favor of postfix a decade ago. The only reason I use anything other than postfix these days is if I want to have /etc/aliases and procmail read for local email addresses, and SMTP relay for 'name@host.com' email addresses. The only SMTP server I've seen that handles both at the same time is exim.
I agree that is likely what happened, if the sendmail.mc file does not match the sendmail.cf file, it backs up the cf file and creates a new one from the cm file.
My .mc file is not named sendmail.mc. that way an update won't overwrite it, either. so you're telling me that if it had been named sendmail.mc that this wouldn't have happened?
That is the standard behavior, and this is not the first version where that happens:
https://bugzilla.redhat.com/show_bug.cgi?id=1196342
I personally don't like this method, but it is what postfix updates do, and it is by design in RHEL.
I gotta say that I don't remember encountering this behavior before.
Yes, that is what Red Hat is tell us in bug #1196342 ..
That it is not a bug if the sendmail.mc file does not match the sendmail.cf file and sendmail.cf.bak is created and a new sendmail.cf is generated.
Since the sendmail.mc file was the default from before, the update system thinks that sendmail.cf (which is supposed to be generated from sendmail.mc) is also default. If it is default, it needs to be replaced by this update .. or so the theory goes.
If sendmail.mc was modified, then a sendmail.cf.rpmnew would have been generated and neither sendmail.mc or sendmail.cf would have been updated.
The behavior has at least been documented in EL 5.11 in bug #1196342.
And, I see things that imply it worked this way as far back as 2007:
https://www.redhat.com/archives/rpm-list/2007-September/msg00064.html
But I have never actually used sendmail in production, so I can only go on what is written in the bugs and archives of the mailing list.