Configuring apache modules

The apacheconf component has a number of useful features which provide support for loading and configuring apache modules.

Default Modules

There are a large number of standard modules loaded by default, the list will reflect the default configuration for the platform as provided by the distribution (e.g. RHEL7). For the current list see the apacheconf.modules resource in the lcfg/defaults/apacheconf.h header file.

Optional Modules

Header files are provided for a number of optional modules, these will add extra packages, load the modules and configure appropriately for the standard usage. Currently there are:

• apacheconf-cosign.h
• apacheconf-fcgi.h
• apacheconf-gssapi.h
• apacheconf-infostatus.h
• apacheconf-iplimit.h
• apacheconf-jk.h
• apacheconf-krb5.h (for EL7 and beyond we recommend using the gssapi module instead)
• apacheconf-ldapauthz.h
• apacheconf-perl.h
• apacheconf-php5.h
• apacheconf-proxy.h
• apacheconf-python.h
• apacheconf-rewrite.h
• apacheconf-security.h
• apacheconf-ssl.h
• apacheconf-suexec.h
• apacheconf-svn.h
• apacheconf-user_rewrite.h
• apacheconf-waklog.h
• apacheconf-wsgi.h

Loading a Module

In the most simple case all that is required is to configure apache to load a module. If the module name is a valid LCFG tag name (which is usually the case) then all that is necessary is:

!apacheconf.modules                     mADD(fcgid)

This expects the apache module name to be fcgid_module and the object file to be mod_fcgid.so. Either/both of those can be overridden using the modulename_<modtag> and moduleobject_<modtag> resources. For example:

!apacheconf.modules                     mADD(php5)
!apacheconf.modulename_php5             mSET(php5_module)
!apacheconf.moduleobject_php5           mSET(libphp5.so)

The module object files are expected to be found in the directory referred to in the apacheconf.module_path resource (which is typically /usr/lib64/httpd/modules) and consequently that path is always prefixed to the object file name.

The fcgid example above will produce a file, named /etc/httpd/lcfg.modules.d/fcgid.conf, which contains:

LoadModule fcgid_module /usr/lib64/httpd/modules/mod_fcgid.so

and in the main apache config file (/etc/httpd/conf/httpd.conf), there will be an associated include for the module config file:

Include "/etc/httpd/lcfg.modules.d/fcgid.conf"

Every module has a separate configuration file in the lcfg.modules.d sub-directory, the files are included in the main configuration file in the same order as the tags are specified in the apacheconf.modules resource. For some modules care must be taken to ensure they are loaded in the correct order since the behaviour will be dependent on which modules are available, for example mod_status requires mod_limitipconn to be already loaded.

Configuring a module

There are several ways in which a module can be configured:

Using an existing configuration

Some modules are accompanied by a standard configuration file which will do the job nicely so there is little point in replicating that using LCFG resources. In that case the following is sufficient:

apacheconf.modulefile_fcgid             /etc/httpd/conf.d/fcgid.conf

This example will result in the following appearing in the module configuration file (/etc/httpd/lcfg.modules.d/fcgid.conf):

Include "/etc/httpd/conf.d/fcgid.conf"

The modulefile_<modtag> resource takes a space-separated list of files. Any which are not specified as absolute paths will be searched for in the top-level server root directory (as specified in the apacheconf.serverroot resource) which is usually /etc/httpd and also the conf.d sub-directory. If the file is not found an error will be logged. Whenever the apacheconf component configure method is called all external files are checked for changes since the previous call. If any changes are found then the component will attempt to reload the Apache daemon. The configuration files are typically in the standard locations so relative paths will work but if the file is provided by a package it is good practice to specify the absolute path, that way if you ever feel the need to change the server root location the files will still be found and the includes will still be correct.

Sometimes the configuration provided by upstream actually includes the necessary LoadModule which means that the LCFG-generated configuration file does not need to also do that. The loading of the module in the LCFG-generated file can be disabled using the moduleload_<modtag> resource.

For example, the php package provides /etc/httpd/conf.modules.d/10-php.conf that checks which MPM module is loaded before doing the load of libphp5.so. So that module can be configured like this:

!apacheconf.modules                  mADD(php5)

apacheconf.moduleload_php5           no
apacheconf.modulefile_php5           /etc/httpd/conf.modules.d/10-php.conf

which generates a file (/etc/httpd/lcfg.modules.d/php5.conf) which looks like this:

# apache module configuration managed by LCFG apacheconf component.
# This is for module tag 'php5'.

# Module is loaded somewhere else.

Include "/etc/httpd/conf.modules.d/10-php.conf"

<IfModule php5_module>
  AddType application/x-httpd-php .php
</IfModule>

# eof

Using verbatim statements

The apacheconf component also supports adding verbatim lines for modules, these can be used to specify any additional configuration which is required. They are added last in the generated module configuration file so that they can be used to override settings in any included files. Verbatim lines are specified by adding an LCFG tag to the moduleverbatim_<modtag> resource and setting a value resource, for example:

!apacheconf.moduleverbatim_wsgi             mADD(socketprefix)
apacheconf.moduleline_wsgi_socketprefix     WSGISocketPrefix /run/wsgi

This will result in the following appearing at the end of the file for the wsgi module (/etc/httpd/lcfg.modules.d/wsgi.conf)

<IfModule wsgi_module>
  WSGISocketPrefix /run/wsgi
</IfModule>

Deactivating a module

Occasionally it can be useful to deactivate a module. What this means is that the configuration file will still be generated by the component but it will NOT be included into the main Apache configuration. This is particularly useful when you would like to examine the generated configuration for a new module before attempting to load it which should mean there is less chance of it causing a problem for the server. It could also be useful if you become aware of a security issue with the module. Removing the module from the apacheconf.modules list would result in the removal of the configuration file which might not be helpful for later investigations.

A module can be deactivated using the boolean moduleactive_ resource, for example:

!apacheconf.moduleactive_wsgi mSET(no)

the top-level Apache configuration then has the Include commented out, like this:

# Include "/etc/httpd/lcfg.modules.d/wsgi.conf"

and the module config file also contains a line which indicates that it is not active:

# This module is NOT currently included in the main configuration file.

-- Main.squinney - 2016-06-02