Modules not included with IHS

What do I need to know about using apxs provided by IBM HTTP Server

  • apxs does not need to be explicitly told about any paths to IHS libraries or include files, these are all known to apxs implicitly.

  • Makefile-like flags largely come from build/config_vars.mk and represent how the core of the server was configured.

  • Settings can be overrided with arguments like -S or -Wc/-Wl.

Why might a particular third-party module not build correctly with IHS?

IBM does not provide support for building third party modules, but the regular facilities used to build Apache modules are not restricted in any way. Some potential pitfalls in third party modules:

  • The module interprets the IHS version string incorrectly, it might make some incorrect choices.

  • The module tries to invoke "httpd" under the server root, instead of apachectl.

  • The module may provide conflicting compiler flags instead of relying on apxs, causing a mismatch in the size of various data structures (e.g. a module that enables large file support)

  • The module may not be fully tested on the particular platform you're using, at all or some releases of the module

  • zOS specific issues:

    • Modules should be built with IBM1047 source code (i.e. not using -qascii). It is technically possible to use -qascii in a module, but it would need to convert any data read/written by the module that is shared with any other module.

    • build/config_vars.mk is copied at the time when bin/install_ihs is run. Consule the important variables like CC, CFLAGS, LDFLAGS in the read-only /usr/lpp/ihsa_zos/ if interested.

    • Third-party modules may fail to compile on zOS for many reasons unrelated to Apache core headers/symbols, such as relying on non-portable constructs, relying on gcc extensions, or relying on libraries not available.

Why does APXS reference a non-existent /opt/IBMIHS directory?

A defect exists in 6.1.0.23 on z/Linux only that causes apxs, the tool used to compile out-of-tree modules, to reference the compiled-in server root instead of the installation PATH. <ihsinst>/build/config_vars.mk is unnecessarily replaced by this fixpack and the logic to replace the "default" values is only run during a Full Install.

The file can be updated by changing to the <ihsinst> directory and running bin/updateinstallpath $PWD.

On unaffected systems, or after re-running bin/updateinstallpath, some entries in <ihsinst>/build/config_vars.mk will continue to reflect build-time values, but they are not required to match the installation directory for apxs.

Can I use PHP with IBM HTTP Server?

No IBM product bundles IHS and PHP for this purpose as a supported configuration, therefore no customer or product support is available for it.

IBM HTTP Supports CGI and FastCGI interfaces which are suitable for running PHP scripts outside of the server. Since IHS is always threaded, and mod_php is rarely threadsafe in practice, mod_php should never be used with IHS.

Why isn't mod_auth_form part of IBM HTTP Server

mod_auth_form allows Apache to accept credentials via an HTML form instead of HTTP Basic Authentication. Unfortunately, it requires the services of mod_session to allow a once-per-session form-based challenge to authenticate a user for some period of time

In turn, mod_session requires at least one of session persistence (via a database abstraction layer) or additional cryptographic routines inside of Apache Portable Runtime (APR), a low level library Apache HTTP Server is built on. These functions are not available in the IBM's build of APR.

It is not consistent with IBM's strategy to replicate this application server functionality in IBM HTTP Server, and the drag of cryptography and database drivers into IBM HTTP Server is too great to include this module in IHS.

Because of these dependencies, it is not practical for users to compile their own mod_auth_form and mod_session in IBM HTTP Server.