Debian

This utility reruns the same configuration scripts that run during installation. It is run from the command line, and options can be used to vary the level of complexity of the questions asked. It is generally used when extensive, local modifications aren't required and the admirristrator just wants to update the basic configuration as provided by the installation scripts. It is also useful if the basic configuration has been corrupted, or changes made that have caused the package to stop working, to return it to the configuration provided immediately after installation.

So, what are some of the utilities provided for Debian administration? We've already mentioned a couple of specialized ones for GRUB and sendmail. There are many others that handle specific software or services, either included in the Debian package itself, or in a separate package. Here, however, we're concerned with more general utilities. The two main ones are dpkg-reeonfigure and gadmin.

One of the stability requirements for Debian is that when a package is installed, it should not adversely affect the system. Often, this is as simple as providing a standard configuration, such as Apache's simple It works! page. In other cases, however, at least some information must be provided during installation in order to create a basic, working configuration. This is handled by having the installation procedure ask the necessary questions during the installation process in order to create a working configuration.

Configuration files are placed in / etc by most software developers, and this is standard practice for Debian packages. If the file is fairly simple, and the only file required, it is often placed directly in / etc with a .conf extension, such as / etc/ inetd. conf for the openbsd-inetd package. For packages that require a more complex configuration, usually via multiple configuration files, those files are placed in a subdirectory of /etc which is generally named after the 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.

Most configuration files reside in the / ete directory hierarchy. In general, most packages place their configuration files in a subdirectory named after the software. In cases where the upstream developers do not do this, the Debian package usually modifies the behavior. A good example is the BIND DNS server software. Traditionally, the base configuration is placed in /ete/named. eonf, with any other configuration files placed in the /var/lib/named directory. The Debian BIND package places all configuration files in /ete/bind9 and its subdirectory.

Debian depends heavily on the configuration methods used by the upstream developers of each package, supplemented by the Debian developers' modifications and additions to standardize package configuration, and make the administrator's life easier. In this chapter, we will cover the standard location of configuration files, utilities available to assist in configuration, trends in configuration file management, and some examples.

The package managers in Debian make it easy to upgrade software packages, and even upgrade to a new, major release level. Upgrades don't require major server downtime, although if they involve major software changes that modify how the software is configured or behaves, additional work may be required after the upgrade to return service to normal. Non-Debian repositories can be added so that the package managers can update non-Debian software just as easily as official Debian packages.

Once the distribution upgrade is complete, there are still a few steps that should be taken. First, if the configuration file issues weren't resolved during installation, now is the time to do this. The new file is in the same place as the old one, with an added dpkg-new extension. Ifthe installer selected the developers' version, the old configuration is there with a dpkg-old extension. Either way, the administrator can check them for differences and make the necessary changes.

You've selected the packages to upgrade (or are performing an all at once upgrade), and started the process. The first thing to note is what packages are going to be removed. If one or more of them appear to be packages you need, cross-check them with the packages being installed to see if they are being replaced by a new package with similar functions. If they are not, make a note to follow the upgrade with a separate installation of whatever packages are required.