[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

mixmaster /etc/default/*

Having read the bug report I don't think there is very much to be said
in favour of the submitter's point of view.

Here is a draft resolution and rationale.



 (1) The REMAIL option should not be supplanted or supplemented by
     anything in an /etc/default file.  The current behaviour of the
     mixmaster init script, to examine /etc/mixmaster/remailer.conf's
     REMAIL option, is correct.

 (2) Policy is clear and correct, and need not be changed.


  [ ] Choice K: Keep current behaviour and existing policy, as above.
  [ ] Choice F: Further discussion

1. As very helpfully summarised by Peter Palfrader, the current
   situation is as follows:

    o The mixmaster package provides both the client and server
    o By default the server part (running a remailer) is not enabled.
    o To configure mixmaster to run as a remailer the admin has to set
      a dozen options in /etc/mixmaster/remailer.conf.  Options like
      email address, which formats they will accept, whether to run as
      an exit or only as a middleman remailer, etc.
    o One of those options is the REMAIL setting, which enables or
      disables the remailing ("server") part of mixmaster.
    o The init script has code to only try starting the mixmaster
      daemon, which is only needed when it's being run as a remailer,
      when the REMAIL option is actually set to "y" in that config

2. The submitter has requested that instead of checking
   /etc/mixmaster/remailer.conf for REMAIL being set to `y',
   the init script should read a new setting out of a file in

3. The submitter relies on this part of policy 9.3.2:

      Often there are some variables in the init.d scripts whose
      values control the behavior of the scripts, and which a system
      administrator is likely to want to change. As the scripts
      themselves are frequently conffiles, modifying them requires
      that the administrator merge in their changes each time the
      package is upgraded and the conffile changes.  To ease the
      burden on the system administrator, such configurable values
      should not be placed directly in the script. Instead, they
      should be placed in a file in /etc/default, which typically will
      have the same base name as the init.d script.  This extra file
      should be sourced by the script when the script runs.  [...]

4. The committee's role is not to interpret policy; rather our role
   includes both determining the appropriate behaviour in a specific
   case and also to specify the appropriate policy wording.  However,
   we should make our decisions based on the all of the available
   information, and existing policy documents are a useful input to
   that process.

5. The purpose of this section of policy is admirably and clearly
   stated by the policy itself.  The intent is that an administrator
   who wishes to make a commonly-made change to the behaviour of an
   init script will be able to edit the file in /etc/default rather
   than the script itself.  The point of this is that when the package
   maintainer improves the script (which happens often), the
   administrator only needs to do a trivial merge of the /etc/default
   file rather than to deal with a conffile prompt due to the changes
   to the script itself.

6. I agree with the policy as stated, and find the wording clear.
   There is little room for improvement.  I wholeheartedly adopt the
   principles and rationale described in the policy text, as a good
   basis for the rest of my reasoning.

7. The present situation does not match that described in the policy.
   The setting in question, whether to run the daemon, is not recorded
   in the init.d script but rather in a different configuration file.
   There is no need to edit the init.d script to enable or disable the
   daemon.  So the reasoning described in the policy does not apply

8. But we should consider whether an analogous argument can be made.
   The reasoning in the policy text could apply to other configuration
   files which contain a good deal of complex text supplied by the
   package maintainer, and where certain changes might want to be made
   by many administrators.  In those circumstances it would be useful
   to move those commonly-modified configuration options into a
   separate file for the same reasons as one wishes to movoe
   commonly-modified settings out of init.d scripts.

9. If that were the case then a file in /etc/default might be a good
   choice, depending on implementation language and other details.
   (For example, in my opinion files in /etc/default ought to be shell
   scripts as described in 9.3.2, and if for implementation reasons
   the new small configuration file wasn't a shell script then it
   ought not to be in /etc/default; also, not all such shell script
   configuration fragments ought to be in /etc/default as the package
   may well have a better place to put them.)

10. However, this is not the case here - the REMAIL configuration
   option which controls daemon startup is indeed in a configuration
   file along with other configuration variables, but many of those
   configuration variables also need to be modified by an
   administrator who wishes to change REMAIL.  So there would be
   no benefit in moving the REMAIL option into a separate file.

11. Daemon startup can in any case be controlled by adjustment of the
   /etc/rc*.d links.  These links which are provided specificially for
   the purpose of allowing the system administrator control over the
   operation of subsystems like this one.  Daemon startup should not
   be controlled by variables in /etc/default.

12. Additionally, having the init.d script read the package's
   config files to discover whether the system configuration indicates
   that the daemon needs to be started, is a good and appropriate
   technique.  I commend this approach to package maintainers.

13. I therefore conclude that the policy and the package are both
   correct.  Unfortunately the submitter appears to have misunderstood
   both the actual policy text, and the reasoning behind it.


Reply to: