Articles / How to Fix the Unix Configu...

How to Fix the Unix Configuration Nightmare

Unix is steadily evolving into something much easier to use. The trick is to find tools that make things friendlier, but which fit in well with existing tools and are easier for people to take and use for new projects.

The Linux distributions and the BSD ports system are like this, taking an existing wealth of software and working with its quirks to streamline the installation and upgrading of applications and system software.

The GNU project has done a lot of good work in standardizing the compilation of software on different operating systems (automake and configure), parsing commandline options (getopts), and working with internationalization (gettext).

One thing that's still a mess, however, is application configuration.

There are useful general trends, like putting system-wide configurations in /etc and personal preferences in files beginning with . in your home directory. However, there is a complete zoo of configuration file formats. Some use the Windows .INI format. Others use simple variable assignments. Some use a natural language syntax. A certain amount of diversity is healthy, but in this case, it makes it a bit of a black art to build user-friendly and powerful configuration tools for all the software on a machine.

There have been various noble attempts to fix this.

Some popular packages, like Apache and Samba, have had point-and-click frontends built for them, but each frontend works differently. Other packages (notably the Linux kernel and Debian's debconf) have a range of interfaces that can be used, depending on the user's taste, from a raw text file and vi, to a text-based menu system, to graphical point-and-click. Another approach is to custom build a consistent set of frontends for a lot of different software configurations, as is done with the GNOME and KDE control panels, the Linuxconf project, and The Dotfile Generator.

I don't think I need to go into much detail as to what a mess the Windows registry is. It does provide a certain amount of power for graphical applications, but the text-level access is shoddy and cryptic, and a binary database seems to be an inherently unstable and inflexible way of storing data.

A new approach

All of the above efforts have made things better, but none have quite pulled off the kind of user interface consistency that Windows and MacOS have. However, despite an apparently messy situation, I think that Unix may not be very far from a workable solution.

Obviously, it's possible; MacOS X has pulled off a very nice graphical frontend to Unix. However, that frontend is the bit they're keeping closed, so the other Unix systems are going to need to build something Free.

The solution, I think, lies in combining the best of the approaches I listed above. It's vital that it be something that can work with existing programs, but which is attractive to developers to incorporate into new versions and new projects. Without integration into applications, it's always going to be a bit of a dodgy hack (see Linuxconf) that makes it difficult to change the configuration file in a variety of ways. Getting the developer involved is crucial for making sure the configuration manager keeps up-to-date with changes in the application, which I believe is a big part of the success of standards like gettext and configure.

It needs to accommodate diversity (the opposite of the One Registry approach, which I think will never fly on Unix), and it needs to be tenacious; it should be useful even with minimal information, but take good advantage of as much information as is given. It needs to help both the user and the developer. It helps the developer by automating and cleaning up configuration handling and documentation. It helps the user by providing flexibility and consistency.

Here's an outline of how it might work:

  • A core system would handle parsing, verification, and storage of text-based configuration files in one or two basic formats.
  • The master copy of the configuration is always left in the native text files (in /etc and ~/.*). This is where Linuxconf fell down; it started keeping its own copy of the configuration, which meant that if Linuxconf took over your system and then something stuffed up, it was difficult to edit a text file without losing Linuxconf completely.
  • In order for some features to work, it might be necessary for application developers to switch to the use of the configuration manager for their internal routines. However, this should be possible without breaking backward compatibility with the original configuration file format for most features.
  • A key element would be the configuration format description file. This would list the configuration options for a given piece of software, giving for each one the name, type (boolean, list, string, etc.), options, category (for subsections within the config), and help text (short and long).

    It would be good to be able to write descriptions of how options relate to each other. For example, one option might disable a bunch of other options.

    Ideally, you would be able to add optional hints to help with the layout of the options on the screen under various configuration editor systems.

    Done well, this could be a big attraction for developers, because it could automate a lot of the work involved in managing configuration systems. By creating a single place for storing such info, it could be used to automatically generate and update all documentation: user guides, man pages, Web page help, commented template systems and user config files, and programmatic help output.

  • Because so much language is involved in configuration options, it needs to be internationalized from the ground up.
  • This core system would be kept small and efficient, so that it is easy to add it to all sorts of projects without weighing them down. It would have interfaces in all of the common Unix languages: C, C++, Perl, PHP, shell, Python, etc.
  • Plugins would allow the addition of a lot of diversity, and would be of at least two types:
    • File format plugins would allow the programming of new configuration file formats. This includes parsing, verification, editing, and writing. You could expect heaps of such plugins, preferably provided with an application or by a third party.
    • Editor plugins would give various methods for changing configuration files. These could range from a wrapper on your favorite text editor, to text-based menus (curses), to graphical menus (GNOME, KDE, etc.), to distribution-specific methods (e.g., Debian's debconf), to Web forms (useful for Web applications that have a lot of configuration options). It should be possible to invoke an editor from within an application (using the application's File -> Preferences... menu, or a commandline option) or directly from the commandline (or a GUI equivalent that lists installed apps, like a control panel). It should also be possible to programmatically edit configurations, either through a standard commandline or through the various language bindings listed above. Network administrators would love such tools.
  • It all needs to be language, distribution, and operating system neutral, so as to avoid turning off any potential software developers who might find it useful.

With such a system, Unix could go even further than Windows and MacOS, providing the ease-of-use of graphical configuration with the flexibility and security of remote text-based configuration and the power of programmatic access to read and change configurations throughout the system.

If this seems like a good idea, all we need is a team of programmers and documenters to write it. It seems like a lot of work, but with the right touch, and strategic initial energy, it would be something that would attract contributions from a lot of different angles.

RSS Recent comments

16 Feb 2002 00:46 maffew

revised version
I know the story is only 50 minutes old, but I've made some revisions (www.cat.org.au/maffew/...) already, which I think make it a little clearer what I'm getting at.

16 Feb 2002 01:00 openface

Configuration made simple...
/etc/conf/*.xml

Perhaps one day, in a Linux distribution near you. =]

16 Feb 2002 01:21 mystran

One thing about Mac OSX and Aqua
There is one big difference between Aqua and X11/Unix.

Aqua is like Windows in the sence that there is the one true way for things like configuration, drawing a button, moving windows, etc..

With X11 we have a lot of different libraries/thing like GTK, KDE, Motif, QT, GNOME. They are all designed to work and be used differently. This same goes for programs. The configuration format of sendmail is designed to (best) reflect the inner workings of sendmail where as for exim the same format really would be just about making things hard.

To unite the configuration aspect of this great variety of different designs would either limit the creativity of programmers so as to make truly original programs less likely, or to make supporting the configuration scheme so hard that many programmers would simply ignore it.

If we were to make a single configuration system that is really good for everything, we would probably have to make it so complicated that only a few people on the globe would actually be able to understand it and develop software to support it.

Most likely we would end up with something like the web that everybody can make content with but to browse the whole thing you have only a few choices, because the whole thing is so hard to parse and there are so many different extensions.

And while it's easy enough to make a simple boolean variable into [y/n] question or a check box, it's pretty hard to make a graphical presentation of something as complicated as a simple regular expression, not to even think about the more complicated things.

For example to specify which hosts can use a server it's pretty nice to say something like "d.*\.[~n]\.company.com"

Another example would be key binding that may in simple applications have simple meanings like "quit" or "open" but
what if you wanted to do this in mail client: "reply to item if the address has a @ sign and reply to <address>@pp.company.com if it doesn't. Anybody ever tried to make a filter with outlook btw ?

16 Feb 2002 01:42 mystran

Re: One thing about Mac OSX and Aqua
I'd like to add one more thing.
More important than changing the way we configure our software, is to limit the number of useless configuration options.

It's too great you can select if a button gets clicked just by pressing the mouse button down or only when you release the button and whether the mouse still has to be on the button when releasing, or that you can choose whether an open file dialog defaults to last directory or home directory or some other directory.. but..

after all you can eliminate the whole need by opening the dialog in last known place (if it still is there) and add a button with which to access the home (or whatever).

The same is true for ALL too many configuration options.
How many people actually detach menubars ?

All unimportant stuff should be cut to minimum.
They all contribute to the adminstration overhead whether they are used with the same tool or different. Just finding out what they all mean is often the most time-consuming part.

The sawfish style "beginner/medium/expert" style is quite nice, only that all the REALLY useful options tend to be in the expert menus..

16 Feb 2002 04:04 olivierkaloudoff

cgenfine meet some of this requirements
Hi,

cfengine is meant as a multi platform
configuration engine, so maybe some of the concepts and/or code of this tool might be used
as a start ...

my 2 cents.

Kalou

16 Feb 2002 04:16 buchanmilne

This mirrors some of my thoughts on the issue ....
I have been looking for a way to easily do configuration of server software on the command line, something like:

# conf samba add_share myshare /home/me/myshare

# conf samba _add share
would give the help text described.

But here are some of the ideas I think are important:

There should be a standard directory containing the meta-configuration data (which contains the possible configuration options, help text, syntax definition etc), which each server project would be responsible for. Thus in my example, the samba team would need to keep /etc/config.d/samba up-to-date. In this way, configuration can never be out of sync with the software

It would be a good idea to have meta-configurations possible, so that a configuration tool could have a "setup wins" button, which would set samba to wins, and provide the wins addresses by dhcp (simple example, but I am sure there are others).

There would probably have to be syntax files (otherwise a section of the software's config.d file would have to include this) which would define what a comment is, what sections there are and how they are delimited. However, since there might be a number of projects using the same syntax (wine and samba both using ini-style and cups using Apache-style), it might be important that the configuration tool comes with some of these predefined.

One of the advantages of unix text configuration files is the ability to have text comments in the file (try this in the windows registry!). Any front-end to the configuration backend needs to be able to display comments. It would be nice if the parser would pick up where the comments are applicable.

Another advantage of text configuration files is the ability to comment out (disable) configurations. For example, it may be useful to keep a specific configuration entry which is used from time-to-time. Note that this is different from a text comment, and should be displayed differently. In many configuration file types, there are at least two types of comment delimiters, in which case one (for example, # in smb.conf) could be used for text comment, and the other (; in smb.conf) could be used for disabled configuration. Mandrake ships samba with examples of most configuration commented with ; in smb.conf, and the biggest frustration is that no configuration tools currently display this, and at least one removes all the comments - including sample configuration.

16 Feb 2002 04:46 illumino

Formats
I think one of the those formats must be a XML Application. I feel that I standard configuration based schema/schema types should be developed which have at least the following properties:
- Ability to document each option in a way that can be both useful to a GUI and to documentation generation.
- Ability to define useful generic tags with well understood semantics and can be validated (easily) - example: file, directory, device, protocol, service (validated against /etc/services for example), hosts, ip (both 4 and 6)
- Flexibility to be customised to most/all applications
- A standard base format (XML) and standard configuration layer will encourage the development of std tools etc

Just my 2c worth

Peter

16 Feb 2002 04:54 jensus

GConf
It sounds like you're talking about GConf (freshmeat.net/projects...).

GConf stores configuration using a backend of choice (currently implemented backends are xml and db). You access all values
using paths like "/apps/galeon/UI/Tabs/tabbed_loading_color". Aplications are informed when a value changes.

I don't know if it is secure enogh to be used for serverprogramming.

16 Feb 2002 05:00 Jyrinx

Re: One thing about Mac OSX and Aqua
Well, *I*, for one, detach menus sometimes; in the GNOME menu, it solves the problem of having to root through several submenus whenever I run another program in the same folder. Windows might allow this a little more nicely (double-clicking on a submenu in the Start Menu opens it as a bona-fide folder), but I bet the GNOME coders didn't have to write a single line to let me do this with the GNOME menu. Since the detachable stuff is all dealt with in the toolkit, app developers don't have to worry about it.

(Similarly, there must be people that are driven nuts by the default behavior of button clicks. I can't imagine it's much of a task for a toolkit to allow this to be customized, so why drive those people nuts? If another GUI lets them customize it, they'll be driven straight toward a competitor ...)

In any case, I don't believe that the rarity of people using a feature like this is grounds on its own for removal. The one-interface-fits-all attitude is one that bugged me for years with the Mac, such as when I couldn't get full menu access with the keyboard (Alt-F for file menu, etc.). The Mac guys I talked to always said "But the mouse is easier!" Of course, but *I* like using the keyboard at times, and my being able to use it doesn't get in the way of anybody else (how many people find the little underlines intrusive in Windows menus?). I'd be willing to bet that there are few people who are *really* comfortable with their setups in any GUI who haven't tweaked something most people don't use. In other words, depriving everyone of the weirder options eventually alienates everyone. The user is the master, not the computer or the programmers; what *I* want, *I* should get, whenever reasonable.

If people find tear-off menus obtrusive, then having them off by default is quite reasonable, so long as I can turn them on easily (the subject of the article, of course). But this *is* Unix here; if nothing else, Unix OS's are distinguished by their infinite tweakability, and to take out settings just because a majority thinks they're dumb is to take a giant leap toward Windows-land.

(A good compromise, as mentioned, is Sawfish's three levels of options; maybe a universal config system could have a global variable for this, defaulting to "beginner" or "simple" or whatever, that would be every app's default setting; that way those who want to toy with the funkiest settings around can do so to their hearts' content, and those who mostly stick with the defaults won't be bothered with all the bells and whistles.)

An aside: Isn't all this what GConf is for? AFAIK, it uses a standardized XML format (as does MacOS X), and keeps everything in dotfile hierarchies under "/home", and such niceties. I'm not familiar with GConf's innards, but it seems to me that's much what this article is looking for.

> I'd like to add one more thing.
> More important than changing the way
> we configure our software, is to limit
> the number of useless configuration
> options.
>
> It's too great you can select if a
> button gets clicked just by pressing the
> mouse button down or only when you
> release the button and whether the mouse
> still has to be on the button when
> releasing, or that you can choose
> whether an open file dialog defaults to
> last directory or home directory or some
> other directory.. but..
>
> after all you can eliminate the whole
> need by opening the dialog in last known
> place (if it still is there) and add a
> button with which to access the home (or
> whatever).
>
> The same is true for ALL too many
> configuration options.
> How many people actually detach
> menubars ?
>
> All unimportant stuff should be cut to
> minimum.
> They all contribute to the
> adminstration overhead whether they are
> used with the same tool or different.
> Just finding out what they all mean is
> often the most time-consuming part.
>
> The sawfish style
> "beginner/medium/expert" style is quite
> nice, only that all the REALLY useful
> options tend to be in the expert
> menus..
>

16 Feb 2002 05:23 etrepum

Speaking of Mac OS X...
MacOS X's solution to this problem is a couple levels
deep. There are three (?!) systems for configuration:

(1) /etc (which is a symlink to /private/etc):
It's still there, used for a few things. But not much.
More or less just stuff that runs before everything else,
or stuff that apple doesn't have much control over, like
Apache.

(2) Netinfo database:
basically takes a lot of stuff out of /etc and puts it in a
"registry", this registry is accessible over a network
connection for remote administration and such. You
can also do some funky server/client stuff with this too.
There's a command line interface to it that lets you
read/change 'keys' and also dump out certain keys in
well known /etc style formats

(3) Property Lists (.plist):
This is the way that just about all configurable
information in MacOS X is stored. There are a couple
different kinds of plists that the Core Foundation
libraries understand, but the most prevalent of which is
the XMLified version, the others are either vestigal or
are used primarily for localization of strings. Every
application (well, bundled app) on the system has an
info.plist file that has application settings that the OS
reads from on app startup, but you can also put your
own tags in there. Applications also have the option of
putting their own tags in the Resources subdirectory in
their bundle, which is the preferred way. OS specific
preferences (requires admin privs) go in /System/
Library/Preferences, System-wide app preferences go
in /Library/Preferences, Network-wide app prefs (only
applicable if you have OS X Server on the network) are
in /Network/Library/Preferences, and User app prefs go
in ~/Library/Preferences.

The Core Foundation framework manages more or less
all of the work. They'll find the plist for you, let you
work with the data structures, and serialize/deserialize
it to plist format. It's really quite nice to use. Just
about all of the data structures in Core Foundation are
serializable, even the property list data structures, so
sometimes you'll see property lists with serialized
property lists inside them.

As far as unified configuration interfaces go, there
really isn't a need for any in Mac OS X.

You're on your own with /etc, as nothing there is meant
to be novice-tweaked anyways (In OS X).

There is a GUI NetInfo Manager and command line tools
to configure the stuff in that database (nothing a
novice needs to touch).

Configuring the plists is primarily done inside the
applications that you use (since it's so easy for the
developer to use Core Foundation to read/write
property lists), there are no separate configuration
programs, but there are command line tools for working
with plists. If you're using the developers kit, you get a
little (not very poweful and pretty inefficient) program
to edit plist files graphically, but otherwise you either
do it by hand with a text editor or the command line
tools and risk breaking things or let the apps take care
of it themself.

BTW, all of the Core Foundation stuff is available in two
flavors: C, and Objective C. The C libraries are pretty
straightforward and work in all situations, but if you're
writing an app using the Cocoa framework in Obj C, it's
way easier.. though there are a few little peculiarities
about the Obj C implementations. The bonus is that
you can use both at the same time, and Core
Foundation types / Cocoa instances are interchangable
by some voodoo that Apple did. If the Cocoa
implementation doesn't work right (As with serializing a
plist that has NSNumber Boolean types), you just use
the Core Foundation implementation and a typecast..
voila, one line of code changed and everything is
happy.

16 Feb 2002 06:22 un

A few basic but never-used point
( sorry I don't have enoutgh time to deeply explain my view)

1) NEVER EVER write or modify system directory, that mean for example, dont create directory in / ( which is obviolously a system directory) or don't install any application in /usr: /usr is no longer a user partition since at least 10 year. This is now part of system directory.
If you are not writing/installing a system things, go away from /, /usr, /var...

2) don't put every application in the same directory as this quickly become an unmagable mess ( even with package): hundred of unknow files in the samle place
. Everything in /usr/local is only marginaly better than all in /usr.
Use a separate directory for every application. Use symbolic link to share some file ( library) to other.
Separate data file from app. ( don't mix apache and html file) this will make your upgrade more confortable.
"/opt/yourapplication" tend to be something common, and, much inportant, findable and understable in only 1sec.

3) use generic library name ( libsomething.so, not libsomethings.so.4). so that your admin won't have to keep 3 version of the same tool in order to make slitly old application keep running. Let old app use your wonderful speedy new library version.

4) use obvious name. Long name are okay. I don't care about long name, I use completion. But I care of wondering me what is is this fucking "xy" command or file. "IDoThis" is a much better name because I know what is, what it does, and where it came from.

5) use good package system ( well I know this not admin fault, but this has to be told). I hardly understand rpm option and dependcy problem. FreeBSD ( which I am more familiar) package have also some huge weakness: overwriting existing file without warning or removing modified or some-package-else file without warning. ( When 2 different package use same file)

Well, I think I should write an issue/story/paper in some 'zine, in order to explain my view better.... when I got some more time :-)

A 7 year admin. Having admin 100 sun and 30 FreeBSD & linux.

16 Feb 2002 06:55 tarjeihu

This should be a GNU project!
I'm not a some kind of RMS fan or anything, but I think this should be part of GNU's standard tools that they give to developers. The idea is very good, and would probably be supported by all the big distros.

This is the most important next step to world domination. Why? Before a common config system is in place, linux will alway be for people who know their way around.

16 Feb 2002 08:01 pldaniels

Re: Configuration made simple...

> /etc/conf/*.xml
>
> Perhaps one day, in a Linux
> distribution near you. =]

I like it, I want it... I'll go for it. . . of course, in a way, it's a bit like saying "/etc/conf/*.txt", perhaps it was the simplicity of the post that attracted me like a moth to the flam*bbzzZZZTTT*

16 Feb 2002 11:15 mrsbrisby

real solutions
i personally like djb's approach; programs don't seem to rely much on environment variables, and everyone seems to like to write parsers.

Well, this isn't really a problem with configuration consistancy- because we actually need multiple interfaces for configuration (graphical, commandline, network, etc). Some interfaces are non-interactive, and these can survive with offline documentation and/or scriptability. Others rely on interactive, and require much online interaction with the user. More importantly, a bridge needs to be made that allows the configuration to "describe" the interface in this respect.

Obviously, XML is a grand choice for this- because it's designed (more or less) for exactly this purpose. Of course, we could roll-our-own (like the linux kernel people did) and we might be able to simplify parsing, but the truth is that the hardest part about building a unified configuration front is not in the design, but in the integration.

Whatever it is, it must stand alone, and be lightweight (at least on the client end) - otherwise it will never be used in embedded targets, or in secure applications (where complete control over all ends must be exercised).

This ficticious configuration engine must also be flexible -- some programmers write out a single binary, others write programs that work together to provide an application.

So let's divide it here: pass ALL CONFIGURATION over environment variables, plain text files (lists of strings, or single-line private stuff like passwords), and encourage this behavior by chrooting everything. This way, nobody needs to write a client at all!

But to solve the interface problems, simply front-end it so that we would have our "config loading program" run the actual application, and we can then switch out our configuration loading programs (and the suite it comes with) as we choose. I can put all my stuff in LDAP, or just some of it, and the rest in SQL.

Infact, I find it interesting that this article puts down this approach; saying that this is what makes "linuxconf" suck. No, linuxconf sucks because it tries to be something nobody wants: Service administration and System administration are TWO COMPLETELY DIFFERENT THINGS. I want to delegate System administration (setting up network interfaces, configuring printer drivers, formatting disks, etc) tasks, and keep my Service administration (configuration of the mail server) to my self. Or other other way around. You combine the two, and you get something everyone is skeptical of. I mean, nobody likes the MMC tool on windows systems because it clumps everything together and all the little applets don't behave like eachother.

Delegation is a word i used above. A big word for some, but it shouldn't reflect anything about the design decisions regarding our reinvented configuration system. Those could be handled by the same frontend (only grabbing data allowed, etc). And because the interface is simple enough, most people can put together the autonomous interfaces themselves, and others can still use the interactive ones.... if the configuration tool ever existed that is.

Of course, Linuxconf also sucked because it didn't give the admins the ability to poke inside, and automate anything. Maybe that's what the author meant.

In any event, and in short: I suppose the goal is to avoid using configuration files at all, but instead to rely on configuration being supplied at run-time. And there's a bonus: If more applications are built this way (and more every day are), then we'll see trends towards making applications smaller, and thereby more manageable (from the source level), and thereby making them potentially more secure.

It's a nice pipe dream, isn't it?

16 Feb 2002 11:27 javeed

What about Webmin?
It started out as a great effort by Caldera I believe. Now it's a very useful tool that maintains all file formats as they are and parses and modifies them as needed. That gives one the power of changing the configuration files by hand as well as the ease of changing them using a GUI.

16 Feb 2002 11:38 darrenp

Re: What about Webmin?
Webmin is bar far the best cross platform admin tool that I have seen. I started using it quite a while ago, and have never looked back.

Using webmin means that you can use the same method for creating accounts on mandrake, redhat, suse, or solaris (and many others) which means when you move from using linux servers to higher end mainframes, etc, you don't have to make any sort of skill jump.

Also it allows you to delegate responsibility of certain areas to other users. Give one user access to create accounts, another access to the DNS servers and a third one might have access to samba and apache.

Brilliant package! I am in no way associatied with the webmin development team, I'm just a happy user!

16 Feb 2002 12:53 r0b0

And what about using "Brain"
Yes, I mean the thing stuffed inside your head.

Why do you need single configuration interface to
all things that can be configured? Are you too lazy
to learn how to configure each single one by one?
Are you too lame?

For real, how many ways to configure things do you
know? How many formats there exist? How many do
*you* need to know? Let's count: you need to set up
mail server, http server, samba, mail client, database
server, window manager... How many have you
counted to?

Can't you just learn how to configure these? I,
personally, like learning stuff. Maybe you could give
learning a try. I promise you'll learn much more than
just configuration. You'll get somehow deeper look
inside the thing you are configuring, how does it
work. When you know what and why you are
configuring, you'll definitely configure it better and it
will work better for you.

The best example I gould give you are "commented
configuration files". Look at /etc/postfix/main.cf or
/usr/local/apache/conf/httpd.conf e.g. Have you
forgotten to read text? Have you forgotten how to
launch a text editor and change some values in a
file? What do you learn by clicking on checkboxes?

Ah, you were talking about "newbie users". I believe
that the best one can do to have his product easily
unterstandable and configurable for newbies is to set
up a fully functioning configuration 'out of the box'
and keep the configuration files commented and
simple to understand.

Robert

P.S. and sorry if this sounded like flame. It wasn't
meant so.

16 Feb 2002 13:50 elanthis

Re: And what about using "Brain"
Um, what about people that *don't* want to learn, or don't have the time? I know how to configure 90% of the average Linux server applications without using any documentation, but it certainly takes a long while. It's a hell of a lot faster to point and click a few times, and be done with it.

Not to mention that there *are* newbies to the system that don't want to learn at all. They just want to get the task done without spending a week learning how to setup a webserver.

I certainly would hope your only reason to not making configuration simpler is your ego and trying to feel l337't than everyone else.

> Yes, I mean the thing stuffed inside
> your head.
>
> Why do you need single configuration
> interface to
> all things that can be configured? Are
> you too lazy
> to learn how to configure each single
> one by one?
> Are you too lame?
>
> For real, how many ways to configure
> things do you
> know? How many formats there exist?
> How many do
> *you* need to know? Let's count: you
> need to set up
> mail server, http server, samba, mail
> client, database
> server, window manager... How many
> have you
> counted to?
>
> Can't you just learn how to configure
> these? I,
> personally, like learning stuff. Maybe
> you could give
> learning a try. I promise you'll learn
> much more than
> just configuration. You'll get somehow
> deeper look
> inside the thing you are configuring,
> how does it
> work. When you know what and why you
> are
> configuring, you'll definitely
> configure it better and it
> will work better for you.
>
> The best example I gould give you are
> "commented
> configuration files". Look at
> /etc/postfix/main.cf or
> /usr/local/apache/conf/httpd.conf e.g.
> Have you
> forgotten to read text? Have you
> forgotten how to
> launch a text editor and change some
> values in a
> file? What do you learn by clicking on
> checkboxes?
>
> Ah, you were talking about
> "newbie users". I believe
> that the best one can do to have his
> product easily
> unterstandable and configurable for
> newbies is to set
> up a fully functioning configuration
> 'out of the box'
> and keep the configuration files
> commented and
> simple to understand.
>
> Robert
>
> P.S. and sorry if this sounded like
> flame. It wasn't
> meant so.
>
>

16 Feb 2002 13:55 annoyed

Re: And what about using "Brain"

> Yes, I mean the thing stuffed inside
> your head.
>
> Why do you need single configuration
> interface to
> all things that can be configured? Are
> you too lazy
> to learn how to configure each single
> one by one?
> Are you too lame?

This is not intended as flame either, but you have got to be kidding. While I agree that you should learn how to configure commonly used programs, the problem is that it can be as hard as hell to figure out how to configure less common applications.

I mean, I often do support for third party systems. I waste a lot of time trying to figure out how they've configured their systems. For instance, some applications might put a configuration file in /etc, and others in /usr/local/etc, and others in /etc/appname, and still others in /usr/share/appname or /usr/local/share/appname or /usr/local/appname/conf. The configuration files may or may not have a logical relationship to the name of the application, so locate doesn't necessarily help.

[Don't get me started on documentation, either. Some programs use info, some man, some use html docs, and for some you have to read the startup script or the source to figure it out.]

While the author's proposal sounds a bit overengineered to me, I do think he's trying to address a real need. Personally, stricter adherence to existing standards (a la the LSB) would go a long ways towards helping.

16 Feb 2002 16:10 andylongton

Re: What about Webmin?
Yep. I'll be the third person to chime in on this one but hopefully not the last.

Webmin answers the core issues this editorial was about.

www.webmin.com/webmin

It is trivial to install, easy to use, and it's possible to add just about any admin task to it. For the most part, you won't have to since someone probably has already created a plugin for you.

If you use any Unix-style system, you really should get it and use it. It is valuable by itself, and allows you to easily get others who might be gun shy about Unix to start working with it.

Webmin simplifies managing different Unix-style systems -- even OSX and Windows (Cygwin) -- by using one set of tools per service. Use of Webmin can be a good step towards an all (or mostly all) Unix environment.

16 Feb 2002 16:39 Stonefly

vi rulzZz..
well, you really think it is possible to create a better configuration tool than vi??????

all-in-one configuration tools suck, because 2 seconds after publishing them, someone releases a new version of his/her program with millions of new features and your super trooper linuxconf/yast2/orhoweveruwannacallit is out of date.

one last question: how can i use a "graphical
point-and-click" configuration tool on my server without a mouse/X-server???

regards,

Stonefly

16 Feb 2002 16:42 buchanmilne

Webmin is part of the problem ...
While I agree that webmin is one of the best configuration tools available at the moment, it does not solve the fundamental problems with unix configuration:

Webmin does not show comments in text files. Adding good comments in config files is one of the best ways to document a system. We have a standard for modifying configuration files, so that is is easy to see what configuration has been changed, when, why, and by whom. Not being able to see or add comments in webmin is a problem.

If software is updated, webmin can no longer configure it (correctly).

Webmin can't be used in a one-liner command-line configuration tool (ie as a backend for some other configuration, for which it is not worthwhile writing a seperate webmin module).

A new webmin module needs to be written for each service/file that is to be configured.

By writing a decent parsing engine backend, and sticking to schema-type files to define the configuration files/syntax/options (and maybe even a graphical schema editor), it makes it possible for non-programming admins to be able to improve the tool, by writing schema files.

16 Feb 2002 16:55 cinnix

Re: And what about using "Brain"

> Not to mention that there *are*
> newbies to the system that don't want to
> learn at all. They just want to get the
> task done without spending a week
> learning how to setup a webserver.

Why are we worried about newbies who don't want to learn at all. Making things easier is one thing but totally revamping everything that people have worked on in order to support people who aren't willing to learn.

If you can't read the documentation and manage the softwares configuration files, then maybe you shouldn't be running the software.

I personally think that some packages such as apache, samba and many others have quite understandable config files. Although they are completely different, understanding the configuration is part of the learning process. I say tough shit, if you aren't willing to learn.

16 Feb 2002 17:02 buchanmilne

Re: vi rulzZz..

> well, you really think it is possible to
> create a better configuration tool than
> vi??????

Not necessarily. Maybe we can make vi display help on the configuration entry you are using. Maybe not all people care to learn vi.

> all-in-one configuration tools suck,
> because 2 seconds after publishing them,
> someone releases a new version of
> his/her program with millions of new
> features and your super trooper
> linuxconf/yast2/orhoweveruwannacallit is
> out of date.

That is one of the specific things a tool like this would address. By having some sort of meta-configuration information (shema files) which are maintained by the project the files configure. Thus, they should never be out of date.

> one last question: how can i use a
> "graphical
point-and-click"
> configuration tool on my server without
> a mouse/X-server???

A graphical interface would only be one frontend to a really good backend. Tell me you wouldn't like to be able to do:

# config http add_virtual_host my.domain.com /var/www/mydomain.com

16 Feb 2002 17:22 Stonefly

Re: vi rulzZz..

>
> % well, you really think it is
> possible to
> % create a better configuration tool
> than
> % vi??????
>
>
> Not necessarily. Maybe we can make vi
> display help on the configuration entry
> you are using. Maybe not all people care
> to learn vi.
>

u wanna make vi doing what?
are u sure u know what a console based text editor is?

>
> % all-in-one configuration tools
> suck,
> % because 2 seconds after publishing
> them,
> % someone releases a new version of
> % his/her program with millions of
> new
> % features and your super trooper
> %
> linuxconf/yast2/orhoweveruwannacallit
> is
> % out of date.
>
>
> That is one of the specific things a
> tool like this would address. By having
> some sort of meta-configuration
> information (shema files) which are
> maintained by the project the files
> configure. Thus, they should never be
> out of date.
>

oke, one point for you

>
> % one last question: how can i use a
> % "graphical
> point-and-click"
> % configuration tool on my server
> without
> % a mouse/X-server???
>
>
> A graphical interface would only be
> one frontend to a really good backend.
> Tell me you wouldn't like to be able to
> do:
>
> # config http add_virtual_host
> my.domain.com /var/www/mydomain.com

i would like to be able to change the mtu settings on a windows machine with a text editor

16 Feb 2002 19:37 rmiddle

Re: And what about using "Brain"

> Yes, I mean the thing stuffed inside
> your head.
>
> Why do you need single configuration
> interface to
> all things that can be configured? Are
> you too lazy
> to learn how to configure each single
> one by one?
> Are you too lame?

No I am not but have you every spent 3 Days tring to find out how to ad a netbios name into redhat 7.0 so you could use DHCP with the old @home network. I have. It was hidden real well so well in fact that I help over 20 People fix that myself and know alot who just didn't bother and set themselves up as staticly and created all kinds of problems later on when that IP address changed and had to go upgrade it.

> For real, how many ways to configure
> things do you
> know? How many formats there exist?
> How many do
> *you* need to know? Let's count: you
> need to set up
> mail server, http server, samba, mail
> client, database
> server, window manager... How many
> have you
> counted to?

Have you looked at your /etc/ dir lately there are hundreds of files in there and some programs don't have just one.

> Can't you just learn how to configure
> these? I,
> personally, like learning stuff. Maybe
> you could give
> learning a try. I promise you'll learn
> much more than
> just configuration. You'll get somehow
> deeper look
> inside the thing you are configuring,
> how does it
> work. When you know what and why you
> are
> configuring, you'll definitely
> configure it better and it
> will work better for you.
>
> The best example I gould give you are
> "commented
> configuration files". Look at
> /etc/postfix/main.cf or
> /usr/local/apache/conf/httpd.conf e.g.
> Have you
> forgotten to read text? Have you
> forgotten how to
> launch a text editor and change some
> values in a
> file? What do you learn by clicking on
> checkboxes?

Have you ever looked at some of the config files in /etc. What about those thing that aren't well documented or even listed. As I said eairlier the fix for the computer name was to add a line in /etc/sysconfig/network-script/ifcfg-eth0 and add some command I don't even rember right now that caused the computer name to be presented to the @home DHCP sever. Which wasn't listed in the file or was it documents where the file was. After Looking thought hundreds of Sites I found on bugtrack report for something simlar that gave me that command and where to put it.

> Ah, you were talking about
> "newbie users". I believe
> that the best one can do to have his
> product easily
> unterstandable and configurable for
> newbies is to set
> up a fully functioning configuration
> 'out of the box'
> and keep the configuration files
> commented and
> simple to understand.

But Now back to the real world where most apps aren't well documented and even all the options aren't in the example conf because they are more rear but the author would be more likely to include in something like this. Althought I think it is a good Idea but I can't picture most projects going for something like this. Some will but many wont and that is why many of this projects fail.

Robert

16 Feb 2002 21:35 Ilan

Spaces, the filename frontier...

> /etc/conf/*.xml
>
> Perhaps one day, in a Linux
> distribution near you. =]

Or to better yet improve the configuration system, we could have:

/System Preferences/*.xml

It's about time we migrate folder names to Plain Damn English. If someone has a real religious problem with this, then they can stick to their little server closet ghettos where they belong. People who hate spaces in filenames and find gobbledygook filenames perfectly accetable should be permanently locked out of the linux desktop.

16 Feb 2002 22:42 lukekendall

Re: revised version

> I know the story is only 50 minutes old,
> but I've made some revisions already,
> which I think make it a little clearer
> what I'm getting at.

The window manager "Window Maker" uses a system like this; the library used is called libPropList.
It could probably be used as-is and meet most of your requirements. I'm not sure if it stores comments; all the same, it's used to excellent effect in the Window Maker configuration tool WPrefs.

That said, it was designed before XML really got accepted, so storing all the config info as xml may be a better long term solution - then at least any xml editor (or vi) would let you edit the configuration files.

Either way, the problem that remains is fitting in with existing practice. It would be nice to have an easy migration path.

If the developer has centralised all the configuration initialisation stuff, then things would be easy. You'd call the new config file reader function, which would fail if the file wasn't in the new format, and you'd call the old config file reader function.

If the developer hasn't centralised all the configuration initialisation stuff, and does it piecemeal, that's not too bad either, it just means that in each place where you probed the old config file for a setting, you'd call a new function that first checks if the config file is old or new style; if old style, it does what it used to, if new, it just grabs the named value out of the config data structure loaded in.

(I also thought that the Gnome or KDE people were tackling this problem; the idea was to have a text based config file, which got compiled into a fast-loading form. If the text file was a later date than the compiled form, the binary file was discarded and re-generated from the plain text file. But let's face it, that's simply an optimisation, it's not a requirement.)

Anyway, I agree that this is a serious and growing problem in Unix, that webmin does a great job, but that webmin's or anything elses's job would be much easier if the config file formats could be gradually moved across to all use one basic very free-format grammar, all accessible via one simple API. It would also make option setting and querying much easier for the developer.

Seriously, libproplist is well worth an examination. Ah ha! Looks like it's been incorporated into Gnome, in some sense at least. here

I think Window Maker's libproplist was designed to give the kind of functionality you had in Nextstep. They, unfortunately, stored config info only as binary files, though at least they had commands that could be used to get and set values from the command line, or even dump out the whole file in textual form. (dread and dwrite.)

That kind of thing would be very useful in this new proposal. It would be nice to be able to just query the current setting of some option, examine it, and then write back a modified form, all from the command line.

17 Feb 2002 07:28 buchanmilne

Re: Spaces, the filename frontier...

> Or to better yet improve the
> configuration system, we could have:
>
> /System Preferences/*.xml
>
> It's about time we migrate folder
> names to Plain Damn English. If someone
> has a real religious problem with this,
> then they can stick to their little
> server closet ghettos where they belong.
> People who hate spaces in filenames and
> find gobbledygook filenames perfectly
> accetable should be permanently locked
> out of the linux desktop.

Obviously you don't spend a lot of time on a console. Obviously you haven't tried to admin a unix box with a minimal shell (that doesn't complete) from a terminal client that doesn't send back-spaces. I can agree with more descriptive names, but don't make me change case or have to escape spaces. Even die-hard windows people complain about Program Files, My Documents, Documents and Settings etc (I am not prepared any more of those now, when I could type progs, docs and home - which is what I use on windows boxes).

Anyway, the point of the excercise is to prevent you from having to actually edit any of the files by hand (although it should be possible). You would rather be using one of the front-ends, so you wouldn't know if it was /etc (1 second to type) or /System\ Preferences (4 seconds to type), or /system_preferences (2 seconds to type)

17 Feb 2002 07:48 buchanmilne

Re: vi rulzZz..

> u wanna make vi doing what?
> are u sure u know what a console based
> text editor is?

You could have vi display the hints for the configuration option in another buffer (like the way the help works). OK, maybe emacs would be better for this. But yes, I know what a console editor is, I currently use vim-enhanced about 15% of the time I use a computer.

> % % one last question: how can i use
> a
> % % "graphical
> % point-and-click"
> % % configuration tool on my server
> % without
> % % a mouse/X-server???
> %
> %
> % A graphical interface would only
> be
> % one frontend to a really good
> backend.
> % Tell me you wouldn't like to be able
> to
> % do:
> %
> % # config http add_virtual_host
> % my.domain.com
> /var/www/mydomain.com

Of course, I forgot to mention that this would make the tool scriptable, so you could do:

# for i in my yours hers everyone;do
config http add_virtual_host $i.domain.com /var/www/$i.domaim.com;
done

Wouldn't that be cool?

> i would like to be able to change the
> mtu settings on a windows machine with a
> text editor

C:\>regedit /s mtu.reg
(you use the text editor to create mtu.reg of course)

But then you run into exactly the same problem. Which registry keys do you change? What value do you need to put into the key?

Maybe we could make a backend for you that writes a .reg file for you, and then installs it on the remote machine for you. If you are working locally, it's even easier.

17 Feb 2002 20:10 kat

In With the Old, In With the New

I agree with most of the things said in the article -- an easier common configuration is needed. Ignore the flamers who want to stay in their 3l33t hell -- I use vi(m) with the best of them, but I'd still rather have a tool which helped me pick options quicker and still enable me to edit the config file later by hand if I wanted to.

Two main partial solutions have been proposed, Webmin and Gconf. Webmin is cool, I use it myself, but I agree that it has limitations, mainly the web-only interface, and the lack of including of the helpful comments. At least it does allow you to go back and edit the original config files, rather than mangling them beyond recall, as other tools have done in the past. Gconf may be cool, but it has even more of a hurdle -- correct me if I'm wrong, but I gather it requires the application to be rewritten to use Gconf, it won't work with existing text configuration files.

If one really wants a common configuration interface

one must make it easy for the application writer to write the "meta config" files for it -- because the harder it is, the more likely that the application writer simply will not bother, and there goes your dream of the application writer keeping the interface up to date for you.

Whatever the system is, it shouldn't require the application writer to rewrite their application in order to use it -- though they may if they want to (the idea of being able to call the config engine from an application's File->Preferences menu is cool, but not if it doesn't have a File->Preferences menu!). But, realistically speaking, hands up how many people think that the author of Sendmail will rewrite it to use Gconf? Oh, really? Well, I have this bridge I can sell you...

The point is, that the interface is not required to be an interface with the program itself, but with the program's configuration files. The idea of backend and frontend plugins is a good one, so long as whatever does the translation (to XML, maybe) does preserve all of the original configuration file's information -- or we'll get back to the trash-the-config-file-hell we want

to avoid with a general configuration tool.

Plugins allow flexibility and, hopefully, the application

of more volunteers to help make the tool more useful.

So what if some particular config file style is only used

by one particular application (say, Sendmail...) -- if
somebody wants to write a plugin for it, that's another
blow for democ- well, a blow for diversity, anyway.

An alternative to having the application writer write

the metafile would be to have volunteers write them for

particular applications if the application writer in question won't do so. After all, we can't assume that

every application writer will do so, and presumably

it shouldn't be harder to get volunteers for such an effort

than it is to get volunteers to make Webmin modules

(or Debian packages, for that matter). (Though, how

hard is it to write a Webmin module? Not trivial, I expect.)

Another reason such a configuration tool needs to be able to read original existing configuration file formats is that users won't be too pleased at losing all their

customisations the first time they use the tool because

their old config files are no longer used.

(Another problem I have with Gconf is really just a bleeding edge problem; I tried to get the most recent version of Galeon running, and it wouldn't because I didn't have the latest version of Gconf. But that's more of a Galeon problem than a Gconf problem and I shouldn't blame Gconf for it...)

(And while I'm going for asides, the person who was

complaining about how hard it is to get at the documentation, since some is manpages, some HTML,

some info, some Pod and so on --

Webmin has a really useful

module for System Documentation, which will search

all of the above documentation types for you,

and give you access to all the documents it finds.

So it doesn't matter if it's a man page or a HTML file,

or a plain text README file, you can read it.)

Enough asides. But I think if I go on I'll start repeating myself....

18 Feb 2002 04:55 nagora

Re: real solutions
Obviously, XML is a grand choice for
this- because it's designed (more or
less) for exactly this purpose.

The idea of using XML to make anything simpler is like using petrol to fight fires.

TWW

18 Feb 2002 06:00 malaba

Re: Spaces, the filename frontier...
I would add that puting capital letter
here and there contribute to the
"carpal tunnel syndrome".
If you try to write rapidly,
with time, it could hurt a lot.

I totally agree on "no space, no capital letter,
no strange characters and small is beautiful"

:o)

18 Feb 2002 06:16 kiwipeso

Kaos unix configuration
I'm developing a new Operating System, Kaos.
Kaos is a rewritten BSD with an exokernel, XML
filesystem, MIME database and encrypted filesharing/
IM.

I use XML as the main document satndard so I can tie
the filesystem to the search database to MIME to
filesharing and configuration files.

By using XML as a semantic web, a Grid operating
system can be installed, run and operated inside a web
browser running on your old OS before you startup
from the Kaos ramdisk loader.

This means configuration files are easy to edit, setup in
a web browser or use in a GUI program.
This also allows for SQL tables, java wizards or perl
scripts as plugins for even more simplicity.

Kaos will accept all existing BSD code and is likely to
accept some standard linux formats.

18 Feb 2002 06:19 opk

Further ideas for new approach
I've thought about this before and considered starting a project. I used to do sysadmin on AIX and the AIX smitty tool is great. You have both a curses and GUI interface. One of the things I really liked was that by pressing F6, it would list which UNIX commands it was going to run to make the change. I could still do much of my administration with vi and from the command-line - much better than Linuxconf.
The article talks a lot obout configuration files but where possible external commands should be used - useradd/usermod etc, chkconfig for init levels, the print subsystem. For these things shell scripts could be stored and processed through m4 to cut them down to be as minimal as possible.
I also think XML is fairly suited to this task (though I've seen XML used in places where it shouldn't have been). We could start with an XML definition of all the configuration possibilities (though using the file-system for much of the division). XSLT could then process this down to make a platform dependant set of files. So an application could install its own XML definition files and the config tool would instantly be able to configure it. The XML might be a little like an HTML form with more info on processing. The config tool should definitely also allow different interfaces, especially including curses (text mode).I'd definitely be interested in helping work on such a project so if anyone starts one, let me know.

18 Feb 2002 06:32 Cabuzel

Re: And what about using "Brain"

>
> % Not to mention that there *are*
> % newbies to the system that don't
> want to
> % learn at all. They just want to get
> the
> % task done without spending a week
> % learning how to setup a webserver.
>
>
> Why are we worried about newbies who
> don't want to learn at all. Making
> things easier is one thing but totally
> revamping everything that people have
> worked on in order to support people who
> aren't willing to learn.
>
> If you can't read the documentation
> and manage the softwares configuration
> files, then maybe you shouldn't be
> running the software.
>
> I personally think that some packages
> such as apache, samba and many others
> have quite understandable config files.
> Although they are completely different,
> understanding the configuration is part
> of the learning process. I say tough
> shit, if you aren't willing to learn.

To set up:
- I am a newbee in Linux.
- I have a big windows background.

Yes, I agree, some packages have quite understandable configuration files. My goal is to set up a Web & Mail server for my family. I have no problem to learn. For example, I have no problem with PHP and MySQL config files. But I am stuck on virtual domain in Apache (I try to configure Apache as www.mydomain.org and someprefix.mydomain.org point to 2 distinct web site). Sendmail configuration scary me to the point I try to find another Mail server more easy to configure.

A linux newbee.

18 Feb 2002 06:59 prefect

Re: And what about using "Brain"

> Sendmail
> configuration scary me to the point I
> try to find another Mail server more
> easy to configure.
%
> A linux newbee.

I'm not a linux newbie, but I refuse to use
sendmail on principle, because the configuration
file format is atrocious. I always revert to
using qmail or exim, both of which are fantastic.
The misconception is that easy and powerful are
at opposite ends of some mystic scale.

jh

18 Feb 2002 07:37 pointal

An adaptable configuration system
For a project I develop at work, we have a similar problem: what to use for configuration files. In previous developments (under Windows but the problem remain the same), we used INI files, registry, registry mimic via directories and text files.
None was perfect, and the bad new is that each time our code depend on that configuration system.

So we develop a configuration front-end, using configuration resource URL, and entity name in that configuration resource. A function resolve the resource URL and the entity name and return an object which allows to access informations about the entity at the URL (after that informations are stored as paired name=value grouped by logical named sections).

Our code has not to know about configuration storage format and it has not to know about the protocol to access the information and the storage format, its processed by intermediate tools in the configuration library.

Currently we have only support for our text file format (see below), but i'm working on registry storage access (to include one of our new libraries into an older project - this library will need no code modification to use registry in place of text file).

Such a configuration tool allows you to store configuration data anywhere (maybe on remote computer, accessing it via LDAP or CORBA or SQL...), again its upon the configuration protocol support libraries to deal with that and to offer a standard interface.

Ex. of URL: fileconf:C:\confs\myconfig.txt
Ex. of URL: HKLM/Software/LURE/Disp
Ex. of our text configuration file
# This is a conf file
# Start an entity:
@Motor Bragg
# Start a section
[Unit]
unit=cm
longunit=centimeter
# Start another section
[target]
device=Motor2
protocol=CORBA
# Start another entity
@Motor Alpha
#... & co

A+

Laurent Pointal
CNRS - LURE

18 Feb 2002 07:42 beezly

Re: A few basic but never-used point

> 1) NEVER EVER write or modify system
> directory, that mean for example, dont
> create directory in / ( which is
> obviolously a system directory) or don't
> install any application in /usr: /usr is
> no longer a user partition since at
> least 10 year. This is now part of
> system directory.
> If you are not writing/installing a
> system things, go away from /, /usr,
> /var...
> A 7 year admin. Having admin 100 sun
> and 30 FreeBSD & linux.

Someone with 7 years admin experience should know that /usr DOES NOT mean "User". /usr historically mean "Unix System Resources".

Beezly

18 Feb 2002 07:42 chtephan

GConf
I always wondered, if we couldn't use GConf for this.

(as you know, GConf is a new backend configuration engine used in gnome).

GConf is modular, it uses plugins to store the configuration. The default plugins are xml files oder dbm files. The whole configuration on the frontend is shown like a big registry (like in windows), so the interface is easy to use and allows nice configuration applications to be written, but in contrary to windows, it doesn't write everything in one big file, but in separate files like tradiotional unix configuration files.

Now, if you write plugins to handle all the file formats in /etc, it should be possible to use GConf to handle this quit nicely.

Another point why GConf is great: The communication with GConf is done through a server process which keeps track of modifications. You can register callbacks if someone changes the configuration. So e.g. if someone changes the apache configuration file, you would immediately know it and send HUP to it. Or something like this.

You could even use it to do remote administration since it uses CORBA as communication engine, but there remain some security problems...

18 Feb 2002 07:59 cam000

config management on a PDA
I am interested in configuration from a point of view of the Linux PDA. There is a real need for lightweight, centralised config management. Some of the requirements are:

* low memory usage
* one interface to the config, not duplicated effort (ie. one option setting library vs. every app having a custom written options page)
* persistence of options (obvious)
* buffer changes to prevent continual writes to disk/flash
* ability for apps to behave more like daemons in restarting and re-reading config files on the fly.

The best thing about doing this on a PDA is that it is a limited platform, so it is a feasible target to rewrite the config interface to every app and daemon on the platform.

There is a good page on config storage here:

www.cbbrowne.com/info/...

I used to have a link to a linux registry project that was widely dissed, I think for the wrong reasons. I hope they didn't give up. IMHO there are great gains in taking the responsibility for config file parsing, editing, restarting and so on away from the application programmer.

Some other comments on the article:

* application programmers should be able to 'layer' their option changing interface over the standard - eg. to provide a visual representation of page margins, line spacing, paragraph positioning etc. instead of the underlying numbers.
* internationalisation should be a separate issue. Config values are code. Static language dependent prompts should be internationalisable. But if a french guy wants to rename his 'Inbox' it is a matter of personal preference (config editing) not internationalisation. All we need is the ability to set default config settings depending on language preference.
* you do not mention management of config between different versions of applications. Imagine being able to: back up Abiword settings; update to latest version; revert to previous version (and settings)... all with minimal effort on the part of the application programmer.
* the trouble with maintaining a master copy in existing files is the potential for damage by a user.
* no mention of the ability to store the config centrally yet present it as a number of text files... think /proc

And I wish people would stop knee-jerking and shouting XML. That is great for interchange between systems but has little to offer as a config file repository. All the man-readablity of a binary database and all the bloat of text files. IMHO we need text files or a binary registry. Imagine a registry coded with unix values at heart, presented as a filesystem of text files: /conf a bit like /proc... I dream on!

-Cam

18 Feb 2002 07:59 ddubois

Re: Spaces, the filename frontier...
I dont think it is a good idea since:

1- a lot of people/programs are used to this.

2- this is not as complicated as that.

3- it is easier to borwse using the CLI

But if you like this you can create your symlinks or even create your new distro with this kind of naming....

D.

>
> % /etc/conf/*.xml
> %
> % Perhaps one day, in a Linux
> % distribution near you. =]
>
>
> Or to better yet improve the
> configuration system, we could have:
>
> /System Preferences/*.xml
>
> It's about time we migrate folder
> names to Plain Damn English. If someone
> has a real religious problem with this,
> then they can stick to their little
> server closet ghettos where they belong.
> People who hate spaces in filenames and
> find gobbledygook filenames perfectly
> accetable should be permanently locked
> out of the linux desktop.

18 Feb 2002 08:56 fcsaszar

Re: Configuration made simple...

> /etc/conf/*.xml

Yeah, this is it. Now let's talk about the schema. It should be something like
this:

<parameter>

<name>TimeToWait</name>

<type>smallint</type>

<value>10</value>

<unit>minutes</unit>

<description>Time in minutues 'till screensaver starts working</description>

<comment> JSmith 2002-01-01: changed to 10</comment>

<comment>Tom: 2002-02-05: prefer to use 15</comment>

</parameter>

Some notes:

"comments" are optional.
A GUI is straigthfoward to do. The XML parser it's done.
The only thing missing is to package it to make it appealing to the developers.

I agree with almost everyone: this is something very important and useful
to do. It should be an Open Source project!

18 Feb 2002 09:28 TrebleJunkie

Re: And what about using "Brain"

> Why are we worried about newbies who
> don't want to learn at all. Making
> things easier is one thing but totally
> revamping everything that people have
> worked on in order to support people who
> aren't willing to learn.

I run Linux. A lot of Linux. I was and am willing to do what it takes to learn what I'm working on. I have an entire bookshelf of O'Rielly and other Linux books. On Bind. Samba. Sendmail. PHP. Apache. Linux-in-general. PostGres.

I run Windows. A lot of Windows. I was and am willing to do what it takes to learn what I'm working on.

I don't own a single windows-related book. Not one. Not IIS. Not SQL Server 7. Not PPTP. Not Windows-in-General.

If Linux was a thing of ease and beauty, I could see your point. It's not. If we want Linux to succeed in the server room, the boardroom, and the living room, frankly, Linux needs to be easy enough for a "newbie." Moreso, it needs to be easier for me, a guy trying to use it to get his job done.

As it is, Linux needs to be made easier, even for the "experts." I think the author of the above article missed the boat, bigtime. It's not the *format* of the configuration files that a problem. Okay, well, it is, but not THE problem. THE problem is that configuration files (and, well, if you think about it, APPLICATION files are strewn all over the damned disk seemingly without any rhyme or reason. I've been running Linux now for at least 6 years. I've built web servers. I've built database servers. I've built VPN routers. And you know what? I STILL have to do a "find" every time I need to edit a damned apache or postgres config or god forbid start a daemon manually. Even worse if it's something I *dont* use as much.

No, the big problem with ease of use is that there's no one place to find config data or applications.

Windows may have one big "registry," but at least it's easy to find. And it's a pretty safe bet you're going to find programs you've installed under "Program Files." The Linux community, and especially distro packagers would do well to take note.

And complain about newbies all you want, but they're vital to the survival of Linux. Help them to learn, DON'T call them stupid. They are NOT a waste of time, they are the future of Linux. Realize, too, that if you make changes to the OS that helps them, you're helping yourselves in the long run, too.

18 Feb 2002 09:50 alex9er

Configuration
I really don't want to mock around, but if Linux ever wants to be popular on desktops, it needs grafical "point and click" interface/program to modify it's configuration.
Yes, Windows Registry is garbage (not stable, not editable in text editor on console, etc.) BUT IT WORKS... most of the time.

Greets,

Alex

18 Feb 2002 09:52 philhoward

Re: real solutions

> Obviously, XML is a grand choice for
> this- because it's designed (more or
> less) for exactly this purpose.
>
> The idea of using XML to make anything
> simpler is like using petrol to fight
> fires.
>
> TWW

I have to agree. People think that because XML doesn't have binary byte codes, it must be easy to edit. However, it's syntax is not. It requires a lot of extra typing work for no gain, and with tags jammed up with text, it's hard to even read (sure, easier than byte codes in vi, but not as easy as something simple, like how BIND does it for named.conf, as an example). XML is also adding ambiguity when you look at how different people are using it, where some "data" is in the document part (between tags) and in the "meta" part (inside the tags). XML was based on syntax intended as markup for documents (e.g. text and other renderable objects). It makes a lousy data language, by taking the worst of things.

18 Feb 2002 10:12 quinticent

We have a perfect language to handle this
Everything the author put forth can be handled by XML. Providing a Schema (I prefer RELAX-NG to XML Schema) for Linux configuration files to use as a standard will allow vi/emacs lovers to edit a config file by hand and still keep a file well formed for front end config tools. In fact XML goes a step further and allows for easy translation via XSLT. This makes automating building of frontends from the actual config files easy. Frontends would no longer need the amount of manpower currently required to keep it in sync with current config file formats. Think HTML frontends, textbased frontends and graphical GNOME and KDE frontends that drop right into the control panel when installed. An author would just have to write an XML skeleton for the config and any of these frontends would instantly work. Sounds like a good direction to go in.

--
J5

18 Feb 2002 10:13 philhoward

Re: A few basic but never-used point

> Someone with 7 years admin experience
> should know that /usr DOES NOT mean
> "User". /usr historically mean
> "Unix System Resources".
>
> Beezly

The "u" actually does mean "user", though it is not a shortening of "user", but apparently it was considered to be very early on. It was probably a result of a cute word play.

The "s" does not mean system, it means "shared". So you get "User Shared Resource" (I've also heard argument the "r" meant "read/only", and even "region", but those have been much fewer). In this context "shared" means what all the users can use (not "shared" in the context of sharing the memory of a shared-object file, since that didn't even exist back in the early days).

18 Feb 2002 10:14 mikpos

Re: And what about using "Brain"

> I'm not a linux newbie, but I refuse
> to use
> sendmail on principle, because the
> configuration
> file format is atrocious. I always
> revert to
> using qmail or exim, both of which are
> fantastic.

Please, don't use the word "revert". exim and qmail are just plain better than sendmail. There's no reason to use sendmail.

18 Feb 2002 10:16 macc

Missing : Revision Control
What i miss with all config files is some kind of revision control.
to be able to
- back out a disastrous change affecting more
than one config file with a couple off keystrokes
- to have distinct config states
- to do temporary changes and return to your old config
- to merge in those new options that have been introduced
but not loose your current config
- whatever else your tortured mind comes up with

18 Feb 2002 10:55 mbrix

So where do we start?
I like the article and the good-hearted purpose. But is anyone taking up the task?

I feel that this is "empty talk" if noone is going to take up the quest to start such project. A project to write documents about the configuration formats, create the APIs for different languages and to try getting this into LSB.

I would like to be a part of such project and to contribute with code and ideas, but I don't feel like I have the skills nor the time to lead it.

18 Feb 2002 11:37 cinnix

Re: And what about using "Brain"

>
> % Sendmail
> % configuration scary me to the point
> I
> % try to find another Mail server
> more
> % easy to configure.
> %
> % A linux newbee.
>
>
> I'm not a linux newbie, but I refuse
> to use
> sendmail on principle, because the
> configuration
> file format is atrocious.

I agree, the sendmail config file is a crazy mess. I am not trying to promote qmail, but I really like how the configs are set up.

It uses several config files where each serves one pupose only. There is no syntax to learn. You just put the name of your virtual domain in the vitualdomains file.

echo "mail.new.domain" >> /var/qmail/control/virtualdomain

Sure seems easy to me.

The one thing I don't agree with though is unconventional location of files in qmail. I still agree with the outlines set by the FHS, but qmail is definitely on to something

18 Feb 2002 12:10 tmathews

Re: Configuration made simple...
From a GUI, it might not be too bad, but I wouldn't want to have to recreate that by hand in a text editor.

18 Feb 2002 12:21 osama

Re: Configuration made simple...

>
> % /etc/conf/*.xml
>
> Yeah, this is it. Now let's talk about
> the schema. It should be something like
>
> this:
> <parameter>
>
>
> <name>TimeToWait</name>
>
> <type>smallint</type>
> <value>10</value>
> <unit>minutes</unit>
> <description>Time in
> minutues 'till screensaver starts
> working</description>
> <comment> JSmith 2002-01-01:
> changed to 10</comment>
> <comment>Tom: 2002-02-05:
> prefer to use 15</comment>
>
> </parameter>
> Some notes:
>
> "comments" are optional.
> A GUI is straigthfoward to do. The
> XML parser it's done.
> The only thing missing is to package
> it to make it appealing to the
> developers.
>
> I agree with almost everyone: this is
> something very important and useful
> to do. It should be an Open Source
> project!
>
>

i think we should separate values (data) from defaults, descriptions, comments, additionally, older configs could be archived (smb.cf.1.gz, smb.cf.2.gz, ...etc. like logs)

How about something like this:

/etc/conf/smb.cf
==========
<global>
<string name="workgroup" value="MYGROUP"/>
<bool name="loadprinters" value="1"/>
<int name="maxlogsize" value="50"/>
</global>
==========

/etc/conf/smb.cf.setup
==========
<global>
<string name="workgroup" value="WORKGROUP" caption="NT Domain or Workgroup name" Comments=""/>
<bool name="loadprinters" value="0" caption="Automatically Load Printers" Comments="If you want to automatically load printers, set this to true"/>
<int name="maxlogsize" value="50" caption="Maximum Log Size" Comments="The maximum size of the log in kilobytes."/>
<multivalue name="printing" value="cups" caption="Print System Type" Comments="The Print System Type">
<value name="cups">
<value name="bsd">
<value name="sysv">
<value name="plp">
</multivalue>
</global>
==========

18 Feb 2002 12:28 tmathews

Re: And what about using "Brain"

>
> As it is, Linux needs to be made
> easier, even for the
> "experts." I think the author
> of the above article missed the boat,
> bigtime. It's not the *format* of the
> configuration files that a problem.
> Okay, well, it is, but not THE problem.
> THE problem is that configuration files
> (and, well, if you think about it,
> APPLICATION files are strewn all over
> the damned disk seemingly without any
> rhyme or reason. I've been running
> Linux now for at least 6 years. I've
> built web servers. I've built database
> servers. I've built VPN routers. And
> you know what? I STILL have to do a
> "find" every time I need to
> edit a damned apache or postgres config
> or god forbid start a daemon manually.
> Even worse if it's something I *dont*
> use as much.
>
> No, the big problem with ease of use
> is that there's no one place to find
> config data or applications.
%

TrebleJunkie made a lot of good points, but this one I think is key. There are certain defined ways that the directory structure and thus the config files on a *nix system are supposed to be layed out. Unfortunately a lot of developers have strayed from this. Yeah, one set way of writing config files would be nice, but if you can't remember where the files are your job won't be any easier.

18 Feb 2002 12:31 cinnix

Re: And what about using "Brain"

>
> % Why are we worried about newbies
> who
> % don't want to learn at all. Making
> % things easier is one thing but
> totally
> % revamping everything that people
> have
> % worked on in order to support people
> who
> % aren't willing to learn.
>
> And complain about newbies all you
> want, but they're vital to the survival
> of Linux. Help them to learn, DON'T
> call them stupid. They are NOT a waste
> of time, they are the future of Linux.
> Realize, too, that if you make changes
> to the OS that helps them, you're
> helping yourselves in the long run,
> too.
>

I am not calling newbies stupid or a waste of time, and you are very correct in calling them the future of Linux.

What I am saying is that a newbie who doesn't want to learn is a waste of time. I am willing to help any newbie with anything I can as long as they are trying to learn.

There is a reason that most seasoned Linux users aren't asking for major configuration changes. The reason is that they learned their way around a system and found out that 'in most cases' the current way things are done works quite well. There are some things that could stand to be a little easier, but this is absolutely no reason to revamp the way things are done.

A couple of problems with things such as webmin is....
(bear in mind that webmin is just an example, many of these thoughts can apply to to other methods too.)
1.) Security. I have seen it time and time again. Sacraficing security in order to make something easier is unacceptable to me.

2.) It prevents you from taking advantage of the software on your system. It's true that webmin lets you do things with minimal effort, but you get minimal options compared to what is available.

3.) It prevents you from knowing about the software. There are times when webmin isn't available such as at a remote location, (please don't tell me that you are using webmin remotely. The 11th commandment should be "Thou shalt not use webmin remotely"). In the chance that webmin available then you are lost without it. (Imagine configuring BIND with webmin without learning how to do it manually. Once you have that picture in your head, try to imagine settting up a DNS record without it. It would be a nightmare, plain and simple.)

Which reminds me a lot about windows. I know how to do all kinds of things in windows because of all the pretty interfaces, but I have no idea what the hell what is actually happening or what I would do if these interfaces were gone. If you give new Linux users the same kind of , then you are going to have Linux users who are pointed in the wrong direction and they will never learn how to handle things without it.

18 Feb 2002 13:01 karlheg

Re: GConf

> I always wondered, if we couldn't use
> GConf for this.
>
> (as you know, GConf is a new backend
> configuration engine used in gnome).

I think that this is exactly what "gconf" and "debconf" are designed for. (Perhaps "debconf" can use gconf? I'm not sure yet, since I've not spend much time studying this problem yet.) If "gconf" is not completely up to the task, then perhaps it is where development should be focused, to make it capable enough.

18 Feb 2002 13:48 waldoj

Extremely Important
Creating a unified configuration front end is perhaps
the single most important task remaining prior to
widespread Linux adoption. I suspect that we're
approaching a saturation point on acceptance of Linux
by Windows admins until we have a system of this
nature. Further, there are a lot of admins (mine
included) whose lives would be simplified tremendously
by this system.

Sure, I know how to appropriately modify Sendmail/
Apache/BIND/xinetd/etc., but the fact that everything is
so spread out is not at all helpful. If I want to add a
new domain to DNS, HTTPD, and my MTA, the process is
considerably more involved than it should be.

A unified XML-based data storage system (thus both
human and machine parseable) is clearly the solution
to this process, allowing any number of configuration
applications to take advantage of this common storage
system and simplify the process of Linux adoption as
well as make things easier for existing Linux
sysadmins.

18 Feb 2002 13:49 karlheg

Re: And what about using "Brain"
The real problem is not having to edit conffiles, but that there is so much redundancy in them. How many of them contain the hostname, or the IP, or ranges of IP's, etc. When you change your hostname or domain, you must edit several conffiles to fix things up. That's not very often on most boxes, but what about on a laptop?

The big thing that a centralized conf manager would do would be to consolidate that redundant data... to normalize the global confdata schema.

18 Feb 2002 14:18 cfadam

Re: Kaos unix configuration

OK, so where is the code? I checked out your site and saw nothing but a "wish list" of features you want to implement. Personally, I liked your idea, but if all you are going to do is spam this post with links to your vaporware OS, then take a hike.

The proof is in the code man. I also found it amusing that no part of your website may be stored in a computer per your copyright.. are you unaware of caching?

Best of luck in the future, but I still suggest you give back to the community from which you take. Your site mentions nothing about OSS, nor any plans to release your code under any open license. Maybe if you open-sourced your idea you would get some like-minded developers to help, but instead you have a 6yr old site dedicated to an OS that probably won't ever make it past the drawing board.

18 Feb 2002 14:25 ttfkam

Re: Spaces, the filename frontier...

> Obviously you don't spend a lot of
> time on a console. Obviously you haven't
> tried to admin a unix box with a minimal
> shell (that doesn't complete) from a
> terminal client that doesn't send
> back-spaces. I can agree with more
> descriptive names, but don't make me
> change case or have to escape spaces.
> Even die-hard windows people complain
> about Program Files, My Documents,
> Documents and Settings etc (I am not
> prepared any more of those now, when I
> could type progs, docs and home - which
> is what I use on windows boxes).

And obviously you think that trying to admin a box without bash (or an equivalent) is acceptable. If you're the admin, you decide what goes on the box and unless it's an embedded device, there is no excuse for continuing to use a broken shell. And if it's an embedded device, you shouldn't have a shell anyway -- the content is usually fixed and so configuration options are usually as well (fixed in the number of options, not that the options can't be changed).

"Program Files" is only an issue because cmd.exe (a) doesn't have filename completion by default, (b) doesn't allow backslash escaping for spaces, (c) is a broken shell by anyone's standards, and (d) Windows was not designed for and was never intended to be run from the command line. Your "die-hard" Windows users were probably old-school DOS users who couldn't come to grips with the fact that MS never cared about their command interpreters/shells even when DOS was their main OS (glorified program loader).

Real die-hard Windows users use it the same way as Joe Sixpack: clicking on the folder called "My Documents."

The point is that we need to move past cryptic names and make the system usable without reading half a dozen HOWTOs. The proper way to handle the info wouldn't be by editing the raw config file anyway. There should be more control than that. Not because people shouldn't be allowed to configure their own machines, but rather that people make mistakes. Editing raw text is error-prone. Updating a configuration through an API allows for type checking and other minor error handling. I agree that the config files should still be there, but if your reason for keeping them cryptic is so that they will be easier to use(!?!) is illogical. We should be moving in a direction that makes it optional to edit them directly, not the primary method to configure.

18 Feb 2002 14:34 cssharp

While we're at it...

Who's benefitting from having config files it /etc, man pages in /usr/man, libraries in /usr/lib, cache and locks and things in /var, and the program binary in /usr/bin?

I suppose originally those things made it easier for the system, not necessarily the user or the administator: have PATH check /usr/bin, have man check /usr/man, go look for shared libraries in /usr/lib, and so on.

Let's have a bit more than a config read/write library. Let's encapsulate a program and all of its files into a single system subdirectory. Installation and uninstallation of a program becomes easy. Complete backup and recovery of an application becomes easy. A clean separation between programs is better than an arbitrary intermingling.

The Windows Registry is successful because it's actually easier than managing a specific config file. This common interface allows us to do it one better: still an easy add/get/remove interface, but intead of storing the data globally in the registry (or semi-globally in /etc), it's local in that programs directory. That's both more sane and more clean.

And, of course, it can be extended so that user prefernces for an application can overlay the global config through a similar structure in the user's home directory. With a properly thought out API, programs can now have very easy access to both system and user configuration.

Let's try more than to just chase tails. Let's lead the pack.

18 Feb 2002 14:38 ttfkam

Re: An adaptable configuration system

> at the URL (after that informations are
> stored as paired name=value grouped by
> logical named sections).

In other words, standard Windows INI format. A format that Microsoft itself has abandoned for all of its programs because of its limitations.

1) It allows for only two levels of hierarchy (group and key/value pair)

2) Has no provisions for meta-data or structure enforcement
2a) because of this, a configuration tool would have to know about every program it configured in order to update as opposed to a unified method of defining what parameters are allowed and what types are allowed in that parameter.

3) Comments are not associated with the parameters to give context.
3a) Configuration tools would have to either assume that all comments above (or below or next to) a particular parameter were associated or none of them are and thus probable discontinuity between what the UI says the parameter does and what the config says that the parameter does.
3b) There is no distinction between a parameter comment (what the parameter does in all cases) and an instance comment (what the parameter does for your particular installation).

Addendum: Does your parser read and process Unicode characters properly? Can you assume that all programs who use this library will have no reason to store non-Latin1 values?

Now you can either try hacking these items into your config library/format or you can just bite the bullet and use XML.

18 Feb 2002 14:54 ttfkam

Re: real solutions

> However, it's syntax is not. It
> requires a lot of extra typing work for
> no gain, and with tags jammed up with
> text, it's hard to even read (sure,
> easier than byte codes in vi, but not as
> easy as something simple, like how BIND
> does it for named.conf, as an example).

Yeah, so difficult to understand that no one would ever write any significant amount of work with anything like it. Execpt maybe for HTML and the web. I think you grossly overstate it's complexity and "extra typing work." For the record, when supplied a DTD, emacs can tell you which tags to use and closes them for you. Ends up being less typing work.

> XML is also adding ambiguity when you
> look at how different people are using
> it, where some "data" is in
> the document part (between tags) and in
> the "meta" part (inside the
> tags).

As opposed to the far wider variety of ambiguity in plain text config files (PTCF)? PTCF don't stop at attribute vs. element data. With PTCF, not even document structure is uniform. And if folks came up with a common configuration schema for XML, the ambiguity is gone.

Personally, I like some diversity. Each program configured through an XML file with an associated DTD, XML Schema, or RELAX-NG metafile would suit me just fine. At least it would give configuration tools something with which to work. With PTCF, configuration tools are completely brute force -- thus the problem.

18 Feb 2002 14:56 karlheg

Re: Spaces, the filename frontier...

>
> Or to better yet improve the
> configuration system, we could have:
>
> /System Preferences/*.xml
>
> It's about time we migrate folder
> names to Plain Damn English. If someone
> has a real religious problem with this, [...]

A big problem with that is that many existing shell scripts assume that there are no spaces in file names. The shell splits lines into tokens on whitespace. Spaces in filenames thus cause trouble unless the scripts are carefully written. (insert perl banner ad here). Zsh and Bash both support array variables, and filenames can be gotten via "find -print0"...

It would take a certain amount of effort to audit all scripts for this weakness. It would also require the addition of a clause in the distribution policy document, and once that's done, all new scripts would require audits for "sif" (space if filename) bugs.

18 Feb 2002 15:11 ttfkam

Re: And what about using "Brain"

> Why do you need single configuration
> interface to
> all things that can be configured? Are
> you too lazy
> to learn how to configure each single
> one by one?
> Are you too lame?
>
> For real, how many ways to configure
> things do you
> know? How many formats there exist?
> How many do
> *you* need to know? Let's count: you
> need to set up
> mail server, http server, samba, mail
> client, database
> server, window manager... How many
> have you
> counted to?

How much do you know about how to build a house? Have you studied the blueprints? Are you competant enough to rewire your house or make additions? Or do you just live there?

How much do you know about how your car works? Do you need to read the manual for 2002 Ford Explorers to know how to use it or do you just assume that the unified configuration format for cars is sufficient (put pump in gas tank hole, pull out dip stick and add oil as appropriate, use wheel for steering, accelerator as right foot pedal for moving faster, brake directly to the left of accelerator for moving slower)?

You should not need to know how it works in order to use it. Division of labor and all that. If everyone had to spend the time necessary to become familiar with a new config file format for every program they use, no one would get anything done because most people who aren't in the computer industry have better things to do with their time. An artist doesn't care about a geek's hardon for Apache's config file format. The artist just wants to put his/her artwork up on the Net for people to see. If it's difficult to do this, the geek's done something wrong it exactly the same way that if the artist creates something without any aesthetic value, the artist has done something wrong. After all, we shouldn't have to take an art class just to enjoy a piece of artwork, right? It may help, but it shouldn't be necessary.

18 Feb 2002 15:30 ttfkam

Re: Missing : Revision Control
I'd prefer that this was handled at the filesystem level: something akin to SnapFS (lwn.net/2001/0308/kern...), but it's development seems to have faltered. I believe the idea is sound however and solves more revision issues than just configuration files.

18 Feb 2002 15:41 colinsmith

LibCFG: A configuration management API
Already exists, here, in Freshmeat.

You may not like the API, you may not like the code and you may not like the current storage mechanism but, the concept is the correct answer to the problem. The rest can be fixed.

18 Feb 2002 15:43 ttfkam

Re: While we're at it...
A registry-like API doesn't mean we have to change the underlying structure. Keeping man data separate from configuration files is IMHO a good thing. As long as the locations are well defined (which they are in UNIX), the common API to which you refer can handle the disparate locations for you and present a common repository model to you.

18 Feb 2002 16:02 m45

Re: Missing : Revision Control
Check RCSVI (freshmeat.net/projects...). Its a simple wrapper around vi that
puts files under revision control. It's very simple and does not answer half of your needs but hey.
The concept is there.

18 Feb 2002 16:58 cssharp

Re: While we're at it...

Of course it doesn't mean the underlying structure has to change. I'm asserting that it should change. It's not exactly mixing man data with configuration files when both only belong to a single application. And I'm not ruling out putting those in further subdirs through a metaconfig if it's relevant for the application.

Just as many global variables start to pollute a C program, I think /etc pollutes the filesystem -- in the sense that every application is a little bit of everywhere in the filesystem. Encapsulation helps clean it up.

Aside from a sense of inertia, what reasons are there to keep /etc going? Easy grepping? With that simple, unified config file interface, it's easy to write either 1) an application that greps it for you, or 2) an application that dumps all configs to stdout for grepping with existing tools.

I believe the benefits of keeping a unique directory tree for each program significantly outweigh any minor benefits of /etc.

18 Feb 2002 17:20 knussn

Re: And what about using "Brain"

> As it is, Linux needs to be made
> easier, even for the
> "experts." I think the author
> of the above article missed the boat,
> bigtime. It's not the *format* of the
> configuration files that a problem.
> Okay, well, it is, but not THE problem.
> THE problem is that configuration files
> (and, well, if you think about it,
> APPLICATION files are strewn all over
> the damned disk seemingly without any
> rhyme or reason.

That's the thing I changed to Debian after 8 weeks of Linux in '97. Everything to configure is in /etc. You can just take a look there to explore the possibilities. Everything is so clean organized, that you can guess where binaries or shared or changing data is placed.

Because of the FHS this should be no problem with other distributions today, too.

And, personally, I like the (half a dozen) Un*x style(s) of configuration (with the exception of sendmail). Good documentation and examples even inside the Files. The biggest problem is to become familar with emacs or vi.

Windows is a mess to configure, IMHO. You know that something must be somewhere. And you click and click through the GUI 'til you drop ("regedit.exe" is another thing, I wouldn't name it a GUI. It's the worst of both worlds - and nothing for newbies, even if you have 17-year-experience on different other systems.). Than you have found something that could be the thing, but you're not sure, what the hell this... MS names things different than anybody else. So type "F1"... "with this button you can change the state between 'on' and 'off'".... I thought so before....

Or you know where it is, but you have to right click here, pull down there, type in otherwhere, lose your old config totally instead of copy-paste-and-#-the-old-one, maybe reboot.

Personally, I prefer C-r \n and being at the old place of a saved session.

But than is MHO.

18 Feb 2002 17:31 tmathews

I like the idea

I've been wanting to do something like this for a while. I've made a few comments above, but this one's my big rant.

This is something thats been needed since the eighties. If it had been done when the GNU project was formed, it would already have been a standard when Linux was first being put together.

There is a lot of archaic mess that Linux inherited from various other Unices, depending on which (if any) version particular developers were familiar with. So now GNU/Linux is a little of everything and not a lot of anything (standards wise).

I think that there are three big steps involved with making this happening.

First, review the specs for directory layout for AT&T Unix. Then review the way the BSD's do it, then compare layouts from the big 4 of Linux (Redhat, Mandrake, Slackware and Debian) and maybe SuSe as well.

Second, now that we have an idea of how different disto's do it, sit down and highlight the strengths and weaknesses of the various layouts. Then we can come up with a layout that will actually work well. This means two things, first the partition that has the config stuff on can be mounted read-only with out worry of messing anything up, and second it means that most user programs and help files can live on the network.

Thirdly, and I think this is the one point that everyone has been debating, develop a standard config file layout. I would strongly recommend not using XML and come up with a better way. There are several reasons for this. The first is that although XML is OK for use with a GUI, its no fun in a text editor. I don't think that an ncurses based UI is good here either. Ever try to use Linuxconf on a text only terminal over a packet radio link? Well written shell scripts can be just as easy, if not easier to read than XML, and its not too difficult to get a program to read them either.

A nice graphical config is good, and I think neccissary as well as an ncurses based one, but I think we still need the ability to easily tweak things from a text editor. With a standard API, a web based config would be a piece of cake. The webmin people would probably help out there.

I would be willing to coordinate a project like this, if anyone wants to help out, please contact me. I forsee the need for at least a half dozen people to start and then a lot more to get the config files set up the way we decide. Obviously, community input is essential so getting a website and mailing list going would be nice.

Being able to move from one version of Linux to another and maybe even on to BSD without having to think about how things are layed out would make a lot people a lot happier as well as make the transition to Linux a whole lot smoother (for windows people anyway). If you start to learn on one distro and then switch to another, you shouldn't have to start all over again. Being able to pick up where you left off would be a huge help.

I don't know if my email is on my profile, so if you want to contact me, its tim@accssden.dhs.NOSPA... (mailto:tim@accssden.dhs.NOSPA...), obviously, take out the ".NOSPAM" part.

--Tim

18 Feb 2002 17:31 lillywhite

Bridging the gap(s)
It seems to me that there are a few steps that are needed to get to a unified configuration file format:

1. Decide on the file format
2. Write bridges to let existing, unmodified applications work with the file format,
3. Convert the existing applications to use a standard API that may also use the new file format.

These steps can be broken down:

1a. Decide on a basic file structure.
1b. Decide on a set of common elements.

I would suggest simply using XML Schema and XML files to represent the configuration. It doesn't mean that XML files need to be used to store the config, just that the config can be serialized to/encoded from standard XML without losing information.

2a. Define a schema for each specific application. If necessary, extend XML Schema to include helper fields.
2b. Write bridging tools to convert between the XML format and the native format used by the target application. In the case of XML, you could just write XSLT transforms. These are much easier to keep up-to-date than straight code.

Part 2 means that we are not locked into a schema immediately -- we can play around with the schemas until we are happy that they provide all the functionality of the original files.

3a. Write a simple mechanism for accessing the configurations. XML gives us XPath and the DOM, which means that writing configuration parsers is straightforward -- we have ways to refer to any given node in a configuration file and we have a low level API for accessing it easily. So really a configuration file parser is simply a wrapper around the DOM.
3b. Write a configuration editor for each tool. With XML this is simple, you just need a tool that can read the XML schema definition -- IBM's Xeena tool (though written in Java) provides context-sensitive pallete for editing an XML document based on the DTD, so doing the same for an XML Schema should be fairly straightforward.

The advantages of this scheme are:

1. All the basic tools already exist as free software.
2. Potentially 100% compatability with old applications
3. Most of the code is XSLT and therefore more easily maintained than a hard-wired parser (I am only arguing that XSLT is easier to follow than C code implementing a parser for the same structure).
4. Permits graphical or text based configuration
5. In conjunction with the kernel file monitor and a simple daemon, modifying the XML source of a configuration file could automatically cause the daemon itself to restart (obviously this would need to be configurable, too).
6. Very easy project to start; there are not thousands of lines of code to write.
7. 100% standards based, most of this stuff developers are already familiar with (or should be).

IMO the approach of linuxconf, Ximian Setup tools and Webmin is all wrong wrong wrong. Unifying the configuration can be done without initially rewriting the applications. Start from the bottom -- unify the configuration first and let the application authors decide when, if ever, to jump on board.

Finally, the file format could permit references to "included" configuration files, the storage of which could be in multiple places including over the network. For example, the standard configuration document (e.g. /etc/xcf/bind.xml) could include configuration from server.example.com/xcf.... This would optionally permit configuration to be based on a single server or alternatively across multiple files.

18 Feb 2002 17:37 jdhildeb

Re: While we're at it...

> Who's benefitting from having config files in /etc, man pages in /usr/man, libraries in /usr/lib, cache and locks and things in /var, and the program binary in /usr/bin?

I am. One way I benefit is by knowing that I don't have to backup my entire system; I can backup the configuration of my entire machine by taking a snapshot of the /etc directory. So it only costs me about 2 MB, instead of 8GB to back up everything I need to reconstruct my system.

> Let's have a bit more than a config read/write library. Let's encapsulate a program and all of its files into a single system subdirectory.
> Installation and uninstallation of a program becomes easy.

It already is easy. If it's not easy for you, try a different distribution (like debian, for example).

> Complete backup and recovery of an application becomes easy.

I already do this. I use dpkg-repack to re-create a package from its constituent files on my system, which means I can take a snapshot of a package and its current configuration.

> A clean separation between programs is better than an arbitrary intermingling.

Why? I find that consistent location of files by function
has advantages (as stated above) over lumping all application files together, especially when your packaging system takes care of installation/deinstallation. How would you propose to separate things like shared libraries "cleanly"?

18 Feb 2002 18:06 cssharp

Re: While we're at it...

> Why? I find that consistent location
> of files by function
> has advantages (as stated above) over
> lumping all application files together,
> especially when your packaging system
> takes care of
> installation/deinstallation. How would
> you propose to separate things like
> shared libraries "cleanly"?

Shared libraries don't create any issues. Cast ldconfig cast into this model. ldconfig lives in its own tree. It discovers shared libraries either by querying the config library or by direct report from the application with the shared library. The shared library is its own application, so all of its relevant man pages and configs are store in this unique-dir model under, as well.

This primary config application itself lives by its own rules, in its own unique subdir. And, if we're fitting this into the "registry" model, then that application is necessarily aware of the location of all applications and their config files (through preferably a discovery/report model like the bizarro-ldconfig, for robustness). From there, it is trivial to write an app that dumps the location of all config files to stdout for feeding into tar for backup.

18 Feb 2002 18:27 jdhildeb

Re: While we're at it...

> This primary config application itself
> lives by its own rules, in its own
> unique subdir. And, if we're fitting
> this into the "registry"
> model, then that application is
> necessarily aware of the location of all
> applications and their config files
> (through preferably a discovery/report
> model like the bizarro-ldconfig, for
> robustness). From there, it is trivial
> to write an app that dumps the location
> of all config files to stdout for
> feeding into tar for backup.
>

Fair enough, but why would I want to implement this when I can do tar -vzf etc.tgz /etc today?

What are the compelling reasons, in your mind, for wanting all application files to live together? What would that allow you to do that can't already be done?

18 Feb 2002 20:34 cssharp

Re: While we're at it...

> What are the compelling reasons, in
> your mind, for wanting all application
> files to live together? What would that
> allow you to do that can't already be
> done?

A reasonable request. In many ways, I want this for the same reasons you like the current method: ease of doing things By Hand. I suppose that's hard to define exactly, but something like "doing something By Hand means being able to exploit a variety existing tools to accomplish a task."

So, installing a package, completely uninstalling a package, relocating a package to a different directory or filesystem, being able to trivially inspect the resources (libs, man pages, binaries) that constitute a package -- these are things I'd like to do easily By Hand.

I can do some of those things with RPM, and perhaps from the sound of it, even more with the tools in Debian. But these tools and others (linuxconf) live more inside the system than on top of it. Which means I'm dependent on those tools to do the job, even when I otherwise wouldn't mind having other, simpler options. Abstacting to a lightweight layer to solve the problems curretly attacked by these heavyweight applications enhances robustness of the underlying structure and allows more versatility and variety in the front-end applications.

Now, I'm all in favor of tools that make things easier. But, I beleve those tools should supplement the system, not take it over. So, if we can exploit basic filesystem structure to accomplish more than these heavy management systems that push other tools out of the way, I think we should do it.

18 Feb 2002 21:57 fprog

Summary
- *MUST BE* XML based
- XML to text converter
- text to XML converter
- XML editing is a joke if you use XML editors,
or some vi/emacs completion macro

- Registry should look like this:

/etc/registry.xml

<!-- This solves any global registry problems -->
<REGISTRY>
<!--#include file="/usr/local/myapp1/config.xml"-->
<!--#include file="/usr/local/myapp2/config.xml"-->
<!--#include file="/usr/local/myapp3/config.xml"-->
<!--#include file="/usr/local/myapp4/config.xml"-->
<!--#include file="~/user_registry.xml"-->
</REGISTRY>

- We need an easy method for shell script insert/query tool

#!/bin/csh
if ( -e /REGISTRY/app/myapp1/ ) then
setreg /REGISTRY/app/myapp1/key1 value
endif

We need a C API which is very simple to use:

char* value = registry_get( "/REGISTRY/app/myapp1/key1" );

registry_set( "/REGISTRY/app/myapp/key1", "value" );

struct registry_tree_t registry_select( "/REGISTRY/app/myapp/", "/^menu\w+/" );

register_insert( "/REGISTRY/app/myapp/key1" );

register_delete( "/REGISTRY/app/myapp/" );

In Perl, we could do the same, or simply
use a DBD::XML similar, i.e. DBD::AnyData

Other language should have something similar
to C or Perl

Another idea, is to use an SQL command-like
query engine.

If the C interface exist, ports to other language
should be easy.

How do you save the configuration for XYZ app ?

tar cvfz xyz_conf.tgz /usr/local/XYZ/config.xml

Fred

19 Feb 2002 00:03 aiken11

Re: Configuration made simple...

Things like your "type" and "unit" and "description" should not be in the config file. The actual config file itself should look something like this:

<parameter name="TimeToWait">
10
</parameter>

Whereas things like type, unit, descrption, etc. should live in a configuration description file which sets up what valid parameters are and form the basis for UIs.

This keeps the config file itself simple, while maintaining all your data.

19 Feb 2002 02:49 delong

Re: Configuration

> I really don't want to mock around, but
> if Linux ever wants to be popular on
> desktops, it needs grafical "point and
> click" interface/program to modify it's
> configuration.
> Yes, Windows Registry is garbage (not
> stable, not editable in text editor on
> console, etc.) BUT IT WORKS... most of
> the time.
>
> Greets,
>
> Alex

Well, flat text config files work right now too. All of the time.

GUIs are handy and I agree that the average user will need one for widespread desktop acceptance of Linux. But binary is not the way to go. Let's learn from the mistakes of others. Plain text is GOODNESS.

Derek

19 Feb 2002 06:20 paj1234

How about extending /proc?
The Linux kernel puts its configuration variables in the virtual filesystem /proc. I think this is a winning strategy. It fits in with the fundamental Unix design brilliance, 'everything is a file'.

I suggest building on the /proc filesystem. I suggest a virtualised filesystem as a consistent interface to configurations such as user accounts and Apache setup. The virtual filesystem would read and write the normal config files in the /etc directory.

Restoring a backup of /proc/virtual-etc would ideally have the same effect as restoring a backup of /etc. The only difference would be the former would take longer because the 'deep magic' running the /proc/virtual-etc filesystem would have to build the real configuration files in /etc.

The /proc filesystem is brilliant. I can browse the hierarchy of system configuration information using simple shell commands or the browser of my choice. I can see details such as the CPU info using any editor, or using a simple 'cat' command.
I can even turn on and off kernel facilities, such as IP forwarding, using a simple 'cat'.

So, extending the genius and simplicity of /proc, how about something like this?

Example 1: View all the Unix accounts in the system:

shell#> ls /proc/virtual-etc/unixaccts/users
root mail fred joe barney wilma

Example 2: Set the shell of the Unix account 'fred' to '/bin/bash':

shell#> cat "/bin/bash" > /proc/virtual-etc/unixaccts/users/fred/shell

Example 3: Copy a named virtual host in Apache, and set the HTML directory for the new virtual host:

shell#> cd /proc/virtual-etc/apache/vhosts
shell#> cp -R somehost newhost
shell#> cd newhost
shell#> cat "/var/www/newhost" > DocumentRoot

19 Feb 2002 07:12 paj1234

I want a standard
I want a standard which other programs can use to:

1) find out what options my program has
2) set those options.

I do wish there was such a standard. I have noticed that other programs which depend on mine tend to say "Have you enabled X in createusers.conf?", "Have you enabled Y in createusers.conf?", etc.

If there was such a standard then those other programs would be able to check and enable it themselves. Those programs could query my program to see what options have been set, and perhaps change them as necessary.

Such a standard might allow my program's options to be automatically in a magical '/proc/virtual-etc' preferences virtual filesystem - without the need for any additional programming. (This virtual filesystem is described in my post below).

I don't know what form such a standard might take, but if it delivers this dream, I will be quick to adopt it in my program.

19 Feb 2002 08:02 prefect

Re: And what about using "Brain"

> Please, don't use the word
> "revert". exim and qmail are
> just plain better than sendmail.
> There's no reason to use sendmail.

Yep, that's a fair point. I didn't mean it as a
downgrade, more of a "everytime I do a distro
install they plonk sendmail | postfix on the disk,
and I always switch back to qmail | exim."

jh

19 Feb 2002 08:04 prefect

Re: And what about using "Brain"

> I agree, the sendmail config file is a
> crazy mess. I am not trying to promote
> qmail, but I really like how the configs
> are set up.

I tend towards exim for trivial sites, as the
config file is fairly clean (some nastiness with
the routing rules but not bad), and the exim
configuration program is just plain lazy. A few
easy questions and it'll work for a reasonable config.

jh

19 Feb 2002 13:14 bhu73

Re: And what about using "Brain"

>
> % Not to mention that there *are*
> % newbies to the system that don't
> want to
> % learn at all. They just want to get
> the
> % task done without spending a week
> % learning how to setup a webserver.
>
>
> Why are we worried about newbies who
> don't want to learn at all. Making
> things easier is one thing but totally
> revamping everything that people have
> worked on in order to support people who
> aren't willing to learn.
>
> If you can't read the documentation
> and manage the softwares configuration
> files, then maybe you shouldn't be
> running the software.
>
> I personally think that some packages
> such as apache, samba and many others
> have quite understandable config files.
> Although they are completely different,
> understanding the configuration is part
> of the learning process. I say tough
> shit, if you aren't willing to learn.

Because, my dear, we don't all work with one or two
servers, some of us work with hundreds, of more
than one variety, and tools to simplifly and unify
configuration changes across these platforms are
well worth investigation. We know how to configure
applications, it is not rocket science; managing
multiple configurations safely, consistently and
quickly can be.....

19 Feb 2002 15:47 samboy

Re: And what about using "Brain"

> Why do you need single configuration
> interface to
> all things that can be configured? Are
> you too lazy
> to learn how to configure each single
> one by one?
> Are you too lame?

OK, lets stop right there. Most people want to use computer to get things done, not waste their time dealing with archaic configurations.

For example, I recently was in a foreign country and wanted to print out some essay I had written for class there with my Linux laptop. Thus, my nightmare began.

Keep in mind this: I have been using Linux when you thought Windows 95 was the cool new OS for all of your gaming needs (or when you thought the SNES still had cool games; my Linux usage predates the introduction of the Nintendo 64)

To make a long story short, it took me about two hours of learning obscure arguments to the ghostscript program and how newer kernels handle devices on the paralell ports (it has changes since the 2.0.x and 1.2.x days) to get Linux to talk to that printer.

The same operation, in Windows, takes about five minutes.

I like to learn things as much as the other person, but when it takes two hours to do something in Linux which can be done in Windows in five minutes, it is time for Linux to imporve its interface.

- Sam

19 Feb 2002 16:32 cinnix

Re: And what about using "Brain"

>
> %
> % % Not to mention that there *are*
> % % newbies to the system that don't
> % want to
> % % learn at all. They just want to
> get
> % the
> % % task done without spending a
> week
> % % learning how to setup a
> webserver.
> %
> %
> % Why are we worried about newbies
> who
> % don't want to learn at all. Making
> % things easier is one thing but
> totally
> % revamping everything that people
> have
> % worked on in order to support people
> who
> % aren't willing to learn.
> %
> % If you can't read the
> documentation
> % and manage the softwares
> configuration
> % files, then maybe you shouldn't be
> % running the software.
> %
> % I personally think that some
> packages
> % such as apache, samba and many
> others
> % have quite understandable config
> files.
> % Although they are completely
> different,
> % understanding the configuration is
> part
> % of the learning process. I say
> tough
> % shit, if you aren't willing to
> learn.
>
>
> Because, my dear, we don't all work
> with one or two
> servers, some of us work with
> hundreds, of more
> than one variety, and tools to
> simplifly and unify
> configuration changes across these
> platforms are
> well worth investigation. We know how
> to configure
> applications, it is not rocket
> science; managing
> multiple configurations safely,
> consistently and
> quickly can be.....
>

It seems that you managing 100 servers is a bit mis-represented.

Are you running something completely different on each server?

If someone was to have 100 servers then they wouldn't be managing each of these seperately, they would have them working together so that 100 configurations were not necessary. And in this case configurations would be managed from a central location rather than at each individual server.

What you are referring to is an implentation problem, not a configuration problem. It doesn't matter what method you are using individually configure 100 servers, you are turning a bottle-rocket into rocket-science.

I might be wrong on how I interpretted your statement but it seems to me that someone in the situation that you mentioned needs to examine the architecture of their network layout rather than find a configuration tool to manage it.

19 Feb 2002 22:39 zubin

avoid a global registry for local apps
One of the biggest problems with having a single global registry like in Windows is that if you do a clean re-install of the OS, or a from-scratch install of an upgrade, you lose everything, including applications you may have downloaded and installed separately.

One of the nice things in Unix is that you can have /usr/local on a separate partition/filesystem, and that way when you do a clean re-install of the OS, you can avoid formatting /usr/local, and so continue using all your existing applications in that directory. This is possible because the configuration information for the applications was stored on the same filesystem as the application itself. If some important configuration information were to be stored in a "global" place (e.g., in /etc), then this advantage would be lost.

20 Feb 2002 01:48 jhhudso

Re: How about extending /proc?
I really like this idea. In my mind this would allow applications to still keep their configuration files where/and how they want while ALSO creating a centralized place for all configuration information. I would propose that the best way to do this would be a linux kernel virtual filesystem in conjunction with a daemon that has multiple modules for different applications and their configuration file formats. That way people (or application programmers) can provide a configfs module for their application, if they don't someone who understands how to configure the application can write their own and have configfs dlopen() the module for that application.

> The Linux kernel puts its configuration
> variables in the virtual filesystem
> /proc. I think this is a winning
> strategy. It fits in with the
> fundamental Unix design brilliance,
> 'everything is a file'.
>
> I suggest building on the /proc
> filesystem. I suggest a virtualised
> filesystem as a consistent interface to
> configurations such as user accounts and
> Apache setup. The virtual filesystem
> would read and write the normal config
> files in the /etc directory.
>
> Restoring a backup of
> /proc/virtual-etc would ideally have the
> same effect as restoring a backup of
> /etc. The only difference would be the
> former would take longer because the
> 'deep magic' running the
> /proc/virtual-etc filesystem would have
> to build the real configuration files in
> /etc.
>
> The /proc filesystem is brilliant. I
> can browse the hierarchy of system
> configuration information using simple
> shell commands or the browser of my
> choice. I can see details such as the
> CPU info using any editor, or using a
> simple 'cat' command.
> I can even turn on and off kernel
> facilities, such as IP forwarding, using
> a simple 'cat'.
>
> So, extending the genius and
> simplicity of /proc, how about something
> like this?
>
> Example 1: View all the Unix accounts
> in the system:
>
> shell#> ls
> /proc/virtual-etc/unixaccts/users
> root mail fred joe
> barney wilma
>
> Example 2: Set the shell of the Unix
> account 'fred' to '/bin/bash':
>
> shell#> cat "/bin/bash"
> >
> /proc/virtual-etc/unixaccts/users/fred/shell
>
> Example 3: Copy a named virtual host
> in Apache, and set the HTML directory
> for the new virtual host:
>
> shell#> cd
> /proc/virtual-etc/apache/vhosts
> shell#> cp -R somehost newhost
> shell#> cd newhost
> shell#> cat
> "/var/www/newhost" >
> DocumentRoot
>

20 Feb 2002 04:13 job

Be practical

It's not very clear what you want. Any GUI-related options under X11 are set in the (centralized, which "won't fly"?) X Resource DB.
Do you wish to have each app's configuration separated, or each type of configuration separate (as in xrdb)?

Being able to set default configuration for lots of apps is a good thing (IMHO). The problem as I see it today are machine-generated configs which are not human readable. (One more XML-config and I'll puke! It only requires this-n-that many libs to parse...)

So please start a GNU project for cross platform, human readable configuration files which supports site defaults, system defaults, getopt overrides and inter-app defaults (such as colors, mailbox location, printer types etc.), and I'll use it any day!

(As you understand, I believe this is a large undertaking so you'll need the weight of GNU and KDE behind you...)

20 Feb 2002 05:38 alienlifeform

Re: real solutions
Greetings.

[...]
>
> I have to agree.

I beg to disagree. :-)

%People think that
> because XML doesn't have binary byte
> codes, it must be easy to edit.

I do not think anything of that kind. As a matter of fact I do not think anyone - that does not feel so inclined - should be hand editing XML conf files.

If ASCII is your cup of tea, the config system should provide a way to compile *and* decompile from XML to ASCII (or better, UTF-8, another good reason for looking at XML - 7 bit days are numbered, guys). And tools that make easy to avoid syntax errors should be provided, too; other pointed out that tools for easy XML editing are also available (after all, very few use HEX editors on text files).

Tripwire does this already. Sendmail (horrors!) does this already - I configure it by running m4 mysite.mc > mysite.cf and never EVER touch the cf itself - that one should do so is a common misconception, but a misconception all the same.

> [...] like how BIND
> does it for named.conf, as an example).

Funny that you should bring BIND up... I have forgotten how many times I stuffed named.conf by forgetting a strategical ';' or how many times I had to lookup the format for a list in that lovely BNF-oriented documentation... Better then named.boot, no quarrel here - named.boot was horrible anyway -and an improvement over UUCP and INN, but I see plenty of room from improvement.

> XML is also adding ambiguity when you
> look at how different people are using
> it, where some 'data' is in
> the document part (between tags) and in
> the 'meta' part (inside the
> tags).

XML has nothing to do with this. DTD and schemas have all to do with this (and they are of course part of the desing of any XML project). BizTalk (just an example) puts zilch in what you call 'Document part'. As a matter of fact, I doubt that BizTalk has nary a CDATA tag (but I might be wrong). SOAP is also very clear about this kind of stuff.

> XML was based on syntax intended
> as markup for documents (e.g. text and
> other renderable objects).

This is simply untrue. It would be less than true even if you replaced "XML" with "SGML" or - egads! - "HTML" (which used to beconcerned above all with document structure - Remember the good ole Mosaic days? - that was before <BLINK>, of course.)

XML was designed from inception with data (also) in mind - and the fact that this kind of comments are still possible just goes to show that this fact has not been made clear enough.

> It makes a
> lousy data language, by taking the worst
> of things.

In fact XML has done something that is much more powerful than telling people where to put angulars.
It has showed, in a very compelling way, that "the parser is the document" - which is exactly the reason why its use should be promoted.

And because of this - back to the main subject of conversation - physical XML need not even exist, where serialization is not an issue. All plugins writer must provide is a SAX event stream - AKA a SAX parser.

Cheers,
alf

20 Feb 2002 06:30 paj1234

Re: How about extending /proc?
I could make a little proof-of-concept application. It would be a simple program. It would make a RAM disk and mount it someplace. Then it would go through /etc/passwd (for example) and create a file structure like this:

virtual-etc/

virtual-etc/unix-accts/

virtual-etc/unix-accts/users/fred/

virtual-etc/unix-accts/users/fred/primary-group

virtual-etc/unix-accts/users/fred/realname

virtual-etc/unix-accts/users/fred/secondary-group

virtual-etc/unix-accts/users/fred/shell

virtual-etc/unix-accts/users/fred/uid

I could then watch /etc/passwd for changes and arrange for the RAM disk tree to be rebuilt when necessary. Secondly, any changes to the RAM disk files, maybe including comments, could be parsed and written back into /etc/passwd. I could set UNIX permissions on the files and directories in the RAM disk to control which users can read or write what.

The tree could be extended to cover /etc/shadow and /etc/group, if needed. Should I give this a go?

I hope a tiny partial implementation would be useful. For example, it might allow an application author to easily pick up selected Unix account info about Joe Random User without having to worry about the format or location of the /etc/passwd file.

20 Feb 2002 06:47 paj1234

Re: avoid a global registry for local apps
That advantage has a high price, namely, extra work to do a full system-configuration backup and the possibility of missing something. In this discussion there are people saying they switched to Debian because it puts things nice and organised in /etc.

You can put /etc on a separate partition if you don't want to format that, I guess.

20 Feb 2002 10:37 mihajlov

How about WBEM?
Sorry for the long posting, but it's really a matter of heart to me...
The problem with configuring (not only) applications has multiple dimensions. One of them - as already pointed out in different posts - is access technology. A single, consistent method is necessary to read and update all the configuration data. I chose the term "access technology" deliberately because we cannot not really expect all the legacy /etc files like inittab and passwd to go away or change their format (be it XML or something entirely different). We also cannot faithfully expect that formats converge, meaning one is given up in favor of the other. This means that the access technology must facilitate a wrappering approach to the current configuration repositories. It also has to be suited for scripting, fancy GUIs of course and allow remote access, especially important if we think of bigger installations.
Coming up with such a technology is conceivable, it will buy us only part of the solution however. The problem is that even if all config data was accessible in a single way, we are still missing semantical information (ever tried to configure a printer via, say the Windows registry?). What this really means is that a data model is needed in addition, describing the semantics of configuration data (and other parts of the system). The data model must provide different levels of detail, giving the possibility to perform high-level, generic configuration tasks as well as highly application-specific modifications.
Let's take web browsers as an example: all of them allow the specification of proxy servers, each in it's unique way. Now assume a situation were a company-wide proxy server changes and hundreds of clients have to be reconfigured to reflect the change. In this case it's really convenient perform a remote "set proxy for client xyz" configuration command, without even knowing the exact nature of the client's browser.
Access and data modeling technologies for systems management purposes exist today already, in form of DMTF's WBEM and CIM standards. Parts of the data models therein deal with configurations and settings (of devices and applications) which I believe to be a sound base for further developments. Now what does this mean? For the purpose of application configuration, appropriate data models have to defined by extending the respective CIM models. Then it is necessary to write data access modules interfacing to the real resources, the so called providers. And what's perhaps most important, management applications exploiting the stuff.
Several Open Source projects related WBEM technology are cooperating under the umbrella of the WBEMsource initiative. If you want to learn more about, www.opengroup.org/wbem... would be a good starting point, as well as the DMTF website www.dmtf.org . To summarize and emphasize my statement: the infrastructure technology is there, the hard work still has to be done. It will take quite some time, but if successful it will lead a way out of all the configuration quirks and nightmares, and this not only for Linux but for all platforms supporting WBEM.

Regards, Viktor

20 Feb 2002 14:02 smoku

Re: And what about using "Brain"

> I agree, the sendmail config file is a
> crazy mess. I am not trying to promote
> qmail, but I really like how the configs
> are set up.
>
> It uses several config files where
> each serves one pupose only. There is no
> syntax to learn. You just put the name
> of your virtual domain in the
> vitualdomains file.
>
> echo "mail.new.domain"
> >>
> /var/qmail/control/virtualdomain
>
> Sure seems easy to me.

Isn't it just like the virtual-etc filesystem suggested above? :-)

21 Feb 2002 00:43 egreB

Re: How about extending /proc?

> I could make a little proof-of-concept
> application. It would be a simple
> program. It would make a RAM disk and
> mount it someplace. Then it would go
> through /etc/passwd (for example) and
> create a file structure like this:

If you could have done that, it would have been excellent. I love the idea of your comment's parent, and really think it's the way to go. A proof-of-concept application (or kernel module, I imagine) would, among other things, be cool to play with (-8 This is just what Linux/Unix needs to get the little push over the edge to world domination.. (-;

21 Feb 2002 03:09 fprog

Re: How about extending /proc?

I think polluting /proc with a registry is bad,
maybe /reg or /registry

Still, this doesn't solve the problem completely
they are just files or pseudo-files.

Are you telling that values should be store like this?

/registry/Software/Company/VIM/params/options=hex:48,00,04,00,00,00,27,0c

Parsed by:

$entry =~ m/(\S+)=hex\s*:\s*([0-9A-Fa-f]+,?\s*)+/;

$key = $1;

$val = $2;

to mean this:

/registry/Software/Company/VIM/params/

options = $48,00,04,00,00,00,27,0c

Another way would be like Windows INI files
or Windows REG files like this:

REGEDIT4 example

[HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\{28FD0F82-4A73-4453-84A6-2F4F62702A3F}]

@="Windows Setup - XYZ"

"ComponentID"="PROGDL"

"IsInstalled"=hex:01,00,00,00

"Locale"="EN"

"Version"="5,4,1103,3"

I have only one problem with /reg or /proc
what about NON-ROOT users ?

This is why I loved the SHTML/XML include:

<!--#include file="~/user_registry.xml"-->

Let say I want to install VIM on /home/fred/

because the sysadmin loves EMACS
and hates VI, let say.

Will this means
that the sysadmin can prohibit installation
of software on /tmp or /home ?

Sincerely,

Fred.

21 Feb 2002 04:20 iburger

Re: I want a standard
All I can say is: Yech. Keep application dependent stuff like this out of the kernel please. Also, Please, NO CENTRAL REPOSITORY! Then we have a single point of failure exactly like the windows registry.

Rather use something like gtk-config. Then your application can simply call otherapp-config --show or something like that to figure things out.

> I want a standard which other programs
> can use to:
>
> 1) find out what options my program
> has
> 2) set those options.
>
> I do wish there was such a standard. I
> have noticed that other programs which
> depend on mine tend to say "Have
> you enabled X in
> createusers.conf?", "Have you
> enabled Y in createusers.conf?",
> etc.
>
> If there was such a standard then
> those other programs would be able to
> check and enable it themselves. Those
> programs could query my program to see
> what options have been set, and perhaps
> change them as necessary.
>
> Such a standard might allow my
> program's options to be automatically in
> a magical '/proc/virtual-etc'
> preferences virtual filesystem - without
> the need for any additional programming.
> (This virtual filesystem is described in
> my post below).
>
> I don't know what form such a standard
> might take, but if it delivers this
> dream, I will be quick to adopt it in my
> program.

21 Feb 2002 07:22 paj1234

Re: How about extending /proc?
You wouldn't have to mount the 'virtual-etc' RAM disk directory structure in /proc. You could mount it anywhere you like.

The idea isn't a registry. It's just an alternative view of normal configuration files. Besides, I would prefer to keep the 'R' word far away. The 'R' word has way too many negative associations IMHO. :-)

For per-user prefs, I could maybe try mounting a small RAM disk somewhere in each user's home directory. For vi preferences, it might be possible to create a file structure like this:

/home/joe/.virtual-dot/vi/

/home/joe/.virtual-dot/vi/line-numbering

/home/joe/.virtual-dot/vi/shift-width

/home/joe/.virtual-dot/vi/wrap-margin

These files would dynamically represent various entries in the user's "~/.exrc" vi preferences file. If "~/.exrc" gets updated, the tree in the RAM disk would be updated automatically.

For example, you could see what has been set in "~/.exrc" using these commands:

shell> cd /home/joe/.virtual-dot/vi

shell> more *

*********

line-numbering

*********

# Controls whether line numbers are shown

0

*********

shift-width

*********

# Number of characters to use when indenting or outdenting

3

*********

wrap-margin

*********

# Place carriage return at the end of each line, starting this many characters from the right edge. If -1, no wrap margin is used, ie, a carriage return is inserted only when you type one.

-1

This says don't line number, use a shiftwidth of 3 characters, don't insert carriage returns automatically.

Line numbering could be turned on using this command:

shell> cat "1" > /home/joe/.virtual-dot/vi/line-numbering

This would update the "~/.exrc" file automatically.
Should I give this a try?

21 Feb 2002 19:03 cinnix

Re: avoid a global registry for local apps

> That advantage has a high price, namely,
> extra work to do a full
> system-configuration backup and the
> possibility of missing something. In
> this discussion there are people saying
> they switched to Debian because it puts
> things nice and organised in /etc.
>
> You can put /etc on a separate
> partition if you don't want to format
> that, I guess.

I have always thought putting /etc on a seperate partition would be handy but if I am not mistaken /etc cannot be on it's own partition. I think the same goes for /lib and /dev. Please correct if I am wrong.

I personally hate having a programs config file in /usr/local.

It has always been my opinion that config files go in /etc, logs go in /var/log and binaries go in a reasonable location. I try to adhere to the FHS in placing binaries but that doesn't always work out.

I understand your point about how nice it is to have config files right next to the binaries but I like to have everything in /etc to make it easier to find stuff. I think it is nice to go into /etc and be able to configure everything. The /etc directory is usually pretty small so it is trivial to backup. (I just did a tar -cvzf on my etc directory and I ended up with a 595K tarball.)

For me a reinstall ends up doubling as an upgrade and I run into trouble using old binaries with new libs, so what I do is do a full upgrade and get everything installed and then I piece the backed up config files back into place. Config files are almost always portable between upgrades or will only need tweaked a little bit.

I usually change certain packages around so that things end up in the right place. Programs that come to mind are apache and qmail, which like to put all of their file under one subdirectory.

This way instead of trying to remember where you installed something, you only need to think about the type of file. (If it is a config file then it is in /etc, dynamic information would be in /var, etc, etc, etc.)

Another easy way of soing things is putting /usr/src/ or /usr/local/src on a seperate partition and keeping ALL of your source on it. so after the reinstall all you have to do is a make install and things are ready to go. I keep a copy of /etc on this partition too. This helped me do a complete reinstall and have all available services back up in about 2.5 hours on my home server/workstation.

21 Feb 2002 23:09 fprog

Re: How about extending /proc?
Okay, so it's even easier than I tough
the parameter are stored within the file
of that name, where the line doesn't start with

# SOME COMMENTS

like shells for instance

Therefore, everything is done via cat... =)

cat "whatever" > /reg/key

cat /reg/key | grep ...

> shell> cat "1" >
> /home/joe/.virtual-dot/vi/line-numbering

You should give it a try, looks simple enough
for anyone I think.

Still, there should be a commity for structuring

that tree, inspiring by MicroSoft registry

success and errors would be useful !

Another good point is that instead of having

crappy {12341-1243213-12432} links

we could use ln -s !

Give it a try man!
Cuz your da man!

Fred.

22 Feb 2002 04:53 lolive

Daemon.
I realmly like the webmin system.
I wonder if a kind of system could be done that would be:
a daemon listens on a specific port (a port for configuration) on localhost.
An abstract layer handles a /etc/whateverfile.conf to "standard XML" translation (both sides).
The daemon handles the serving of thoses standard representation of configuration datas. And clients are available to format that XML into GUI, and command the daemon to write the modification into the corect file.

The idea is to separate tasks as in a client/server system.

22 Feb 2002 06:30 maffew

unixconfig.sourceforge.net and mailing list now open
some of the comments are very interesting. i really appreciate all the ideas flying around here.

we've created an ongoing web site and mailing list for people to continue discussing, organising, and hopefully in the end coding. it's at unixconfig.sourceforge.net (unixconfig.sourceforge...).

meanwhile here's another link to the permanent home for this article (www.cat.org.au/maffew/...). this is where i'm making revisions and adding links.

22 Feb 2002 07:26 paj1234

Re: How about extending /proc?
I made a ramdisk mounted on /vetc, plus a Perl script to read /etc/passwd and /etc/group and run the appropriate 'mkdir' and 'echo' commands. Then I made a few test users and put them in the 'users' group. The result was encouraging, even though I am not much of a Perl hacker:

shell> cd /vetc/unixaccts/users/phil

shell> ls

gid uid homedir realname shell

shell> more *

***gid ***

100

***uid ***

500

***homedir ***

/home/phil

***realname ***

Phil Jones

*** shell ***

/bin/bash

shell> cd /vetc/unixaccts/groups/users

shell> ls

gid members

shell> more *

*** gid ***

100

*** members ***

phil

user1

user2

user3

Maybe I should add parsing of /etc/shadow? If I did then it would be possible to do this:

shell> ls /vetc/unixaccts/users/phil

gid uid homedir realname shell min max warn
inactive expire

It took a few seconds to build the /vetc RAM disk directories and files but it did appear to be possibly useful despite being so limited. I was able to browse the results using mc.

Should I post the code here, or mail it to someone?

22 Feb 2002 14:48 blueeagle

It's a good idea... BUT
I believe that any piece of software that requires configuration should have a configuration feature buildt in. This is fine for any new software you find, but what puts many new *nix users off is the fact that they don't really know where to start.

Even the most trivial thing as running fortune on login had me put off in the beginning. (i looked for something that looked like autoexec.bat... but don't tell anyone). I found out how after spending n hour reading x^n lines of howtos and docs. After a while I couldn't remember what I was looking for...

This is where imho someone like the distor vendors ought to come into play. Or something as easy as an index to what config files does what.

Here info has started a good thing when it comes to indexin and making an overview of man pages.

As to the format of config files... Comments in the beginning ought to explain them... Well config files shouldn't have to be tampered with by hand at all!

I hope this makes any sense... Forgive me if I'm rambeling but it has been a long day:)

22 Feb 2002 16:21 jeff280679

Re: Configuration made simple...

>
> % /etc/conf/*.xml
>
> Yeah, this is it. Now let's talk about
> the schema. It should be something like
>
> this:
> <parameter>
>
>
> <name>TimeToWait</name>
>
> <type>smallint</type>
> <value>10</value>
> <unit>minutes</unit>
> <description>Time in
> minutues 'till screensaver starts
> working</description>
> <comment> JSmith 2002-01-01:
> changed to 10</comment>
> <comment>Tom: 2002-02-05:
> prefer to use 15</comment>
>
> </parameter>

What needs to happen it that the configuration definition and the actual configuration are separate. The actual value for the configuration can be stored in the applications default format.

What is required is 3 things:

1) A standard API for accessing configuration information. This means that any configuration editor can be written in any language and not have to worry about the underlying format. This may be already available.
2) Parsers to give access to existing configuration files through the standard API.

3) Some schema to define the possible configuration for any application and an API to this schema. This would include your type and description as well as more complex things like occurance of an option (once, twice, zero_or_more...) and validity checks.

Using the three above, configurators, be they GUI, curses or text based, will be able to read, parse, validate and write config files for as many applications as people write plugins for.

Open to suggestions...

Jeff

25 Feb 2002 17:44 egreB

Re: How about extending /proc?

> Should I post the code here, or mail
> it to someone?

If you could mail it to egrebNO@SPAMtrivini.com (remove the obvious), I would be greatful. It looks quite interesting to hack furher on, if my Perl-skills can do any good (wich they probarbly can't, since I'm still learing Perl). Keep up the good work! (-8

27 Feb 2002 12:23 jstalker

Re: avoid a global registry for local apps

> I have always thought putting /etc on
> a seperate partition would be handy but
> if I am not mistaken /etc cannot be on
> it's own partition. I think the same
> goes for /lib and /dev. Please correct
> if I am wrong.

You are correct. The reason is very simple. If
/etc is in a separate partition it will never get
mounted, because you don't have an /etc/fstab to
tell mount where it is. There are some hacks you
could use to get around this, but all of the ones I
can think of are pretty unpleasant.

07 Mar 2002 14:19 braden

Re: Spaces, the filename frontier...

>
> %
> % Or to better yet improve the
> % configuration system, we could
> have:
> %
> % /System Preferences/*.xml
> %
> % It's about time we migrate folder
> % names to Plain Damn English. If
> someone
> % has a real religious problem with
> this, [...]
>
>
> A big problem with that is that many
> existing shell scripts assume that there
> are no spaces in file names. The shell
> splits lines into tokens on whitespace.
> Spaces in filenames thus cause trouble
> unless the scripts are carefully
> written. (insert perl banner ad here).
> Zsh and Bash both support array
> variables, and filenames can be gotten
> via "find -print0"...
>
>
>
> It would take a certain amount of
> effort to audit all scripts for this
> weakness. It would also require the
> addition of a clause in the distribution
> policy document, and once that's done,
> all new scripts would require audits for
> "sif" (space if filename) bugs.
>

A bigger problem is internationalization. If it's worth doing in English, it's worth doing in other languages. Then you have a situation where software that wants to deploy itself can't be sure what the directory names are without consulting some directory. Windows does this. It is needlessly complicated.

The filesystem hierarchy should be kept succinct and standard. Clarity to the Average User--where it's appropriate--should be taken care of by an abstraction layer.

13 Mar 2002 10:04 djarshi

Configuration Idea
Sorry for the inconsistent message but i have some points.

i hear the following:
Whats a better editor than 'vi'?
I want point and click
I want want to easily change settings on command line
How can we use point and click without X ?
Text registry vs. binary registry

Well i think to start is most programs have user/system settings.
- local for every user
- system is for every user.

Well thats great but for administrators it is a lot of work to get all things in working order. reading alot of documentation before the options can be set. what if you create a a new language tool that can read/write configuration files. The idea was already given in the beginning of this reply storm. You could make properties for
lists,stringlists,booleans,words,integers.
And with that comment should also be in the files and the X-editor or Web-editor should have no trouble reading the input/output with its parser (or OpenSourced librabry that does that for him/her/it) If the language is correctly designed even the comment can be written back into the files so the real vi-guru can edit the configuration files without have to fool around with damn editors. You can go this way into multiple directions with one language.

To give an impression of what i mean i will put a sample language with some settings in it. its ways from complete but maybe its useful.

myServer {
set port word = 3000 /* the port our server listens to */;
unset allowmultiple bool = false
/* allow multiple connections from the same i.p. */;
set banned stringlist {
"*.dino.saurs.net",
"192.168.1.42",
"200.199.188.0/24"
} /* sites that dont get access to our server */;
}

the idea is:
every property starts with unset|set and ends with ';'
property ::= set name typeandvalue comment ';'
comment ::= /* bla blah */
comment ::=
name ::= a-z[A-Z0-9]
typeandvalue ::= word
typeandvalue ::= othertypes
word ::= [0-9]

but anyhow this way with the property you can provide a comment and even a set/unset parameter because in most programs not every setting has to be set specifically some programs have defaults for some variables. You can even extend the language with an 'optional' keyword.

Well bla i quit. I hope i was useful :)
Later

13 Mar 2002 10:10 djarshi

Re: Configuration Idea
myServer {
set port word = 3000 /* the port our server listens to */;
unset allowmultiple bool = false /* allow multiple connections from the same i.p. */;
set banned stringlist {
"*.dino.saurs.net","192.168.1.42", "200.199.188.0/24" } /* sites that dont get access to our server */; }
The idea is: every property starts with unset|set and ends with ';'
property ::= set name typeandvalue comment ';'
comment ::= /* bla blah */
comment ::= empty
name ::= a-z[A-Z0-9]
typeandvalue ::= word
typeandvalue ::= othertype
word ::= [0-9]

// sorry indentation and stuff didn't work and also sorry for the grammar mistakes and all that stuff. Im a foreigner (dutch)

15 Mar 2002 02:16 wbsoft

Re: vi rulzZz..

> You could have vi display the hints
> for the configuration option in another
> buffer (like the way the help works).

Then why not just commented config files. I find that very intuïtive. Explanation can just be added in the file as comments. You can enter different config options, and easily uncomment the desired one. You can write comments yourself, to remember why such-and-such config change was done.

19 Mar 2002 16:19 kodera

why there is a problem?
Well i have read most of the comments posted about the unix configuration nightmare along with many comparisons with the windows system. i guess the problem is devided in 3 parts.

1) system level configuration ( fstab , inittab, termcap ,..................);
2) system level service configuration ( bandwidth management ,firewalling , printing, ......)
3) programs configuration

1) for system configuration files i guess all we need just write a standard api interface such as

addIdeDrive( .............)
setAutoMount(...........)

things like that and every distro must have this api set . Normal program such as adduser, passwd and such basic programs should also use this api's. Also there must be a certain file permission that allows only kernel level process to modify these files in order for them not to be modified by hand. I guess this would not take too much time because basic system configuration files are not that numerous.

2) as for the system level services configuration problem. i was and still am writting a program for intefaacing the tc command line. the documents about tc are pieces of shit. some of them tells you what is completly the opposite of the others. so develeper of such services ( specially new ones ) should create more friendly interfaces along with a programming api interface too. so that things can be easily interfaced later

3)as for the programs configuration problem .it lies in the open source projects. Almost all developers of the open source projects do not give much attention to the configuration of their programs. Take blackbox as an example it is a wonderfull window manager configuration is a nightmare. another one is window maker too much configuration before you can really run it, now kde just runs as soon as you start it. so who is the most popular kde. that is why windows is popular not because the system is popular but because application are much easier to configure if my configuration is hard my software would not sell. But for linux we use a lot programs only because there is nothing else to
use to acconplish a specific task. So the main idea is when a software developer creates a new program he should make a configuration program along with it. i guess that will solve many of our problems.

In the end, I want to say computer is about programs. Programs should do the stuff .If i have a program to configure things i don't really have to care how the configuration is written, where it is written or whether it is centralised or distributed. actually if i did not know that windows has a registry I would have never guessed. I never needed direct access to it as a user.

21 Mar 2002 03:04 cinnix

Re: why there is a problem?

3)as for the programs configuration
> problem .it lies in the open source
> projects. Almost all developers of the
> open source projects do not give much
> attention to the configuration of their
> programs. Take blackbox as an example it
> is a wonderfull window manager
> configuration is a nightmare. another
> one is window maker too much
> configuration before you can really run
> it, now kde just runs as soon as you
> start it. so who is the most popular
> kde.

What is so hard about configuring blackbox?
You shouldn't need a great big GUI in order to figure out how to configure something like this. Most people out there can look at the below line and figure out what it would mean.

[exec] (Galeon) {/usr/bin/galeon}

This is my biggest gripe against a lot of the current Linux development. GUI developement has been psychotic lately. I keep seeing bigger and bigger GUI's that are only serving the purpose of making easy things harder.

I have used KDE before and it was was real pretty and a huge fucking waste of space. In order to change the menu you have to root through a huge list of menu items that link to things you will never use just to edit the menu. KDE does not turn on as soon as you start it, you have to wait for it to boot because it is large enough and complicated enough to be it's own operating system.

I am can think of another thing in KDE that follows this same patterm too. Kpackage - gimme a break. If this application could run long enough without crashing, then I might be able to run a really overdone program just to install a simple rpm. c'mon, what is so hard about opening up your trusty xterm and typing 'rpm -i <packagename>'.

Developers created a useless program to keep someone from having to type in 5 characters and the name of the package.

I am guessing that KDE is the most popular for the same reason windows is so popular. People don't know any better.

25 Mar 2002 23:20 sharkey3

COAS
This sounds a lot like the COAS project started at Caldera. <www.coas.org> Like all things Caldera, it failed for lack of effort, but perhaps someone could pick up the pieces and make it work.

13 Jun 2002 01:22 guodman

Re: why there is a problem?
RPM files are a much bigger problem than config files, and the advantage of the good package managers (like rpmdrake) is that they try to automatically install or remove packages to satisfy dependencies (they do fail often). The idea of going to a command line and opening a file scares many people. If there is a nice gui, the users can make modifications and be sure that they will not mess up the program by typing something wrong. before you start talking about how easy it is (and I would agree that it can be easier) remember that when you go to the general public, many people don't want to spend any time learning about their computer. With a gui, all of the available options can be listed for the user to pick from, and the user doesn't need to search for the file to configure.

28 Jun 2002 02:01 linuxknight

Re: And what about using "Brain"

> installed under Program
> Files. The Linux community, and
> especially distro packagers would do
> well to take note.

Do you know ANYTHING about linux?
The programs are installed in one of 3 places:
/bin, /usr/bin, and /usr/local/bin.

Some programs install their files in /usr/<programname>.
For example, Mozilla installs in /usr/mozilla by default.
Is THAT hard to figure out? I personally think
that anyone who's so STUPID that they want to
use the STUPID Micro$oft Window$ operating system
just because it's EASY to use shouldn't be using a
computer at all!

Fools who just want to learn to "click the
mouse" and "use the easy control panel" have no place
using a computer. Go back to your typewriter!

(No offence to computer experts who use windows, this is
targeted at the idiots who want to use a computer the
Simple M$ way.)

26 Jan 2003 09:02 kjkhyperion

Re: avoid a global registry for local apps

> One of the biggest problems with having
> a single global registry like in Windows

no, it isn't a single, global registry. It's split up into many system-wide parts - namely, SOFTWARE, SYSTEM, SAM, and SECURITY - and a per-user part. Notably, the per-user part is stored in a file located in the user's profile directory. Not to lose your installed programs, you backup SOFTWARE. Not to lose drivers and services, you backup SYSTEM

And it can be done better than this

03 Jan 2007 23:13 wwwalker

Re: unixconfig.sourceforge.net and mailing list now open

> some of the comments are very

> interesting. i really appreciate all the

> ideas flying around here.

>

>

>

> we've created an ongoing web site and

> mailing list for people to continue

> discussing, organising, and hopefully in

> the end coding. it's at

> unixconfig.sourceforge.net.

>

>

>

> meanwhile here's another link to the

> permanent home for this article. this is

> where i'm making revisions and adding

> links.

>

That site link is dead. I tried search sourceforge.net for unixconfig and got nothing.

Screenshot

Project Spotlight

c++-gtk-utils

A lightweight library containing a number of classes and functions to ease the task of programming GTK+ programs with C++ in POSIX environments.

Screenshot

Project Spotlight

TurnKey Movable Type Appliance

A Movable Type appliance that is easy to use and lightweight.