-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Forwarding this to server(a)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-----