Pkg exim4 users - Dec 2005 - minor comment on exim README.Debian

The README.Debian says

Benefits of the split configuration approach:
    * it means less work for you when upgrading. If we shipped one big file
      and modified for example the Maildir transport in a new version you
      won''t have to do manual conffile merging unless you had changed
      exactly _this_ transport.
    * It allows other packages (e.g. sa-exim) to modify exim''s
      configuration by shipping files in /etc/exim4/conf.d.

Benefits of the unsplit configuration approach:
    * It is more fragile. If I add optionfoo=bar to the Debian setup of
      a later version, and you have already set this option in a local
      file, exim will break with the new version until you manually
      correct this.

I think the latter paragraph is a little unclear. How is it a benefit that 
the unsplit configuration is more fragile? Is it talking about the split 
configuration here?

                                                                Faheem.

On Sat, Dec 10, 2005 at 06:32:51PM -0500, Faheem Mitha
wrote:
> 
> The README.Debian says
> 
> Benefits of the split configuration approach:
>    * it means less work for you when upgrading. If we shipped one big file
>      and modified for example the Maildir transport in a new version you
>      won''t have to do manual conffile merging unless you had
changed
>      exactly _this_ transport.
>    * It allows other packages (e.g. sa-exim) to modify exim''s
>      configuration by shipping files in /etc/exim4/conf.d.
> 
> Benefits of the unsplit configuration approach:
>    * It is more fragile. If I add optionfoo=bar to the Debian setup of
>      a later version, and you have already set this option in a local
>      file, exim will break with the new version until you manually
>      correct this.
> 
> I think the latter paragraph is a little unclear. How is it a benefit that 
> the unsplit configuration is more fragile? Is it talking about the split 
> configuration here?
> 
>                                                                Faheem.
I''m pretty sure the "It is more fragile" section describes
the split
configuration.  The benefit of unsplit is that it doesn''t suffer this
problem.

I agree that the sections you quote are unclear.

Ross Boylan

On Sat, Dec 10, 2005 at 05:13:33PM -0800, Ross Boylan
wrote:
> On Sat, Dec 10, 2005 at 06:32:51PM -0500, Faheem Mitha wrote:
> > The README.Debian says
> > Benefits of the split configuration approach:
> >    * it means less work for you when upgrading. If we shipped one big
file
> >      and modified for example the Maildir transport in a new version
you
> >      won''t have to do manual conffile merging unless you had
changed
> >      exactly _this_ transport.
> >    * It allows other packages (e.g. sa-exim) to modify exim''s
> >      configuration by shipping files in /etc/exim4/conf.d.
> > 
> > Benefits of the unsplit configuration approach:
> >    * It is more fragile. If I add optionfoo=bar to the Debian setup of
> >      a later version, and you have already set this option in a local
> >      file, exim will break with the new version until you manually
> >      correct this.
> > 
> > I think the latter paragraph is a little unclear. How is it a benefit
that
> > the unsplit configuration is more fragile?
That''s an error in the docs which was fixed some time after
sarge''s
release. The sentence should mean "It is less fragile".
> I''m pretty sure the "It is more fragile" section
describes the split
> configuration.  The benefit of unsplit is that it doesn''t suffer
this
> problem.
Agreed.
> I agree that the sections you quote are unclear.
I have re-worded the sections. What do you think about this:

        Benefits of the split configuration approach:
        <itemizedlist>
          <listitem>
            <simpara>
              it means less work for you when upgrading. If we shipped
              one big file and modified for example the Maildir
              transport in a new version you won''t have to do manual
              conffile merging unless you had changed exactly
              <emphasis>this</emphasis> transport.
            </simpara>
          </listitem>
          <listitem>
            <simpara>
              It allows other packages (e.g. sa-exim) to modify exim''s
              configuration by dropping files into
              <filename>/etc/exim4/conf.d</filename>. This needs,
however
              quite exact syncing between the exim4 packages and the other,
              cooperating package.
            </simpara>
          </listitem>
          <listitem>
            <simpara>
              It is more fragile. If files from different sources
              (package, manually changed, or other package) get out of
              sync, it is possible for exim to break until you
              manually correct this. This can for example happen if we
              decide to add a new option to the Debian setup of a
              later version, and you have already set this option in a
              local file.
            </simpara>
          </listitem>
        </itemizedlist>
      </para>
      <para>
        Benefits of the unsplit configuration approach:
        <itemizedlist>
          <listitem>
            <simpara>
              People familiar with configuring exim may find this
              approach easier to understand as exim4.conf.template
              basically is a complete exim configuration file which will
              only undergo some basic string replacement before is it
              passed to exim.
            </simpara>
          </listitem>
          <listitem>
            <simpara>
              Split-config''s fragility mentioned above does not occur
              with the unsplit configuration at the price of needing manual
              intervention in case of an upgrade.
            </simpara>
          </listitem>
        </itemizedlist>
      </para>
      <para>
        If in doubt go for the unsplit config, because it is easier to
        roll back to Debian''s default configuration in one step. If you
        intend to do many changes to the Debian setup, you might want to
        use the split config at the price of having to more closely
        examine the config file after an update.
      </para>
      <para>
        We''d appreciate a patch that uses ucf and the 3-way-merge
        mechanism offered by that package. It might be the best way to
        handle the big configuration file.
      </para>

If you find that acceptable, I''ll commit it to svn.

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

On Sun, 11 Dec 2005, Marc Haber wrote:
> I have re-worded the sections. What do you think about this:
>
>        Benefits of the split configuration approach:
>        <itemizedlist>
>          <listitem>
>            <simpara>
>              it means less work for you when upgrading. If we shipped
>              one big file and modified for example the Maildir
>              transport in a new version you won''t have to do
manual
>              conffile merging unless you had changed exactly
>              <emphasis>this</emphasis> transport.
>            </simpara>
>          </listitem>
>          <listitem>
>            <simpara>
>              It allows other packages (e.g. sa-exim) to modify
exim''s
>              configuration by dropping files into
>              <filename>/etc/exim4/conf.d</filename>. This
needs, however
>              quite exact syncing between the exim4 packages and the other,
>              cooperating package.
>            </simpara>
>          </listitem>
>          <listitem>
>            <simpara>
>              It is more fragile. If files from different sources
>              (package, manually changed, or other package) get out of
>              sync, it is possible for exim to break until you
>              manually correct this. This can for example happen if we
>              decide to add a new option to the Debian setup of a
>              later version, and you have already set this option in a
>              local file.
>            </simpara>
>          </listitem>
You''ve got this ''more fragile'' item listed under
benefits. Maybe create a
separate category here called ''Drawbacks''?

Drawbacks:

Is more fragile. ...
>        </itemizedlist>
>      </para>
>      <para>
>        Benefits of the unsplit configuration approach:
>        <itemizedlist>
>          <listitem>
>            <simpara>
>              People familiar with configuring exim may find this
>              approach easier to understand as exim4.conf.template
>              basically is a complete exim configuration file which will
>              only undergo some basic string replacement before is it
>              passed to exim.
>            </simpara>
>          </listitem>
>          <listitem>
>            <simpara>
>              Split-config''s fragility mentioned above does not
occur
>              with the unsplit configuration at the price of needing manual
>              intervention in case of an upgrade.
Perhaps move the last phrase out of there, "at the price...".
>            </simpara>
>          </listitem>
>        </itemizedlist>
Drawbacks:

Will require manual intervention in case of an upgrade.

A little verbose, but clear.
>      </para>
>      <para>
>        If in doubt go for the unsplit config, because it is easier to
>        roll back to Debian''s default configuration in one step. If
you
>        intend to do many changes to the Debian setup, you might want to
>        use the split config at the price of having to more closely
>        examine the config file after an update.
>      </para>
>      <para>
>        We''d appreciate a patch that uses ucf and the 3-way-merge
>        mechanism offered by that package. It might be the best way to
>        handle the big configuration file.
>      </para>
>
> If you find that acceptable, I''ll commit it to svn.
Otherwise looks good.

BTW, you say in the README.Debian

************************************************************
If you chose unsplit configuration, "update-exim4.conf" builds the
configuration from /etc/exim4/exim4.conf.template, which is basically
the files from /etc/exim4/conf.d/ concatenated together at package
build time, and thus guarantees consistency on the target system.
*************************************************************

Are the files in /etc/exim4/conf.d really only concatenated at package 
build time? What about if a another packages adds a file to 
/etc/exim4/conf.d?

Thanks.                                                           Faheem.

On Sun, Dec 11, 2005 at 02:45:10PM -0500, Faheem Mitha
wrote:
> On Sun, 11 Dec 2005, Marc Haber wrote:
> >I have re-worded the sections. What do you think about this:
> >       Benefits of the split configuration approach:
> >       <itemizedlist>
> >         <listitem>
> >           <simpara>
> >             it means less work for you when upgrading. If we shipped
> >             one big file and modified for example the Maildir
> >             transport in a new version you won''t have to do
manual
> >             conffile merging unless you had changed exactly
> >             <emphasis>this</emphasis> transport.
> >           </simpara>
> >         </listitem>
> >         <listitem>
> >           <simpara>
> >             It allows other packages (e.g. sa-exim) to modify
exim''s
> >             configuration by dropping files into
> >             <filename>/etc/exim4/conf.d</filename>. This
needs, however
> >             quite exact syncing between the exim4 packages and the
other,
> >             cooperating package.
> >           </simpara>
> >         </listitem>
> >         <listitem>
> >           <simpara>
> >             It is more fragile. If files from different sources
> >             (package, manually changed, or other package) get out of
> >             sync, it is possible for exim to break until you
> >             manually correct this. This can for example happen if we
> >             decide to add a new option to the Debian setup of a
> >             later version, and you have already set this option in a
> >             local file.
> >           </simpara>
> >         </listitem>
> 
> You''ve got this ''more fragile'' item listed under
benefits. Maybe create a
> separate category here called ''Drawbacks''?
You have a point here. Done.
> Perhaps move the last phrase out of there, "at the price...".
> 
> >           </simpara>
> >         </listitem>
> >       </itemizedlist>
> 
> Drawbacks:
> 
> Will require manual intervention in case of an upgrade.
Also done.
> BTW, you say in the README.Debian
> 
> ************************************************************
> If you chose unsplit configuration, "update-exim4.conf" builds
the
> configuration from /etc/exim4/exim4.conf.template, which is basically
> the files from /etc/exim4/conf.d/ concatenated together at package
> build time, and thus guarantees consistency on the target system.
> *************************************************************
> 
> Are the files in /etc/exim4/conf.d really only concatenated at package 
> build time?
conf.d is used at package build time to build
/etc/exim4/exim4.conf.template, which in turn use used at daemon start
time to build /var/lib/exim4/config.autogenerated in case of non-split
configuration. In that case, conf.d on the target system is ignored.

The local admin can use update-exim4.conf.template to manually
re-build /etc/exim4/exim4.conf.template if he desires so.

In case of split configuration, conf.d on the target system is used at
daemon start time to buil /var/lib/exim4/config.autogenerated. In that
case, /etc/exim4/exim4.conf.template is ignored.
> What about if a another packages adds a file to 
> /etc/exim4/conf.d?
In case of non-split configuration, it is ignored until manual
intervention of local admin. In case of split configuration, it is
used at the next daemon reload.

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

On Sun, Dec 11, 2005 at 09:12:15PM +0100, Marc Haber
wrote:
> On Sun, Dec 11, 2005 at 02:45:10PM -0500, Faheem Mitha wrote:
> > On Sun, 11 Dec 2005, Marc Haber wrote:
> > >I have re-worded the sections. What do you think about this:
> > >       Benefits of the split configuration approach:
> > >       <itemizedlist>
> > >         <listitem>
> > >           <simpara>
> > >             it means less work for you when upgrading. If we
shipped
> > >             one big file and modified for example the Maildir
> > >             transport in a new version you won''t have to
do manual
> > >             conffile merging unless you had changed exactly
> > >             <emphasis>this</emphasis> transport.
> > >           </simpara>
> > >         </listitem>
> > >         <listitem>
> > >           <simpara>
> > >             It allows other packages (e.g. sa-exim) to modify
exim''s
> > >             configuration by dropping files into
> > >             <filename>/etc/exim4/conf.d</filename>.
This needs, however
> > >             quite exact syncing between the exim4 packages and
the other,
> > >             cooperating package.
> > >           </simpara>
> > >         </listitem>
> > >         <listitem>
> > >           <simpara>
> > >             It is more fragile. If files from different sources
> > >             (package, manually changed, or other package) get out
of
> > >             sync, it is possible for exim to break until you
> > >             manually correct this. This can for example happen if
we
> > >             decide to add a new option to the Debian setup of a
> > >             later version, and you have already set this option
in a
> > >             local file.
> > >           </simpara>
> > >         </listitem>
> > 
> > You''ve got this ''more fragile'' item listed
under benefits. Maybe create a
> > separate category here called ''Drawbacks''?
> 
> You have a point here. Done.
Sounds good.  Alternately, just move the whole discussion to benefits
of unsplit.

However, this raises some issues about split/vs unsplit configs.
Apologies if this has already been discussed.

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?

A truly ambitious package writer might want to work on automatically
updating the unsplit config, but that seems like a lot to ask.
Simplest is for the package to print/mail/have in the README a warning
that you must manually edit the exim config file.  Or exim could
provide some script that attempts to merge stuff into the unsplit
config.

Conversely, perhaps there are some old packages, or old package
instructions, that will update the unsplit config file even if split
config is in use.  (Or do the different file names assure this won''t
happen?).  I could imagine that leading to a frustrating situation
where things work for awhile and then, when the config is regenerated,
they stop working because the changes get overwritten.

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).  Is the issue the
likelihood of the problem, or the difficulty of noticing the
duplication if you have an unsplit config?  I''d call the latter more a
debugging issue--not that that is unimportant.

The general remark about getting out of sync may be too strong; it
makes it sound as if the whole thing is likely to collapse at any
change.  It sounds a bit like the kernel; if I rebuild my kernel, I
must rebuild all the modules.  Extending this thinking to exim, every
package add on needs to be "built" or designed for a particular
version of exim.  I know that''s not true, but I think it would be easy
for someone reading the text above to get the impression that it is
true.

I''d try to suggest some alternate language, but I''m not sure
enough of
the importance of the debugging issue I raised earlier to know what to
say.

Ross

On Mon, Dec 12, 2005 at 02:03:35PM -0800, Ross Boylan
wrote:
> Sounds good.
Changes committed to svn.
> Alternately, just move the whole discussion to benefits
> of unsplit.
As someone who likes split more, I won''t do that ;)
> 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.
> A truly ambitious package writer might want to work on automatically
> updating the unsplit config,
No, that''s forbidden.
> Simplest is for the package to print/mail/have in the README a warning
> that you must manually edit the exim config file.
That''s about all that''s possible.
> 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.
> Conversely, perhaps there are some old packages, or old package
> instructions, that will update the unsplit config file even if split
> config is in use.
That might happen, and would be a bug in the other package.
> I could imagine that leading to a frustrating situation
> where things work for awhile and then, when the config is regenerated,
> they stop working because the changes get overwritten.
Explain. I cannot imagine a situation like that. If the local admin
uses update-exim4.conf.template, she decides to overwrite
exim4.conf.template consciously. In the other cases I can think of,
things either don''t work at all, or work and live over updates.
> 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,
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.
> The general remark about getting out of sync may be too strong; it
> makes it sound as if the whole thing is likely to collapse at any
> change.  It sounds a bit like the kernel; if I rebuild my kernel, I
> must rebuild all the modules.  Extending this thinking to exim, every
> package add on needs to be "built" or designed for a particular
> version of exim.  I know that''s not true, but I think it would be
easy
> for someone reading the text above to get the impression that it is
> true.
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 ;)

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

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:
> > Sounds good.
> 
> Changes committed to svn.
> 
> > 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.  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).
> 
> > 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.  My guess is that is not a conffile for
exim4, since the package doesn''t even create the file by default.
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?
> 
> > A truly ambitious package writer might want to work on automatically
> > updating the unsplit config,
> 
> No, that''s forbidden.
> 
> > Simplest is for the package to print/mail/have in the README a warning
> > that you must manually edit the exim config file.
> 
> That''s about all that''s possible.
> 
> > 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.
> 
> > Conversely, perhaps there are some old packages, or old package
> > instructions, that will update the unsplit config file even if split
> > config is in use.
> 
> That might happen, and would be a bug in the other package.
> 
> > I could imagine that leading to a frustrating situation
> > where things work for awhile and then, when the config is regenerated,
> > they stop working because the changes get overwritten.
> 
> Explain. I cannot imagine a situation like that. If the local admin
> uses update-exim4.conf.template, she decides to overwrite
> exim4.conf.template consciously. In the other cases I can think of,
> things either don''t work at all, or work and live over updates.
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.
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.
3) Admin attempts to recreate exim4.conf from the automatically
generated files.

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

I think this does show that even if a packages modifies the unsplit
file--and it''s not clear that''s a good idea--it should still
drop in the
little configuration snippet for conf.d.

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

Somehow, I doubt I''m helping here :(  Maybe better luck with the next
issue.
> 
> > 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?
> 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?

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.

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).
> 
> > The general remark about getting out of sync may be too strong; it
> > makes it sound as if the whole thing is likely to collapse at any
> > change.  It sounds a bit like the kernel; if I rebuild my kernel, I
> > must rebuild all the modules.  Extending this thinking to exim, every
> > package add on needs to be "built" or designed for a
particular
> > version of exim.  I know that''s not true, but I think it
would be easy
> > for someone reading the text above to get the impression that it is
> > true.
> 
> 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.

I presume if you run update-exim4.conf.template you have about the same
problems as a user of unsplit, except that it''s probably easier to
notice the double definition when both definitions are in a single
file.
> 
> Greetings
> Marc
> 
-- 
Ross Boylan                                      wk:  (415) 514-8146
185 Berry St #5700                               ross@biostat.ucsf.edu
Dept of Epidemiology and Biostatistics           fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739                     hm:  (415) 550-1062

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

This is my exim afternoon :)
On Wed, 2005-12-21 at 10:59 +0100, Marc Haber wrote:
> 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:
[snip]
> > 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.
> 
Would it be possible and desirable for breakage to occur noisily at
installation time?  This could be done either by forcing a reload, or
(maybe) running an update script and checking for errors.

The problem would be to be sure that this operation occurred after
another package dropped an exim snippet in place.

Hmm, maybe this belongs on the -dev list.

Ross

On Tue, Jan 03, 2006 at 02:45:52PM -0800, Ross Boylan
wrote:
> On Wed, 2005-12-21 at 10:59 +0100, Marc Haber wrote:
> > 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:
> [snip]
> > > 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.
> > 
> 
> Would it be possible and desirable for breakage to occur noisily at
> installation time?
At an unknown third-party package''s installation time?
> The problem would be to be sure that this operation occurred after
> another package dropped an exim snippet in place.
Yes.
> Hmm, maybe this belongs on the -dev list.
On which -dev list?

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

On Sat, Feb 25, 2006 at 07:18:37PM +0100, Marc Haber
wrote:
> On Tue, Jan 03, 2006 at 02:45:52PM -0800, Ross Boylan wrote:
> > On Wed, 2005-12-21 at 10:59 +0100, Marc Haber wrote:
> > > 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:
> > [snip]
> > > > 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.
> > > 
> > 
> > Would it be possible and desirable for breakage to occur noisily at
> > installation time?
> 
> At an unknown third-party package''s installation time?
Yes.  For example, if packages that messed with exim''s setup restarted
exim, forcing the breakage to be visible then.  This would require
some cooperation from the other package, perhaps limited to using a
standard macro to modify the setup (dh_exim_setup?).

> 
> > The problem would be to be sure that this operation occurred after
> > another package dropped an exim snippet in place.
> 
> Yes.
> 
> > Hmm, maybe this belongs on the -dev list.
> 
> On which -dev list?
pkg-exim4-devel

On Sat, Feb 25, 2006 at 11:41:18AM -0800, Ross Boylan
wrote:
> On Sat, Feb 25, 2006 at 07:18:37PM +0100, Marc Haber wrote:
> > At an unknown third-party package''s installation time?
> 
> Yes.  For example, if packages that messed with exim''s setup
restarted
> exim, forcing the breakage to be visible then.
Yes. Behavior like that is generally frowned upon in Debian though.
You are not supposed to restart a daemon belonging to a foreign package.

If so, it would be good to use invoke-rc.d which has hooks to allow
the local admin to interfere with restarting the other daemon.
> > > Hmm, maybe this belongs on the -dev list.
> > 
> > On which -dev list?
> 
> pkg-exim4-devel
Actually, I don''t see any need to change anything in the exim4
packages to support things that are frowned upon, but already possible
and which are not used by any current third-party package.

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

On Sat, Feb 25, 2006 at 09:32:10PM +0100, Marc Haber
wrote:
> On Sat, Feb 25, 2006 at 11:41:18AM -0800, Ross Boylan wrote:
> > On Sat, Feb 25, 2006 at 07:18:37PM +0100, Marc Haber wrote:
> > > At an unknown third-party package''s installation time?
> > 
> > Yes.  For example, if packages that messed with exim''s setup
restarted
> > exim, forcing the breakage to be visible then.
> 
> Yes. Behavior like that is generally frowned upon in Debian though.
> You are not supposed to restart a daemon belonging to a foreign package.
> 
> If so, it would be good to use invoke-rc.d which has hooks to allow
> the local admin to interfere with restarting the other daemon.
> 
> > > > Hmm, maybe this belongs on the -dev list.
> > > 
> > > On which -dev list?
> > 
> > pkg-exim4-devel
> 
> Actually, I don''t see any need to change anything in the exim4
> packages to support things that are frowned upon, but already possible
> and which are not used by any current third-party package.
> 
Sounds reasonable to me.
Ross

On Sat, Feb 25, 2006 at 09:32:10PM +0100, Marc Haber
wrote:
> On Sat, Feb 25, 2006 at 11:41:18AM -0800, Ross Boylan wrote:
> > On Sat, Feb 25, 2006 at 07:18:37PM +0100, Marc Haber wrote:
> > > At an unknown third-party package''s installation time?
> > 
> > Yes.  For example, if packages that messed with exim''s setup
restarted
> > exim, forcing the breakage to be visible then.
> 
> Yes. Behavior like that is generally frowned upon in Debian though.
> You are not supposed to restart a daemon belonging to a foreign package.
> 
> If so, it would be good to use invoke-rc.d which has hooks to allow
> the local admin to interfere with restarting the other daemon.
> 
> > > > Hmm, maybe this belongs on the -dev list.
> > > 
> > > On which -dev list?
> > 
> > pkg-exim4-devel
> 
> Actually, I don''t see any need to change anything in the exim4
> packages to support things that are frowned upon, but already possible
> and which are not used by any current third-party package.
Sorry, just to be clear, I meant your decision sounds reasonable to
me.
Ross