Slashdot Mirror
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?"
Simply port over the Windows registry, problem solved!
/HKEY_LOCAL_MACHINE/ /HKEY_CURRENT_USER/ /HKEY_CLASSES_ROOT/ /HKEY_CURRENT_CONFIG/ /HKEY_USERS/
&
should do it, I'd have thought. Then restrict it to a tree structure only under there and everybody should be happy.
Ok, I'm just a humble hardware engineer that has to support a couple Linux servers. So when I have to muck with /etc I make sure I'm close to a google window where I can run for help.
/etc, for each application and service that tells what the files are named and what they do. Is that so much to ask?
I'd be very grateful for nothing more than a README file, in
"Eve of Destruction", it's not just for old hippies anymore...
Have you ever thought of using et al instead of etc?
to clear /etc/ you would create another one that would need programmers to comply to that?
/etc/ so that they're logically placed and findable?
/etc/blaablaa? no. it's hell a lot better than registry still and at least I got SOME idea where the config file is.
wouldn't it be actually easier to get them to place stuff in
because going over to elektra seems actually more work. even elektra's web page admits.. "It is much more an agreement then a piece of software. Relation is 99% to 1%.".
do I have a problem with
world was created 5 seconds before this post as it is.
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.
Let's turn all those files into XML, integrate Xalan into the kernel, and change the cd command to have it evaluate XPATH requests. Then some magical thing will probably happen !
--
<runs_away type="duck" reason="run forest, run !"/>
Insert a clause in the GPL stating that all programs using any part of any component or system must prepare their config files in the following format and must have the following directory structure /etc/program/bin, /etc/program/config, etc.
Seriously though. The best way would be to set up a standard and then begin to push the agenda across the linux distributions asking them to ask the developers to abide by the standard.
Another offbeat solution is that: (You can have a kernel module which reads the program files and if not in the correct format will tell the user it is wrong and therefore it will not run the binary. This would get users to 1. hack a solution or hopefully 2. complain to the developers to fix the problem.)
Or maybe make programs use a specific installer which does this...
Or you could chmod all the other directories to prohibit the programs from writing someplace else...
Quality Hosting e3 Servers
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.
You are not alone. This is not normal. None of this is normal.
What's the real problem with /etc anyway? If you said "all the different and wacky file formats" then you're missing the forest for the trees. Those different file formats exist because it is appropriate to have a file format that suits the purpose of the application. /etc/password and /etc/group are designed for exactly the purpose for which they are used, for example. It doesn't make much sense for apache to have a file format similar to, say, exim; they are applications with entirely different purposes.
/etc. Suppose I am administering a Debian machine with CUPS, since I happen to have one handy. Something is wrong with printing. I have to somehow know all of the following:
/etc/init.d/cupsys /etc/cups/printers.conf /etc/cups/cupsd.conf /etc/cups but, rather, connect to http://localhost:631/ with a web browser.
/etc/cups, but I never do. /System/Library/StartupItems/PrintingServices/Prin tingServices, but I never do.
/etc/profile belong in the same place as /etc/inetd.conf? That gets back to the central question, of course, and I think the answer there is that each package should be responsible for managing its own (default and user) configuration and, similarly
The real problem is that the user doesn't automatically know how to correlate a process, configuration file, startup script, etc., and it affects more than just
1) Printing services are managed by CUPS.
2) To start and stop printing services, I need to run
3) If that doesn't work properly, the process to kill is named cupsd.
4) The config file for specific printers for CUPS is
5) The config file for the cups service as a whole is
6) To manage most things about CUPS (though not browsing and sharing), I don't really want to touch the files in
Just for kicks, let's consider the same situation under MacOS X (10.3):
1) I can control pretty much everything about printing services (including browsing and sharing) from the Print & Fax section of the System Preferences
2) If I really need to mess with the config files, they are in
3) If I really need to manually start and stop printing services I use
4) If I really need to use the web interface to CUPS, it is still at http://localhost:631/
The really important thing here is that on a Mac, I don't even need to know that printing is handled by CUPS. The down side is that on any *nix, unlike Windows, I don't have a way of seeing all the services my machine is providing (to itself or the net). Of course, under Windows it's pretty hard to tell what a service is really for, or how to configure it. When you get right down to it, each system has some good ideas, but none of them have it right.
I want a system where I can get a list of running services (not just all processes), the ports on which they are listening (I don't care if they are TCP, UDP, Unix domain, whatever passes for IPC on Windows, or even Mach ports), and be able to trivially turn a service on, or off, or configure it with a simple commandline or a click of the mouse.
Give me the Windows services manager (with a console equivalent) with the ability to see through what interfaces (e.g. ports) that service is provided, the ability to configure when and how it is started (e.g. at which runlevel), the ability to configure it directly from there (e.g. bring up a custom configurator, a web browser with the appropriate URL, or a text editor on the right files with a double-click in the list). I don't care where the configuration is on disk (though this better integrate well with backup software), nor how it's stored (though there had better be a human-readable text format that can be exported and imported, if necessary).
Furthermore, there should be a separation of default configuration of user applications and configuration of services. Why does
GoboLinux
I am not clueless or Myths and misconceptions about the design of GoboLinux
GoboHide: surviving aside the legacy tree
It's 10 PM. Do you know if you're un-American?
* Using XML is ABSOLUTELY NOT a solution. It is a problem. You can't assume XML-based tools available everywhere. I'm not going to link a 2MB XML library into my 1KB daemon. If you tell me I have to, I will put my config someplace else. I'm not going to put a 2MB XML library on my 8MB flash card. XML makes absolutely no sense for a mission-critical config.
/etc.
/bin/sh and basic Unix tools are present.
/config or something, but we're kinda stuck with it I think.
/etc is not broken, it's not a problem, there's nothing to "solve". Just focus on simplicity. If your ego wants you to invent yet another config file format, DON'T. If your software has a bunch of useless config settings, trim them down, use command-line flags, do something, don't just pile them into a config file. Make your software work in some capacity WITHOUT a config. Look at DJB's software for ideas on how to keep your config simple and powerful. Use the power of pipes, shell scripts, line-oriented text files, and so forth. THINK about the busy admin who has to deal with your crap.
* The config files are way too complex NOW, even without XML. Everybody invents pointless file formats. For instance if you need a flag for a program, just use the abscence or presence of a file in a directory in the filesystem! Don't create a format, write a parser, deal with error checking, etc, etc, just to set a damn flag. Another advantage to using the filesystem as a database (or "registry" if you prefer) is that it becomes super-easy to automate. Automation, simplicity, and guaranteed correctness are GOOD things.
Something to think about: your filesystem is a key/value database, for example "/etc/hostname" is a key, and the contents of that file is the value. There, you don't have to write a parser or a new config file format. Use what's already there.
I remember when Red Hat and other distros started setting up Apache (and other programs) so that they read extra config files out of a directory, instead of trying to automate in-place edits using sed or something. Suddenly everything got 10x easier. Need to install a new config? Just link or copy to the directory.
Taking this to the logical conclusion, you have DJB's software (qmail, djb-dns, etc). Ultra-minimal config using only environment variables or a few line-oriented files. Very flexible, easy to automate, updates can be atomic, merges/updates can done with ssh/rsync, and so forth. Configs can be placed anywhere you want, not just in a special spot in
Gentoo is on the right track in this department. They use filesystem-based configs for some things (for instance the bash-completion package can be configured by linking things into a directory).
* If you absolutely need a complex config, use a shell script that sets environment variables. Many distros (BSD, gentoo again) also use configs that are shell scripts. I.e. the config is just a script that sets some variables. If you want, you can add some code in the script to do calculations or have other logic. This is very nice and flexible. And you don't have to write a new parser, you can assume
* Merging updates: this is impossible to automate. This is the same problem as branching/merging in a version control system. The best thing we can do is 1) KEEP THE CONFIGS SIMPLE as mentioned above 2) use version control to track changes and assist with the merge and 3) again, keep it simple! (Imagine what a nightmare XML would be for merging, by the way). You as an admin should know how to merge the configs, and the machine should make it as simple as possible.
Again Gentoo is on the right track here too. It makes it easy for you to diff/merge your new configs, and can even keep old revisions in version control with RCS.
* The name of the directory (/etc) is bad, it should be
So in conclusion,
And please, no XML!
I didn't even think of /etc as a problem to be solved. Tools like grep, find, vi, and others are all there to rip through text file configurations.
/etc the way it is. It might be a mess, but the alternatives are worse.
Maybe a naming standard would be more appropriate. A solution like Windows Registry would give me nightmares. Have you ever dealt with a corrupt registry on a system?
I say keep
Ruby on Rails Screencast
That is an interesting proposal, a CVS like merge for config files.
:)
The problem I see is the same sort of thing that CVS fails at, logical inconsistancy.
Suppose I have added foo=off at the top of the file, and the new config adds a default for foo, foo=on at the bottom. I'm sure going to be shocked when I'm exploited through the foo unicode vulnerability I didn't know I was subject to!
You get the idea.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
How many times do people have to come up with crazy ideas like XML and Registries or even elektra.
/configuration/foo/bar/baz. Read the contents of the file. DONE!
.template file in the parent directory. Many other ideas could be added. The important thing is all this structure can be IGNORED by a simple program that just wants to read configuration.
It's easy: make a file for each key and put the literal value (not encrypted or encoded or anything) into the file. Want the "registry key" foo/bar/baz? Look in ~/configuration/foo/bar/baz, and if it is no there look in
The filesystem already supports a totally arbitrary name hierarchy, and the data is allowed to be blocks of bytes of arbitrary size. YOU DO NOT NEED ANYTHING ELSE!
Comments could be supported by renaming the file baz to baz.comment. You could also document the expected structure of each directory with a
Elektra is close, but the files are not raw data.
I don't understand why this solution is not absolutely obvious to everybody. What is the problem? Why is anybody proposing anything other than this?
A master notices his young apprentice in a state of obvious distress. "What troubles you, my apprentice" asks the master. The apprentice replies "I am fed up with the mess that is /etc. There are dozens of file formats, all of them incompatible, and most of them are difficult to apply changes to automatically".
The master calmly asks the apprentice, "How would you solve this problem?" The apprentice thinks for a moment and then excitedly blurts "I know, I shall invent a new configuration file format that will be in all ways superior to the existing formats. Every application will use my format and there will no longer be any problem".
The master quickly strikes the apprentice on the head with his bamboo discipline rod. "You fool, then I would have to support yet another incompatible file format".
And the apprentice was enlightened.
I just deleted /etc because it was pissing me off. Now I'm posting from a Windows machine. Why won't anybody give me root access ?
In Soviet America the banks rob you!
I fail to see how a 'common format' is going to help anyone - it's not the format that causes head-scratching, it's working out how to achieve what one wants using the options available.
Because of the simple text file nature of /etc one can easily place the directory into some sort of revision control system (RCS, CVS and the like), making tracking of changes extremely simple.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
my home folder has like 352 items in it + my other 2 home folders (for myself with differnt usernames (because of all my distro changing)) it's 690. now /etc only has 210 it's no mess
Config files should be in separate directories of /etc based on the package/program they are for. On gentoo, for example, I have /etc/portage/. This is how it should work. It makes everything easy to find. I don't find etc-update a terrible amount of work, because I know that, if I didn't touch the config file in question, it is safe to update, because I'll be moving from a default to a default. As it is, it's not a big problem, because most programs have .conf files with descriptive names. As for the idea of a consistent API, I think it is doomed to failure because applications have such vastly different requirements from their config files. There are config files that just have the default settings for a program, all the way to something like the apache config file that is, essentially, the only way to control the program. As for the idea of one file, like the Windows Registry: no. Aside from insecurity, this means that a group (that, say, admins the HTTP server) can not be allowed to modify apache's config, but nothing else.
You people who have been suggesting XML have no idea what the deficiencies of XML are.
t hird</li>
/etc/. Do you want to inflate the size of these programs by 10x just to read a simple conf file?
Please enumerate them. I recommend something like
<ol>
<li>first</li>
<li>second</li>
<li>
</ol>
Remember, there are some tiny programs that need to access files in
It's a shlib. It's in memory already. Get over it.
Or do you want some dependency on an XML library in order to run basic system services?
Yup. Just like libc (or whatever they call it these days), libposix, etc.
These files all look different because they are built to do different things. What is so difficult about this concept? We have JPEGs and GIFs and PNGs and all kinds of formats for images. We have TXT and SXW and HTML and PDF and PS and DocBook and DVI and Tex and what else for generating text. Why? They all serve different purposes.
And all those image formats get us what, exactly? Wouldn't it be far more convenient to standardize on one? If you had listed a vector format, I may have said 2, but all those are just different ways of representing M bits of color and N bits of alpha for X by Y pixels and Z frames. I don't care about what compression is used - just flag the format and be done with it. In fact, I think that's a perfect example of arbitary, meaningless, and bad choice.
The text formats you list server 3-4 purposes, but there are 8 listed. Yup, I think it'd be nice to reduce that list, too.
Choice is good!
No. As others have pointed out: arbitrary choice is bad. Meaningful choice is good. The OSS world has far too much arbitrary choice in it.