Okay, this is gonna be a short one.

If you’ve used Debian/Ubuntu on a server before, you’ve probably already run into popups asking you various questions during package installations. Have you ever wondered what happens if you try to automate it ?

Well, basically, nothing good for you.

Initial situation

I have an ansible playbook to provision a laptop, typically used when a new dev arrives. Among other things, this playbook installs Virtualbox.

The corresponding ansible config is pretty straighforward :

- name: Install virtualbox and extpack
  apt:
    state: latest
    name:
      - dkms
      - virtualbox
      - virtualbox-dkms
      - virtualbox-ext-pack

Until recently, this just worked, but today, it broke during the installation of virtualbox-ext-pack with the following error message :

[…]
Preparing to unpack .../virtualbox-ext-pack_5.2.34-1~ubuntu18.04.1_all.deb ...
User did not accept the license.
dpkg: error processing archive /var/cache/apt/archives/virtualbox-ext-pack_5.2.34-1~ubuntu18.04.1_all.deb (--unpack):
 new virtualbox-ext-pack package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/virtualbox-ext-pack_5.2.34-1~ubuntu18.04.1_all.deb

Yeah, I suppose Oracle added a new license to accept. Not exactly surprising, but still quite annoying.

Let’s just make sure and install it manually :

apt-get install virtualbox-ext-pack

This command gave me a fullscreen ncurses interface asking to accept the license, then worked just fine.

Enter debconf

You may have noticed there was an important difference between the two install tentatives : the automated one did not get the fullscreen popup asking for the licence. Instead, it failed directly.

That’s because it’s not just made with a custom postinst script made by the package manager. It leverages a standard tool of the debian ecosystem : debconf.

This is a standardized configuration system that allow you to configure many debian packages requiring configuration, and that’s what actually gives you these fullscreen popups most of the time. The reason why it failed directly is because it’s properly integrated with dpkg/apt, and able to understand that this session is not interactive, so there’s no point in opening a popup (which would make the install hang).

The fact that the user license acceptance is configured via debconf (and not some custom script) is very good news for us, because there are other ways to interact with the debconf database.

Interacting with debconf

Let’s dive into the debconf database !

It’s actually pretty simple, here’s a command to dump the entire debconf database to the terminal in text format :

debconf-copydb configdb stdout --config=Name:stdout --config=Driver:Pipe --config=InFd:none

This command can obviously do way more than just dump the whole database to your terminal, but that’s enough for our needs.

Since the list is pretty long, let’s just open it in vim instead :

vim <(debconf-copydb configdb stdout --config=Name:stdout --config=Driver:Pipe --config=InFd:none)

We can easily find the key we want to configure in here :

Name: virtualbox-ext-pack/license
Template: virtualbox-ext-pack/license
Value: true
Owners: virtualbox-ext-pack
Flags: seen

All in all, pretty straightforward once we know what we’re looking for.

Automating the configuration

Back to my example.

There’s an ansible module for debconf, just perfect ! This way, I won’t have to monkey around with the debconf cli to set the option.

Let’s just add this to my playbook :

- name: Accept virtualbox license
  debconf:
    name: virtualbox-ext-pack
    question: virtualbox-ext-pack/license
    vtype: select
    value: 'true'

- name: Install virtualbox and extpack
  apt:
    state: latest
    name:
      - dkms
      - virtualbox
      - virtualbox-dkms
      - virtualbox-ext-pack

A few things to notice here :

  • The “seen” flag is automatically set by this task, I did not need to add it myself
  • Quoting the “true” is essential, else ansible will interpret it as a boolean, and capitalize it. Which is not valid for debconf.
  • This task is idempotent, allowing for a clean playbook

Try it out

Reinstalling entirely the machine to test this config is a bit overkill.

Instead, purging the package does the job :

apt-get purge virtualbox-ext-pack

You can re-run the debconf dump command given above, and check for yourself that the configuration is gone.

Re-running the playbook now installs everything properly without any failure.

Yay \o/

Further reading

Here are a few extra resources that helped me understand what was happening :