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