ideal config management framework [was: CPU Frequency Scaling]

Florin Andrei florin at andrei.myip.org
Tue Dec 5 19:41:40 UTC 2006


Matthew Miller wrote:

> I'm just not convinced that not being able to ssh in to a server and edit
> some config files but rather have to figure out how to tweak the
> policy-daemon-of-the-month is the user experience a large segment of "we"
> wants at all. Human-editable config files are a huge strength. Using a
> policy daemon may be part of the answer, but it should be able to get its
> configuration from something that can be fixed with vi.

Long-term, it's actually best for the sysadmin to only have to deal with 
_one_ interface for all configuration tasks. Automating config changes 
will be made consistent and trivial. Just think of it, you could run 
(fictional example) something like...

config-tool change <app-name> <config-key> <new-value>

...and presto! you just reconfigured the app. E.g.:

config-tool change apache ServerRoot "/foo/bar"

Or something like...

config-tool dump <app-name> | less

...and, well, it's self-explanatory.

Certain values in the <app-name> space could be reserved for system 
settings. E.g.:

config-tool change system-eth0 ip-address 192.168.2.7

How about this?

config-tool -remote some.other.server.com change <app-name> \
	<config-key> <new-value>

I would _love_ to be able to do that (if everything's correctly 
implemented, with security in mind, let's not be clueless morons, 
yadda-yadda).

I hate the freakin' text files with passion. It would be great if all 
config files had the same format, ideally either something along the 
lines of daemontools or djbdns (specially designed so automation is 
super-trivial), or heck I would even take XML - but only if it was 
universally used by all apps and system components.

Several different user-level tools could be implemented, offering 
different views into the same data, and different mechanisms to change 
the same settings:
- a command-line tool as exemplified above
- a text-based pseudo-GUI (think Midnight Commander)
- a true GUI, based on GTK or Qt or what have you
- APIs for PHP, Perl, Python, C, Java, etc. for Web interfaces or for 
direct access from within other apps
If push comes to shove, the configuration daemon could be stopped and 
the XML backend (or whatever) could be edited manually by those who 
really need to do that.

I am dreaming about this since... I don't know, maybe 1999 or so.

P.S.:
Please note that I'm not necessarily speaking of gconf in particular. 
I'm merely discussing the advantages of a well-written configuration 
management framework - which gconf may or may not be yet, I'm not 
familiar enough with it.

-- 
Florin Andrei

http://florin.myip.org/




More information about the fedora-devel-list mailing list