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?"
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.
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.
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?
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
You're joking but seriously... look at what Apple did... /Library/Preferences/*.plist is a simple, human parsable, easily scriptable, programmatically manipulatable (with a concise API) way. All current different weird file patters could be collapsed in an unique versatile structure that could be (ad lib) mapped to a registry like GUI or handled by sh scripts or vi. I vote for com.example.app.plist files
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
Like all OMG-TEH-XML-IS-GOOD-4-EVARYTHING-morons, you miess the point.
Straw-man. Nobody says that XML is good for everything, and the person you responded to certainly didn't.
XML is for hierarchical, complex data-structures.
Sounds like config files to me.
The configuration-system deals with flat, key-value-pairs.
Which configuration system? /etc is full of different ones. Most people who talk about "key-value pairs" advocate something like INI-style. Pretty much every non-trivial INI-style config file format I have seen ends up with things like config1=, config2=, confign= in numerous [section]s - basically, shitty workarounds to try and store hierarchical data with a non-hierarchical syntax.
I seriously hope you don't even think about doing something in the IT-industry.
Dickhead.
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.
Instead of having nested XML tags, we could use directories and text files! Oh, wait...
I suffer from attention surplus disorder.
Or he could always visit the Half Bakery.
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
How is the registry "non-secure" and "non-manageable" ?
It can be remotely edited, or (much preferably) modified via Group Policy for centralised system configuration.
Its "locations" and "structure" are well defined.
Access is restricted down to the key level by per-user ACLs.
It's transactional.
A user's personal registry settings are stored in their profile.
Automatic backups are made by the system.
The problem, as with 99% of "Windows problems" is not with Windows, but with poor software developers misusing - or not using at all - the system's facilities properly.
I very much like Apple's OS X approach. Separate files for each service/application. The problem with Windows's registry is that there are many entries that references other entries. If an application's uninstaller is not written just right, you will have dangling references polluting your hive. Apple's approach is very much like Mac OS. If you remove an app, you know that you can go to (basically, there are exceptions) System Folder:Preferences and remove the app's preference file/folder. With the Windows registry, you're never really sure since there are a lot of GUIDs like "{4D36E97B-E325-11CE-BFC1-08002BE10318}" where you have no idea what they mean.
.INI construct. Just don't make the damn thing binary. Even Apple's XML files contains encoded binary. Not very user friendly, but I suppose they've done that on purpose. You can be sure that information can be hidden, regardless of how it's implemented.
As far as XML, it doesn't really matter if it's done using XML or the Windows
You might want to read Esr's Art of Unix Programming, specially chapter 5 on data formats :
Here's what he says about XML files
The most serious problem with XML is that it doesn't play well with traditional Unix tools. Software that wants to read an XML format needs an XML parser; this means bulky, complicated programs. Also, XML is itself rather bulky; it can be difficult to see the data amidst all the markup.
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.