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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
