Solving the /etc Situation?

mrfibbi asks: "/etc is a mess, plain and simple. Each program has its own (incompatible) config file format and the naming scheme/hierarchy is left almost solely to the author. Furthermore, package updates are a mess, either choosing to replace the entire config file, reject any updated versions (which leads to inconsistencies), or, as is the case with etc-update, asking the user to manually merge the files, which takes forever after a big update. We've revamped /dev with udev, but we've still failed to come up with a universal, duct-tape-free solution for the problem. Though solutions exist, there has been little or no adoption, either due to a personal dislike for the idea or API, or just an indifference to the problem. Should we work toward migrating to an Elektra-like system? Something else? Or do most simply find it not worth the trouble?"

Comments

This is just how OSS is...

[JacquesPinette84]

OSS is about choises, and /etc really highlights this. People have different ideas on how apps should be configured, and I think putting all configurations in one place was a good compromise.

Messes are inevitable

[squiggleslash]

Whatever solution you come up with, it's unlikely to remain clean for long. I'm sure the inventors of the Windows Registry thought they'd come up with a clean solution, and I know the GConf people did too. Are they clean? Do you like them?

I don't.

Leave /etc as it is. It works. It's done the right job now for coming on 30 years. It's had one major clean up (executables moved to /sbin), and otherwise it's nice. You can grep it. Help is a manpage away. With the exception of a handful of recent apps from programmers who don't "get it" and think XML is better than simplicity, the config files are, by and large, consistant, within a certain mindset.

There's lots of things that could be improved about Unix. Destroying /etc doesn't really improve it.

Re:Messes are inevitable

[Anonymous Coward]

Unbelievable. Just this little example you show demonstrates the utter insanity of XML.

The XML version is harder to read than the .ini version. It's hard to tell at a glance if the config is a valid config. Would you really be able to spot an error in a closing tag, for instance?

It is also harder to edit using command-line tools. It is harder to edit with ANY common unix tool, actually. You *must* use editors that understand XML (do you have editors like that on every machine by default? And no, syntax highlighting doesn't exactly count).

How do you diff/merge? How do you push out changes to *some* of the values to your farm of 100 machines? Remember, your XML file can look like this too, and still be equivalent:

<section
name='Top'
>
<Setting1>true</Setting1< Setting2>true</Setting2>
<Setting3
>false</Setti ng3><Setting4
>false</Setting4>
</section>

(the extra spaces here and there are /.'s doing)

Say goodbye to the entire arsenal of simple well-established unix text-munging tools. Say hello to multi-megabyte XML parsers, just to slurp up key/value pairs.

XML is definitely NOT what I'd want to see on my machines. Especially ones that are meant to be reliable.

Here's how I would write that hypothetical program. I'd create a directory /etc/my-app/top. The "true" settings can be set like this:

cd /etc/my-app
touch top/setting1 top/setting2

Done. Now my app can just check for the existence of the file as a true/false (or yes/no) flag. Do I need a new setting "top/send-alerts-to" that takes a string? No problem:

cd /etc/my-app
echo me@example.com > top/send-alerts-to

Am I use a high-availability system? Here's how to do the above atomically:

cd /etc/my-app
echo me@example.com > top/send-alerts-to.tmp
mv top/send-alerts-to.tmp top/send-alerts-to

Do I need to synchronize this config with another machine? But not the "send-alerts-to" setting? No problem:

rsync -a --exclude top/send-alerts-to /etc/my-app/ othermachine:/etc/my-app/

Do I need to temporarily change the config and leave a comment for another admin? Here I go:

cp -a /etc/my-app /etc/my-app.2005-03-02
touch /etc/my-app/top/setting6
echo "Temporarily activating top/setting6 because...." > /etc/my-app/README

Want to merge changes? No problem, just use common version control tools like CVS, SVN, Darcs, whatever, that you probably already have laying around. You don't need a special XML merge tool.

Want to quickly double-check a setting? Use grep, find, a GUI tool, whatever you want. NEVER underestimate the power of line-oriented text files. Searching XML with grep is a nightmare.

Am I just showing off my 'leet command line skeelz here? No I'm showing how simple and flexible this scheme is. It's pretty hard to make the configs unparseable or inconsistent. They can be automated, or edited with vim, or whatever. Heck, in your XML examples, you have to type each tag *twice* (open/close)! Yeesh. That doubles the chance of mistakes, right there.

Re:I got an ... _angle_

[tzanger]

You are on crack. Seriously cheap crack. There are so many problems with your idea I can't even figure out where to start.

One badass file that everything clamours to get access to, even through a well defined API is going to be hell. Contention abounds. A bug can kill the entire system configuration. And then you throw the saviour of the digital world into it: XML. Why don't you just make it a binary file and have every single problem the Win32 registry has.

A unified configuration scheme is a great idea. XML really isn't IMO the solution, and one big badass file is certainly the wrong way to go about it.