“What is configuration in Linux? What do experienced system administrators do when they need to, for example, modify the access rights to a Web site or change the network settings for their server? Invariably, they’re going to login into the machine and edit a text file using a Unix editor such as vi or Emacs. That by itself isn’t that bad, but depending on which application you want to configure and which Linux distribution you happen to be using, the location of the file you need to edit (and maybe even the format of the file) could be completely unknown.” Read the article at FreshMeat.
A Solution to the Problem of Configuration in Linux
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
They refer to linuxconf, webmin and other tools, but they don’t talk about Mandrake’s Control Center. Especially the latest one – 9.0. It is great and lets you configure anything from a single screen:
1. boot management
2. system management
3. user management
4. security settings
5. hardware settings
6. software management
7. network management
Check it out at mandrake’s site: http://www.linux-mandrake.com.
If needed something like this can be implemented on the command-line and there we go: Linux servers have an organized, easy to use, configuration tool that (given the current great GUI) won’t scare off new Linux users either.
Personally, I love Gnome2’s Gconf. It just works and it is pretty “clean”. No matter if it looks similar to the registry or not. It is not cluttered or slow.
I think KControl is a good solution. As of now, you can configure lilo, and even kernel options. To see more fine-grained network configuration modules and cron modules, and that sort of thing would be nice too. It’s very possible. The only drawback is that a whole lot of people don’t use KDE. Still, though, kcontrol is a good framework to start with.
Erm… the author does not nesserarily talks about the front end, but for the way the data is organized and then presented behind the scenes. The KControl is nothing but a front end to various text file configurations that exist today. The author is speaking of a bit more behind the scenes configuration schemes. KControl is a high level solution.
I agree agree with Eugenia, the registry aproach of GConf is much better, if newer apps, daemons, whatever, where “forced” to start using this, we could start getting rid of all those stupid config files. Having some windows-like wizards would also be cool (setting up a small network with xp requires only a few mouse clicks, i wish it could be the same for linux).
> newer apps, daemons, whatever,
> where “forced” to start using thi
we could start getting rid of
> all those stupid config files.
The config files are pretty important and extremely convinient. Very many people are already used to them. They make scripting easy and trivial. And many production systems are not going to have an X Server installation for obvious reasons. Any such tool must retain config files if it hopes to be adopted.
IMO it is very important to keep the actual config files in a format
that is readable in a simple text editor. That gives you a safe
fallback when (for example) the GUI config editor has a bug.
Should the format be XML or just the present typical collection of
one-line statements?
Each program must retain a separate file or files. Any attempt to
merge lots of config files into a unified structure would invite
disaster a la Registry. But a uniform style of GUI editor for the
files would be liked by many.
Personally I am happy with a text file edited by a text editor so long
as it is well commented. But a program which has a choice of fonts or
colors must have a GUI to set them.
The cool thing about GConf is, that you can choose the backend. By default this is a bunch of xml files in ~/.gconf, but if you want you can put the config files in a mysql database or ldap or whatever. The application that uses gconf doesn’t need to know about any of this, so it would be nice if stuff would work with this..
In the article: the location of the file you need to edit could be completely unknown
On non-LSB compliant distributions, that is. Oh, the joys of LSB…
Eugenia on Gconf2: No matter if it looks similar to the registry or not.
The problem with Gconf2 is that reminds me of one of the worst things about Windows Registry: the “affinity to crash”.
Every time somebody makes something bad on Debian unstable (Debian is the distro that better suited my pre-G3PowerMac and unstable is the only way to use Debian AND be up-to-date) GNOME 2, the Gconf files go crazy and I lose all my configurations.
Definitely needing more work. (Yes, I’m a GNOME fan so I’m worried about this)
Erm… the author does not nesserarily talks about the front end, but for the way the data is organized and then presented behind the scenes. The KControl is nothing but a front end to various text file configurations that exist today.
from the article:
“Configuration data should be stored in the native configuration files for the applications they configure. This will allow the system to work with existing configuration applications, as well as allowing the users to hand-edit the files if necessary.”
But I do see that the solution the article proposes, because of its “middle layer”, is much more comprehensive and extensible.
The problem with Gconf2 is that reminds me of one of the worst things about Windows Registry: the “affinity to crash”.
The same thing happens when you mess with the XF86Config-4 file for example.
you have to admit, this is one thing that Microsoft does right. And honestly, I use to be one of the biggest haters and grippers of Microsoft but now with XP – I have nothing to complain about.
It’s:
stable,
fast,
efficient,
boot’s faster than anything I have ever seen,
and Configuration is made EXTREMELY easy
> you have to admit, this is one thing that Microsoft does > right. And honestly, I use to be one of the biggest
> haters and grippers of Microsoft but now with XP – I have
> nothing to complain about.
>
> It’s:
> stable,
> fast,
> efficient,
> boot’s faster than anything I have ever seen,
Mandatory BeOS comment…BeOS boots faster.
> and Configuration is made EXTREMELY easy
I disagree, I have watched several of my friends using XP. Poking around the various config screens/wizards whatever trying to find some config setting they KNEW was there before. Windows XP hides too much. Windows 2000 was better in this regard, it doesn’t treat the user as too dumb to learn.
Cheers
David
The problem with Gconf2 is that reminds me of one of the worst things about Windows Registry: the “affinity to crash”.
Every time somebody makes something bad on Debian unstable (Debian is the distro that better suited my pre-G3PowerMac and unstable is the only way to use Debian AND be up-to-date) GNOME 2, the Gconf files go crazy and I lose all my configurations.
I guess that’s why it’s called “unstable”
Anyway, note that you should only lose the gconf file of the app you were using/tweaking, as there are different files divided on directories to control most apps. That means that, unlike windows registry, deleting a file won’t affect the whole system, just an app.
One of the Great things about IBM’s iSeries is the consistancy of their config files. They have a similar layout for all the editors and a standard of sorts for the different commonly used variables. Even if you are new to a screen or program the interface is still more or less the same, the settings do what you would come to expect from using all the other ones.
I would like to see this in a Linux distro. One could make an ugly but consistant Admin mode similar to a terminal green screen. This would allow for more consistant documentation (I can pull up 5 yr old AS400 config docs that still work!) Also it would allow user related distros like Lindows to protect their root user buy forcing an ugly, but funtional and more userfriendly interface.
All this talk about nice GUI interfaces is fine, if your box is running X, that is. There are many cases where there is no need for a linux box to run X so we need to take this into account when deciding the best way forward.
I think we should keep the text file based configuration, this allows for the maintenance of systems which admins access through text consoles where a GUI isn’t available or X has stopped working for some reason. The text file based configuration needs to be standardised across distros, this means that the file which needs to be edited on one system to enable say, DHCP, is the same file across all distros. The structure of these files needs to be standardised. Once something like this is in place, it is then easy to write nice GUI frontends to configure the system without taking anything away from the power or flexibility.