Proposed guideline for init script files

[Toshio Kuratomi]

On Wed, 2007-02-28 at 14:46 +0100, Laurent Rineau wrote:
> On Wednesday 28 February 2007 13:59:29 Christopher Blizzard wrote:
> > On Tue, 2007-02-27 at 15:37 -0500, Jesse Keating wrote:
> > > The Packaging Committee has been discussing guidelines for init scripts
> > > for a while.  Currently there is a split between init scripts being
> > > marked as %config and many that aren't.  We (the PC) with input from
> > > various folks feel it is best to not mark init scripts as %config, and
> > > instead promote configuration to happen in an /etc/sysconfig/<init> file.
> > >  Mostly the reason being that init scripts are just that, scripts to run
> > > and not config files to edit.  As such I've drafted a proposal for the
> > > guidelines and the PC approved it.  There is time now for a wider
> > > audience to review the proposed change and comment.
> >
> > +1.  In general if you have to edit an init startup file, it's a bug.
> > Configuration should be in /etc/sysconfig/foo.
> 
> Right. But are we sure our scripts are configurable enough for usages of all 
> administrators?
> 
> As an administrator, I would like to be able to use Fedora without filling a 
> bug when my local settings are incompatible with Fedora's init scripts.
> 
This was my only complaint with the policy.  I think it needs to
emphasize the importance of packagers exposing configuration options to
the enduser.  Otherwise we put users in the unenviable position of
having their necessary changes silently lost with every update.

Matthias's suggestion to have a Best Practices section that outlines
what a proper init script will help as well.  There should be a section
that talks about exposing customization.  Here's a snippet for exposing
the command line:
'''
If your daemon can be customized via environment variables or
commandline switches, then you need to expose that to the end user.  Do
this by
1. Creating an /etc/sysconfig/DAEMONNAME file to store the configuration
in.  Be sure to add comments to this file that indicate what variables
it will know about.
2. Your init script must source that config file.
3. If the daemon you're starting takes commandline options, one of the
variables must be DAEMONOPTS which your init script will use when it
invokes the daemon.  Be sure that this variable allows the user to
override any commandline options you've placed in the file.  If the
daemon does not override arguments but rather spits out errors (like "-v
and -q are incompatible.  Please specify one or the other.") you may
have to place the default commandline options in the sysconfig config
file.
'''

We should also have some rough guidelines of what customization would be
so invasive that a separate package should be built instead of trying to
support it in the initscript/config file.  For instance, managing the
package in a chroot might be something that is configured by dropping a
second package on the system that has a different init script and a
chroot environment setup.

The one thing that I see as the worst of all worlds is encouraging a
situation where initscripts are not config and we simultaneously have
packages where bugs about customization are considered low priority.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070228/eadfdb48/attachment.sig>