Configuration Files, Alternatives and Package Hooks

An upgrade asks whether to keep a locally modified configuration file. Choosing the package maintainer’s version can remove local behavior; keeping the local version can omit a new required setting. The correct choice depends on the actual change, the service and a tested rollback plan.

This chapter uses bl05-packages-lab from the preceding chapters. It inspects package configuration and alternatives, then removes the tree package that the lab deliberately installed. It does not alter a real service configuration or force a conffile prompt.

A conffile is a package-managed configuration file

A Debian package can mark selected files as conffiles. dpkg tracks the installed package version and can ask what to do when both the administrator and a new package version changed a conffile. Not every file under /etc is a dpkg conffile: packages and applications also generate or manage configuration by other mechanisms.

Inspect the package’s recorded conffile information:

dpkg-query -W -f='${binary:Package}\n${Conffiles}\n' apt

The output can contain paths and recorded checksums; it does not show an intelligible three-way diff or prove that a service accepts its current configuration. If the field is empty, choose another installed package known to have conffiles rather than fabricating a path. The dpkg manual describes conffile handling and package states.

Before a real upgrade, record the service’s current configuration, package version, dependencies, validation command and recovery path. During a conffile prompt, inspect the displayed difference and consult the package’s instructions. Common choices can keep the local file, install the maintainer’s file, or inspect differences; available prompts and defaults depend on the operation and options. Keep a protected backup and test the resulting service behavior. Blindly accepting either side is not a merge strategy.

Files with suffixes such as .dpkg-dist, .dpkg-old or .dpkg-new can be evidence of a package operation, but their presence and exact meaning depend on the operation. Review the actual files before deleting or merging them. Configuration can contain secrets; restrict access and redact differences before sharing.

Maintainer scripts and triggers

Packages can run maintainer scripts during installation, configuration, upgrade and removal. Triggers allow one package to request deferred work from another; package state can remain pending while that work is incomplete. These scripts can affect generated files or services that are not listed as ordinary package payload paths.

Inspect the available control files for the installed apt package:

dpkg-query --control-list apt

If postinst appears in the list, inspect it without executing it:

dpkg-query --control-show apt postinst

A missing script is normal for some packages. The dpkg-query manual documents these read-only control-file queries. A script’s content is not a transaction preview; its execution depends on package state, arguments, dependencies and environment. Never run a maintainer script manually just to see what it does.

When a transaction fails, capture the package state and exact script error. A partially configured package and a fully configured package with a broken application are different conditions. The later interrupted-transaction chapter covers controlled recovery; do not force a package state or remove scripts from the database to silence an error.

Alternatives select an implementation

The alternatives system can present a common name that points through managed symbolic links to one of several implementations. Automatic mode generally follows configured priorities; manual mode retains a selected choice until an administrator changes it. Inspect the editor group if present:

update-alternatives --display editor
ls -l /usr/bin/editor /etc/alternatives/editor
readlink -f /usr/bin/editor

An unavailable alternatives group or path is a result to investigate, not a reason to create one. The update-alternatives manual describes link groups and modes. Package ownership of the final executable, an alternatives selection, and a user’s EDITOR environment variable can all affect what is actually invoked. Inspect the relevant caller before changing the system default.

This operation is read-only. A real alternatives change should identify the owner and consumers, record the previous mode and selection, test the affected application and provide a rollback. Not every Ubuntu command is managed by alternatives; for example, distribution provider selection may use other packaging mechanisms.

Lab: finish and remove the test package

The earlier chapters installed tree only after confirming it was absent, then removed its temporary hold. Reconfirm those assumptions on the clone:

hostnamectl
dpkg-query -l tree
apt-mark showhold

Proceed only if the manager identifies bl05-packages-lab, tree is the test package installed during this lab and it is no longer held. If the original state is uncertain, stop; do not remove a package merely because it is named tree.

Preview removal:

sudo apt-get -s remove tree

Read the whole proposed transaction. If it removes anything other than the intended test package or reports unexpected dependency consequences, stop and investigate. When the actual proposal is understood:

sudo apt remove tree

Review the real confirmation before accepting. Do not run autoremove or purge as part of this exercise: dependencies or configuration can have other owners and retention requirements. Verify the package state and command result:

dpkg-query -l tree
command -v tree
sudo dpkg --audit

command -v tree may return no output and nonzero if no other executable with that name is on PATH; that is expected for this clean lab. A removed package can leave configuration records, and another installation mechanism could provide a command with the same name. Record the actual state and investigate any discrepancy. End with the clone powered off before restarting bl02.

Worked diagnosis: a service changed after upgrade

Suppose a service fails after its package upgraded. Compare the transaction time, package version, service logs and configuration validation. Check whether a conffile was kept, replaced or left with an alternate version, and whether a maintainer script or trigger failed. Restore or merge only after understanding which configuration belongs to the new version. Then restart through the service’s documented procedure and repeat a client-side acceptance test.

Replacing all of /etc from an old backup or downgrading a package without accounting for data-format changes can create further failures. Preserve the evidence and use the service’s supported recovery plan.

Practice and recall

Record one package’s conffile field, one available control-file name, the editor alternatives state if present, and the test package’s before/after removal state. Explain why none of those alone proves the application is working.

• A conffile is one package-management mechanism, not every configuration file.
• Maintainer scripts and triggers can change state beyond a file list.
• Alternatives, package ownership and an environment override are different selection layers.
• Preview removal and verify the actual resulting state; do not assume purge or autoremove is harmless.