Apache Web サーバに関する考慮事項 (UNIX®/Linux/macOS)

セキュリティ

Apache Web サーバを起動すると、通常スーパーユーザ特権で実行される親プロセスが初期化されます。これは、TCP ポート 80 にバインドするために必要な操作です。

その後、Apache は Web 要求の処理を行う子プロセス (ワーカ・プロセス) を起動します。これらの子プロセスは、User および Group Apache 構成指示文を使用して指定する、より低い特権のユーザおよびグループとして実行されます。

子プロセスは、それらが処理するすべてのコンテンツを読み取る能力 (および Web ゲートウェイの構成およびイベント・ログ・ファイルへの読み取り/書き込みアクセス権) が必要です。ただし、これ以外に、これらの子プロセスに付与する特権は最小限にする必要があります。詳細は、Apache ドキュメントを参照してください。

Apache プロセス管理と Web ゲートウェイ

InterSystems Web ゲートウェイ・モジュールは Apache ワーカ・プロセスに直接バインドされます。 したがって、プロセス・プールを管理するための Apache の構成方法が、Web ゲートウェイに直接の影響を与えます。

Apache は、プロセス管理のためにPrefork MPM (http://httpd.apache.org/docs/current/mod/prefork.htmlOpens in a new tab)、Worker MPM (http://httpd.apache.org/docs/current/mod/worker.htmlOpens in a new tab)、Event MPM (http://httpd.apache.org/docs/current/mod/event.htmlOpens in a new tab) の 3 つのマルチプロセッシング・モジュール (MPM) を提供しています。Web ゲートウェイ動的共有オブジェクト (DSO) モジュールはスレッドセーフで、どの MPM とも一緒に展開できます。

どちらのサーバ・モデルが既存のインストールに使用されているかを判別するには、コマンド・プロンプトから以下のコマンドを発行します。

RHEL Ubuntu/SUSE

httpd -V

apache2 -V

すべての MPM が、複数の子 (ワーカ) プロセスにわたる負荷分散に関係します。StartServers 指示文は、すべての MPM について、開始するワーカ・プロセスの数を指定します。Web ゲートウェイ・モジュールはワーカ・プロセスに直接バインドされるため、この指示文は処理される Web ゲートウェイ・インスタンスの数も決定します。

ただし、実行中の構成、接続テーブル、およびフォーム・キャッシュは共有メモリ・セクタに保持されます。 これにより、Web ゲートウェイ・システム・ステータス・フォームのコンテンツは、すべてのワーカ・プロセスで一貫して Web ゲートウェイのアクティビティを反映するようになります。Apache サーバでは、接続テーブル (および接続番号) に、各 InterSystems IRIS 接続が関連付けられる Web サーバ・プロセス ID を示す追加列が含まれます。

ステート認識セッション (保持モード 1)

複数の Apache ワーカ・プロセスでステート認識セッションをサポートするために、Web ゲートウェイは UNIX® ドメイン・ソケットを使用して、ワーカ・プロセス間で要求をルーティングします。

例として、P1、P2、および P3 の 3 つのワーカ・プロセスに負荷を分散する Web サーバ・インストールについて考えてみましょう。 各ワーカ・プロセスは、使用されている Web サーバの MPM と構成に従って、任意の数のスレッド (T1、T2 … Tn) を開始できます。

アプリケーションがそのセッションをステート認識 (保持モード 1) とマークする要求を行い、Web ゲートウェイがプロセス P2 でその指示を認識すると仮定します。 今ではプライベートの InterSystems IRIS プロセスへの接続 (およびセキュリティ・コンテキスト) は Web サーバのワーカ・プロセス P2 によってホストされます。 そのユーザ/セッションに対する以降の要求は、すべてワーカ・プロセス P2 で処理する必要があります。 ただし、Web ゲートウェイは Web サーバが以降の要求をどのワーカ・プロセスに転送するかを制御できないため、Web ゲートウェイは P2 と (可能性として) そのセット内の他の任意のワーカ・プロセスとの間で IPC チャンネルを確立する必要があります。

Web ゲートウェイは P2 でステート認識として接続をマークすると、別個の分離されたスレッドで待ち受けサービスを開始します。 ログ・レベル v2 の場合、イベント・ログには以下のようなメッセージが含まれます。

IPC Server 
Process ID: 28457 Listening on Domain Socket: /tmp/csp28457.str

同じセッションに対する別の要求がワーカ・プロセス P3 によって処理される場合、Web ゲートウェイはその要求を、以前に確立された IPC チャンネルを介してプロセス P2 に転送し、応答を待機します。ログ・レベル v2 の場合、イベント・ログには以下のようなメッセージが含まれます。

Route request over IPC to another web server process
PrivateSession=2; pid_self=28456; ipc_to_pid=28457; 

もちろん、Web サーバがこのセッションに対する要求を P2 に転送する場合、Web ゲートウェイ環境でそれ以上の転送は必要ありません。

以前作成された IPC チャンネルに Web ゲートウェイが接続して要求を転送できない場合は、イベント・ログに以下のメッセージのいずれかが記録されます (コンテキストに応じて)。

IPC CLIENT: Error
Cannot connect

または

IPC CLIENT: Error
Cannot send request

Apache がワーカ・プロセスを閉じたり、リサイクルした場合、このエラーが発生することがあります。 ワーカ・プロセスもクラッシュした可能性があります。この場合、Apache エラー・ログにもエラーが記録されます。