[BlueOnyx:20778] Re: prevent own sendmail.mc entries for getting overwritten by an update?

[Michael Stauber]

Hi Dirk,

> is there a way to prevent own entries in /etc/mail/sendmail.mc to get overwritten by an update?

If you have the AV-SPAM installed, then there is an easy way:

Put your changes into this file:

/home/solarspeed/av-spam/configs/sendmail.mc.meta.

If it's present, then base-blueonyx (and base-email) will not use the
"stock" sendmail.mc that comes with BlueOnyx. Instead they will use the
above sendmail.mc.meta.

If you don't have the AV-SPAM installed? Then create this Constructor:

mkdir -p /usr/sausalito/constructor/solarspeed/av_spam/
pico /usr/sausalito/constructor/solarspeed/av_spam/aa_initial_inst.pl

And put the following code into it:

#!/usr/bin/perl -I/usr/sausalito/perl
# $Id: aa_initial_inst.pl - special edition ;-)
use CCE;
my $cce = new CCE;
$cce->connectuds();
system("cp /root/sendmail.mc /etc/mail/sendmail.mc");
$cce->bye('SUCCESS');
exit(0);

And make it executable:

chmod 755 /usr/sausalito/constructor/solarspeed/av_spam/aa_initial_inst.pl

Mind you, the Constructor for the AV-SPAM is much longer as it also does
other things. But this replacement constructor copies /root/sendmail.mc
to /etc/mail/sendmail.mc whenever CCEd is restarted and (especially)
whenever base-emails is updated.

The RPM-Trigger in base-email runs this constructor right before it uses
/etc/mail/sendmail.mc to rebuild the sendmail.cf:

m4 /usr/share/sendmail-cf/m4/cf.m4 /etc/mail/sendmail.mc >
/etc/mail/sendmail.cf

So either one of those two methods should fix the problem for you. In
the longer run I'll check if I can either skip the sendmail.mc
replacement under certain conditions, or provide provisions which allow
you to permanently substitute your own that doesn't get replaced.

-- 
With best regards

Michael Stauber