[Pkg-exim4-users] DEBCONFitemDEBCONF

[David Baron]

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 
possible.

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 
me!

> >  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 
too awful.