Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

Solving the /etc Situation? 293

Posted by Cliff from the config-file-wars dept.
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?"
This discussion has been archived. No new comments can be posted.

Solving the /etc Situation? More

Solving the /etc Situation?

Comments Filter:

  • I got an ... _angle_ (Score:5, Funny)

    by Tumbleweed ( 3706 ) * on Friday March 18, 2005 @05:56PM (#11980582)
    Simply port over the Windows registry, problem solved!

    • Re:I got an ... _angle_ (Score:3, Insightful)

      by Anonymous Coward
      Now there's a good solution. I will take the chaotic state of /etc over the Windows Registry NIGHTMARE any day. Hell, I'd rather get a good swift kick in the nuts than deal with the Windows registry nightmare
      • I agree. But I definetely think that an alternate is needed severely. Elektra would work quite easily as long as they adopt a little extra policy that says inside each programs folder they need to have a subfolder for each installed version of the software. These subfolders could be symlinks to the other folders if they wanted to use the same conf in different versions. Additionally, I've seen a comment on Elektra's lack of a 'list' datatype as one of the available key/value pairs (Elektra currently on
      • But actually I suppose the real problem here is the lack of a tool that non-destructively updates the config files for newer versions without requiring user input, or only requiring an easy Q&A sequence which can be scripted (oh that would be sweet). Really, my main concern with this stuff is easy administration on a large volume of servers/workstations without having to use something like cfengine (eeek).
    • damn, beat me to it.
    • Okay, the serious answer is that yes, 'a' registry would be a very useful thing - just not implemented in a half-assed, non-secure, non-manageable manner ala Windows.

      So, we make it a nicely-formatted XML text file, obviously.

      Each user should be able to access only their portion of the file.

      Each application can access only their portion of the file, and are _signed_ (by the system) as to what changed what and when.

      The amount of changes backed-up could be left to the user or sysad when the file is changed
      • GConf [gnome.org] anyone? Only less per-user oriented and more system-wide oriented?
      • The user registry should be in the user's home directory.

        And do you know how disorganized a single file can get? Much more than a single directory, that's for sure. I like having a separate config file for things because file system operations are so much easier to handle than text editing alone.

        Some of you might find /etc messy, but I think it's a flowerbed compared to the jungle that is the Windows registry.

        • Re:I got an ... _angle_ (Score:3, Informative)

          by MeanMF ( 631837 ) *
          The user registry should be in the user's home directory.

          Ever wonder what that NTUSER.DAT file in your home directory is?
          • That's not what the statement is about. When the GP states,

            Each user should be able to access only their portion of the file.

            he is implying that everything is kept in the central registry, when clearly this should not be. Such things also require semantics that are only in Reiser4.

            • Re:I got an ... _angle_ (Score:4, Informative)

              by Foolhardy ( 664051 ) <csmith32@gmai l . com> on Saturday March 19, 2005 @01:06AM (#11982782)
              The only things centralized about the registry are that it has a single database server that does the actual file writes while providing a high level API, and it has a single-root hierarchy.
              Data in the registry is stored in hives mounted at various places in the registry's hierarchy. The registry's root is a key named \REGISTRY in the Object Manager [windowsitpro.com]'s namespace. Win32 confuses things a little by renaming \REGISTRY\MACHINE to HKEY_LOCAL_MACHINE and \REGISTRY\USER to HKEY_USERS, and providing some pseudo keys, like for the current user, but the idea is the same. The RegLoadKey [microsoft.com], RegUnLoadKey [microsoft.com] and RegSaveKey [microsoft.com] functions can be used to dynamically mount, unmount and copy hives in the registry. The key \REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control \hivelist [microsoft.com] contains a list of all the hives to be automatically mounted at startup. Go ahead, divide the registry into as many hives as you want, and put them where ever you want.

              What I'm trying to say is that the registry is no more centralized than the VFS is in Linux. The registry consists of various hives mounted at different locations, just like the VFS consists of various filesystems mounted at different locations.

              As for messyness, is this due to the structure of the registry itself, or Microsoft's usage of it: do you really think that if Windows used an /etc it would be any better documented or organized?
              Personally, I don't think the layout is all that bad.

      • Re:I got an ... _angle_ (Score:4, Insightful)

        by BrynM ( 217883 ) * on Friday March 18, 2005 @06:38PM (#11980861) Homepage Journal
        So, we make it a nicely-formatted XML text file, obviously.
        This sounds dangerous to me. Suppose and RPM writes a garbled line to the file by mistake. That could hose every app on the system. Don't get me wrong - a single file is a good idea, but it would take quite a bit of error checking for me to trust it.

        When it comes down to it, I would prefer some heirarchal system. I think the habit of some apps (like Apache) having their conf files in a subdirectory of /etc might be a good way to go.

      • Re:I got an ... _angle_ (Score:5, Insightful)

        by tzanger ( 1575 ) on Friday March 18, 2005 @06:59PM (#11981028) Homepage

        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.

      • Sounds like a good idea, but of course the point of GNU/Linux is that it is not one product but a zillion products that you glue together to make a computer. So how do you make something new a standard for a zillion applications?

        Do the KDA and Gnome people have any insight? How do they make people conform to their standards?

        All that can, I guess, be done is for someone to implement a registry framework (including lots of tools to manipulate it for people, and a dev kit to make it trivial to build into you
      • "non-secure"

        How is the registry non-secure? Registry keys have the same privelage options as items in the filesystem under Windows.

      • Re:I got an ... _angle_ (Score:3, Insightful)

        by Anonymous Coward

        Uhm, are you joking? What you describe has already been invented, it's called "the filesystem".

        So, we make it a nicely-formatted XML text file, obviously.

        This is the "joke" part. Let's ignore it.

        Each user should be able to access only their portion of the file.

        Unix filesystem permissions? Check.

        Each application can access only their portion of the file,

        Open only the files you need? Check.

        and are _signed_ (by the system) as to what changed what and when.

        Not 100% sure what you mean (ho

        • Why reinvent the wheel?

          Congrats! Great minds indeed think alike. You've just re-invented Elektra. Read the original article. (-: Seriously! Go read it! You'll laugh at how similar Elektra is.

          The only exception is that it might be nice to have XML metadata throughout the hierarchy for optional type-checking, etc. by automated tools.
      • Instead of having nested XML tags, we could use directories and text files! Oh, wait...
      • So, we make it a nicely-formatted XML text file, obviously. Each user should be able to access only their portion of the file.

        This would require a bunch of new software and a config daemon running all the time. This daemon would be an additional single point of failure or possible attack vector. It would also eliminate the possibility of manual repair should something go completely awry.

        The Elektra folks already though about the whole XML approach and they've described quite nicely why it isn't such a
      • Okay, the serious answer is that yes, 'a' registry would be a very useful thing - just not implemented in a half-assed, non-secure, non-manageable manner ala Windows.

        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

      • Re:I got an ... _angle_ (Score:3, Interesting)

        by klui ( 457783 )
        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

  • Simple (Score:3, Insightful)

    by ambrosen ( 176977 ) on Friday March 18, 2005 @05:57PM (#11980592) Homepage
    /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.

  • A simple request (Score:3, Insightful)

    by HotNeedleOfInquiry ( 598897 ) on Friday March 18, 2005 @06:00PM (#11980605)
    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.

    I'd be very grateful for nothing more than a README file, in /etc, for each application and service that tells what the files are named and what they do. Is that so much to ask?

    • Re:A simple request (Score:4, Insightful)

      by jon787 ( 512497 ) on Friday March 18, 2005 @06:04PM (#11980640) Homepage Journal
      A well commented config file with inline examples is even better. Sure they might end up being 10x longer than necessary, but they are readable.

      • Re:A simple request (Score:3, Insightful)

        by Curtman ( 556920 )
        A well commented config file with inline examples is even better.

        I don't see the problem with the man pages. Except when they are non-obvious. But anything that simply doesn't have one should be filed as a bug IMHO.
      • A well commented config file with inline examples is even better.

        A GUI admin interface with all options, possible values, descriptions, and examples sourced from XML meta-data is even better.

        Elektra now! (: .. Plus optional XML meta-data in the config hierarchy so we can make our lives easier with modern admin tools.

        http://elektra.sf.net
    • I'd be very grateful for nothing more than a README file, in /etc, for each application and service that tells what the files are named and what they do. Is that so much to ask?


      try this out for size:

      'man -k foo'

      and then try these:
      /usr/share/doc
      /usr/share/examples
      /usr/local/share/doc
      /usr/local/share/examples

  • I use et al (Score:5, Funny)

    by christopherfinke ( 608750 ) <chris@efinke.com> on Friday March 18, 2005 @06:03PM (#11980631) Homepage Journal
    Have you ever thought of using et al instead of etc?

  • so.. clearing the mess.. (Score:4, Interesting)

    by gl4ss ( 559668 ) on Friday March 18, 2005 @06:03PM (#11980633) Homepage Journal
    to clear /etc/ you would create another one that would need programmers to comply to that?

    wouldn't it be actually easier to get them to place stuff in /etc/ so that they're logically placed and findable?

    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 /etc/blaablaa? no. it's hell a lot better than registry still and at least I got SOME idea where the config file is.
    • to clear /etc/ you would create another one that would need programmers to comply to that?

      Elektra-style configuration could easily be phased in over time. That's part of the beauty and simplicity of it.

      wouldn't it be actually easier to get them to place stuff in /etc/ so that they're logically placed and findable?

      It wouldn't solve the problem -- which is that it takes too much time and effort to administer a system using today's /etc mess. It has very little to do with logical /etc organization. It

  • This is just how OSS is... (Score:5, Interesting)

    by JacquesPinette84 ( 547156 ) <jacques.pinette@g m a i l.com> on Friday March 18, 2005 @06:11PM (#11980683) Homepage
    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.
    • The sentence "OSS is about choices" is generally used to say that the users can choose between several alternatives.
      Here the users have the choice between having a messy architecture.

      OSS is about having to deal with a constant lack of consistency :)

    • Re:This is just how OSS is... (Score:4, Insightful)

      by Ogerman ( 136333 ) on Friday March 18, 2005 @11:34PM (#11982436)
      OSS is about choises, and /etc really highlights this. People have different ideas on how apps should be configured

      OSS is about choices. But not all choices bring value to the community. As a long time Linux admin, I can tell you that peoples' different ideas on how apps should be configured does NOT bring any value whatsoever to Open Source. It does quite the opposite. We absolutely must find a compromise and bring sanity to the situation.

      So far, Elektra is the best compromise. It doesn't require any new tools. It doesn't require any drastic changes in most software. It doesn't create any single points of failure. It retains the human readable and human editable nature of /etc. It makes security more granular. And most importantly, it opens the door for a new generation of GUI admin tools that will make Unix administration accessible to the masses of existing Windows admins who don't have time to re-learn everything they know. Of course, it'll also improve the lives of seasoned Unix admins as well. At least those who value their time..

      Elektra + XML meta-data now! (:

  • I have the answer (Score:4, Funny)

    by HawkingMattress ( 588824 ) on Friday March 18, 2005 @06:15PM (#11980705)
    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 !"/>
    • 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
      • I vote for com.example.app.plist files

        It's an improvement, but Elektra plus optional XML meta-data is much more powerful and flexible. Forget new APIs and use our trusty filesystems instead.. it makes perfect sense. Seriously.. head over to http://elektra.sf.net and read all about it! (:

  • How about changing the GPL? (Score:3, Funny)

    by WebHostingGuy ( 825421 ) on Friday March 18, 2005 @06:31PM (#11980806) Homepage Journal
    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...

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Friday March 18, 2005 @06:39PM (#11980870)
    Comment removed based on user account deletion

    • Re:Messes are inevitable (Score:5, Informative)

      by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Friday March 18, 2005 @07:12PM (#11981115) Homepage Journal
      I agree, with the exception that I think XML is infinitely preferable to some of the hand-rolled workalikes I've seen, and you can use a standard set of tools to parse any particular XML file sitting around.

      What's the conceptual differences between

      [TopSection]
      Setting1 = true
      Setting2 = yes
      Setting3 = no
      Setting4 = false
      and
      <section name="Top">
      <Setting1>true</Setting1>
      <Setting2>true</Setting2>
      <Setting3>false</Setting3>
      <Setting4>false</Setting4>
      </section>
      except that the latter can be browsed and edited with any editor that understands XML (as opposed to only Vim with the file-format-specific highlighter), can be deterministically validated by generic tools, and doesn't require the program's author to implement his own configuration file parser?

      XML isn't a perfect fit everywhere, but /etc is one of the places I think it works brilliantly.

      • Re:Messes are inevitable (Score:5, Insightful)

        by walt-sjc ( 145127 ) on Friday March 18, 2005 @07:32PM (#11981231)
        One is clean and readable, the other wordy and cluttered. I hate xml config files. I don't WANT to be forced to use some bizzaro XML editor, or deal with manually edited XML.
        • This isn't flamebait, it's a good point. xml files are cluttered with tags (I might add the tags are usually longer than the data they hold). Standard ini-style files are easily editable by notepad without hassle, and it would be very easy to design an editor for them if people wanted one.
          • XML is the wrong approach, partly for the reason you mentioned. Head over to Elektra's website, http://elektra.sf.net and find out why their idea is so much better than both /etc and XML alternatives.

            Now one thing you must consider, however, is that XML meta-data would be a good thing. It would allow you to edit your flat files in an Elektra hierarchy any way you wish, but it would also allow for rich, self-describing config trees easily managable with a rich GUI admin tools.
      • If you can't see the difference between the two you have done to much html editing. The first is human readable, the second is not. Yeah yeah I know it is "readable" but come on.

        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 subdi

        • 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.

          I fully agree. Head on over to Elektra's website, http://elektra.sf.net, and ponder the alternative of breaking configuration down into a standard file hierarchy much like /proc or /sys.

          And it would be trivial to re-combine everything into a single list for rapid text editing.. just traverse the tree. I'll bet an editor for this would be mere weekend project in Perl.

          Elektra + optional XML me

      • Re:Messes are inevitable (Score:5, Insightful)

        by Anonymous Coward on Friday March 18, 2005 @08:12PM (#11981462)
        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.
      • The difference is that I've written a error-checking, error-reporting parser and an easy to use interface for the first format in less than 50 lines c++.
      • The first example has been used by tens of thousands of programs (granted, most are for Windows), is extremely human readable to even the computer illiterate, and is rather straightforward to deal with programmatically. The second is xml.

      • Re:Messes are inevitable (Score:3, Interesting)

        by anpe ( 217106 )
        You might want to read Esr's Art of Unix Programming, specially chapter 5 on data formats [faqs.org]
        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.
    • Leave /etc as it is. It works. It's done the right job now for coming on 30 years.

      It works. It's far better than Windows registry. But it can be improved and this is what the Elektra project mentioned in the topic is all about. Unfortunately, it appears that nobody posting to this thread has actually read about the idea. (as usual.. skip the article and jump into a flamewar) Everyone just assumes the only alternative to /etc is some sorta hideous XML jungle.. or a special daemon reliant mess like GCon
  • ./configure --prefix=/usr/local/-
    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 /usr/local/kerberos and all packages pertaining to postfix are in /usr/local/postfix who cares?

    Besides, most people don't follow conventions anyway, how much stuff is in /etc/ instead of /usr/local/etc/ anyway?
    • "Besides, most people don't follow conventions anyway"

      I think you have identified the source of the problem.

      Quips aside, When I was a boy the creator of the OS defined what went into /bin, /usr/bin, and so on. The administrator of the machine put stuff into /usr/local. This way when something broke you had a nice way of finding out who to blame.

      People have forgotten, never knew, or just don't care about stuff like that anymore. We all pay the price. Recently, I downloaded an OSS binary package (with

  • One idea, no really (Score:2, Interesting)

    by mugnyte ( 203225 )
    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
  • 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.

  • The good, the bad, and the ugly (Score:4, Interesting)

    by gseidman ( 97 ) <gss+sdot@nOSPaM.anthropohedron.net> on Friday March 18, 2005 @07:02PM (#11981054)
    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.

    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 /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:

    1) Printing services are managed by CUPS.
    2) To start and stop printing services, I need to run /etc/init.d/cupsys
    3) If that doesn't work properly, the process to kill is named cupsd.
    4) The config file for specific printers for CUPS is /etc/cups/printers.conf
    5) The config file for the cups service as a whole is /etc/cups/cupsd.conf
    6) To manage most things about CUPS (though not browsing and sharing), I don't really want to touch the files in /etc/cups but, rather, connect to http://localhost:631/ with a web browser.

    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 /etc/cups, but I never do.
    3) If I really need to manually start and stop printing services I use /System/Library/StartupItems/PrintingServices/Prin tingServices, but I never do.
    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 /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

    • 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.

      SuSE Yast does all this.

      Give me the Windows services manager (with a console equivalent) with the ability to see through what interfaces (e.g. ports) that ser
    • 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.

      Are you aware of netstat -anp as root?

      chkconfig fulfills a lot of your later wants too.

      I'm happy using those tools, if you want to write a front end UI, feel fre
  • The /etc can be replaced with smitty. Heck the config files themselves can be databasen, or in a database, or (gasp!) registry.

    All that is the windowsizeation of unix. The whole mess of /etc comes from the unparalleled freedom developers enjoy on unix in the first place, no placing intricate structures in some central registry.

    The real mess is the difference between /etc, /etc/app.conf/, /usr/local/etc, /opt/etc, /var/etc, ~/.app/etc.... etc etc

    Proper hier structures dictate that apps installed as a part
  • 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

  • as usual, complexity is the problem (Score:4, Insightful)

    by Anonymous Coward on Friday March 18, 2005 @07:38PM (#11981269)
    * 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.

    * 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 /etc.

    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 /bin/sh and basic Unix tools are present.

    * 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 /config or something, but we're kinda stuck with it I think.

    So in conclusion, /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.

    And please, no XML!
    • Here is something else to think about. Each small file, even if it contains no data, takes up a standard chunk of disk space.

      Filesystems are designed to store things on disk, they are not meant to efficiently store and retrieve (key, value) pairs. That is what a database is for. Databases also have to deal with disk storage, and they do that through the filesystem in an intelligent way. However, their functionality is WAY more complicated than simply makinga file for each key/value pair.

      Finally, as a bus
    • Well written and argued.

      But how would you design Apache's config format to be simple and still retain the same amount of flexibility?

  • Linux turns newbies into programmers (Score:3, Interesting)

    by Ridgelift ( 228977 ) on Friday March 18, 2005 @07:47PM (#11981304)
    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.

    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 /etc the way it is. It might be a mess, but the alternatives are worse.

  • /etc is a mess? (Score:2, Insightful)

    by ConceptJunkie ( 24823 )
    There's something that's much better. It's called "\Documents and Settings".

    Very organized, consistent, and above all easy to understand.

  • 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 fi

  • 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 compatibilit
  • I think the poster wants something like the windows registry. Fair enough. Windows registy is were all programs store their settings and seems to work. Except wait. No it doesn't. Windows registry is so easy that to store a 1 you really got to write x000001 or something. Yeah that is noob friendly. Also many programs especially games use both the registry AND .ini or .cfg files. Some games even use multiple AND put them sometimes in the game install dir and sometimes under the Home dir of the user. Document
  • What is missing is an automated versioning of everything in /etc

    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 /etc as free wild as it is, but! put the whole directory under a filesystem based revision control like http://www.ext3cow.com/
  • 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 /

    • Re:NO XML! (Score:3, Interesting)

      by kwerle ( 39371 )
      You people who have been suggesting XML have no idea what the deficiencies of XML are.

      Please enumerate them. I recommend something like
      <ol>
      <li>first</li>
      <li>second</li>
      <li> t hird</li>
      </ol>

      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?

      It's a shlib. It's in memory already. Get over it.

      Or do you want some dependency on an XML library in
  • 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 doe

  • Use the filesystem! (Score:5, Insightful)

    by spitzak ( 4019 ) on Friday March 18, 2005 @10:54PM (#11982262) Homepage
    How many times do people have to come up with crazy ideas like XML and Registries or even elektra.

    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 /configuration/foo/bar/baz. Read the contents of the file. DONE!

    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 .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.

    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?
    • YOU DO NOT NEED ANYTHING ELSE!

      Except, of course, the requirement that may no longer use any old file system. When you use one inode per key, you're going to quickly run out of inodes. Especially when you've made your root filesystem tiny. You can, of course, use a really small inode size for the root filesystem, but that's going to affect everything else in the filesystem. To avoid wasting huge amounts of space, you're going to have to make your inodes ridiculously tiny. And even after I do that, what's t

    • 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?

      Sounds interesting, but editing a program's configuration would be a royal pain in the ass with this system. Right now, I can open the conf file, browse through it, read the commentaries and change what needs to be changed. With your proposal, I would have to open a new file for each setting, plus one for the commentary. Unless, of course, there is a special
  • We need APIs for accessing configuration data instead of relying on static file locations. That leaves programmers free to change the locations and formats of files in the future without breaking compatibility. And it leaves distros free to put the files wherever they want. And it allows standard tools and installers to find and update the configuration data. While still preserving the ability for sysadmins to manually edit the files.

    Then you can make some simple command-line tools would make it easy

  • Koan (Score:3, Funny)

    by nathanh ( 1214 ) on Saturday March 19, 2005 @01:16AM (#11982812) Homepage

    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.

  • Why I don't have a problem with /etc (Score:4, Insightful)

    by phaze3000 ( 204500 ) on Saturday March 19, 2005 @03:47AM (#11983215) Homepage
    Personally, I don't consider /etc to be a problem. /etc is a directory to be edited by the system administrator, and as a system administrator, one should damn well know what one is doing editing config files. End users shouldn't have to touch these files.

    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.

  • My view... (Score:4, Insightful)

    by agraupe ( 769778 ) on Saturday March 19, 2005 @09:13AM (#11984029) Journal
    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.

Slashdot Top Deals

To be awake is to be alive. -- Henry David Thoreau, in "Walden"

Close