(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.
The FreedomBox configuration is a tricky part of the project. It should be simple and understandable. The configuration manager should provide:
Debian integration. the FreedomBox configuration should be integrated with and should not diverge from this distribution.
- a way to make configuration changes programmatically, safely, and immediately on the devices themselves (eg, an API called by higher level user interfaces),
- a way for developers to define defaults and track those defaults over time (eg, version control for the default/skeleton /etc directory)
- a way for owners to backup and restore entire configuration profiles/snapshots,
- a mechanism for independent package maintainers to define tweak-able variables as easily as possible (aka, minimize "repackaging" for use with FBx).
1. 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.
2. 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.
Other previous work includes
the very mature UCI (Unified Configuration Interface) from OpenWRT (which underlies the LuCI web interface and handles a lot of tricky problems),
deployment-oriented tools like [Puppet] and [Chef], Bcfg2, CFEngine, a
the recent Blueprint configuration reverse engineering tool (with interoperates with Chef and Puppet, handles manual changes, based on git and python).
DebConf is how the debian package system manages configuration of packages ("dpkg-reconfigure"),
Augeas is a C library to allow editing of many different text-based config file syntaxes through a single tree/node interface, and
Config::Modelis a newish set of Perl libraries that build upon the other two, as well as basic GUI and ncurses interfaces to those libraries.
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?).
1. 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:
- Configuration files generated that way can not be modified manually.
- The debconf database is stored in /var/cache and so we should not consider it persistant
Both of these issues can be solved using Config::Model
2. 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 :
- Identify which packages will be used for a given service or feature.
- See if a Config::Model backend exists for their configuration files.
- Write the missing ones.
- Push to the package maintainer patches to use Config::Model.
3. 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/Design/UserInterface
Next call: Sunday, October 24 at 17:00 UTC
This page is copyright its contributors and is licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.