UNIX®、Linux、および Mac OS X の Web サーバ
Apache と Sun の Web サーバについては、このセクションで説明します。
Apache にはいくつかの接続オプションがあります。Apache グループは、ダイナミック・リンク・モジュール (DSO) として実装された拡張機能をサポートしています。Apache モジュールとして記述された拡張機能は、Apache コアに直接構築できます。これは推奨オプションです。その他の一般的ではない構成のオプションについては、付録 "UNIX®、Linux、および Mac OS X の代替構成" に記載しています。
Sun の Web サーバーは、高性能 API を使用することで拡張できます。NSAPI (Netscape Application Programming Interface) の使用により、UNIX® 共有オブジェクト (共有ライブラリ) として実装されたモジュールを通じて Web サーバを拡張できます。
Apache サーバ
Apache は Apache グループによって提供されており、http://www.apache.orgOpens in a new tab から無料でダウンロードできます。
一部の UNIX® システムではビルド済みキットが利用できますが、一般にこれは最新バージョンよりもいくつか前のバージョンをビルドしたものです。Apache の完全なソース・コードが、Apache サーバの構築に関する明確な解説と共にダウンロード可能です。このような目的で GNU C コンパイラ (gcc) を無料で入手できますが、Apache 構築プロシージャは固有の C コンパイラを使用します。
多くのシステムは、Apache を事前にインストールおよび構成して、すぐに使用できる状態で出荷されます。ほとんどの Linux ディストリビューションには Apache が含まれています。IBM は、独自の UNIX® 実装である AIX® に Apache を組み込んで提供しています。
IBM が AIX で提供している Apache のビルドには、ここで推奨している Apache API モジュールとの互換性がありません。AIX で Apache の互換バージョンを組み込むには、付録 "IBM AIX 用の Apache の構築" の指示に従います。NSD を使用する構成では、この手順を踏む必要はありません。詳細は、付録 "UNIX®、Linux、および Mac OS X の代替構成" を参照してください。
このガイドでは、CSP ゲートウェイ・コンポーネントがインストールされている以下のディレクトリを参照しています。
/opt/cspgateway/csp/
このガイドでは、Apache がインストールされている以下のディレクトリを参照しています。実際の環境では Apache のインストールディレクトリが異なっている可能性があります。
/usr/apache/
システムのレイアウトが異なる場合は、必要に応じて、この後のセクションで説明する構成指示文を修正してください。
このセクションでは、CSP ゲートウェイをインストールするための推奨オプションについて説明します。
-
このドキュメントの “UNIX で稼動する Apache サーバでのインストール (すべてのオプション)” のセクションの説明に従う必要があります。
-
次に、“推奨オプション : NSD を使用しない Apache API モジュール (CSPa.so)” のセクションの説明に従います。 一般的ではないオプション使用している場合は、付録 "UNIX、Linux、および Mac OS X の代替構成" を参照してください。
UNIX®、Linux、Mac OS の Apache インストール場所 (推奨オプション)
このセクションでは、CSP ゲートウェイ・ファイルと CSP 静的ファイルのディレクトリの場所について説明します。
-
ダイナミック・リンク・モジュールには、以下のものがあります。
-
CSPa24.so (Apache バージョン 2.4.x)
-
CSPa22.so (Apache バージョン 2.2.x)
-
CSPa20.so (Apache バージョン 2.0.x)
Caché のアップグレード時に既存のゲートウェイに影響を与えないように、インストールの際にこれらのモジュールは以下の共通の場所に配置されます。この場所は、特定の Caché インスタンスに関するものではありません。
/opt/cspgateway/bin
元の場所 (/cache-install-dir/csp/bin) は、特定の Caché インスタンスの管理ポータルの提供に必要なゲートウェイ・コンポーネントの保持に使用されます。
Sys が追加されたモジュールは、CSP ウェブゲートウェイ管理ページにアクセスします。実行時モジュール (Sys が追加されていないモジュール) はCSP ウェブゲートウェイ管理ページにアクセスできません。
-
-
ハイパーイベントのコンポーネント
-
CSPBroker.js
-
CSPxmlhttp.js
これらのファイルの既定の場所は以下のとおりです。
/cache-install-dir/csp/broker
-
-
CSP サンプルで使用するその他の静的リソース
CSP サンプルでは、(イメージ・ファイルなど) いくつかの静的な Web リソースが必要になります。これらのファイルの既定の場所は以下のとおりです。
/cache-install-dir/csp/samples
-
管理ポータルで使用するその他の静的リソース。
管理ポータルでは、(イメージ・ファイルなど) いくつかの静的な Web リソースが必要になります。これらのファイルの既定の場所は以下のとおりです。
/cache-install-dir/csp/sys
推奨オプションまたは代替オプション 1 の手順を実行する前に、共有オブジェクトを管理するためのモジュール (mod_so) が、使用している Apache ビルドに組み込まれていることを確認してください。この確認を行うには、以下のコマンドを実行します。その結果、Apache で現在使用可能なモジュールが一覧表示されます。
httpd -l
表示されるモジュール・リストには、共有オブジェクト・モジュール (mod_so) が含まれているはずです。一般的なモジュール・リストは以下のとおりです (mod_so が含まれています)。
Compiled in modules:
core.c
mod_access.c
mod_auth.c
mod_include.c
mod_log_config.c
mod_env.c
mod_setenvif.c
prefork.c
http_core.c
mod_mime.c
mod_status.c
mod_autoindex.c
mod_asis.c
mod_cgi.c
mod_negotiation.c
mod_dir.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_so.c
インストールされている Apache に mod_so が含まれていない場合は、Apache ドキュメントを参照し、Apache を再構築してこのモジュールを追加するための手順に従ってください。
推奨オプション : NSD を使用しない Apache API モジュール (CSPa24.so)
このオプションは、管理ポータルにおけるプライベート Web サーバの構成で使用されます。
この接続オプションは、最適なパフォーマンスをもたらすだけでなく、構成が最も簡単です。
このオプションを使用する前に、Apache v2.x..x は部分的にマルチスレッド対応であり、マルチプロセスとマルチスレッド・サーバの組み合わせとして実装されていることを念頭に置く必要があります。つまり、実際の稼動では、Apache の子プロセスごとに CSP ゲートウェイのインスタンスが 1 つあることを意味します。これ自体は問題ではありませんが、このアーキテクチャでは、ゲートウェイの各インスタンスが Caché 接続プールを各自で管理するため、ゲートウェイで使用する Caché (および Caché プロセス) への接続数の制御が難しくなります。
これらのモジュールではステート認識接続 (保持モード 1) を使用しないでください。
CSPa24.so (実行時) モジュールおよび CSPa24Sys.so (ゲートウェイ・システム管理) モジュールは、ダイナミック・リンク・モジュール (DSO) です。
CSP 要求 (ファイル・タイプ .csp、.cls、および .zen) を認識し、それらを CSP ゲートウェイ・モジュールに渡して処理するように Web サーバを構成します。
-
Apache 2.4.x : CSPa24.so モジュールと CSPa24Sys.so モジュールを使用します。
-
Apache 2.2.x : CSPa22.so モジュールと CSPa22Sys.so モジュールを使用します。
-
Apache 2.0.x : CSPa2.so モジュールと CSPa2Sys.so モジュールを使用します。
Web サーバ構成ファイル (httpd.conf) は以下のディレクトリにあります。
/usr/apache/conf
Red Hat Linux の場合、httpd.conf の実行時バージョンは以下の場所に配置されています。
/etc/httpd/conf
Suse の場合、httpd.conf の実行時バージョンは以下の場所に配置されています。
/etc/apache2/conf
-
Apache 2.4.x : 以下のセクションを、httpd.conf の最後に追加します。
LoadModule csp_module_sa /opt/cspgateway/bin/CSPa24.so CSPModulePath /opt/cspgateway/bin/ <Location "/csp/bin/Systems/"> SetHandler cspsys-handler-sa </Location> <Location "/csp/bin/RunTime/"> SetHandler csp-handler-sa </Location> CSPFileTypes csp cls zen cxw Alias /csp/ /opt/cspgateway/csp/ <Directory "/opt/cspgateway/csp"> AllowOverride None Options MultiViews FollowSymLinks ExecCGI Require all granted <FilesMatch "\.(log|ini|pid|exe)$"> Require all denied </FilesMatch> </Directory>
Apache 2.2.x : 以下のセクションを、httpd.conf の最後に追加します。
LoadModule csp_module_sa /opt/cspgateway/bin/CSPa22.so CSPModulePath /opt/cspgateway/bin/ <Location "/csp/bin/Systems/"> SetHandler cspsys-handler-sa </Location> <Location "/csp/bin/RunTime/"> SetHandler csp-handler-sa </Location> CSPFileTypes csp cls zen cxw Alias /csp/ /opt/cspgateway/csp/ <Directory "/opt/cspgateway/csp"> AllowOverride None Options MultiViews FollowSymLinks ExecCGI Order allow,deny Allow from all <FilesMatch "\.(log|ini|pid|exe)$"> Deny from all </FilesMatch> </Directory>
Apache 2.0.x : 上記のセクションを、CSPa2.dll を使用して httpd.conf の最後に追加します。
-
httpd.conf の変更後に、Apache を再起動します。
CSP へのファイルの種類の追加登録
Apache API モジュールは、以下の予約されたファイル拡張子を常に認識します。
.csp .cls .zen .cxw
この他のファイルを CSP に送信して処理できます。例えば、CSP ゲートウェイを経由して他の静的ファイルを処理する必要がある場合、またはこの Web サーバを経由して管理ポータルにアクセスする必要がある場合は、ファイルの .jpg、.gif、.png、.css、.js の各種類に対してマッピングを追加します。
以下の方法で、CSP に渡すファイルを Apache が認識するように構成できます。
-
CSP の Location 指示文の使用
-
ファイル拡張子の使用 — CSPFileTypes 指示文
-
MIME タイプの使用
CSP 指示文を使用して、特定の位置にあるすべてのファイルが CSP によって処理されるように要求します。 パス /csp の下にあるすべてのファイルとディレクトリが CSP によって処理されるように要求するには、以下のように指定します。
<Location /csp>
CSP On
SetHandler csp-handler-sa
</Location>
例えば、以下のファイルはすべて CSP に送信されて処理されます。
/csp/
csp/samples/menu.csp
csp/sys/
CSPFileTypes 指示文は、拡張子を持つファイル (/csp/menu.csp など) に対する要求に適用されます。 ファイル拡張子を持たないファイル (/csp/menu など) への要求には適用されません。
このパラメータは、ゲートウェイの Apache モジュールにより処理され、(httpd.conf の) サーバ定義レベルでグローバルに定義されるか、または位置もしくはディレクトリ・ブロックに対する定義内に制限されます。
ファイルの種類で指定: .xxx と . yyy の両方の種類のファイルが CSP によって処理されるように要求するには、以下の指示文のように指定します。
CSPFileTypes xxx yyy
位置で指定 : 以下の要求では、.xxx と .yyy の両方の種類のファイルが CSP によって処理されますが、/csp よりも下の位置 (例えば、/csp/samples などのサブ・ディレクトリ) にあるファイルに限られます。
<Location /csp/>
CSPFileTypes xxx yyy
</Location>
ワイルドカード文字を使用して、パス /csp の下 (および /csp/samples など) にあるすべてのファイルが CSP によって処理されるように要求するには、以下のように指定します。
<Location /csp/>
CSPFileTypes *
</Location>
CSP は、前述のファイル拡張子に加えて、以下の MIME タイプのファイルを認識することもできます。
application/x-csp
および
text/csp
例えば、CSP によって処理されるファイルのリストにファイル拡張子 xxx を追加するには以下のように指定します。
LoadModule csp_module_sa /opt/cspgateway/bin/CSPa22.so
AddType application/x-csp csp cls zen xxx
MIME タイプを使用してファイルの種類を CSP と関連付けた場合の問題の 1 つに、リソースへのパス (ホスト・ディレクトリ) が物理的に存在することを Apache が確認し、存在しない場合には「ファイルが見つかりません」というエラーを返すことがあります。 しかし、要求されたファイルが物理的に存在することを保証するためのチェックは行われませんが、これは CSP によりサービスを受けるリソースには適切です。なぜならば、このようなリソースは Caché からサービスを受け、Web サーバからは仮想的なものだからです。 したがって、“MIME タイプによる指定” というアプローチは、アプリケーションのパス構造を Web サーバ上に複製できる場合のみ適しています。
Apache API を使用したゲートウェイの運用および管理
CSP ウェブゲートウェイ管理ページにアクセスするには、ブラウザで以下を指定します。
http://localhost:<port_no>/csp/bin/Systems/Module.cxw
cxw ファイル拡張子を使用することに注意してください。この拡張子は、Apache が、Apache グループの ISAPI インタフェースを介して、これらの DLL をロードして実行しないようにします。また、Apache の場合、URL のパス名とファイル名で大文字と小文字が区別されることに注意してください。
承認されないユーザであることを通知するエラー・メッセージが表示された場合は、"セキュリティの考慮事項" を参照してください。
.csp、.cls、および .zen 拡張子を含むファイルが要求されると、CSP エンジンが自動的に呼び出されます。以下はその例です。
http://localhost:<port_no>/csp/samples/menu.csp
承認されないユーザであることを通知するエラー・メッセージが表示された場合は、"セキュリティの考慮事項" を参照してください。
Sun の Web サーバ
このセクションでは、Sun の Web サーバを介して CSP を実行するための構成手順と操作手順を説明します。このドキュメントの説明は、以下のファイル・システムにインストールされている、CSP Web サーバのコンポーネントに基づいています。
/cache-install-dir/csp/
Web サーバは、以下のディレクトリにインストールされていることが前提となっています。
/usr/SUNWwbsvr/ (or /opt/SUNWwbsvr/)
Sun サーバの個々のインスタンスは、以下のフォームのディレクトリにインストールされます。
/usr/SUNWwbsvr/https-<server_name>/
または
/usr/SUNWwbsvr/httpd-<server_name>/
server_name は、ホスト・コンピュータに割り当てられた論理名です。
システムのレイアウトが異なる場合は、必要に応じて、この後のセクションで説明する構成指示文を修正してください。
通常、これらのサーバのドキュメント・ルート・ディレクトリは以下のとおりです。
/usr/SUNWwbsvr/docs/
Sun Web サーバのインストール場所 (推奨オプション)
以下の CSP ゲートウェイのコンポーネントおよび CSP 静的ファイルをインストールします。
-
NSAPI と CGI のモジュール
-
CSPn3.so (実行時モジュール)
-
CSPn3Sys.so (システム管理モジュール)
-
CSPcn3.so (提供される場合は、NSD の NSAPI クライアント)
-
CSPcgi.exe (実行時モジュール)
-
nph-CSPcgi.exe (CSPcgi のコピー)
-
CSPcgiSys.exe (システム管理モジュール)
-
nph-CSPcgiSys.exe (CSPcgiSys のコピー)
上記すべてのモジュールが各接続オプションで必要になるわけではありません。各オプションについてのセクションを参照し、実際に必要なモジュールを確認してください。
これらのモジュールの既定の場所は以下のとおりです。
/opt/cspgateway/bin
NSD ベース以外の接続オプションの場合、構成ファイル (CSP.INI) とイベント・ログ (CSP.LOG) はこのディレクトリに書き込まれます。
-
-
ハイパーイベントのコンポーネント
-
CSPBroker.js
-
CSPxmlhttp.js
これらのファイルの既定の場所は以下のとおりです。
/cache-install-dir/csp/broker
-
-
CSP サンプルで使用するその他の静的リソース
CSP サンプルでは、(イメージ・ファイルなど) いくつかの静的な Web リソースが必要になります。これらのファイルの既定の場所は以下のとおりです。
/cache-install-dir/csp/samples
-
管理ポータルで使用するその他の静的リソース。
管理ポータルでは、(イメージ・ファイルなど) いくつかの静的な Web リソースが必要になります。これらのファイルの既定の場所は以下のとおりです。
/cache-install-dir/csp/sys
推奨オプション : NSAPI モジュール (CSPn3.so)
CSP 要求 (ファイル・タイプ .csp、.cls、および .zen) を認識し、それらを CSP ゲートウェイに渡して処理するように Web サーバを構成します。
Web サーバ構成ファイル (magnus.conf と obj.conf) は、以下のディレクトリに配置されます。
/usr/SUNWwbsvr/https-<server_name>/config/
NSAPI モジュール、および CSP ファイルを認識して処理するための手順をロードする指示文を Web サーバ構成に追加する必要があります。
指示文
以下の各指示文サブセクションの指示に従います。
NSAPI モジュールをロードするための指示文
Init 指示文は、NSAPI モジュールをロードするよう Web サーバに指示します。これらの指示文は、コアの magnus.conf ファイルに追加する必要があります。これらのコア構成指示文は、以下のような形式で常に存在します。
Init fn=load-types mime-types=mime.types
コア Init 指示文のブロックを見つけて、そのブロックの前に以下のセクションを追加します。
Init fn=load-modules shlib=/opt/cspgateway/bin/CSPn3.so \
funcs=csp_term,csp_init,csp_req
Init fn=csp_init shlib=”/opt/cspgateway/bin/CSPn3.so”
Init 指示文は 1 行で構成されることに注意してください。ただし表示スペースに制限があるため、上に示す行は、機能宣言 (funcs) の前で折り返されています。
静的コンポーネントを見つけるための指示文
CSP には、Web サーバから提供されるいくつかの静的ファイルが含まれます。例えば、Java/JavaScript ファイルは、CSP サンプルで必要となるハイパーイベントとイメージを実装するために使用されます。これらのファイルについては、"インストール" のセクション 2 および 3 をそれぞれ参照してください。
Web サーバは、仮想 CSP ドキュメント・ルート・ディレクトリを基準として、これらのファイルの場所を把握する必要があります。
obj.conf の default 指示文セクションを探します。
<Object name="default">
default セクションで、上記の行の後に以下の行を追加します。
NameTrans fn="pfx2dir" from="/csp/samples" dir="/cache-install-dir/csp/samples"
NameTrans fn="pfx2dir" from="/csp/broker" dir="/cache-install-dir/csp/broker"
CSP 要求を認識および処理するための指示文
obj.conf の最後に以下のセクションを追加します。
<Object ppath="*/*.csp">
Service method=(GET|HEAD|POST) fn=csp_req
</Object>
<Object ppath="*/*.cls">
Service method=(GET|HEAD|POST) fn=csp_req
</Object>
<Object ppath="*/*.zen">
Service method=(GET|HEAD|POST) fn=csp_req
</Object>
<Object ppath="*/CSPn3Sys.so">
Service method=(GET|HEAD|POST) fn=csp_req
</Object>
<Object ppath="*/CSPn3.so">
Service method=(GET|HEAD|POST) fn=csp_req
</Object>
<Object ppath="*/Systems/Module.cxw">
Service method=(GET|HEAD|POST) fn=csp_req
</Object>
<Object ppath="*/RunTime/Module.cxw">
Service method=(GET|HEAD|POST) fn=csp_req
</Object>
CSP へのファイルの種類の追加登録
CSP により処理されるファイルの種類を追加構成するには、単に、通常のファイル拡張子 (csp、cls、zen) について (obj.conf の末尾に) 作成された構成ブロックを新しいファイル拡張子に対応するように複製します。
CSP ゲートウェイを経由して他の静的ファイルを処理する必要がある場合、またはこの Web サーバを経由して管理ポータルにアクセスする必要がある場合は、ファイルの .jpg、.gif、.png、.css、.js の各種類に対してマッピングを追加します。
すべてのファイルに対する要求を、指定されたパスの CSP にマップするには、このパスについてワイルドカードをセットアップします。 以下はその例です。
<Object ppath="/csp/*.*">
Service method=(GET|HEAD|POST) fn=csp_req
</Object>
このセクションにさらに構成ブロックを追加する必要はありません。 この変更の他、Web サーバ上の物理位置へのパスにエイリアスを付けるためにこれまで使用されていた構成指示文がすべて削除されていることを確認します。 つまり、以下の行 (または、類似する行) が obj.conf ファイルに追加されていてはいけません。
NameTrans fn="pfx2dir" from="/csp/samples" dir="/cache-install-dir/csp/samples"
NameTrans fn="pfx2dir" from="/csp/broker" dir="/cache-install-dir/csp/broker"
Sun NSAPI を使用したゲートウェイの運用および管理
Web サーバの構成ファイル (magnus.conf および obj.conf) を変更した後は、その Web サーバを再起動する必要があります。
CSP ウェブゲートウェイ管理ページにアクセスするには、ブラウザで以下の場所のいずれかを指定します。
http://localhost:<port_no>/csp/bin/Systems/Module.cxw
http://localhost:<port_no>/csp/bin/CSPn3Sys.so
承認されないユーザであることを通知するエラー・メッセージが表示された場合は、"セキュリティの考慮事項" を参照してください。
.csp、.cls、および .zen 拡張子を含むファイルが要求されると、CSP エンジンが自動的に呼び出されます。以下はその例です。
http://localhost:<port_no>/csp/samples/menu.csp
Nginx Web サーバ
Nginx はオープン・ソース製品で、ソース・コードは以下のサイトから無料でダウンロードできます。
http://nginx.org/Opens in a new tab
Linux 用の一部のビルド済みキットを入手できますが、通常、これは最新の Nginx ビルドよりもいくつか前のバージョンをビルドしたものです。 ただし、拡張子を Nginx コアにコンパイルする必要があるため、CSP のサポートを含めるには、Web サーバをソース・コードからローカルにビルドすることが必要です。
このドキュメントでは、CSP ゲートウェイ Web サーバのコンポーネントが以下のディレクトリにインストールされていると仮定します。
/opt/cspgateway/bin/
Caché がローカルにインストールされている場合は、以下のディレクトリにあると仮定します。
/opt/cachesys/
Web サーバは、以下のディレクトリにインストールされていることが前提となっています。
/opt/nginx/
システムのレイアウトが異なる場合は、必要に応じて、この後のセクションで説明する各種構成指示文を修正してください。
インストール
以下の CSP ゲートウェイのコンポーネントおよび CSP 静的ファイルをインストールします。
-
動的にリンクされるユニバーサル CSP ゲートウェイ・モジュール
-
CSPx.so (実行時モジュール)
-
CSPxSys.so (ゲートウェイ・システム管理モジュール)
これらのバイナリの既定の場所は以下のとおりです。
/opt/cspgateway/bin/
構成ファイル (CSP.INI) とイベント・ログ (CSP.LOG) は、このディレクトリに記述されます。
Sys が追加されたモジュールは、CSP システム管理スイートにアクセスするための特別なモジュールです。 実行時モジュール (Sys が追加されていないモジュール) はシステム管理のフォームにアクセスできません。
-
-
ハイパーイベントのコンポーネント
CSPBroker.js
CSPxmlhttp.js
これらのファイルの既定の場所は以下のとおりです。
/opt/cachesys/csp/broker
これらのファイルが静的コンポーネントとして Web サーバによって直接処理される場合は、以下の場所にコピーする必要があります。
/opt/nginx/html/csp/broker
-
CSP サンプルで使用するその他の静的リソース
CSP サンプルでは、(イメージ・ファイルなど) いくつかの静的な Web リソースが必要になります。 これらのファイルの既定の場所は以下のとおりです。
/opt/cachesys/csp/samples
これらが Web サーバによって直接処理される場合は、以下の場所にコピーします。
/opt/nginx/html/csp/samples
-
Caché SMP で使用するその他の静的リソース
SMP では、(イメージ・ファイルなど) いくつかの静的な Web リソースが必要になります。 これらのファイルの既定の場所は以下のとおりです。
/opt/cachesys/csp/sys
これらが Web サーバによって直接処理される場合は、以下の場所にコピーします。
/opt/nginx/html/csp/sys
詳細は、"Cach Server Pages (CSP) の使用法" の "静的ファイル" のセクションを参照してください。
CSP のための Nginx Web サーバの構築
CSP ゲートウェイ機能のほとんどは、ユニバーサル・モジュール (CSPx[Sys].so) によって提供されます。 CSP アクセスのために、小さなコンパイル済みモジュールを介してこれらのユニバーサル・モジュールと通信するように、Nginx を構築および構成することができます。
ngx_http_csp_module_sa.c
ここで説明する構築手順は、UNIX システム下で Nginx を構築するための公式ドキュメントに基づいています。
http://nginx.org/en/docs/configure.htmlOpens in a new tab
Nginx のドキュメントには、以下のサードパーティのアドオンが必要であると記載されています。
-
PCRE
-
OpenSSL
-
Zlib
ただし、最終インストールで、上記のコンポーネントによって提供される機能を必要としない場合は、これらのコンポーネントを使用しなくても充分に機能するサーバを作成することは可能です。
上記のオプションのモジュールすべてを含む、Nginx を構築するための一般的な構成スクリプトは、以下のとおりです。
./configure --prefix=/opt/nginx --with-http_ssl_module
これにより、既定の Nginx ビルドが /opt/nginx 下にインストールされます。
構築プロセスを以下のように変更して、オプションのモジュールを除外することもできます。
-
OpenSSL - SSL 機能を削除します。
指示文の削除:--with-http_ssl_module
-
Zlib - GZIP 機能を削除します。
指示文の追加:--without-http_gzip_module
-
PCRE - HTTP 書き換え機能を削除します。
指示文の追加:--without-http_rewrite_module
CSP のための Nginx の構築手順
-
ソース・ディストリビューションを任意の場所に解凍します。 例 :
/opt/
解凍後、/opt/ を指定すると、ソース・コード・ディストリビューションは以下に配置されます。
/opt/nginx-n.n.n/
-
CSP 拡張子に以下のディレクトリを作成します。
/opt/nginx-n.n.n/csp/
-
モジュールのソース・コード (ngx_http_csp_module_sa.c および cspapi.h) を、上記で作成したディレクトリにコピーします。
-
同じディレクトリ内に、config という名前の構成ファイルを作成します。 このファイルには、以下の行が含まれる必要があります。
ngx_addon_name=ngx_http_csp_module_sa HTTP_MODULES="$HTTP_MODULES ngx_http_csp_module_sa" NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_addon_dir/ngx_http_csp_module_sa.c" CORE_LIBS="$CORE_LIBS -ldl"
-
/opt/nginx-n.n.n/ で作業し、Nginx 構築環境を構成します。
./configure --prefix=/opt/nginx \ --with-http_ssl_module \ --add-module=/opt/nginx-n.n.n/csp
または、OpenSSL、ZLIB、および PCRE により提供されるオプションの機能を使用しない場合は、以下のようになります。
./configure --prefix=/opt/nginx \ --without-http_rewrite_module \ --without-http_gzip_module \ --add-module=/opt/nginx-n.n.n/csp
最後の行に、CSP モジュールをインクルードする指示が含まれることに注意してください。
-
Nginx のコンパイル:
make
-
Nginx のインストール:
make install
成功した場合、以下のディレクトリに完全なサーバ・インストールが表示されます。
/opt/nginx/
ユニバーサル CSP ゲートウェイ・モジュール (CSPx*.so) の使用
CSPx.so (実行時) および CSPxSys.so (ゲートウェイ・システム管理) ユニバーサル・モジュールは、CSP 対応 Nginx インストールによりロードされるよう設計されたダイナミック・リンク・モジュールです。
CSP 要求 (ファイル・タイプ .csp、.cls、および .zen) を認識し、それらを CSP ゲートウェイ・モジュールに渡して処理するように Web サーバを構成します。
Web サーバ構成ファイル (nginx.conf) は、以下のディレクトリにあります。
/opt/nginx/conf
CSP 拡張子用に、以下の構成指示文が用意されています。
-
CSPModulePath
http セクション:ユニバーサル・ゲートウェイ・モジュールへのパス
-
CSP
server セクション:パス全体に対して CSP を有効化
-
CSPFileTypes
server セクション:特定のファイルの種類に対して CSP を有効化
以下の指示文を http 構成ブロック内に配置します。
CSPModulePath /opt/cspgateway/bin/;
この指示文により、Nginx でユニバーサル・ゲートウェイ・モジュール (CSPx[Sys].so) および関連付けられた構成 (CSP.ini) を見つけられるようになります。
これで、CSP への特定のパスに対するすべての要求、または特定のファイルの種類のみを渡すように Nginx を構成できます。
ユニバーサル CSP ゲートウェイ・モジュール (CSPx*.dll) の使用
CSPx.dll (実行時) および CSPxSys.dll (ゲートウェイ・システム管理) ユニバーサル・モジュールは、CSP 対応 Nginx インストールによりロードされるよう設計されたダイナミック・リンク・モジュールです。
CSP 要求 (ファイル・タイプ .csp、.cls、および .zen) を認識し、それらを CSP ゲートウェイ・モジュールに渡して処理するように Web サーバを構成します。
Web サーバ構成ファイル (nginx.conf) は、以下のディレクトリにあります。
C:\nginx\conf
CSP 拡張子用に、以下の構成指示文が用意されています。
-
CSPModulePath
http セクション:ユニバーサル・ゲートウェイ・モジュールへのパス
-
CSP
server セクション:パス全体に対して CSP を有効化
-
CSPFileTypes
server セクション:特定のファイルの種類に対して CSP を有効化
Windows の場合、スレッド・スタック・サイズを 2MB まで増やす必要があります。 これを実行するには、以下の指示文を Nginx 構成ファイルの先頭 (http セクションの前) に追加します。
thread_stack_size 2000000;
以下の指示文を http 構成ブロック内に配置します。
CSPModulePath C:/cachesys/csp/bin/;
この指示文により、Nginx でユニバーサル・ゲートウェイ・モジュール (CSPx[Sys].dll) および関連付けられた構成 (CSP.ini) を見つけられるようになります。
これで、CSP への特定のパスに対するすべての要求、または特定のファイルの種類のみを渡すように Nginx を構成できます。
特定のパスに対する CSP の有効化
以下のセクションを適切な server 構成ブロック内に配置します。
location /csp {
CSP On;
}
CSP への特定のファイルの種類の登録
以下のセクションを適切な server 構成ブロック内に配置します。
location /csp {
CSPFileTypes csp cls zen cxw;
}
Nginx の起動および停止
最初に、Nginx にユニバーサル・ゲートウェイ・モジュール (/opt/cspgateway/bin/) を保持する場所に対する読み取り/書き込み権限があることを確認してください。 これは、ゲートウェイの構成ファイルおよびイベント・ログ・ファイル (CSP.ini および CSP.log) が保持される場所です。
Nginx を起動する方法は、以下のとおりです。
/opt/nginx/sbin/nginx
Nginx を停止する方法は、以下のとおりです。
/opt/nginx/sbin/nginx –s stop
ゲートウェイの運用および管理
CSP ゲートウェイのシステム管理スイートへアクセスするには、ブラウザで以下の場所を指定します。
http://<ip_address>/csp/bin/Systems/Module.cxw
cxw ファイル拡張子を使用することに注意してください。
.csp、.cls、および .zen 拡張子を含むファイルが要求されると、CSP エンジンが自動的に呼び出されます。 次に例を示します。
http://<ip_address>/csp/samples/menu.csp
承認されないユーザであることを通知するエラー・メッセージが表示された場合は、このドキュメントの "セキュリティの考慮事項" を参照してください。
CSP NSD コンポーネントを使用する Nginx の構築
Nginx は、ユニバーサル・モジュール (CSPx[Sys].dll) ではなく、CSP ゲートウェイの Network Service Daemon コンポーネント (CSPnsd[Sv].exe) を使用するよう構築することができます。 これを行うには、構築および構成手順を以下のように変更します。
-
ソース・コード・モジュール ngx_http_csp_module_sa.c の代わりに ngx_http_csp_module.c を使用して Nginx を構築します。
-
CSP (/opt/nginx/objs/lib/csp/config) の構成ファイルは、以下のようになります。
ngx_addon_name=ngx_http_csp_module HTTP_MODULES="$HTTP_MODULES ngx_http_csp_module" NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_addon_dir/ngx_http_csp_module.c"
-
Nginx 構成から CSPModulePath 指示文を削除します。
-
NSD コンポーネントを開始します。
通常 NSD コンポーネントの使用が適しているのは、CSP ステート認識モード (保持モード) の完全で信頼できるサポートを得るためです。 ただし、Nginx で最適の結果を得るには、アプリケーションを完全にステートレスにすることをお勧めします。