On Sat, 07 Jun 2003 15:13:11 +0200, Luca Berra wrote: > > I would personally like a single framework for configuration, but all > frameworks i found in 13 years working on unix systems do suck far > more than vi.
The reason they all suck worse than vi is because they all aim far too low. They all aim to simply replace vi with a click'n'drool gui. Look at Webmin for example. It is pretty rich in the number of packages that it will configure, but the problem is that you still have to know what each of the packages' config options do. Some modules in Webmin do a pretty good job of linking a clickable help paragraph with each configurable item (Postfix is a great example), but you still have to sift through all of the items, understand them and then configure the right ones as per your intended functionality. If you are proficient at understanding how to configure Postfix (for example) to the level that you need to be to use Webmin, you likely are a sysadmin anyway and prefer the speed of vi. Webmin does nothing to ease the configuration of Postfix, or most of any of the other packages it supports. This is where a new configuration framework should aim higher. The focus of a newly designed configuration system should be about configuring "services" not packages. Frequently it takes many packages to provide a "service". Let's use e-mail for example. The packages involved (at a minimum) are an MTA, and authentication/authorization system and (possibly) a message store. So in a newly designed framework, the admin should simply have to configure an e-mail account, giving the particulars of the account, which then updates the authentication/authorization (/etc/password, or LDAP, or some SQL system, etc.), creates the message store for the account, initializes any system files, etc. This could be coupled with creating login accounts, or it could be stand-alone in the case of a "sealed-server" situation (i.e. mail accounts != login accounts). > I never asked for another web frontend, The actual gui part (front-end) should be built with interfaces to the configuration backend through an API, akin to the way DrakX works with GTK/newt/(minimally, http/html) > i am just stating that their > existance is caused by repeated failures of creating a decent framework, > or agreing on the need of one, we have tons of linux distros each with > it's own config framework, plus a good number of non distro related > tools. Right. And none of them are "service-centric", but rather each tool is built to administer one "package". > M$ did not have this problem, and did not even have to deal with 100+ > different configuration syntaxes, and 10+ different gui frameworks, > hence the better result. No, the better result is solely to do with building the tools with the right goal -- configuring complete services, not individual tools for each component of a service. Libconf _could_ achieve this if it keeps the goal in mind. From what little documentation I have found about it (is there anything more than what's in the wiki?), it could be on the right track, creating abstraction layers. The key will be to keep the goal of configuring "services" in sight. To continue on the example of e-mail, the sysadmin should be able to choose which MTA he wants to use as well as which message store he wants to use, as well as which authentication/authorization mechanism. Each component of a service should have a common API and each type of each component will need to write interfaces to that API. So for example, when the "e-mail" service is designed, an API for the MTA component could include _standard_ interfaces to specify "who-can-relay" permissions, message store hand-off specifications, "local delivery" domains, etc. Each type of each component (Postfix, Sendmail, Qmail MTAs for example) would need to have a module that implemented the API as per it's own configuration files. To complete the example, the API would include interfaces to configure the message store of choice, to create/change/delete accounts/folders, etc (some of which could be NOOPs if there was nothing additional that needed to be done). I could go on, but I think you get the idea. Thots? b.
