-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forwarding this to server@xxxxxxxxxxxxxxxxxxxxxxx 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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
