5:37 p.m.
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