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.
Let's see you do it better!
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...
Heh, that's what I got when I clicked on the "Read more..." Link heh. Guess I am faster than /. these days
+(norad) if you rearrange the letters in mother in law, you get woman hitler
/usr/local/etc
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.
I agree! The windows registry is a much better solution to the problem....
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.
People have suggested using an XML based etc/ This is really appropriete for XML because most files under etc/ are small and infrequently read. Maybe a DB backed etc/ for ease of maintainance across a large pool of machines?
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
If the system were to keep around the unedited original versions of each config file, then on update it could diff your edited version against that, creating a patch, which it could attempt to apply to the new version. (If the patch does not apply cleanly, of course, then you still have to hand-merge, but I suspect that in the majority of cases the lines the user has changed will not be the lines that have changed in the new version. For instance, in http.conf a lot of us only change a couple of basic things, like DocumentRoot and such, and for most upgrades the patch would apply cleanly, unless the app has made major changes to the config file (e.g., between Apache 1.x and 2.x). I have changed just one thing in wgetrc (to make it do passive ftp, since I'm behind a NAT gateway) -- that should apply cleanly almost no matter WHAT the wget people do to the next version of the config file, I would think.
/etc-originals) or perhaps right beside the in-use config files, with a .orig suffix added or something.
/etc, ~/.* should probably be handled much the same way.
I'm not entirely sure where the unedited originals should be kept; perhaps in a separate hierarchy of their own (e.g.,
Besides
Cut that out, or I will ship you to Norilsk in a box.
Perhaps if there were some sort of "registry", to which all configuration information could be added in a common format, which any program could access or modify...
-- 'The' Lord and Master Bitman On High, Master Of All
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.
./configure --prefix=/usr/local/-
/usr/local/kerberos and all packages pertaining to postfix are in /usr/local/postfix who cares?
/etc/ instead of /usr/local/etc/ anyway?
make && make install
Don't get me wrong, I think there should probably be a "conf" directory in addition to an "etc" directory, but hey, if all packages pertaining to kerberos are in
Besides, most people don't follow conventions anyway, how much stuff is in
RandomAndInteresting.comdefending the world from stupidity since 1979
Config files aren't going to be forward compat, so place their contents into an XML file. But also place enough documentation in the XML file that each admin can grow a small hand-editable help file right with it, geared towards the audience they admin with. DON'T keep all these xml's in the etc file, but in another directory.
"xtransetc" build a navigatiable page set from the files, allow you to hop around quickly and remotely.
"genetc" fills the dir from the xml files, as you've tweaked it (with comments, don't/dos)
"readetc" fills the xml file "meat" from the etc directory itself, thus it's two-way.
This first step re-bottles the data in a more extensible format. Next up, you keep portions of the "meat" in the user's specific folders. Then, genetc collects and collates these separate portions into a single etc folder, overwriting with the xml base. this runs at full logon. next, during this process, check user's groups to ensure they have overwriting permissions for each config payload.
New configuration files can be absorbed blindly, just leaving many of the metadata tags empty. a list of "feed" dirs is kept in the xml store, as well as the "discovered_in_dir" tag in the xml file.
Dependencies can be built through metainfo tags as well, but also holding very specific information, like dates, checksums, or package/file authentication. In addition, a "cross-compatability" section can list several safe substitutes for given dependencies.
the full thesaurus of dependency identifiers (since multiple names may point to the same program) has be to the cross-distro key. this shouldn't be hard, just a web site one distro starts and as others creep up, are posted.
in this way, you can gen a full web version of all distro/packages/apps/config files into a single tree, with dependencies and synonymous identifiers. also, versions will add "depth" dimension to the tree to see where branches formed and detached (if ever).
um, yeah. i'll get right on that.
Supposedly registries are supposed to make administration easier, but in my experience they do exactly the opposite. Think about how many times you see instructions on Windows that say "before you make any changes, back up the registry". Having a registry makes sense when all your data all looks the same, but this isn't the case for config data. Every config file is different for a reason.
Of the many reasons that I switched from Windows to Linux, the ease of configuration was high on the list. I love RPMs because the config data just falls right into place without me having to touch anything or worry about messing up some other program's config data. Adding another layer to config data that doesn't add any value would just screw things up. I'd go so far as to argue that Windows would be a lot easier to deal with if they brought back .ini files.
If you don't want crime to pay, let the government run it.
OpenBSD.
Buy a Mac, then you won't have to worry about what's in /etc. It'll still be there, but you won't have to look at it.
It's good to use your head, but not as a battering ram.
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?
... and if this was a windows bashing story and you said "windows was flawless... *runs*...", it would be +1 funny
I've been thinking about this too, and actually the windows registry has the right idea. there you don't have to parse and merge a file to add an option, you just make a new key and such. the comments could be added as a note to each key or something. great initiative.
The /etc can be replaced with smitty. Heck the config files themselves can be databasen, or in a database, or (gasp!) registry.
/etc comes from the unparalleled freedom developers enjoy on unix in the first place, no placing intricate structures in some central registry.
/etc, /etc/app.conf/, /usr/local/etc, /opt/etc, /var/etc, ~/.app/etc.... etc etc
/etc, others should head into /usr/local/etc. End of story. The problem comes when people compile their own apps, and either do not do ./configure --prefix=/usr/local, or the app doesnt allow it. Another issue is multiple installations of an app...
/usr/apps/app1/etc.
All that is the windowsizeation of unix. The whole mess of
The real mess is the difference between
Proper hier structures dictate that apps installed as a part of the OS should go into
All that can be solved by making sure all apps when compiled can accept --prefix, and when in packaged form, can be installed in a different folder root, like
And to start solving such issues, we should begin by whipping apps like qmail, which go to lengths not to get installed in the proper directories.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
On a gentoo system, after you update a package with an /etc/* file, it tells you that you have to update the file. Then you run "etc-update". I usually play the game this way. If I've ever edited the file, I'll take a look at it to see if it's going to bork my system. If it's not a file I've ever touched, I'll assume that the changes are fine and I replace the file...
oh wait...that only works if the user knows what's going on with the system...I'd hate to be an administrator in charge of many computers after an update!
* 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
Why not switch to using Application Directories? Simple, self-contained, and easy to manage.
There's something that's much better. It's called "\Documents and Settings".
Very organized, consistent, and above all easy to understand.
You are in a maze of twisty little passages, all alike.
If you want to change /etc you are going to have to convince vi or even ed users like me. xml ain't gonna do it. We use vi because emacs takes to many keypresses to start. We are not going to type the variable name twice. No way. Try again.
/etc is a mess wich could first be slightly cleaned by moving every config file into a subdir with the same name as the app. This would at least reduce the number of entries and avoid problems with designers naming essential config files something else then app.cfg. Yes I am talking to you mplayer.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
In my humble opinion, I say that /etc is partially fine as it is. As someone said earlier, atleast you have SOME idea about where your configuration files are. However, since I am a fan of tidy filesystems, I would say that /etc should be as it is, but with a few modifications. For example, files needed to run the system (passwd/shadow, ppp.conf, shells, groups, and such) could have their place in /etc while other applications' configuration files could be moved to a subdirectory. The same goes for other files. Myself, I think this could be a good idea, as long as it does not create a ton of subdirectories and become way too messy. If it is kept simple, the way the idea behind /etc originally was, it could work.
this is probably the most boring sig in the world
For most services, a simple cut and dry config file is all that is really needed. This has worked for many years, and most of the problem can be solved by having good manual pages for each of the files (see OpenBSD for good man pages).
For the few problems that need a more complex solution, then those can be taken on a case-by-case basis. For example, Sun revamped the whole init process with SMF, replacing many separate files and directories with a few command line tools. Of course, there is compatibility for "legacy" apps, but the rc directories and inetd.conf files are much much smaller, now.
Replacing all the
When it comes to
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
Oh lets admit it, windows registry is an even greater mess. At least /etc support bloody goddamn fucking comments. Something MS apparently thought nobody would ever need.
But what about all those different file formats. Mmmm well yes true enough. They are really not all that different though. Most of them have 1 pure text file seperated into sections for easier reading and each entry is something like "setting = value" contruction. The better config files have lots of comments to indicate possible values and what they mean. Very easy for humans to use. I generally find editing a config file to be a breeze.
The problem is between updates. I get the idea that the poster is using a gentoo and gentoo has a thing for updates. Gentoo updates a lot and for some reason config files change a lot. Not a problem with config files you never touch youreselve just accept the updated one but with things like /etc/fstab samba or apache configs it becomes more complex.
For a long time gentoo insisted on constantly changing /etc/fstab despite the fact that the format never changed, no new options were ever added and all the settings are purely individual. Thank god they changed this but they still insist on giving me a new config file for each time samba or apache gets installed. Now some of the changes are security related and important but an awfull lot seem to be pure preference by whoever this time did the config file. Finding out the differences ain't easy. Often they are purely syntax differences anyway. Diff is a nice tool but can't understand human reasons for why lines might be in a different order.
So merging new configs and your existing config is indeed a mess. A better way to do this would indeed be usefull.
This however HAS ABSOLUTLY NOTHING TO DO WITH /ETC. The exact same problem occurs on windows with its registry. You see the simple problem is this. Say I got a config entry that says, foo=bar. Now during an bugfix it becomes clear that for 99% of users this should be foo=bar2 instead. How do you change this? Just overwrite what is there? No because for mee foo=bar might be what I need and I don't want an upgrade to change my settings. Ignore? But then I am never alerted to the fact I am using outdated settings. Alert me? Well nobody seems to do that.
Ideally during an upgrade the installer would go through the existing settings and analyze them for correctness and alert the user to changes.
It is not a gentoo specific problem either. If you install apache by hand it just leaves the old config untouched. Windows throws a dice during boot to see what it does with your settings. Games just overwrite if they feel like it.
Don't mistake messy dir structure with lousy upgrading of configuration settings.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I don't know why you are using etc-update. Everyone I know uses dispatch-conf. It's widely accepted as the smartest way to handle etc. Sure, there are probably easier ways to handle etc, but you're never going to get everyone to standardize on any single thing.
The best solution I see would be to have some sort of XML/database kind of solution and have a nice gui tool and a command line tool to configure everything with a tree-like interface. Something like the GNOME configuration editor but fuller and better. Since all the tools are open source you just have to modify each piece of software to use the database instead of its own default. This would probably result in an entire new distribution of *nix with custom builds for everything with patches to support this.
But to be perfectly honest, I kind of like the seperate txt config files for everything. As long as all of them are in etc and named and organized appropriately. And as long as the format of the file is intuitive and simple with appropriate documentation it's all good. The real problems are programs like apache which have needlessly complex and bastardly configuration files that require tomes to understand. KISS like mplayer or Xorg.
The GeekNights podcast is going strong. Listen!
What is missing is an automated versioning of everything in /etc
/etc as free wild as it is, but! put the whole directory under a filesystem based revision control like http://www.ext3cow.com/
I don't have an issue with multiple file formats, like another poster said, find and grep do the job quite nicely. However, what I don't like is that there is no history of modifications. No single way to undo any modification.
My proposal is to leave format of
-- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
You people who have been suggesting XML have no idea what the deficiencies of XML are. Remember, there are some tiny programs that need to access files in /etc/. Do you want to inflate the size of these programs by 10x just to read a simple conf file? Or do you want some dependency on an XML library in order to run basic system services? Or would you rather use a dialect of XML that can be parsed easily? If you can't name ten problems for each of these scenarios, you shouldn't be suggesting what to put in /etc.
/etc. No external libraries. No unreadable XML crap. Something simple and easy.
/etc/selinux, etc...)
I would prefer a simple file format (not XML) that can be parsed in very few lines of C code in
Oh wait! We already have that! If you do a survey of what file formats are actually used, you'll note that they come in a handful of formats. You have your database files (/etc/passwd and friends). You have your simple config files (/etc/resolv.conf) and you have your more complicated ones that are specific to the application (/etc/httpd,
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.
Free Software is about choice and diversity. Get over it. We are always going to have choices, and the more choices we have, the better. If that bothers you, go back to Windows where you choose nothing, or go live in Cuba or North Korea.
Choice is good!
The radical sect of Islam would either see you dead or "reverted" to Islam.
The XML version is harder to read than the .ini version.
That's a matter of opinion, and can vary greatly depending on what data you want to store.
It's hard to tell at a glance if the config is a valid config.
The same applies to proprietary syntaxes. The only difference is that XML has clear rules for treating syntax errors, and has many tools to automatically check syntax. Some editors even do that for you automatically when you save, or don't let you create syntax errors in the first place.
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
I'll stop responding here, since it is plainly obvious that you don't even know the first thing about XML. To cut a long comment short - you are clueless and utterly wrong.
/etc is not an issue with LSB complant distributions.
.
.xinit/.xsession files from the hidden safe directory before kde/xfce/windowmaker start. Maybe this should be standard?
A bigger issue is how we prevent less than average user from having thier linux machine become a host owned by the seedy people
Maybe this isn't the forum, but it needs to be discussed. Not from the kernel or services perspective either, just from the Joe/Jane user context.
My thoughts?
- We should not pester the user too much. My parents turned off Zone Alarm because they got tired of the pop-up warnings. (I know you can turn it off, but I didn't and left and they disabled it).
- Any program that connects to the internet needs to su to a different user context after initialization (like apache, thttpd etc.). This should prevent the application from overriding the user files because of a bug/flaw.
- Programs not started by the user with a click or run command should not be allowed to execute. Could Gnome/Kde implement such a feature?
- After X login, I have a script that copies my
I don't know all the answers, this is just a topic for discussion. Lets start a thread on how you would implement user level safety while still enjoying the benefits of Linux.
Enjoy.
It's just the normal noises in here.
Mac OSX (ok, I'm sure this dates back to {Open,Next}Step) has a nice solution. Preferences are stored in an XML formated file, typically (but not necessarily) one per application. Global preferences are stored in /Library/Preferences/foo.plist, and user-specific preferences are stored in ~/Library/Preferences/foo.plist. Also, the convention is to make the file name unique by combining it with a domain name, like com.apple.SomeApplication.plist. Of course this is on top of the normal unix /etc/ files and doesn't exactly replace them, but it's a nice system that could be adopted.
_______
2B1ASK1
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?
Then you can make some simple command-line tools would make it easy for admins to find configuration files if they forgot where they are.
This is one place where Mac and Windows have a benefit. There are standard APIs for configuring most things (even though Windows keeps the files hidden in a massive and ugly registry). It makes it easy to write reliable configuration tools. We don't have to have a big registry to do that. Just some nice wrappers on top of what we have would be good.
I don't think the problem is where the files are placed. It very easy for me to find the config for a program that I never used because all I have to do is look in /etc and it's mostly there.
Cheers,
RoadkillBunny
I use FreeBSD, so my /etc is nice and clean. But my /usr/local/etc/ is pretty ragged....
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.
The problem is that the unholy mess that is /etc is one of the primary ways unix administrators assure their job security. Until these attitudes (already expressed prolifically in comments above) change, /etc will remain inconsistent, poorly documented and problematic.
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!
So they should simply pick a syntax that's been standard for a long time; and all use that. I propose sendmail.cf; since it's quite powerful.
Or... how about XML. Then /etc could blow up to a few gigabytes and we could sell more hard drives.
More to the point, the article's premise that "/etc is a mess" is simply wrong. Different applications have differing needs; and there's nothing wrong with reading the man page to know what its config files should look like.
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
I really love the registry on Windows. It's fast, flexible, and Microsoft have allready defined a standard by their included programs, and Office. I hope Linux sooner or later would like to use this stunning registry-database.
Please dont give me the shit about registry corrupts and similar, there's no problem with this now. It works nicely atleast on our atleast 8000 clients
This (good) idea will fail again, because IMHO the people involved are too short-sighted.
/etc may not need to be cleaned up explicitly. Instead, use a proper system-wide and POSIX-standardized API for implementing a defaults system which gives the user/application programmer/sysadmin benefits so he is inclined to use the API.
Main points against this proposition include:
- It has worked to far, no need to change it.
- Why yet another key-value format? The old one does all we need.
- I hate XML. It's a hype, and that will pass.
My points for this proposition:
- It has worked so far, but maybe there is room for improvement?
- XML gives you more than many other key-value-formats, namely namespaces and proper escaping.
- Get over the XML-is-a-hype. Try to look at the benefits neutrally, then use what's best to do the job. IMO, XML is a code like ASCII (on top of a charset). Anyone who proposes that he can read a text-configfile with any editor is really using a tool to convert the data into ASCII. Well, I can read any XML file with any text-editor, or I can read it with nice formatting because XML is so machine-readable.
In my opinion, the mess in
Benefits could be:
- No self-made serializing/parsing system needed.
- Platform-independent defaults system.
- Forget escaping or namespaces. The API provides that.
- Installation-specific or user-specific overriding of values.
The API could use a user-defined file format, but probably XML does all you need.
Provide tools for the grep-happy people to search the config-files.
But again, this will fail, mainly because the people involved are not looking for benefits of an improved system.
Lars
When I started playing with Linux several years ago, my reaction to the file system was "What were they thinking?" Not in the sense of "that was stupid" but seriously not having a clue what was supposed to be where. I managed to dig up a reference that explained the structure, but it hasn't helped because it doesn't conform to reality.
One of my if-I-had-50-more-hours-a-day-and-knew-how-to-persu ade-people-to-follow-me projects would be to build a more intuitive file structure into *n*x. (Maybe starting with an overlay of symbolic links?) The biggest problem with "/etc" is its name; it should be called "/config" or something like that, rather than implying that it's just a bunch of insignificant leftover stuff that you don't need to worry about. The whole SysV init hierarchy could do with a facelift as well. To say nothing of the dozen *bin directories scattered about the tree. Sure, it was great to be able to wow my new boss with my tech savvy by sitting at a console and typing vi /var/named/foo.bar.zone, adding an A record, and then going /etc/rc.d/init.d/named restart to add a new hostname for our domain, but I don't think it gave her a very good impression of Linux's manageability (compared to say, edit /config/bind/zones/food.bar and /startup/master/bind restart).
Sure, /etc could use some spit and polish, but once you find all those *.conf files, they're really not that difficult to deal with.
http://alternatives.rzero.com/
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.
Looks to me like he was describing our current /etc system. Is Elektra just XML metadata bolted onto an /etc like filesystem?
This post written under Gentoo-linux with an SCO IP license.
As a system admin for about 50 computer systems running different types of unix, I cannot see why /etc is considered a mess. It is only a few megabytes at most and provides easy filebased access to all important configuration files. Using your package manager of choice, you can easily find out which files in /etc belong to which program.
/etc to be /etc files + cfengine site managment functionallity.
If anything, I would suggest files in
cfengine friendly. A registry is nothing else but human readable
If you don't like where your package leaves its config data, build it from source. Don't be lazy.
./configure --help | grep sysconfdir
root@moops:/usr/local/src/php-4.3.3#
--sysconfdir=DIR read-only single-machine data in DIR [PREFIX/etc]
You want an easy-to-use abstraction layer.
A lot of the problems between distributions would be solved if they agreed on a single, simple, underlying data format and structure for things. This has happened to some extent, but much remains to be done. One of my frustrations is that the major distro's are moving more and more into bloatware approaches to systems administration that make it more and more difficult to figure out how to make the system do the right thing.
Instead of editing a single text file, I often end up spending four hours (or days) deciphering a complex overlay of bloatware programs and data files - so that I can edit their "never to be touched" text file, so that their configuration system will update the original text file in the correct way. ARGGGGHH!!
I'd also like to see all those "hidden" files in my home directory pushed into a ".hidden" directory. Of course, if the various X applications followed the same convention, that would help. Acrobat Reader comes to mind.
While I'm dreaming of the glorious integrated future, I'd like data commonality between various applications - like web browser bookmarks, mail file trees, etc. (Yes, I do switch between wysiwyg mail applications. I'm fickle, and none of them do _everything_ the way I want.)
And, while I'm at it, how do I convince Gnome-2.6/Nautilus to include the "eject" option for the Desktop icon for my ATAPI Zip Drive? And how do I turn on window-edge gravity?
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
What happens when you want to change a setting that's not shown in the user-friendly GUI "Settings" editor?
Some programs have a lot of obscure options. Are they all presented in the nice "Settings" windows, for all Mac applications?
That's a problem I've encounted with the simplest of systems (e.g. webmin) which edit files in /etc on a Linux box. Occasionally I need a setting which the fancy settings-editor doesn't know about, and then I have to worry that future uses of the settings-editor will break essential
changes I had to make to /etc by hand, without me knowing until I observe the symptom maybe days or weeks later.
Once that point is reached, that risk is unacceptable and the only safe thing to do is stop using the settings-editor.
What is the solution to this? Making all the options visible in a GUI "Registry editor" type of program is not a solution, because if I've done something unusual to a file in /etc, then I will have added explanatory comments and grouped the unusual options together to make it obvious that they are related by my specific requirements. No "registry editor" I have ever seen offers that kind of functionality, which I find essential.
-- Jamie
If you have this problem, it was of your own making. One thing I learned many years ago. Prefix every package to its own directory and use links in /etc. Now you can have /usr/local/ver1, /usr/local/ver2 and so on and create links to the config file. Also, who said you can't config the app to use a different path for the config file. The main reason I love *nix, is I have compelete control over my system. Even install prefixes and default config files ;-)
You only live once, so you might as well have fun before you die.
I'd offer some suggestions, but it would not matter. Folks are going to riddle directories as they see fit. Way it goes.
"Play is the only way the highest intelligence of humankind can unfold." -- Joseph Chilton Pearce
Pure FUD. You didn't even put any effort in to finding a good example, you just used something which one would never require to use on a mac, and even if they did, would only need to edit some configuration file because it's not a Mac app, it's some crazy Linux POS.
If you put your energy in to forging a solution to your problems rather than bitching about how the alternatives are "unacceptable" and a "risk", you might actually have a fulfilling life.
Dear Anonymous,
What the fuck are you talking about?
Your comment doesn't actually say anything. It doesn't answer any of the posed questions, and it doesn't offer any solutions to the real and genuine question of how to manage unusual configurations without editing /etc files.
Your suggestion to "forge" an alternate solution, by which I can only presume you mean do something other than edit config files - WTF does that mean, do you have something to add or is it just a masturbatory flame?
I have a solution to my problems, which is editing config files, or writing scripts which generate configs: it has so far always been the best solution that I'm aware of for the problems that I've encountered. You probably encounter different problems, so have different requirements.
But I am not wedded to the approach. Which is why I asked if all configuration options for apps on the Mac are shown in the GUI. It is a pretty straightforward question. An answer of "yes" would be nice. Even if the answer is "yes but only if it's a Mac app", that would be nice. But apparently you don't answer questions, preferring instead to be an unfriendly wanker who can't tell the difference between a question and stupid fight.
-- Jamie
Something like ReiserFS's plug-ins might be useful here. See this example of how /etc/passwd could be split up to improve privilege granularity (search for "Take /etc/passwd for example"), all without breaking existing programs. This would also give you finer-grained modification timestamps, which would help you figure out what that pesky installer just did.
Hasn't happened yet.
It's good to use your head, but not as a battering ram.
In case you're wondering if that's just me being a Luddite or if there's a solution in mind, perhaps there is.
It's for each application to include metadata for each of its config files, indicating the types of data, ranges of options and so forth, and how to present the information in a config file editor. In addition, a certain free-form commenting and option-rearranging facility is needed when presenting configs in a config file editor.
Such metadata would be quite complicated in some cases (examples of complicated configs: /etc/iptables.conf, /etc/samba/smb.conf, /etc/apache/httpd.conf). However, and XML Schema or something similar would likely cover most of the practical cases.
Comments are important in config files, when a configuration is unusual. For example in my OpenVPN config, I have three options and a comment which I'll summarise here as: "ping-restart 60, ping 15, nobind -- all three are needed together to workaround a problem with some NAT routers, when the ADSL-side IP address changes dynamically".
Somehow, a GUI, TUI, or even XML view which presents configuration files in a standardised syntax must be able to record this kind of human-relevant information somewhere. It's not enough that programs can read and edit the configs; they record important information for human users too.
When the structure of a config file is described by some kind of metadata, that begs the question: can't the metadata described the syntax of the file too? There is no need to use XML, if the syntax can be adequately described by metadata in addition to the structure.
Finally, it's essential that such metadata is updated by individual application updates, and not as part of a "config editor" package. This is because the metadata is only useful if it reflects the range of options currently supported by each application, not merely the options that the config editor knew about at its last release cycle. This may seem like a difficult thing to get widely adopted, but it would not be so difficult provided metadata was easy to write, described the kind of file formats that application writes are happy to use, and was actually useful. For better or worse, XML is not such a format, precisely because it's not very human friendly in comparison with many of the text formats.
-- Jamie