+

Search Tips   |   Advanced Search

Migrate web server configurations

  1. Migrate web server configurations:

    If the new version of IBM HTTP Server (IHS) is installed in a different directory, we do not need to complete Steps a - d.

    1. Stop the IHS and the IHS administration server.

    2. Copy the existing installation directory to a new location.

      This action preserves the configuration, keys, and content.

      Copy the previous installation:

        cp -rp current_install_directory new_directory_name

      (Windows)

        xcopy current_install_directory new_directory_name /s /e /k /i

    3. Uninstall the previous IHS version.

    4. Remove the previous installation directory.

      Because the uninstall leaves behind some files, such as modified and added files, fixpack files, and uninstall files, we must manually remove the previous installation directory to complete the uninstall process. If we have any uninstall issues, review and backup the uninstall log files in the http_server_install/logs/uninstall directory before proceeding.

      Remove the installation directory:

        rm -r current_install_directory

      (Windows)

        rd /s current_install_directory

    5. Install IBM HTTP Server v9.0.

      If we are upgrading our existing version, install into the directory where the previous installation was located.

      If we are installing the new version alongside an existing version, install the new version into a different directory.

    6. Run the Plug-ins Configuration Tool (pct), to configure server plug-ins.

    7. Restore any custom configurations that were made to the previous version of IHS and IHS administration server.

      • Identify the previous customizations.

        If we used the httpd.conf configuration files provided with the previous version of IHS as the starting point for our configuration files, compare the content of each configuration file, with its corresponding .default file, within the directory containing the previous IHS installation. For example, if we compare the content of the httpd.conf file with the httpd.conf.default file we should see any customization that were made to the httpd.conf file since the original installation. Then perform similar comparisons for the other configuration files.

        If we did not use the httpd.conf configuration files provided with the previous version of IHS as the starting point for our configuration files, we will need to perform a more manual analysis to determine the previous settings. Use a tool such as BeyondCompare to compare the settings in the httpd.conf.default file provided with the new IHS, with the settings in the httpd.conf.default file provided with the previous IHS version. This comparison enables us to identify configuration differences in the two httpd.conf.default files. We can then use this information to modify our customized configuration file to work with the v9.0 IHS.

        Compare the bin/envars file to the bin/envars-std file within the directory containing the previous IHS installation. This identifies what customizations, if any that was made to this file.

      • Merge the customizations into the newly installed IHS configuration and envars files.

        After identifying the configuration customizations made to the previous version of IHS, make these same changes, when applicable, to the configuration files for the v9.0 IHS.

        If the configuration files contain WAS plug-in statements from previous versions, remove them so as to not cause duplicates. If we do not remove these statements, when the HTTP Server attempts to start the v9.0 plug-in binary module, an error might occur that indicates that the module is already loaded.

        The configuration file might also contain duplicate entries for accessing WAS samples. Remove any aliases for previous versions and retain the v9.0 entries:

    8. Restore HTML content.

      If our web page content was previously stored under the IHS installation directory, copy those content files from the directory containing the prior version of IHS into the installation directory for the new version.

    9. Copy any SSL KeyFiles, that might be within the installation directory of the previous IHS, into the new installation directory

  2. Change port assignments for coexisting IBM HTTP Servers.

    If we installed the IHS into a new directory and retained the previous version of the IHS, by default the administration server and the Web Server use the same ports as the previous version administration server and Web Server. If we run both versions of the IHS simultaneously, port conflicts will occur unless we change the port numbers for one of the server versions.

    To modify the port numbers for one of the IHS, edit the server configuration files for that IHS. These files are located in the http_server_install/conf directory.

  3. Upgrade Apache plug-in modules.

    There are no Apache API changes from the previous major release so there should be no need to rebuild modules that worked with the previous release. However, if we use modules from third party vendors, then we should contact your vendors to verify they support the module with the version of IHS to which we are upgrading.

    Apache plug-in modules from sources other than the IHS v9.0 installation must be built to support Apache 2.2. The distributors of modules used with older versions of IHS might need to recompile the modules to support Apache 2.2.

    • WebSphere Application Server provides a plug-in for Apache 2.2 and IHS v9.0.

    • If we use modules from third party vendors, contact your vendor for a version of the module that works with the Apache 2.2 API (application programming interface).

    • If we use modules developed in-house, we must rebuild your modules to support Apache 2.2. The modules might also require some modifications.

  4. Update the IHS service name.

    Update the IHS service name in the WAS web server definition if (1) this is a Windows server and (2) we installed IHS into the same directory where an earlier version was located, and (3) we are using a web server definition from that prior installation.

    For a IHS on a Windows server system, use 'Services' to determine the name used for the new IHS service, and then update the web server definition to use this service name.

  5. Migrate web server definitions A web server definition is used to manage the web server from a stand alone profile or the deployment manager.

    • If we have updated IHS on the same host and in the same directory, no action is required. The current web server definition will suffice.

    • If the updated IHS Server is on the original host but in a new directory, update the path by selected the web server:Servers > Server Types > Web Servers in the WAS administration console.

    • If the updated IHS Server is on a new host, follow the Plug-ins roadmap to create a new web server definition. We can remove the old web server definition when we have confirmed the new web server is working properly. See "Selecting a web server topology diagram and roadmap" for a full description.


  • Select a web server topology diagram and roadmap
  • Overview of migration, coexistence, and interoperability
  • Migration Toolkit on WASdev