Comments on YaST and admin tools

[Dax Kelson]

On Thu, 2006-08-31 at 17:12 -0400, Steve Barnhart wrote: 
> Well Ok I'd like to some people for their actual dissection of what
> the problems were. I guess I don't work in production environments
> (not that Fedora is even for that??) and didn't realize so many users
> hatrid of YaST. I've always found it pretty simple to use but maybe
> that's just me. At least reasoning was given..hopefully the team can
> atleast add some more system-config-* programs or something.

For a living I teach Linux classes and write courseware, my customers
ask that I know and cover both RHEL/FC and SLES/SL. Because of this I've
gotten very familiar SUSE and YaST over the last few years. I run
production servers on RHEL, SLES, Debian, and Solaris for the
experience.

General problems with GUI admin tools like YaST, system-config-*, and
others

* Only has the ability to configure a subset of the total functionality
** Advanced config using the tool is often to manual edits
in /etc/sysconfig/ files which then get parsed and generate the real
config. If I have to do manual edits to get the config I want, why not
edit the real config file?

* Increased complexity

* Doesn't play nicely with, or overwrites, manual edits (usually the
case).
** Wants to "take over"

* Usually doesn't read the real config for authoritative configuration,
but instead has a separate location (xml files, or /etc/syconfig/, or
other).

Good things about those tools:

* Can automate in syntax typo free fashion large configuration changes,
or changes that touch many files. For example. Setting up PPP, switching
NSS and PAM backends and configuring them, X configuration.

Specific problems with YaST (and SUSE configuration in general):

* Is heavily plagued with the "config file used to generate another
config" file disease. For example, on SUSE 9.3 and higher don't make any
edits to /etc/sysctl.conf as they will be overridden
by /etc/sysconfig/sysctl which is a YaST style sysconfig file that, of
course, doesn't even allow to you specify all possible sysctl keys.

* In order to YaSTify certain services you end up with major departures
from upstream config style.  For example, on my SLES10 box
under /etc/apache2 there are 35 .conf files (I only have two in the
conf.d directory) as well as /etc/sysconfig/apache2.

* Very limited scriptability. Pretty much all of YaST is only
interactive. On RHEL/FC boxes a many/most of the system-config tools can
be executed non-interactively with switches, for example.

system-config-keyboard --noui us

* Doesn't encourage the K.I.S.S. principle when adding new features,
software to SUSE as it is easy to "just write a yast module" to manage
it.

* Over engineering. For example, by reading the SUSE bash bootup scripts
I've learned amazing scripting techniques that I would have not thought
possible with bash and friends. It is obvious the SUSE developer(s) is
brilliant, too bad that knowledge is used to introduce complexity
instead of remove it. Of course this is my personal opinion and I'm a
fan of the simplest solutions for a given problem.

* When exiting YaST it re-generates all config files under it's control
versus just the one you were working on.

* Mixed case commands and odd directories like /sbin/conf.d/.

Specific problems with the RHEL/FC system-config tools:

* Lack of consistency. Is it --noui, --text, --nox, or
system-config-command-tui? 

* Not a integrated modular system (which would solve the consistency
problem).

* Limited coverage of system configuration compared to competitors

Good things specifically about YaST / SUSE:

* Fairly broad coverage of system configuration.

* Some cool modules. I like the full featured "Certificate Authority
Management" module. Another interesting feature is the /etc/permissions*
files, although it can cause false hits with rpm verify.

* Automatic curses and GUI/QT interfaces available "for free" to module
developers.

* Ability to tell it "hands off" certain parts of the system, for
example: echo "MAIL_CREATE_CONFIG=no" > /etc/sysconfig/mail.

The above list is not complete. Just some things that came to mind. 

In my opinion porting YaST would be a lot of effort and for what?
Naturally the whole YaST system has lots of SUSE specifics
(see /sbin/conf.d) and by the time you pull those out what is left? A
skeleton of a management framework that supports curses and QT. Would
that effort be better spent on an integrated modular multi-interface
system that followed the Fedora development philosophies from the get
go?

Dax Kelson
Guru Labs