The Strengths and Weakness of Fedora/RHEL OS management

[Shane Stixrud]

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