debconf (7) - Linux Manuals
debconf: Debian package configuration system
NAME
debconf - Debian package configuration systemDESCRIPTION
Debconf is a configuration system for Debian packages. There is a rarely-used command named debconf, documented in debconf(1)Debconf provides a consistent interface for configuring packages, allowing you to choose from several user interface frontends. It supports preconfiguring packages before they are installed, which allows large installs and upgrades to ask you for all the necessary information up front, and then go do the work while you do something else. It lets you, if you're in a hurry, skip over less important questions and information while installing a package (and revisit it later).
Preconfiguring packages
Debconf can configure packages before they are even installed onto your system. This is useful because it lets all the questions the packages are going to ask be asked at the beginning of an install, so the rest of the install can proceed while you are away getting a cup of coffee.If you use apt (version 0.5 or above), and you have apt-utils installed, each package apt installs will be automatically preconfigured. This is controlled via /etc/apt/apt.conf.d/70debconf
Sometimes you might want to preconfigure a package by hand, when you're not installing it with apt. You can use dpkg-preconfigure(8) to do that, just pass it the filenames of the packages you want to preconfigure. You will need apt-utils installed for that to work.
Reconfiguring packages
Suppose you installed the package, and answered debconf's questions, but now that you've used it awhile, you realize you want to go back and change some of your answers. In the past, reinstalling a package was often the thing to do when you got in this situation, but when you reinstall the package, debconf seems to remember you have answered the questions, and doesn't ask them again (this is a feature).
Luckily, debconf makes it easy to reconfigure any package that uses it.
Suppose you want to reconfigure debconf itself. Just run, as root:
This will ask all the questions you saw when debconf was first installed.
It may ask you other questions as well, since it asks even low priority
questions that may have been skipped when the package was installed.
You can use it on any other package that uses debconf, as well.
This frontend has some special hotkeys. Pageup (or ctrl-u)
will go back to the previous question (if that is supported
by the package that is using debconf), and pagedown (or
ctrl-v) will skip forward to the next question.
This is the best frontend for remote admin work over a slow
connection, or for those who are comfortable with unix.
Do keep in mind that this is not a very secure frontend.
Anyone who has access to the computer being configured
can currently access the web server and configure things
while this frontend is running. So this is more of a
proof of concept than anything.
You can change the default frontend debconf uses by reconfiguring
debconf. On the other hand, if you just want to change the frontend
for a minute, you can set the DEBIAN_FRONTEND environment variable to
the name of the frontend to use. For example:
The
dpkg-reconfigure(8)
and
dpkg-preconfigure(8)
commands also let you pass
--frontend=
to them, followed by the frontend you want them to use.
Note that not all frontends will work in all circumstances. If a frontend
fails to start up for some reason, debconf will print out a message
explaining why, and fall back to the next-most similar frontend.
Only questions with a priority equal to or greater than the priority you
choose will be shown to you. You can set the priority value by
reconfiguring debconf, or temporarily by passing
--priority=
followed by the value to the
dpkg-reconfigure(8)
and
dpkg-preconfigure(8)
commands, or by setting the DEBIAN_PRIORITY environment variable.
You should really read
debconf.conf(5)
before this section, as you need to understand how debconf's databases work.
The easiest way to set up the database is to install the packages on one
machine and answer their questions as usual. Or you might just use
dpkg-preconfigure(8)
to configure a set of packages without actually installing them. Or you
might even decide to write a plain text debconf database by hand or
something.
Once you have the database, you need to figure out how to make
the remote systems use it. This depends of course on the configuration of
those systems and what database types they are set up to use.
If you are using the LDAP debconf database, an entire network of debian
machines can also have any or all package installation questions answered
automatically by a single LDAP server.
But perhaps you're using something a little bit easier to set up like, say,
the default debconf database configuration, or you just don't want your
remote systems to use LDAP all the time. In this case the best approach is
to temporarily configure the remote systems to stack your database
underneath their own existing databases, so they pull default values out of
it. Debconf offers two environment variables, DEBCONF_DB_FALLBACK and
DEBCONF_DB_OVERRIDE, to make it easy to do this on the fly. Here is a sample
use:
This makes the debconf on the remote host read in the data that is piped
across the ssh connection and interpret it as a plain text format debconf
database. It then uses that database as a fallback database -- a
read-only database that is queried for answers to questions if the system's
main debconf database lacks answers.
Here's another way to use the DEBCONF_DB_FALLBACK environment variable:
Here ssh is used to set up a tunneled LDAP connection and run debconf.
Debconf is told to use the LDAP server as the fallback database. Note the
use of "{host:localhost}" to configure how debconf accesses the LDAP
database by providing the "host" field with a value of "localhost".
Here's another method:
Here you copy the database over with scp, and then ssh over and make
debconf use the file you copied over. This illustrates a shorthand you can
use in the DEBCONF_DB_FALLBACK parameters -- if a field name is left off, it
defaults to "filename".
There is only one problem with these uses of the DEBCONF_DB_FALLBACK parameter:
While the fallback database can provide answers to questions the other
debconf databases have never seen, it is only queried as a fallback; after
the other databases. If you need to instead temporarily override an
existing value on the remote host, you should instead use the
DEBCONF_DB_OVERRIDE variable. Like DEBCONF_DB_FALLBACK, it sets up a temporary
database, but this database is consulted before any others, and can be used
to override existing values.
Briefly, debconf communicates with maintainer scripts or other programs
via standard input and output, using a simple line-oriented command language
similar to that used by common internet protocols such as SMTP. Programs use
this protocol to ask debconf to display questions to the user, and retrieve
the user's answers. The questions themselves are defined in a separate file,
called the "templates file", which has a format not unlike a debian control
file.
Debian packages which use debconf typically provide
both a templates file and a "config" script (run to preconfigure the
package) in the control metadata section of the package.
Thus, this uses the fallbackdb in debconf.conf:
While this sets up a new database of type File, and tells it a filename to
use and turns off backups:
And as a shorthand, this sets up a database of type File with a filename:
Note that if a fallback database is set up on the fly, it will be read-only
by default.
If you do file a bug report, be sure to include the following information:
Frontends
One of debconf's unique features is that the interface it presents to
you is only one of many, that can be swapped in at will. There are many
debconf frontends available:
Priorities
Another nice feature of debconf is that the questions it asks you are
prioritized. If you don't want to be bothered about every little thing,
you can set up debconf to only ask you the most important questions.
On the other hand, if you are a control freak, you can make it show
you all questions. Each question has a priority. In increasing order of
importance:
Backend Database
Debconf uses a rather flexible and potentially complicated backend
database for storing data such as the answers to questions. The file
/etc/debconf.conf
is used to configure this database. If you need to set up something
complicated, like make debconf read a remote database to get defaults,
with local overrides, read the
debconf.conf(5)
man page for all the gory details. Generally,
the backend database is located in
/var/cache/debconf/
Unattended Package Installation
If you have many machines to manage you will sometimes find yourself in the
position of needing to perform an unattended installation or upgrade of
packages on many systems, when the default answers to some configuration
questions are not acceptable. There are many ways to approach this; all
involve setting up a database and making debconf use it to get the answers
you want.
cat
ssh root [at] target
Developing for Debconf
Package developers and others who want to develop packages that use
debconf should read
debconf-devel(7)
ENVIRONMENT
BUGS
Probably quite a few, there's a lot of code here.
AUTHOR
Joey Hess <joeyh [at] debian.org>