Fedora.next: I would like working configurations

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forwarding this to server at lists.fedoraproject.org as well. Responses
inline.


On 01/27/2014 07:35 PM, Oron Peled wrote:
> 
> 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...)

I realize you address this below somewhat, but I want to call out that
what you're describing here is the *presentation layer* of
configuration, not necessarily the configuration itself. In general,
the vast majority of applications keep their configurations in 1) a
set of text files, 2) a project-specific database or 3) a combination
of the two)

If projects provide a set of tools to manipulate this configuration,
that's separate from the configuration itself. As we start talking
about applying configuration to a system, we can reuse existing tools
where they make sense, but it's also reasonable to say that we might
choose to bypass them and use a tool such as Augeaus or Puppet to
apply the configuration we want.

> 
> 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).
> 

Yes, I agree. Simple package installation must not require
interaction. We should define that as a fundamental tenet of our
approach. We need it to always be possible to have unattended or
scripted operation.


> 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)

Yeah, obviously we'll need to maintain simple distinction about how we
maintain the data. Namespacing is one option. Another might be to use
an object-oriented API where we have objects associated with each
service (not necessarily package...) that have configuration options
specified as their attributes.


> * Each configuration option has specific *type* info (string,
> boolean, multi-select, etc.)

Extending the above, one of my thoughts on another thread on the
Fedora Server mailing list is to use D-BUS for the configuration API.
Among other things, we have the D-BUS object types to work with. This
would mean that we can have service-specific objects with
appropriately-typed options.


> * A package installation register its configuration options in a
> system-wide "database".

I'm not sure this makes sense. This would require us to maintain data
in two places, because zero existing packages would *retrieve* their
data from this location. We'd have a duplication problem and we would
also be responsible for bi-directional sync (if someone hand-edited a
configuration file, we'd need to read it back into the database).

I think it makes more sense to build an API around something like
Augeaus and rely on being able to read and write the configuration
that the packages already understand.


> * This also contains end-user visible text for each option
> including i18n.

I think it would be better to handle this at the API layer, rather
than in a database.


> * The debconf database may be populated via different front-ends: 
> GUI, TUI, command-line, web-based (experimental), preseed (for
> "kickstart" install).
> 

Again, if we build a sensible API, it should be possible to build
whatever presentation layer we want to atop it. Of note, we're
planning to work with the Cockpit Project for our reference
implementation.


> * 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)
> 

I don't agree with this. Providing just a text entry box and a
description isn't an effective UI technique, particularly if you want
to be able to produce guided or wizard-based operation. (For example,
if you have branching decisions during configuration).


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

See above for the sync problem with this.

> 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.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLnr2IACgkQeiVVYja6o6PakwCeP8H/i/yakvVZhCXI0qSo1k84
tSwAn3rMeLFL6/FigFgk7LYqPwPA5OlQ
=/tjT
-----END PGP SIGNATURE-----