The basic, non-partisan answer, goes something like this. Distributions evolve over time. Their goal is often to allow you easy package management, simple configuration, and good integration, for a myriad of tools which have little or no association with each other. In order to accomplish this, they attempt to abstract things into manageable chunks which are scripting-friendly. This philosiphy applies equally well to the base system, as to individual package config file setup and placement. Consider the following thought experiment.
You're going to install package Foo, a control package for a network appliance of some sort. In the installer / configurator / defaults, it has been requested that Foo:
1) Start at boot up
2) Add an entry to the Gnome Applications menu
3) Create an alternate interface on your primary network card
4) Create a static route to it's remote device on that network card
In order to accomplish this in a minimilast distro (say, Slackware, for example), the package would probably provide short instructions at the end of the installation, or perhaps in the INSTALL file, describing what changes should be made where, in order for the package to function. In more full-service distros, ala RedHat, Mandrake, Debian, etc it would be preferred for those actions to happen automagically. To automate them with the way Slack has things laid out would require very cumbersome and error-prone scripted parsing and editing of configuartion files. If you recall back to the `linuxconf` days, this is very error prone. If done poorly, it can cause all kinds of trouble, ranging from blowing up your entire configuration file, stripping all of the comments, or dropping just that important setting you made yesterday.
So, how best to solve this problem? One way (the traditional RedHat way) is to break the configuration files down into configuration *directories*, which are parsed by a configuration file. The config file simply says, look into that directory over there, and parse every file as config entries in order. This allows automated systems to easily add reliably and remove bits of the configuration, with out fear of messing up other aspects of the config. It's a very simple, elegant solution to an otherwise rather complicated problem.
As you pointed out, distributions even vary internally over time. RH has gradually broken apart more and more things, in their continued quest to provide better automated configuration. With the current setup in RHAS, you can add your static routes to one interface, and have them come and go with that interface. A good example is a firewall, with a dedicated dialup to a remote location for emergency connectivity situations. Normal routing to RemoteLocationA goes over the "big pipe". Bring up that ppp0 interface via the simple "ifup ppp0", and up with it comes the static route to RemoteLocationA over the dialup link - nothing behind the firewall needs to change, and it works intelligently as it should.
Hopefully that's a thorough explanation that doesn't bore anyone too much. :) As Mike M. pointed out (while I was typing this up), much good discussion (and many heated arguments) can be had over topics like this. I often end up debating amongst my close circle of friends the merits and disadvantages of these configuration styles, though so often I'm just "out numbered". :) People often prefer one style to the other not for maintenance or configuration reasons, but simply because it's what they're comfortable with.
Aaron S. Joyner
Ryan Leathers wrote:
Hi all. I have wondered from time to time why configuration files are
located in one place or another, and why this location isn't more
consistent between ditributions.
Here is an example. In Redhat 9 static routes are stored in the file aptly named static-routes found under /etc/sysconfig. In RHAS 3 this same information is stored under /etc/sysconfig/networking/devices in an interface specific file like eth0.route
I can see the benefit of associating static routes to specific
interfaces, but why not just do that in one file? This isn't a big
deal, but if anyone knows WHY this was done I'd enjoy hearing the tale. I'm also just generally curious about how these kinds of decisions come
to be.
-- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
