Debian

The Apache example should give you a feel for how Debian splits configuration files into smaller, more easily managed files, and provides means to ease various administration tasks, such as activating and deactivation modules. Other software will have different layouts, as well as, different configuration features and utilities, all described in the appropriate documentation.

Exim, for example, uses a single, monolithic configuration file. In order to split files out, Debian provides a utility update-exim4. conf that combines all of the separate configuration files from the / etc/exim4 / conf . d hierarchy into the single file required by the exim4 software. There are several minor variations in how this may be done (all explained in the documentation), so that an administrator can choose his preferred method.

Debian sendmail, another email package, uses another method. All of its configuration files are in the /etc/mail hierarchy, and GNU make is used after updating the configuration to create all of the necessary database and config files. In fact, a special utility, sendmailconfig, will not only run make for you, it will also handle incorporating /etc/default/sendrnail changes, and reload the sendmail configuration after processing is complete.

All of this shows how the Debian developers provide various methods of making configuration easier. Simpler packages may have few, one, or no configuration files. Those with larger or more complex configuration won't all be handled identically, although the technique of splitting files into smaller, easier to modify pieces and providing utilities to ease config administration will be common to most (and, per Debian policy, described in the documentation for each package).

The configuration files in this directory are intended to control the standard initialization scripts found in /etc/init.d (known as init scripts), or the way various system libraries behave. They contain environment variable definitions that are used by system libraries or in the init scripts, to control execution options, software module loading, and anything else that can be controlled dynamically.

In the case of definitions used by the init scripts, the variables usually include a definition of command line options to be used. In some cases, setting one of the variables modifies the behavior of the script. For example, setting RESOLVCONF to anything but no in /etc/default/bind9 will cause the init script to use the resolvconf utility to add an appropriate resolver line for the localloopback interface during initialization (and remove it during shutdown).

For those scripts that apply to system libraries, they generally define default behavior for commands or software that the libraries affect. A good example of this is /etc/ default/nss, which controls how the Name Service Switch (NSS) functions in the GNU C library. In particular, it controls what information the library will consider authoritative for NSS calls, as well as the behavior of certain function calls.

In special cases, the default definition file may not be a single file, but " a subdirectory of /etc/default. TItis is done to split information into groups of related variables, both for ease of update, and to allow local modifications that won't be overwritten when configuration files are replaced.