Migrating an IHS configuration file from a previous release
Apache Http Server Version 2.2 Free
Apache is a modular server. This implies that only the most basic functionality is included in the core server. Extended features are available through modules which can be loaded into Apache. By default, a base set of modules is included in the server at compile-time. Many third-party modules designed for version 2.2 will otherwise work unchanged with the Apache HTTP Server version 2.4. Some will require changes; see the API update overview. Common problems when upgrading.
The preferred method of migration is to apply your customizations over the new default configuration. If this is prohibitively complicated, it is possible to manually migrate a configuration from a prior release.
The following are steps to change an IHS 7.0, 8.0, or 8.5 httpd.conf such that it is useable on an IHS 9.0. This procedure assumes the installation paths of the old and new releases differ.
- Copy your prior releases configuration file(s) to the new installation path.
- Update paths if the install root has changed. Many absolute paths within the configuration contain the install root. Replacing old paths can be done quickly using the
sedcommand, e.g. This command copies
httpd.conffrom the prior releases installation directory to the new installation directory, and replaces all instances of
- Remove <IfModule worker.c> and the </IfModule> that follows it, leaving the contained directives. On Linux, IHS uses the 'event' MPM and this <IfModule worker.c> would hide the MPM configuration.
authz_core_module; i.e. replace with If the module is not replaced, you will receive an error similar to the following:
- Update access control. Take only one of the following actions:
- Replace the old access control directives
Denywith the new
Requiredirective. Refer to the Access Control section below. This is preferred.
- Otherwise, load the
mod_access_compatmodule by adding the following line to the configuration:
AuthSAFAuthoritativeif present (see information at the bottom of this document for more details)
- Replace the old access control directives
- Load the
mod_unixdsecurity module by adding the following line to the configuration: Otherwise, the following error occurs:
- Update the WAS plugin by changing the
LoadModuleline from: to:
- Update third-party modules to their Apache 2.4 versions. There are no general instructions for this step; contact the third-party module's vendor for explicit instructions.
If modules are not compatible with Apache 2.4, you can receive one of two types of error messages. The examples below are how the message is reported on z/OS -- the operative parts of the message are problems with symbols similar to 'ap_my_generation' or 'ap_log_error'.The first form resembles this: To figure out which module is causing the problem, start the server with the
-e debugoption, e.g. This should partially output your configuration file, and then output the error. The line of the configuration after the last line which is printed should be a
LoadModuledirective containing the name of the failing module. The other type of error message that may be shown when a module is incompatible with Apache 2.4/IHS version 9.0 looks like this: The problematic module's name is contained within the error message - in this case, myapp22_module.
- Search your configuration for directives such as Include, AuthUserFile, AuthGroupFile, and KeyFile. These directives may either point to files under the old installation root that need to be copied.
- If using the 'BFlagEscapeAllNonAlnum' parameter to RewriteOptions, remove it. It's the default and only behavior in this and future releases.
- Linux only: Add a line to dynamically load the Event MPM, e.g. 'LoadModule mpm_event_module modules/mod_mpm_event.so'?
- Attempt to start the server with the updated configuration. Review the output of the start command and the error_log to make sure no errors were reported. If a directive has been removed or has moved to a new module, you may see an error resemlbing this message:
Consult the rest of this document for informaton about the specific directive, then check http://publib.boulder.ibm.com/httpserv/manual24/mod/directives.html to find the proper module to load.
This step will likely require a number of rounds of iteration, as only 1 error is detected at a time.
- Optional: Review and apply other changes to the default configuration (httpd.conf.default) in the new release:
- ReportInterval has been reduced to 300 seconds.
- TrackModules On, TrackHooks allhooks, SlowThreshold 60, TrackHooksOptions logslow have been added.
- mod_backtrace is now loaded on some platforms where it was unintentionally omitted in previous releases.
- The default 'LogFormat' now has additional columns appended for serviceability.
- The default config has been updated to deny access to all directories by default and then explicitly allow access to the document root, icons, CGI-BIN, etc.
After taking all the above steps, the configuration should be ready to be loaded by IHSv9.0. The remainder of the document serves as a reference for what has changed between Apache 2.2 and 2.4.
Configuring your server to permit SSI
To permit SSI on your server, you must have the following directive either in your
httpd.conf file, or in a
This tells Apache that you want to permit files to be parsed for SSI directives. Note that most configurations contain multiple
Options directives that can override each other. You will probably need to apply the
Options to the specific directory where you want SSI enabled in order to assure that it gets evaluated last.
Not just any file is parsed for SSI directives. You have to tell Apache which files should be parsed. There are two ways to do this. You can tell Apache to parse any file with a particular file extension, such as
.shtml, with the following directives:
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
One disadvantage to this approach is that if you wanted to add SSI directives to an existing page, you would have to change the name of that page, and all links to that page, in order to give it a
.shtml extension, so that those directives would be executed.
Apache Http Server Version 2.4 For Windows 10
The other method is to use the
XBitHack tells Apache to parse files for SSI directives if they have the execute bit set. So, to add SSI directives to an existing page, rather than having to change the file name, you would just need to make the file executable using
chmod +x pagename.html
A brief comment about what not to do. You'll occasionally see people recommending that you just tell Apache to parse all
.html files for SSI, so that you don't have to mess with
.shtml file names. These folks have perhaps not heard about
XBitHack. The thing to keep in mind is that, by doing this, you're requiring that Apache read through every single file that it sends out to clients, even if they don't contain any SSI directives. This can slow things down quite a bit, and is not a good idea.
Of course, on Windows, there is no such thing as an execute bit to set, so that limits your options a little.
In its default configuration, Apache does not send the last modified date or content length HTTP headers on SSI pages, because these values are difficult to calculate for dynamic content. This can prevent your document from being cached, and result in slower perceived client performance. There are two ways to solve this:
- Use the
XBitHack Fullconfiguration. This tells Apache to determine the last modified date by looking only at the date of the originally requested file, ignoring the modification date of any included files.
- Use the directives provided by
mod_expiresto set an explicit expiration time on your files, thereby letting browsers and proxies know that it is acceptable to cache them.