(from a mailing list discussion)

General purpose "Configuration Management" seems to be a crucial component of the FreedomBox software stack/distribution. It needs to be secure, accessible (elegant user experience for diverse userbase), reliable, robust, etc.

If the idea is to build the FreedomBox on top of Debian, with as little modification as possible, using package configuration to setup services makes a lot of sense. This requires pushing in every used package what's necessary so that it can handle the FreedomBox use case.

Requirements

The FreedomBox configuration is a tricky part of the project. It should be simple and understandable. The configuration manager should provide:

Nice to Avoid

One common problem with the configuration of a Debian system happens when the user has changed some options, and installed a new version of the Debian package. The change is detected and the user gets prompted by a not-so-intuitive interface.

Nice to Have

It would be a nice feature if users could "undo" configuration changes atomically. It's unclear to me if we need fine grained access control to system-wide configuration or if this is all owner/root level (eg, should installed packages be allowed access to the centralized configuration interface?). It's also unclear how to handle syntax or logical errors with configuration.

Existing approaches

Other previous work includes

Implementation Ideas

Use some combination of DebConf, Config::Model and Augeas to manage and implement configuration.

I'm not sure what Plinth calls down to right now, but I assume it would call in to Config::Model (via a Python wrapper?).

Debconf preseeding

Configuration values can be pushed into debconf prior to the installation of packages, using debconf-set-selections. Using debconf and ucf in the maintainer scripts in order to generate configuration files allows the process to be completely automated.

With this approach, programatically changing a configuration value after the package is installed is possible by inserting the new value into debconf and running dpkg-reconfigure.

There are a couple of drawbacks:

Both of these issues can be solved using Config::Model

Configuration model

Using Config::Model would allow us to easily generate configuration files based on the contents of the debconf database. It would also allow for manual editing of configuration data.

There is actually a proposal in Debian to use Config::Model as a mechanism to merge user changes and package configurations (see PackageConfigUpgrade). Some packages of the Debian archive are already using Config::Model (openssh, approx,...).

That would help to smoothly manage conflicts in package configuration, as well as help to programatically configure services depending on simpler choices asked from the users.

Working with Config::Model to configure packages requires some work :

Debconf web frontend

In the cases where we can not provide sensible defaults or if the user needs to change a configuration parameter, debconf package installation/upgrade questions must be shown in the FreedomBox web interface.

Debconf already has a minimal web frontend, but the current implementation is more of a proof of concept than a robust workable solution.

For security reasons, the debconf web server listens only on the local host. Still, there are ways to workaround this issue so that debconf web frontend output gets integrated into the FreedomBox interface (Setting up a reverse proxy with some kind of authentication for instance)

See also FreedomBox/UserInterface


CategoryFreedomBox