実践！IBM HTTP Serverの構築手順とよくあるトラブル解決法

はじめに

IBM HTTP Server（以下、IHS）は、エンタープライズ環境で広く利用されている高機能なWebサーバです。その心臓部には、世界で最も普及しているWebサーバソフトウェアであるApache HTTP Serverが採用されており、その安定性と柔軟性を継承しつつ、IBM WebSphere Application Server（以下、WAS）との親和性を最大限に高めるための独自の機能が追加されています。

特に、WASと連携する際のフロントエンドWebサーバとしてIHSを選択することは、IBMが提供するエコシステム内でのシームレスな連携、パフォーマンスの最適化、そして一元的なサポートという大きなメリットをもたらします。WebSphere Web Server Plug-inを介した動的なリクエストルーティング、SSLオフロード、ロードバランシング、フェイルオーバーといった機能は、大規模でミッションクリティカルなWebシステムを構築する上で不可欠な要素です。

しかし、その多機能さゆえに、構築や設定、そしてトラブルシューティングには専門的な知識が求められる場面も少なくありません。「設定ファイルはどこにあるのか？」「WASと上手く連携できない」「SSL証明書のエラーが解消しない」といった問題に直面した経験のある方も多いのではないでしょうか。

この記事は、IHSをこれから導入するインフラエンジニア、WASの運用を担当する管理者、そして既にIHSを運用しているもののトラブル解決に時間を要している方々を対象としています。IHSの基本的なアーキテクチャの理解から、IBM Installation Managerを用いた具体的なインストール手順、WASとの連携設定、SSL/TLSによるセキュア化、そして現場で頻繁に遭遇するトラブルとその解決法までを、網羅的かつ実践的に解説します。

この記事を読み終える頃には、IHSを自信を持って構築・運用し、問題発生時にも冷静かつ的確に対処できるようになることを目指します。

第1章：IBM HTTP Server のアーキテクチャと主要機能

IHSを効果的に利用するためには、まずその基本的な構造と主要な機能コンポーネントを理解することが重要です。

1.1 IHSの基本アーキテクチャ

IHSはApache HTTP Serverをベースにしているため、そのアーキテクチャもApacheに準じています。

プロセスモデル: IHSはクライアントからのリクエストを処理するために、複数の子プロセス（またはスレッド）を生成します。この動作モデルはMPM（Multi-Processing Module）によって決定されます。
- prefork MPM (Unix/Linux系): リクエストを受け付ける前に、あらかじめ複数の子プロセスをフォークしておくモデルです。プロセスごとに独立したメモリ空間を持つため非常に安定的ですが、メモリ消費量が大きい傾向にあります。
- worker MPM (Unix/Linux系): 複数の子プロセスを生成し、各プロセスがさらに複数のスレッドを持つハイブリッドモデルです。preforkよりも少ないメモリで多くの同時接続を処理できます。
- winnt MPM (Windows): 単一の親プロセスと、リクエストを処理するスレッドを持つ単一の子プロセスで構成されます。Windowsのアーキテクチャに最適化されています。
設定ファイル (httpd.conf): IHSの動作は、主に{IHS_ROOT}/conf/httpd.confというテキストファイルによって制御されます。サーバのグローバル設定、仮想ホストの定義、モジュールのロード、ログの設定など、あらゆる挙動がこのファイル内のディレクティブ（指示子）によって記述されます。
モジュールによる機能拡張: IHSの機能の多くは、モジュールとして提供されています。必要な機能をLoadModuleディレクティブで読み込むことで、サーバをカスタマイズできます。例えば、SSL/TLS機能はibm_ssl_module、リライト機能はrewrite_moduleによって提供されます。

1.2 WebSphere Application Server との連携

IHSの最も重要な役割の一つが、WASとの連携です。この連携は「WebSphere Web Server Plug-in」という専用モジュールによって実現されます。

WebSphere Web Server Plug-in の役割: このプラグインは、IHSが受け取ったHTTPリクエストのうち、JavaサーブレットやJSPなど、WASで処理すべき動的なリクエストを判断し、適切なアプリケーションサーバに転送する役割を担います。静的なコンテンツ（HTML, CSS, 画像など）はIHSが直接応答し、WASの負荷を軽減します。
plugin-cfg.xml の重要性: プラグインの動作はplugin-cfg.xmlという設定ファイルによって制御されます。このファイルには、どのURIパターンをWASに転送するか、転送先のアプリケーションサーバはどこか（ホスト名、ポート番号）、ロードバランシングやセッションアフィニティ（特定のセッションを同じサーバに振り分ける機能）をどうするか、といった情報が詳細に記述されています。このファイルは通常、WASの管理コンソールで生成・管理されます。
連携の仕組み:
1. クライアントがIHSにリクエストを送信します。
2. IHSはリクエストを受け取り、WebSphere Web Server Plug-inに処理を渡します。
3. プラグインはplugin-cfg.xmlを参照し、リクエストされたURIがWASへの転送対象であるか判断します。
4. 転送対象の場合、プラグインはWASのトランスポートポート（WC_defaulthostなど）に対して新しいHTTPリクエストを作成し、転送します。
5. WASはリクエストを処理し、レスポンスをプラグインに返します。
6. プラグインはレスポンスをIHSに返し、IHSが最終的にクライアントに応答します。

1.3 SSL/TLSによるセキュア通信

現代のWebサイトにおいて、通信の暗号化は必須です。IHSは強力なSSL/TLS機能を提供します。

IKEYMAN (IBM Key Management Utility): IHSのSSL/TLS設定の中心となるのが、デジタル証明書と秘密鍵を管理するためのGUIツール「IKEYMAN」です。これにより、鍵データベースの作成、証明書署名要求（CSR）の生成、認証局（CA）から発行された証明書のインポートなどを直感的に行うことができます。
鍵データベースファイル（.kdb）: IKEYMANで管理される証明書や鍵は、単一の鍵データベースファイル（例: key.kdb）に格納されます。このファイルは、サーバの秘密鍵、サーバ証明書、そしてその証明書を信頼するための信頼チェーン（中間CA証明書、ルートCA証明書）を保持します。
スタッシュファイル（.sth）: KDBファイルはパスワードで保護されていますが、IHS起動時に毎回パスワードを入力するのは現実的ではありません。そこで、暗号化されたパスワードを格納したスタッシュファイル（.sth）を作成し、IHSが起動時に自動でKDBファイルのロックを解除できるようにします。

第2章：【実践】IBM HTTP Server のインストールと初期設定

ここでは、Linux環境を例に、IBM Installation Managerを使用したIHSのインストール手順を解説します。

2.1 前提条件の確認

対応OS: IHSをインストールするOSが、サポート対象バージョンであることを確認します。（例: Red Hat Enterprise Linux 8.x, SUSE Linux Enterprise Server 15.x, Windows Server 2019など）
システムリソース: 十分なメモリ、CPU、ディスク容量を確保します。最低でも2GBのRAM、2GBの空きディスク容量を推奨します。
IBM Installation Manager (IM): IHSのインストールにはIMが必要です。まだインストールされていない場合は、IBMのサイトからダウンロードして先にインストールしておきます。IMはGUIモードとコンソール（CUI）モードの両方をサポートしています。

2.2 IBM Installation Manager を用いたインストール手順

リポジトリの準備:
IHSのインストールメディア（ZIPファイルなど）を入手し、展開します。もしくは、IMがインターネット上のライブリポジトリに接続できるよう設定します。ここでは、ローカルリポジトリを使用する前提で進めます。
IMの起動とリポジトリの追加:
IMを起動し、「ファイル」>「設定」を選択します。「リポジトリ」パネルで「リポジトリの追加」をクリックし、展開したインストールメディア内のrepository.configファイルを選択します。
インストールパッケージの選択:
IMのメイン画面で「インストール」をクリックします。追加したリポジトリからインストール可能なパッケージが表示されます。以下の3つを選択します。
- IBM HTTP Server for WebSphere Application Server
- Web Server Plug-ins for WebSphere Application Server
- WebSphere Customization Toolbox (プラグイン構成に必須)
ライセンスの同意:
ライセンス条項を確認し、同意します。
インストールディレクトリの指定:
共有リソースディレクトリ（IM自体の情報を格納）と、各パッケージのインストールディレクトリを指定します。特に理由がなければデフォルトのままで問題ありません。
- 例: IHS本体: /opt/IBM/HTTPServer
- 例: Plugins: /opt/IBM/WebSphere/Plugins
- 例: WCT: /opt/IBM/WebSphere/Toolbox
アーキテクチャーの選択:
64ビット環境では、64ビット版を選択します。
構成の指定:
- HTTPポート: IHSがHTTPリクエストを待ち受けるポート番号を指定します。（デフォルト: 80）
- Windowsサービスとして実行: (Windowsの場合) IHSをWindowsサービスとして登録するかどうかを選択します。システム起動時に自動起動させたい場合はチェックを入れます。
- 管理サーバーの構成: (オプション) IHSの管理サーバーをセットアップし、WAS管理コンソールからIHSをリモートで起動・停止したい場合に構成します。今回は構成しない前提で進めます。
要約とインストール実行:
最後に、選択した内容の要約が表示されます。内容に問題がなければ「インストール」ボタンをクリックし、インストールを開始します。完了まで数分かかります。

2.3 インストール後のディレクトリ構造

インストールが完了すると、指定したディレクトリに以下のような構造でファイルが配置されます。

/opt/IBM/HTTPServer/ (IHS_ROOT)
- bin/: apachectl, httpd, ikeymanなどの実行ファイル
- conf/: メイン設定ファイルhttpd.conf
- logs/: access_log, error_logなどのログファイル
- htdocs/: デフォルトのドキュメントルート
/opt/IBM/WebSphere/Plugins/ (PLUGINS_ROOT)
- bin/: プラグイン構成スクリプト
- config/: plugin-cfg.xmlを配置するデフォルトディレクトリ
- logs/: プラグインのログhttp_plugin.log

2.4 初期設定と起動・停止

httpd.confの基本的な設定:
最小限、以下のディレクティブを確認・編集します。
“`apacheconf
# vi /opt/IBM/HTTPServer/conf/httpd.conf

サーバのホスト名を指定します。DNSで解決できる名前にしてください。

ServerName your-ihs-server.example.com:80

待ち受けポート。インストール時に80を指定した場合。

Listen 80

IHSを実行するユーザーとグループ。セキュリティ上、root以外を推奨。

専用のユーザー(e.g., ihsadmin)を作成して指定するのがベストプラクティスです。

User ihsadmin
Group ihsadmin
“`
起動・停止コマンド:
{IHS_ROOT}/binディレクトリにあるapachectlスクリプトを使用します。
- 構文チェック:
  bash /opt/IBM/HTTPServer/bin/apachectl configtest #=> Syntax OK と表示されればOK
- 起動:
  bash sudo /opt/IBM/HTTPServer/bin/apachectl start
- 停止:
  bash sudo /opt/IBM/HTTPServer/bin/apachectl stop
- 再起動:
  bash sudo /opt/IBM/HTTPServer/bin/apachectl restart
起動確認:
- ブラウザ: Webブラウザから http://your-ihs-server.example.com/ にアクセスし、IHSのデフォルトページが表示されることを確認します。
- コマンド: psコマンドでhttpdプロセスが起動していることを確認します。
  bash ps -ef | grep httpd

第3章：【実践】WebSphere Application Server との連携設定

IHS単体での動作確認ができたら、次は本題であるWASとの連携設定を行います。

3.1 WebSphere Customization Toolbox (WCT) の利用

プラグイン構成ファイル (plugin-cfg.xml) の生成は、WCTに含まれる「Web Server Plug-ins Configuration Tool」を使用するのが最も簡単で確実です。

WCTの起動:
{WCT_ROOT}/bin/にあるwct.shまたはwct.batを実行して、GUIツールを起動します。
Webサーバプラグイン構成ツールの選択:
ツールの一覧から「Web Server Plug-ins Configuration Tool」を選択し、「作成」をクリックします。
Webサーバープラグインのランタイムロケーションの追加:
「追加」ボタンをクリックし、先ほどインストールしたPluginsの場所 (/opt/IBM/WebSphere/Plugins) を指定します。
構成シナリオの選択:
- (推奨) IBM WebSphere Application Server: リモートのWAS Deployment Manager (Dmgr) またはスタンドアロンサーバに接続して構成情報を取得するシナリオです。Dmgrのホスト名、管理ポート（SOAPポート）、管理者ID、パスワードを入力します。
- ローカル: WASと同じマシンにIHSがインストールされている場合に選択します。
Webサーバ定義:
- Webサーバーのタイプ: 「IBM HTTP Server」を選択します。
- Webサーバー構成ファイルの場所: IHSのhttpd.confのフルパス (/opt/IBM/HTTPServer/conf/httpd.conf) を指定します。
- Webサーバーポート: IHSのポート番号（例: 80）を指定します。
- Webサーバー定義名: WAS管理コンソール上でこのWebサーバを識別するための名前を付けます（例: webserver1）。
構成の完了:
ウィザードの指示に従い、設定を完了します。このプロセスにより、以下の処理が自動的に行われます。
- WAS DmgrにWebサーバ定義が作成される。
- Dmgr上でplugin-cfg.xmlが生成される。
- httpd.confにプラグインを読み込むための設定が追記される。
- 生成されたplugin-cfg.xmlがIHS側に転送（伝搬）される。

3.2 `httpd.conf` の編集確認

WCTによる構成が完了すると、httpd.confの末尾に以下のような行が自動的に追加されているはずです。手動で設定する場合は、この内容を追記します。

“`apacheconf

WebSphere Application Server Plug-in

LoadModule was_ap24_module /opt/IBM/WebSphere/Plugins/bin/64bits/mod_was_ap24_http.so
WebSpherePluginConfig /opt/IBM/WebSphere/Plugins/config/webserver1/plugin-cfg.xml
“`

3.3 連携動作の確認

IHSの再起動:
設定を反映させるために、IHSを再起動します。
bash sudo /opt/IBM/HTTPServer/bin/apachectl restart
WAS上のアプリケーションへのアクセス:
WASにデプロイされているアプリケーション（例: snoopサーブレット）に、IHS経由でアクセスします。
http://your-ihs-server.example.com/snoop
ログの確認:
もしアクセスできない場合は、以下のログを確認して問題を切り分けます。
- {PLUGINS_ROOT}/logs/webserver1/http_plugin.log: IHSとWAS間の通信ログです。接続エラーやルーティングの問題を調査する上で最も重要なログです。
- IHSのerror_log: プラグイン自体のロードエラーなどが出ていないか確認します。
- WASのSystemOut.log: WAS側でリクエスト処理中にエラーが発生していないか確認します。
管理コンソールでの確認:
WASの管理コンソールにログインし、「サーバー」>「サーバー・タイプ」>「Web サーバー」に、作成したWebサーバー (webserver1) が表示され、ステータスが「開始済み」（緑色の矢印）になっていることを確認します。

第4章：【実践】SSL/TLS設定によるセキュア化

次に、IHSでHTTPS通信を有効にする手順を解説します。

4.1 鍵データベース（KDB）の作成

IKEYMANの起動:
GUI環境が利用できる場合は、{IHS_ROOT}/bin/ikeyman.sh (Linux) または ikeyman.bat (Windows) を実行します。
新規鍵データベースファイルの作成:
- メニューから「鍵データベース・ファイル」>「新規」を選択します。
- 鍵データベース・タイプ: CMS を選択します。（IHSの標準）
- ファイル名: key.kdbなど、分かりやすい名前を付けます。
- ロケーション: {IHS_ROOT}/conf/など、管理しやすい場所に保存します。
- パスワードの設定: KDBファイルを保護するためのパスワードを入力します。このパスワードは後で必要になるので、必ず控えておきます。
- 「パスワードをファイルに隠す」にチェックを入れると、対応するスタッシュファイル (.sth) が同時に作成されます。

4.2 サーバ証明書の作成とインポート

ここでは、テスト目的で自己署名証明書を作成する手順を解説します。本番環境では、認証局（CA）から発行された正規の証明書を使用してください。

自己署名証明書の作成:
- IKEYMANのメイン画面で、ドロップダウンリストから「個人証明書」を選択します。
- 右側の「新規自己署名…」ボタンをクリックします。
- キー・ラベル: 証明書のエイリアス（ニックネーム）です。（例: ihsserver_cert）
- 共通名 (CN): サーバのFQDN（完全修飾ドメイン名）を入力します。（例: your-ihs-server.example.com）
- 組織: 会社名などを入力します。
- その他のフィールドを適宜入力し、「OK」をクリックします。
- これで、KDBファイル内に秘密鍵とそれに対応する公開鍵証明書が作成されました。

(補足: 本番環境の手順)
本番環境では、「新規認証要求…」からCSRを作成し、そのCSRを認証局に提出します。認証局から発行されたサーバ証明書、中間CA証明書、ルートCA証明書を、IKEYMANの「署名者証明書」セクションにルート→中間の順で「追加」し、最後に「個人証明書」セクションでサーバ証明書を「受信」します。

4.3 `httpd.conf` でのSSL設定

httpd.confを編集して、SSLを有効化します。ファイルの末尾に追記するのが一般的です。

“`apacheconf

SSLモジュールをロード

LoadModule ibm_ssl_module modules/mod_ibm_ssl.so

HTTPSポート(443)をリッスン

Listen 443

SSL仮想ホストの設定

# サーバ名
ServerName your-ihs-server.example.com

# SSLを有効にする
SSLEnable

# (セキュリティ強化) 古い脆弱なプロトコルを無効化
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11

# (セキュリティ強化) 推奨される暗号スイートを指定
SSLCipherSpec TLS_AES_256_GCM_SHA384
SSLCipherSpec TLS_CHACHA20_POLY1305_SHA256
SSLCipherSpec TLS_AES_128_GCM_SHA256

# 鍵データベースファイルのパス
KeyFile /opt/IBM/HTTPServer/conf/key.kdb

# スタッシュファイルのパス (これがあれば起動時にパスワード不要)
SSLStashfile /opt/IBM/HTTPServer/conf/key.sth

# (オプション) 使用する証明書のラベルを指定
# KDBに複数の個人証明書がある場合に必要
# SSLLabel ihsserver_cert

“`

4.4 設定の反映と確認

構文チェックと再起動:
bash /opt/IBM/HTTPServer/bin/apachectl configtest sudo /opt/IBM/HTTPServer/bin/apachectl restart
ブラウザでの確認:
Webブラウザで https://your-ihs-server.example.com/ にアクセスします。自己署名証明書を使用しているため、ブラウザは警告を表示しますが、例外を許可して進むと、IHSのデフォルトページがHTTPSで表示されるはずです。ブラウザの鍵アイコンをクリックし、証明書の詳細（共通名など）が正しく表示されていることを確認します。

第5章：よくあるトラブルシューティング

ここでは、IHSの運用で遭遇しがちな問題とその解決策をパターン別に解説します。

5.1 起動・停止に関するトラブル

現象: apachectl start を実行してもIHSが起動しない、またはすぐに終了してしまう。

原因と解決法:

ポートの競合:
- 原因: Listenディレクティブで指定したポート（80, 443など）を、他のプロセスが既に使用している。
- 調査: netstatコマンドでポートの使用状況を確認します。
  bash netstat -anp | grep ":80" netstat -anp | grep ":443"
- 解決法: 競合しているプロセスを停止するか、IHSが使用するポート番号をhttpd.confで変更します。
設定ファイルの構文エラー:
- 原因: httpd.confの記述に誤りがある（ディレクティブのスペルミス、閉じタグの不足など）。
- 調査: apachectl configtestを実行し、エラーメッセージを確認します。エラー箇所と行番号が示されます。
  bash /opt/IBM/HTTPServer/bin/apachectl configtest #=> Syntax error on line 123 of /opt/IBM/HTTPServer/conf/httpd.conf: Invalid command 'SrverName' ...
- 解決法: 指摘された箇所の構文を修正します。
権限不足:
- 原因: IHSの実行ユーザー（User, Groupで指定）が、ログファイルやPIDファイルを書き込むディレクトリへの権限を持っていない。または、特権ポート（1024未満）をリッスンする権限がない（root以外で起動しようとした場合）。
- 調査: {IHS_ROOT}/logs/error_logに “Permission denied” などのエラーが出力されていないか確認します。
- 解決法:
  - chown -R ihsadmin:ihsadmin /opt/IBM/HTTPServer/logs/ のように、ディレクトリの所有者を正しく設定します。
  - 特権ポートを使用する場合は、rootユーザーでapachectlを実行する必要があります。

5.2 WebSphere連携に関するトラブル

現象: 静的コンテンツは表示されるが、WAS上のアプリケーションにアクセスすると500 Internal Server Errorや503 Service Unavailableが表示される。

原因と解決法:

plugin-cfg.xmlが不正確または古い:
- 原因: WAS側でアプリケーションのデプロイやサーバ構成の変更があったにもかかわらず、plugin-cfg.xmlが更新・伝搬されていない。
- 調査: WAS管理コンソールで「環境」>「Webサーバー・プラグインの更新」を確認。または「サーバー」>「Webサーバー」> webserver1 > 「プラグイン・プロパティー」で「プラグイン構成ファイルの表示」をクリックし、内容が最新か確認します。
- 解決法: WAS管理コンソールでWebサーバを選択し、「プラグインの生成」を実行後、「プラグインの伝搬」を実行します。その後、IHSを再起動します。
WASアプリケーションサーバの停止:
- 原因: プラグインがリクエストを転送しようとしている先のアプリケーションサーバ（クラスタメンバ）が停止している。
- 調査: {PLUGINS_ROOT}/logs/webserver1/http_plugin.log を確認します。”ERROR: ws_common: websphereConnect: Connect failed” や “Failed to connect” といったメッセージが記録されます。
- 解決法: WAS管理コンソールで対象のアプリケーションサーバのステータスを確認し、停止していれば起動します。
ファイアウォールによるブロック:
- 原因: IHSが稼働するサーバとWASが稼働するサーバの間にあるファイアウォールが、WASのトランスポートポート（デフォルト9080, 9443など）への通信をブロックしている。
- 調査: IHSサーバからWASサーバに対してtelnetやcurlコマンドでポートへの接続を試みます。
  bash telnet was-server.example.com 9080 #=> "Connected to was-server.example.com" と表示されればOK
- 解決法: ネットワーク管理者と協力し、ファイアウォールで必要なポートの通信を許可します。

5.3 SSL/TLSに関するトラブル

現象: HTTPSでアクセスできない（接続がタイムアウトする、リセットされる）、ブラウザで証明書に関するエラーが表示される。

原因と解決法:

KDBファイルまたはスタッシュファイルのパス間違い:
- 原因: httpd.confのKeyFileやSSLStashfileディレクティブで指定したパスが間違っているか、ファイルが存在しない。
- 調査: {IHS_ROOT}/logs/error_logに “Could not open key file” や “Failed to open stash file” といったエラーが出力されます。
- 解決法: httpd.confのパス指定を修正し、ファイルが正しい場所に正しい権限で存在することを確認します。
証明書の有効期限切れまたは不一致:
- 原因: サーバ証明書の有効期限が切れている。または、アクセスしているホスト名と証明書のコモンネーム（CN）やサブジェクト代替名（SAN）が一致していない。
- 調査: IKEYMANでKDBファイルを開き、証明書の有効期限を確認します。ブラウザのエラー詳細でも確認できます。
- 解決法: 有効な証明書を再発行し、KDBにインポートします。
中間証明書の不足（信頼チェーンの不備）:
- 原因: サーバ証明書は正しいが、その証明書を発行した中間CAの証明書がKDBにインポートされていない。これにより、ブラウザはサーバ証明書を信頼できません。
- 調査: openssl s_clientコマンドやオンラインのSSLチェックツールでサーバの証明書チェーンを確認します。
- 解決法: 認証局から提供された中間CA証明書を、IKEYMANの「署名者証明書」セクションに追加します。

第6章：運用とセキュリティ強化

構築が完了した後も、安定稼働とセキュリティ維持のための継続的な運用が重要です。

6.1 ログローテーション

IHSは稼働し続けるとログファイルが肥大化し、ディスク容量を圧迫します。標準で搭載されているrotatelogsユーティリティを使って、ログを定期的に分割・保管しましょう。

httpd.confのCustomLogディレクティブを以下のように変更します。

“`apacheconf

毎日0時に日付付きのファイル名で新しいログファイルに切り替える

例: access_log.2023-10-27

CustomLog “|/opt/IBM/HTTPServer/bin/rotatelogs /opt/IBM/HTTPServer/logs/access_log.%Y-%m-%d 86400” common
“`

6.2 セキュリティ設定のベストプラクティス

サーバ情報の隠蔽:
httpd.confに以下を追記し、エラーページやHTTPヘッダからIHSのバージョン情報などが漏洩するのを防ぎます。
apacheconf ServerTokens Prod ServerSignature Off
脆弱なプロトコル・暗号スイートの無効化:
第4章のSSL設定例のように、SSLProtocolDisableとSSLCipherSpecを使用して、現在では安全でないとされるSSLv3やTLS 1.0/1.1、古い暗号スイートを無効化します。
セキュリティ関連HTTPヘッダの追加:
mod_headersモジュールを使い、クリックジャッキングやXSS（クロスサイトスクリプティング）攻撃を緩和するヘッダを追加します。
apacheconf LoadModule headers_module modules/mod_headers.so Header always set X-Frame-Options "SAMEORIGIN" Header always set X-XSS-Protection "1; mode=block" Header always set X-Content-Type-Options "nosniff"

6.3 パッチとフィックスパックの適用

IHSやApache HTTP Serverには、定期的にセキュリティ脆弱性が発見されます。IBM Fix Centralを定期的にチェックし、最新のフィックスパックを適用することが極めて重要です。フィックスパックの適用は、IBM Installation Managerの「更新」機能を使って簡単に行うことができます。

まとめ

この記事では、IBM HTTP Serverのアーキテクチャから、インストール、WebSphere Application Serverとの連携、SSL/TLSによるセキュア化といった一連の構築手順を、具体的なコマンドや設定例を交えて解説しました。さらに、現場で直面しがちなトラブルをパターン別に分類し、その原因究明と解決策を詳述しました。

IHSは、単なる静的Webサーバではなく、WASを中心としたエンタープライズシステムの堅牢な「玄関口」としての役割を担います。その挙動を正しく理解し、適切に設定・運用することが、システム全体の安定性とセキュリティを確保する鍵となります。

特に、トラブルシューティングにおいては、以下の3つのログファイルを常に意識することが問題解決への近道です。

error_log: IHS自体のエラー
http_plugin.log: IHSとWAS間の連携エラー
access_log: クライアントからのリクエスト記録

本記事で得た知識を基に、ぜひ実際の環境でIHSの構築に挑戦してみてください。そして問題に直面した際には、この記事をトラブルシューティングのガイドとしてご活用いただければ幸いです。Webシステムの世界は常に進化していますが、その基盤となる技術を深く理解することは、エンジニアとしての価値を大いに高めることでしょう。

実践！IBM HTTP Serverの構築手順とよくあるトラブル解決法

はじめに

第1章：IBM HTTP Server のアーキテクチャと主要機能

1.1 IHSの基本アーキテクチャ

1.2 WebSphere Application Server との連携

1.3 SSL/TLSによるセキュア通信

第2章：【実践】IBM HTTP Server のインストールと初期設定

2.1 前提条件の確認

2.2 IBM Installation Manager を用いたインストール手順

2.3 インストール後のディレクトリ構造

2.4 初期設定と起動・停止

サーバのホスト名を指定します。DNSで解決できる名前にしてください。

待ち受けポート。インストール時に80を指定した場合。

IHSを実行するユーザーとグループ。セキュリティ上、root以外を推奨。

専用のユーザー(e.g., ihsadmin)を作成して指定するのがベストプラクティスです。

第3章：【実践】WebSphere Application Server との連携設定

3.1 WebSphere Customization Toolbox (WCT) の利用

3.2 httpd.conf の編集確認

WebSphere Application Server Plug-in

3.3 連携動作の確認

第4章：【実践】SSL/TLS設定によるセキュア化

4.1 鍵データベース（KDB）の作成

4.2 サーバ証明書の作成とインポート

4.3 httpd.conf でのSSL設定

SSLモジュールをロード

HTTPSポート(443)をリッスン

SSL仮想ホストの設定

4.4 設定の反映と確認

第5章：よくあるトラブルシューティング

5.1 起動・停止に関するトラブル

5.2 WebSphere連携に関するトラブル

5.3 SSL/TLSに関するトラブル

第6章：運用とセキュリティ強化

6.1 ログローテーション

毎日0時に日付付きのファイル名で新しいログファイルに切り替える

例: access_log.2023-10-27

6.2 セキュリティ設定のベストプラクティス

6.3 パッチとフィックスパックの適用

まとめ

コメントする 返信をキャンセル

3.2 `httpd.conf` の編集確認

4.3 `httpd.conf` でのSSL設定

コメントする返信をキャンセル