Apache HTTPD Multiple Instances

Scanner Process

For running the scans on every software versions, refer to BigFix Scanner for Middleware Application. These results are then used by the Apache HTTPD patching tasks to determine which instances require updates.

Note: Before performing any patching activity, it is recommended to create a backup of all custom configurations, instance files, and environment-specific settings. This ensures that you can restore custom configurations if required after the patching process.

Note: The detection mechanism identifies only source code based installations. For more informations, refer to Apache org (Linux) and Apache Lounge (Windows) documentation.

Mandatory Pre-Patching Prerequisites

Before applying the patch, the following conditions must be met to ensure successful execution:

Apache files cannot be updated while in use. You must stop the Windows Service (e.g., Apache2.4) before patching to prevent file "locking". If a check fails, confirm that no background instances are running.
The environment requires gcc, make, apr, apr-util, and PCRE to compile source code into executable binaries.
Features enabled during configuration may require modules like mod_security and mod_wsgi. Users must ensure all third-party dependencies are installed and accessible so the patching script can verify them.
For Windows only Fixlet deployments, manual caching is required to stage the update. Refer to the Manual caching for detailed instructions.

Patching Process

The Apache HTTPD patching task uses the scanner results to identify lower versions and update them to the patch version specified in the task.

Select the applicable computer in the BigFix Console to review installed HTTPd versions.
When the action is executed on the endpoint, the patching task reads the results.xml file and identifies all HTTPd instances present on the system.
For each detected instance, distinct makefiles are created in the middleware/httpd directory.
For Windows: All outdated or lower versions of Apache HTTPd are updated in a single execution. Verify that no background instances are running if the patching process fails.
For Linux: Distinct makefiles are created for all detected instances in the middleware/httpd directory by running a configuration check using the config.nice file located in the Build folder of each instance.
Note: If the configuration check step fails, verify that all required dependencies are installed and properly configured.

The upgrade process follows a structured sequence to ensure minimal downtime and configuration integrity.

Building and Installing Binaries

The task involves adding the patch source code and executing the configuration check script prior to installation.

For Linux: Users are required to compile and install the updated binaries by running the make and make install commands using the provided Makefile. After successful installation, the source code package should be removed.

Exit codes and their meanings

When performing tasks such as patching or extracting files in Apache HTTPD, certain exit codes may be returned to indicate the outcome of the operation. These codes help to find the issues during the installation or update process. Below is a list of common exit codes, along with their meanings and suggested actions to resolve the issues.

Table 1. Exit codes and their meanings
Exit code	Action
Exit Code 11: Patching of one or more instances failed	Run the discovery task again to retrieve the latest versions of the installed Tomcat instances. Ensure that all instances are properly configured and accessible.
Exit Code 13: Archive file not found	Verify that the download link is correct and the file is accessible. Ensure the file exists at the specified location.
Exit Code 14: Extraction of the archive failed	Check if you have the necessary file extraction permissions Ensure that the extraction path is valid and has sufficient space.