A Day in the Life of #Apache
by Rich Bowen, coauthor of
Editor's note: Rich Bowen tackles yet another common Apache dilemma in the latest installment in this series based on his conversations on the IRC channel, #apache. This week he delves into the sometimes confusing world of modules: when to enable them, when to disable them, and why.
#apache is an IRC channel that runs on the
network. To join this channel, you need to install an IRC client (XChat, MIRC,
and bitchx are several popular clients) and enter the following commands:
/server irc.freenode.net /join #apache
Today we'll see a less recipe-based topic. Whereas in the previous articles we had problems for which there was a standard canned answer (well, almost), this time we'll be talking about something that will vary greatly from one server to another and will require some experimentation and thinking.
The topic for today involves a moderately common error message, and a fairly
simple solution, as well as a somewhat deeper question that arises out of the solution. We join
#apache as a frustrated user is trying to exorcise her daemon of an annoying error message.
<greenberet> When I start Apache I get the following error message:
can't read magic file /etc/apache/share/magic
<greenberet> Can someone tell me how to make that error message go away, so that Apache will start?
<DrBacchus> fajita: can't read magic file
<fajita> Comment out the LoadModule line for mod_mime_magic, unless you think you are using that module for something.
<greenberet> OK, how would I know whether I'm using that module?
<DrBacchus> Well, if you don't know, then you're probably not using it. On the other hand, if that breaks something, you can always uncomment it again.
At this point,
greenberet disappears for a few moments, presumably making the change, and then reappears.
<greenberet> Great. Thanks. That solved it. But why?
<DrBacchus> You had a module enabled that was missing a needed file. And, since you're probably not using the file, the simplest solution is to just not enable the module.
<greenberet> Cool. So, are there other modules that I can get rid of too?
<greenberet> And, while we're at it, why was this one enabled by default if I'm not going to use it?
greenberet has cut straight to the heart of the matter, let's dig a little deeper here.
When you build Apache from source code, downloaded from http://httpd.apache.org/ (or, preferably, a mirror), certain modules are enabled by default, and certain other ones are not. The decision is made based on the notion that modules most people will need should be turned on by default, and those most people will not need should not. And, if you choose to do so, you can modify the modules that are built at compile time. Or you can choose to build them all.
When you install some binary distribution of Apache -- either an RPM, or a Debian package, or a Windows .MSI, or some other pre-built installation -- this decision is made for you. The package managers make decisions based on what they think are the most popular modules. Sometimes, they make decisions differently than the person packaging the Apache source code, and so the Apache installed on Debian, say, might have different modules enabled by default than the Apache installed on Red Hat.
However, by far the most common technique is to build all the modules as
shared objects, and then simply enable certain ones by putting
LoadModule lines in
httpd.conf to load those modules,
and leaving the
LoadModule lines commented out for others. This
way, you can go back and enable or disable modules by simply uncommenting, or
commenting, a line of the configuration file.
For example, in the default Debian configuration file, you'll see something like this:
# LoadModule anon_auth_module /usr/lib/apache/1.3/mod_auth_anon.so LoadModule imap_module /usr/lib/apache/1.3/mod_imap.so
This means that
mod_auth_anon will not be loaded, but
mod_imap will be loaded. If you wanted to prevent
mod_imap from loading, simply comment out that line; that is, put
# on the beginning of that line, and restart Apache.
So, once you know that, you might ask the logical next question, which is:
<greenberet> Cool. So, are there other modules that I can get rid of too?
And the answer is a resounding maybe!
This will vary from one server to another. The package managers don't willy-nilly enable modules, but enable those ones that they think most people will need. At least, that's the theory. But since every web site is different, some sites won't need some of those modules, and some sites will need other ones.
It should be noted here that some distributions of Apache, like the Debian distribution, tend to the conservative side, enabling pretty much the same modules that a default Apache source build will enable. Other distributions, like the Red Hat 9 distribution, enable just about everything just in case you might happen to want it some day.
There are two main reasons for disabling modules: security and performance.
The security angle on this is that if you're running a module you're not
actively using, you'll probably not notice when there's a security bulletin
mod_unique_id has a new security vulnerability in it?
Well, that doesn't sound familiar, so I won't bother going to get the patch.
But, lo and behold, there it is running on your server without you even knowing
The performance angle is more obvious. Modules take up memory. Things that consume more memory run more slowly. Eliminate modules, and things will run faster.
There are a few different techniques for identifying the modules that you don't need, and I'll look at two of them.
The first method is to pick out modules that look suspect, remove them, and
see if anything breaks. If it breaks put it back in. You might not want to do
this on a production server. Make the changes on a temporary copy of your
configuration file, and run
apachetcl configtest -f new-httpd.conf
to see if you got the syntax right. You can also start up Apache using the
-f flag and the temporary file, allowing you to switch between the
two quickly if something breaks.
httpd -f /etc/apache/new-httpd.conf
So, if I was to pick on the most common unnecessary modules, I think I'd have to go for these ones.
mod_imap: Lets you use server-side image maps. Server-side image maps,
you ask? That's right. Server-side image maps. Most of you have never even heard
of this feature, and that's because in about 1995, the Netscape browser came out
with client-side image maps, and nobody has used server-side image maps since
then. Nobody needs to be running this module.
mod_mime_magic: Sets MIME types on files based on the contents of the file rather than on the file extension. Pretty neat module, but hardly anyone
ever actually uses it.
mod_unique_id: Assigns a unique ID to each HTTP request for tracking
purposes. Again, a neat module, but not only is it seldom used, it also occasionally causes esoteric problems in default installations. I'll leave the details to another time, but in most cases you're better off just removing it.
I could go on, but, instead, I'll jump to the second technique, which is to
start from the ground and work up. What's the bare minimum you can get away
with? Well, to be completely minimalistic, you can remove all the modules, and
Apache will still run, but it might be a little limiting. (Pun about
mod_access omitted to conserve word count.) So I've whittled it
down to three modules that you can't live without. After that, the idea is to
add on those modules that you need, as you need them.
mod_dir: Maps requests for http://server/ to http://server/index.html
so that users can simply type a server name, rather than always having to know a
mod_mime: Allows you to serve files of types other than plain text
mod_log_config: You really shouldn't run a web site without log
From there, you can add modules as you need them. Of course, this might require that you actually read the documentation and find out what some of the modules do, but that shouldn't be too much of a hardship.
Need CGI programs? Add
mod_cgi. Want password authentication?
mod_auth. And so on, as needed. This can be a tedious process,
but it leaves you with a server that is as small as it can possibly be, without
the deadweight of modules you never use.
If your configuration file uses a directive from a module that is not loaded, you'll get an error message that says something like "directive misspelled or defined by a module not loaded." For a given directive, you can always look in the documentation and determine what module it is from. The very easiest way to do this is to ask fajita:
<DrBacchus> fajita: AddType
<fajita> i guess AddType is http://httpd.apache.org/docs-2.0/mod/mod_mime.html#addtype or http://httpd.apache.org/docs/mod/mod_mime.html#addtype
From that response, you can immediately see that the
directive is in the module
mod_mime. So if you don't have
mod_mime loaded, you'll get that error message. At that point
you'll need to determine whether to remove the directive, or add the module,
depending on whether you need that particular functionality.
Of course, if you aren't on IRC, you can look for the directive in the list of configuration directives and then look at the Module line in the description for that directive.
But everyone should be on IRC.
Stay tuned. Next month we'll present yet another solution to a common, or not so common, Apache problem.
Rich Bowen is a member of the Apache Software Foundation, working primarily on the documentation for the Apache Web Server. DrBacchus, Rich's handle on IRC, can be found on the web at www.drbacchus.com/journal.
O'Reilly & Associates recently released (November 2003) Apache Cookbook.
Sample Chapter 9, "Error Handling," is available free online.
For more information, or to order the book, click here.
Return to the Apache DevCenter.
Copyright © 2009 O'Reilly Media, Inc.