[Pkg-exim4-users] minor comment on exim README.Debian

[Marc Haber]

On Tue, Dec 20, 2005 at 02:33:26PM -0800, Ross Boylan wrote:
> On Sat, 2005-12-17 at 16:01 +0100, Marc Haber wrote:
> > On Mon, Dec 12, 2005 at 02:03:35PM -0800, Ross Boylan wrote:
> > > Alternately, just move the whole discussion to benefits
> > > of unsplit.
> > 
> > As someone who likes split more, I won't do that ;)
>
> I don't see how leaving a discussion of the drawbacks of split in the
> section on the split configuration makes it look better.

It makes the benedits of unsplit list longer.

> Oh, my original remark may have been unclear.  "whole discussion"
> referred to the discussion of the fragility issue, which in the draft
> is split between a section under split config (how it is fragile, a
> drawback) and unsplit (how it is less fragile, an advantage).

I think that the current structure helps the local admin decide since
the properties of the two alternatives are listed together.

> > > 1) There should be some advice for maintainers of other packages that
> > > want to drop in snippets to the conf.d.  In particular, what should
> > > they do if the configuration is unsplit?  Is there a debian helper
> > > macro?
> > 
> > No, and if there would be one, using it in a maintainer script of a
> > non-exim4 package would be a policy violation and an RC bug. Package A
> > cannot modify package B's dpkg-conffiles in its maintainer scripts.

> I'm thinking of the case where the user/admin
> crafts /etc/exim4/exim4.conf.

Ah, ok. That is a possibility offered to be used by the local admin,
but not supported at all. We won't mess with that file, and we don't
offer any help with that file since whoever uses it has clearly
indicated that she does not want our magic. I'd prefer manpower going
into the supported ways of configuration.

> My guess is that is not a conffile for
> exim4, since the package doesn't even create the file by default.

Yes.

> Also, I didn't know the rule about packages not modifying each others'
> confiles; I figured if a user can do it, why not a package?

afair, this is caused by the fact that by the time maintainer scripts
run, dpkg has already loaded state of the conffiles and might be
deeply confused about unexpected changes at that time.

> > > Or exim could
> > > provide some script that attempts to merge stuff into the unsplit
> > > config.
> > 
> > That script is already there. It is update-exim4.conf.template.
> Again, I'm thinking of an exim4.conf.

use update-exim4.conf.template, followed by update-exim4.conf -o. But
again, why would someone not wanting our magic want our configuration
as a starting point?

> Having studied things more closely, I think this could only arise out of
> poor administrative practice.  The scenario I had in mind is
> 1) someone has their own exim4.conf file, perhaps created by copying the
> autogenerated file and then modifying it.

At that point, support done by the exim4 maintainers kind of ends.

> 2) A non-exim package modifies exim4.conf under my imagined scenario
> above where other packages update the unsplit exim4.conf if it's there.

The local admin has explicitly requested her configuration to stay
untouched.

> 3) Admin attempts to recreate exim4.conf from the automatically
> generated files.

Again, her own decision she is free to do. If it breaks, she gets to
keep the pieces.

> The problem is that step 3 is kind of silly anyway, since it would
> remove all customizations that had been applied.

Right.

> I think this does show that even if a packages modifies the unsplit
> file--and it's not clear that's a good idea--

Any Debian package touching /etc/exim4/exim4.conf.template without
being called "exim4-foo" is RC buggy.

> it should still drop in the
> little configuration snippet for conf.d.

Yes. Absolutely.

> Additional complication: conf.d may not be present, since that depends
> on the decision to use exim4-config.

In that case, conf.d would be created on the third-party package's
installation, and of course ignored. No breakage here.

> > > 2) I know the "fragility" referred to above has been cited as a
> > > drawback of split, but I'm not sure how distinct it is to split.  If
> > > someone merges some code into an unsplit config, it could easily have
> > > the same problem (e.g., double definition of macro).
> > 
> > Yes. But it is a conscious thing to activate the new configuration,
> I don't follow what "activate the new configuration" means.  Is it a
> reference to using the split config at all?  Or to the new configuration
> induced by the other package?

When you use split config, and a third party package drops in a faulty
/etc/exim4/conf.d/router/400_thirdparty_faulty router, exim4 breaks at
the time of the next reload, which will probably be the next
cron.daily run when the logs are rotated.

When you use unsplit config, and 400_thirdparty_faulty suddenly shows
up, it is ignored until the local admin consciously executes
update-exim4.conf.template.

> > and thus the breakage is immediately noticed. Andreas was concerned
> > about some random package dropping broken and incompatible config into
> > the split directory, and exim would fail on next config reload, which
> > could be days later.
> Is the premise of this concern that a new package will drop something
> into conf.d but do nothing that would affect the unsplit config
> (including modifying the template), whether autogenerated or purely
> hand-crafted?

Yes. No package is permitted to touch /etc/exim4/exim4.conf.template.

Let's define some expressions:

split config: /etc/exim4/conf.d -> /var/lib/exim4/config.autogenerated
unsplit config: /etc/exim4/exim4.conf.template -> /var/lib/exim4/config.autogenerated
hand-crafted config: /etc/exim4.conf

> If so, the concern seems to be more with the dangers of automatic
> updates of the configuration than whether it's split or not.  However,
> since the unsplit doesn't get automatically updated (if my
> interpretation is correct), it comes out safer.

It is _forbidden_ to update the unsplit config. Any package doing so
would be RC-Buggy.

> If this interpretation is correct, then the split configuration has a
> feature (updates from other packages automatically incorporated) which
> is simultaneously a plus and a minus (good that it's automatic; bad that
> it might break).

Right.

> > Please suggest a less harsh wording. I am a big friend of the split
> > config, and nonsplit wouldn't exist hadn't Andreas insisted, so I'm
> > all in favor of letting split look better ;)
> First I need to understand exactly what the fragility issue is about.  I
> understand that something like a double definition will mess things up;
> I'm not sure why that is less likely to happen (or be easier to debug?)
> in the unsplit than the split case.

In the unsplit case, the local admin somehow edits the
exim4.conf.template (probably by executing update-exim4.conf.template)
and is aware that exim might break _now_.

In the split case, the breakage will occur on next daemon reload,
which might be later, and noticed by somebody else, who is not even
aware that exim's configuration was touched.

> I presume if you run update-exim4.conf.template you have about the same
> problems as a user of unsplit,

Yes. But you know that your exim might break _now_, and the breakage
is a immediate effect of explicitly touching the config.

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 621 72739835