Home arrow Apache arrow Page 4 - Building Apache the Way You Want It

Enabling or Disabling Modules in Bulk - Apache

Have you ever wanted to customize Apache? This article will help you get started on building a customized version of Apache to suit your own needs. It is taken from chapter three of the book Pro Apache third edition, written by Peter Wainwright (Apress, 2004; ISBN: 1590593006).

TABLE OF CONTENTS:
  1. Building Apache the Way You Want It
  2. Building Apache from Source
  3. General Options
  4. Enabling or Disabling Modules in Bulk
  5. Changing the Module Order (Apache 1.3)
  6. Building Apache from Source As an RPM (Apache 2)
  7. Advanced Configuration
  8. Determining Apacheís Locations Individually
  9. Choosing a MultiProcessing Module (Apache 2)
  10. Building Apache with suExec support
  11. Configuring Apache 2 for Cross-Platform Builds
  12. Configuring the Build Environment
  13. Building Modules with apxs
By: Apress Publishing
Rating: starstarstarstarstar / 14
August 18, 2005

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

The --enable-module option of Apache 1.3 and the --enable-modules option of Apache 2 have in common two special arguments that allow you to specify a larger group of modules without listing them explicitly:

  • most expands the default list to include a larger selection of the modules available.

  • all goes further and builds all modules that arenít experimental or otherwise treated specially.

Tables 3-2 and 3-3 contrast the modules that are built at the default, most, and all levels, for Apache 1.3 and Apache 2, respectively. Each column adds to the previous one, so the All column contains only those modules that are additional to most. The Explicitly Enabled column details all modules that arenít included unless explicitly enabled, along with a subheading detailing why.

Some experimental modules are likely to be added to the list of All modules at some point in the future; in Apache 2 this includes mod_file_cache, mod_proxy, and mod_cache. These modules have been listed under Additional rather than Experimental in the Explicitly Enabled column to differentiate them from truly experimental or demonstration modules such as mod_example, which should never be encountered in a production-server environment.

Table 3-2 is the list for Apache 1.3.

Table 3-2. Apache 1.3 Included Modules

Default

Most

All

Explicitly Enabled

mod_access

mod_auth_anon

mod_mmap_static

mod_auth_digest

mod_actions

mod_auth_db

(mod_so)

mod_alias

mod_auth_dbm

Obsolete:

mod_asis

mod_cern_meta

mod_auth_db

mod_auth

mod_digest

mod_log_agent

mod_autoindex

mod_expires

mod_log_referer

mod_cgi

mod_headers

Example and Experimental

mod_dir

mod_info

mod_example

mod_env

mod_mime_magic

mod_imap

mod_proxy

mod_include

mod_rewrite

mod_log_config

mod_speling

mod_mime

mod_unique_id

mod_negotiation

mod_usertrack

mod_setenvif

mod_vhost_alias

(mod_so)

mod_status

mod_auth_db is deprecated in favor of mod_auth_dbm, which now also handles Berkeley DB. mod_log_referer and mod_log_agent are deprecated in favor of mod_log_confug. mod_so is automatically enabled if any other module is dynamic; otherwise, it must be enabled explicitly in Apache 1.3 (Apache 2 always enables it even if all modules are static). mod_mmap_static is technically experimental but stable in practice. mod_auth_digest replaces mod_digest; only one of them may be built.

Table 3-3 is the corresponding list for Apache 2. 

Table 3-3. Apache 2 Included Modules 

Default

Most

All

Explicitly Enabled

mod_access

mod_auth_anon

mod_cern_meta

mod_cache

mod_actions

mod_auth_dbm

mod_mime_magic

mod_disk_cache

mod_alias

mod_auth_digest

mod_unique_id

mod_mem_cache

mod_asis

mod_dav

mod_usertrack

mod_charset_lite

mod_auth

mod_dav_fs

mod_deflate

mod_autoindex

mod_expires

mod_ext_filter

mod_cgi/mod_cgid

mod_headers

mod_file_cache

mod_dir

mod_info

mod_isapi (Windows only)

(Continued)

Table 3-3. Apache 2 Included Modules (Continued)  

Default

Most

All

Explicitly Enabled

mod_env

mod_rewrite

mod_ldap

mod_http

mod_auth_ldap

mod_imap

mod_logio

mod_include

mod_proxy

mod_log_config

mod_proxy_connect

mod_mime

mod_proxy_ftp

mod_negotiation

mod_proxy_http

mod_setenvif

mod_ssl

mod_so

mod_suexec

mod_status

Example and Experimental:

mod_userdir

mod_bucketeer

mod_case_filter

mod_case_filter_in

mod_echo

mod_example

mod_optional_hook_export

mod_optional_hook_import

mod_optional_fn_import

mod_optional_fn_export

Either mod_cgid or mod_cgi is built automatically depending on whether the chosen MPM is threaded. Modules shown indented depend on the module before them; that is, mod_mem_cache requires mod_cache.mod_logio requires mod_log_config.mod_deflate and mod_ssl require external libraries to be built; mod_file_cache, mod_cache, and mod_proxy may migrate to the all list in time. mod_http provides basic HTTP support; it may be removed for those intending to use Apache as a framework for a generic protocol server, but should be kept in general use.

Options concatenate so you can specify both general and specific options together to get the mix of modules you want with the minimum of effort. For example, in Apache 1.3, you can specify this:

[1.3] $ ./configure --enable-module=most --enable-module=rewrite
[1.3] $ ./configure --enable-module=all --disable-module=rewrite --disable-module=so

or in Apache 2, you can specify this:

[2.0] $ ./configure --enable-modules=most --enable-rewrite
[2.0] $ ./configure --enable-modules=all --disable-rewrite --disable-so

Deciding what to include and exclude is made simpler if you choose to build a dynamic server because, as I mentioned earlier, you can simply choose to build all the modules and sort them out later. Once the server is installed, you can then comment out the directives in the configuration for the modules you donít want. This only breaks down if a module canít be built dynamically or you want to explicitly disable mod_so (because by definition it canít be dynamic and load itself ). If you change your mind later, you just uncomment the relevant directives and restart Apache.

Building Apache As a Dynamic Server

Building Apache as a purely dynamic server is almost as simple as building it as a static server, though the options again differ between Apache 1.3 and Apache 2. The approach taken also differs subtly. In Apache 1.3, you have to both enable a module and specify that itís to be built dynamically; neither implies the other, so if you specify that a module is dynamic without also enabling it, it wonít get built. In Apache 2, if you ask for it to be built dynamically, itíll also automatically be enabled, which is more reasonable.

The option to create modules dynamically in Apache 1.3 is --enable-shared. This takes the name of a module as an argument or the special value max, which takes the list of enabled modules and makes dynamic any of those modules that are capable of being loaded dynamically. The following is fairly typical of how the majority of Apache 1.3 servers are built:

[1.3] $ ./configure --enable-module=all --enable-shared=max

You could also have used most or left out the --enable-module option if you wanted fewer modules compiled. max operates on the result of the combination of all the --enable-module options you specify; it doesnít imply a particular set of modules in and of itself.

Apache 2 does away with separate options and instead provides a single combined option, --enable-mods-shared, which both enables and makes dynamic the module or list of modules you specify. As with --enable-modules, you can also specify most or all. The equivalent to the previous command in Apache 2 is this:

[2.0] $ ./configure --enable-mods-shared=all

More interestingly, you can also keep Apache a primarily static server but make one or two modules dynamic, or vice versa, so you can have the best of both worlds. This allows you to take advantage of the slightly increased performance benefits of binding a module statically into the server but at the same time keeping optional features external to the server so that they can be removed to make Apache more lightweight without it.

For example, mod_rewrite is very powerful, but itís large, so if youíre not sure whether youíll actually be using it, you can only make it dynamic with this (depending on what else youíve enabled):

[1.3] $ ./configure --enable-module=all --enable-shared=rewrite
[1.3] $ ./configure --enable-module=most
        --enable-module=rewrite --enable-shared=rewrite

You donít need to enable mod_rewrite explicitly in the first example because itís covered by all. Otherwise, you need to add an --enable-module=rewrite as well. Apache 1.3 doesnít build it by default.

The equivalent for Apache 2 is this:

[2.0] $ ./configure --enable-modules=all --enable-mods-shared=rewrite,...
[2.0] $ ./configure --enable-modules=most --enable-mods-shared=rewrite,...

Interestingly, you can also make a module shared by giving the --enable option the value shared, so you could also have said this:

[2.0] $ ./configure --enable-modules=all --enable-rewrite=shared ...

Even if you choose to build Apache statically, you can still include the mod_so module to allow dynamically loaded modules to be added to the server later. In Apache 1.3 you do this by enabling all modules (which includes mod_so), making any module dynamic, or explicitly add mod_so with this:

[1.3] $ ./configure --enable-module=so ...

Conversely, Apache 2 automatically includes mod_so even in a fully static server. If you donít want it, you must explicitly disable it using any of these:

[2.0] $ ./configure --disable-so ...
[2.0] $ ./configure --enable-so=no ...
[2.0] $ ./configure --disable-module=so,... ...

Alternatively, you can build a mostly dynamic server with one or two modules built statically. Itís rare that you wouldnít want mod_access or mod_mime not built into the server, so you can make them static with this:

[1.3] $ ./configure --enable-module=all --enable-shared=all --disable-shared=access
             --disable-shared=mime

To do the same for Apache 2, you make use of the last argument you can give to an --enable option: static. This is the only way to reverse the status of a module from dynamic back to built-in because there are no such options as --disable-mods-shared or --enable-mods-static in Apache 2 (at least not currently):

[2.0] $ ./configure --enable-modules=all --enable-access=static
                  --enable-mime=static

When Apache is built from this configuration, it automatically inserts the directives to load dynamic modules, saving you the trouble of doing it yourself. It is, therefore, convenient to build modules even if you donít really need them. You can comment out the enabling directives and uncomment them later should you change your mind.



 
 
>>> More Apache Articles          >>> More By Apress Publishing
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

APACHE ARTICLES

- Apache Unveils Cassandra 1.2
- Apache on ARM Chips? Dell and Calxeda Help M...
- The Down Side of Open Source Software
- VMware Unveils Serengeti for Apache Hadoop
- SAP Takes Steps to Improve Hadoop Integration
- Looking to Hone Apache Hadoop Skills?
- How to Install Joomla on WAMPP
- Working with XAMPP and Wordpress
- GUI Available for Apache Camel
- Reduce Server Load for Apache and PHP Websit...
- Creating a VAMP (Vista, Apache, MySQL, PHP) ...
- Putting Apache in Jail
- Containing Intrusions in Apache
- Server Limits for Apache Security
- Setting Permissions in Apache

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: