Bug#481597: dpkg-reconfigure exim4-config does not recognize changed hostname

[Andrew Vaughan]

On Sunday 25 May 2008 18:42, Marc Haber wrote:
> On Sat, May 24, 2008 at 04:44:27AM +1000, Andrew Vaughan wrote:
> > On Saturday 24 May 2008 02:43, Marc Haber wrote:
> > > On Sat, May 17, 2008 at 07:34:22PM +1000, Andrew Vaughan wrote:
> > > > I changed the hostname on my home server.  I changed /etc/hostname
> > > > and /etc/mailname, rebooted and ran dpkg-reconfigure exim4-config
> > > > thinking that that should be enough to get exim configured for the
> > > > new hostname.
> > >
> > > Did you also change your /etc/hosts?
> >
> > No, but the new hostname is listed as an alias (and has been for 2
> > years).
> >
> > Experimenting shows that this does seem to the the problem.
>
> Yes, it is. Exim tries to determine its FQDN on startup to be able to
> correctly process the @ macro. Without /etc/hosts, the FQDN cannot
> be correctly obtained since /etc/hostname only sets the unqualified
> host name.

I wasn't even aware that the local machine should be listed in /etc/hosts.  
(In my case it was there because I edited /etc/hosts once, and then copied 
it to my other 2 machines).  

I note that if I remove that line, dpkg-reconfigure exim-config will happily 
complete, but that question 5 shows that exim-config doesn't know what the 
local hostname is.  (Something complains "hostname: Unknown host", but 
exim-config doesn't seem to actually care about the error.)

I guess that the FQDN at startup can legitimately be different from the FQDN 
at debconf question 3, otherwise you wouldn't be asking question 3.  

>
> >   Changing the order so that the new hostname is listed first fixes
> >   the displayed name in exim4-config question 5.  I'll check whether
> >   mail from cron gets delivered.
>
> Does it work?

yes
>
> > Perhaps exim4-config could be changed to automatically add
> > /bin/hostname -a to the list of automatic list of "local domains" in
> > debconf question 5.
>
> That is not necessary. The list of local domains always includes @,
> which expands to the local host name on a correctly configured system.
> I don't think that it is correct to work around local configuration
> errors automatically.

In general I agree.  It's much better to detect and report the error.  
Deamons/config-tools should try to validate their configuration files as 
much as is reasonably possible.

But if a config-tool can generate a configuration file that will work 
despite possible local configuration errors that the config-tool/daemon 
can't detect, then that is better IMO than the alternative of the daemon 
appearing to start ok, and working for some use-cases, but actually being 
misconfigured.

In this case it simply occurred to me that a machine accepting mail for all 
of its hostname aliases would possibly be a reasonable default config, and 
is potentially desirable.  

>
> > Note that I consider the fact that exim was unable to notify me about
> > the stuck mail as part of the justification for the important bug
> > severity.

Thinking back to this, I actually misinterpreted the standard notification 
to sender (in this case root) that their mail is delayed/not undelivered as 
exim4 attempting to notifying root that there is stuck mail.  

If exim were to attempt to notify root of email problems, it should try to 
avoid letting the notification also get stuck.

>
> If you want to be notified about stuck messages, use eximstats on a
> regular basis and/or install a log management/check package.
>
I don't want to be running such checks manually.  But unless I'm missing 
something, I can't think of an easy way to automate such checks that would 
work when exim fails to deliver mail from cron?

Thanks for your help.  Feel free to close and/or downgrade this bug if you 
won't/can't make exim/exim-config more robust against this type of 
mis-configuration, and don't see any other issues from what I wrote above.

Cheers
Andrew V.