The Strengths and Weakness of Fedora/RHEL OS management

Shane Stixrud shane at geeklords.org
Mon Mar 27 20:33:50 UTC 2006


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
>
>




More information about the fedora-devel-list mailing list