Bug#251949: "trivial" change to config files

[Andrew Archibald]

Marc Haber wrote:
> On Fri, Feb 04, 2005 at 02:41:11AM -0500, Andrew Archibald wrote:
> 
> It is always a good idea to get some acquaintance with the software
> you're using.

Hmm, there's something to be said for software that Just Works, as much 
as possible.

> The port number needs to be in the smtp transport which is actually
> used for message delivery, and that transport is surprisingly named
> remote_smtp_smarthost if you're using a smarthost setup.

So, after some reading, I now have some idea what transports, routers, 
and so forth are.  But really, I'd have been happier just punching in a 
port number.

> The file you need to change is /etc/exim4/exim4.conf.template if you
> have chosen the non-split config setup, and
> /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost if
> you have chosen the split config setup. See
> /usr/share/doc/exim4-base/README.Debian.gz for a more detailed
> description of the config mechanism.

Ah. Silly me.  I looked in /usr/share/doc/exim4-config for information 
on the configuration mechanism for exim4.

I also spent a certain amount of time editing the wrong config files, 
since it wasn't clear that all the configuration was present in two 
places, only one of which had any effect (this was not helped by the 
program update-exim4.conf, which I assumed to be constructing exom4.conf 
from fragments.

> Debian takes great care in not clobbering local conffile changes on
> package upgrades. So there is no reason to be afraid of that.

Except when you change something that's not supposed to be a conffile, 
like the file generated (perhaps only in old setups) from all the 
modutils fragments.  Edit that, andit vanishes next time a module is 
upgraded.  By which time you've forgotten what you did and are left with 
a mysterious breakage.

Which is the situation I'm in now.  If I use debconf to go to a normal 
smarthost, it just won't work; I'll get a connection refused error, and 
go looking for reasons the host might not be letting me in.  If I fix 
the port, I have to also remove the self stanza or risk a mail meltdown 
if I make an error switching back to the current setup.

>>That's why it should be a debconf option: just allow host:port in the 
>>usual way.
> 
> That's not the usual way for exim.

No, I can see that.  But the people who use debconf have no idea what 
the usual way for exim is.  They may well have used ssh, though, or a 
web browser.  If it's too confusing, a separate box at the "control 
freak" priority would work; at the least some instructions in 
/usr/share/doc/exim4-config would be nice.

>>No change to the dialog itself is even necessary; a patch is 
>>in the bug tracking system already.
> 
> 
> That patch is quite intrusive and probably not suitable for sarge.

There's about four lines of change...

> ftp://ftp.exim.org/pub/exim/exim4/WishList is the upstream wishlist
> which has an entry for specifying the port in a route list ("Specify a
> port along with a host in a route_list.") This is the clean way to do
> it, and we will probably support this one upstream has implemented
> that feature. Due to the upcoming pain during upgrade, we will most
> probably refrain from doing any local hacks with the clean fix being
> in upstream's pipe.

The ultimate user interface probably won't be any different; the user 
can still enter a port in just the same way with the future version as 
they can with this patch.  If it's stored in a debconf variable (or 
several debconf variables), rather than hacked into the conffiles, it 
should be easy to make this upgrade on users' systems.  The hack itself 
can be discarded once exim4 actually does this.

Anyway, the package is not actually broken, and most users will not have 
to suffer this. But it would be nice if those who do had an easier time 
of it.

Andrew