Fedora.next: I would like working configurations

[Robert M. Albrecht]

Hi,

THAT would be worhty of being called Fedora.Next .

cu romal


Am 28.01.14 01:35, schrieb 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.
>