Configuration file handling

5.3.3 Configuration file handling

As I mentioned earlier, the package may contain two types of files: those installed and subsequently managed bydpkg, and so-calledconffiles— configuration files which are expected to be modified by the user. When unpacking,dpkghappily overwrites existing files of the first type. Configuration files, however, are handled specially:

1. During the package’s unpack phase,dpkginstalls all files marked asconffile to their target locations, but gives each a.dpkg-newextension to prevent clashes with any existing files.

2. When configuring the package,dpkgchecks each existing configuration file for modifications (using a set ofMD5checksums; see below). If modifica-tions are found, the administrator must choose whether to overwrite or keep the local file.

3. If the local file is kept, the new configuration file (installed with the .dpkg-newextension) is renamed with the.dpkg-distextension.

4. If the local file is to be replaced by the configuration file from the package, it is given the.dpkg-oldextension and left in place as a backup.

For example, theabcdepackage provides/etc/abcde.conf, which is flagged as a configuration file. Thus,dpkghandles it appropriately:

˜# dpkg --unpack abcde_2.0.3-1_all.deb

(Reading database ... 59575 files and directories currently installed.) Preparing to replace abcde 2.0.2-1 (using abcde 2.0.3-1 all.deb) ...

Unpacking replacement abcde ...

˜# ls -F /etc/abcde.conf*

/etc/abcde.conf /etc/abcde.conf.dpkg-new

˜# dpkg --configure abcde Setting up abcde (2.0.3-1) ...

Installing new version of config file /etc/abcde.conf ...

If the administrator had made changes to the file,dpkgwould have asked before taking any action (the first command simply appends a line to the file, thereby simulating a modification):

˜# echo >> /etc/abcde.conf

˜# dpkg --unpack abcde_2.0.3-1_all.deb

(Reading database ... 59575 files and directories currently installed.) Preparing to replace abcde 2.0.2-1 (using abcde 2.0.3-1 all.deb) ...

Unpacking replacement abcde ...

˜# dpkg --configure abcde Setting up abcde (2.0.3-1) ...

Configuration file ‘/etc/abcde.conf’

==> Modified (by you or by a script) since installation.

==> Package distributor has shipped an updated version.

What would you like to do about it ? Your options are:

Y or I : install the package maintainer’s version N or O : keep your currently-installed version

D : show the differences between the versions Z : background this process to examine the situation The default action is to keep your current version.

*** abcde.conf (Y/I/N/O/D/Z) [default=N] ? y

Installing new version of config file /etc/abcde.conf ...

Identifying change

dpkgonly prompts on changed configuration files if it is about to install a config-uration file that has changed from the previous version it installed. If the adminis-trator removes a configuration file from the system,dpkgalso prevents trouble: if a previous configuration file is not present, it will not reinstall it. If, however,dpkg upgrades a package and installs a configuration file that differs from the previous one, it will prompt. If the user opts to replace the file, everything continues as before. If, however, the user chooses to preserve the local modifications,dpkgwill continue to prompt the administrator whenever the package is upgraded, whether the maintainer-provided configuration file changed or not.

In pseudo code:

Mp <= stored MD5 sum of configuration file from package of previous version Mn <= MD5 sum of new configuration file,

extracted from the package

Ml <= MD5 sum of locally installed configuration file if Mn != Mp

then: # the maintainer provides a new file if Ml != Mp:

then: # the administrator made local changes A <= action desired by administrator if A == install

then: # admin chose to replace file

install new version of configuration file end if

else: # the local file was not changed install new version of configuration file end if

let Mp = Mn # make the new version the next previous else: # the new package does not update the file

do nothing end if

It is entirely up to the you as the administrator to decide whatdpkg should do when a new version of a package provides updated configuration files which con-flict with the locally modified ones. If you choose to keep your locally edited copy of theconffile,dpkgwill install the new version next to the one you decided to keep, using the.dpkg-distextension to the filename. You may return at a later time to inspect the new configuration file and merge your old configuration into it. If, however, you choose to replace your local file with the new version from the package being installed,dpkgsaves the file with your changes with the.dpkg-old extension, allowing you to refer to the locally modified file later.

The Debian utilities know about the possible existence of these files and ignore them. Therefore, there is no danger in leaving stray.dpkg-distor.dpkg-oldfiles around. Nevertheless, when another package upgrade comes around, itwill over-write existing.dpkg-distand.dpkg-old(if you’ve edited the configuration since the last update), so it is always a good idea to tend to configuration files and re-move the ones with a.dpkg-*extension if you will not need them again. A simple command can then help you identify configuration files that need manual migra-tion:

˜# find /etc -name ’*.dpkg-*’

Merging configuration files (or not)

Often, users complain that even thoughdpkgpreserves changes made to files, it provides no way to merge new configuration directives from updated configuration files provided by newer versions of a package. For instance, take the following configuration file, in which the administrator replaced the previous nickname with

“madduck”:

˜$ cat /etc/foo.conf NICKNAME=madduck

In a newer version of thefooprogramme, the configuration file also specifies the server to which to connect. The package includes the following file:

˜$ cat /etc/foo.conf NICKNAME=gort

SERVER=barada.nikto.org

In an ideal world,dpkgwould offer to merge the files to produce a version with the (unchanged) server directive, but with “madduck” as the nickname.

Unfortunately, the variety of configuration paradigms found across a Unix system make this virtually impossible; one would have to givedpkgknowledge of every configuration file that it should ever merge, including (but not limited to) its struc-ture and its syntax. Then, when a configuration paradigm changes, dpkgwould need to be updated.

Beyond standardisation of configuration files across all of Unix (which is not going to happen), the only sensible approach to this task is the automatic generation of configuration files from values stored and maintained in a database or registry.

Debian purposely does not go down that road because it aims to bring the software to the user with minimal modifications. If you install thepostfixpackage, you get thepostfixmail transport agent in much the same way as if you were to build and install it yourself. A seasonedpostfixadministrator would never consider running a mail server with Debian GNU/Linux if it required configuration through a database, possibly imposing limitations on the configuration syntax.