d_baron at 012.net.il
Mon Jul 2 11:21:56 UTC 2007
On Monday 02 July 2007, Marc Haber wrote:
> On Sun, Jul 01, 2007 at 05:11:28PM +0300, David Baron wrote:
> > This stuff is no lonber acceptable and any Sid upgrades not accepting the
> > maintiners configuration will render exim4 inoperative
> Exim should either not run at all, or continue running with the old
> configuration. Please show evidence of an "inoperative" exim.
Exim complained about missing config and cited the DEBCONF macros in the /var
tmp file generated. The daemon continued to run but bawked at every email
offered, repeated the error messages. Either of the modes cited above would
have been preferable.
I do not know about receiving messages (see below), but I believe I was still
able to send.
> > and fetched email will go to neverland until one realizes what
> > happened.
> Please show evidence that exim4 loses mail. The use of the term
> "fetched" indicates a fetchmail setup, and fetchmail should not delete
> messages from the input mailbox until the SMTP listener has accepted
> the message. If it does do differently, please go yell at fetchmail.
I was afraid messages were lost. Maybe they were none in reality, during the
period the inoperative exim was running, I did not receive any. Certainly
The logs did not tell me anything.
> > The documentation says one can define:
> > exim macro DEBCONFstringOK_config_adapted
> > and continue with existing configuration files
> No, that's wrong. If you still have - after adapting your local config
> to the new configuration scheme - DEBCONFsomethingDEBCONF somewhere in
> your config, you can silence the warning. That is not going to change
> your requirement to adapt your config. You can find information about
> how to define exim macros in README.Debian.gz, chapter 2.1.3.
Ok. That "news" file was in error. So what is really needed is a script to
convert the configuration files. Since resolving those DEBCONF thingies was
part of update-exim.conf, a one-time conversion script should be readily
available and should be offered.
I made copies of the configuration files I believe I changed so I suppose I
could take the new ones and then work from there. However, exim is not the
easiest to set up and a conversion script would make more sense, at least to
> > but does not say where or how to do this. Tried a few places to no
> > avail before downgrading to the "testing" packates.
> Ask smart questions. Say exactly what you did and people will be able
> to help. "A few places" does not help at all.
Where would one try such a thing? main/01_exim4-config_listmacrodefs (I am
using separate files)? update-exim4.conf.conf? Where else... ?
If the "adapted" idea were indeed in error, then neither would worked.
> > So ... the upgrade should be nicer behaved, either shutting exim and
> > stuff like fetchmail down until there is a valid configuration
> Please show evidence that it does not.
Obviously does not.
> > or better instructions offered.
> Send a patch.
If I knew enough on how to do that, I would be delighted. Basically as I
posted to Debian-user:
1. Shutting down found mail fetcher fetchmail or alternative.
2. Shutting down exim4
3. Upgrading exim4
4. Uh-oh, cannot run with the old config files right now--better do something
about this. Do not restart the daemons until resolving this!
Outside chance of minimal data loss at most.
If one successfully upgraded, i.e. accepted the new files:
5. Succesfful. Your old configuration saved to ....
6. Restarting exim4
7. Restarting mail fetcher fetchmail ...
> > Best: A script to replace those DEBCONFitemDEBCONF things in existing
> > configuration files.
> Send a patch. One that works for each and every corner case, please.
Same here. However, update-exim4.conf used to do this every thing so somebody
knows much better than I would :-)
> > Anyway, how do I do the config_adapted or alternative?
> Best thing to do is probably accept our config changes and repeat your
> local modifications. You know best what you changed, we know best what
> we changed.
Probably will do this. Using procmail for spam and virus check (I do not
rememver having done anything to exim for this). Smarthost + PLAINTEXT auth,
so enabling no TLS in macro and the smarthost remote transport. Should not be
More information about the Pkg-exim4-users