Copy debconf Databases with debconf-copydb

Copying debconf answers is easy to get wrong, because debconf-copydb will happily write your source's secrets somewhere you did not intend. The examples use package version 1.5.86ubuntu1, installed on this machine. Allow about fifteen minutes if the destination format is already clear, or longer if you need to design a new database stanza.

You will copy all or selected entries from one debconf database into another, including a destination defined only on the command line.

• You need: a shell and the debconf package.
• Privileges: read-only inspection normally needs none.
• Sensitivity: copies can expose package configuration, including answers that should not be shared, so treat output files and streams as sensitive.

1. Check the installed command

The command takes a source database name, a destination database name, and optional filters or configuration overrides:

$ command -v debconf-copydb
/usr/bin/debconf-copydb
$ dpkg-query -W -f='${Package} ${Version}\n' debconf
debconf 1.5.86ubuntu1
$ debconf-copydb --help
Unknown option: help
Usage: debconf-copydb sourcedb destdb [--pattern=pattern] [--owner-pattern=pattern] [--config=Foo:bar]

That last result is expected. The program has no conventional --help option, so use the installed manual page for the option contract rather than guessing at extra flags.

2. Preview a narrow slice

Database names usually come from debconf.conf or .debconfrc. The common source name configdb refers to the system's configured debconf database. Before copying anything, pick a package prefix you recognise. This read-only command sends matching records to a pipe driver and writes them to standard output:

$ debconf-copydb configdb stdout \
    --config=Name:stdout \
    --config=Driver:Pipe \
    --config=InFd:none \
    --pattern='^example-package/'

Replace example-package with a real owner or item prefix. An empty result means the pattern matched nothing, not that the source database is empty. The command can print warnings when a configured database is unreadable. On this machine, an unprivileged read also warns about the protected passwords database. Take warnings as a cue to check access and sensitivity, not as permission to copy blindly.

3. Copy into an existing destination

If the destination stanza already exists in your debconf configuration, the smallest command is:

$ debconf-copydb configdb backup --pattern='^example-package/'

Here backup is a configured database name, not a filename. The two databases' drivers may use different formats, and the program converts between them. Check the destination's own driver documentation and permissions first. This changes the destination database, so it may need elevated privileges depending on where that database lives. It does not alter the source.

4. Define a scratch file destination

Repeated --config options let you build a destination stanza on the fly. That suits a scratch export and avoids editing a global configuration file:

$ dest='/tmp/debconf-example.dat'
$ debconf-copydb configdb newdb \
    --pattern='^example-package/' \
    --config=Name:newdb \
    --config=Driver:File \
    --config=Filename:"$dest"
$ test -f "$dest" && ls -l "$dest"
-rw------- 1 user user 1234 ... /tmp/debconf-example.dat

Size and timestamp vary. A zero-byte file is possible when the pattern matches no records, so check the pattern separately rather than treating file creation as proof that data was copied. The File driver writes the destination database at the path in Filename.

Quote a path that comes from a variable. Do not place untrusted text directly into a --config argument without deciding how it should be parsed. Each --config option sets one field, and a Name:dbname option starts a new stanza, so build one complete destination stanza before adding another.

5. Export to standard output

The pipe driver helps when another process will receive the database, or when you want to inspect a small selection without creating a file:

$ debconf-copydb configdb stdout \
    --config=Name:stdout \
    --config=Driver:Pipe \
    --config=InFd:none \
    --pattern='^example-package/' > example-package.debconf
$ test -s example-package.debconf && echo 'export is non-empty'
export is non-empty

Redirect standard output only after checking the pattern. Shell redirection truncates an existing file before debconf-copydb even starts, so use a new pathname or copy the old file aside first. If the command fails, discard the incomplete export and keep the original backup.

6. Copy through a remote pipe

The manual documents a pipe-driver arrangement for a remote system. The local process writes the selected database to standard output, and an SSH command feeds that stream into a remote debconf-copydb:

$ debconf-copydb configdb pipe \
    --config=Name:pipe \
    --config=Driver:Pipe \
    --config=InFd:none \
    --pattern='^example-package/' | \
    ssh remotehost debconf-copydb pipe configdb \
    --config=Name:pipe \
    --config=Driver:Pipe

If the remote command fails, do not assume the local half was harmless. Inspect both exit statuses and the remote destination before retrying. Use an explicit SSH account and host policy rather than embedding credentials in the command.

7. Filter by owner instead

Some jobs are easier to express by owner. Combine the owner filter with a destination definition just as you would --pattern:

$ debconf-copydb configdb newdb \
    --owner-pattern='^example-package$' \
    --config=Name:newdb \
    --config=Driver:File \
    --config=Filename:'/tmp/example-owner.dat'

Use anchors when you mean one exact owner. Without them, a broad regular expression can pull in similarly named packages.