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

Re: mysteries of /etc/default/*



Adrian 'Dagurashibanipal' von Bidder wrote:
> On Thursday 15 July 2004 15.15, Martin Dickopp wrote:
> > Sebastian Henschel <debian@kodeaffe.de> writes:
> [/etc/default]
> > See Policy 9.3.2.  (Disclaimer: IANADD.)
> 
> Which does only say:
> | To ensure that vital configurable values are always available, the
> | init.d script should set default values for each of the shell
> | variables it uses, either before sourcing the /etc/default/ file or
> | afterwards using something like the : ${VAR:=default} syntax.
> which isn't much.

A few bits that you missed:

     Often there are some variables in the `init.d' scripts whose values
     control the behaviour of the scripts, and which a system administrator
     is likely to want to change.  As the scripts themselves are frequently
     `conffile's, 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.  It
     must contain only variable settings and comments in POSIX `sh' format.
     It may either be a `conffile' or a configuration file maintained by
     the package maintainer scripts.  See Section 10.7, `Configuration
     files' for more details.

9.3.5. Example
--------------

     The `bind' DNS (nameserver) package wants to make sure that the
     nameserver is running in multiuser runlevels, and is properly shut
     down with the system.  It puts a script in `/etc/init.d', naming the
     script appropriately `bind'.  As you can see, the script interprets
     the argument `reload' to send the nameserver a `HUP' signal (causing
     it to reload its configuration); this way the system administrator can
     say `/etc/init.d/bind reload' to reload the name server.  The script
     has one configurable value, which can be used to pass parameters to
     the named program at startup; this value is read from
     `/etc/default/bind' (see below).

...

     Complementing the above init script is a configuration file
     `/etc/default/bind', which contains configurable parameters used by
     the script.  This would be created by the `postinst' script if it was
     not already present, and removed on purge by the `postrm' script.
          # Specified parameters to pass to named. See named(8).
          # You may uncomment the following line, and edit to taste.
          #PARAMS="-u nobody"

It's really not that hard to run less on policy and type /etc\/default

-- 
see shy jo

Attachment: signature.asc
Description: Digital signature


Reply to: