Apache packages: creating a support vacuum Right at the end of OSCon in September, I got the opportunity to harangue Ubuntu's Mark Shuttleworth about the support vacuum distros such as his create. He didn't have an answer. OK, I was putting him on the spot, but I don't think he'd have done much better if he'd had notice of the question. Frankly, I don't think there is an …
The default Apache installation doesn't seem to follow the Linux Standard Base specification for filesystem hierarchy, so why expect distros to adhere to the defaults? There's also no suggested configuration file hierarchy for a virtual host setup. If apache would provide a good default for that it would probably mildly force the various distros to converge on that.
The apparent 'nonsense' is there to support what the apache source never has: automatically configured on install modules and the like. In, say, Debian land, it's not enough just having the main Apache package working out of the box, users also expect that installing php automatically enable the module, and installing squirrelmail adds the magic to enable them to use it out of the box.
And that's a bit of a bitch with a monolithic config file.
Apache's not the only package with this problem, the same war is raging over Exim4. Last I checked, the Debian package allowed you to choose between a monolithic config file, and one split into a lot of fragments (to allow, for instance, the mailman package to supply the fragment of configuration that it needs), which get assembled to a temporary config file when restarting the exim service.
As annoying it is to the hardcore Apache or Exim supporters, it's required to meet the needs that the distros fulfill in order to make the packages reach so many users as they have.
I don't see it as one side having to solve this problem, I think that distros and upstream supporters have to work together on it.
This is very true, more so of the Debian based distro's.
Exim is a worst case example I think in Debian. The Debian stuff is STILL at V3 which hasn't had any developer support for over four years. The devs even setup a separate maillist just to cover then and stop the main list getting drowned in V3 questions which people can hardly remember anymore.
It also doesn't help that alot of packages make up their own directory layout and can be difficult to place in other ways. and again the distro's have their own layout which they config the package into - eg package1 uses /usr/local/package1 by default; package2 uses /usr/local; distro one puts things in /usr, distro 2 puts things in /usr/sfw....
it's a mess and this needs sorting out not just for linux based systems for for the Unix world in general.
I agree the disparity in configuration structures is annoying, but it is there because the current default system does not scale well - or at least not as well as the alternatives.
Having been an Apache webserver administrator for some years, I originally rolled my own version, compiling from source every time a new point release came out with a critical bug fixed. after about the fourth time this got annoying, because I was essentially performing an inefficient "packaging" and "delivery" of something that my chosen distro (Debian) already did for me. Hence my switch earlier this year to using the version provided by Debian.
At that point I had maybe 60 virtual domains, all with their configurations stored in the httpd.conf file. If I wanted to remove one, I needed to edit the file and comment out a block of lines in order to turn it off. Now all I need to do is run a2dissite. I can do an "ls" on the /etc/apache2/sites-enabled to see at a glance what sites there are (I have a separate config file named after the virtual domain). I can provide write access for certain users to just their own configuration files for their site, and so on.
Basically, the Apache web server is a brilliant piece of software. Debian have, in my opinion, improved it's maintenance by 100% by reconfiguring the system to make it scaleable and maintainable.
IMHO, if you don't appreciate distros modifying the default configuration setup, then the only alternative is to make the default configuration setup better than any possible modifications - or take one of the current distro configurations and evangelise it to the rest of the distros as the "standard". A nice suite of maintenance tools would be good, too.
Cheers!
This brief article clearly does drawn on the long never ending trouble with the people who package the common sources that we all use and love.
Whilst I am a very avid user of Linux & OSS I often get frustrated with the differences between distributions. At some point some kind of agreement is going to have to be made or some more restrictions within licenses to structure is going to have to exist.
"OH but it's free software, we should have no restrictions!"
I'm no lawyer and I don't know all the GNU and various licenses off by heart but with regard distributions, they should be forbidden to muck around with standard configuration paths and location of libraries/docs with such global software such as Apache.
Whilst yes distrobutions require a huge diverse structure to fit itself, some of the small things feel free to move it around. But for example many years ago I was playing around with SuSE 7 (or something near it) and I found my htdocs root was in something like /src , surely that's just plain wrong?
But with the layer of abstraction currently being undertaken with config files and apache, it's just means it slows my ability to move freely between systems.
My choice of server is Gentoo, I love the portage tree (mostly) but over the last year things with apache just keep evolving and when it's where I choose to run apache all the time, when I come to use a webserver for example on my Laptop (Ubuntu). I've gotta spend some time just to get to grips with where it's saving all of it's config files for apache.
So really I think that we need some limitation on such changes and if people with distributions feel it really necessary that path changes exist. Then they should be getting in contact with the devs of the software and suggesting changes. Ballot and the like.
Otherwise we will never get a nice & flat standard linux fs tree.
Part of the problem is that Apache's default layout is not very convenient, IMHO. Everything: html, configuration, log files, is in one directory under '/usr/local/apache'.
I expect configuration files to be under '/etc', logs to be in '/var/log', etc. '/usr' should be mountable as read-only. This makes backup and user permissions much easier, etc. It cleanly separates files which never change, from one which change more often and need to be editable by different groups of people.
There are other factors too. You need to be able to cleanly install Apache 1.3 and 2.0 at the same time, since 2.0 is not just an upgrade. This also requires some naming changes.
If you check the Wiki link about the different distribution layouts, you'll see that all of them (except Windows) change the default layout to more or less what I am describing above. Perhaps Apache should change the documentation to reflect the established practices.
Good afternoon,
The second DebUbu maintainers decided to change the apache configuration topology, they chose (however unwillingly) to support those changes. You're not finding a "support vacuum", you're just finding lousy support. Live with it or switch distros.
Frank
First of all, the Linux Standards Base is a crock. It only exists in the first place to allow people to write closed-source software and expect it to be able to run on a GNU/Linux system. LSB is about putting certain files in certain places so pre-compiled binaries can find them where they were told, thereby removing the need for the user to have access to the source code for the purposes of compile-time configuration.
Ordinarily, you can put *any* file *anywhere* -- that's what the "configure" step of installing a generic .tar.gz package is all about. "configure" generates a makefile which instructs the compiler as to where various required files are located and where to put the compiled binaries and libraries. "make" actually builds the binaries and libraries, though it doesn't move anything to its eventual location. "make install" copies them to the location from which they will be run -- which is why this step must be performed as root, because this will be some location that ordinary users are not allowed to write.
Of course, if someone else has done the "configure" and "make" steps for you, leaving you to do "make install" -- or its equivalent; installing a pre-compiled binary packages (.rpm or .deb) has essentially the same effect as "make install" -- then the locations of certain files will be prescribed. Some standard is required against which pre-compiled packages can be expected to work. Hence, LSB.
Your distributor has already configured and compiled the source to create .rpms or .debs. They chose somewhere sensible to put the files, *which may not be the same place the package author chose*. In fact, there's a good chance it won't. By convention, under Linux, /usr/ is used by package managers -- and /usr/local/ is left for packages installed outside of any package management system. Files in /usr/ are liable to get stomped on. Almost any package you download in source form will by default install itself somewhere under /usr/local/, because that location is "safe" from interference. If you want it somewhere else, you have to say so.
Distributions typically want their pre-compiled packages to have binaries and libraries in /usr/ and their configuration files in /etc/, so they give appropriate parameters to configure. Even pre-compiled binaries from closed-source packages are often placed in /usr/local/ to protect them from package managers.
The Apache httpd server is a complex piece of software -- so complex that even its configuration system is itself configurable. Debian (for it is they who supply Ubuntu) have (IMHO) improved Apache's configuration system for the 2.0 release, by breaking up the old, monolithic configuration file into logical, "feature-sized" units. It takes some getting used to, if you've grown up with the "old" way, but it definitely makes sense.
Part of the problem is the way we've all got used to a very centralised culture, where local dealers don't modify manufacturers' products anymore. Once upon a time, all cars were shipped from the factory with a very basic specification, and garages would enhance each one to the buyer's preference. A modern-day consumer spirited back to those times would naturally tend to take up any problems with the car manufacturer, not the dealer who supplied it.
Open Source is a very de-centralised model, wherein everyone must take responsibility for their own actions. You shouldn't change anything unless you are prepared to document your changes.
This can't be fixed by Apache or the Distro alone, because it applies to every app installed on a box. They all need configuration files and they all have their own way of doing it. That's the problem, not the OS or the distro, but the MxN combination of the two.
The solution, I believe, is a "centralised" configuration manager, accessible by API. I don't want to use the Windows Registry as an example, but some sort of common interface allows these things to be edited via an app: "org.apache.apache.DocumentRoot = ..." - and for the results to wind up in a predicable location: /etc/conf/org/apache/apache.xml.
The location root could vary by OS or distro, but once it's known it applies to all applications. The result? The user can use one tool to configure all the applications installed on his machine. If they want to do it by hand, start at "/etc/conf" or wherever and they know exactly where to go.
I agree with the main point of the article - that having different structures in different distros is bad. The first distro I used in anger was RedHat 6, I took a dislike to it then and I still dislike it's arrangement of stuff !
These days I use Debian by choice, and I find their structure of Apache config files FAR superior to anything else I've seen. I still have to deal with RedHat derived systems (CentOS in an Asterisk@Home/TrixBox setup) and find dealing with the Apache config to be a right royal PITA.
As has already been pointed out, in Debian you get a /etc/apache or /etc/apache2 directory (so no confusion between configs for 1.3 or 2) with things neatly broken down in another layer below. I particularly like the Debian way of splitting out the configs for separate modules and separate virtual hosts into separate files - far superior to one huge file that's too easy to mangle !
So agree with others that say - let the distro and package maintainers have some dialog. In the case of Apache I believe the reason they have the problem is because the Apache default way of doing it isn't the best - they could learn from Debian.
I've been meaning for a long while now to write a general-purpose configuration management tool. I want to use a split-screen approach; radio buttons, tick boxes, text entries, drop-down selectors and the usual GUI requester stuff on the LHS, and an old-skool-looking text editor on the RHS (with maybe even a column of ~s to make it look *really* authentic .....) and as each side is updated, the other would reflect the changes. The idea being to show the relationship between changes made using a graphical configuration tool and the configuration file under /etc/ in the hope that maybe it will give people the confidence to take a text editor to their configuration files.
Of course, it's going to have to be extensible since configuration file formats are subject to change. I'm thinking in terms of having some sort of XML-style, meta-configuration file to hold the formats of the various configuration files that it will be able to edit. The alternative would be to use the programming language as its own generality-of-purpose abstraction layer and write separate programs for editing exim.conf, httpd.conf, my.cnf and so forth. That may not be as horribly inefficient as it looks; effectively it means writing a library which can then be used by several programs, so it would still be extensible.
Perhaps now I've announced my intention somewhere this public, I'll be sufficiently motivated to get on with doing it!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
