Re: Sendmail updates for slink/potato (99.99% bugs now dead)
Richard A Nelson <cowboy@vnet.ibm.com> writes:
> On Thu, 7 Oct 1999, Wichert Akkerman wrote:
>
> > Previously Richard A Nelson wrote:
> > > Of course, the prior version is saved as sendmail.cf.old - so don't
> > > run the update more than once ;-{
> >
> > Perhaps sendmail.cf should be backuped in /var/backup like some other
> > system files?
>
> Good idea, thanks...
>
> > > Uh, well, I guess -5 wont do that then... btw, other than the don't
> > > masquerade local bit, what other things do you hand edit for in
> > > sendmail.cf?
> >
> > None iirc.
>
> Good, thanks!
> I'm starting to think that sendmail.cf belongs in /var/sendmail!
> as I mentioned in another note (not to this list):
>
> > I'm more interested in things that 'have to be done in sendmail.cf' - or
> > why people hack therein instead of sendmail.mc. Not being allowed to
> > recreate sendmail.cf from sendmail.mc will effectively cripple the
> > ability to add functionality or fix errors in the sendmail and/or
> > Debian provided *.m4 files.
IMHO, there should be some mechanism to prevent currently existing
sendmail.cf files from being overwritten, somewhat similar to
update-modules and /etc/conf.modules. Two schemes I can think of:
1) put a comment in the sendmail.cf that informs the user that changes
WILL be lost if the file is edited directly, and only automatically
recreate sendmail.cf if that comment is still there (i.e., it was an
automatically generated sendmail.cf to begin with). Ask the user
whether to overwrite otherwise.
2) Calculate an md5sum of the sendmail.cf after it has been generated,
and recreate it next time only if it still has the same md5sum.
Ask the user whether to overwrite otherwise.
- Ruud de Rooij.
--
ruud de rooij | ruud@ruud.org | http://ruud.org
Reply to: