Apache Modules

There are a number of extremely popular modules for the Apache Web server that are not included in the basic distribution. Most of these are separate because of licensing or support reasons; some are not distributed by the Apache Software Foundation because of a decision by the Apache developers; and some are integral parts of other projects. For instance, mod_ssl for Apache 1.3 is developed and maintained separately, not only because of the U.S. export control laws (which were more restrictive when the package was originally developed), but also because it requires changes to the core software that the Apache developers chose not to integrate.

The most comprehensive list of third-party modules can be found in the Apache Module Registry at http://modules.apache.org. Some modules like mod rewrite are so popular that they have entire sites devoted to them.

Current Linux distributions include most popular modules for Apache.

Installing a Generic Third-Party Module

Move to the directory where the module's source file was unpacked, and then:

% /path/to/apache/ bin/apxs -cia  module.c 

In the case of a third-party module that consists of a single .c file, there is a good chance that it can be built and installed using this approach. Modules that involve multiple source files should provide their own installation instructions.

The -cia  options mean to compile, install, and activate. The first is pretty straightforward; install means put the .so file in the place Apache expects to find it; and activate means to add the module to the httpd.conf file. See Also apxs manpage

NEWS CONTENTS

• 210210 : mod rewrite ( softpanorama.org, )
• 210210 : mod_authn_pam - Apache HTTP Server ( mod_authn_pam - Apache HTTP Server, )
• 210210 : ONLamp.com Apache Modules ( 09/27/2001 )
• 210210 : Recipe 2.1. Installing a Generic Third-Party Module ( )
• 210210 : Craic Computing Tech Tips ( Craic Computing Tech Tips, )
• 210210 : Apache 2.2 - Where are the modules ? ( Apache 2.2 - Where are the modules ?, )

Old News

mod rewrite

mod_authn_pam - Apache HTTP Server

mod_authn_pam uses the "configure/make/make install" mechanism common to many Open Source programs. Most of the dirty work is handled by either configure or Apache's apxs utility. If you have built apache modules before, there shouldn't be any surprises for you.

Before you can begin compiling mod_authn_pam, you will need a working installation of Apache 2.1-dev (any earlier version, including Apache 2.0.x will NOT work).

The interesting options you can pass to configure are:

• --with-apxs=/path/to/apache/dir/bin/apxs

  This option is used to specify the location of the apxs utility that was installed as part of apache. Specify the location of the binary, not the directory it is located in.

• --with-pam=/path/to/libpam

• --with-pam-includes=/path/to/libpam/includes

• --with-pam-libs=/path/to/libpam/lib

Call configure with your site-specific values and then "make" and "make install" as usual. The module will be installed in the module directory of your Apache installation.

Again mod_authn_pam behave like your average next-door Apache module. Just add

LoadModule authn_pam_module modules/mod_authn_pam.so

to your httpd.conf as usual and restart Apache.

Example Config

       <Location /secure-area>
         AuthType Basic
         AuthName  "basic authn_pop3 testing area"
         AuthBasicProvider pam
         Require valid-user
       </Location>

ONLamp.com Apache Modules

09/27/2001

Over the last few articles, I have covered some of the new features in Apache 2.0, and how you can take advantage of them in your web servers. This time, I am going to cover one of the least-discussed features in Apache 2.0.

One of the biggest advantages of Apache over other web servers is how easy it is to write powerful modules. Apache has used modules since version 1.0 to implement everything but serving basic, static files. Because Apache itself used modules for everything, modules need to have access to every stage of serving a request. Modules have, however, always suffered from one major flaw.

Modules have always been solitary entities. If two modules both have to do the same operation, they both need to implement the feature. This makes maintaining modules very difficult because if you modify the behavior in one module, you must also modify it in every other location. Perhaps the best examples of this are the mod_include and mod_cgi modules. mod_include implements server-side include (SSI) processing. mod_cgi spawns CGI scripts. However, mod_include also needs to be able to spawn CGI scripts whenever it encounters the following code in an SSI:

<!--#exec cgi=/cgi-bin/printenv -->

In Apache 1.3, both modules had logic to create a CGI process and execute the correct program in it. This logic was very complex on some platforms -- especially platforms that did not look at the #! line of a script to find the interpreter.

In Apache 2.0, we can remove this maintainance problem by allowing mod_include to call into mod_cgi to create a CGI script. This does have some drawbacks. The first major drawback is that mod_include cannot include the output of CGI scripts unless mod_cgi is loaded into the server.

The Apache developers decided that this was a valid tradeoff because by not including mod_cgi, the administrator has stated that he or she does not want to allow CGI scripts to be run. We could not find a valid reason to allow CGI scripts within SSI files if they weren't allowed to direct connections. This addition to mod_include allows other module authors to easily extend the tags that are allowed in SSI files, without having to modify the base mod_include code.

Also in Apache 2.0 Basics: Writing Input Filters for Apache 2.0 Writing Apache 2.0 Output Filters Writing Filters for Apache 2.0

To demonstrate how easy it is to extend mod_include, let's take a look at how mod_cgi does it. The first step is to retrieve a couple functions from mod_include. This is done using optional functions, a new feature in Apache 2.0, that lets a module can register functions with the core as optional. When another module wants to use those functions, it queries the core server, asking if modules those functions have been registered. The core uses the name of the function as the key to find the pointer that was stored when the function was registered.

There are three functions that are important for mod_include extensions: ap_register_include_handler, ap_ssi_get_tag_and_value, and ap_ssi_parse_string. The ap_register_include_handler function is used to specify the tag that this module will handle. ap_ssi_get_tag_and_value gets the next attribute and value from the SSI tag that is being parsed. SSI extension functions will loop calling this function, retreiving each of the attributes until the function returns a "null" attribute. This signifies that all attributes have been found. The final function is ap_ssi_parse_string; this function is used to do variable substitution on a string.

Once all these function pointers are retrieved, your module must register a tag with mod_include. This can only be done if all the functions were retrieved successfully. To register a tag, just call the register function with the string that mod_include should look for when processing SSI output, and a function to call when the string is found. The following function is the function that mod_cgi uses to do this.

static void cgi_post_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp, server_rec *s)
{
cgi_pfn_reg_with_ssi = APR_RETRIEVE_OPTIONAL_FN(ap_register_include_handler)
;
cgi_pfn_gtv = APR_RETRIEVE_OPTIONAL_FN(ap_ssi_get_tag_and_value);
cgi_pfn_ps = APR_RETRIEVE_OPTIONAL_FN(ap_ssi_parse_string);

if ((cgi_pfn_reg_with_ssi) && (cgi_pfn_gtv) && (cgi_pfn_ps)) {
/* Required by mod_include filter. This is how mod_cgi registers
* with mod_include to provide processing of the exec directive.
*/
cgi_pfn_reg_with_ssi("exec", handle_exec);
}
}

There is one more important detail. If you look at the previous function's name, you will notice that this is called during the post_config phase. The problem is that mod_include uses a hash table to store the string/function pairs, and it allocates that hash table during its post_config function. If the mod_cgi function is called first, then the server will "seg fault" during startup. This is easily solved using the new hook mechanism in Apache 2.0. Below is an example this. This is the mod_cgi module's register_hooks function. When mod_cgi registers its post_config function, it must specify that mod_include should run first.

static void register_hooks(apr_pool_t *p)
{
static const char * const aszPre[] = { "mod_include.c", NULL };
ap_hook_handler(cgi_handler, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_post_config(cgi_post_config, aszPre, NULL, APR_HOOK_REALLY_FIRST);
}

Of course, this is just one example of where modules extending modules are useful. mod_log_config is another place where this ability has been added to the server. In the case of mod_log_config, we now allow modules to extend the type of information that can be logged. As more people implement Apache 2.0 modules, more situations like this will be discovered, and the core team will continue to create opportunities for modules to help each other solve problems.

Apache 2.0 has many features that were not possible in Apache 1.3. These features will help to keep Apache the most popular web server on the Internet. As this is my last article for OnLAMP.com, I hope that in the last six months I have taught you something about Apache 2.0. And I hope that you will download it and experiment to see where it can provide a better solution than Apache 1.3.

Ryan Bloom is a member of the Apache Software Foundation, and the Vice President of the Apache Portable Run-time project.

Recipe 2.1. Installing a Generic Third-Party Module

Problem

You have downloaded a third-party module that isn't listed in this chapter, and you want to install it.

Solution

Move to the directory where the module's source file was unpacked, and then:

% /path/to/apache/bin/apxs -cia  module.c 

For example

/usr/local/apache2/bin/apxs -cia mod_auth_basic.c

Discussion

In the case of a third-party module that consists of a single .c file, there is a good chance that it can be built and installed using the Solution. Modules that involve multiple source files should provide their own installation instructions.

The -cia options mean to compile, install, and activate. The first is pretty straightforward; install means put the .so file in the place Apache expects to find it, and activate means to add the module to the httpd.conf file.

See Also

• The apxs manpage, typically ServerRoot/man/man8/apxs.8

Craic Computing Tech Tips

A collection of computer systems and programming tips that may be useful to others.

Brought to you by Craic Computing LLC, a bioinformatics consulting company based in Seattle, WA, USA.

• • • Apache 2.2 - Where are the modules ?
    • Adding Hard Drives to a Linux System using fdisk
    • 'Modern' ATX Motherboards have TWO Power Connector...
    • Installing Linux Fedora 7 over a Network
    • Copying a Disk Image to a USB Memory Stick on Mac ...
    • Setting up NFS mounts in Linux (Fedora 6)
  • ► May (1)
    • Installing Rubygems on Linux Fedora
  • ► April (2)
    • Setting up a Subversion Repository
    • Perl CPAN on Mac OSX
  • ► January (8)
    • Using Oracle as a Backend to Rails
    • Configuring Oracle Database XE on Linux
    • Configuration of Web Servers and Rails
    • mod_fastcgi-2.4.2 and Apache 2.2
    • Installing Rails 1.2.1 on Fedora Linux Core 5
    • Issues with :tinyint in Rails Table Definitions
    • Viewing local man pages
    • Fedora Core 5 Linux on Asus P5B / Intel Core Duo 2...

Apache 2.2 - Where are the modules ?

The Apache httpd server has played a critical role in most of my work over the past decade but these days I'm finding more and more reasons to look at alternatives. Its configuration syntax is not pretty, the distribution is bloated, and its performance with some applications (especially Rails) is almost unworkable. Here's another reason to grumble...

I recently compiled Apache 2.2.4 from source. I've done that several times in the past and just did the typical steps of:
# ./configure --prefix=/usr/local/apache2
# make
# make install

That works great and I can fire up the server just fine - until I want to serve an application that involves URL rewriting. I get this error:

[Wed Jun 20 17:00:07 2007] [alert] [client 192.168.2.26] /Users/jones/instiki/public/.htaccess: Invalid command 'RewriteEngine', perhaps misspelled or defined by a module not included in the server configuration

That tells me that the mod_rewrite module is not being loaded in the httpd.conf file. So I go into that file and search for the LoadModule section. In the past there would be a bunch of LoadModule statements, many of which were commented out. But in 2.2.4 there is only one. This is actually a good thing as it makes the httpd.conf file smaller and easier to look through.

I figured I just needed to add a line that loaded mod_rewrite. I checked my apache2/modules directory to get the correct file name - but there are no modules in there. I checked to see if it was compiled into the executable using this:

# /usr/local/apache2/bin/httpd -l

No, it's not in the list. So where are all the modules? Am I supposed to download them separately from apache.org? Looking on that site doesn't tell me what to do. What's the deal?

Turns out that you have to specify the modules you want at compile time. This is a really, really bad move on Apache's part. I'm sure it is done with the best of intentions but what a pain. In order to get my module I have to go and recompile the whole damn thing... great...

*WAIT* If you have already modified your current apache config files, htdocs directory, etc. copy them somewhere safe before you recompile and install over them!

Here's what I need to do to get mod_rewrite and mod_env compiled so that I can load them dynamically.

# ./configure --prefix=/usr/local/apache2 --enable-rewrite=shared --enable-env=shared

To see the full list of options (215 lines of them) do this:

# ./configure --help

You can get 'all' or 'most' (whatever that means) of the modules using these variants

# ./configure --prefix=/usr/local/apache2 --enable-mods-shared=all
# ./configure --prefix=/usr/local/apache2 --enable-mods-shared=most

I chose the latter when I recompiled and that gave the two that I need plus hopefully any others that I might need in the future. So my specific steps were:

# ./configure --prefix=/usr/local/apache2 --enable-mods-shared=most
# make
# make install

Then I went into the httpd.conf file, put back a couple of changes that I had made previously and went looking for the LoadModule lines. Well, I guess I got what I asked for... I asked it to compile most of the modules. It did that and it has set up the config to load all 43 of them!

All I want are two modules, for Pete's sake... so I reckon I want to delete the others, right? WRONG! Without the new configure directive, a bunch of the standard modules are compiled in the server. With the new directive, they are loaded dynamically. So if you delete these LoadModule lines then a load of other stuff will break.

With all this done, I can now get back to where I started with a functioning Apache installation. I hope this note helps you avoid the couple of hours of frustration that I just enjoyed.

Apache is a great piece of work, don't get me wrong, - but nonsense like this is really annoying.

If you are in the market for an alternative you might want to consider Nginx (http://nginx.net/), a relatively unknown http server that is getting a lot of good press in the Rails community.

Posted by Robert Jones at 5:20 PM

Recommended Links

Softpanorama Recommended

Top articles

Sites

Apache 2 Module Tutorial - GNU Build Tools and the Development Environment

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019