Fedora.next: I would like working configurations
Robert M. Albrecht
lists at romal.de
Tue Jan 28 12:36:23 UTC 2014
THAT would be worhty of being called Fedora.Next .
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.
More information about the devel