How to Fix the Unix Configuration Nightmare

jacoplane writes: "There's an interesting article on freshmeat talking how sorting out some kind of standard for configuration could really help Unix systems could be more user friendly. The article points out that since Apple has managed to build a quite usable system on top of NetBSD, it should be doable to do the same for open-source interfaces."

Comments

There are valid reason

[evilviper]

There are situations were I've wondered why they went off and created their own configuration file format just for that one application, but that's not too common. The problem with a universal format is that each application need to do different things. Typing ALL apps to one format would in many cases make configuration changes more difficult.

i.e. instead of changing one thing, you have to make the change for every interface/terminal/etc it is running on. Just an example mind you.

Maybe the author should try webmin

[evil_roy]

Have a look. webmin

WebMin...not the Right Thing but damn good

[Spoing]

I've mentioned this before, so I'll just quote myself;

1. Get Webmin. Setup Webmin. Use Webmin. Show Webmin to all other administrators. Teach them Webmin. Eventually, when the time is right, show Webmin to management. Drive home the idea that Webmin is a one-stop-shopping, simplified, and robust server management web app that anyone can grasp (if not master). Point out that Webmin supports Unix (including OSX) but not Windows servers (except for Windows with Cygwin). Over time, point out that on the server side, the few remaining Windows servers take much longer to manage and are less reliable then the multitude managed under Webmin.
2. www.webmin.com/webmin

The complaints about Webmin is that it isn't perfect. It doesn't solve the desire for a universal config mechanism or encourage the editing of files directly. OK. It doesn't. Yet, it exists now and is a lifesaver when using multiple UNIXs. Anyone who wants to know what any Webmin module is doing probably also knows how to use find -cmin, ls -lart, or read the module itself since they tend to be in Perl.

When a universal config comes along, I'll use it and guess what -- it'll work with WebMin.

Webmin might not be the right thing, but it is good enough for a vast number of uses.

I hope this goes somewhere

[Twylite]

A brilliant article, and a subject which I have tried before (with little success) to broach with various OpenSource developers. Unfortunately the comments demonstrate the lack of understanding that is all too common in the free software world: an inability to distinguish between apis/formats and software implementations; and an unwillingness to move to a more user friendly system.

GConf and Webmin, for example, are not solutions that address the problem posed by the article. Other comments completely lose the plot: this is about a common configuration format which can use metadata to provide for configuring just about any application, it is not about creating an all-encompassing configuration that will give settings to all applications everywhere for all time.

Gconf is half of the solution at best. It provides a library (common abstraction) for accessing the data. But an application still has to have explicit knowledge of the data in order to act on it. A configuration framework describes this knowledge to allow any compliant application to act on it.

Sometimes an example is worth 1000 pictures (and hence about 1000000 words), so consider a simple packet filtering application with an ACCEPT list and a DENY list, which can listen on several interfaces.

Such an application would have a meta-data configuration file (say /etc/conf/meta/filter.cfg) which specifies: section name=interface count=multiple type=ipv4 ; section name=accept count=multiple type=cidr ; section name=dent count=multiple type=cidr. Now any application can access the packet filter's meta-data file, and the real configuration file (say /etc/conf/filter.cfg), and understand the meaning, to a degree, of the configuration. The types "ipv4" and "cidr" will have to be primitives for the configuration framework.

Thus a general configuration application could present a tree which has three branches (interface, accept, deny), each of which displays a screen with a list. Appropriate entries can then be added, modified or removed, reconfiguring the packet filter without the configuration application having any prior knowledge of the filter's configuration or requirements.

With adequate forethough (for the categorisation and types required) such a system can be extremely powerful. A single configuration library can be used by the application, as well as GUI and CLI configuration clients. You could easily have a command in a script: config pktfltr add -section interfaces -value 1.2.3.4 .

A common library like this can also provide powerful features that a lot of applications lack, like local (user) settings which override global defaults. The library can maintain global, group and user configurations for each application, and getting/setting preferences will take the overlays into account.

Implementing such a system would also provide an ideal opportunity to introduce configuration versioning. CVS (for example, or arch, which includes directory versioning) could be used to maintain various versions of the configuration files in /etc/conf.

Arguments about diversity are largely moot. The data format is independant of the data in any well-written program. .INI files, Bind-style files, XML files and SAMBA files can all represent the same information, but they look different. Some are arguably more efficient in some situations. Even the feared Windows registry has the same functionality ... it just makes the (fatal) error of storing everything in a mostly inseparable datastore (sortof like an /etc/conf directory in which you can't treat the various files separately).

This is a suggestion which needs to be followed through, and supported by the community.

It seems you're missing the point

[Nailer]

The problem isn't with the lack of a standardized configuration tools, its a lack of standardized configuration file formats. This allows:

• Systems administrators to work with new applications config files without worrying about how exactly a comment should look
  
• Automated parsers that don't have to be re-written for every config file - you'd have a whole buynch more webmin modules if this was the case.
  
• GUI folk to be able to use their graphical interfaces knowing that they won't screw up a config file, because there's a very rigidly defined format for the config file and a standard parser that's very well tested
  
• Better manipulation, imports, exports, etc of information into config files, as a popular format allows for the development of tools to perform these tasks across many different applications
  

Some *correct* information about MacOS X config

[lcracker]

Yes, I know this is a comment on freshmeat (I wrote it).. but it pains me to see so much incorrect/incomplete information here that people just believe for lack of experience with 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.

Re:Some *correct* information about MacOS X config

[Jordy]

NetInfo exists for the same reason NIS, NYS, YP, etc exist; to centralize system configurations across a network of machines. Things like printer configurations are typically the same in a corporate environment.

NetInfo is actually Open Source. Though I'm not sure how up-to-date it is.

As for /etc... some of those are synchronized from NetInfo, not the other way around. A good number of them are just stub files, but there are a few that do not exist at all in NetInfo at all.

Re:I /like/ the Unix Configuration Nightmare

[Shanep]

that is UNIX. Take it or leave it.

I agree. I'm reading all this wondering why people are complaining so much. How much time do people spend in /etc anyway?

I need to get something set up, I go to /etc and either see a file or directory named something along the lines of what I'm configuring. Get it up and if I don't know it well, either quickly read the comments or the blah.conf man page... configured... working... I'm done in here for a while until I think of some other cool thing to do.

When Win95 went to a single, non-text config file (registry), I instantly thought this was going to be a really bad move. And it proved to be. Registry rot is incredible. Anyone ever notice that if you reinstall Windows about once every year or so, you get a massive boost in performance? I installed 98 the other day (just for D2:LOD, Starcraft and RainbowSix), it boots (PII-300, 512MB) in about 30 seconds and shuts down in 1-2 seconds. Prior to this, 98 was taking an age, *if* it would shut down at all, and I had all sorts of stability problems. BTW, I put the C: on a 700MB partition and used a D: of 2.5GB for the games. I burn the C: to a CDR and when things get bad, just dd it straight back to hda1.

My point is (back to the OSes that are more fun than a Frost Nova up Andariels arse), *I* want to mess with those config files, rather than have some app(s) messing with one really important file.

I like it too.