Fedora.next: I would like working configurations

[Oron Peled]

On Monday 27 January 2014 14:01:32 Stephen Gallagher wrote:
> ...
> or some mechanism to interactively configure and deploy a DHCP server.

IMO, that's exactly the crux of the matter. Most non-trivial services
requires some administrative decisions to configure them properly.

Since rpm does not allow interactive query of the user (IMO rightfully),
everybody implement custom solutions:
 * Some custom scripts (e.g: freeipa-server-install)
 * Only hand configuration (e.g: dhcpd)
 * Some web-based PHP configuration (many php web-applications that look
   for an easy solution to a tough problem and forget about security
   along the way...)

Just like packaging systems implemented a common framework to install
software, we need a common framework to *configure* it (at least
base configuration if the full configuration management problem
is too tough).

My suggestion is to look first at the "debconf" abstract model.

Let's start with one design decision which I think we should avoid:
 * Debian triggers debconf operations from the package installer.
   This means package installation is potentially interactive (not good).
   I think the configuration mechanism should be explicitly called
   from elsewhere. (e.g: when administrator want to activate/configure
   the service).

But now, let's look at the good properties which we can learn from:
 * All configuration options are name-spaced (in debconf it's done by package name)
 * Each configuration option has specific *type* info (string, boolean, multi-select, etc.)
 * A package installation register its configuration options in a system-wide "database".
 * This also contains end-user visible text for each option including i18n.
 * The debconf database may be populated via different front-ends:
     GUI, TUI, command-line, web-based (experimental),
     preseed (for "kickstart" install).

 * All front ends need only understand the generic types of the options.
   (I.e: they provide generic configuration UI widgets which aren't modified
   when new packages/options are added)

 * The debconf "API" allows fetching any option from the database and the
   values of these options are used to configure the actual software.

Note: I tried to abstract away the properties, because I don't think the
      debconf *implementation* fits what we need.

      However, the model shows how very different packages can use a common
      framework for basic configuration, just like RPM shows how very
      different packages can use a common framework for installation.

Having such a framework would allow a *standard* way of configuring a set
of packages for specific roles.

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
"I love deadlines, especially the whooshing sound they make as they go by." 
      -- Douglas Adams