I find it hard to believe no one else sees the current
complexity of system/application configuration as undesirable? Is
this problem too big to be addressed? Is there too much historical
precedence involved? Or is there a solid technical reason for not having
a standardized configuration file format?
Linux is perceived to be "difficult" to configure and managed by many,
this is not because we lack guis and wizards, rather because one must
discover the process each subsystem and application uses to
accept configure directives from its users.
I see no reason why it would not be possible and desirable to have a
plain text compatible configuration file standard that is universal
between subsystems, services and applications (besides it being a lot of
work). It seems to me that the complexities of existing configuration
tools (authconfig, system-config-samba etc...) are largely due to this
same fundamental issue.
Cheers,
Shane
On Sat, 25 Mar 2006, Shane Stixrud wrote:
Greetings,
This message to the Fedora Development Community is an attempt to start a
useful discussion on where Fedora/RHEL is today and where it is going in the
future, on the subject of OS management. My apologies in advance for the long
message.
OS management is a very broad topic, in specific I will focus on the elements
that I consider foundational weaknesses (compared to what it could be). This
is not to imply these perceived "weaknesses" out weigh its strengths or that
other OS's are overall superior in this regard.
A bit of background to put my technical comments in perspective:
I remember when I was first introduced to Unix (1992) and then later Linux
(1993) compared to what I was used to at the time they combined a
flexibility, functionality and a form of simplicity (in design) that when
combined made all other operating systems seem hallow. For the most part I
still feel this way today, but over the years having worked in enterprise
environments where Linux is the up and coming challenger to entrenched
non-unix platforms (VMS, Windows, zOS, etc...) I have come to better
appreciate some of the elements involved in limiting Linux's adoption.
I was recently tasked with standardizing/documenting our Linux server
build/configuration process and as part of this process began training some
of our Windows/Novell administrators to be able to carry out some of these
basic tasks. It was this second part of helping train people that caused me
to examine and re-examine the processes I used for this standardization.
My goal was simple in theory, I would use pxe+kickstart and enforce standard
configurations and policies via a series of post scripts while attempting to
keep readability, simplicity and supportability from a "non-unix guru"
perspective as my guiding light (A wise man once said: Make it as simple as
possible but no simpler). For those interested an example of what I came up
with it can be obtained here: http://geeklords.org/~shane/kickstart
The process turned out to be not quite as simple as the theory but very
educational none the less. To start with I had a number of ways I could
manipulate my fresh Linux install.
1) I could create a custom RPM that had all of the changes imbedded in config
files and rpm scripts that merely overwrote the pre-existing ones. Problem
being this approach hides the complexity of what all was being changed and
why.
2) Use cfengine after the kickstart install. This of course has some
advantages over the rpm method but it also hides the same complexity and adds
some of its own.
3) Document on paper all of the steps required and how to perform them from
the console, taking advantage of the guis when available or command line when
required. I felt that was not only a big waste of time but left far too much
to human error.
4) Create a series of simple scripts using basic OS applications/tools (sed,
echo, cp, mv, authtool, postconf etc...) to perform all of the required
modifications, documenting what and why along the way.
I choose method 4.
My conclusion having completed this process is that the number of variables,
complexity and dependencies that must be understood and taken into account
when modifying configuration files is much higher than it needs to be. I
think this should be clear when reading the example scripts mentioned above.
Some things I learned:
Sed is a wonderful tool, but it is highly limited by the fact its user must
take into account whole file(s) for each expression, this is further
complicated when one must consider the file may change over time. The
complexity and readability of regular expression tools is much higher than
should be required to change OS/application variables.
Creating new files or appending to the end of existing files with "echo" only
takes one so far. This also tends to have the cost of hurting readability as
it is often the case you would prefer putting data somewhere else in the file
(i.e. sed).
The nature of flat configuration files where each application has its own
format is such where recovery and/or applying changes only if they have not
been already applied is too complex and hurts readability far to much to be
attempted in a simple shell script.
Many applications have their own command line driven configuration utilities.
However each has their own oddities and complexities (authtool, gconftool-2,
postconf etc...) Oddly enough out of all of the command line configuration
tools I have used, I find gconftool-2 to be closest to The Right Way (TM),
which is odd as it is by far one of the most complex syntax's to use (God
help anyone who tries to make major edits to gnome xml files using sed)
example:
"gconftool-2 --direct --config-source
xml:readwrite:/etc/gconf/gconf.xml.mandator
y --type float --set /desktop/gnome/peripherals/mouse/motion_acceleration 1"
Even a complex (yet powerful) tool can meet the golden rule of "Make it as
simple as possible but no simpler" when compared against a bunch of tools
that are less powerful (and perhaps less complex when viewed in isolation).
It is my opinion that we as a community need to find a Better Way (tm) to
manage configuration changes for Linux subsystems and applications.
Everything should be a file, but that does not mean every configuration file
needs to be formatted and managed differently.
In closing, a change this fundamental must be designed by the best minds and
must have a strong champion for it to have a chance to succeed. The Fedora
community is likely the only Linux entity with the brain power and influence
to address this issue.
Cheers,
Shane
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
