[Pkg-exim4-users] DEBCONFitemDEBCONF

[Marc Haber]

On Tue, Jul 03, 2007 at 12:14:07PM +0300, David Baron wrote:
> On Tuesday 03 July 2007, Marc Haber wrote:
> > On Mon, Jul 02, 2007 at 02:21:56PM +0300, David Baron wrote:
> > > 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.
> >
> > $ sudo grep DEBCONF /etc/exim4/exim4.conf.template
> > /var/lib/exim4/config.autogenerated
> > /etc/exim4/exim4.conf.template:DEBCONFthisisbrokenconfigDEBCONF
> > $ sudo update-exim4.conf
> > DEBCONFsomethingDEBCONF found in exim configuration. This is most probably
> > caused by you upgrading to exim4 4.67-3 or later without accepting the
> > suggested conffile changes. Please read
> > /usr/share/doc/exim4-config/NEWS.Debian.gz for 4.67-2 and 4.67-4
> > 2007-07-03 02:23:29 Exim configuration error in line 21 of
> > /var/lib/exim4/config.autogenerated.tmp: malformed macro definition
> > Invalid new configfile /var/lib/exim4/config.autogenerated.tmp, not
> > installing /var/lib/exim4/config.autogenerated.tmp to
> > /var/lib/exim4/config.autogenerated $ sudo grep DEBCONF
> > /etc/exim4/exim4.conf.template /var/lib/exim4/config.autogenerated
> > /etc/exim4/exim4.conf.template:DEBCONFthisisbrokenconfigDEBCONF
> > $
> >
> > This shows pretty well that the invalid exim4 configuration does not
> > get installed to the file that is actually read by exim.
> >
> > > The daemon continued to run but bawked at every email offered,
> > > repeated the error messages.
> >
> > Please show evidence that this actually happened so that it can be
> > reproduced here.
> 
> 2007-06-24 22:03:11 1I2XMd-0003rG-7C <= kelly_ik at myjaring.net H=localhost 
> (ip6-localhost) [127.0.0.1] P=esmtp S=8404 
> id=2a63281d469b03e3c6080cce0012f7be at myjaring.net
> 2007-06-24 22:03:11 non-existent configuration 
> file(s): /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated

I reproduced this by starting an exim daemon and moving away
/var/lib/exim4/config.autogenerated while the daemon was still
running. Delivering messages to the daemon in this situation resulted
in the same log messages being written as you quoted.

However, the messages ended up on the queue just fine and were
delivered in the next queue run after repairing the configuration.
Please grep your later logs for the message IDs in question to find
out what happened to the messages on your system.

I am, however, confused how you got your system in that situation. Our
scripts normally only touch /var/lib/exim4/config.autogenerated after
(a) a new file was generated and (b) passed the syntax check. You
report the new file not passing the syntax check, so - theoretically -
the old configuration should have stayed in place.

> Mail was not being correctly received during this period.

Your log shows Mail being correctly received, but not delivered.

> However, stuff that appears here would have been spam so the procmail pipe 
> might have been what ws inoperative.

Procmail pipe? Spam? I suspect that you have not told us about some
important details of your configuration.

> > > > > 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.
> >
> > Which "news" file?
> >
> /usr/share/doc/exim4-config/NEWS.Debian.gz for 4.67-2 and 4.67-4
> 
> and this says that if one wants to continue using a config with DEBCONF 
> macros, one should define the "...adapted" macro.

No. It says that you need to adapt your configuration.
DEBCONFstringOK_config_adapted does only turn off the check for
DEBCONFsomethingDEBCONF just in case that you use such strings in your
local configuration. the exim4 mechanisms are not going to use these
strings any more.

>  It did not say that this would simply suppress the messages

It does:

    If you insist on having DEBCONFsomethingDEBCONF strings in your
    exim configuration and don't want update-exim4.conf to barf, set
    the exim macro DEBCONFstringOK_config_adapted to a non-empty
    value.

> (which it did not do in any event).

That was a bug which has been fixed in the mean time.

> > > If the "adapted" idea were indeed in error, then neither would worked.
> >
> > Which "adapted" idea?
> 
> That ...adapted macro suggested in the "NEWS" file which had no effect.

The adapted macro does not do any magic, it just overrides the
warnings just in case that you find the warnings to be false positives.

> > > > > 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.
> 
> I saw no evidence that any other daemon was touched by the
> installation other than the restart of exim4.

Exim4 is innocent until proven guilty. You seem to be the only one
with this issue.

> > > 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!
> >
> > That's how it is designed to work, and proven to work on my test system.
> 
> OK. If it did so, it was silent about it. All I saw was something like
> 3. and then a warning like 4.

The maintainer scripts shut down exim4 before doing any upgrade. If
that didn't work, I'd like to find out what happened (which might be
hard to do ex-post).

Shutting down other packages during the upgrade is out of the question
as Debian policy does not allow this. I'd expect mail fetchers to
gracefully handle the case when the SMP listener is not ready at their
run time. It can happen all the time.

> which was, in fact, the contents of that NEWS file

I do not understand.

> update-exim4.conf (produces a warning) and restart of exim4 daemon done. My 
> question was whether exim4 should have been restarted at this point if, 
> according to the warning message, it was not (fully) operative.

In theory, at the time of the message, the previous exim configuration
should not have been touched, so it should have been safe to restart
exim.

>  Maybe the NEWS text should display BEFORE any exim4 packages are
>  replaced and ask: Do you want to proceed?

This is what apt-listchanges is for.

>  This was what happened on the original -2 upgrade (I did not proceed)
>  but might only have been visible if apt-listchanges were installed.

apt-listchanges should be installed. There is no way for packages to
do things before they are being installed.

>  This did not repeat for -3 and later and the postconfig stuff was
>  placed after a bug was filed over the malformed macro.

-3 didn't have a new NEWS entry, so it wasn't displayed a second time.
Anyway, the DEBCONFsomethingDEBCONF warning should be clear enough. If
not, please suggest an alternative wording.

>  At the post stage, it is already too late to stop.

Yes. There is nothing a package can do.

> I guess such problems, whether actually serious or not, will occur whenever 
> baskwards compatability of a package is not maintained. 

We try very very hard to maintain compatibility, but we expect users
to read the docs.

> As I said, I installed -5, accepted the newer conf files and edited the 
> macrodefs easily enough.

Sounds like the correct behavior.

>  I certainly never entered any DEBCONFitemDEBCONF that I would have
>  needed to deal with.

So accepting the new configuration changes would be the right thing to
do.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190