Apache DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


Apache Cookbook

A Day in the Life of #Apache
Enabling and Disabling Apache Modules

by Rich Bowen, coauthor of Apache Cookbook
02/26/2004

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 irc.freenode.net IRC 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

Day Three

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.

Related Reading

Apache Cookbook
By Ken Coar, Rich Bowen

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

Since 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 a # 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 about it. 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 about it.

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

mod_mime: Allows you to serve files of types other than plain text files.

mod_log_config: You really shouldn't run a web site without log files.

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? Add 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 AddType 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.


Return to the Apache DevCenter.



Sponsored by: