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/
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
