Motivations for writing Linuxconf

Linuxconf is not the first project targeting linux administration. Probably not the last. The principle behind it is the key to its difference.

The basic principle comes down to this: The quick and easy way won't do it, be prepared for a major undertaking.

What is wrong with current admin tools

Availability of good admin tools for Unix/Linux has always been a problem and has always been a show stopper for most Unix new user/admin/whatever.

Here is a talk about this. This is fairly generalized and we put everything in the same bag. There are exceptions to all this, but we pretty feel this describes the general state of affair. Comments are welcome.

This talk is merely an enumeration of bad things and later we present how Linuxconf tackles the task of fixing this.

A long story

Administration tools so far available are user interfaces to manage configuration files. This is true for all OSs. This is true for Unixes and this is true for Windows and friends. While some administration package are nicer (good looking) than others and some manage more things than others, all these tools are this: User interfaces.

In the Unix world, it looks like this task was never too much took too seriously. We put this on the fact that the market was not much mass market oriented. This is the polite statement. The truth is "Poor marketing". See the "When too much is not enough" section below for a smaller scale example of the concept.

So in Unix, the promises for better administration tools were generally not kept. Even if the market was crying for this for several years, even if everybody was claiming that Unix was difficult to administer and this was giving a hard time to marketing people, not much was done. After providing a tool to create user accounts and potentially configuring the printer, it seems that the efforts were stopped.

Sure enough this is over-simplification. Some admin tools found on some Unixes are not so limited: HPUX can do many things, even configure UUCP, but forget about sendmail, DNS, filesystems, ...

The easy win

Most admin project on linux (at least) have started around this concept. Just pick a cute user interface tool kit, tcl/tk for example, and do some screens, some validation and this is it.

Unfortunately, providing quality, robustness and many other features required by an administration system is not simple. This is a large software project. Which programming tool you pick is debatable but not the issue: Be prepared for a large project. Linuxconf scores now at 40,000 lines of C++ code. Again, most admin project were started with a limited target (configuring one thing and see if something else may fit there).

When too much is not enough

Many software packages available for Linux are so flexible, so powerful, have so many options, have so much documentation available that in the end, they are almost worthless to many users. This is true especially if the default configuration delivered with the installation is not meant to be used directly.

The best example we have is Sendmail. While Sendmail is the undisputed standard for sending mail over the internet, you will find many people so much frustrated by Sendmail that they claim loud and clear that one is lucky if he manages to send email with it !!!!

This is a state of affair for a proven standard which has been around for many years. Just imagine how fast an unknown package with many many features and a sophisticated configuration file will be thrown away by new administrators.

What is wrong with Sendmail

Technically, Sendmail is like Unix: A sophisticated, well documented, highly configurable thing, but without a marketing department. It has so many features, so many specialized features and no user interface to present it. Ultimately, Sendmail has no features: You just start it at boot time and hope something happen.

On most Unix system, the sendmail.cf comes from god. Some unixes deliver two preset sendmail.cf depending of the type of workstation you have (Satellite or mail server) and that's it. We all know how those sendmail.cf were done: Either by playing by hand, or by using the generation utility available in the latest Sendmail sources.

Those Sendmail.cf are generally highly documented (full of comments). They generally have so much comments, that the user has to skip several pages of text just to find the options he wants.

Without a user interface to guide people around those features, they just won't look and jump on anything (potentially no that good) which provide some dialogs. Bye bye Sendmail.

Configure the general case only

(And let the user read the man page if he needs more)

To activate the IPX network(configure the interface only) on linux, on most systems (Client systems), just execute the following command

/sbin/ipx_configure --auto_interface=on --auto_primary=on

This is really enough for most linux workstation. So a user interface to control this could be done this way.

Do it all the time. Just write this command line in one rc script and let it go. If there is a Novell network around, this will be fine. If there is none, then no problem also.
Put a check box letting the user selects if he wants the command to be executed at boot time or not.

It seems that the second one is over design as the first will work most of the time.

The Linuxconf way for IPX configuration

The IPX configuration module in Linuxconf has 354 lines of code and the dialog generated has 51 fields allowing different configuration of the four Ethernet adaptors for the four frame types available. The first three fields control the simple case.

	Enable         [ ] IPX networking
	Autoconfigure  ( ) primary
	Autoconfigure  ( ) interfaces frame types

The idea is simple: If you have features, why not show them and provide simple defaults at the user interface level. This is a marketing operation: Show what you can do. People are always happy or impressed when they owned a car doing 200 MPH (320 km/h) even if law prohibits speeds above 55 MPH in some places. Sure enough this is not quick and easy and be prepared for major undertaking.

Linuxconf, a different view of things

The first thing a new user see about a system is the administration and configuration systems (Well he has to install it also, but this is another story).

If the system ask little question and work, this is fine, but not so impressive.
If the system has little configurability and do not work immediately then your image is in trouble.

You are better to show features with well organized dialogs and be prepared to validate at a very high level the input from the users.

How many millions of Linux users are there

The linux community is growing. The simple scripts (even good looking tcl/tk stuff) won't cut it. The default configuration hidden in rc scripts won't do it. Telling the user he has to edit this or this in a HOWTO is not really good, as a marketing operation. It is not impressive.

You need to show the features. The sad things about linux is that is has so many. Don't be shy. Show the new user that his system can do many many things if needed.

It won't be easy

Linuxconf is a major project. It involves a lot of code, but more important, it has required of lot of prototyping and rework to get to this point. One funny story about Linuxconf is that it started as a Xfree configurator. Then the idea that some probing had to be done to insure proper operation (checking if the network was correctly installed and so on) introduces us to the larger task of Linuxconf itself. The X configurator has been put on the back burner and forgotten since.

Forget about shell scripts

Creating a shell script with many comments is better than nothing. It is good for an in house product. Not for a product with the wide distribution like linux. Remember that your product is just one of the many sophisticated/configurable/extensible product available for linux. Unless you make your features available, new users won't even notice.

We bet that most linux user do not know that they have a working POP server and ftp server on their workstation. Most simply don't know that ftpd do have many features: It just work and this is it. (On a sad note, Linuxconf is still not touching this ... yet).

It requires several user interfaces

One problem of Linux and Unix in general is its flexibility. It can be operate with several user interfaces, be it using a simple text terminal, or a sophisticated X graphical desktop. Further, at boot time very little facilities are available.

Microsoft product are not as flexible and the only user interface is the graphical one. This is a problem in Unix because doing just the graphical one pretty limit the usefulness of the administration tool. We have chosen to provide different user interface for Linuxconf in that order:

Text base (ncurses)
This is the universal one. It is available from a telnet or on the console or whatever. Further, this is the only one available at boot time and Linuxconf is fully operational to configure the system. This interface was needed first.
HTML
The general state of affair about system administration is that most user don't manage their workstation (or barely). An administrator or technical guy generally do the low level tasks such as installing and configuring new software, setting up the network and so on. This is true for all OSs. Remote management has always be a strong point of Unix (everything can be done using a telnet): The HTML interface make this much more appealing.
Full blown graphical user interface
This is not done at this point (Although many prototypes have been done). It will probably work with tcl/tk.
Linuxconf is expected to enter new fields of administration. We call it "personal administration". A GUI is really needed to better fit the desktop. While the HTML interface is nice, the HTTP protocol is not carrying user id so it is difficult to use proper default based on the user id. A GUI version of Linuxconf would be much nicer to use.
It is also expected that some functionality of Linuxconf will only be available with this interface.

People don't use admin tools often

While an admin tool must be good looking, it is not a word processor. People are generally seldom using it. Few options should be available at one point. This is why we have chosen the "one large menu" concept against stuff like pull down and so on. This kind of user interface (pull-down + task bar) is very appropriate for tool you use everyday. They can lead to some frustration for an admin tool. Much too often we have seen people trying to remember under which menu they have saw once an option to do something and could not remember where, or worst, the option is there but not available and clicking on it does not tell you why it is not available, but only a neat "beep".

An admin tool must use the same kind of concept/interface across the board. It must potentially be boring.

Not just a user interface

Just providing more complete dialogs (and much more dialogs indeed) does not cut it. Linux has a huge amount of sophisticated services. Just plugging values in those dialogs and hoping for something to happen at next reboot (The Microsoft NT way) is not enough. Too much time is lost looking around and rebooting and rebooting and hoping :-)

Linuxconf is an activator and in some way a validator.

DNS connectivity check

One neat feature of Linuxconf is the DNS check it does when configuring the network. Again, Linuxconf is not doing this only at boot time, it is doing this anything you ask (using the control panel, or when you quit Linuxconf) it to check is everything is current.

Linuxconf locate (/etc/resolv.conf) the DNS and send a request to it. It waits 4 seconds to get a reply (The answer is known locally by any DNS so the reply should be fast). If the reply is not coming then Linuxconf offers you to abort the network activation/probing since good DNS connectivity is key to proper networking activation (Server activation generally).

This is the kind of test and inspection that Linuxconf is already doing. We believe that the amount of tests will grow in the future.

A marketing operation

After many months of work on the Linuxconf project, one thing comes to our mind. We were looking at different way to support Sendmail configuration and also we were questioning ourselves about what features of Sendmail would be useful or potentially worth showing.

At this point, we would say that doing this project was more like

Somebody has to do it, this is a pain to do, this is needed, somebody has to do it ... and it sounds like we will do it :-(

Then we saw the lights. We saw that many features of Sendmail were really not known very well. All of a sudden we were working for the marketing section of Linux (Virtual section) and not the system section anymore. Changing hats, we realized that Sendmail was not a pain anymore but indeed Sendmail was a salesman dream.

????

Most marketing people and salesman are always asking for features. Features, we need more features, to differentiate ourselves from the competition. More features, more ...

Sendmail is so configurable that you can invent features. The Complex user routing of Linuxconf (see the menu networking/Mail delivery system of Linuxconf) is one key feature which come very handy to handle the new requirements of the virtual web hosting business. This is the 200mph argument. When building a mail server, this is good to know that under the hood, there is something to achieve a lot of tricks if needed, things like

User aliases
Small mailing list
Install filter program
Special domain routing
Complex user routing

Seen this way, Linuxconf is now a very exciting project.

Conclusion

Linuxconf is a large project. A lot has to be done to make it cover all the features of linux. This is our goal. Another goal is to make "package producer" aware that without "marketing" (read a good administration tool), their wonderful feature won't be that much used.

Linuxconf is now a powerful framework to integrate new systems. With so many systems already managed by Linuxconf, plenty of examples are there to teach how new systems should be integrated.

If you are looking to do a configuration utility for your package you may want to talk to me (jacques@solucorp.qc.ca) about it. We have always said that it won't be easy. Doing it in Linuxconf is easier though :-)