この版は、以下のプログラムに適用されます。
また、新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。
本マニュアルに関するご意見やご感想は、次の URL からお送りください。今後の参考にさせていただきます。
http://www.ibm.com/jp/manuals/main/mail.html
なお、日本 IBM 発行のマニュアルはインターネット経由でもご購入いただけます。詳しくは
http://www.ibm.com/jp/manuals/ の「ご注文について」をご覧ください。
(URL は、変更になる場合があります)
お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。
原 典: |
GC31-6920-00 WebSphere Application Server Caching Proxy Administration Guide Version 6.1 |
発 行: | 日本アイ・ビー・エム株式会社 |
担 当: | ナショナル・ランゲージ・サポート |
第1刷 2006.5
まえがきでは、本書の対象読者と目的、その編成、アクセシビリティー機能、規則と用語、および関連する文書について説明します。
Caching Proxy 管理ガイド は、オペレーティング・システムおよび提供されるインターネット・サービスの経験豊富な ネットワークおよびシステム管理者を対象に作成されています。Caching Proxy を事前に経験する必要はありません。
本書は、前のリリースの Caching Proxy をサポートするためのものではありません。
本書では、以下のような書体およびキー操作の規則を使用しています。
規則 | 意味 |
---|---|
太字 | グラフィカル・ユーザー・インターフェース (GUI) に関しては、太字は、メニュー、メニュー項目、 ラベル、ボタン、アイコン、およびフォルダーを示します。 また、太字にしないと周りのテキストと混同される恐れがあるコマンド名を強調するためにも 使用されます。 |
モノスペース | コマンド・プロンプトから入力する必要のあるテキストを示します。 また、モノスペースは、画面上のテキスト、コード例、およびファイルからの引用も示します。 |
イタリック | 指定する必要のある可変値を示します (例: fileName でファイルの名前を指定します)。 イタリックは、強調表示および書名の表示にも使用されます。 |
Ctrl-x | x がキーの名前である場合、制御文字のシーケンスを示します。例えば、Ctrl-c は、Ctrl キーを押しながら c キーを押すという意味になります。 |
Return | Return、Enter または左矢印が表示されていたキーを指します。 |
% | root 権限を必要としないコマンド の Linux(TM) および UNIX(R) コマンド・シェル・プロンプトを示します。 |
# | root 権限を必要とするコマンド の Linux および UNIX コマンド・シェル・プロンプトを示します。 |
C:¥ | Windows(R) コマンド・プロンプトを示します。 |
コマンド入力 | コマンドを "入力" する、または "発行" すると指示された場合は、コマンドを入力してから Return を押します。 例えば、「ls コマンドを入力してください」という指示は、 コマンド・プロンプトに ls とタイプしてから Return を押すという意味になります。 |
[ ] | 構文記述内のオプション項目を囲みます。 |
{ } | 構文記述内の、項目を選択する必要があるリストを囲みます。 |
| | 構文記述の中で { } (中括弧) で囲まれた選択項目リストにある項目を区切るために使用されます。 |
... | 構文記述内の省略記号は、前の項目を 1 回以上繰り返すことができることを示します。 例にある省略記号は、簡潔にするために例から情報が省略されていることを示します。 |
アクセシビリティ機能は、運動障害または視覚障害など身体に障害を持つユーザーがソフトウェア・プロダクトを快適に使用できるように サポートします。 WebSphere(R) Application Server, バージョン 6.1 の主なアクセシビリティー機能は次のとおりです。
ここでは、Caching Proxy コンポーネントの概説、構成および管理フォームおよび構成ウィザードの使用方法、ibmproxy.conf ファイルの手動による編集、プロキシー・サーバーの開始手順と停止手順について説明します。
ここには、次のトピックが含まれます。
リバース・プロキシーまたはフォワード・プロキシーとして機能することで、 Caching Proxy は、クライアントからのデータ要求をインターセプトし、 コンテンツ・ホスティング・マシンから要求された情報を取り出し、 そのコンテンツをクライアントに引き渡します。 一般に、この要求は Web サーバー・マシン (起点サーバーまたはコンテンツ・ホストとも呼びます) に 保管された文書に対して出されていて、HTTP (Hypertext Transfer Protocol) 経由で送達されることが 最も多くなっています。ただし、FTP (ファイル転送プロトコル) や Gopher など、他のプロトコルを扱う ように Caching Proxy を構成することができます。
Caching Proxy では、キャッシュ可能なコンテンツをローカル・キャッシュに保管してから リクエスターに引き渡します。キャッシュ可能なコンテンツの例としては、静的な Web ページ、 および動的に生成されるものの、まれにフラグメントが変化する JavaServer Pages (JSP) ファイル があります。キャッシングにより、Caching Proxy は、以後同じコンテンツが要求されたときにそのコンテンツをキャッシュから直接引き渡すことができるので、改めてコンテンツ・ホストから検索するよりはるかに迅速に処理できます。
重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。
2 つの基本プロキシー構成、リバース・プロキシーとフォワード・プロキシーがあります。
デフォルトでは、 Caching Proxy は、リバース・プロキシー・サーバーとして構成されています。 リバース・プロキシー構成では、プロキシー・サーバーは、 1 つ以上のコンテンツ・サーバーとインターネットの間に配置されます。 この構成は、プロキシー・サーバーのホーム・サイトに保管されているコンテンツについて、 インターネット・クライアントからの要求を受信します。 プロキシー・サーバーは、 クライアントにとっては起点 (コンテンツ) サーバーであるように見えます。 クライアントには、要求が別のサーバーに送信されたことは分かりません。
Caching Proxy を、フォワード・プロキシー・サーバーとして構成することもできます。 ただし、プロキシーを使用するために、 クライアント・ブラウザーを個別に構成する必要があります。 フォワード・プロキシー構成では、 プロキシー・サーバーは、クライアントとインターネットの間に配置されます。 Caching Proxy は、 クライアントの要求をインターネットを通じてコンテンツ・ホストに転送し、 取得データをキャッシュして、その取得データをクライアントに配布します。
フォワード・プロキシー構成を有効にするには、 ibmproxy.conf 構成ファイルで以下の変更を行う必要があります。
Proxy http:* Proxy ftp:* Proxy gopher:*
SSLTunneling OnSSL トンネリングの詳細については、SSL トンネリングの構成を参照してください。
Enable CONNECT OutgoingPorts Allまたは
Enable CONNECT OutgoingPorts 443
Enable CONNECT メソッドのフォーマットおよび使用可能なオプションについては、 SSL トンネリングの構成を参照してください。
これらの変更を行うと、フォワード・プロキシーは以下のことができるようになります。
フォワード Caching Proxy のバリエーションとして、透過 Caching Proxy があります。 このロールでは、Caching Proxy は基本のフォワード Caching Proxy と同じ機能を実行しますが、 その実行はクライアントに認識されません。 透過 Caching Proxy 構成は、Linux システムでのみサポートされています。
通常のフォワード Caching Proxy と同様、透過 Caching Proxy は、 インターネット/ゲートウェイ近くのマシンにインストールします。 ただし、クライアント・ブラウザー・プログラムは、 フォワード Caching Proxy に要求を直接送信するようには構成されません。 クライアントは、その構成にプロキシーが存在することを認識しません。 代わりに、クライアント要求をインターセプトし、 それらの要求を透過 Caching Proxy に送信するよう、ルーターが構成されます。
この構成のためのディレクティブについては、 TransparentProxy - Linux で透過プロキシーを使用可能にするを参照してください。
バージョン 6.1 の「Caching Proxy 管理ガイド」には、 新しく文書化されたフィーチャーおよび修正に関する更新情報が含まれています。
最も重大なフィーチャーには、次のようなものがあります。
フォワード・プロキシーの構成については、 フォワード・プロキシーを参照してください。
透過 (フォワード) プロキシー・ディレクティブについては、 TransparentProxy - Linux で透過プロキシーを使用可能にするを参照してください。
これらのメソッドについては、WebDAV メソッド、MS Exchange メソッド、 およびユーザー定義のメソッドを使用可能にするを参照してください。
これらのディレクティブについては、CompressionFilterAddContentType - 圧縮したい HTTP 応答のコンテンツ・タイプを指定するおよび CompressionFilterEnable - HTTP 応答を圧縮するための圧縮フィルターを有効にするを参照してください。
このディレクティブについては、NoCacheOnRange - Range 要求でキャッシングなしを指定するを参照してください。
このディレクティブについては、OptimizeRuleMapping - ルールの数が増加したときに、着信要求のためのルール・マッピング・プロセスを最適化するを参照してください。
MapQuery は、Map ディレクティブと類似したディレクティブです。 ルールを突き合わせるために、パス・ストリングと照会ストリングの両方を使用します。
このディレクティブについては、MapQuery - ルールの突き合わせを行うため、要求パスおよび照会ストリングを使用して、 マッチング要求を新規要求ストリングに変更するを参照してください。
このディレクティブについては、RuleCaseSense - 大/小文字を区別しないアプリケーション URL からの要求をマップするを参照してください。
これらのディレクティブについては、PKCS11DefaultCert、PKCS11DriverPath、 PKCS11TokenPassword - IBM 4960 PCI 暗号アクセラレーター・ カードをサポートする (AIX のみ)を参照してください。
このディレクティブの論理式オプションについては、 SSLCertificate - 証明書の鍵ラベルを指定するを参照してください。
Caching Proxy には、 実行時に追加のパターン・マッチングを必要とするディレクティブが提供されています。 Caching Proxy のパフォーマンスを向上させるために、これらのディレクティブを、 Proxy または ProxyWAS ルールのオプションとして使用することができます。 Proxy または ProxyWAS ルールのこれらの追加オプションについての詳細は、 Proxy - プロキシー・プロトコルまたはリバース・プロキシーを指定するを参照してください。
Caching Proxy は、プロキシー・サーバーを構成するようにクライアントに要求し、そのために使用できる HTML フォームと一緒に出荷されます。 これらのフォームは、ローカル・プロキシー・サーバー構成ファイル ibmproxy.conf を編集する CGI プログラムを実行します。 これらのフォーム を使用するには、プロキシー・サーバーが実行中で、フォームが入っている ローカル・ディレクトリーからそのフォームを渡せるように構成されていなければなりません。
デフォルトでは、Caching Proxy は ibmproxy.conf に組み込まれた PASS ディレクティブで インストールされ、これにより「構成および管理」フォームにアクセスできるようになります。クライアントが このプロキシー・サーバーからデフォルトのホーム・ページを要求すると、Frntpage.html が表示 されます。 このページには、「構成および管理」フォームの開始ページ wte.html へのハイパーテキスト・ リンクが入っています。
「構成および管理」フォームは保護されているので、使用する前にクライアント認証が必要です。管理者の ID および パスワードの設定方法については、管理者のパスワードの設定を参照してください。
「構成および管理」フォームへのアクセスに使用する Web ブラウザーは、以下の要件をサポートしている必要があります。
推奨されるブラウザーは、 Mozilla および Firefox (Linux、UNIX、および Windows システムの場合)、 および Internet Explorer (Windows システムの場合) です。Mozilla、Firefox、および Internet Explorer などの各ブラウザーの具体的なバージョンについては、 次の Web サイトを参照し、 サポートされるソフトウェアについての Web ページへのリンクをたどってください: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
「構成および管理」フォームにアクセスするには、次の手順を実行してください。
http://your.server.name[:port][/directory][/page.html]ここで、
The requested configuration changes have been completed successfully入力が受け入れられない場合には、上部のフレームにエラー・メッセージが表示され、どの設定が受け入れられなかったかが示されます。
Caching Proxy パッケージをインストールした後で、「構成および管理」フォームにアクセスするために 管理者 ID とパスワードを作成する必要があります。 デフォルトの プロキシー・サーバー 構成では、「構成および管理」フォームを要求したユーザーについて、 Linux および UNIX システムの /opt/ibm/edge/cp/server_root/protect/ ディレクトリー、 または Windows システムの ¥Program Files¥IBM¥edge¥cp¥etc¥ ディレクトリーにある webadmin.passwd パスワード・ ファイルを使用して認証を行います。 パッケージのインストールでは、既存の webadmin.passwd ファイルは上書きされません。
webadmin.passwd ファイルに管理者項目を追加するには、次のコマンドを使用します。
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwdプロンプトが出されたら、htadm プログラムに 管理者のユーザー名、パスワード、および実名を指定します。
cd "¥Program Files¥IBM¥edge¥cp¥server_root¥protect¥" htadm -adduser webadmin.passwd"プロンプトが出されたら、htadm プログラムに 管理者のユーザー名、パスワード、および実名を指定します。
htadm コマンドの詳細については、htadm コマンドを参照してください。
Caching Proxy 構成ウィザードを使用すると、インストール済みの Caching Proxy を迅速に構成することができます。 このプログラムは、Caching Proxy の動作を代理として機能するように変更する、必須のディレクティブのみを設定します。プロキシー・サーバーには、追加の構成が必要になる場合があります。
Caching Proxy 構成ウィザードを使用するには、次のようにします。
Windows システムでは、「スタート」->「プログラム」->「IBM WebSphere」->「Edge Components」->「Caching Proxy」->「構成ウィザード」をクリックします。
Linux および UNIX システムでは、コマンド /opt/ibm/edge/cp/cpwizard/cpwizard.sh を入力します。
Port port Proxy /* http://content server :port
例:
Proxy /* http://content server :443
または
Proxy /* https://content server :443
Linux システムにおける制限事項: Caching Proxy 構成ウィザードでは、キーボード・ショートカットは機能しません。
Caching Proxy は、ibmproxy 構成ファイルを編集することで手動で構成するか、 構成および管理フォームを使用して構成することができます。
構成ファイルはディレクティブと呼ばれるステートメントで構成されます。構成を変更するには、構成ファイルを編集し、ディレクティブを変更することによって、変更を保管します。構成ファイルの編集には、emacs や vi など、ほとんどすべてのテキスト・エディターを使用できます。
構成ファイルに対する変更は、サーバーを再始動したときに有効となります。 ただし、表 6 に示されているディレクティブのいずれかを変更した 場合は別です。そのリストにあるディレクティブのいずれかを変更した場合には、 サーバーを一度停止してから、再び始動しなければなりません。 詳細については、Caching Proxy の開始および停止を参照してください。
付録B. 構成ファイル・ディレクティブでは、各構成ファイル・ディレクティブおよび構文の詳細について説明しています。
Caching Proxy は、オペレーターの介入を最低限に抑え、バックグラウンド・プロセスとして継続実行 するように設計されています。通常、プロキシー・サーバーはマシンのブート・サイクル中に開始し、 保守が必要な場合にのみ停止します。プロキシー・サーバーは必要に応じて手動で開始することができます。 また、プロキシー・サーバーにはアクティブなクライアント接続を中断させることなく、効果的にプロキシー・サーバーを 停止して開始するという再始動命令を渡すことができます。
Linux および UNIX システムでは、Caching Proxy のインストール時に、 ibmproxy 初期化スクリプトと、関連するシンボリック・リンクが、 該当する /etc/ ディレクトリーに配置されます。 これらのスクリプトは、オペレーティング・システムの始動および終了ルーチンに組み込まれます。 自動再始動のための構成の設定値は、ibmproxy スクリプトを編集し、ibmproxy コマンドのオプションを変更して変更することができます。
Caching Proxy 初期化スクリプトは、Solaris のシステム全体のファイル記述子に関する制限によって、 必要なファイル記述子の最大数を設定できない場合があります。システム全体の最大値が Caching Proxy 初期化 スクリプトの設定値より小さい場合には、システム全体の制限が使用されます。値が小さすぎる (1024 未満) ことから生ずるプロキシーのパフォーマンス問題を回避するために、ファイル記述子の制限を変更することができます。 現在使用可能な記述子の数を調べるには、 ulimit コマンドを出してください。 値が 1024 より小さい場合には、ファイル記述子の制限を大きくしてください。ファイル記述子の制限を 1024 まで大きくするには、以下の行を /etc/system ファイルに追加してください。
set rlim_fd_cur=0x400
自動始動と終了を使用不可にする
自動始動と終了を使用不可にするには、次のようにします。
SUSE Linux では、ibmproxy への次のリンクを除去します。
始動メソッドには関係なく、最終的に ibmproxy コマンドが直接コマンド・プロンプトから呼び出されるか、またはスクリプトから呼び出されます。ibmproxy コマンドの詳細については、ibmproxy コマンドを参照してください。 以下に、最も一般的に使用される引き数だけを指定した例を挙げます。
startsrc -s ibmproxy
startsrc -s ibmproxy -e "LC_ALL=locale"
ibmproxy
/sbin/init.d/ibmproxy start
/usr/sbin/ibmproxy
/usr/sbin/ibmproxy -nobg
/etc/rc.d/init.d/ibmproxy start
/usr/sbin/ibmproxy
/usr/sbin/ibmproxy -nobg
squidConfig.file -r /etc/errors_icons.conf
ここで、errors_icons.conf ファイルは、ディレクトリーのブラウズ時に指定されたファイル・タイプに対して使用するアイコンを識別します。
/etc/init.d/ibmproxy start
/usr/sbin/ibmproxy
/usr/sbin/ibmproxy -nobg
Caching Proxy が Windows サービスとしてインストールされている場合には、 他の Windows サービスと同様に開始することができます。
サービスとして Caching Proxy をインストールした場合、Windows の開始時に、そのサーバーが自動的に始動するように構成することができます。そのような場合、プロキシーが要求を満たすことができるようにするために、ログオンする必要はありません。プロキシーを自動的に開始させるには次のようにしてください。
PATH 環境変数のリフレッシュ
「サービス」ウィンドウで Caching Proxy が開始済みと マークされているが、プロキシーが作動していない場合は、プロキシーのインストール後 にマシンが再始動されていない可能性があります。Caching Proxy サービスがデスクトップと対話するように設定されている場合には、 再始動していないと、ポップアップ・ボックスにエラー・メッセージ 「メッセージ・カタログ・エラー: メッセージ・カタログをロードできないか、または無効です」 が現れることがあります。
Windows レジストリーで PATH 環境変数がリフレッシュされるように、マシンを再始動する必要があります。 レジストリーがリフレッシュされていない場合には、 PATH 変数は正しい Caching Proxy および GSK7 パスを示していても、 正しく機能しない可能性があります。
この問題は、Windows PATH 環境変数内で Caching Proxy サービスのパスの前に、ファイル・システム・サービスのパスが現れた場合に発生します。PATH 変数を変更して ファイル・システム・サービスを設定の終わりの方に配置すると、この問題を解決できます。
この問題は、Windows サービスとして稼動していないアプリケーションによって制御されているリモート・ドライブには影響しません。例えば、Caching Proxy ローカル・エリア・ネットワーク (LAN) を介して可視の Windows マシン上の共用ドライブにアクセスできます。
Caching Proxy が Windows アプリケーションとしてインストールされると、インストール・プロシージャーによって、Caching Proxy 項目が「スタート」メニューのサブメニューとして作成されます。 Caching Proxy をアプリケーションとして始動するには、「スタート」->「プログラム」->「IBM WebSphere」->「Edge Components」->「Caching Proxy」をクリックします。
この始動プロシージャーによって、現在の構成設定値を使用してプロキシー・サーバーが実行されます。始動時に他 の設定値を指定したい場合は、コマンド始動プロシージャーを使用します (次のセクションを参照してください)。
Windows または DOS コマンド・プロンプトからサーバーを始動するには、ibmproxy コマンドを使用します。サーバーをインストールした後で Windows を終了して再始動していない場合には、このコマンドで絶対パス名を入力します。デフォルトでは、以下のとおりです。
c:¥Program Files¥IBM¥edge¥cp¥bin¥ibmproxy.exe
ibmproxy コマンドは、サーバーを現行の構成の設定で始動します。インストール以降、サーバー構成を変更していなければ、現行の構成は、インストール時に入力した情報と、デフォルト・オプションをベースにします。
Caching Proxy をサービスとして実行するようにインストールしている場合でも、ibmproxy コマンドは、 サーバーをアプリケーションとして始動します。強制的にサーバーをアプリケーションとして実行する場合には、 コマンド・オプション -noservice を指定することもできます。 他のコマンド・オプションでは、実行時に構成の設定値が変更されます。
プロキシー・サーバーの複数のインスタンスを同時に実行することができますが、それぞれのインスタンスは、別々のポートを listen しなければなりません。AIX システムは、SRC では、1 つのインスタンスしか開始することができません。構成ファイルはポート番号を識別し、この番号は特定のマシンで各サーバーに対して異なっている必要があるので、サーバーのすべてのインスタンスに対して固有の構成ファイルを指定しなければなりません。 サーバーの追加のインスタンスを (少なくとも 1 つのインスタンスがすでに実行中のとき) 開始するには、次のコマンドを入力します。
ibmproxy -r other_config_file
ibmproxy -noservice -r other_config_file
ここで、other_config_file は固有の構成ファイルです。
サーバーの複数のインスタンスを開始するときには、インスタンスごとに表示されるプロセス ID を記録しておきます。この ID はサーバーの特定のインスタンスを停止するために必要です。
サーバーを停止するには、次のような条件があります。
始動メソッド | 停止メソッド |
/etc/inittab (AIX の場合) | stopsrc -s ibmproxy を入力します。 |
/sbin/init.d (HP-UX の場合) | /sbin/init.d/ibmproxy stop を入力します。 |
/etc/rc.d/init.d (Linux の場合) | /etc/rc.d/init.d/ibmproxy stop を入力します。 |
ibmproxy |
このマシン上のすべてのサーバーを停止するには、 killall ibmproxy と入力します。 |
ibmproxy -nobg | ctrl-c を入力します。 |
ibmproxy -r -other_config_file (AIX の場合) | stopsrc -s ibmproxy -p process_id を入力します。 |
ibmproxy -r -other_config_file (Linux の場合) |
|
ibmproxy -unload
サーバーを停止するには、root プロンプトで次のように入力します。
終了コマンドを使用する場合には、以下の制限があります。
AIX、HP-UX、および Linux システムでは、Caching Proxy システムを停止させるためのコマンドが、Caching Proxy プロセスのみを終了させることがあります。この動作の原因となる AIX コマンドは、stopsrc -s ibmproxy コマンドです。この動作の原因となる HP-UX および Linux コマンドは、ibmproxy -stop コマンドです。
LDAP サーバーで使用される PACD プロセスは、プロキシー・サーバーの終了後も 稼働したまま残ることがあります。以下のような kill コマンド を使用することによって、PACD プロセスを安全に終了させることができます。
kill -15 PACD_process_ID
Solaris システムで ibmproxy -stop コマンドを発行しても、 他のオペレーティング・システムで発行された場合と同じ効果が生じません。 Solaris コードの制限のため、ibmproxy -stop が Solaris プラットフォーム で使用された場合は、サーバー終了プラグイン・ステップが実行されません。
この制限は、プロキシー・サーバー・ソフトウェアの場合と同様に、ユーザーがインプリメントする プラグインでも適用されます。
LDAP サーバーで使用される PACD プロセスは、プロキシー・サーバーの終了後も 継続して稼働することが可能です。以下のような kill コマンド を使用することによって、PACD プロセスを安全に終了させることができます。
kill -15 PACD_process_ID
他の Windows プログラムを停止するのと同じ方法で、Caching Proxy サーバーを停止することができます。
プロキシーをサービスとしてインストールする場合は、次のようにします。
プロキシーがサービスとしてインストールされていない場合は、Caching Proxy を 停止するために次のいずれかを行います。
サーバーの構成を (「構成および管理」フォームを使用するか、または ibmproxy.conf ファイルを編集して) 変更した後では、サーバーを再始動しなければその変更は有効となりません。 ほとんどの場合、最初 にサーバーを停止せずに再始動することができますが、再始動するだけではリフレッシュされない設定も あります。 詳しくは、表 6 を参照してください。
サーバーを最初に停止しないで再始動するには、任意の「構成および管理」フォームの「再始動」ボタンをクリックするか、またはコマンド ibmproxy -restart を入力します。
ここでは、Caching Proxy コンポーネントがオペレーティング・システム、コンピューター・ハードウェア、 およびネットワークと対話する仕組みについて説明します。また、この対話を構成する手順に ついても説明します。プロキシー・サーバーを構成するこれらの要素は、通常、システム管理者が管理し、 使用可能メモリーや CPU サイクルなどのシステム・リソースと同様、IP アドレスやホスト名 などのネットワーク・リソースと入念に整合性をとる必要があります。
ここには、次のトピックが含まれます。
一般に Caching Proxy は、ネットワーク・サーバーとして機能するように構成されたホスト・ コンピューター・システムにおいて、バックグラウンド・プロセスとして稼働します。 このプロセスは、ホスト・コンピューター・システム上のアクティブな 1 つまたはすべてのインターネット・プロトコル (IP) アドレスに関連付けられて (バインドされて) います。 プロセスは指定されたポートで FTP や HTTP などのさまざまなインターネット・プロトコルを listen し、 動作構成に従ってこれらの要求についてアクションを実行します。(詳細については、Caching Proxy の動作の構成を参照してください。)
デフォルトでは、Caching Proxy はホスト・コンピューター・システムの名前を想定しています。このデフォルトの動作は、 プロキシー・サーバーのホスト名を故意に指定することにより、上書きできます。Caching Proxy を特定の IP アドレスにバインドするためには、 プロキシー・サーバーのホスト名をその IP アドレスと同じに変更する必要があります。
プロキシー・サーバーのホスト名は、クライアント・トラフィックの解決方法には影響しません。 プロキシー・サーバーでは自身のホスト名を HTTP 要求のヘッダーにあるホスト名引き数の値と比較しません。 プロキシー・サーバーのホスト名は、エラー・メッセージなど、動的に生成されたローカルなコンテンツ・ページに 取り込まれる場合もあります。また、HTTP ヘッダーにある Via 引き数の値として要求クライアントに返されることもあります。
宛先サーバーに要求を引き渡す前に、要求元クライアントのホスト名をプロキシー・サーバーの ホスト名で置換するようにプロキシー・サーバーを構成することができます。置換するように構成すると、 宛先サーバー側ではクライアントとの直接接続が確立されずに、強制的にプロキシー・サーバーを経由した 通信チャネルが維持されます。
プロキシー・サーバー・プロセスを定義するには、ホスト・コンピューター・システムにあるプロキシー・サーバー・ファイルの実際のロケーションとプロキシー・サーバー自身を表す名前、 ServerRoot、Hostname、Port の各ディレクティブの値として listen するポートをそれぞれ指定します。 ホスト側に複数の IP アドレスがある場合にプロキシー・サーバーを特定のアドレスにバインドするには、 BindSpecific ディレクティブの値を On に設定し、Hostname ディレクティブの値をその IP アドレスと同じになるように設定します。
管理ポートは、「構成および管理」フォームへのアクセス・メソッドおよび サーバーの保守メソッドを提供します。管理ポート経由でプロキシー・サーバーにアクセスできるようにするには、 AdminPort ディレクティブに値を指定します。 管理ポートで受信した要求は、標準ポートで受信した要求のキューには入りません。 ただし、マッピング・ルールを記述してこのポートからの「構成および管理」フォームへのアクセスを許可することができます。
BindSpecific ディレクティブが使用可能にされると、 Caching Proxy は Port ディレクティブで指定されたポートと、 Hostname ディレクティブの値から導き出した IP アドレスとにバインドされます AdminPort ディレクティブに指定されたポートは システムで利用可能なすべての IP アドレスにバインドされます。
IBM-PROXY または IBM_HTTP_SERVER など、実行中サーバーのデフォルト名を上書きするには、 HeaderServerName ディレクティブに値を指定します。 この値によって HTTP 応答サーバー・フィールドが設定されます。
プロキシー・パフォーマンスを向上させるには、PureProxy ディレクティブの値を on に設定します。これによって、すべてのキャッシング機能が使用不可になります。
以下のディレクティブでプロキシー・サーバー・プロセスを定義します。
詳細については、ibmproxy.conf ファイルの手作業での編集 を参照してください。
以下の「構成および管理」フォームを使用して関連するディレクティブの値を編集します。
詳細については、「構成および管理」フォームの使用を参照してください。
スーパーユーザー root 以外のユーザーが Caching Proxy を始動すると、そのユーザーが プロキシー・サーバーに関連するプロセスすべての所有権を維持します。ただし、 スーパーユーザー root が Caching Proxy を始動すると、プロキシー・サーバー内に設定された ユーザー ID 機能によって ibmproxy.conf ファイルの UserId および GroupId ディレクティブが読み取られ、プロセス所有権は指定のユーザーおよびグループに変更されます。 これは、ファイル・アクセスを制限し、コンピューター・システムを保護するために実施されます。 UserId または GroupId ディレクティブを変更する場合は、ログ・ディレクトリーと、プロキシー・サーバーで 使用するアクセス制御リスト (ACL) などのその他のファイルについて、所有権およびアクセス権を更新する必要があります。
プロキシー・サーバー・プロセスの所有権を確立するには、UserID、GroupID、 および PidFile ディレクティブの値としてそのプロセス ID が記録されているユーザー ID、 グループ識別、およびファイルの位置を指定します。
強制的に プロキシー・サーバー・プロセスをフォアグラウンド・プロセスとして実行するには、 NoBG ディレクティブの値を on に設定します。
Linux システムの場合:
Linux システムの場合は、接続を listen する役割のあるプロセスとスレッドに ついてのみ、所有権を変更します。ワークフロー内の他のアクティビティーを管理する プロセスおよびスレッドは、依然として root が所有します。すべてのプロセスとスレッドで、 プロセス ID (PID) 番号を受け取ります。 ps コマンドを使用すると、関連付けられているのがプロセスか スレッドかに関係なく、すべてのプロセス ID がリストされます。
Cannot init groups for user nobody, errno: 1そのエラー・メッセージを無視することができます。Caching Proxy の通常操作に 何の影響もないからです。 Caching Proxy を開始する前に、以下の環境変数をエクスポートすることによって、 エラー・メッセージを回避する次善策もあります。
export RPM_FORCE_NPTL=1 export LD_ASSUME_KERNEL=2.4.19:
以下のディレクティブでプロキシー・サーバー・プロセスの所有権を確立します。
詳しくは、ibmproxy.conf ファイルの手作業での編集 を参照してください。
以下の「構成および管理」フォームを使用して関連するディレクティブの値を編集します。
詳細については、「構成および管理」フォームの使用を参照してください。
Caching Proxy は新規スレッドを作成して各クライアント要求を処理します。使用可能なスレッドがない場合、プロキシー・サーバーは、使用可能なスレッドが出てくるまで要求を保留します。アクティブ・スレッドの数が増加するにつれて、プロキシー・サーバーはより多くのメモリーを消費します。 アクティブ・スレッドの最大数を MaxActiveThreads ディレクティブの値として指定してください。
listen バックログは、サーバーが新規クライアントとの接続を拒否するまでに記録する、 クライアント接続の保留要求数です。この設定は、サーバーが数秒間で処理できる 要求の数に基づいて行います。 クライアントの接続がタイムアウトになる前に、サーバーが接続に応答することが必要です。 バックログに記録できる最大の接続数を ListenBacklog ディレクティブの値として指定してください。
プロキシー・サーバーにより、持続クライアント/サーバーの接続が維持されます。 持続接続により、サーバーはクライアントから多重要求を受け入れ、同じ TCP/IP 接続により応答を送信します。 持続接続機能を使用すると、クライアントの待機時間が短縮され、プロキシー・サーバー上の CPU の負荷が軽減されますが、低コストではあるものの、サーバー・メモリーはわずかに増加します。 それぞれの 要求や応答ごとに個別に TCP/IP 接続をサーバーが確立しなくてもよいときには、 全体的なスループットが向上し、接続が持続的な場合は、TCP/IP 接続は 最大限の効率で使用されます。
サーバー側接続プールによって、プロキシー・サーバーと起点サーバーとの間の既存の接続を再使用することにより、 サーバー側で持続接続機能を活用できます。接続が再使用されるたびに、3 つの TCP パケット (接続をセットアップするための 2 つのスリーウェイ・ハンドシェーク・パケットとそのクローズ用に 1 つ) が保管されます。サーバー側接続プールの利点は、以下のとおりです。
サーバー側の接続プールが使用可能になっていると、起点サーバーへの HTTP 接続がプール されます。プロキシーの SSLEnable ディレクティブが on に設定されている構成では、SSL 接続もプールされます。
1 回にサーバー当たりで保持するアイドル・ソケットの最大数、アイドル状態の持続接続を 終了するまでサーバーが待機する時間、およびガーベッジ・コレクション・スレッドが接続の タイムアウトを検査する時間間隔 (デフォルトは 2 分間) を指定して、接続プールが維持される方法を構成します。
各種接続がオープンした状態の時間を、 InputTimeout、 OutputTimeout、 PersistTimeout、 ReadTimeout、 および ScriptTimeout の各ディレクティブの値として定義します。
以下のディレクティブで プロキシー・サーバー・プロセスとの接続を管理します。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
以下の「構成および管理」フォームを使用して関連するディレクティブの値を編集します。
詳細については、「構成および管理」フォームの使用を参照してください。
システムの適切なセットアップと調整によって、Caching Proxy のパフォーマンスを著しく 向上させることができます。セットアップおよび調整の改善については、以下の説明を 参考にしてください。
以下のディレクティブはプロキシー・サーバー・プロセスのパフォーマンスに大きく影響します。
以下の「構成および管理」フォーム・フィールドを使用して関連するディレクティブの値を編集します。
システム上で実行されているサービスまたはデーモンを調べ、使用可能メモリーの増加や CPU サイクルの向上に必要のないものを除去します。例えば、Web ページをわずかしか提供しない Web サーバーをシステムで稼働している 場合、Caching Proxy を唯一の Web サーバーとして使用することを検討してみてください。 次の手順を実行して、他の Web サーバーを使用不可にします。
適切なオペレーションに必要なだけのページング・スペースが、使用しているシステムにあることを確認してください。システムには、物理メモリーの 2 倍のページング・スペースがなければなりません。 可能なら、 ページング・スペースを複数の物理ドライブに分散してください。 例えば、512 MB のメモリーと 5 台の SCSI ドライブを装備した Netfinity 5000 サーバーには、ドライブごとに約 200 MB ずつ、合計 1 GB のページング・スペースが必要です。
Caching Proxy は、オペレーション中に多数のファイルを作成したり破棄したりします。プロキシー・サーバーが アクセスを記録する場合 (アクセス・ログ、プロキシー・アクセス・ログ、または キャッシュ・アクセス・ログを使用して)、そのログが予想外に大きくなったときに、 別の機能 (例えば、キャッシュ) のためのスペースを使用しないよう、ログ固有の ファイル・システムにそのログを送る必要があります。
Caching Proxy は、TCP/IP 構成の変更に敏感です。 いずれかのオペレーティング・システムで TCP/IP 値を下げると、予期しない方法でプロキシー・サーバーが実行される原因となる場合があります。 とりわけ、TCP/IP 値の設定が低すぎると、プロキシー・サーバーに接続されたクライアントよって、またはプロキシーが接続される発信元サーバーによって、接続がリセットされる場合があります。 これは特に、低帯域幅の接続 (56700 bps 以下) を介してプロキシー・サーバーに接続されるクライアントの場合に当てはまります。 TCP/IP パラメーターを下げる必要がある場合は、注意して進めてください。
TCP 時間待ち間隔は、強制的にクローズするまでに、ソケットが送信側からの FIN パケットを待つ、時間の長さを指定します。 強度のロード環境においては、大量のソケットが、その接続がクローズされた後も TIME_WAIT 状態で保留のままになっている場合、プロキシー・サーバーが停止しているように見える場合があります。 TCP 時間待ち間隔を減らすことで、保留にされるソケットの数が削減され、強度のロード環境では、プロキシー・サーバーが停止しているように見えるのを防止することができます。 この間隔は 5 秒に設定することをお勧めします。
TCP 時間待ち間隔を 5 秒に設定するには、以下のようにします。
以下のコマンドを実行します。
ndd /dev/tcp -set tcp_time_wait_interval 5000
「SAM」ユーティリティーを使用し、カーネル・パラメーター max_thread_proc を少なくとも 2048 に設定します。
以下のコマンドを実行します。
echo "1024 61000" > /proc/sys/net/ipv4/ip_local_port_range echo "5" > /proc/sys/net/ipv4/tcp_fin_timeout
以下のコマンドを実行します。
ndd /dev/tcp -set tcp_time_wait_interval 5000
/etc/system ファイルを編集して、以下のようにします。
set tcp:tcp_conn_hash_size=8129
TCP 時間待ち間隔をセットする、レジストリー項目を作成する必要があります。 詳しくは、Windows の資料を参照してください。
Linux カーネルの限界値の中には低いものがあり、変更することができます。 /proc ファイル・システム を介して変更されるものもあれば、カーネルの再コンパイルが必要なものもあります。
注: /proc ファイル・システムは仮想ファイル・システムです。つまり、ディスク上に実在するものではありません。 実在はしませんが、Linux カーネルへのインターフェースの役目を果たします。 実在しないので、リスタート時に入力値は失われます。 したがって、/proc ファイル・システムに加える変更は、RedHat の /etc/rc.d/rc.local ファイル または SUSE の /etc/rc.config ファイルに入れてください。そうすると、リスタート時に必ず変更が有効になります。
次のことをお勧めします。
echo 32768 > /proc/sys/fs/file-max
echo 65536 > /proc/sys/fs/inode-max
echo 32768 61000 > /proc/sys/net/ipv4/ip_local_port_range
カーネルの再作成を決めた場合は、確実に必要なオプションだけを使用可能にしてください。必要のないデーモンは、実行しないでください。
AIX システムでは、システム・スコープ・スレッドを使用して、スレッドが複数のヒープを使用することを許可すると、Caching Proxy パフォーマンスを向上させることができます。パフォーマンスは、オペレーティング・システムのマルチプロセッシング機能、および根本的なオペレーティング・システムのスレッド・スケジューリングと関連しています。AIX スレッド・チューニング変数を次のように設定すると、パフォーマンスを改善することができます。
export AIXTHREAD_SCOPE=S export SPINLOOPTIME=500 export YIELDLOOPTIME=100 export MALLOCMULTIHEAP=1
これらの環境変数は、/usr/sbin/ibmproxy を開始する前に設定するか、または startsrc -s ibmproxy を使用してプロキシー・サーバーを開始する場合には、/etc/rc.ibmproxy に追加することができます。これらのスレッド環境変数を調整すると、SMP システムにおける パフォーマンスの向上がさらに顕著になります。ただし、単一プロセッサー・システム上でも パフォーマンスの向上が明白になる場合があります。
ここでは、Caching Proxy コンポーネントがクライアントの要求に応える仕組みと、この動作の 構成手順について説明します。これらのプロキシー・サーバー構成要素は、通常、Web 管理者が管理しており、 同じネットワーク内のホスト・コンピューター・システム上でも、他のコンピューター・システム 上でもその他のプロセスには影響しません。
ここには、次のトピックが含まれます。
Caching Proxy はクライアント要求を受信すると、要求されたメソッドが使用可能であれば、 URL フィールドに指定されたオブジェクト上のメソッド・フィールドで指定されたアクションを実行します。 プロキシー・サーバーは管理者が定義したマッピング・ルール・セットに従って URL を変換します。 これらのマッピング・ルールによって、Caching Proxy を Web サーバーとして機能させ、 ローカル・ファイル・システムのオブジェクトを検索するように指示したり、 あるいはプロキシー・サーバーとして機能させ、起点サーバーのオブジェクトを検索するように指示したりできます。
このトピックでは、メソッドを使用可能にする方法、マッピング・ルールを定義する方法、および代理プロキシー・サーバーを構成する方法について説明します。
クライアントがサーバーに送信する要求には、指定されたオブジェクトでサーバーが実行するアクションを示すメソッド・フィールドが含まれています。
以下に、プロキシー・サーバーがサポートするメソッドのリストを示し、メソッドが使用可能にされている場合にそのメソッドを含むクライアント要求に対して、どのように応答するかについて説明します。
Enable CONNECT メソッドのフォーマットおよび使用可能なオプションについては、 SSL トンネリングの構成を参照してください。
POST メソッドは、既存のリソースの注釈を扱うように設計されています。例には、掲示板、ニュースグループ、メーリング・リスト、または同様なリソースの グループに対するメッセージの送付、データ・ブロックの提供 (例えば、フォーム からデータ処理プログラムへ)、あるいは付加操作による データベースの拡張が含まれます。 Caching Proxy では、POST メソッドは「構成および管理」フォームを処理するために使用されます。
このメソッドは、持続接続の間、取り扱うことができます。
PUT メソッドを使用可能にすると、HTTP および FTP を使用して、Caching Proxy にファイルを書き込むことができます。 PUT によってクライアントが Caching Proxy に書き込むことができるため、サーバー保護設定を使用して、PUT を使用できる担当者および PUT を使用できるファイルを定義する必要があります。 (サーバー保護セットアップを参照してください)
以下のディレクティブで HTTP/FTP メソッドを使用可能にします。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
以下の「構成および管理」フォームを使用して関連するディレクティブの値を編集します。
詳細については、「構成および管理」フォームの使用を参照してください。
これは、リバース・プロキシー構成にのみ適用されます。
Caching Proxy では、標準 HTTP メソッドのサポートがあるほか、 RFC で定義されたメソッドや、なんらかのアプリケーションで使用されるメソッドなど、 その他のメソッドの転送もサポートしています。 また、Caching Proxy は、カスタマー定義のメソッドもサポートしており、 プロキシー・サーバー経由でそれらのメソッドを転送することもできます。
Web-based Distributed Authoring and Versioning (WebDAV) は、 HTTP プロトコルへの拡張セットです。 この拡張セットを使用すると、 リモート Web サーバー上でファイルの編集と管理を円滑に行うことができます。 Caching Proxy は、WebDAV メソッド、Microsoft Exchange Server で使用されるメソッド、 およびユーザー定義 (カスタマイズ) メソッドをサポートしています。
これらのメソッドは、ハードコーディングされており、 Enable ディレクティブと Disable ディレクティブによって管理します。 管理者は、PROTECT ディレクティブで定義された、 対応するメソッド・マスクを使用して、これらのメソッドの使用を許可することもできます。
サポートされる WebDAV メソッド (RFC 2518): PROPFIND、PROPPATCH、MKCOL、COPY、MOVE、LOCK、UNLOCK、SEARCH
サポートされる MS Exchange メソッド: BMOVE、BCOPY、BDELETE、BPROPFIND、BPROPPATCH、POLL、NOTIFY、 SUBSCRIBE、UNSUBSCRIBE、ACL、SUBSCRIPTIONS、X_MS_ENUMATTS
WebDAV メソッドまたは MS Exchange Server メソッドが有効であると、 Caching Proxy は、要求をターゲット・サーバーにのみ転送し、 要求本体にリソース・リンクを再書き込みすることはありません。
また、Caching Proxy は、 ユーザー定義のメソッドをバックエンド・サーバーに転送することもできます。 ibmproxy.conf ファイルで Enable ディレクティブの以下の構文を使用すると、 カスタマイズ・メソッドを使用可能にできます。
Enable user-defined-method [WithBody | WithoutBody]
WithBody または WithoutBody の値を設定して、 ユーザー定義メソッドが要求本体を必要とするかどうかをプロキシーに指示します。
次の例では、ユーザー定義メソッド My_METHOD を有効にしており、 そのメソッドが要求本体を必要とすることをプロキシーに指示しています。
Enable MY_METHOD WithBody
以下のディレクティブで、WebDAV メソッド、MS Exchange メソッド、 およびユーザー定義メソッドを有効にします。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
マッピング・ルールはクライアント要求を、例えば起点サーバーに (代行して) 渡す、 リダイレクトする、拒否するなど、何らかの方法で Caching Proxy に処理させる構成ディレクティブです。 Caching Proxy を適切に機能させるためには、マッピング・ルールを正しく設定することが重要です。マッピング・ルールが影響を与えるのは、以下の機能です。
マッピング・ルール・ディレクティブは次のような形式を使用します。
rule template target [IP_address | host_name]:[port]
指定のテンプレートと IP ポートの組み合わせに一致する要求だけが、そのルールの対象となります。 テンプレートには、例えば https://**/*.asp のように、ワイルドカードを入れることができます。
構成ファイルでルールが現れる順序は、重要です。 Map ディレクティブを除いて、要求はテンプレートに一致するとすぐに処理され、後のルールは評価されません。 Map ディレクティブは、要求にある URL を置き換えます。この新規の要求が、引き続き残りのマッピング・ルールと比較されます。
以下のマッピング・ルールは、指定のテンプレートと一致するクライアント要求に適用されます。
以下のマッピング・ルールは、起点サーバーの応答に適用されます。
以下のマッピング・ルールは、API アプリケーションに適用されます。
標準サロゲートを構成するには、次のようにします。
Port 80
Proxy /* http://our.content.server.com/* :80
AdminPort 8080
これにより、起点サーバーに対する、ポート 80 のすべての HTTP トラフィックが代行されます。 管理ポートに入ったトラフィックは、初期のワイルドカード・プロキシー・ルールとは突き合わされないため、 影響を受けません。要求は、残りのマッピング・ルールを使用して処理されます。
以下のディレクティブでマッピング・ルールを定義します。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
以下の「構成および管理」フォームを使用して関連するディレクティブの値を編集します。
詳細については、「構成および管理」フォームの使用を参照してください。
これは、リバース・プロキシー構成にのみ適用されます。
JunctionRewrite ディレクティブにより、Caching Proxy 内の ジャンクション再書き込みルーチンは、発信元サーバーからの応答を再書き 込みし、ジャンクションが使用された場合にサーバーに関連した URL が適切な発信元サーバーにマップされるようにします。 ジャンクション再書き込みプラグインも使用可能にする必要があります。ジャンクションは、プロキシー・マッピング・ルールによって定義されます。
プロキシー・マッピング規則を使用してジャンクションを定義するときは、 JunctionPrefix オプションを使用する場合も、しない場合も、Proxy ディレクティブを使用できます。
以下は、ジャンクション再書き込みルーチンによって行われる、有効なジャンクションの例です。
以下は、ジャンクション再書き込みルーチンが作用しない、有効なジャンクションの例です。
以下は、有効なジャンクションの例です。
これらのマッピング・ルールでは、shopserver、authserver、および b2bserver 用のジャンクションが作成されています。 該当する HTML タグ内に、以下の URL が含まれた HTML 文書を shopserver が戻すものとします。
ジャンクション再書き込みルーチンは、以下のように、プロキシー・マッピング・ルールを使用して、サーバー相対参照を再書き込みします。
JunctionPrefix オプションを Proxy ディレクティブと併用するときは、 Proxy 規則内の最初の URL パターンから JunctionPrefix を割り出すようにする代わりに、 次のフォーマットを用いて、Proxy 規則内でジャンクションの接頭部を宣言することができます。
Proxy url_patern1 url_pattern2 JunctionPrefix:url_prefix
JunctionPrefix を使用しているときは、 最初の URL パターンのフォーマットに制限はありません。 JunctionPrefix オプションを使用していないときに ジャンクションの再書き込みをサポートするには、プロキシー URL は次のフォ ーマットを持つ必要があります。Proxy /market/* http://b2bserver/*。 しかし、JunctionPrefix の使用時は、次の Proxy 規則がジャンクション 再書き込みにおいて有効です。
Proxy /market/partners/*.html http://b2bserver.acme.com/*.html junctionprefix:/market/partners
ジャンクション再書き込みルーチンは、以下のタグに影響を与えます。
タグ | 属性 |
---|---|
!-- | URL |
a | href |
applet | archive、codebase |
area | href |
base | href |
body | background |
del | cite |
embed | pluginspage |
form | action |
input | src |
frame | src、longdesc |
iframe | src、longdesc |
ilayer | src、background |
img | src、usemap、lowsrc、longdesc、dynsrc |
layer | src、background |
link | href |
meta | url |
object | data、classid、codebase、codepage |
script | src |
table | background |
td | background |
th | background |
tr | background |
以下のディレクティブは、ジャンクション再書き込みルーチンおよびプラグインを使用可能にするために使用されます。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
以下の「構成および管理」フォームを使用して、ジャンクション再書き込みプラグインを使用可能にすることができます。
詳細については、「構成および管理」フォームの使用を参照してください。
次のように、Cookie を使用して、バックエンド・サーバー情報を保管できます。 Cookie は、クライアント・ブラウザーに送信されます。ブラウザーが HTML ページのリソースに要求を送信すると、 Cookie が添付されるため、Caching Proxy は要求を正しいバックエンド・サーバーに転送します。
JunctionRewrite の代わりに Cookie を使用する場合は、ibmproxy.conf ファイルを 次のように変更します。
以下は、JunctionRewrite プラグインと Cookie のインプリメンテーションの比較です。
Proxy /no-juntion.jpg http://login-server/no-junction.jpg
HTML ファイル内の JavaScript(TM) (SCRIPT) およびアプレット (APPLET) タグ・ブロックを再書き込みおよび構文解析する、カスタマイズ可能なサンプル・コードが提供されています。JunctionRewrite プラグインは、JavaScript 内または Java(TM) のパラメーター値へのリソース・リンクを単独で処理することはできません。
Caching Proxy をインストールした後は、同じコードをコンパイルおよび構成し、JunctionRewrite で実行することができます。
次のサンプル・ファイルは、フィックスパックをダウンロードしたディレクトリー内の ...samples/cp/ サブディレクトリーに配置されています。
Pass および Exec マッピング・ルールは、ローカル・コンテンツを要求元クライアントに 送達するために使用されます。デフォルトでは、ワイルドカード・テンプレート付きの Pass ルールが最後のマッピング・ルールとして指定されます。 このルールによって、直前のテンプレートに一致しないすべての要求を対象に、 通常は文書ルート・ディレクトリーを示すターゲット・ディレクトリーから ファイルを検索するよう指示します。
ファイル名を含まない URL を受信した場合、Caching Proxy は指定ディレクトリーがある場合はそのディレクトリー、 指定ディレクトリーがない場合は文書ルート・ディレクトリーを対象に、構成ファイルで指定された ウェルカム・ページのリストに一致するファイルがないかどうかを検索して、要求を処理します。 ウェルカム・ページより多くのページが定義されている場合、プロキシー・サーバーは定義された順序でページを検索します。 最初に検出されたウェルカム・ページが提供されます。
サーバー・ホーム・ページは、サーバーがディレクトリー名またはファイル名なしで サーバーの URL のみを含む要求を受け取るときにデフォルトで送達する Web ページです。 前に説明したように、デフォルトのワイルドカード・マッピング・ルールでは、 サーバー・ホーム・ページが文書ルート・ディレクトリーに保管されていること、 およびホーム・ページのファイル名が定義されたウェルカム・ページと一致していることが必要です。
このトピックでは、文書ルート・ディレクトリーとウェルカム・ページを定義する方法について説明します。
デフォルトの文書ルート・ディレクトリーは次のようになります。
以下のディレクティブで文書ルート・ディレクトリーを定義します。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
「構成および管理」フォームで文書ルート・ディレクトリーを変更するには、 次の手順を使用してください。
再始動後、サーバーは新規文書ルート・ディレクトリーの使用を開始します。
詳細については、「構成および管理」フォームの使用を参照してください。
サーバーは、文書ルート・ディレクトリー内でホーム・ページを探しますが、そのサーバーが戻す特定 のファイルはウェルカム・ページのリストで定義されます。
ウェルカム・ページについて
サーバーは、ファイル名を指定しない URL 要求を受け取ると、そのサーバーの構成ファイルで設定さ れたウェルカム・ページのリストに従って、要求を満たそうとします。 このリストは、デフォルトのホーム・ページとして使用するファイルを定義します。サーバーは、ウェルカム・ページのリストを文書ルート・ディレクトリー内のファイルに突き合わせて 、ユーザーのホーム・ページを判別します。サーバーが検出する最初に一致するファイ ルが、ユーザーのホーム・ページとして戻されるファイルです。一致するファイルが見つからないと 、サーバーは文書ルート・ディレクトリーのリストを表示します。
特定のファイルをサーバーのホーム・ページとして使用し、要求がディレクトリーまたはファイル名を指定しないときに戻るように設定するには、そのファイルを文書ルート・ディレクトリーに入れ、その名前がウェルカム・ページのリストにリスト表示されているいずれかのファイル名と一致するようにする必要もあります。
デフォルトの構成ファイルは、次の順序で、ウェルカム・ページとして使用するこれらのファイル名を定義します。
サーバーは、リストにあるファイル名と一致する最初のファイルを戻します。ユーザーが welcome.html または index.html ファ イルを作成し、そのファイルを文書ルート・ディレクトリーに入れるまで、サーバーは Frntpage.html をユーザーのホーム・ページとして使用します。
例えば、ユーザーがデフォルト構成を使用していて、文書ルート・ディレクトリー には welcome.html というファイルは含まれていないが、index.html と FrntPage.html と いうファイルが含まれている場合には、index.html ファイルをユーザーのホーム・ページ として使用します。
ホーム・ページが見つからない場合は、文書ルート・ディレクトリーの内容がディレクトリーとして表示されます。
以下のディレクティブでウェルカム・ページを定義します。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
以下の「構成および管理」フォームでウェルカム・ページを定義します。
詳細については、「構成および管理」フォームの使用を参照してください。
これは、フォワード・プロキシー構成にのみ適用されます。
Caching Proxy は、適切な FTP サーバーに対する FTP URL の要求を代行しますが、FTP クライアントからの要求を代行するのには使用できません。 これがサポートするのは、(ftp:// プロトコル方式を使用する) HTTP クライアントから受信した FTP 要求に限られます。
FTP ファイルの要求に対してサポートされるのは、GET、PUT、DELETE の各メソッドだけです。FTP ディレクトリー・リスト作成の要求に対しては、GET メソッドのみがサポートされます。デフォルトでは、PUT および DELETE は Caching Proxy では使用不可です。詳細については、HTTP/FTP メソッドを使用可能にするを参照してください。
このトピックでは、FTP ファイルを保護する方法と、FTP サーバー・ログイン、ディレクトリー・パス、チェーニングを管理する方法について説明します。
FTP ファイル・アップロードの PUT メソッド、または FTP ファイル削除の DELETE メソッド が使用可能になっている場合は、少なくとも PUT 要求と DELETE 要求に 対する FTP プロキシー保護を定義して、FTP サーバーで許可されないファイル更新が 行われるのを防ぐ必要があります。
FTP 要求のプロキシーを保護するには、「構成および管理」フォームで、「サーバー構成」->「文書保護」を選択します。 FTP ファイル要求に保護セットアップを作成するには、要求テンプレートの先頭に ftp:// を入れます。 例えば、exams というディレクトリー内のファイルを 保護するには、テンプレート ftp://exams/* を使用します。
保護セットアップ作成の詳細については、サーバー保護セットアップを参照してください。
要求 URL にユーザー ID もパスワードも指定されていない場合には、Caching Proxy は、要求された FTP サーバーに (ユーザー ID ANONYMOUS を使用して) 無名でログインしようとします。FTP サーバーの多くは、無名 FTP のパスワードとして、電子メール・アドレスを要求します。 FTP サーバーが無名ログインに対するパスワードを要求する場合は、Caching Proxy は、構成ファイルの WebmasterEmail ディレクティブで指定する電子メール・アドレスを送信します。
「構成および管理」フォームで Webmaster 電子メール・アドレスを設定するには、「サーバー構成」->「システム管理」->「SNMP MIB」を選択します。 また、電子メール・アドレスは、WebmasterEmail ディレクティブを使用することにより設定することもできます。詳しくは、WebMasterEMail - 選ばれたサーバー報告書を受け取るための電子メール・アドレスを設定するの該当するセクションを参照してください。
要求 URL の FTP サーバーが、ログイン時に特定のユーザー ID とパスワードを要求する場合は、ユーザーは要求された URL に、例えば次のようにユーザー ID とパスワードを入力することができます。
ftp://userid:password@ftpserverhost/
要求 URL で FTP ユーザー ID のパスワードを指定したくない場合、ユーザー は URL : ftp://userid@ftpserverhost にユーザー ID のみ を入力することができます。Caching Proxy はまず、パスワードのない指定ユーザー ID を使用して、FTP サーバーにログインしようとします。 パスワードのないログインがうまくいかない場合、ブラウザーはプロンプトを出して、指定ユーザー ID に関連したパスワードを入力するよう求めます。
無名ログイン以外のログインの場合、URL に少なくともユーザー ID を指定しなければなりません。 ユーザー ID が指定されていない場合には、無名ログインが行われるので、クライアントに ユーザー ID を求めるプロンプトが出されることはありません。
FTP URL のパス名をユーザーの作業ディレクトリーに関するものと解釈するか、ルート・ディレクトリーに関するものと解釈するかを Caching Proxy に対して指定しなければなりません。例えば、FTP サーバーにログインしたユーザーが /export/home/user1 と呼ばれるデフォルトの 作業ディレクトリーを持っていて、test と呼ばれるサブディレクトリーから test1.exe と 呼ばれるファイルを検索したい場合には、プロキシーは (FTP URL がどのように解釈 されるかによって) 次の URL を使用して FTP サーバーからファイルを検索します。
相対 FTP URL パスが設定されている場合でも、ユーザーは最初のスラッシュ文字 (/) を ルート・ディレクトリーを示す %2F で置き換えるという規則を使用して、絶対パス名を 指定することができます。例えば、作業ディレクトリーが /export/home/user1 の user1 が user2 の 作業ディレクトリー /export/home/user2 のファイルにアクセスしたい場合には、 要求 ftp://user1:user1pw@FTPhost/%2Fexport/home/user2/file は、 相対 FTP URL パス名が選択されていても、ルート・ディレクトリー / に対する URL と して (すなわち、絶対パス名として) 正しく解釈されます。
FTP URL の解釈方法を指定するには、「構成および管理」フォームで、「プロキシー構成」->「プロキシー・パフォーマンス」を選択します。 フォームの下側部分の、「FTP URL パス」の下で、サーバーのルート・ディレクトリーを指定する場合は 「絶対パス」を、パスの開始としてユーザーの作業ディレクトリーを指定する場合は 「相対パス」を選択するようにしてください。
この設定は、プロキシー構成ファイルでも変更することができます。詳しくは、FTPUrlPath - FTP URL をどう解釈するかを指定するを参照してください。
複数の Web プロキシー・サーバーを一緒にチェーニングしている場合は、FTP URL を含む要求が FTP サーバーに直接送信されずに、チェーニングされている Web プロキシー・サーバーに送信されるように指定することができます。FTP 要求 に対してチェーニングされたプロキシー・サーバーを指定するには、「構成および管理」フォーム で、「プロキシー構成」->「プロキシー・チェーニングおよび 非プロキシー・ドメイン」を選択します。 ftp:// プロトコル方式の要求をチェーニングしている場合でも、チェーニングされた プロキシーの URL を指定するために http:// プロトコル方式が使用されます。
プロキシー構成ファイルを使用して FTP チェーニングを構成するには、ftp_proxy - FTP 要求のための別のプロキシー・サーバーを指定するの解説セクションを参照してください。
このトピックでは、サーバー側インクルードを使用して、CGI プログラムおよびクライアントに引き渡される HTML 文書に情報を挿入する方法について説明します。サーバーのエラー・メッセージおよびリソース・マッピングのカスタマイズについても説明しています。
サーバー側インクルードを使用すると、サーバーが起点サーバーとして機能する (つまり代理オブジェクトでもキャッシュされたオブジェクトでもない) 場合に、サーバーが CGI プログラムおよびクライアントに送信する HTML 文書に情報を追加することができます。クライアントに送信できる情報の種類としては、現在日付、ファイルのサイズ、ファイルに加えられた最終変更日付などがあります。このセクションでは、サーバー側インクルードのためのコマンド形式について記述し、サーバー側インクルード・コマンドを CGI プログラムおよび HTML 文書で機能させる方法について説明します。サーバー側インクルードを使用して、エラー・ページをカスタマイズすることもできます。
サーバー側インクルードをサーバーで使用する前に、パフォーマンス、セキュリティー、およびリスクなどの問題を考慮します。
サーバー側インクルードを使用可能にするには、「構成および管理」フォームで、「サーバー構成」->「基本設定」を選択します。このフォ ームを使用して、以下のサーバー側インクルード・タイプの中から受け入れるタイプを指定します。
また、このフォームを使用して、他のファイル・タイプに加えて、テキストまたは HTML 文書 のサーバー側インクルード処理を実行するかどうかも指定します。
さらに、include に使用するファイル拡張子が認識されるようにします。 そのためには、「構成および管理」フォームで、「サーバー構成」->「MIME タイプ およびエンコード」を選択し、「MIME タイプ」フォームを 使用します。shtml および html の拡張子がデフォルトで認識されることに 注意してください。
プロキシー構成ファイル内のディレクティブを編集してサーバー側インクルードのためにサーバーを構成するには、次のディレクティブのそれぞれの該当するセクションを参照してください。
インクルード・コマンドは、コメントとして HTML 文書または CGI プログラムに組み込む必要があります。 そのコマンドの形式は、以下のとおりです。
<!--#directive tag=value ... --> または <!--#directive tag="value" ... -->
値を囲む引用符は任意指定ですが、値にスペースが含まれる場合は必要です。
このセクションでは、サーバー側インクルードのためにサーバーによって受け入れられるディレクティブについて説明します。(これらのディレクティブを、プロキシー構成ファイルのディレクティブ (付録B. 構成ファイル・ディレクティブで説明している) と混同しないようにしてください)
config -- ファイル処理を制御する
このディレクティブを使用して、ファイル処理のある局面を制御します。有効なタグは、cmntmsg、errmsg、sizefmt、および timefmt です。
例:
<!--#config cmntmsg="[This is a comment]" --> <!-- #echo var=" " extra text -->
結果: <!--[This is a comment] extra text -->
デフォルト: [the following was extra in the directive]
例:
<!-- #config errmsg="[An error occurred]" -->
デフォルト: "[An error occurred while processing this directive]"
例 1:
<!--#config sizefmt=bytes --> <!--#fsize file=foo.html -->
結果: 1024
例 2:
<!--#config sizefmt=abbrev --> <!--#fsize file=foo.html -->
結果: 1K
デフォルト: "abbrev"
例:
<!--#config timefmt="%D %T" --> <!--#flastmod file=foo.html -->
結果: "10/18/95 12:05:33"
デフォルト: "%a, %d %b %Y %T %Z"
以下の strftime() 形式が、timefmt タグで有効です。
指定子 | 意味 |
---|---|
%% | % で置換する。 |
%a | 省略された曜日名で置換する。 |
%A | 完全な (省略なし) 曜日名で置換する。 |
%b | 省略された月名で置換する。 |
%B | 完全な (省略なし) 月名で置換する。 |
%c | 日時で置換する。 |
%C | 世紀数 (100 で割って切り捨てた数字) で置換する。 |
%d | 日付で置換する (01 〜 31)。 |
%D | 日付を %m/%d/%y として挿入する。 |
%e | 月数を 10 進数で挿入する (01 〜 12) (C POSIX に限っては、2 文字の、右寄せされ、ブランクで埋められるフィールドです)。 |
%E[cCxyY] | 代替日付 / 時刻形式が使用できない場合、%E 記述子は、非拡張の対応する記述子にマップされる (例えば、%EC は %C にマップされる)。 |
%Ec | 代替日時表示で置換する。 |
%EC | 代替表示の基本となる年 (期間) の名前で置換する。 |
%Ex | 代替日付表示で置換する。 |
%EX | 代替時間表示で置換する。 |
%Ey | 代替表示の %EC (年のみ) からのオフセットで置換する。 |
%EY | 完全な (省略なし) 代替年表示で置換する。 |
%h | 省略された月名で置換する (%b と同じ)。 |
%H | 10 進数 (00 〜 23) の時刻 (24 時間時計) で置換する。 |
%I | 10 進数 (00 〜 12) の時刻 (12 時間時計) で置換する。 |
%j | 年間通算日で置換する (001 〜 366)。 |
%m | 月で置換する (01 〜 12)。 |
%M | 分で置換する (00 〜 59)。 |
%n | 改行で置換する。 |
%O[deHlmMSUwWy] | 代替日付 / 時刻形式が使用できない場合、%O 記述子は、非拡張の対応する記述子にマップされる (例えば、%Od は %d にマップされる)。 |
%Od | 代替数値シンボルを使用して、月の日付で置換する。必要に応じて、ゼロを示す代替シンボルがある場合は先行ゼロ、ない場合は先行スペースによって埋められる。 |
%Oe | 代替数値シンボルを使用して、必要であれば先行スペースで埋めて、月の日付で置換する。 |
%OH | 代替数値シンボルを使用して、時間 (24 時間時計) で置換する。 |
%OI | 代替数値シンボルを使用して、時間 (12 時間時計) で置換する。 |
%Om | 代替数値シンボルを使用して月で置換する。 |
%OM | 代替数値シンボルを使用して分で置換する。 |
%OS | 代替数値シンボルを使用して秒で置換する。 |
%OU | 代替数値シンボルを使用して、年間通算週数 (日曜日を週の第 1 日とし、規則は %U と同じ) で置換する。 |
%Ow | 代替数値シンボルを使用して、曜日 (日曜日 = 0) で置換する。 |
%OW | 代替数値シンボルを使用して、年間通算週数で置換する (月曜日が最初の日)。 |
%Oy | 代替表示の年 (%C からのオフセット) で、代替数値シンボルを使用して置換する。 |
%p | AM または PM と同等のもので置換する。 |
%r | %I:%M:%S %p と同等のストリングで置換する。 |
%R | 24 時間表記の時刻で置換する (%H:%M)。 |
%S | 秒で置換する (00 〜 61)。 |
%t | タブで置換する。 |
%T | %H:%M:%S と同等のストリングで置換する。 |
%u | 10 進数の曜日で置換する (1 〜 7)。1 は月曜日を表す。 |
%U | 年間通算週数 (00 〜 53) で置換する。日曜日を週の最初の日とする。 |
%V | 年間通算週数 (01 〜 53) で置換する。月曜日を週の最初の日とする。 |
%w | 曜日で置換する (0 〜 6)。日曜日は 0 になる。 |
%W | 年間通算週数 (00 〜 53) で置換する。月曜日を週の最初の日とする。 |
%x | 適切な日付表示で置換する。 |
%X | 適切な時間表示で置換する。 |
%y | 2 桁の年数値と世紀で置換する。 |
%Y | 完全な 4 桁の年数値で置換する。 |
%Z | 時間帯の名前で置換する。時間帯が分からない場合は、文字を何も指定しない。 |
オペレーティング・システムの構成によって、月名と年が完全表記であるか省略表記であるかが決まります。
echo -- 可変値を表示する
このディレクティブは、var タグを使用して指定された環境変数の値を表示するために使用します。 変数が検出されない場合は、(None) が表示されます。 echo は、set または global ディレクティブによって設定された値を表示することもできます。 以下のような環境変数を表示することができます。
例:
<!--#echo var=SSI_DIR -->
exec -- CGI プログラムを指定する
このディレクティブを使用して、CGI プログラムの出力を組み込みます。exec ディレクティブは、CGI が出力するすべての HTTP ヘッダーを廃棄します。ただし、以下のものは除きます。
cgi -- CGI プログラム URL を指定する
このディレクティブを使用して、CGI プログラムの URL を指定します。
この例では、program は実行される CGI プログラムで、path_info および query_string は環境変数としてプログラムに渡される 1 つまたは複数のパラメーターを表します。
<!--#exec cgi="/cgi-bin/program/path_info?query_string" -->
次の例は、変数の使用を示すものです。
<!--#exec cgi="&path;&cgiprog;&pathinfo;&querystring;" -->
flastmod -- 文書が最後に変更された日付および時刻を表示する
このディレクティブを使用して、文書が最後に変更された日付および時刻を表示します。この変数の形式設定は、config timefmt ディレクティブによって定義されます。file および virtual タグは、このディレクティブで有効であり、 その意味は次のように定義されます。
ディレクティブ形式:
<!--#flastmod file="/path/file" --> <!--#flastmod virtual="/path/file" -->
<!--#flastmod file="/path/file" -->
<!--#flastmod virtual="/path/file" -->
例:
<!--#flastmod file="foo.html" -->
結果: 12May96
fsize -- ファイル・サイズを表示する
このディレクティブを使用して、指定したファイルのサイズを表示します。この変数の形式設定は、config sizefmt ディレクティブによって定義されます。file および virtual タグは、このディレクティブで有効で、その意味は前に flastmod ディレクティブに定義したものと同じです。
例:
<!--#fsize file="/path/file" --> <!--#fsize virtual="/path/file" -->
結果: 1K
global -- グローバル変数を定義する
このディレクティブを使用して、このファイルまたは任意のインクルード・ファイルによって後からエコーすることができる、グローバル変数を定義します。
例:
<!--#global var=VariableName value="SomeValue" -->
例えば、仮想境界にわたる親文書を参照するために、グローバル変数 DOCUMENT_URI を設定する必要があります。子文書内のグローバル変数も参照する必要があります。 次の例は、親文書に挿入する必要がある HTML コーディングを示したものです。
<!--#global var="PARENT_URI" value=&DOCUMENT_URI; -->
次の例は、子文書に挿入する必要がある HTML コーディングを示したものです。
<!--#flastmod virtual=&PARENT_URI; -->
include -- 文書を出力に組み込む
このディレクティブを使用して、文書からのテキストを出力に組み込みます。file および virtual タグは、このディレクティブで有効であり、その意味は flastmod ディレクティブの場合に上記に定義したものと同じです。
set -- 変数がエコーされるように設定する
このディレクティブを使用して、このファイルだけが後からエコーすることができる変数を設定します。
例:
<!--#set var="Variable 2" value="AnotherValue" -->
ディレクティブを定義している間に、value 内にストリングをエコーすることができます。例えば、次のとおりです。
<!--#include file="&filename;" -->
変数: サーバー側 set ディレクティブは、一般的に echo ディレクティブが続いているので、set 変数を検索し、その変数が見つかると、エコーして、その機能を実行します。これには、変数に対する複数参照を含めることができます。サーバー側 set によって、すでに設定されている変数をエコーすることもできます。set 変数が見つからない場合は、何も表示されません。
サーバー側 set は、サーバー側 include ディレクティブ内部の変数参照が見つかると、サーバー 側でこれを解決しようとします。次の例の 2 行目では、サーバー側変数 &index; がストリング var とともに使用され、変数名 var1 が構成されます。その後で ê 中の & をエスケープして変数 &var1; に値が割り当てられるので、変数として認識されなくなります。代わりに、 値 frêd または e の上に 曲折アクセント記号のついた fred を作成するためのストリングとして使用されます。 変数 ê はクライアント側変数です。
<!--#set var="index" value="1" --> <!--#set var="var&index;" value="fr¥êd" --> <!--#echo var="var1" -->
エスケープできる文字 (エスケープ変数と呼ばれる文字) は、前に円記号 (¥) が付き、 次のようなものがあります。
文字 | 意味 |
---|---|
¥a | アラート (ベル) |
¥b | バックスペース |
¥f | 用紙送り (改ページ) |
¥n | 改行 |
¥r | 改行復帰 |
¥t | 水平タブ |
¥v | 垂直タブ |
¥' | 単一引用符 |
¥" | 二重引用符 |
¥? | 疑問符 (?) |
¥¥ | 円記号 |
¥- | ハイフン |
¥. | ピリオド |
¥& | アンパーサンド |
Caching Proxy から戻されるエラー・メッセージをカスタマイズして、特定のエラー状態に対応する 特定のメッセージを定義することができます。「構成および管理」フォームで、「サーバー構成」->「エラー・メッセージのカスタマイズ」を選択します。 このフォームを使用して、エラー状態を選択し、その状態に使用する 特定の HTML ファイルを指定します。
プロキシー構成ファイル中のディレクティブを編集してエラー・メッセージをカスタマイズするには、ディレクティブの該当するセクション (ErrorPage - 特定のエラー条件にカスタマイズされたメッセージを指定する) を参照してください。
これは、リバース・プロキシー構成にのみ適用されます。
WebSphere Application Server, バージョン 6.1 では、RTSP リダイレクターという形でストリーミング・メディアのサポートを導入しています。 RTSP により Caching Proxy は、メディア・プレイヤーとの最初の接点として働き、メディア・プレイヤーの要求を該当するプロキシー・サーバーへ、または要求されたメディア・コンテンツを提供するコンテンツ・サーバーへリダイレクトすることができます。
RTSP (Real Time Streaming Protocol) は RFC 2326 に定義されています。これは、データ・ストリームを制御するためのインターネット標準プロトコルです。これには、ストリームを 送達する テクノロジーは含まれていませんが、ビデオやオーディオの再生とは無関係なデータ・ストリームを 制御するために使用できる十分な柔軟性があります。
RTSP リダイレクト機能によって、Caching Proxy は、RTSP で制御されるすべてのストリーミング・ メディア・セッションについて要求をリダイレクトできます。そのセッションには、以下のタイプのメディアが含まれます。
RTSP ポート (通常は 554) でプロキシー・サーバーに接続するよう構成できるどのプレイヤーも、Caching Proxy でこのフレームワークを使用して、その要求を RTSP リダイレクターに処理させることができます。
RTSP リダイレクターは、プロキシー・メディア・プレゼンテーションをキャッシュに格納したり送信したりしません。RTSP リダイレクターをサード・パーティー製のストリーミング・メディア・サーバーと一緒に使用し、これらの機能のいずれかまたは両方を提供する必要があります。RTSP リダイレクターを備えた Caching Proxy は、1 つまたは複数の RTSP プロキシー・サーバーにネットワーク・アクセスができることが必要です。
この機能には、以下の制約事項があります。
現在、RealNetworks のテクノロジーだけがサポートされています。これらのテクノロジーには、RealProxy プロキシー・サーバー、RealServer 起点サーバー、RealPlayer メディア・プレイヤーなどがあります。
従来、RTSP リダイレクターには、どの URL についても同じ起点サーバーに向けられたすべての要求が同じ方法でリダイレクトされるという制限がありました。要求された URL のファイル名またはその他の部分を基にしたリダイレクトは不可能でした。この制限はもはや適用されません。RTSP リダイレクターは、Caching Proxy 構成ファイルで設定されたしきい値 (rtsp_proxy_threshold) とともに、受信した要求からの完全 URL を使用して、クライアント要求を起点サーバーとプロキシー・サーバーのどちらにリダイレクトするかを判別するようになりました。同じ 起点サーバーへの要求は、個別に処理されるようになりました。
RTSP リダイレクトを制御するために、以下の構成ファイル・ディレクティブを使用します。これらのディレクティブの設定値は、サーバーを再始動してもリフレッシュされません。これらのディレクティブの変更を有効にするには、サーバーを完全に停止したあと、再始動する必要が あります。
文書を要求するとき、Web クライアントはブラウザーや要求に関する追加の情報を提供するヘッダーを 送信します。ヘッダーは、要求の送信時に自動的に生成されます。
Caching Proxy では、ヘッダー情報を宛先サーバーから隠しておくようにカスタマイズするための、いくつかのオプションを使用できます。実際の ヘッダーをより一般的なヘッダーに置き換えることにはクライアントの匿名性を高める 利点がありますが、一部の Web ページに書き込まれるヘッダー・ベースの ページのカスタマイズが使用不可になるという欠点もあります。
ヘッダーは通常、次のような形式を使用します。
User-Agent: Mozilla 2.02/OS2 Client-IP: 45.37.192.3 Referer: http://www.bigcompany.com/WebTrafficExpress/main.html
このヘッダーには、次のようなフィールドが含まれています。
多くのヘッダーは、適切なプロキシー構成設定によってブロックできます。 しかし、一部のヘッダー・フィールドは起点サーバーに必要で、それらをブロックすると、Web ページが正しく表示されないことがあります (例えば、ある場合には "host" の ヘッダー・フィールドをブロックすると、間違った Web ページが表示されることがあります)。 ヘッダー・フィールドについて詳しくは、HTTP バージョン 1.1 の仕様書を参照してください。
プロキシー構成ファイルを編集してヘッダー・オプションを変更するには、次のディレクティブの解説セクションを参照してください。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
ヘッダー・オプションを指定するために、2 つの「構成および管理」フォームを使用できます。
要求クライアントの IP アドレスを宛先 (コンテンツ) サーバーに転送したい場合は、このボックスにチェックを入れます。 このボックスにチェックがない場合は、宛先サーバーは、プロキシー・サーバーの IP アドレスを受信します。 このボックスにチェックを入れないと、Web サーフィン時のクライアントの匿名性が高くなります。
宛先サーバーにヘッダーで送信するストリングを入力して、クライアントが使用している ブラウザーとオペレーティング・システムのタイプを置き換えます。 例えば、「Caching Proxy 4.0」を指定すると、以下のヘッダー中で Mozilla 2.02/OS2 が置き換えられます。
Content-Type:MIME User-Agent: Mozilla 2.02/OS2 Referer: http://www.ics.raleigh.ibm.com/WebTrafficExpress/main.html Pragma:no-cache
宛先サーバーが "From:" ヘッダーを解析するときに読み取る電子メール・アドレスを 入力します。プロキシー管理者は、すべての問題の報告を受け取る必要があるので、 プロキシー管理者の電子メール・アドレスを指定することをお勧めします。
詳細については、「構成および管理」フォームの使用を参照してください。
アプリケーション・プログラミング・インターフェース (API) の詳細な説明は、 Edge Components プログラミング・ガイド に記載されています。構成ファイル内の API ディレクティブによって、 要求処理ワークフロー内の特定ステップで呼び出されるプラグイン・ルーチンが使用可能になります。 これらのプラグイン・ルーチンは、組み込みルーチンを置き換えることも、組み込みルーチンに追加して実行することもできます。
API ディレクティブは、次のとおりです。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
以下の「構成および管理」フォームを使用して関連するディレクティブの値を編集します。
詳細については、「構成および管理」フォームの使用を参照してください。
ここでは、プロキシー・キャッシュとその構成方法について説明します。キャッシュは、 ファイルをメモリー内に保管 (メモリー・キャッシュ) または 1 つ以上のストレージ・ デバイスに保管 (ディスク・キャッシュ) するように設定できます。 キャッシュ・リフレッシュ・エージェントを構成して、頻繁に要求されるファイルをキャッシュにプリロードし、また、各種の URL フィルターをキャッシングに適用することができます。 またここでは、リモート・キャッシュ・アクセスまたはインターネット・ キャッシング・プロトコル (ICP) プラグインを使用し、キャッシュのガーベッジ・コレクション によって廃止ファイルを除去し、生成ファイルを動的にキャッシングする、キャッシュの共用 方法についても説明します。
ここには、次のトピックが含まれます。
キャッシングとは、プロキシー・サーバーがクライアントに要求されたファイルのローカル・コピーを保管して、同一のクライアントや別のクライアントから再び要求されたときに、キャッシュからそのファイルを迅速に提供できるようにする機能です。
Caching Proxy は HTTP 1.1 に準拠しているため、通常 HTTP 1.1 プロトコルに従って、文書をキャッシュに入れ、その新しさを判別します。
この章では、プロキシー・サーバーキャッシュの機能についてそのいくつかを説明します。構成可能な機能については、 適切な値の設定方法が以降の章で詳細に説明されています。
プロキシー・サーバーは、物理ストレージ・デバイスまたはシステム・メモリーにキャッシュを格納することができます。 ユーザーのシステムに適したキャッシュ・ストレージのタイプは、使用するハードウェアの性能によって、 またキャッシュの応答速度とキャッシュに格納する項目数ではどちらの方が重要かによって異なります。 一般に、メモリー・キャッシュの応答時間はディスク・キャッシュの場合より高速ですが、 メモリー・キャッシュのサイズはプロキシー・サーバー・マシンの RAM 容量によって制限されます。 ディスク・キャッシュのサイズは、ストレージ・デバイスのサイズによって制限されますが、 これは通常、RAM 容量よりもかなり大きなサイズになります。
ディスク・キャッシュの場合、Caching Proxy はロー・ディスク・キャッシュを使用します。これは、プロキシー・サーバーが オペレーティング・システムの読み取りおよび書き込みプロトコルを使用せずに、直接キャッシュ・デバイスに 書き込むという意味です。 htcformat コマンドを使用して、ディスク・キャッシュ用のストレージ・デバイスを 準備しておく必要があります。htcformat の詳細は、基本的なキャッシュの構成のセクションにあります。
メモリー・キャッシュとディスク・キャッシュのどちらの場合でも、 Caching Proxy はシステム・メモリー・スペースを使用してキャッシュの索引も保持します。 これにより、キャッシュされたファイルの検索に要する処理時間が短縮されます。
この Caching Proxy と他のプロキシー・サーバーではキャッシュ・ディレクトリー構造と索引付けメソッドが異なります。Caching Proxy は、キャッシュ内のファイルに関する情報を含む索引をメモリー内で保守します。ディスクまたはその他のメディアの代わりに索引用に RAM を使用すると、ファイルの索引付けと検索がより速くなります。
索引には、キャッシュに格納されたオブジェクトの URL、キャッシュの場所、および有効期限情報が含まれています。このため、索引を入れるのに必要なメモリーの量は、キャッシュ内のオブジェクトの数に比例します。
クライアントから要求を受信すると、プロキシーは、メモリー内のキャッシュ索引を調べてその URL を検索します。
プロキシーは、要求をキャッシュに入れるように構成されると、FTP ファイル要求および HTTP ファイル要求をキャッシュに入れることができます。ただし、FTP ファイル には HTTP ファイルと同じタイプのヘッダー情報が含まれていないため、 キャッシュ FTP ファイルの有効期限は他のキャッシュ・ファイルとは異なる方法で 計算されます。
FTP サーバーにファイル検索の要求を出すと、プロキシーはまず、FTP サーバーにそのファイルの LIST 要求を送信して、そのファイルに関する FTP ディレクトリー情報を入手します。FTP サーバーが LIST 要求に肯定的な完了応答とそのファイルのディレクトリー情報で応答すると、プロキシーは、FTP ディレクトリー情報から解析した日付で HTTP の Last-Modified ヘッダーを作成します。 次に、 プロキシーのキャッシュ機能は、この Last-Modified ヘッダーを、構成ファイル の CacheLastModifiedFactor ディレクティブに設定された値と共に使用して、期限が 切れるまでに FTP ファイルがキャッシュに残る時間を決定します。
"Last-Modified" ヘッダーと CacheLastModifiedFactor ディレクティブを使用して、ファイルがキャッシュに残る時間を決定する方法の詳細については、キャッシュ・コンテンツの保守を参照してください。
無名ログインではなく、特定のユーザー ID で検索される FTP ファイルは、プライベートなファイルと考えられ、キャッシュに格納されません。
Web コンテンツのキャッシングに加えて、プロキシー・サーバーはドメイン・ネーム・サーバー (DNS) のキャッシュも実行します。例えば、クライアントが www.myWebsite.com から URL を要求すると、プロキシーは、ホスト名 www.myWebsite.com を IP アドレスに変換するよう、その DNS サーバーに求めます。その後、この IP アドレスがキャッシュに格納され、そのホスト名に対する以降の要求に必要な応答時間が 改善されます。DNS キャッシュは自動的に行われ、再構成することはできません。
ファイルおよび文書の中には決してキャッシュに格納されないものもあります。そのようなファイルまたは文書とは、以下のようなものです。
キャッシュ・フィルターを設定すると、キャッシュに入れる項目をさらに制限することができます。 例えば、プロキシー・サーバーで プロキシーからローカルで提供されたファイルをキャッシュに入れないようにすることができます。 詳細については、キャッシュ対象の制御を参照してください。
キャッシュの管理には、多くの要因が含まれます。サーバー管理者として、次を指定できます。
さらに、Caching Proxy の全体的なパフォーマンスを改善するために、キャッシュ構成の調整を行うことができます。 パフォーマンス調整の詳細については、プロキシー・サーバー・キャッシュの調整を参照してください。
Caching Proxy をインストールするために Edge components 製品セットアップ・プログラムでデフォルト設定を使用した場合、 キャッシュは使用可能になり、メモリーにキャッシュが格納されます。次の基本的な キャッシュ設定を調整して、システムの要件に応じてキャッシュをカスタマイズできます。
セットアップ・プログラムを使用しなかった場合は、これらの設定を構成すると、キャッシュが使用可能になります。
キャッシュを構成するのに必要な基本ステップは次のとおりです。
基本的なキャッシュ設定を構成したら、次の機能の設定を追加または変更できます。
これらの各設定の変更手順については、本章で説明しています。
キャッシングを使用可能にするには、Caching ディレクティブをオンに設定するか、または「キャッシュ構成」->「キャッシュ設定」構成フォームの「プロキシー・キャッシングを使用可能にする」ボックスにチェックマークを付けます。キャッシュ・デバイスを指定しないと、 キャッシュはメモリーに保管されます。ディスク・キャッシュを作成するには、2. キャッシュ・ストレージを構成するの手順に従ってください。
キャッシュ・ストレージを構成するタスクは、メモリー・キャッシュを使用するか、 ディスク・キャッシュを使用するかによって異なります。
メモリー・キャッシュを使用するには、キャッシュのコンテンツを保持するのに 十分なメモリーが組み込まれるように「キャッシュ・メモリー」の設定をカスタマイズします。 キャッシュ・メモリーの推奨サイズについては、キャッシュ・メモリーを設定するを参照してください。
ディスク・キャッシュを使用するには、以下の手順 を実行することが必要です。
キャッシュには、特別にフォーマットされたデバイスが必要です。デバイスまたはディスク区画全体をキャッシュ専用にすることをお勧めします。キャッシュの最小サイズは 16392KB です。
キャッシュ・デバイスをフォーマットするには、次のようにします。
htcformat raw_device_path [-blocksize block_size] [-blocks number_of_blocks]-blocksize 引き数と -blocks 引き数はオプションです。 デフォルトのブロック・サイズは 8192 バイトです。ブロックの数を指定しない場合、ディスク区画には、収容できるだけの数のブロックが格納されます。
デバイス・パスを指定するときには、必ずロー・デバイスのパスを指定してください。
raw /dev/raw/raw1 dev/sdb1
ロー・デバイスへのアクセスに関する追加情報については、使用中のファイル・システムの参考資料を参照してください。
オペレーティング・システムがキャッシュ・デバイスへの書き込みを試みた場合、キャッシュ・ データが消失する可能性があります。これを避けるために、Windows の Disk Manager ユーティリティーを使用して、htcformat コマンドを使用する前にディスクの準備を行うことができます。ディスクの準備を行うには、このディスク・ユーティリティーを使用して、使用するデバイスまたは区画を削除してから、デバイスまたは区画をフォーマットしないで再作成してください。このようにすると、システムは、そのデバイスがシステム・ストレージ用に選択不可能であると見なします。
CacheMemory ディレクティブ内 (または「キャッシュ設定」 構成フォームの「キャッシュ・メモリー」フィールド内) の値を、 以下の原理に従って設定します。この値に設定された メモリーは、キャッシュ索引を含むキャッシュ・インフラストラクチャーのサポートに 使用され、また、メモリー・キャッシュが構成されていれば、キャッシュのコンテンツを 格納するのに使用されます。
ディスク・キャッシュのパフォーマンスを最適にするためには、キャッシュ索引を含むキャッシュ・インフラストラクチャーのサポートには、キャッシュ・メモリーの値を最小 64 MB にすることをお勧めします。 キャッシュ・サイズが増えると、キャッシュ索引が増加し、索引を保管するためにさらにキャッシュ・メモリーが必要になります。 64 MB のキャッシュ・メモリー値は、キャッシュ・インフラストラクチャーのサポートを提供し、約 6.4 GB までのディスク・キャッシュ用のキャッシュ索引を保管するために十分な大きさです。 もっと大きなディスク・キャッシュの場合、キャッシュ・メモリーは、キャッシュ・サイズの 1% にすべきです。
メモリー・キャッシュの場合、キャッシュ・メモリーの値は、キャッシュ・インフラストラクチャーのサポートとキャッシュそれ自体のために確保するメモリーの量になります。 最小 64 MB のキャッシュ・メモリー値をお勧めします。
メモリー・キャッシュ用にあまりにも多すぎる物理メモリーが割り振られると、「メモリー 不足」エラーやプロキシー・サーバー障害などの、望ましくない動作が発生する可能性が あります。キャッシュ・メモリーの制限値は、32 ビット・アプリケーションの制限に 依存します。Caching Proxy は 32 ビット・アプリケーションなので、最大 2 GB のメモリー を使用可能です。
Caching Proxy によって、CacheMemory ディレクティブで定義されたメモリーが割り振られ、 オブジェクトを格納するキャッシュとして使用されます。メモリー・キャッシュまたはロー・ ディスク・キャッシュのいずれの場合でも、追加のメモリーを割り振る必要が あります。このメモリーは、キャッシュのデータ構造、ネットワーク入出力および接続用の バッファー、セッション用バッファー、およびメイン・プロセスや他のすべての スレッド用のメモリーなどに使用されます。さらに、クライアントからの要求の中には、 デフォルトよりも大きなメモリー・プール・ブロックを割り振る必要が生じる場合も あります。したがって、CacheMemory ディレクティブが 2 GB に近い値に設定されている 場合、特に要求負荷が高い状況では、Caching Proxy で操作に十分なメモリーを 確保できない可能性もあります。
CacheMemory ディレクティブの値を 1600 MB 以下に設定することをお勧めします。 1600 MB を超える値を設定すると、Caching Proxy が通常の操作で必要とするメモリーが 不足し、不都合な副次作用が発生する原因となります。一般にこれらの副次作用は、 増大する CPU 使用率 (場合によっては使用率 100% まで)、メモリー不足エラー、および パフォーマンス低下などだけではありません。全体的に大きなキャッシュ・サイズが必要な場合は、 キャッシュ・デバイスを使用するか、または RCA または ICP を使用した 共用キャッシュ構成をインプリメントしてください。
キャッシュの内容をダンプ・ファイルからインポートしたり、ダンプ・ファイルへ エクスポートしたりすることができます。再始動時にキャッシュ・メモリーが破損したり、同じキャッシュを複数のプロキシーに配置する場合などに役立つ機能です。
フィルターでは、URL 要求の形式に一致させることによって、キャッシュ対象を制限できます。 フィルター設定について詳しくは、キャッシュ対象の制御を参照してください。
オプションで、照会要求の結果をキャッシュに入れるようにプロキシー・サーバーを構成できます。 デフォルトでは、疑問符 (?) が含まれている URL はキャッシュに入れられません。詳細については、照会応答のキャッシュを参照してください。
もう 1 つのオプションでは、IBM WebSphere Application Server からサーブレットまたは JSP を実行した結果をキャッシュに入れることができます。 詳細については、動的に生成されたコンテンツのキャッシングを参照してください。
キャッシュ内のファイルの有効期限が切れた場合の構成、および廃止ファイルの除去方法について 詳しくは、キャッシュ・コンテンツの保守を参照してください。
頻繁にアクセスされるファイルのほとんどを、リフレッシュ要求が出される前に 自動的に毎日リフレッシュするように、キャッシュを構成することができます。詳しくは、自動リフレッシュおよびプリロードのためのキャッシュ・エージェントの構成を 参照してください。
特定の環境下では、共用キャッシュを使用すると、要求されたファイルがキャッシュで 検出される可能性が高くなります。詳しくは、共用キャッシュの使用を参照してください。
ログを簡潔かつ正確に保つことは、Caching Proxy を管理する上で重要なことです。Caching Proxy のモニターに、 プロキシー・サーバー・ログの構成と使用法に関する情報が記載されています。
Caching Proxy は、キャッシュされるファイル、文書、およびその他のオブジェクトを制御するために、いくつかのフィルター操作メソッドを提供します。メソッドには次の機能が含まれます。
ファイルをキャッシュに入れるかどうかを判別するために、URL テンプレートに対する要求を 比較するようにプロキシー・サーバーを構成することができます。この機能は、ファイルが 常にキャッシュに入れられる要求のテンプレートと、 ファイルを決して キャッシュに入れてはならない要求の 個別のテンプレートを設定することによって、構成されます。複数のテンプレートを使用できます。
これと類似したシステムが、照会応答キャッシュを使用可能にする時にも使用されます。詳しくは、照会応答のキャッシュを 参照してください。
ibmproxy.conf ファイルを編集して URL キャッシュ・フィルターを設定するには、 CacheOnly - テンプレートと一致する URL を持つファイルだけをキャッシュに入れるおよび NoCaching - URL がテンプレートと一致したファイルはキャッシュに入れないことを指定するを参照してください。
構成および管理フォームで URL キャッシュ・フィルターを設定するには、「キャッシュ構成」->「キャッシュの動作」の「URL により キャッシュをフィルターに掛ける」フィールドを使用します。常に キャッシュに入れるファイルのある URL を指定するとき、または決してキャッシュに 入れないファイルのある URL を指定するときに、このセクションを使用します。 2 つのリスト、つまり、常にキャッシュに入れるファイルのリストと決してキャッシュに入れないファイル のリストを指定するために、どちらか一方のリストを作成してから「実行依頼」をクリックし、そのあとでもう一方のリストを作成してください。
照会 (疑問符を含む URL 要求) から戻された応答を、キャッシュ・フィルターを 使用してキャッシュに入れることができます。多くのクライアントが同じ照会要求を行う場合、 この機能はリバース・プロキシー (代理) シナリオに役立ちます。
照会キャッシュを構成するには、ibmproxy.conf 構成ファイルで CacheQueries ディレクティブを編集します。 CacheQueries ディレクティブには、次のオプションがあります。
これらのオプションについての追加情報は、CacheQueries - 疑問符 (?) を含む URL へのキャッシュ応答を指定するに示されています。
構成および管理フォームで照会応答キャッシュを構成するには、「キャッシュ構成」->「キャッシュの動作」の「URL により キャッシュ照会応答をフィルターに掛ける」フィールドを使用します。2 つのリストを指定するには、 どちらか一方のリストを作成してから「実行依頼」をクリックし、そのあとでもう 一方のリストを作成してください。
照会応答をキャッシュ可能にするには、照会キャッシュの構成の他に、以下の設定を 適切に構成するようにしてください。「構成および管理」フォームを使用してこれらのオプションを 設定する方法については、キャッシュの新しさの構成を参照してください。
一般的に、プロキシー・サーバーから提供されるファイルをキャッシュに入れるのは非効率的なので、 サーバーのローカル・ドメイン起源のファイルは、デフォルトではキャッシュに入れられません。 サーバーのローカル・ドメイン起源のオブジェクトをキャッシュに入れるには、 「キャッシュ構成」->「キャッシュの動作」構成および管理フォームの「ローカル・ドメイン・ファイルをキャッシュに入れる」 ボックスにチェックマークを付けます。または、プロキシー構成ファイルで CacheLocalDomain ディレクティブを on に設定します。
項目は、完全な URL でなく、着信 URL の指定部分 (重要な部分) に基づいてキャッシュできるようになりました。これは、着信要求の URL の重要な部分が同一であるときにさまざまな着信要求に対してしばしば同一の応答が返されるので、トランザクション・モデルの Web サービスや動的キャッシングの場合に便利です。
部分 URL に基づいてキャッシュを指定するために、「構成および管理」フォームを使用することは できません。 代わりに、プロキシー構成ファイル内の SignificantUrlTerminator ディレクティブを使用して URL 要求の 終了コードを指定してください。この指定により、Caching Proxy では、要求の処理時に終了コードの前の文字だけを評価して、 要求されたファイルがキャッシュされているかどうかが判別されます。 複数の終了コードが定義されている場合には、Caching Proxy は着信 URL を ibmproxy.conf ファイルに定義されている順序での終了コードと比較します。 詳しくは、SignificantURLTerminator - URL 要求の終了コードを指定するを参照してください。
プロキシー構成ファイルを直接編集してキャッシュ・フィルターを設定するには、次のディレクティブの該当するセクションを参照してください。
キャッシュに格納できない文書の詳細については、プロキシー・サーバー・キャッシングの概説を参照してください。
キャッシュには、提供されたファイルのコピーを作成し保管する作業が含まれるので、 キャッシュが正しく機能するためにはルーチン保守が必要です。キャッシュに入れられた ファイルは、新しさ について検査して、起点サーバー上の ファイルとの整合性がすでになくなっている場合は無効にする必要があります。このような ファイルの満了処理については、ファイルの有効期限で説明しています。また、 無効にしたファイルまたは未使用のファイルは、新しいファイル用のスペースを作るために、 キャッシュから除去する必要があります。このようなキャッシュ・パージ処理については、 ガーベッジ・コレクションで説明しています。
キャッシュに格納されたオブジェクトとコンテンツ・サーバー上の元のオブジェクトとの整合性を保持することを、キャッシュの新しさを維持すると言います。Caching Proxy は、キャッシュに入れる文書またはその他のオブジェクトごとに、オブジェクトの有効期限が切れる時刻を計算します。
HTTP ページの場合、コンテンツ・サーバーが生成する文書のヘッダーには、有効期限情報が含まれています。
FTP プロトコルには同等の有効期限情報が含まれていないので、Caching Proxy は、FTP ファイルに対して上記で説明しているように、それぞれのファイルの FTP ディレクトリー情報に基づいて独自の Last-Modified ヘッダーを生成して、その情報を有効期限の計算に使用します。プロキシー・サーバーが FTP サーバーからファイルのディレクトリー情報を取得できない場合は、FTP URL と一致するデフォルト値が使用されます。また、FTP サーバーには標準の日付形式がないので、Caching Proxy は一部の FTP サーバーが送信した日付および時刻を認識できない場合があります。 その場合、プロキシー・サーバー のデフォルトの有効期限時刻値が使用されます。 この手順によって、プロキシーは HTTP ページと FTP ファイルのキャッシングを同様の方法で管理することができます。
有効期限は、以下の方法 (優先順位の順) のいずれかでコンテンツ・サーバーにより指定できます。
前述の詳細情報を使用して有効期限時間が計算された後、Caching Proxy では、この URL に 適用される最小保持時間の値があるかどうかが調べられます。 この値があるときに、指定された時間が計算した有効期限時間より長い場合は、最小保持時間値で指定された時間がオブジェクトの有効期限時間として使用されます。 このことは、Caching Proxy が文書の有効期限時間を 0 分と計算した場合にも該当します。したがって、 失効したコンテンツがサービスされるのを回避するために、最小保持時間設定値の使用には 注意してください。(最小保持時間値を設定するには、CacheMinHold ディレクティブまたは 「キャッシュ構成」->「キャッシュ有効期限設定」の 「URL 有効期限」の設定を使用してください。詳しくは、 キャッシュの新しさの構成を参照してください。)
最後に有効期限時間の値は、「時間マージン」の設定値と照合されます。有効期限時間が「時間マージン」値より大きい場合には、文書はキャッシュに格納され、そうでない場合には、キャッシュに追加されません。 (「時間マージン」値を設定するには、CacheTimeMargin ディレクティブを使用するか、 または キャッシュの新しさの構成の指示に従ってください。)
文書がキャッシュ内にあるが、有効期限が切れている場合には、Caching Proxy は、コンテンツ・サーバーに対して if-modified-since 要求という特別の要求を出します。 この要求によって、文書がプロキシーに最後に受信された後に変更された場合にのみ、コンテンツ・サーバー は文書を送信することになります。文書が変更されていない場合には、コンテンツ・サーバーはそのことを示すメッセージを送って、そのページは再送信しません。この場合、プロキシーは、キャッシュに格納された文書をサービスします。 FTP ファイルの場合、プロキシー・サーバーは、この if-modified-since プロセスをシミュレートします。 ファイルが FTP サーバーで変更されなかったと判別すると、キャッシュからファイルがサービスされます。 そうでない場合には、FTP サーバーから新しいバージョンを入手します。
これは、フォワード・プロキシー構成にのみ適用されます。
FTP プロトコルは HTTP プロトコルほど厳格に日付や時刻を定義しないので、FTP ファイルに対してプロキシーが生成する Last-Modified ヘッダーは、いくつかの要因によって実際のファイル日付とわずかに異なることがあります。このような要因として、以下のものがあります。
FTP ファイルのキャッシュ有効期限が切れた場合、プロキシーは、その FTP ファイル用に、 HTTP の if-modified-since 再検査プロセスをシミュレートします。 これは、要求されたファイルに 対して FTP LIST コマンドを発行し直して、ファイル日付を FTP サーバーが戻した応答から解析し、 その日付をファイルの最初の検索時に Last-Modified ヘッダー用にプロキシー・サーバーが生成した日付と比較します。 ファイル日付が変更されていない場合には、プロキシー・サーバーはキャッシュされた FTP ファイルを再検査済みとマーク付けしてそのファイルに新しい有効期限を設定し、FTP サーバーからファイルを再検索しないで、キャッシュからファイルをサービスします。 この 2 つのファイル日付が一致しない場合には、プロキシーは FTP サーバーからファイルを再検索して、新しいファイル日付で新しいコピーをキャッシュに入れます。
FTP サーバーからファイルのディレクトリー情報を入手することが、いつでも可能というわけではあ りません。プロキシーが FTP ファイルの日付を判別できない場合は、そのファイルの "Last-Modified" ヘッダーを生成することはありません。代わりに、URL に一致する、CacheDefaultExpiry ディレクティブ用に指定された値を使用して、そのファイルをキャッシュに保持しておく時間を決定します。この時間枠が期限切れになると、プロキシーはいつでも、FTP サーバーからファイルを再検索します。 キャッシュ内の特定の FTP ファイルがしばしば CacheDefaultExpiry ディレクティブを使用して、頻繁に検索している (大量のネットワーク・トラフィックを生成している) ように見える場合には、その特定のファイルについてきめ細かい CacheDefaultExpiry の値の指定を考慮してください。これを行うことで、それらはより長時間キャッシュで保持されます。
構成および管理フォームでキャッシュ有効期限設定を指定するには、「キャッシュ構成」->「キャッシュ有効期限設定」->「キャッシュ・ ファイルの時間制限」フォームを使用します。 キャッシュ・ファイルの有効期限の設定に関する詳細は、ファイルの有効期限を参照してください。
キャッシュ・ファイルの有効期限時間を指定するには、「構成および管理」フォームで、「キャッシュ構成」->「キャッシュ有効期限設定」を選択します。 次のフォームが役立ちます。
このフォームでは、URL に基づいてファイルがキャッシュに保持される最小時間を設定します。 このフォームでは、各種の URL 要求テンプレートに対してさまざまなキャッシュ動作を指定できます。
プロキシー構成ファイルを編集して URL ベースのファイル有効期限を設定するには、 付録B. 構成ファイル・ディレクティブの次のディレクティブについての解説セクションを参照してください。
「キャッシュ有効期限設定」フォームを使用して、 使用済みファイルまたは未使用ファイルのデフォルトの有効期限設定値を指定します。 別々の値を HTTP、FTP、および Gopher ファイルに設定することができ、 使用済みファイルまたは未使用ファイルにも別々の値を設定することができます。
このフォームには、次のような別のファイル有効期限オプションもあります。
プロキシー構成ファイルを編集してデフォルトの有効期限設定値を設定するには、以下のディレクティブについての解説ページを参照してください。
「最終変更係数」フォームを使用して、ヘッダーに有効期限のない キャッシュ・ファイルの有効期限をプロキシーで計算するために使用する値を設定します。 各種の要求テンプレートと一致するファイルに異なる値を設定できます。 有効期限を計算するために、最初に一致したテンプレートが使用されます。
プロキシー構成ファイルを直接編集して最終変更係数を設定するには、CacheLastModifiedFactor - 有効期限を決定する値を指定するを参照してください。
「キャッシュ・ファイルの時間制限」構成フォームでは、 ファイルがキャッシュ内に残っていることのできる最長時間を設定します。 時間制限は、要求テンプレートに基づいて設定され、時間制限が期限切れになったときにその ファイルを破棄するか、または妥当性を再検査するかを指定できます。 この設定は、有効期限が無効になっていたり、有効期限時間が非常に長いファイルを保守するために使用することができます。
プロキシー構成ファイルを編集してキャッシュ・ファイルの最長有効期限時間の制限を設定するには、以下を参照してください。
頻繁にアクセスされる URL をキャッシュして、システム・リソースの使用量を最小にする努力の一環として、Caching Proxy は、ガーベッジ・コレクション と呼ばれるクリーンアップ・プロセスを実行します。このプロセスでは、古いファイルや使われないファイルがキャッシュから取り除かれて、より新しいファイル用のスペースが作られます。
ガーベッジ・コレクション・プロセスでは、キャッシュ・ディレクトリー内のファイルを調べ、有効期限が切れたファイルの除去を試みて、キャッシュのサイズを削減して新しいファイル用にスペースを作り出します。ガーベッジ・コレクションは自動的に実行されますが、一部の設定値を構成し、要件に合わせてこのプロセスを調整することができます。
ガーベッジ・コレクションを構成するには、「構成および管理」フォームで、 「キャッシュ構成」->「ガーベッジ・コレクション設定」を選択します。 このフォームを使用して、「最高水準点」および 「最低水準点」を設定することにより、ガーベッジ・ コレクションの開始時と停止時を決定します。キャッシュ内の使用済みスペースが 最高水準点に設定したパーセンテージ以上になると、ガーベッジ・コレクションが 開始されます。キャッシュ内の使用済みスペースのパーセンテージが最低水準点に 設定した値以下になるまで、ガーベッジ・コレクションは継続されます。
2 つのガーベッジ・コレクション・アルゴリズムから選択することができます。 responsetime アルゴリズムでは、大きいファイルを優先的に キャッシュから除去することによってユーザーへの応答に必要な時間を最適化します。 bandwidth アルゴリズムでは、小さいファイルを優先的に キャッシュから除去することによってネットワーク帯域幅の使用を最適化します。 いずれかを選択するか、または両方を混合して使用してください。
プロキシー構成ファイルを編集してガーベッジ・コレクションを構成するには、以下のディレクティブについての解説セクションを参照してください。
ほとんどの Caching Proxy サーバーは、ユーザーがファイルを要求した後でそのファイルをキャッシュに入れるだけです。Caching Proxy には、自動キャッシュ・プリロードを行うキャッシュ・エージェントがあります。 キャッシュ・エージェントが、指定された URL または最も頻繁にアクセス される URL、あるいはその両方を自動的に検索し、これらの URL が要求される前に これらをキャッシュに入れるように指定することができます。
場合によっては、プロキシー・サーバーのホスト名を設定して、キャッシュをプリロードする前にキャッシュ・アクセス・ログを識別する必要があります。 キャッシュ・エージェントを構成するには、「構成および管理」フォームで、 「キャッシュ構成」を選択し、「キャッシュ・ プリロード」および「キャッシュ・リフレッシュ」フォームを 使用してください。照会の結果を表すファイル (つまり、その URL に疑問符文字 (?) が 含まれているファイル) がキャッシュに入れられるのは、照会キャッシュが使用可能な 場合だけであることに注意してください。
自動キャッシュ・リフレッシュおよびプリロードには、以下の利点があります。
欠点としては次のものがあげられます。
効率を最適にするために、キャッシュ・エージェントを、サーバーの活動が少ないときや、クライアントの要求でビジーになる前に実行するように設定してください。 その場合、ユーザーがはじめてファイルを要求したときに高速に実行できるように、キャッシュ内でファイルが使用可能状態になっています。 デフォルトでは、キャッシュ・エージェントは、毎日、地方時の午前 3 時に開始します。
リバース・プロキシー構成の特別な考慮事項
リバース・プロキシー構成を使用するときは、 デフォルトで Proxy http:* ルールを無効にしてください。 これは、セキュリティー上の理由で必要となります。 (つまり、このルールは ibmproxy.conf ファイル内でコメント化されます。) ただし、このルールを無効にすると、キャッシュ・エージェントは、 要求の送信や Caching Proxy のキャッシュ内容のリフレッシュを、 正常に行うことができなくなります。 エラー・ログに「403 Forbidden By Rule Error」が示され、 キャッシュのリフレッシュが完了しません。
この問題を回避するには、cacheAgentService を使用します。 これは、Caching Proxy が提供している内部サービスです。 このサービスを有効にするには、 ibmproxy.conf ファイルのその他のマッピング・ルールの前に、 次の Service ディレクティブを書き込みます。
Service /any-valid-string* INTERNAL:cacheAgentService
any-valid-string 変数は、 ibmproxy.conf ファイルの他のマッピング・ルールと競合しない、有効な任意のストリングです。
Caching Proxy およびキャッシュ・エージェントの両方が、 このサービス・ディレクティブを基にして URI の解析を行います。 URI を直接 Caching Proxy に送信する代わりに、 キャッシュ・エージェント・ユーティリティーは、 このサービス・ディレクティブで URI の前に /any-valid-string パターンを付加します。
たとえば、キャッシュ・エージェントは、
http://www.ibm.com/
この URI を、次のように変換します。
/any-valid-string/http://www.ibm.com/
キャッシュ・エージェントは、この接頭部の付いた URI を Caching Proxy に送信します。 Caching Proxy は、この要求を受け取ると、 接頭部 /any-valid-string/ を除去します。 残りの URI が完全修飾されたユニットになっていれば、 Caching Proxy は、他のルールに対して URI をマッピングすることなく、 この要求にサービスを直接提供します。
さらに、キャッシュ・エージェントは、 関連する URI を Caching Proxy に送信することもできます。 たとえば、ibmproxy.conf ファイルで前に参照したサービス・ディレクティブを使用して、 LoadURL /abc/ を追加すると、 キャッシュ・エージェントはそれを /any-valid-string/abc/ に変換し、 Caching Proxy に送信します。 Caching Proxy は URL を受け取ると、 接頭部を除去し、他のマッピング・ルールに対して /abc/ をマップし、一致がある場合はその要求を処理します。
Service ディレクティブについては、Service - サービス・ステップをカスタマイズするを参照してください。
Linux および UNIX プラットフォームでは、 キャッシュがプリロードまたはリフレッシュされるプロキシー・サーバーの ホスト名を指定します。 Windows プラットフォームでは、リフレッシュされるプロキシー・サーバーがローカル・マシン上にない 場合だけホスト名を指定してください。(ローカル・キャッシュ・エージェントはリモート・サーバーの キャッシュ・アクセス・ログにアクセスしないので、頻繁にアクセスするファイルに基づいてリモート・ サーバーのキャッシュをリフレッシュすることはできないことに注意してください。)
プロキシー・サーバーのホスト名を設定するには、「構成および管理」フォームで、「キャッシュ構成」->「キャッシュ・リフレッシュ」の「キャッシュ宛先サーバーの識別」を選択します。
キャッシュに特定の URL に保管されているコンテンツをプリロードするには、「構成および管理」フォームで、 「キャッシュ構成」->「キャッシュ・プリロード」を使用します。 このフォームで、キャッシュ・エージェントがロードする URL を指定できます。 プロキシーは、そのページが以前にキャッシュされていたかどうかに関係なく、 キャッシュ・エージェントの開始時にそのページを検索します (これら の URL は、LoadURL ディレクティブによってプロキシー構成ファイルに指定されます)。 また、このフォームは、そのコンテンツをキャッシュに入れない URL を定義する場合にも使用できます。 このタイプのキャッシュ・プリロードでは、キャッシュ・アクセス・ログへのアクセスは不要です。
「キャッシュ・プリロード」フォームを使用して、次のオプションを構成します。
最もアクセス頻度の高いページを自動的にプリロードするには、「キャッシュ構成」->「キャッシュ・リフレッシュ」フォームを使用します。 この機能には、プロキシー・サーバーのキャッシュ・アクセス・ログが必要です。 (ログの位置と名前は変更可能です。Caching Proxy のモニターを参照してください。) 頻繁にアクセス される URL は、キャッシュ・アクセス・ログから自動的に判別されます。管理者は、キャッシュにプリロードする頻繁にアクセスされるページの数を指定することもできます。(この数は LoadTopCached ディレクティブによってプロキシー構成ファイルに指定されます。)
「キャッシュ・リフレッシュ」フォームを使用して、次のオプションを構成します。
探求 とは、自動キャッシュ・リフレッシュ機能のうちのオプション部分です。ほとんどの Web ページには、関連情報を含んでいる他のページへのリンクがあり、ユーザーは、通常、あるページから別のページへとリンクしたり、あるサイトから別のサイトへとリンクするパスを たどります。探求は、このような論理情報パスをキャッシュに入れる手段となります。探求機能では、キャッシュ・エージェントは、ロードするページの指定されたレベルのハイパーテキスト (HTML) リンクをたどって、そのリンク・ページすべてをキャッシュに入れます。 リンクされたページは、ソース・ページと同じホストに常駐する場合でも、他のホストに常駐する場合でもかまいません。図 1 でこのことについて説明します。
探求プロセスを制御するために、管理者はキャッシュ・エージェントにロードできる URL の最大数 (デフォルトの設定は 2000)、実行可能な最長時間 (デフォルトの設定は 2 時間)、および使用できるスレッドの最大数 (デフォルトの設定は 4) を指定します。 管理者は追加の制御も構成することができます。 デフォルトでは、探求機能は 2 レベルの階層で使用可能になっていますが、ホスト間では許可されません。 さらに、要求間に遅延を挿入します。 これらの設定値を変更するには、関連したプロキシー構成ファイル・ディレクティブを参照してください。
キャッシュ・エージェントは、以下の順序でキャッシュをロードしたあと、リフレッシュします。
キャッシュ・エージェントは、リンク間の探求を開始するまではページの最大数にすでに達して いるかどうかについて検査しません。ページ数の最大値 (プロキシー構成ファイル内 で MaxURL と呼ばれる) がステップ 1 および 2 で検索されるページの数より 小さい場合は、リンクされたページはまったく検索されません。
以下の例は、指定された URL の最大数に関連して、キャッシュ・エージェントがキャッシュ・リフレッシュの優先順位と探求をどのように処理するかを示しています (以下の例すべてに探求機能が構成されているものとします)。
構成ファイルの設定 | 結果 |
---|---|
LoadURL http://www.getthis.com/main.html LoadURL http://www.getmetoo.com/welcome.htm LoadTopCached 30 MaxURLs 50 |
キャッシュ・アクセス・ログに 31 以上の固有の URL がある場合、キャッシュ・エージェント は、main.html と welcome.htm を検索し、キャッシュ ・アクセス・ログに基づいた上位 30 の要求された URL を検索します。 MaxURL 値にはまだ達していないので、キャッシュ・エージェントは、リンクされた URL を最大 18 まで、すでにキャッシュに格納されているページから検索してロードします。 |
LoadURL http://ww.joesmith.edu/favorites.html LoadURL http://www.janesmith.edu/dislikes.html LoadTopCached 30 MaxURLs 25 |
キャッシュ・アクセス・ログに 31 以上の固有の URL がある場合、キャッシュ・エージェント は、favorites.html と dislikes.html を検索し、キャッシュ・アクセス・ログから上位 30 の要求された URL を検索します。 MaxURL の値をすでに超えているので、その他のファイルは検索されません。 |
LoadURL http://www.hello.com/hi.htm LoadURL http://www.ballyhoo.com/index.html LoadTopCached 20 MaxURLs 25 |
キャッシュ・アクセス・ログに 21 以上の固有の URL がある場合、キャッシュ・エージェント は、hi.htm と index.html を検索し、キャッシュ・ アクセス・ログから上位 20 の要求された URL、および以前のページから最高 3 つまでのリンク された URL を検索します。MaxURL の値にすでに達しているので、その他のファイルは検索されません。 |
キャッシュ・エージェントは、プロキシー構成ファイルで適切なディレクティブを直接編集して構成することもできます。キャッシュ・エージェントに関連したプロキシー構成ファイルのディレクティブについては、付録B. 構成ファイル・ディレクティブの以下の解説ページを参照してください。
自動キャッシュ・リフレッシュが使用可能になっていると、キャッシュ・エージェントは 指定された時刻に自動的にリフレッシュ操作を実行します。 しかし、キャッシュ・エージェントは、任意の時刻にコマンド行から実行することもできます。
実行可能ファイルは、次のとおりです。
ここでは、server_root は、 Caching Proxy をインストールしてあるドライブおよびディレクトリー (たとえば、C:¥Program Files¥IBM¥edge¥cp) になります。
Linux および UNIX プラットフォームでは、 cron デーモンを使用することにより、 さまざまな時刻にキャッシュ・エージェントを自動的に実行できます。 cron で制御されるジョブは、システムの crontab ファイルに行を追加することによって指定します。 次に、Linux および UNIX 上のコマンド・ファイルの項目の例を示します。
45 16 * * * /usr/sbin/cacheagt
このコマンド例は、地方時で毎日の午後 4 時 45 分にキャッシュ・エージェントを 開始します。複数の項目を使用して、希望すれば、複数回キャッシュ・エージェントを実行することができます。詳しくは、使用しているオペレーティング・システムの資料で cron デーモンについて参照してください。
cron デーモンを使用してキャッシュ・エージェントを実行する場合には、 「キャッシュ構成」->「キャッシュ・リフレッシュ」構成フォームを 使用するか、またはプロキシー構成ファイルを編集して、自動リフレッシュ・オプションをオフにすることを 忘れないでください。そうしないと、キャッシュ・エージェントが毎日複数回実行されることになります。
Web 上のある地点で単一のサーバーでは処理しきれない量のトラフィックが発生することは よくあることです。解決策の 1 つは、単にサーバーをさらに追加することです。 しかし、複数の Caching Proxy サーバーを使用すると、あるキャッシュのコンテンツが他のキャッシュのコンテンツと重複することがよくあります。 記憶域に不要な冗長部分が 生じるだけでなく、帯域幅の節約を最大化することができなくなります。これは、 キャッシュ・ファイルの取り出し要求が、独自のキャッシュにそのファイルを持たない プロキシー・サーバーに対して出された時に、そのファイルが起点サーバーから再び 取り出されるためです。階層チェーンのプロキシー・サーバーを使用すると重複キャッシュを最小限に抑えることができますが、この方法でも特定のサーバーを経由するトラフィックが増える結果となり、チェーン内のリンクが追加されるたびに待ち時間が長くなります。
キャッシュ共用では、各キャッシュが他のキャッシュと共にそのコンテンツを共用できるので、 このような問題が解消されます。帯域幅は、以下の理由から節減されます。
複数のキャッシュを 1 つの論理キャッシュであるかのように使用するには、以下の 2 とおりの方法があります。
RCA と ICP は併用できます。
RCA の計画では、以下の勧告を考慮に入れてください。
これらの条件のいずれかに違反しているか、あるいは別の組織が この配列のメンバーである別のサーバーを管理している場合には、 リモート・キャッシュ・アクセスは適切ではありません。
リモート・キャッシュ・アクセスを構成するには、「構成および管理」フォームで、 「キャッシュ構成」->「リモート・キャッシュ・アクセス」を選択します。 このフォームには、1 つの論理キャッシュを共用する名前付き配列を定義するフィールドがあります。 配列のメンバーごとに、必要な情報を入力してください。
プロキシー構成ファイルを編集してリモート・キャッシュ・アクセスを構成するには、付録B. 構成ファイル・ディレクティブの 以下のディレクティブについての解説セクションを参照してください。
インターネット・キャッシング・プロトコル・プラグインによって Caching Proxy は、 HTML ページおよびその他のキャッシュ可能リソースの検索で、ICP に準拠した キャッシュを照会できます。プロキシー・サーバーは HTTP 要求を受け取ると、独自のキャッシュでそのリソースを検索します。 ローカル・キャッシュにそのリソースが見つからず、ICP プラグインが使用可能な場合には、 プロキシー・サーバーは ICP 照会パケット内の URL 要求をカプセル化して、識別された すべての ICP PEER キャッシュにこのパケットを配布します。PEER キャッシュがリソースを 持っていると応答すると、プロキシー・サーバーはその PEER のキャッシュからリソースを検索します。 複数の PEER が肯定的な応答をした場合は、最初の応答が処理されます。 ヒットで応答する PEER がない場合には、元のサーバーはそのワークフローに従って要求の処理を続行します。 例えば、プロキシー・サーバーがもう 1 つのプラグインを呼び出し、リモート・キャッシュ・アクセス・ルーチンへ 継続するか (RCA が使用可能な場合)、または要求されたリソースそのものを取り出すことができます。
ICP プラグインは、プロキシー構成ファイル ibmproxy.conf を編集することによって、 活動化され、構成されます。ICP プラグインを使用するためには、ServerInit ディレクティブ または PreExit ディレクティブ、あるいはその両方を構成ファイルの API ディレクティブ・ セクションに追加する必要があります。どちらのディレクティブが使用されるかは、ICP システム内で Caching Proxy に割り当てられている役割に応じて異なります。
これらのディレクティブを作成するには、ibmproxy.conf ファイルを手作業で編集するか、 あるいはプロキシー・サーバーがすでに稼働中の場合には「構成および管理」フォームの「サーバー構成」->「要求処理」->「API 要求処理」に接続します。
ibmproxy.conf ファイルの API セクションには、(コメントの形で) プロトタイプ・ディレクティブが追加されていることに注意してください。 この API ディレクティブは目的別の順序で配列されています。 API ディレクティブを追加して新しい機能やプラグイン・モジュールを使用できるようにするには、各ディレクティブを構成ファイルのプロトタイプ・セクションに示されているように配列してください。あるいは、必要に応じて API ディレクティブをアンコメントして編集し、 それぞれ必要な機能やプラグインに対するサポートを組み込んでください。
ServerInit および PreExit ディレクティブには 2 つの引き数があります。(1) 共用ライブラリーの完全修飾パスと (2) 関数呼び出しです。これらの引き数はコロン (:) で区切られます。 最初の引き数はシステム特有で、プラグイン・コンポーネントのインストール場所によって決まります。2 番目の引き数は共用ライブラリーにハードコーディングされるので表示されたとおりに入力する必要があります。
プロキシー構成ファイルでは各ディレクティブは単一行にある必要があります。
ServerInit path_of_shared_library:icpServer
Linux および UNIX の例:
ServerInit /opt/ibm/edge/cp/internet/lib/plugins/icp/libicp_plugin.so:icpServer
Windows の例:
ServerInit C:¥Program Files¥IBM¥edge¥cp¥Bin¥plugins¥icp¥icpplugin.dll:icpServer
PreExit path_of_shared_library:icpClient
Linux および UNIX の例:
PreExit /opt/ibm/edge/cp/internet/lib/plugins/icp/libicp_plugin.so:icpClient
Windows の例:
PreExit C:¥Program Files¥IBM¥edge¥cp¥Bin¥plugins¥icp¥icpplugin.dll:icpClient
プラグインの設定を構成するには、プロキシー構成ファイルで提供されている ICP* ディレクティブを追加または変更します。詳しくは、次のディレクティブの説明を参照してください。
これは、リバース・プロキシー構成にのみ適用されます。
動的キャッシング機能により、Caching Proxy は IBM WebSphere Application Server によって生成された JavaServer Pages (JSP) およびサーブレットからの応答の形式で、動的に生成されたコンテンツをキャッシュできます。Caching Proxy アダプター・モジュールは、応答がアプリケーション・サーバーの動的キャッシュに キャッシュされるのに加えてプロキシー・サーバーでもキャッシュされるように、 アプリケーション・サーバーで応答を変更するのに使用されます。この機能を 使用すると、動的に生成されたコンテンツがネットワークのエッジでキャッシュされるため、 複数のクライアントが同じコンテンツを要求する場合に、コンテンツ・ホストは アプリケーション・サーバーに要求を繰り返すことから解放されます。
動的キャッシュ機能を 機能させるには、場合によっては、照会キャッシュを使用可能にする必要があります。例えば、サーブレットが 照会のフォームで URL を使用する場合などです。プロキシー・サーバーでは、疑問符 (?) が含まれている URL を照会として扱います。
動的に生成されたコンテンツのキャッシングにより、以下のような利点が得られます。
アプリケーション・サーバーでは、プロキシー・キャッシングの場合、完全に構成された 公開ページだけがエクスポートされます。プライベート・ページはプロキシーによってキャッシュされません。例えば、公開サイトから動的に生成され、現在の天気予報をリストしたページは、IBM WebSphere Application Server によってエクスポートし、Caching Proxy によりキャッシュすることができます。 しかし、動的に生成され、ユーザーのショッピング・カートのコンテンツをリストするページをプロキシー・サーバーによってキャッシュすることはできません。 また、動的に生成されたページをキャッシュするには、そのページのサブコンポーネント もすべてキャッシュ可能でなければなりません。
キャッシュされた動的ファイルは、通常のファイルのように有効期限が切れることはありません。これらは、これらを生成したアプリケーション・サーバーによって無効にすることができます。
次の状況では、動的キャッシュの項目が無効化されます。
動的キャッシュ項目の無効化は、 Caching Proxy 動的キャッシング・プラグインの特定の インスタンスに対する無効化 (Invalidate) メッセージの生成によって行われます。 Caching Proxy は、/WES_External_Adapter リソース・ロケーターへの通知として 無効化 (Invalidate) メッセージを受信します。Caching Proxy は、次に、無効な項目をそのキャッシュから消去します。
動的キャッシングには次の構成ステップが必要です。
ローカル動的キャッシュ (動的フラグメント・キャッシュとも呼ばれる) を使用するように アプリケーション・サーバーを構成する場合は、IBM WebSphere Application Server 資料の説明に従ってください。 動的フラグメント・キャッシュは Application Server Caching Proxy の外部キャッシュと相互作用します。
IBM WebSphere Application Server は、Application Server と共にインストールされる外部キャッシュ・アダプター (External Cache Adapter) と呼ばれるソフトウェア・モジュールを使用して、Caching Proxy と通信します。
動的に生成されたコンテンツ (サーブレットおよび JSP からの結果) をプロキシー・サーバーで キャッシュ可能にするには、プロキシー構成ファイル ibmproxy.conf に 2 つの変更を 行う必要があります。最初の変更は、動的キャッシング・プラグイン・モジュールを 使用可能にすることで、2 番目の変更は、キャッシュ可能な動的コンテンツの送信元を このモジュールが認識するように構成することです。
Service ステップの API ディレクティブは、動的キャッシング・プラグインを 使用可能にするのに使用されます。このディレクティブを作成するには、ibmproxy.conf ファイルを 手作業で編集するか、あるいはプロキシー・サーバーがすでに実行中であれば、「構成および管理」フォームを 使用して、「サーバー構成」->「要求処理」->「API 要求処理」を選択します。ディレクティブの内容は、このセクションの後の方にある例で示されます。
動的キャッシングを使用可能にする Service ディレクティブのプロトタイプ は、ibmproxy.conf ファイルの API セクションにコメントとして存在しています。そこ には JSP Plug-in という見出しがあります。プロトタイプ の API ディレクティブは、目的別の順序で配列されていることに注意してください。 API ディレクティブを追加して新しい機能やプラグイン・モジュールを使用できるようにするには、各ディレクティブを構成ファイルのプロトタイプ・セクションに示されているように配列してください。オプションで、 コメント文字をプロトタイプ API ディレクティブから除去し、必要に応じてそれらを 編集して、所要のそれぞれの機能またはプラグインのサポートを組み込むことができます。
次の例に示されるように、Service ディレクティブを設定します。(プロキシー構成ファイル では、それぞれのディレクティブは単一行になければならないことに注意してください。 次の例では、読みやすくするために改行されている場合があります。)
Service /WES_External_Adapter /opt/ibm/edge/cp/lib/plugins/ dynacache/libdyna_plugin.o:exec_dynacmd
Service /WES_External_Adapter /opt/ibm/edge/cp/lib/plugins/ dynacache/libdyna_plugin.so:exec_dynacmd
Service /WES_External_Adapter /usr/lib/libdyna_plugin.so:exec_dynacmd
Service /WES_External_Adapter C:¥Program Files¥IBM¥edge¥cp¥bin¥plugins¥ dynacache¥dyna_plugin.dll:exec_dynacmd
Caching Proxy ソフトウェアをデフォルト以外のディレクトリーにインストールしている場合は、 これらの例のパスについて、インストール・パスを置き換えてください。
各 Caching Proxy は動的に生成されるファイルの送信元を認識するように構成する必要もあります。 この プロキシー・サーバー. で動的に生成されたコンテンツをキャッシュに入れるアプリケーション・サーバーごとに、 ExternalCacheManager ディレクティブを ibmproxy.conf ファイルに追加してください。このディレクティブでは、 プロキシーで結果をキャッシュに入れる WebSphere Application Server が指定され、そのサーバーからのコンテンツについての 最大有効期間時間が設定されます。 詳細は、ExternalCacheManager - IBM WebSphere Application Server からの動的キャッシング用の Caching Proxy の構成 に示されています。
ExternalCacheManager ディレクティブで使用されるサーバー ID は、アプリケーション・ サーバーの dynacache.xml ファイルの外部キャッシュ・グループ・スタンザで 使用されるグループ ID と一致していなければなりません。
前述の例では、以下の項目を個々のプロキシーの ibmproxy.conf ファイルに追加します。
ExternalCacheManager IBM-edge-cp-XYZ-1 20 seconds
Caching Proxy は、IBM WebSphere Application Server からそのグループ ID が ibmproxy.conf ファイルの ExternalCacheManager 項目と一致するコンテンツだけをキャッシュします。
キャッシュが使用可能な場合、キャッシュ・ストレージの速度は Caching Proxy のパフォーマンスにとって 重要なことです。このセクションでは、キャッシュ・ストレージの種類を選択し、最高のパフォーマンスを得られる ようにキャッシュ・ストレージを設定する方法について、提案を示します。
Caching Proxy では、キャッシュ・ストレージの以下の 2 種類のメディアを使用できます。
メモリー・キャッシュでは、ファイルの検索速度は最高になりますが、メモリー・キャッシュのサイズはプロキシー・サーバー・マシンで使用できるメモリーの容量によって制限されます。1 つまたは複数の ロー・ディスク区画からなるディスク・キャッシュは、メモリー・キャッシュ より低速ですが、ほとんどの場合、より大きいキャッシュ・サイズが可能になります。
ディスク・キャッシュに使用するデバイス区画は、キャッシュ専用にする必要があります。 つまり、これらの物理ディスクを、他のファイル・システムを含めるために使用したり、 プロキシー・キャッシュを格納する以外の目的で使用したりしないでください。 また、パフォーマンスを低下させるので、プロキシー・キャッシュ用に使用される ディスクではデータ圧縮を使用しないでください。
キャッシュ・ストレージ (ディスクまたはファイルのいずれでも) ごとにプロキシー・サーバー上で メモリー・オーバーヘッドが発生します。一般に、1 つの物理ディスク全体を 1 つのキャッシュ・デバイスとして使用すると、最高のパフォーマンスが 得られます。RAID またはその他の機構を使用し、複数の物理ディスクを結合して 1 つの論理ディスクにすると、逆効果となることがあります。 複数のディスクを使用する場合は、「キャッシュの設定」構成フォームを使用して、 またはプロキシー構成ファイル内の CacheDev ディレクティブを編集して、それらのディスクを複数のキャッシュ・ デバイスとして指定します。 この方式では、プロキシー・サーバーは、複数のディスクに対する読み取りと書き込みの並列性を 制御することができ、オペレーティング・システムやディスク・サブシステムのパフォーマンスに依存 しなくなります。
プロキシー・サーバーのキャッシュ・ガーベッジ・コレクションでは、有効期限の切れたファイルがキャッシュから廃棄され、 新規要求のファイルをキャッシュに入れるためにスペースが解放されます。キャッシュ内の使用スペースの 量が最高水準点と呼ばれる管理者指定の限度に達すると、ガーベッジ・コレクションが 自動的に起動され、使用スペースの量が最低水準点に達するまで処理が継続されます。
ガーベッジ・コレクション・ルーチンが使用する CPU リソースは最小限であり、キャッシュ に格納後まだ有効期限切れになっていないものの可用性が影響を受けることはないので、ガーベッジ ・コレクションが特定の時刻に実行されるよう設定する必要はありません。
ガーベッジ・コレクションのパフォーマンスを向上させるために、最高水準点と最低水準点 を設定できます。 また、ガーベッジ・コレクションのために使用されるアルゴリズムの種類を設定することも できます。ガーベッジ・コレクションの設定の変更方法の詳細については、ガーベッジ・コレクションを参照 してください。
以下に示すのは、プラットフォームごとのキャッシュのパフォーマンス最適化に関する その他の提案です。
なるべく使用可能なすべての物理区画 (PP) を使用して、1 つのディスク上に単一の論理ボリューム を作成してください。例えば、9 GB のディスクの場合、cpcache1 という 9 GB の論理 ボリュームを作成します。 これをフォーマットし、そのロー論理ボリューム /dev/rcpcache1 を 使用するプロキシー・キャッシュ・デバイスとして指定します。
ディスクのサイズ全体を使用する単一の区画 (またはスライス) をキャッシュ・デバイス上に作成します。 例えば、9 GB のディスク上に c1t3d0s0 という 9 GB の区画を作成します。 これをフォーマットし、そのロー・デバイス /dev/rdsk/c1t3d0s0 を 使用するプロキシー・キャッシュ・デバイスとして指定します。
ディスクのサイズ全体を使用して単一の区画を作成します。例えば、9 GB のディスク上に i: という 9 GB の区画を作成します。 これをフォーマットし、そのロー・デバイス ¥¥.¥i: を使用する プロキシー・キャッシュ・デバイスとして指定します。
プロキシー・サーバーのキャッシュの構成方法、およびキャッシュ・デバイスをフォーマットして 指定する方法については、プロキシー・サーバー・キャッシングの構成を参照してください。
ここには、Caching Proxy で SSL を使用する場合、暗号ハードウェアを使用できるようにする場合、IBM Tivoli(R) Access Manager (以前の Tivoli Policy Director) プラグイン を使用する場合、および PAC-LDAP 許可モジュールを使用する場合の、基本的なセキュリティーに関する情報があります。
ここには、次のトピックが含まれます。
Tivoli Access Manager プラグインの使用
インターネットからアクセス可能なサーバーでは、そのサーバーが稼働しているシステムに対して望ましくない行為を受ける危険性があります。 許可されない人々が、パスワードの推測、ファイルの更新、ファイルの実行、あるいは機密データの読み取りを試みるかもしれません。 Web の魅力の 1 つは、それが開かれていることです。 しかし、Web は正当な使用も不正な使用も可能です。
以下の項では、Caching Proxy サーバー上のファイルにアクセスするユーザーを管理する方法について説明します。
Caching Proxy は Secure Sockets Layer (SSL) 接続をサポートしています。この SSL 接続では、 暗号化と暗号化解除を行うセキュア伝送がクライアント・ブラウザーと宛先サーバー (コンテンツ・ サーバーまたは代理サーバーのいずれか) の間で確立されます。
Caching Proxy は、代理として構成されていると、クライアント、コンテンツ・サーバー、 またはその両方とセキュア接続を確立することができます。SSL 接続を使用可能にするには、 「構成および管理」フォームで、「プロキシー構成」->「SSL 設定」を 選択します。このフォームで、「SSL を使用可能にする」 チェック・ボックスを選択し、鍵リング・データベースと鍵リング・データベース・ パスワード・ファイルを指定します。
Caching Proxy は、フォワード・プロキシー・サーバーとして構成されていると、SSL トンネリング というパススルー・プロトコルに従って、クライアントとコンテンツ・サーバーの間で暗号化された要求の受け渡しを行います。プロキシー・サーバーはトンネル伝送の要求の暗号化を解除しないため、暗号化された情報はキャッシュには入れられません。フォワード・プロキシーのインストールでは、SSL トンネリングが使用可能にされています。これを使用不可にするには、「構成および管理」フォームで、「プロキシー構成」->「プロキシー設定」を選択し、このフォーム上で 「SSL トンネリング」チェック・ボックスをクリアします。
システムを保護するために基本的ないくつかの予防措置を講じることができます。
パケット・フィルター操作によって、データがどこから来てどこへ行くかを定義することができます。一定の発信元と送信先の組み合わせを拒否するよう、システムを構成することができます。
ファイアウォールは、社内ネットワークを、インターネットなどの公衆ネットワークから分離します。ファイアウォールはコンピューター・グループまたは単一のコンピューターで、両方向のゲートウェイの役目を果たし、そこを通過するトラフィックを規制したり追跡したりできます。IBM Firewall は、ファイアウォール・ソフトウェアの一例です。
例:
Proxy /* http://content server :443
または
Proxy /* https://content server :443
この章では、保護セットアップを使用して、サーバー上のデータおよびファイルを保護する方法について説明します。保護セットアップは、サーバーが受信する要求、特に、特定のディレクトリー、ファイル、または要求が対応するファイルのタイプに基づいて起動されます。 保護セットアップでは、サブディレクティブが保護の対象となるディレクトリーまたはファイルの特性に基づいてアクセスを認可または拒否する方法を制御します。
保護セットアップおよびその適用方法を定義するには、「構成および管理」フォームで、「サーバー構成」->「文書保護」を選択します。 このフォームを使用して、以下のステップを実行します。
保護規則は、構成フォームの表にリストされた順序で適用されます。 通常、規則は特定のものから全般的なものの順にリストされます。
ドロップダウン・メニューおよびボタンを使用して、保護規則の配置を指定します。
保護機能は、クライアントがプロキシー・サーバーに送信する要求の内容と比較される要求テンプレートに基づいて活動化されます。
要求 は、サーバーのホスト名に続く完全 URL の一部です。 例えば、 サーバーの名前が fine.feathers.com で、ブラウザー・ユーザー が URL http://fine.feathers.com/waterfowl/schedule.html と入力すると、 サーバーが受信する要求は /waterfowl/schedule.html となります。要求テンプレートは、保護の対象となるディレクトリーまたはファイル名、あるいはその両方を指定します。 例えば、今説明した要求テンプレート (/waterfowl/schedule.html) に基づいて保護機能を活動化する要求には /waterfowl/* および /*schedule.html が含まれます。
「URL 要求テンプレート」フィールドに要求テンプレートを 入力します。
保護セットアップは、要求テンプレートと一致する要求に対して行うことを Caching Proxy に指示します。 名前付きの 保護セットアップを使用することも、「文書保護」フォームで 新規セットアップを定義することもできます。
名前付きセットアップを使用するには、「名前付き保護」ラジオ・ボタンをクリックして、提供されているフィールドに使用する名前付きセットアップの名前を入力します。 新規 セットアップを定義するには、「インライン」ラジオ・ボタンを クリックし、与えられた指示に従います (ステップ 6 を参照)。
要求に対してさまざまなサーバー・アドレスからさまざまな規則を適用することができます。 例えば、会社に割り当てられた IP アドレスから要求を受信する場合に、ログ・ファイルに対する要求に異なる保護セットアップを適用することが必要となる場合があります。
要求元のアドレスを規則に組み込む場合、そのアドレスを 「サーバー IP アドレスまたはホスト名」フィールドに入力します。
名前付き保護セットアップを使用した場合、これ以上の入力は必要ありません。インライン保護セットアップを選択した場合、あるいは存在しない名前付きセットアップを指定した場合には、システムは追加のフォームをオープンします。
既存の名前付き保護セットアップを指定しなかった場合には、追加のフォームがオープンされ、要求テンプレートと一致する文書またはディレクトリーに対してどのユーザーをアクセスできるようにするか、またどのアクションをそのユーザーに許可するかを指定できます。
Caching Proxy の構成ファイルを直接編集して保護を設定するためには、まず次の問題を理解しておく必要があります。
Map、Exec、Pass、Proxy などの要求経路指定ディレクティブは、サーバーがどの要求を受け入れ、実際のファイル位置へどのように要求を経路指定するかを制御するために使用されます。 要求経路指定ディレクティブは、保護ディレクティブと同じタイプの要求テンプレートを使用します。 要求ごとに最初に突き合わせするテンプレートに関連した指示が実行されるので、保護が正しく機能するようにするためには、構成ファイル内で経路指定ディレクティブの前に保護ディレクティブをリストする必要があります。 詳しくは、Protect - テンプレートと一致する要求の保護セットアップを活動化するを参照してください。
Protect ディレクティブを使用してインライン保護セットアップを指定することも、既存の名前付きセットアップを参照することもできます。 2 つのタイプのステートメントの構文は多少異なります。 詳しくは、Protect - テンプレートと一致する要求の保護セットアップを活動化するを参照してください。
保護セットアップは、保護サブディレクティブを使用する一連のステートメントです。保護セットアップの作成に関する構文および解説情報は、付録B. 構成ファイル・ディレクティブに記載されています。次の該当するセクションを参照してください。
デフォルトのプロキシー構成ファイルには、/admin-bin/ ディレクトリー内 のファイルにアクセスするために管理者 ID とパスワードを必要とする保護セットアップが含まれています。 この設定値は、「構成および管理」フォームへのアクセスを制限します。
Secure Sockets Layer (SSL) は、情報を自動的に暗号化してからそれをインターネット上で送信し、使用前に相手側でそれを暗号化解除するシステムです。これにより、インターネット上の伝送中に、クレジット・カード番号などの機密情報が保護されます。
Caching Proxy は SSL を使用して代理サーバーの安全を保護し、以下のセクションで説明するように セキュア・リモート管理を可能にします。また、SSL を使用して、バックエンド・ サーバー (例えば、コンテンツ・サーバーやアプリケーション・サーバー) への接続を保護したり、 プロキシー・サーバーとそのクライアントの間の通信を保護したりすることもできます。
フォワード・プロキシーの場合、Caching Proxy は SSL トンネリングをサポートします。これにより、SSL がバイパスされ、すでに暗号化されたデータが変更なしに送り出されます。
SSL 保護は、セキュア・コネクション要求が 1 つのマシンから別のマシンに送信されるとき、例えば、 ブラウザーが要求を代理プロキシー・サーバーに送信するときに、開始されます。 要求構文として http:// の代わりに https:// を使用すると、サーバーがセキュア接続要求を listen するポート 443 (通常の要求用のポート 80 の代わり) 上で要求を送信するようにブラウザーに指示されます。 ブラウザーとサーバーの間でセキュア・セッションを確立するには、2 つのマシンが SSL ハンドシェーク と呼ばれる交換を実行してその暗号仕様に関して同意し、情報の暗号化および暗号化解除に使用される鍵を選択します。 鍵は自動的に生成され、セッションが満了するとその有効期限が切れます。 一般的なシナリオ (SSL バージョン 3 を想定) は、次のとおりです。
クライアントは、クライアントの暗号化能力を説明する Client Hello メッセージを送信して、Caching Proxy との SSL セッションを開始する。
サーバーはクライアントに証明書を送信し、データ暗号化に使用する暗号方式を選択する。
クライアントは、暗号化されたデータの対称暗号鍵の作成に使用される鍵の情報を送信する。この鍵の材料は、プリマスターリング・シークレット と呼ばれ、サーバーの公開鍵 (サーバーの証明書から取得します。鍵および認証の管理を参照) で暗号化されます。 サーバーもクライアントも、このプリマスターリング・シークレットから、読み取りおよび書き込みの対称暗号鍵を得ることができます。
サーバーは、ハンドシェーク・プロトコル全体の最終確認とメッセージ確認コード (MAC) を送信する。
クライアントは、サーバーの最終メッセージを検証するためのメッセージを送信する。
クライアントがサーバーの最終メッセージを検証すると、暗号化されたデータのフローが始まる。
Caching Proxy をセキュア接続のエンドポイントとして使用することによって、コンテンツ・サーバーまたは アプリケーション・サーバーの負荷を軽減することができます。Caching Proxy は、セキュア接続を維持する場合に、 すべて CPU 集中操作となる暗号化および暗号化解除と、鍵の作成を行います。 また、Caching Proxy によって SSL セッションのタイムアウトを構成して、それぞれの鍵の使用を 最大限にすることができます。
SSL の制限
WebSphere Application Server の Caching Proxy 内の SSL には、以下のような制限が適用されます。
HTTPS トラフィックの量が増すと、Caching Proxy サーバーが原因で、CPU 使用が高くなることがあります。 環境変数 (GSK_V3_SIDCACHE_SIZE) およびプロキシー・ディレクティブ (SSLV3Timeout) に対する変更を調整すると、 プロキシー・サーバーが負荷を処理しやすくなり、また CPU 使用の削減にも役立ちます。
SSL セッション ID は、再使用可能な SSL セッションを識別する ID です。 ブラウザーとサーバーの両者で使用される、暗号化または暗号化解除の鍵を含みます。 また、SSL セッション ID は、 新規接続での 不要な SSL ハンドシェーク (サーバーの CPU 時間を大きく消費します) を 回避するためにも使用されます。 Caching Proxy サーバー用の GSKit ライブラリーは、 SSL セッション ID をサポートし、 SSL セッション ID キャッシュを含んでいます。 デフォルトでは、SSL セッション ID キャッシュに 512 個の項目が含まれています。 項目の制限に達すると、一番古いセッション項目が除去され、 新規の項目がキャッシュに追加されます。
SSL セッション ID キャッシュのデフォルトのサイズを変更するには、 GSK_V3_SIDCACHE_SIZE 環境変数を使用します。 この変数の有効な値は、1 から 4096 です。このサイズを大きくするほど、 キャッシュ SSL セッションを探し出すために必要な検索時間が増加します。 ただし、検索時間が増加することは、 SSL 接続を確立するために必要となるオーバーヘッドと比較すると、 それほど重要なことではありません。 キャッシュ・サイズを大きくすると、プロキシー・サーバーは、 より多くの並行 SSL セッションを処理できるようになります。 また、プロキシー・サーバーに高い HTTPS 負荷がかかっているときの CPU 使用も削減されます。
Caching Proxy には、調整可能な SSLV3Timeout ディレクティブもあります。 (SSLV3Timeout - SSLV3 セッションが有効期限切れになるまでの待ち時間を指定するを参照してください。) このディレクティブのデフォルト値は、1000 秒です。 このディレクティブでは、セッション・キャッシュでの SSL セッションの存続時間を定義します。 着信 SSL 接続で既存の SSL セッションが使用されず、 しかもセッションの存続時間がこの値を超えると、 そのセッションはセッション・キャッシュから除去されます。 SSLV3Timeout 値は、 保護されたクライアント・セッションの標準的な長さに設定することをお勧めします。 タイムアウトをあまり短く設定すると、 プロキシーのパフォーマンスが低下することがあります。 これは、単一の保護セッションを完了するために、 複数の SSL ハンドシェーク・セッションが必要となるからです。 ただし、長すぎる値を設定すると、 保護セッションのセキュリティーが損なわれる場合があります。
これは、フォワード・プロキシー構成にのみ適用されます。
Caching Proxy は、フォワード・プロキシー・サーバーとして構成されると、SSL トンネリングを使用して、クライアントとコンテンツ・サーバーの間のセキュア接続をサポートします。SSL トンネリングでは、暗号化されたデータが変換されずにプロキシー・サーバーをパススルーします。プロキシー・サーバーはデータの暗号化を解除しないため、プロキシー・サーバーが要求をまたは文書ヘッダーを読み取る必要のある機能は SSL トンネリングではサポートされていません。またトンネルに入れられる要求はキャッシュに入れられません。
図 2 では、SSL トンネリングを使用することにより接続を確立する方法を示しています。
SSL トンネリング・プロセスは、次のとおりです。
フォワード・プロキシー設定では、SSL トンネリングのみが使用可能です。SSL トンネリング を使用可能にするには、「構成および管理」フォームで、「プロキシー構成」->「プロキシー設定」を選択します。次に、 「SSL トンネリング」チェック・ボックスを選択します。
SSL トンネリング接続では、CONNECT メソッド (デフォルトでは使用不可) も使用可能にする必要があります。これを 使用可能にするには、「構成および管理」フォームで、「サーバー構成」->「要求処理」を選択し、「HTTP メソッド」 フォームを使用します。
拡張 SSL トンネリング・セキュリティーのために、 Enable CONNECT ディレクティブには 3 つのオプション (OutgoingPorts、OutgoingIPs、IncomingIPs) が用意されています。 少なくとも OutgoingPorts には、値を指定する必要があります。 このオプションの値を指定しないと、CONNECT メソッドは有効になりません。
Enable CONNECT OutgoingPorts [all | [port1|port1-port2|port1-*],...]SSL トンネリングのために、 クライアントがリモート・サーバーのポート 443 にのみ接続できるようにするには、次のディレクティブを設定します。 (通常、ポート 443 は、リモート・サーバー上の HTTPS 要求に使われます。)
Enable CONNECT OutgoingPorts 443 SSLTunneling onSSL トンネリングのために、 クライアントがリモート・サーバーのすべてのポートに接続できるようにするには、 次のディレクティブを設定します。
Enable CONNECT OutgoingPorts all SSLTunneling onSSL トンネリングのために、クライアントがリモート・サーバーのポート 80、 8080-8088、および 9000 以上のポートに接続できるようにするには、 次のディレクティブを設定します。
Enable CONNECT OutgoingPorts 80,8080-8088,9000-* SSLTunneling on
ポートおよびポート範囲は、 リスト内にスペースを入れずに、コンマで区切って指定します。
重要: フォワード・プロキシー構成の場合、 通常の SSL トンネリングを有効にするためには、 OutgoingPorts オプションで、 少なくとも 443 または all を指定してください。
Enable CONNECT OutgoingIPs [[!]IP_pattern,...]たとえば、IP/ホスト名 *.ibm.com に一致し、192.168.*.* には一致しないリモート・サーバーのすべてのポートに、 クライアントが接続できるようにするには、次のディレクティブを設定します。
Enable CONNECT OutgoingPorts all OutgoingIPs *.ibm.com,!192.168.*.* SSLTunneling on
Enable CONNECT IncomingIPs [[!]IP_Pattern,...]たとえば、SSL トンネリングのために、 IP アドレスが 192.168.*.* であるクライアントが、 リモート・サーバーのすべてのポートへ接続を行えるようにするには、 次のディレクティブを設定します。
Enable CONNECT OutgoingPorts all IncomingIPs 192.168.*.* SSLTunneling on
プロキシー構成ファイルを編集して、 SSL トンネリングおよび CONNECT ディレクティブを使用可能にするには、 次のディレクティブの付録B. 構成ファイル・ディレクティブにおいて、 それぞれの解説セクションを参照してください。
Caching Proxy のリモート管理は、Secure Sockets Layer (SSL) が提供するセキュリティー機能とパスワード認証を使用することにより行うことができます。 この方法をとると、許可されない人がプロキシー・サーバーにアクセスする可能性が大幅に減少します。
サーバーのリモート管理を実行しているときに SSL を適用するには、http:// 要求の代わりに https:// 要求を使用して、「構成および管理」フォームをオープンします。 例えば、次のとおりです。
https://your.server.name/yourFrontPage.html
前述のように SSL を構成する前に、鍵データベースをセットアップし、 証明書を取得または作成する必要があります。証明書は、サーバー ID を認証するために使用されます。 IBM 鍵管理ユーティリティー (iKeyman と呼ばれる場合もある) を使用して、証明書ファイルをセットアップしてください。このユーティリティー は Application Server に付属している GSKit ソフトウェアの一部です。GSKit には、証明書ファイルを開くための、Java ベースのグラフィカル・インターフェースも含まれています。
以下は、SSL キーおよび証明書をセットアップするための基本的な手順です。
Linux 用以外のすべてのオペレーティング・システムで、証明書がの 有効期限が切れた場合、Caching Proxy は適切に開始せず、鍵データベースの有効期限が切れたことを 示すエラー・メッセージが表示されます。Linux の場合は、プロキシーが現れて開始しますが、 プロセスは即時に消失し、何のエラー・メッセージも生成しません。
Red Hat Enterprise Linux 3.0 システムでこの問題を回避するには、 GCC パッケージが以下に示しているレベルか、 またはそれ以上のレベルであることを確認してください。
公開鍵は、サーバーのトラステッド・ルート認証局 (CA) と指定された CA による、ディジタル署名済み証明書に関連したものでなければなりません。 署名済み証明書は、認証局 (CA) プロバイダーに証明書要求を依頼することによって、購入することができます。Caching Proxy は、次の外部 CA をサポートしています。
デフォルトでは、トラステッド CA として、以下のものが指定されています。
この項では、IBM 鍵管理ユーティリティー (iKeyman) の使用に関するクイック・リファレンスを提供します。鍵管理を使用して、SSL 鍵データベース・ファイル、公開鍵と秘密鍵のペア、および証明書要求を作成します。CA の署名済み証明書を受け取ったら、鍵管理を使用して、その証明書を、オリジナルの証明書要求を作成した鍵データベースに入れてください。
IBM 鍵管理および GSKit の詳細な資料が、GSKit ソフトウェアと同梱されています。
鍵管理を実行するためのシステムのセットアップ
IKeyman GUI を開始する前に、以下を実行してください。
ibmjcefw.jar ibmpkcs11.jar
ibmjceprovider.jar ibmpkcs.jar
local_policy.jar US_export_policy.jar
JAVA_HOME/jre/lib/security/java.security ファイルを更新し、Sun プロバイダーの後に、IBM CMS および IBM JCE プロバイダーの両方に追加します。例えば、次のとおりです。
security.provider.1=sun.security.provider.Sun security.provider.2=com.ibm.spi.IBMCMSProvider security.provider.3=com.ibm.crypto.provider.IBMJCE
java.security ファイルのサンプルは、GSKit_Installation_path/classes/gsk_java.security にあります。
security.provider.1=sun.security.provider.Sun security.provider.2=com.ibm.spi.IBMCMSProvider security.provider.3=com.ibm.crypto.fips.provider.IBMJCEFIPS security.provider.4=com.ibm.crypto.provider.IBMJCE
security.provider.1=sun.security.provider.Sun security.provider.2=com.ibm.crypto.provider.IBMJCE security.provider.3=com.ibm.crypto.pkcs11.provider.IBMPKCS11
鍵管理の開始
鍵管理グラフィカル・ユーザー・インターフェースは、次の方法で開始します。
このセッション時に新規の鍵データベース・ファイルを作成する場合、作成されたファイルは、鍵管理を開始したディレクトリーに保管されます。
鍵データベースは、1 つまたは複数の鍵のペアと証明書を保管するために、サーバーが使用するファイルです。すべての鍵のペアと証明書に 1 つの鍵データベースを使用することも、複数のデータベースを作成することもできます。鍵管理ユーティリティーを使用して、新規の鍵データベースを作成し、そのパスワードと stash ファイルを指定します。
鍵データベースおよび stash ファイルを作成する手順は、次のとおりです。
新規の鍵データベースを作成するときに指定するパスワードは、秘密鍵を保護します。文書に署名し、公開鍵で暗号化されたメッセージを暗号化解除することができるのは、秘密鍵だけです。
パスワードを指定する際には、以下のガイドラインに従ってください。
鍵データベースのパスワードをしばしば変更するのは、よい方法です。ただし、パスワード に有効期限を指定した場合は、パスワードの変更時期を記録してください。変更する前にパスワードが有効期限切れになると、 エラー・ログにメッセージが書き込まれます。この場合、サーバーは始動しますが、安全なネットワーク接続ができなくなります。
鍵データベース・パスワードを変更するには、次のステップに従ってください。
プロキシー・サーバーと LDAP サーバーの間の SSL 接続の場合は、 鍵データベース・パスワードを pac_keyring.pwd ファイルに入れます。 (pac_keyring.pwd ファイルは IKeyMan の生成する stash ファイルではないことに注目してください。)
新規の鍵のペアと証明書要求を作成する
鍵データベースは、鍵のペアと証明書要求を保管します。公開鍵と秘密鍵のペアおよび証明書要求を作成するには、次のようにします。
A new certificate request has been successfully created in the file keyfile_database_name.
自己署名の証明書を作成する
証明書が発行されるのを待つ間に、鍵管理ユーティリティーを使用して自己署名のサーバー証明書を作成し、クライアントとプロキシー・サーバー間の SSL セッションを使用可能にすることができます。 また、この自己署名の証明書はテスト目的にも使用できます。
次の手順に従って、自己署名の証明書を作成します。
鍵をエクスポートする
次の手順を使用して、鍵を別の鍵データベースにエクスポートします。
鍵をインポートする
別の鍵データベースから鍵をインポートするには、次のようにします。
認証局のリスト表示
鍵データベース中のトラステッド認証局 (CA) のリストを表示するには、次のようにします。
この手順は、デフォルトによってトラステッド CA として指定された認証局 (CA) から電子メールで送信されてきた証明書を受け取るために使用します (認証局のリストを参照)。 CA の署名済み証明書を発行する CA が、鍵データベースのトラステッド CA でない場合は、まず CA の証明書を保管し、その CA をトラステッド CA に指定しなければなりません。 そうすれば、CA の署名済み証明書を、データベースに受け入れることができます。 トラステッド CA 以外の CA から、CA の署名済み証明書を受け取ることはできません。(CA の証明書を保管するを参照)
CA の署名入り証明書を鍵データベースに受け入れるには、次のようにします。
セキュア接続を確立するために、トラステッド CA によって署名された証明書のみが受け入れられます。 トラステッド認証局のリストに CA を追加するには、そのトラステッド証明書を取得し、保管する必要があります。新規 の CA から発行された証明書を保管するには、それをデータベースに受け入れる前に 次の手順に従います。
鍵データベースのデフォルト鍵を表示する
次の手順でデフォルトの鍵項目を表示します。
SSL のバージョン 2 および 3 で使用されている、暗号化アルゴリズムとハッシュを次の表に示します。
鍵のペアの生成: RSA 512 - 1024 秘密鍵のサイズ
SSL バージョン 2
米国内バージョン | エクスポート・バージョン |
RC4 US | RC4 エクスポート |
RC2 US | RC2 エクスポート |
DES 56 ビット | 適用不可 |
Triple DES US | 適用不可 |
RC4 エクスポート | 適用不可 |
RC2 エクスポート | 適用不可 |
SSL バージョン 3
米国内バージョン | エクスポート・バージョン |
Triple DES SHA US | DES SHA エクスポート |
DES SHA エクスポート | RC2 MD5 エクスポート |
RC2 MD5 エクスポート | RC4 MD5 エクスポート |
RC4 SHA US | NULL SHA |
RC4 MD5 US | NULL MD5 |
RC4 MD5 エクスポート | NULL NULL |
RC4 SHA 56 ビット | 適用不可 |
DES CBC SHA | 適用不可 |
NULL SHA | 適用不可 |
NULL MD5 | 適用不可 |
NULL NULL | 適用不可 |
これらの SSL 仕様は、プロキシー構成ファイルを直接に編集しても構成できます。詳しくは、以下のディレクティブの 付録B. 構成ファイル・ディレクティブの該当するセクションを参照してください。
Caching Proxy の場合の 128 ビット暗号化
Caching Proxy の 128 ビット暗号化バージョンのみが出荷されます。56 ビット・バージョンは使用できなくなりました。直前のバージョンを更新する場合には、現在インストール済みの 128 ビットまたは 56 ビット・バージョンに Caching Proxy を直接インストールすることができます。これまで 56 ビット (エクスポート) ブラウザーを使用していた場合には、プロキシーで 128 ビット暗号化を活用できるように、128 ビット・ブラウザーにアップグレードする必要があります。
Caching Proxy の 56 ビット・バージョンから 128 ビット・バージョンへのアップグレード後に、証明書の暗号化に使用される鍵のサイズが 1024 に設定されている場合には、構成の変更は不要です。 しかし、鍵のサイズが 512 に設定されている場合には、プロキシーの 128 ビット暗号化を活用できるように、鍵のサイズが 1024 の新規証明書を作成する必要があります。 IBM 鍵管理ユーティリティー (iKeyman) を使用して、新しい鍵を作成します。
IBM 鍵管理ユーティリティーの詳細な説明については、鍵および認証の管理を参照してください。
製品のこのバージョンでは、SUSE Linux での暗号化はサポートされないことに注意してください。
これは、リバース・プロキシー構成にのみ適用されます。
次の手順に従って、SSL ハンドシェーク・ルーチンを暗号ハードウェア・カードに オフロードできるようにします。
AIX で、IBM 4960 PCI 暗号アクセラレーター・カードをサポートするためには、 PKCS11DefaultCert、PKCS11DriverPath、 PKCS11TokenPassword - IBM 4960 PCI 暗号アクセラレーター・ カードをサポートする (AIX のみ)を参照してください。
Caching Proxy プラグインは、Tivoli Access Manager (以前は Tivoli Policy Director) とともに提供され、Caching Proxy が Access Manager を認証および許可に使用できるようにします。このプラグインによって、Web アクセス制御に Access Manager を使用する企業は、プロキシー・サーバー 用に個別の許可スキーマをセットアップする重複した作業を必要とせずに、Edge テクノロジーを追加できます。
Tivoli Access Manager についての追加情報は、製品 Web サイト http://www.ibm.com/software/tivoli/products/ をご覧ください。ソフトウェアおよびハードウェア要件と Access Manager プラグインのインストールについては、Tivoli Access Manager とともに提供される文書を参照してください。
Caching Proxy 用のセットアップ・スクリプトは、Access Manager プラグインとともに提供されます。
スクリプトを実行する前に、以下を実行してください。
セットアップ・スクリプトは wslconfig.sh という名前で、/opt/pdweb-lite/bin/ ディレクトリーで提供されています。プロンプトに応じて、Access Manager 管理者 ID および LDAP 管理者名を入力してください。
構成スクリプトでは、以下のステップが自動的に実行されます。
ServerInit /opt/pdweb-lite/lib/wesauth.so:WTESeal_Init /opt/pdweb-lite/etc/ibmwesas.conf
PreExit /opt/pdweb-lite/lib/wesauth.so:WTESeal_PreExit
Authorization * /opt/pdweb-lite/lib/wesauth.so:WTESeal_Authorize
ServerTerm /opt/pdweb-lite/lib/wesauth.so:WTESeal_Term
以下のように、すべての要求を Access Manager 認証プロセスに転送する、Protect ステートメントおよび Protection セットアップを作成します。
Protection PROXY-PROT { ServerId WebSEAL-Lite Mask All@(*) AuthType Basic } Protect * PROXY-PROT
プロキシー・サーバー および Access Manager プラグインを構成した後に、ibmproxy start ではなく wslstartwte コマンドを使用して プロキシー・サーバー を始動します。 wslstartwte コマンドは、Access Manager プラグインが初期化のために必要とする環境変数を自動的にロードします。 プロキシー・サーバー の始動時に wslstartwte を使用しない場合は、 Access Manager プラグインに関するエラー・メッセージが表示されます。プラグインが使用されているときには、対応する停止コマンド ibmproxy stop がまだ有効です。
PAC-LDAP 許可モジュールによって、Caching Proxy は許可または認証ルーチンの実行時に Lightweight Directory Access Protocol (LDAP) サーバーにアクセスできます。このモジュールは 2 つのコンポーネント・セットから構成されています。Caching Proxy API と Policy Authentication Control (PAC) デーモンに LDAP 機能を追加する共用ライブラリーのペアです。ibmproxy.conf ファイルの中の ServerInit ディレクティブは、Caching Proxy の始動時に 1 つ以上の PAC デーモンを初期化するように共用ライブラリーに指示します。共用ライブラリーは、paccp.conf ファイルを読み取って、PAC デーモンの数値および特性を判別します。初期化中にこのデーモンは、pac.conf ファイルで構成ディレクティブを、また pacpolicy.conf でポリシー情報を読み取ります。次に、ibmproxy.conf ファイル内の Authentication ディレクティブが、認証が必要なときに共用ライブラリーを呼び出すようにプロキシー・サーバーに指示するか、あるいは Authorization ディレクティブが標準 HTTP 要求の処理中に Caching Proxy のワークフローを取り出します。
認証のプロセスは、提供されたクリデンシャルのセット、すなわちユーザー名およびパスワードが有効かどうかを判断します。このプロセスには、ユーザーがレジストリー内に存在すること、および提供されたパスワードが レジストリーに保管されたパスワードと一致することの検証が含まれます。これらのアクションは、認証のステップの中で PAC-LDAP モジュールを使用して実行されます。
PAC-LDAP 許可モジュールは、認証に使用できるようになっている場合は、ユーザー ID、パスワード、 およびグループを検索するデフォルトのリポジトリーになります。HTTP 要求が Caching Proxy の ワークフローに渡されると、それぞれの Protect ディレクティブが要求された URL をその要求 テンプレートと比較します。一致が見つかると、Protect ディレクティブは、サーバー ID、使用する認証のタイプ、要求元クライアントに適用されるマスキング規則、およびパスワード・ファイルとグループ・ファイルの場所が入っている保護スキーマを呼び出します。パスワード・ファイルが定義されていない場合には、ユーザー ID とパスワードは PAC-LDAP 許可モジュールを介して検索されます。タイプ 0、1、2、および 3 のポリシーは認証スキーマを定義します。認証されるとその要求はサービスされ、認証されないと Caching Proxy はクライアントに 401 エラーを戻します。
認証のプロセスは、ユーザーが保護リソースにアクセスするために必要な許可を持っているかどうかを判断します。PAC-LDAP モジュールが使用される場合は、 HTTP 要求に対して pacpolicy.conf ファイル内の許可規則が適用されます。
PAC-LDAP 許可モジュールが許可について使用可能になっていると、pacpolicy.conf ファイル内の 許可規則が HTTP 要求に適用されます。HTTP 要求が Caching Proxy の ワークフローに渡されると、それぞれの Protect ディレクティブが要求された URL をその要求 テンプレートと比較します。一致が見つかると、Protect ディレクティブは保護スキーマを呼び出します。この場合には、保護スキーマは PAC-LDAP 許可モジュールによって取り出された許可ルーチンです。Authorization ディレクティブは、要求された URL をその要求テンプレートと比較して、一致するものが見つかると PAC-LDAP 許可モジュールが呼び出されます。タイプ 4 のポリシーは、pacpolicy.conf ファイル内で定義されて、各種の URL 要求に必要な認証を詳細に定義します。
LDAP は、最少のシステム・リソースを用いて対話式に X.500 ディレクトリーにアクセスします。IANA は LDAP に TCP ポート 389 と UDP ポート 389 を割り当てています。 詳細については、LDAP を定義している RFC 1777 を参照してください。
サポートされる LDAP クライアントの例としては、IBM Tivoli LDAP クライアントおよび IBM SecureWay LDAP クライアントがあります。
PAC-LDAP 許可モジュールのすべてのコンポーネントは、WebSphere Application Server, バージョン 6.1 の Caching Proxy システムのインストール時に自動的にインストールされます。 Linux および UNIX システムでは、Caching Proxy ライブラリー (./lib/) ディレクトリー、 PAC-LDAP 許可モジュール ライブラリー (./lib/plugins/pac/) ディレクトリー、 バイナリー (./bin/) ディレクトリー、および構成 (./etc/) ディレクトリーが /opt/ibm/edge/cp/ ディレクトリー内 に作成されます。 次に、/usr/lib/、/usr/sbin/、および /etc ディレクトリーからそれらの製品特有のものへのシンボリック・リンクが作成されます。
ディレクトリー構造
Linux および UNIX ディレクトリー | Windows ディレクトリー | コンテンツ |
---|---|---|
/opt/ibm/edge/cp/ | ¥Program Files¥IBM¥edge¥cp¥ | Caching Proxy 基本ディレクトリー (cp_root) |
cp_root/sbin/ | ¥Program Files¥IBM¥edge¥cp¥Bin¥ | Caching Proxy バイナリーおよびスクリプト |
/usr/sbin/ | cp_root/sbin/ へのシンボリック・リンク | |
cp_root/etc/ | ¥Program Files¥IBM¥edge¥cp¥etc¥ | Caching Proxy 構成ファイル |
/etc/ | cp_root/etc/ へのシンボリック・リンク | |
cp_root/lib/ | ¥Program Files¥IBM¥edge¥cp¥lib¥ plugins¥ | Caching Proxy ライブラリー |
cp_root/lib/ plugins/pac/ | ¥Program Files¥IBM¥edge¥ cp¥lib¥plugins¥pac¥ | PAC-LDAP 許可モジュール・ライブラリー |
/usr/lib/ | cp_root/lib/ および cp_root/lib/ plugins/pac/ へのシンボリック・リンク | |
cp_root/server_root/pac/data/ | ¥Program Files¥IBM¥ edge¥cp¥server_root¥pac¥data¥ | PAC-LDAP 許可モジュール・データ・ストレージ |
cp_root/server_root/ pac/creds/ | ¥Program Files¥IBM¥ edge¥cp¥server_root¥pac¥creds¥ | PAC-LDAP 許可モジュール・クリデンシャル |
LDAP プラグイン・ファイル
Linux および UNIX ファイル名 | Windows ファイル名 | 説明 |
---|---|---|
libpacwte.so | pacwte.dll | 共用ライブラリー |
libpacman.so | pacman.dll | 共用ライブラリー |
pacd_restart.sh | pacd_restart.bat | PAC デーモン再始動スクリプト |
paccp.conf, pac.conf, pacpolicy.conf | paccp.conf, pac.conf, pacpolicy.conf | 構成およびポリシー・ファイル |
PACD デーモンと LDAP サーバーとの Secure Sockets Layer (SSL) 接続を可能にするには、 LDAP クライアント・パッケージで必要とされる GSKit パッケージをインストールしてください。 GSKit 7 は Caching Proxy マシンでは必要であり、マシン上でデフォルトで提供されていますが、 マシン上の LDAP クライアントが必要とするバージョンとは異なるバージョンの可能性があります。 同一のマシン上で、別々のプロセスで異なるバージョンの GSKit を使用することは可能です。
GSKit 鍵ファイルを $pacd_creds_dir/pac_keyring.kdb に置き、パスワードを $pacd_creds_dir/pac_keyring.pwd に置きます。
Linux システムでは、PACD デーモンと LDAP サーバーとの SSL 接続を可能にするために、 以下に説明されているように LD_PRELOAD 環境変数を構成する必要があります。 変数に次の値を設定してください。
LD_PRELOAD=/usr/lib/libstdc++-libc6.1-1.so.2
このセクションで前述の GSKit 要件は、Linux システムにも適用されます。
Red Hat Enterprise Linux 4.0 システムでは、 認証に ITDS 6.0 LDAP プラグインを使用するよう Caching Proxy が構成されている場合、PACD プロセスが開始されません。 その結果、次のエラー・メッセージが出されます。
"error while loading shared libraries: /usr/lib/libldapiconv.so: R_PPC_REL24 relocation at 0x0fb58ad0 for symbol 'strpbrk' out of range"
現在、ITDS 6.0 で RHEL 4.0 システムがサポートされないという制限があります。
ITDS LDAP クライアントの使用時、未解決のリンクがあると、 AIX システムで PACD プロセスが開始されません。 PACD プロセスを開始する際、次のようなエラーが発生する可能性があります。
exec(): 0509-036 Cannot load program /usr/sbin/pacd because of the following errors: 0509-022 Cannot load module /usr/lib/libpacman.a. 0509-150 Dependent module libldap.a could not be loaded. 0509-022 Cannot load module libldap.a.
ITDS バージョン 5 の LDAP クライアントで、この問題に対処するには、 次のシンボリックを作成します。
ln -s /usr/lib/libibmldap.a /usr/lib/libldap.a
ITDS バージョン 6 の LDAP クライアントで、この問題に対処するには、 次のシンボリックを作成します。
ln -s /opt/IBM/ldap/V6.0/lib/libibmldap.a /usr/lib/libldap.a
PAC-LDAP 許可モジュールを初期化するには、3 つのディレクティブ ServerInit、 Authorization または Authentication、および ServerTerm を、ibmproxy.conf ファイルの API ディレクティブ・セクションに追加する必要があります。これらの ディレクティブを作成するには、ibmproxy.conf ファイルを手作業で編集するか、 あるいはプロキシー・サーバーがすでに実行中の場合にはインターネット・ブラウザーで 「構成および管理」フォームに接続して「API 要求処理」フォームを 開きます (「サーバー構成」->「要求処理」->「API 要求処理」をクリックします)。このセクションの例では分かりやすくするために改行を入れてありますが、プロキシー構成ファイルではそれぞれのディレクティブは単一行にある必要があります。
ibmproxy.conf ファイルの API セクションには、(コメントの形で) プロトタイプ・ディレクティブが 提供されていることに注意してください。この API ディレクティブは目的別の順序で配列されています。 API ディレクティブを追加して新しい機能やプラグイン・モジュールを使用できるようにするには、各ディレクティブを構成ファイルのプロトタイプ・セクションに示されているように配列してください。あるいは、必要に応じて API ディレクティブをアンコメントして編集し、 それぞれ必要な機能やプラグインに対するサポートを組み込んでください。
ServerInit ディレクティブには 3 つの引き数があります。(1) 共用ライブラリーの完全修飾パス、(2) 関数呼び出し、および (3) paccp.conf ファイルの完全修飾パスです。最初の引き数と 2 番目の引き数はコロン (:) で区切ります。2 番目の引き数と 3 番目の引き数はスペースで区切ります。 最初の引き数と 3 番目の引き数はシステム特有で、プラグイン・コンポーネントのインストール場所によって決まります。2 番目の引き数は共用ライブラリーにハードコーディングされるので表示されたとおりに入力する必要があります。 「API 要求処理」フォームを使用して ServerInit ディレクティブを作成する場合には、2 番目と 3 番目の両方の引き数を「関数名」フィールドに入力する必要があります。3 番目の引き数は「IP テンプレート」欄に表示されます。
Authorization ディレクティブには 3 つの引き数があります。(1) 要求テンプレート、(2) 共用ライブラリーの完全修飾パス、および (3) 関数名です。HTTP 要求は、アプリケーション機能が呼び出されたかどうかを判断するために、要求テンプレートと比較されます。要求テンプレートには、プロトコル、ドメイン、およびホストを組み込むことができ、前にスラッシュ (/) を付けたり、ワイルドカードとしてアスタリスク (*) を使用することができます。 例えば、/front_page.html、 http://www.ics.raleigh.ibm.com、/pub*、/*、および * はすべて有効です。関数名は、プログラムの中でアプリケーション機能に与えられた名前です。これはハードコーディングされるので、表示されたとおりに入力する必要があります。最初の 2 つの引き数はスペースで区切ります。最後の 2 つの引き数はコロン (:) で区切ります。
Authentication ディレクティブには 2 つの引き数があります。(1) 共用ライブラリーの完全修飾パスと (2) 関数名です。これらの引き数はコロン (:) で区切られます。 最初の引き数はシステム特有で、共用ライブラリーがインストールされている場所によって決まります。 Caching Proxy をリバース・プロクシーとして使用しているとき、 最初の引き数の URL テンプレートは文書のルート (/) から開始する必要があります。 2 番目の引き数は共用ライブラリーにハードコーディングされるので表示されたとおりに入力する必要があります。
ServerTerm ディレクティブには 2 つの引き数があります。(1) 共用ライブラリーの完全修飾パスと (2) 関数名です。これらの引き数はコロン (:) で区切られます。 最初の引き数はシステム特有で、共用ライブラリーがインストールされている場所によって決まります。 2 番目の引き数は共用ライブラリーにハードコーディングされるので表示されたとおりに入力する必要があります。 このディレクティブは、プロキシー・サーバーの終了時に PAC デーモンを終了します。このデーモンの所有者がプロキシー・サーバーの所有者 と違う場合には、プロキシー・サーバーはそのデーモンを停止させることができません。この場合には、管理者がデーモンを手作業で 停止する必要があります。
ServerInit path_of_shared_library:pacwte_auth_init path_of_conf_policy_file
Linux および UNIX の例:
ServerInit /usr/lib/libpacwte.so:pacwte_auth_init /etc/pac.conf
Windows の例:
ServerInit C:¥Progra ~1¥IBM¥edge¥cp¥lib¥plugins¥ pac¥pacwte.dll:pacwte_auth_init C:¥Progra ~1¥IBM¥edge¥cp
Authorization request-template path_of_shared_library:pacwte_auth_policy
Linux および UNIX の例:
Authorization http://* /usr/lib/libpacwte.so:pacwte_auth_policy
Windows の例:
Authorization http://* C:¥Program Files¥IBM¥edge¥cp¥lib¥plugins¥ pac¥pacwte.dll:pacwte_auth_policy
Authentication BASIC path_of_shared_library:pacwte_auth_policy
Linux および UNIX の例:
Authentication BASIC /usr/lib/plugins/pac/libpacwte.so:pacwte_auth_policy
Windows の例:
Authentication BASIC C:¥Program Files¥IBM¥edge¥cp¥lib¥plugins¥ pac¥pacwte.dll:pacwte_auth_policy
ServerTerm path_of_shared_library:pacwte_shutdown
Linux および UNIX の例:
ServerTerm /usr/lib/libpacwte.so:pacwte_shutdown
Windows の例:
ServerTerm BASIC C:¥Program Files¥IBM¥edge¥cp¥lib¥plugins¥ pac¥bin¥pacwte.dll:pacwte_shutdown
PAC-LDAP 許可モジュール構成およびポリシー・ファイルは、テキスト・エディターを使用して手作業で編集する 必要があります。ディレクティブ名とその最初の引き数はコロン (:) で区切ります。複数の引き数はコンマ (,) で区切ります。構成およびポリシー・ファイルには、編集時に注釈を組み込みます。 以下に、主要なポリシー・ディレクティブを示します。
paccp.conf ファイルは、Caching Proxy の初期化中に共用ライブラリーによって読み取られ、開始するそれぞれの PAC デーモンの定義 ([PAC_MAN_SERVER] スタンザ) が入っています。それぞれの PAC デーモンには、独自の [PAC_MAN_SERVER] スタンザがなければなりません。
[PAC_MAN_SERVER] hostname: # name of PAC daemon port: # port pacd is listening on [PACWTE_PLUGIN] hostname_check:[true|false] # enables DNS lookup. Must have # DNS lookup turned on for ibmproxy to work.
pac.conf ファイルは、PAC デーモンが接続しようとする LDAP サーバーを指定します。
[PAC_MAN_SERVER]
hostname: # name of PAC daemon
port: # port pacd is listening on
conn_type:ssl # comment out if you do not use SSL
authentication_sequence: [primary|secondary|none]
authorization_sequence: [primary|secondary|none]
[LDAP_SERVER]
hostname: # LDAP Server hostname
port:389 # Port LDAP is listening on
ssl_port:636 # SSL port used by the LDAP server
admin_dn: # User with permission to access the LDAP server
# specify admin_dn:NULL to enable anonymous binding
search_base: # Portion of LDAP tree to search for policy info
# If not required, specify search_base:NULL
search_key: # ID field to search
[CACHE]
cred_cache_enabled [TRUE|FALSE] # turn credentials cache on
cred_cache_min_size:100 # minimum number of credentials to cache in pacd
cred_cache_max_size:64000 # maximum number of credentials to cache in pacd
cred_cache_expiration:86400 # when a credential expires
policy_cache_enabled:[TRUE|FALSE] # turns policy cache on/off
policy_cache_min_size:100 # min. number of policy related items to cache
policy_cache_max_size:64000 # max. number of policy related items to cache
policy_cache_expiration:86400 # when a policy related item expires
すべての LDAP ポリシーは、構成およびポリシー・ファイル内の次のテンプレートを使用します。それぞれのポリシーは、大括弧で囲んだ大文字のキーワード POLICY で始まっていなければなりません。
[POLICY] default_policy:[grant|deny] # describes the default policy for users # that are not described in the POLICY section pac_client_hotname: # the instances of Caching Proxy that are allowed # to use a policy list id: # the id for the LDAP entry or ip/hostname # (wildcard supported, such as *.ibm.com) grant:[true|false] # true means to grant access, false means # to deny access type:[0|1|2|3|4] # 0 LDAP entry that is a group, # 1 LDAP entry that is not a group, # 2 IP address # 3 hostname # 4 URL propagate:[true|false] # true means that the access rights (grant # or deny) will be propagated to all # descendants or members stop_entry:[entry|NULL] # Propagation of the access right stops # at this entry. If the id is a group, # stop_entry must be set to NULL. # stop_entry may be applied to an IP # address or hostname. Each stop_entry # must be on its own line exception_entry:[entry|NULL] # Assignment of the access right skips # these entries, but continues through their # subtrees. This may be a list of entries. # exception_entry may be applied to a group, # IP address, or hostname. Each # exception_entry must be on its own line. Exception_type: Exception:
ワイルドカード (*) がサポートされるのは、id および stop_entry ディレクティブの IP アドレスの最後の桁か、ホスト名の最初の桁だけです。ワイルドカードは、exception_entry ではサポートされません。ワイルドカードは、いずれのフィールドの LDAP 項目でもサポートされません。
複数のポリシーがサポートされ、ポリシーが競合する場合には、偽の値が常に優先します。言い換えれば、ポリシー内の単一の否定でアクセスが阻止されます。構成およびポリシー・ファイルにポリシーがリストされている順序は無関係で、優先順位を設定するものではありません。
一連のポリシーの例では、構成ファイル・ディレクトリーの pacpolicy.conf ファイルを参照してください。
pac_ldap.cred という名前のプレーン・テキストを /cp_root/server_root/pac/creds 内に作成します。 このファイルには、pac.conf ファイル内の admin_dn デ ィレクティブのユーザー名に 対応するパスワードが入ります。
PAC デーモンは、初めてそのファイルを読み取ったときにパスワードを暗号化します。
ファイル pac_ldap.cred を Linux および UNIX プラットフォームで作成するには、次のコマンドを実行します。
cd cp_root/server_root/pac/creds echo "password" > pac_ldap.cred chown nobody pac_ldap.cred chgrp nobody pac_ldap.cred (on SUSE Linux, use chgrp nogroup pac_ldap.cred.)
このファイルを Windows プラットフォームで作成するには、テキスト・ファイルにパスワードを入力し、そのファイルを server_root¥pac¥creds¥ ディレクトリーに格納します。
LDAP 許可デーモンは、pacd プロセスとして実行します。規定のスクリプトを使用して、Caching Proxy に割り込まずに LDAP 許可を再始動することができます。次の手順で pacd スクリプトを実行します。
/usr/sbin/pacd_restart.sh pacd_user_id
C:¥Program Files¥IBM¥edge¥cp¥Bin¥pacd_restart.bat CP_install_root
kill -15 pacd_process_ID
HP-UX の場合: PAC-LDAP プラグインおよび pacd は、実行時にすべての従属共用ライブラリーをロードしません。それらを使用する前に、システム変数が次のように設定されていることを確認してください。
SHLIB_PATH=/usr/lib:/usr/IBMldap/lib PATH=/usr/IBMldap/bin:$PATH PATH=/usr/IBMldap/bin
/usr/IBMldap/ は、HP-UX の LDAP クライアント用のデフォルトのインストール・パスです。LDAP クライアントが別のロケーションにインストールされている場合は、それに応じて PATH および SHLIB_PATH を調整してください。これらの変数を設定しないと、次のエラーが発生する可能性があります。
"Serverinit Error: server did not load functions from DLL module /opt/ibm/edge/cp/lib/plugins/pac/libpacwte.sl"
"/usr/lib/dld.sl: Can't find path for shared library: libibmldap.sl /usr/lib/dld.sl: No such file or directory Abort"
Linux の場合: SUSE Linux Enterprise Server 9 の場合、ldd pacd は、libldap.so が見つからない、とレポートことがあります。この問題に対処するには、 以下のシンボリックを作成してください。
ln -s /usr/lib/libldap.so.19 /usr/lib/libldap.so
AIX の場合: IBM Tivoli Directory Server 5.2 で pacd を開始する場合は、 PAC-LDAP モジュールがロードできずに、次のエラーが出される可能性があります。
exec(): 0509-036 Cannot load program /usr/sbin/pacd because of the following errors: 0509-022 Cannot load module /usr/lib/libpacman.a. 0509-150 Dependent module libldap.a could not be loaded. 0509-022 Cannot load module libldap.a.
この問題に対処するには、 以下のシンボリックを作成してください。
ln -s /usr/lib/libibmldap.a /usr/lib/libldap.a
Could not extract a value for: Uid, return code:3このエラーは、LDAP 認証が正しく機能している場合でも表示されますので、無視することができます。
ここでは、ログおよびサーバー・アクティビティー・モニターを使用した Caching Proxy のモニターについて説明します。
ここには、次のトピックが含まれます。
ロギングをカスタマイズするために、「構成および管理」フォームを使用するか、または プロキシー構成ファイルのディレクティブを編集することができます。以下のオプションを 設定できます。
Caching Proxy では、3 種類のアクセス・ログに加えて 1 つのイベント・ログと 1 つのエラー・ログを作成できます。
Caching Proxy は、毎日、午前 0 時に新規ログ・ファイルを作成します。プロキシーが午前 0 時に実行されていない場合、その日の最初に開始されるときに、新規ログが作成されます。それぞれのログ・ファイルにディレクトリーとファイル名接頭部を指定することができます。また、作成されるそれぞれのログ・ファイルには、.Mmmddyyyy 形式の日付接尾部 (例えば、.Apr142000) が含まれます。
ログは大量のスペースを使用することがあるので、エラーを回避するために、ログ・ファイル をオペレーティング・システムおよびキャッシュとは別のストレージ・デバイスに 格納することを検討してください。また、ログの保守とアーカイブで示すような ログ保守ルーチンを構成してください。
プロキシー・サーバー・ログの基本構成を指定するには、「構成および管理」フォームで、「サーバー構成」->「ログ記録」->「ログ・ファイル」を選択します。 使用するログ・ファイルごとに、パス名およびファイル名を指定します。各ログの現在のファイル名が対応するテキスト・ボック スに表示されます。パスを指定していない場合には、デフォルトのパスが表示されます。
プロキシー・ログに記録された情報は、システム・ログに自動的に書き込まれるのでは なく、独自のログの他に追加で、またはそのログの代わりにシステム・ログに 書き込むように Caching Proxy を構成することができます。「ログ・ファイル」フォームで、「情報を Syslog へ記録」チェック・ボックス を選択します。このオプションを選択する前に、システム・ログを作成しておく必要があることに注意してください。
プロキシー・サーバー・ログ情報をシステム・ログのみに書き込むように指定するには、 プロキシー構成ファイルを編集する必要があります。LogToSyslog - アクセス情報をシステム・ログに送信するかどうかを指定する (Linux と UNIX 専用)を参照してください。
関連する構成ファイル・ディレクティブ
プロキシー構成ファイルを使用することによりログをセットアップするには、付録B. 構成ファイル・ディレクティブの以下のディレクティブについての解説セクションを参照してください。
アクセス・ログは、ホスト・マシン、プロキシー、およびキャッシュの活動を記録します。 プロキシーがアクセス要求を受信するたびに、以下の情報を含む項目が適切な アクセス・ログに作成されます。
アクセス・エラーは、サーバーのエラー・ログに記録されます。
ログを制御する理由は、いくつかあります。
使用頻度の高いサーバーのログ・ファイルは、サーバーのディスク・スペースが いっぱいになるほど大きくなることがあります。デフォルトでは、すべてのアクセス要求が ログに記録されるようになっていますが、そのことは、HTML ページだけでなく そのページに含まれるそれぞれのイメージについてもログ項目が作成されることを意味します。 有意義なアクセス要求だけを含めることによって、ログの項目数を大幅に減らすことができます。 例えば、アクセス・ログを構成して、HTML ページに対するアクセス要求を示すログ項目だけ を含めて、GIF イメージのアクセス要求の項目は含めないようにすることができます。
例えば、社外からサーバーにアクセスしている人を知りたい場合は、社内の IP アドレスから出るアクセス要求をフィルターに掛けて除外します。 特定の Web サイトの利用者数を知りたい場合は、その URL に対するアクセス要求のみを 示すアクセス・ログを作成することができます。
アクセス・ログから除外された情報は、アクセス・レポートには記録されず、後で使用することはできません。したがって、 どの程度のアクセス情報をトラッキングする必要があるかどうかわからない場合は、 サーバーのモニターに関して経験を得るまで、除外フィルターの適用を控えめにします。
アクセス・ログ項目は、次のいずれかの属性に基づいてフィルターに掛けることができます。
フィルターを指定するには、「構成および管理」フォームで、「サーバー構成」->「ログ記録」->「アクセス・ログ除外」を選択します。 除外する必要のあるもののみ指定します。すべてのカテゴリーを使用する必要はありません。
「実行依頼」をクリックします。
関連する構成ファイル・ディレクティブ
プロキシー構成ファイルを使用することによりアクセス・ログ・フィルターを設定するには、付録B. 構成ファイル・ディレクティブの以下のディレクティブについての解説セクションを参照してください。
Caching Proxy デフォルト構成では、すべてのログが使用可能にされています。 すべてのログは、インストール・ディレクトリーの logs/ サブディレクトリーに格納されます。 デフォルト・パスは、次のとおりです。
各ログ・ファイル名は、ベース名と .Mmmddyyyy という形式の日付接尾部を組み合わせた名前になります (例えば、proxy.Feb292000)。
デフォルトでは、ログは共通ファイル形式で格納されます。 結合ログ形式を使用する こともでき、次の行をプロキシー構成ファイル (ibmproxy.conf) に追加することに よって設定できます。
LogFileFormat combined
結合ログ形式は共通形式と似ていますが、参照者、ユーザー・エージェント、および Cookie 情報を表示する追加のフィールドがあります。 地方時形式がデフォルトの時間形式です。
デフォルトでは、アクセス要求はすべて適切なアクセス・ログに記録されて、システム・ログにはアクセス情報は記録されません。 エラー・ログ情報はエラー・ログにのみ書き込まれ、イベント・ログ情報はイベント・ログにのみ書き込まれます。
デフォルト構成では、ログはアーカイブも削除もされません。
Caching Proxy は、プラグインを使用してログを管理します。 詳細については、付録B. 構成ファイル・ディレクティブの構成ファイル・ディレクティブについて Midnight - ログのアーカイブに使用される API プラグインを指定するの解説ページを参照してください。
日々のログをアーカイブしたり、ログを除去する方法を指定することができます。基本的なオプションとして、次のものがあります。
デフォルトでは、本日と前日のログが保守エージェントによって削除される ことはありません。本日のログおよび前日のキャッシュ・アクセス・ログのすべてが、 保守エージェントによって圧縮されることはありません。
ログ保守を構成するには、「構成および管理」フォームで、「サーバー構成」->「ログ記録」->「ログ・アーカイブ」を選択します。 このフォームで、ドロップダウン・ボックスを使用して保守メソッドを 指定します。
関連する構成ファイル・ディレクティブ
プロキシー構成ファイルを使用してログのアーカイブを構成するには、付録B. 構成ファイル・ディレクティブの以下のディレクティブについての解説ページを参照してください。
次の例では、要件に合わせてログ記録をカスタマイズする方法を示しています。Caching Proxy を 購入してインストールした直後を想定します。以下の要件について、サーバーを セットアップして、アクセス情報およびエラー情報をログに記録します。
これらの基準に従ってログを保持するように Caching Proxy を構成するには、 「構成および管理」フォームで「サーバー構成」-> 「ロギング」と選択します。
これらの指示に従って、プロキシー構成ファイルに次の行が作成されます。
LogArchive purge PurgeAge 30 PurgeSize 25 AccessLogExcludeURL *.gif NoLog 130.128.*.* AccessLogExcludeReturnCode 300
Caching Proxy のサーバー活動モニターは、サーバーおよびネットワークのパフォーマンス統計、サーバーおよ びネットワークの状況、およびアクセス・ログ項目を表示します。このモニターはリモート側で使用することができ、プロキシー・サーバーを実行している同じマシン上になくてもかまいません。 サーバー活動はデフォルトで使用可能にされており、構成は必要ありません。
サーバー活動モニターを開くには、以下の 2 とおりあります。
http://your.server.name/Usage/Initial
構成クライアント内のその他のフォームとは異なり、このカテゴリーのフォームでは、サーバーの構成を設定するのではなく、サーバーの使用状況に関するデータが表示されます。これらの フォームでは、単一のコンソール・ウィンドウに表示できる情報よりも相当に多くの 情報が提供されます。
以降のセクションでは、「サーバー活動モニター」が提供する情報のタイプ、 およびその情報を使用してパフォーマンスを調整する方法を示しています。
以下の「サーバー活動モニター」ページを使用できます。
これらのページのそれぞれには「最新表示」ボタンがあり、これを使用すると、 情報を更新できます。
活動統計
表 4 は、「活動統計」ページの例です。
活動統計 | |
---|---|
接続 | 1 アクティブ、431 最大 |
応答時間 | 利用不能 |
スループット | 0 接続/秒 |
今日処理した要求 | 0 |
処理した要求の総量 | 114 |
要求エラー | 3 |
これらのサーバー活動統計を使用して、アクセス要求の数、応答時間、スループット、今日処理した要求数、処理済みの合計要求数、エラーなどによって、サーバーのトラフィックをモニターすることができます。 以下の構成変更によって、「活動」ページの統計が影響を受けます。
ネットワーク統計
表 5 は、「ネットワーク統計」ページの例です。
ネットワーク統計 | |
---|---|
送信データ: | 1KB/秒 |
着信データ: | 1KB/秒 |
保管された帯域幅: | 3KB (0KB/秒) |
今日保管された帯域幅: | 0KB (0KB/秒) |
「ネットワーク統計」フォームは、プロキシーが実行中のネットワークに関する情報 (送受信バイト数によるデータ速度を含む) を提供します。
アクセス統計
「アクセス統計」ページには、アクセス・ログの中の 最新の 20 項目が表示されます。このページには、プロキシー・アクセス・ログ (黒のタイプ) およびキャッシュ・アクセス・ ログ (青のタイプ) の中の最新の項目が表示されます。 ログの対象となるものをカスタマイズすることによって、表示内容をカスタマイズできます。アクセス・ログ統計についての詳細は、アクセス・ログ・フィルターを参照してください。
プロキシー・アクセス統計
「プロキシー・アクセス統計」フォームでは、どの URL が要求された か、URL がキャッシュから提供されたことなど、プロキシー活動に関する情報が提供 されます。 URL のあとには、クライアントに提供される戻りコードとバイト単位のファイル・サイズが 示されます。 以下の設定によって、プロキシー・アクセス統計を改善できます。
キャッシュ統計
キャッシュが使用可能な場合、「キャッシュ統計」ページには最新のキャッシュ ・アクセス情報が表示されます。 以下のようなキャッシュと索引に 関する情報が提供されます。
多くのキャッシュ構成オプションでキャッシュ統計結果が変更されます。(プロキシー・サーバー・キャッシングの構成を参照)
キャッシュ・リフレッシュ要約
キャッシュ・エージェントがキャッシュにファイルをプリロードするように構成されている場合には、「キャッシュ・リフレッシュ要約」ページにキャッシュ・エージェントの最後の実行に関する情報が表示されます。 情報を表示するには、キャッシュ・エージェントが少なくとも一度は実行されている必要があります。キャッシュ・エージェントのリフレッシュ方法を変更するには、以下の事項について検討してください。
このトピックには、プロキシー・サーバー・コマンドのリファレンスを記載してあります。
cgiparse コマンドは、CGI スクリプトの QUERY_STRING 環境変数を解析するために使用します。QUERY_STRING 環境変数が設定されていない場合は、コマンドは、標準入力から CONTENT_LENGTH で指定された文字数だけ文字を読み取ります。 戻される出力はすべて、標準出力に書き込まれます。
cgiparse -Flag [Modifier]
フラグ、フラグと等価な 1 文字 (-k -f -v -r -i -s -p -c -q -P)、およびフラグの機能を 以下に示します。
eval 'cgiparse -init'
このコマンドが呼び出されると、GET または POST のどちらが使用されたかに関係なく、QUERY_STRING 環境変数が設定されます。
cgiparse は、GET メソッドが使用される場合には同じスクリプトで 複数回呼び出すことができますが、POST メソッドが使用される場合には、一度だけ呼び出します。 POST メソッドの場合、標準入力が読み取られた後、2 回目に cgiparse を呼び出しても 標準入力は空であり、無期限に待機することになります。
以下の例では、実際には QUERY_STRING がすでにサーバーによって設定されているという事実を無視しています。 これらの例において、$ は Bourne シェル (B シェル) のプロンプトです。
$ QUERY_STRING="is+2%2B2+really+four%3F" $ export QUERY_STRING $ cgiparse -keywords is 2+2 really four? $
$ export QUERY_STRING="name1=Value1&name2=Value2%3f+That%27s+right%21"; $ cgiparse -form FORM_name1='Value1'; FORM_name2='Value2? That'¥'s right!' $ eval `cgiparse -form` $ set | grep FORM FORM_name1="Value1" FORM_name2="Value2? That's right!" $
$ QUERY_STRING="name1=value1&name2=Second+value%3F+That'¥'s%27s $ cgiparse -value name1 value1 $ cgiparse -value name2 Second value? That's right! $
nph (no-parse header) プログラムで cgiutils コマンドを使用して、完全な HTTP 1.0 応答を生成します。
cgiutils -Flag [Modifier]
Modifier にブランクが含まれる場合は、それを引用符 ("") で囲んでください。
cgiutils -ct text/html
type/subtype を省略すると、MIME コンテンツ・タイプは、デフォルトの text/plain に設定されます。次の例は、MIME コンテンツ・タイプを text/plain に戻します。
cgiutils -ct
cgiutils -ce x-compress
cgiutils -cl en_UK
cgiutils -expires 2 days 12 hours
この cgiutils コマンドは、指定された時間を現在の GMT (グリニッジ標準時) に加算して有効期限日付を求めます。有効期限日付 は、HTTP 形式で Expires: ヘッダーに書き込まれます。
cgiutils -expires "1 year 3 months 2 weeks 4 days 12 hours 30 mins"
cgiutils -status 200 -reason "Virtual doc follows" -expires now
このコマンドは、次のようなヘッダーを生成します。
HTTP/1.0 200 Virtual doc follows MIME-Version: 1.0 Server: IBM-ICS Date: Tue, 05 Jan 1996 03:43:46 GMT Expires: Tue, 05 Jan 1996 03:43:46 GM
Server: ヘッダーは CGI 環境で使用可能なため、cgiutils コマンドは 自動的にこのヘッダーを生成します。また、-nodate フラグを指定しない 限り、Date: フィールドも自動的に生成されます。
MIME ヘッダー・セクションの終わりを示すために、出力の後にさらにブランク行が 1 行出力されます。ユーザー固有のヘッダーをさらに出力したい場合は、-noel (NO-Empty-Line) フラグを次の例で示すように使用してください。
cgiutils -noel -expires "2 days" -nodate
HTTP/1.0 200 Virtual doc follows MIME-Version: 1.0 Server: IBM-ICS Expires: Tue, 07 Jan 1996 03:43:46 GMT
htadm コマンドの使用目的は、サーバー・パスワード・ファイルを制御することです。 サーバーはパスワード・ファイルを使用して、ファイルへのアクセスを制御します。パスワード・ファイルへ ユーザー名を追加したり、パスワード・ファイルからユーザーを削除したり、ユーザーのパスワードを検査したり、 空のパスワード・ファイルを作成したりすることができます。 まずユーザーのパスワードを削除してから、新しいパスワードを作成することによって、ユーザーのパスワードを変更することもできます。
htadm -Flag [Modifier]
ユーザー名に使用できる文字は英字および数字のみです。特殊文字を使用してはなりません。
指定した名前のユーザーがすでにパスワード・ファイル内にある場合は、このコマンドは失敗します。
パスワードは最大 32 文字の長さです。 パスワードに使用できる文字は英字および数字のみです。特殊文字を使用してはなりません。
パスワードは最大 32 文字の長さです。 パスワードに使用できる文字は英字および数字のみです。特殊文字を使用してはなりません。
htadm -adduser /opt/ibm/edge/cp/server_root/protect/heroes.pwd clark superman "Clark Kent"
htadm -adduser "C:¥Program Files¥IBM¥edge¥cp¥server_root¥protect¥ heroes.pwd" clark superman "Clark Kent"
htadm -deluser /opt/ibm/edge/cp/server_root/protect/ heroes.pwd clark superman "Clark Kent"
htadm -deluser "C:¥Program Files¥IBM¥edge¥cp¥server_root¥protect¥ heroes.pwd" clark superman "Clark Kent"
htcformat コマンドは、プロキシー・キャッシュを保持するロー・デバイスまたはファイルの準備 を行うときに使用します。プロキシー・キャッシュで使用するようデバイスを指定する前に、このフォーマット・コマンド を使用する必要があります。
装置パスでロー・デバイスを指定することが必要です。ロー・デバイスへのアクセス方法の詳細については、使用ファイル・システムの資料を参照 してください。プロキシー・サーバー・キャッシングの構成の例を利用できます。
Caching Proxy キャッシュの最小サイズは 16392 KB であり、2049 ブロックです。
htcformat device [-blocksize <block size>] [-blocks number of blocks] htcformat -file filepath [-blocksize block size] -blocks number of blocks
さらに、キャッシュ・ファイルまたはキャッシュ・デバイスは、キャッシュ・システムによって 索引化とガーベッジ・コレクションのためにコンテナー内に分離されます。コンテナーのサイズは、一定数のブロックに設定されます。つまり、コンテナーのサイズを構成 することはできません。ガーベッジ・コレクションを実行するために、最低限 2 つのコンテナーが必要です。最小 キャッシュ・サイズは 16392 KB です。
htcformat コマンドでは、コンテナーが 2 つ未満のキャッシュ・デバイスを生成するようなフォーマット要求は拒否されます。
次の例では、c0t0d0s0 というディスク区画を Solaris 上でフォーマット します。
htcformat /dev/rdsk/c0t0d0s0
次の例では、lv02 というディスク区画を AIX 上でフォーマットします。
htcformat /dev/rlv02
次の例では、d: というディスク区画を Windows 上でフォーマットします。
htcformat ¥¥.¥d:
次の例では、filecache という名前のファイルを約 1 GB の大きさに フォーマットします。
htcformat -file /opt/ibm/edge/cp/filecache -blocks 131072
ibmproxy コマンドは、サーバーを始動するために使用します。
これらのフラグは、(-r を除く) すべて、サーバー構成ファイル内のディレクティブを使用して 設定することができます。
通常、そのディレクトリーについてよく知らないユーザーが読む指示または注意が 書かれている README という名前のファイルを作成します。 ibmproxy コマンドはデフォルトでは、ハイパーテキスト・バージョンのディレクトリーに README ファイルを埋め込みます。README ファイルの指示は、DirReadme 構成ディレクティブで設定することもできます。
ibmproxy [-Flag [-Flag [-Flag..]]]
http デーモンは、サーバーが現在 PidFile にアクセスするために使用している構成ファイルを読み取る必要があるため、再始動する際には、同じ構成ファイルを指定する必要があります。サーバーの始動時に -r フラグと特定の構成ファイルを使用した場合、このフラグおよび同じファイルを -restart で指定する必要があります。
また、シグナル処理オプションは Linux および UNIX プラットフォームのみに存在します。 Linux および UNIX プラットフォームでは、次のオプションが使用可能です。
ibmproxy -p 8080 -r /usr/etc/ibmproxy.conf
startsrc -s ibmproxy
デフォルト構成ファイルがない場合、ibmproxy は、/Public ディレクトリー ・ツリーをエクスポートします。 このツリーには、他のディレクトリー・ツリーへのソフト・リンクを入れることができます。
この トピック では、ibmproxy.conf 構成ファイルに含まれているディレクティブを説明します。
ibmproxy.conf ファイルを編集してサーバーを構成するときに、この情報を参照してください。「構成および管理」フォームを使用する場合は、この章を参照する必要はありません。
ディレクティブは、アルファベット順にリストされています。
ディレクティブの中には、再始動時に更新されないものがあります。サーバーの実行中に以下のディレクティブを変更した場合には、手動でサーバーを停止してから、それを再始動する必要があります。(Caching Proxy の開始および停止を参照してください。)
ディレクティブ・グループ | ディレクティブ |
CGI | DisinheritEnv、InheritEnv |
Caching | Caching |
ロギング | AccessLog、 CacheAccessLog、 ErrorLog、 ProxyAccessLog、 ServerRoot |
ネットワーク・アクセス | BindSpecific、Hostname、ListenBacklog、Port |
パフォーマンス | MaxActiveThreads |
RTSP | すべての RTSP ディレクティブ |
SSL | すべての SSL ディレクティブ |
Linux および UNIX プロセス制御 | GroupId、UserId |
その他 | TransparentProxy |
この付録では、各ディレクティブについて以下の情報を示します。
DirectiveName value
これらの値は、デフォルトの構成ファイルに最初からコーディングされている値です。変更を加える場合は、デフォルト値から、変えたい設定値の部分だけを変更してください。当初からデフォルト値のコーディングされないディレクティブは、ファイルの中で前にコメント・マーカー (#) を付けて表示されています。そのディレクティブに値を指定したい場合には、コメント・マーカーを除去し、値を構成ファイル内の行に追加してください。
以下のリストには、構成ファイルで受け入れられる値が含まれています。
すべての項目は、秒に変換されてから集計されます。
構成ファイルを編集する際には、次の要件を忘れないでください。
Caching Proxy ディレクティブは、以下のとおりです。
このディレクティブは、ファイルの MIME タイプがクライアントから送信された ACCEPT: ヘッダーと一致しない場合であってもそのクライアントにファイルを提供するときに使用します。このディレクティブが OFF に設定されている場合は、クライアントが受け入れ可能なタイプと異なる MIME タイプのファイルは表示されません。代わりに、エラー・ページが表示されます。
AcceptAnything {on | off}
AcceptAnything off
AcceptAnything on
このディレクティブを使用して、サーバーがアクセス統計をログに記録する場所のディレクトリーとファイルを指定します。デフォルトでは、クライアントがサーバーに、ローカル・サーバーに格納されているデータを要求するたびに、サーバーがその項目をこのログに書き込みます。通常、これらの項目には、Caching Proxy マシンが起点サーバーとして使用されるときに、構成クライアントからの要求またはアクセスが含まれるだけです。このログには、プロキシーまたはキャッシュ・アクセス情報は含まれません。
NoLog ディレクティブは、その要求をログに記録しないクライアントを指定するときに使用します。NoLog ディレクティブについては、NoLog - テンプレートと一致する特定のホストまたはドメインのログ項目を抑制するを参照してください。
サーバーは、午前 0 時に新規ログ・ファイルを開始します (サーバーが稼働している場合)。午前 0 時にサーバーが稼働していない場合は、その日における最初のサーバー始動時に新規ログ・ファイルの記録を開始します。ファイル作成時に、サーバーは、指定されたファイル名を使用し、日付接尾部を付加します。日付接尾部は、Mmmddyyyy という形式です。Mmm は月の最初の 3 文字、dd は日、yyyy は年です。
古いログ・ファイルは、ハード・ディスク上で大量のスペースを使用する可能性があるため、これらのファイルは除去するようにしてください。
AccessLog /directory_path/logfile_name
AccessLog /logs/accesslog
このディレクティブは、ファイルまたはディレクトリーにアクセスするために特定のメソッドによって行われた要求のロギングは防止するときに使用します。例えば、ファイルまたはディレクトリーに対する DELETE 要求はログに記録したくない場合があります。
このディレクティブは、構成ファイル内に複数回指定することができます。 また、1 つまたは複数のスペースで区切れば、1 つのディレクティブに複数のメソッドを指定することもできます。
AccessLogExcludeMethod method [...]
AccessLogExcludeMethod GET AccessLogExcludeMethod PUT AccessLogExcludeMethod POST AccessLogExcludeMethod DELETE AccessLogExcludeMethod GET PUT
なし。サーバーは、すべての種類のメソッドに必要なファイルとディレクトリーをアクセス・ログに記録します。
このディレクティブは、指定の MIME タイプのディレクトリーまたはファイルに対するアクセスの要求をプロキシー・アクセス・ログに記録したくないことを指定するときに使用します。(MIME タイプの例としては、text/html、image/gif、および image/jpeg があります。) 例えば、GIF イメージへのアクセス要求を記録しないようにすることができます。
このディレクティブは、構成ファイル内に複数回指定することができます。 また、1 つまたは複数のスペースで区切れば、1 つのディレクティブに複数の MIME タイプを指定することもできます。
AccessLogExcludeMimeType MIME_type [...]
AccessLogExcludeMimeType image/gif AccessLogExcludeMimeType text/html AccessLogExcludeMimeType image/gif text/html
なし。アクセス・ログには、すべての MIME タイプのファイルとディレクトリーに対する要求 (サーバー用) が含まれています。
このディレクティブは、指定の範囲のエラー・コード番号に入るアクセス要求はログに記録したくないことを指定する場合に使用します。これらのエラー・コード番号は、プロキシー・サーバー状況コードです。個々のコードを指定することはできません。300 を指定すると、リダイレクト戻りコード (301、302、303、および 304) を持つアクセス要求を除外したいということが示されます。
このディレクティブは、構成ファイル内に複数回指定することができます。 また、1 つまたは複数のスペースで区切れば、1 つのディレクティブに複数の戻りコードを指定することもできます。
AccessLogExcludeReturnCode range
AccessLogExcludeReturnCode 300
なし。アクセス・ログには、コードとは関係なく、サーバーへ送信するすべての要求が含まれています。
このディレクティブは、指定の URL テンプレートに一致する特定のファイルまたはディレクトリーに対するアクセスの要求をログに記録したくないことを指定するときに使用します。例えば、GIF ファイルへのアクセス要求はログに記録したくない場合や、サーバー上の特定のファイルまたはディレクトリーに対するアクセス要求はログに記録したくない場合があります。
このディレクティブは、構成ファイル内に複数回指定することができます。 また、1 つまたは複数のスペースで区切れば、1 つのディレクティブに複数の項目を指定することもできます。
AccessLogExcludeURL file_or_type [...]
AccessLogExcludeURL *.gif AccessLogExcludeURL /Freebies/* AccessLogExcludeURL *.gif /Freebies/*
なし。サーバーは、すべてのファイルおよびディレクトリーに対するアクセスの要求をログに記録します。
このディレクティブは、特定のユーザー・エージェント (例えば、Internet Explorer 5.0) が行った アクセス要求をログに記録しないことを指定する場合に使用します。
このディレクティブは、構成ファイル内に複数回指定することができます。 また、1 つまたは複数のスペースで区切れば、1 つのディレクティブに複数の項目を指定することもできます。
AccessLogExcludeUserAgent user_agent [...]
AccessLogExcludeUserAgent *Mozilla/2.0 AccessLogExcludeUserAgent *MSIE 5*
ibmproxy.conf ファイルは、AccessLogExcludeUserAgent ディレクティブに対する次の定義をデフォルトで含みます。
AccessLogExcludeUserAgent IBM_Network_Dispatcher_HTTP_Advisor AccessLogExcludeUserAgent IBM_Network_Dispatcher_WTE_Advisor
上記のユーザー・エージェントは、通常、Caching Proxy サーバーの前面に配置された、 特定の Load Balancer アドバイザー用に定義されています。これらのユーザー・エージェントは、 ログへの書き込み回数を最少化してパフォーマンスを向上させるため、ログに記録されません。 デフォルトでは、サーバーは、他のすべてのユーザー・エージェントによるアクセス要求を ログに記録します。
このディレクティブは、サーバーが FTP 要求のためのプロキシーとして働く場合に、戻されたディレクトリー・リストの見出しの位置合わせに使用するアイコンを指定するときに使用します。アイコンは関連ファイルのそばに表示され、ファイルを区別するのに役立ちます。
このアイコンは、ブランク・アイコンとするか、あるいはディレクトリー・リストの見出しに表示されるように指定する別のアイコンとすることができます。正しい位置合わせのためには、使用するアイコンのサイズは、ディレクトリー・リスト上で使用する他のアイコンと同じでなければなりません。
AddBlankIcon icon_URL alternative_text
アイコンの URL の最後の部分を指定します。サーバーはこの値を /icons/ ディレクトリーに付加して、 完全な URL 要求を形成します。ローカル・ファイルに対する要求の場合は、サーバーは、マッピング・ディレクティブによって要求を変換します。アイコンが検索されるためには、マッピング・ディレクティブで要求が渡されるようにしなければなりません。
サーバーをプロキシー・サーバーとして使用する場合は、完全要求は、 サーバーを指す完全修飾 URL でなければなりません。
AddBlankIcon logo.gif logo
デフォルトでは、アイコンがブランクになっているので、代替テキストは指定されていません。
このディレクティブを使用して、ディレクトリー・リスト上のディレクトリーを表すアイコンを指定します。
AddDirIcon icon_URL alternatIve_text
アイコンの URL の最後の部分を指定します。サーバーはこの値を /icons/ ディレクトリーに付加して、 完全な URL 要求を形成します。ローカル・ファイルに対する要求の場合は、サーバーは、マッピング・ディレクティブによって要求を変換します。アイコンが検索されるためには、マッピング・ディレクティブで要求が渡されるようにしなければなりません。
サーバーをプロキシー・サーバーとして使用する場合は、完全要求は、 サーバーを指す完全修飾 URL でなければなりません。URL をローカル・ファイルにマップし、マッピング・ディレクティブによって、URL が渡されるようにしなければなりません。
AddDirIcon direct.gif DIR
このディレクティブは、特定の接尾部を持つファイルを MIME エンコード・タイプにバインドする場合に使用します。このディレクティブはあまり使用されません。
AddEncoding .extension encoding
AddEncoding .qp quoted_printable
AddEncoding .Z x-compress
このディレクティブを使用して、特定の MIME コンテンツ・タイプまたはエンコード・タイプを持つファイルを表すアイコンを指定します。サーバーは、このアイコンを FTP ディレクトリー・リストを含むディレクトリー・リストで使用します。
AddIcon icon_URL alternative_text MIME_type_template
アイコンの URL の最後の部分を指定します。サーバーはこの値を /icons/ ディレクトリーに付加して、 完全な URL 要求を形成します。ローカル・ファイルに対する要求の場合は、サーバーは、マッピング・ディレクティブによって要求を変換します。アイコンが検索されるためには、マッピング・ディレクティブで要求が渡されるようにしなければなりません。
サーバーをプロキシー・サーバーとして使用する場合は、完全要求は、 サーバーを指す完全修飾 URL でなければなりません。URL をローカル・ファイルにマップし、マッピング・ディレクティブによって、URL が渡されるようにしなければなりません。
AddIcon video_file.m.pm.gif MOV video/*
ibmproxy.conf 構成ファイルの AddIcon ディレクティブには、多数のデフォルトが設定されています。
このディレクティブを使用して、ディレクトリー・リスト上の親ディレクトリーを表すアイコンを指定します。
AddParentIcon icon_URL alternative_text
アイコンの URL の最後の部分を指定します。サーバーはこの値を /icons/ ディレクトリーに付加して、 完全な URL 要求を形成します。ローカル・ファイルに対する要求の場合は、サーバーは、マッピング・ディレクティブによって要求を変換します。アイコンが検索されるためには、マッピング・ディレクティブで要求が渡されるようにしなければなりません。
サーバーをプロキシー・サーバーとして使用する場合は、完全要求は、 サーバーを指す完全修飾 URL でなければなりません。URL をローカル・ファイルにマップし、マッピング・ディレクティブによって、URL が渡されるようにしなければなりません。
AddParentIcon parent.gif UP
AddParentIcon dir-up.gif UP
このディレクティブを使用して、特定の接尾部を持つファイルを MIME タイプおよびサブタイプにバインドします。このディレクティブは、構成ファイル内に複数回指定することができます。 サーバーは、最も一般的に使用される接尾部のためのデフォルトを提供します。
AddType .extension type/subtype encoding [quality[ character_set]]
その他のエンコード値はすべて binary と同様に扱われ、コンテンツ・エンコード MIME ヘッダーとして MIME ヘッダーに入れて渡されます。7bit および 8bit は、MIME ヘッダーに入れて送信されることはありません。
AddType .ps application/postscript 8bit 1.0 AddType *.* application/binary binary 0.3
AddType .bin application/octet-stream binary 0.8
構成ファイル (ibmproxy.conf) には、AddType ディレクティブの多数のデフォルト設定が含まれています。
このディレクティブを使用して、ディレクトリー・リスト上のファイル・タイプ不明のファイルを表すアイコンを指定します。
AddUnknownIcon icon_URL alternative_text
アイコンの URL の最後の部分を指定します。サーバーは、この値を /icons/ に付加して、完全な URL 要求を形成します。ローカル・ファイルに対する要求の場合は、サーバーは、マッピング・ディレクティブによって要求を変換します。アイコンが検索されるためには、マッピング・ディレクティブで要求が渡されるようにしなければなりません。
サーバーをプロキシー・サーバーとして使用する場合は、完全要求は、 サーバーを指す完全修飾 URL でなければなりません。URL をローカル・ファイルにマップし、マッピング・ディレクティブによって、URL が渡されるようにしなければなりません。
AddUnknownIcon saywhat.gif unknown
このディレクティブを使用して、管理者がサーバーの状況ページまたは構成フォームにアクセスする場合に使用するポートを指定します。このポートに対する要求は、Port ディレクティブで定義されている標準ポート上の、他のすべての着信要求とともにキューには入りません。 ただし、AdminPort 上の要求は、通常のアクセス制御および Pass、 Exec、Protect などの要求マッピング規則を介して実行します。
AdminPort port_number
AdminPort 2001
AdminPort 8008
このディレクティブは、起点サーバーによって戻され、キャッシュ不可能のマークのあるファイルをキャッシュに入れる必要があるかどうかを指定するときに使用します。このディレクティブに従ってキャッシュに入れられたキャッシュ不可能なファイルには、再妥当性検査が必要である旨のマークが付けられます。このファイルが要求されるたびに、プロキシー・サーバーは、応答がキャッシュから提供される前にその応答の妥当性を再検査するために、If-Modified-Since (その後変更されたかどうか) の要求を起点サーバーに送信します。現在のところ、"cache-control: no-cache" ヘッダーを含む起点サーバーからの応答は、このディレクティブの影響を受けるキャッシュ不可能なファイルだけです。このディレクティブは、複数回指定することができます。
AggressiveCaching url_pattern
AggressiveCaching http://www.hosta.com/* AggressiveCaching http://www.hostb.com/*
逆方向の互換性のために、このディレクティブの前の構文 (AggressiveCaching {on | off}) は、以下のように取り扱われることになりました。
なし
ディレクトリー名を含むが、ファイル名は含まない要求の場合、AlwaysWelcome ディレクティブは、サーバーがディレクトリーで戻すべきウェルカム・ファイルを探すかどうかを指定します。デフォルトにより、AlwaysWelcome の値は on に設定されます。 つまり、サーバーは必ず要求されたディレクトリーを見て、Welcome ディレクティブに指定された名前に一致するファイルを探すということです。一致するファイルが見つかると、そのファイルが要求側に戻されます。 サーバーが、ディレクトリー内のファイルと Welcome ディレクティブに指定されたファイル名との間で一致するものを複数見つけた場合は、Welcome ディレクティブの順序によって、どのファイルが戻されるかが決まります。 サーバーは、構成ファイルの一番上に最も近い Welcome ディレクティブを使用します。
AlwaysWelcome on | off
AlwaysWelcome on
このディレクティブは、Caching Proxy が POST 要求の本文の最後に復帰文字と改行文字を付加する必要のある URL を指定するときに使用します。このディレクティブは、複数回指定することができます。
appendCRLFtoPost url_pattern
appendCRLFtoPost http://www.hosta.com/
なし
このディレクティブは、複数のサーバーに共用されるリモート・キャッシュ配列を指定するときに使用します。
ArrayName array_name
なし
このディレクティブを使用して、サーバー要求処理の認証ステップ実行中にサーバーで呼び出したいカスタマイズ済みアプリケーション関数を指定します。 このコードは、認証方式に従って実行されます。BASIC 認証だけがサポートされています。
Authentication type /path/file:function_name
Authentication BASIC /ics/api/bin/icsextpgm.so:basic_authentication
なし
このディレクティブは、サーバー要求プロセスの許可ステップの実行中にサーバーで呼び出すカスタマイズ済み アプリケーション関数を指定するときに使用します。このコードは、要求されたオブジェクトをクライアントに提供できるようにします。
Authorization request_template /path/file:function_name
Authorization /index.html /api/bin/icsextpgm.so:auth_url
なし
このディレクティブは、キャッシュ・リフレッシュを On または Off に設定するときに使用します。リフレッシュが On にされると、キャッシュのコンテンツが自動的にリフレッシュされます。リフレッシュが Off の場合には、キャッシュ・エージェントは呼び出されず、その設定はすべて無視されます。 キャッシュ・エージェントを別の方法で (例えば、Linux または UNIX システム で cron ジョブを使用することによって) 開始している場合には、 このディレクティブは Off に設定してください。
AutoCacheRefresh {on | off}
AutoCacheRefresh On
このディレクティブは、サーバーが単一のネットワーク・アドレスを listen するかどうかを指定するときに、 マルチホーム・システム上で使用します。値を On に設定すると、サーバーは、すべての ローカル IP アドレスにバインドせずに、Hostname ディレクティブに指定された IP アドレスにバインドします。
このディレクティブが指定されていないと、サーバーはデフォルトの Hostname とバインドします。
このディレクティブを変更した場合は、手動でサーバーを停止してから再始動しなければなりません。再始動しただけでは、サーバーは変更を行いません。 (Caching Proxy の開始および停止を参照してください。)
BindSpecific {on | off} [OutgoingSrcIp ip_addr | host_name]
BindSpecific Off
このディレクティブは、キャッシュ・デバイスのメディア内のブロックのサイズ (バイト単位) を指定します。デフォルトでは、その値は 8192 です。これがサポートされる唯一のサイズであるため、値は変更しないようにしてください。詳しくは、htcformat コマンドの解説セクションを参照してください。
BlockSize size
デフォルトでは、構成ファイルに BlockSize の設定はありません。(デフォルト値は 8192 です。)
このディレクティブは、プロキシー・キャッシュへのアクセスのログをサーバーに保管させる場所のパスとファイル名を指定するために使用します。このディレクティブは、サーバーがプロキシーとして実行されている場合にのみ有効です。詳しくは、CacheRefreshTime - キャッシュ・エージェントをいつ開始するかを指定するを参照してください。
プロキシー・キャッシュへの要求のログ記録を使用可能にするには、Caching ディレクティブを ON に設定し、CacheMemory および CacheAccessLog ディレクティブの値を設定する必要があります。オプションで、CacheDev ディレクティブを使用して 1 つまたは複数のキャッシュ・デバイスを定義できます。
CacheAccessLog の値は、絶対パスか ServerRoot への相対パスのいずれかとすることができます。(それぞれについて例を 1 つ示してあります。)
CacheAccessLog path/file
CacheAccessLog /absolute/path/logfile CacheAccessLog /logs/logfile
このディレクティブは、ガーベッジ・コレクション中にサーバーが使用するキャッシュ・アルゴリズムを指定するときに使用します。
CacheAlgorithm {bandwidth | responsetime | blend}
CacheAlgorithm bandwidth
このディレクティブは、生成されるキャッシュ・ファイル名が要求の着信 URL を基にするかどうかを指定するときに使用します。
このディレクティブを On に設定すると、キャッシュ・ファイル名は着信 URL を基にして生成されます。このディレクティブを Off に設定すると、着信 URL は、最初にすべての適用可能な名前変換プラグイン、MAP 規則、および PROXY 規則経由で渡され、生成されるキャッシュ・ファイル名はその結果の URL に基づきます。
CacheByIncomingUrl {on | off}
CacheByIncomingURL off
このディレクティブは、キャッシュされたファイルをサーバーが保持する期間を指定するために使用します。 ガーベッジ・コレクションの実行の際に、サーバーは、この期間を過ぎたキャッシュされたファイルを、そのファイルの有効期限とは無関係に削除します。 指定された時間より長くファイルをキャッシュするよう要求されると、サーバーは、ファイルを供給する前に、そのファイルが有効であることを確認するためにファイルの再検証を行います。
CacheClean time_specification
CacheClean 2 weeks
CacheClean 1 month
このディレクティブは、Expires または Last-Modified ヘッダーのいずれもサーバーにより 提供されていないファイルのデフォルトの有効期限時間を設定するときに使用します。URL テンプレートを指定し、その テンプレートと一致する URL を持つファイルの有効期限時間を指定します。 このディレクティブは、構成ファイル内で 複数回使用することができます。テンプレートごとに別々のディレクティブを組み込んでください。URL テンプレートにはプロトコルを指定しなければなりません。 時間の値は、月 (months)、週 (weeks)、日 (days)、および時間 (hours) を任意に組み合わせて指定します。
CacheDefaultExpiry URL_template expiration_time
CacheDefaultExpiry ftp:* 1 day CacheDefaultExpiry gopher:* 2 days CacheDefaultExpiry http:* 0 days
このディレクティブは、キャッシュ・ストレージを指定するときに使用します。ファイルまたはロー・ディスク区画のいずれかを指定できます。AIX プラットフォームでは、ロー論理ボリュームを指定できます。(メモリー・キャッシュを使用しない場合は、ロー・ディスク・キャッシュによって最良のパフォーマンスが得られます。)
キャッシュ・デバイスは、指定する前に準備する必要があることに注意してください。キャッシュ・デバイスの準備をするには、htcformat コマンドを使用して それをフォーマットします。詳しくは、htcformat コマンドを参照してください。
複数のキャッシュ・デバイスを指定できます。同じ CacheMemory 値と BlockSize 値に各デバイスが関連付けられます。しかし、プロキシー・サーバー・マシンで約 8 MB のメモリー・オーバーヘッドが、キャッシュ・デバイスごとに必要になります。大きいデバイスを少数使用するほうが、小さいデバイスを数多く使用するよりも効率的です。 最高の効率を得るには、1 つのディスク全体を 1 つの大きい区画として使用し、そのディスクには他のものを何も入れないでください。キャッシュ・ストレージの詳細については、ディスク・キャッシュのパフォーマンスの最適化を参照してください。
CacheDev {raw_disk_partition | file}
AIX: CacheDev /dev/rlv02
HP-UX: CacheDev /dev/rdsk/c1t15d0
Linux: CacheDev /opt/IBMWTE/filecache1
Solaris: CacheDev /dev/rdsk/clt3d0s0
Windows: CacheDev ¥¥.¥E:
なし
このディレクティブは、サーバーが有効期限の切れたキャッシュ・ファイルを戻すかどうかを指定するときに使用 します。サーバーに有効期限切れのファイルを戻させたい場合には、この値を Off に設定 します。クライアントが有効期限切れのファイルを要求している場合に、プロキシーがもっと最近のバージョンについて 起点サーバーをチェックするようにしたい場合は、デフォルト値の On を使用します。一般に、管理者は サーバーが有効期限切れのファイルを戻すことを希望しません。ただし例外として、サーバーを実際に点検しているとき など、戻されるコンテンツについては特に関心がない場合があります。
CacheExpiryCheck {on | off}
CacheExpiryCheck On
このディレクティブは、キャッシュに入れるファイルの最大サイズを指定するときに使用します。 このサイズより大きいファイルはキャッシュに格納されません。その値は、バイト (B)、キロバイト (K)、メガバイト (M)、またはギガバイト (G) で指定することができます。 この指定で数値と測定単位 (B、K、M、G) の間にスペースが入っていても問題ありません。
CacheFileSizeLimit maximum {B | K | M | G}
CacheFileSizeLimit 4000 K
このディレクティブは、特定の URL、またはテンプレートと一致するすべての URL に対する有効期限の計算に使用する値を指定する場合に使用します。
HTTP サーバーでは、ファイルの「最終変更」日時が提供されることはよくありますが、「有効期限」の日付は提供 されません。同様に、FTP ファイルには、「最終変更」タイム・スタンプはあっても、有効期限がない場合が あります。Caching Proxy は、最終変更日時に基づいてこれらのファイルの有効期限を計算します。サーバーは、最終変更日時を使用して、ファイルが変更されてからの時間の長さを判別し、それに CacheLastModifiedFactor ディレクティブの値を 乗算します。この計算結果は、ファイルの存続時間、またはファイルが失効するまでの期間です。
また、off または -1 を指定して、このディレクティブを Off にし、有効期限を計算しないようにすることもできます。プロキシー・サーバーは、CacheLastModifiedFactor ディレクティブを構成ファイル内に表示される順番で読み取ります。プロキシー・サーバーは、キャッシュ・ファイルに適用できる最初のディレクティブを使用します。
CacheLastModifiedFactor url factor
CacheLastModifiedFactor *://hosta/* off CacheLastModifiedFactor ftp://hostb/* 0.30 CacheLastModifiedFactor ftp://* 0.25 CacheLastModifiedFactor http://* 0.10 CacheLastModifiedFactor * 0.50
CacheLastModifiedFactor http://*/ 0.10 CacheLastModifiedFactor http://*.htm* 0.20 CacheLastModifiedFactor http://*.gif 1.00 CacheLastModifiedFactor http://*.jpg 1.00 CacheLastModifiedFactor http://*.jpeg 1.00 CacheLastModifiedFactor http://*.png 1.00 CacheLastModifiedFactor http://*.tar 1.00 CacheLastModifiedFactor http://*.zip 1.00 CacheLastModifiedFactor http:* 0.15 CacheLastModifiedFactor ftp:* 0.50 CacheLastModifiedFactor * 0.10
デフォルトの 0.14 では、1 週間前に変更されたファイルが 1 日で有効期限切れになります。
このディレクティブは、プロキシーと同じドメイン内のホストからの URL をキャッシュに入れるかどうかを指定するために使用します。内部の帯域幅は URL を迅速にロードするのに十分であるため、 イントラネット上のローカル・サイトでは、通常、キャッシュに入れる必要はありません。ローカル・サイトをキャッシュに入れないということは、検索に時間のかかる URL のためにキャッシュ・スペースを節約することになります。
CacheLocalDomain {on | off}
CacheLocalDomain on
バックエンド・サーバーが同一の URL で多種の言語をお客様に戻す能力がある場合は、 このディレクティブを使用して、同一の URL での異なる言語のキャッシングをサポートします。 このディレクティブを使用すると、Caching Proxy が要求中の言語プリファレンスを、 キャッシュされた応答の言語と比べて検証することができます。
CacheMatchLanguage が使用可能にされると、 Caching Proxy がキャッシュされたコンテンツを読み込む前に、 要求の Accept-Language ヘッダーにある言語プリファレンスを、 キャッシュされたコンテンツの言語と比べます。 Caching Proxy はまた、プリファレンスとの違いの大きさを比べます。 プリファレンスとの違いの大きさが指定された限度内の場合は、 キャッシュされたコピーを戻し、 そうでない場合は、プロキシーは要求をバックエンド・サーバーに転送し、 要求した言語で新しいコピーを取得します。
CacheMatchLanguage {on | off} lang-prefer-distance-limit special-id-for-all-lang
以下は、ディレクティブ、キャッシュ・オブジェクト、および要求の構成例です。
CacheMatchLanguage On 0.2
キャッシュ・オブジェクトが中国語 (簡体字、zh_cn) であり、要求が次のものの場合、
GET / HTTP/1.1 ... Accept-Language: en_US;q=1.0, zh_cn;q=0.7, ja;q=0.3 ....
この要求では、カスタマーは英語のページ (コードと品質は en_US/1.0) を要求し、 次に中国語 (簡体字) (コードと品質は zh_cn/0.7) を要求し、次に日本語 (コードと品質は ja/0.3) を 要求します。 キャッシュされるオブジェクトは中国語 (簡体字) です。 期待される最良の品質と一致する言語品質との間のプリファレンスの違いは、1.0 - 0.7 = 0.3 です。 CacheMatchLanguage ディレクティブで限度が 0.2 に設定されており、 0.3 は限度を超えているため、 プロキシーはキャッシュ中のオブジェクトを戻すのではなく、サーバーにその URL の新規コピーを求めます。
サーバーが言語を指定していないか、 応答を戻すときに Content-Language ヘッダーで special-id-for-all-lang を指定していない場合は、 次の要求を受けるときにプロキシーは言語プリファレンスの突き合わせをせず、 キャッシュ中のコピーを戻します。
CacheMatchLanguage off
このディレクティブは、ファイルがキャッシュ内に留まっていられる時間の最大値を定義する場合に使用します。キャッシュ・ファイルの存続時間は、更新のために起点による検査を受けることなしに、それをキャッシュから提供できる時間の長さを定義します。場合によっては、キャッシュ・ファイルの計算された存続時間の方がユーザーがファイルを保持したい時間より長い場合があります。ファイルの存続時間 (起点によって指定されたかまたは Caching Proxy によって計算された) は、CacheMaxExpiry ディレクティブによって指定された限界を超えることはできません。
このディレクティブは、構成ファイル内で複数回使用することができます。テンプレートごとに別々のディレクティブを組み込んでください。
CacheMaxExpiry URL lifetime
CacheMaxExpiry ftp:* 1 month CacheMaxExpiry http://www.santaclaus.np/* 2 days 12 hours
CacheMaxExpiry 1 month
このディレクティブは、キャッシュに関連付けるメモリーの量を指定するときに使用します。ディスク・キャッシュのパフォーマンスを最適にするためには、キャッシュ索引を含むキャッシュ・インフラストラクチャーのサポートには、キャッシュ・メモリーの値を最小 64 MB にすることをお勧めします。キャッシュ・サイズが増えると、キャッシュ索引が増加し、索引を保管するためにさらにキャッシュ・メモリーが必要になります。 64 MB のキャッシュ・メモリー値は、キャッシュ・インフラストラクチャーのサポートを提供し、約 6.4 GB までのディスク・キャッシュ用のキャッシュ索引を保管するために十分な大きさです。もっと大きなディスク・キャッシュの場合、キャッシュ・メモリーは、キャッシュ・サイズの 1% にすべきです。
メモリー・キャッシングを使用している場合には、キャッシュそれ自体とキャッシュ索引に必要なメモリー量の両方を含めるよう、このディレクティブを設定してください。
このディレクティブの最大推奨値は 1600 MB です。この制限は、Caching Proxy が、32 ビット・ アプリケーションとして最大 2 GB のメモリーを使用できることから決定されています。 キャッシュに必要なメモリーの量に、ルーチン処理で使用されるメモリーの量を加えた合計が 2 GB に近づくか、 またはそれを超えると、Caching Proxy は正常に稼働しません。
その量は、以下の単位のいずれかで指定できます。バイト (B)、キロバイト (K)、メガバイト (M)、およびギガバイト (G)。
CacheMemory amount {B | K | M | G}
CacheMemory 64 M
このディレクティブは、有効期限を上書きするファイルの URL を指定するときに使用します。一部のサイトでは、ファイルの存続時間の終了前に有効期限が切れるように設定されているので、サーバーはファイルをさらに頻繁に要求することが必要になります。CacheMinHold ディレクティブによって、有効期限切れのファイルは、それが再度要求されるまで、指定された時間の長さだけキャッシュに保持されます。このディレクティブは、複数回指定することができます。
CacheMinHold http://www.cachebusters.com/* 1 hour
なし
このディレクティブは、プロキシー・サーバーがリモート・サーバーからファイルを検索するかどうかを指定するときに使用します。デフォルト値 (Off) では、サーバーはリモート・サーバーからファイルを検索できます。On の値は、サーバーをスタンドアロン・キャッシュ・モードで稼働するように設定します。これは、サーバーがそのキャッシュにすでに保管されているファイルしか戻すことができないことを意味します。通常は、サーバーがこのモードで稼働するときは、CacheExpiryCheck ディレクティブも Off に設定します。
サーバーをスタンドアロン・キャッシュ・モードで実行するのは、サーバーをデモのために使用する場合に便利です。デモに使用したいファイルがすべてキャッシュに保管されていることがわかっていれば、ネットワーク接続は不要です。
CacheNoConnect {on | off}
CacheNoConnect Off
このディレクティブは、指定したテンプレートと一致する URL を持つファイルだけをキャッシュに入れるよう指定するときに使用します。このディレクティブは、構成ファイル内で複数回使用することができます。テンプレートごとに別々のディレクティブを組み込んでください。URL テンプレートにはプロトコルを指定しなければなりません。 このディレクティブに値を設定しなければ、NoCaching ディレクティブと一致しないすべての URL もキャッシュに入れることができます。CacheOnly と NoCaching のどちらのディレクティブも構成ファイルに組み込まない場合は、すべての URL をキャッシュに入れることができます。
CacheOnly url_pattern
CacheOnly http://realstuff/*
なし
このディレクティブは、照会要求に対する応答をキャッシュに入れる URL を指定するときに使用します。 PUBLIC url_pattern の値を使用すると、 起点サーバーに cache-control: public ヘッダーが含まれ、 その応答が別の方法でキャッシュ可能であれば、URL に疑問符の含まれる GET 要求に対する応答がキャッシュに入れられます。ALWAYS url_pattern の 値を指定すると、その応答が別の方法でキャッシュ可能である場合は、URL に疑問符を含む GET 要求に対する応答が キャッシュに入れられます。
このディレクティブは、複数回指定することができます。
CacheQueries {ALWAYS | PUBLIC} url_pattern
CacheQueries ALWAYS http://www.hosta.com/* CacheQueries PUBLIC http://www.hostb.com/*
なし
このディレクティブは、キャッシュ・ファイルが変更されているかどうかを判別するために起点サーバーが検査する時期を指定するときに使用します。
CacheClean ディレクティブは、このディレクティブと同じように見えますが、相違点があります。CacheRefreshInterval は、プロキシーがファイルの妥当性を使用前に検査するよう指定するだけであるのに対して、CacheClean ディレクティブでは、指定した期間の後にファイルがキャッシュから除去されます。
CacheRefreshInterval URL_pattern time_period
CacheRefreshInterval time_period
CacheRefreshInterval *.gif 8 hours CacheRefreshInterval 1 week
CacheRefreshInterval 2 weeks
このディレクティブは、キャッシュ・エージェントを開始する時期を指定するときに使用します。キャッシュ・エージェントは、特定の時間に開始することができます。
CacheRefreshTime HH:MM
CacheRefreshTime 03:00
CacheTimeMargin ディレクティブは、ファイルをキャッシュに入れておくために必要なそのファイルの最小存続時間を指定するときに使用します。
Caching Proxy は、ファイルごとに有効期限を計算します。ほとんどないことですが、ファイルが有効期限切れとなる前にそのファイルに対する別の要求が受け取られた場合に、Caching Proxy は、ファイルをキャッシュに入れておくにはそのファイルの存続時間が短すぎると見なします。デフォルトでは、Caching Proxy は存続時間が 10 分より短いファイルはキャッシュに入れません。キャッシュがその最大容量に近くなければ、このディレクティブは初期値のままにしておきます。キャッシュがその容量近くまで埋め込まれた場合には、この最小存続時間の値を大きくすることを考慮してください。
CacheTimeMargin minimum_lifetime
CacheTimeMargin 10 minutes
このディレクティブは、指定したテンプレートと一致する URL を持つ未使用のキャッシュ・ファイルをサーバーが保持する時間の最大長を指定するときに使用します。テンプレートと一致する URL を持つ未使用ファイルは、有効期限とは無関係に、指定の期間だけキャッシュに格納された後でサーバーにより削除されます。このディレクティブは、構成ファイル内で複数回使用することができます。 テンプレートごとに別々のディレクティブを組み込んでください。URL テンプレートにはプロトコルを指定しなければなりません。 時間の値は、月 (months)、週 (weeks)、日 (days)、および時間 (hours) を任意に組み合わせて指定します。
CacheUnused url_template time_length
CacheUnused ftp:* 3 weeks CacheUnused gopher:* 3 days 12 hours CacheUnused * 4 weeks
CacheUnused ftp:* 3 days CacheUnused gopher:* 12 hours CacheUnused http:* 2 days
このディレクティブは、ファイルのキャッシュを使用可能にするときに使用します。キャッシングが On になっていると、プロキシー・サーバーは、他のサーバーから検索したファイルをローカル・キャッシュに保管します。これで、プロキシー・サーバーは、同じファイルに対するこれ以降の要求があっても、他のサーバーから検索する必要なしに応答します。
Caching {on | off}
Caching On
このディレクティブは、ログを圧縮するまでの経過時間を指定するときに使用します。ログは、CompressAge に設定された値より古くなると圧縮されます。CompressAge を 0 に設定した場合は、ログが圧縮されることはありません。現在および直前の日のログは決して圧縮されません。
CompressAge number_of_days
CompressAge 1
このディレクティブは、ログの圧縮に使用される圧縮ユーティリティーを識別し、パラメーターをそのユーティリティーに渡すコマンドを作成するときに使用します。アーカイブ・ログのパスを組み込んでください。
圧縮ユーティリティーは、そのマシンのパスにリストされているディレクトリーにインストールしなければなりません。
CompressCommand command
CompressCommand tar -cf /logarchs/log%%DATE%%.tar %%LOGFILES%% ; gzip /logarchs/log%%DATE%%.tar CompressCommand tar -cf /logarchs/log%%DATE%%.tar %%LOGFILES%% ; compress /logarchs/log%%DATE%%.tar CompressCommand zip -q /logarchs/log%%DATE%%.zip %%LOGFILES%%
CompressCommand pkzip -q d:¥logarchs¥log%%DATE%%.tar %%LOGFILES%%
なし
このディレクティブは、ログの圧縮後、いつログを削除するかを指定する場合に使用します。 ログは、CompressDeleteAge の値に設定された日数より古くなると削除されます。CompressDeleteAge を 0 に設定するか、あるいは CompressAge ディレクティブに設定された値より低い場合には、ログは削除されません。
CompressDeleteAge number_of_days
CompressDeleteAge 7
圧縮したい HTTP 応答のコンテンツ・タイプを指定するには、 このディレクティブを使用します。
HTTP 応答を圧縮すると、ネットワーク負荷の軽減に役立ち、 プロキシー・サーバーのパフォーマンスも改善されます。 圧縮フィルター機能が有効になっている場合、 ブラウザーで HTTP 圧縮がサポートされていて、 HTTP 応答が現在のところ圧縮されていなければ、 Caching Proxy は HTTP 応答を圧縮し、圧縮したコンテンツをブラウザーに戻します。
圧縮フィルター機能を有効にするには、 次の 2 つのディレクティブを ibmproxy.conf ファイルに追加します。
CompressionFilterEnable /opt/ibm/edge/cp/lib/mod_z.sl CompressionFilterAddContentType type-1[,type-n]
CompressionFilterEnable /opt/ibm/edge/cp/lib/mod_z.so CompressionFilterAddContentType type-1[,type-n]
CompressionFilterEnable C:¥Progra~1¥IBM¥edge¥cp¥Bin¥mod_z.dll CompressionFilterAddContentType type-1[,type-n]
CompressionFilterEnable ディレクティブで参照された mod_z ライブラリーは、 zlib1.1.4 の動的バージョンです。
type-n 変数は、コンテンツ・タイプ・ヘッダーの有効な任意の値です。 たとえば、text/html または image/bmp がこれに相当します。
なし
このディレクティブは、バックエンド・サーバーからの、 またはプロキシー・サーバーのキャッシュからの、 HTTP 応答を圧縮するための圧縮フィルターを有効にする場合に、使用します。
このディレクティブの使用方法の例については、 CompressionFilterAddContentType - 圧縮したい HTTP 応答のコンテンツ・タイプを指定するを参照してください。
なし
このディレクティブは、追加の構成ファイルの名前および場所を指定する場合に使用します。特定の構成ファイル内で見つかったディレクティブは、現在の構成ファイルの後で処理されます。
なし
このディレクティブを使用して、 接続の管理に使用する接続スレッドの数を定義します。
ConnThreads number
ConnThreads 5
クライアント接続が終了した場合にも、Caching Proxy がキャッシュ・ファイルを作成し終わるために、要求されたファイルの うちのどれだけの部分を転送しなければならないかを指定するとき、このディレクティブを使用します。この変数の 有効な値は 0 から 100 までの範囲の整数です。
例えば、ContinueCaching 75 を指定すると、Caching Proxy がクライアント接続の終了を検出するまでにファイルの 75% 以上がすでに転送されていれば、Caching Proxy は、コンテンツ・サーバーからのファイルの転送を継続し、キャッシュ・ファイルを生成します。
ContinueCaching percentage
ContinueCaching 75
このディレクティブは、レーティング・サービス情報を含めて、コンテンツの URL をフィルターに掛けるために必要な情報をプロキシーに提供するときに使用します。このディレクティブは、複数回指定することができます。
DefinePicsRule "filter_name" {
DefinePicsRule "RSAC Example" {
このディレクティブを使用して、デフォルトの保護セットアップを、テンプレートと一致する要求に関連付けます。
DefProt request_template setup_name [FOR server_IP_address | host_name]
要求がこのテンプレートと一致しても、後続の Protect ディレクティブのテンプレートと一致しなければ、この要求の保護は活動化されません。Protect ディレクティブを DefProt とともに使用する方法の説明については、Protect - テンプレートと一致する要求の保護セットアップを活動化するを参照してください。
IP アドレス (例えば、FOR 240.146.167.72) を指定するか、あるいはホスト名 (例えば、FOR hostA.bcd.com) を指定することができます。
このパラメーターはオプションです。このパラメーターを指定しないと、サーバーは、要求を受信する IP アドレスや URL のホスト名に関係なく、このディレクティブを使用してすべての要求を処理します。
ワイルドカード文字をサーバーの IP アドレスとして指定することはできません。
DefProt /secret/* /server/protect/setup1.acc
DefProt /secret/* SECRET-PROT
DefProt { AuthType Basic ServerID restricted PasswdFile /docs/etc/WWW/restrict.password GroupFile /docs/etc/WWW/restrict.group GetMask authors PutMask authors }
DefProt /secret/* CustomerA-PROT 0.67.106.79 DefProt /secret/* CustomerB-PROT 0.83.100.45
DefProt /secret/* CustomerA-PROT hostA.bcd.com DefProt /secret/* CustomerB-PROT hostB.bcd.com
なし
このディレクティブは、キャッシュ・エージェントが宛先サーバーに要求を送信する間隔をあけるかどうかを指定するために使用します。要求間の遅延を指定すると、宛先サーバーの負荷だけでなく、プロキシー・マシンおよびユーザーのネットワーク・リンクの負荷も軽減されます。遅延を指定しない場合には、キャッシュ・エージェントは最高速度で稼働します。低速のインターネット接続の場合には、ネットワークの最大使用を達成するために、遅延期間は指定しないことを考慮してください。
DelayPeriod {on | off}
DelayPeriod On
このディレクティブは、キャッシュ・エージェントがホスト間のハイパーテキスト・リンクをたどるかどうかを指定するために使用します。キャッシュに格納された URL に他のサーバーへのリンクが含まれている場合、サーバーは、そのリンク を無視することもたどることもできます。DelveInto ディレクティブが never に設定されている場合は、このディレクティブは適用されません。
DelveAcrossHosts {on | off}
DelveAcrossHosts Off
このディレクティブは、キャッシュにロードするページの検索時にたどるリンク・レベルの数を指定するときに使用します。DelveInto ディレクティブが never に設定されている場合は、このディレクティブは適用されません。
DelveDepth number_of_levels
DelveDepth 2
このディレクティブは、キャッシュ・エージェントがキャッシュに入れられた URL からのリンクをたどってページをロードするかどうかを指定するときに使用します。
DelveInto {always | never | admin | topn}
DelveInto always
このディレクティブは、背景イメージをプロキシー・サーバーによって生成されたディレクトリー・リストに適用するのに使用します。ディレクトリー・リストは、プロキシー・サーバーが FTP サイトのブラウズに使用されたときに生成されます。
背景イメージの絶対パスを指定してください。イメージが別のサーバーにある場合は、背景イメージは完全な URL として指定しなければなりません。背景イメージが指定されていない場合は、プレーンな白い背景が使用されます。
DirBackgroundImage /path/file
DirBackgroundImage /images/corplogo.png DirBackgroundimage http://www.somehost.com/graphics/embossed.gif
なし
このディレクティブを使用して、1 KB より小さいファイルの正確なバイト・カウントをディレクトリー・リストに表示するかどうかを指定します。値が Off の場合は、ディレクトリー・リストでは、サイズが 1 KB 以下のファイルはすべて、サイズが 1 KB と表示されます。
DirShowBytes {on | off}
DirShowBytes Off
このディレクティブを使用して、ディレクトリー・リスト上のファイル名のソート時に大文字と小文字を区別するかどうかを指定します。
On の値は、ファイルのリスト中で大文字が小文字の前に置かれることを意味します。
DirShowCase {on | off}
DirShowCase On
このディレクティブは、ディレクトリー・リストに各ファイルが最後に変更された日付を含めるかどうかを指定するときに使用します。
DirShowDate {on | off}
DirShowDate On
このディレクティブを使用して、HTML ファイルの記述をディレクトリー・リストに表示するかどうかを指定します。 記述は、ファイルの HTML <title> タグから取得されます。
FTP ディレクトリー・リストの記述は、判別できる場合は MIME タイプを示しています。
DirShowDescription {on | off}
DirShowDescription On
このディレクティブを使用して、ディレクトリー中の隠しファイルをディレクトリー・リストに表示するかどうかを指定します。サーバーは、ピリオド (.) で始まる名前を持つすべてのファイルを隠しファイルと見なします。
DirShowHidden {on | off}
DirShowHidden On
このディレクティブは、サーバーがアイコンをディレクトリー・リストに組み込むかどうかを指定するときに使用します。アイコンを使用すれば、リスト内のファイルのコンテンツ・タイプをグラフィックで表示することができます。アイコンそのものは、AddBlankIcon、AddDirIcon、AddIcon、AddParentIcon、および AddUnknownIcon ディレクティブで定義されます。
DirShowIcons {on | off}
DirShowIcons On
このディレクティブを使用して、ディレクトリー・リストの記述フィールドに表示される文字の最大文字数を設定します。
DirShowMaxDescrLength number_of_characters
DirShowMaxDescrLength 25
このディレクティブを使用して、ディレクトリー・リストのファイル名に使用される文字の最大文字数を設定します。
DirShowMaxDescrLength number_of_characters
DirShowMaxLength 25
このディレクティブを使用して、ディレクトリー・リストのファイル名用に常に確保される最小の文字数を設定します。ディレクトリー内のファイル名は、この数字を超えても構いません。ただし、ファイル名は、DirShowMaxLength ディレクティブで指定した数字を超えてはなりません。
DirShowMinLength number_of_characters
DirShowMinLength 15
このディレクティブを使用して、ファイルのサイズをディレクトリー・リストに表示するかどうかを指定します。
DirShowSize {on | off}
DirShowSize On
このディレクティブは、サーバーが受け入れない HTTP メソッドを指定するときに使用します。サーバーが拒否するメソッドごとに、別個の Disable ディレクティブを入力してください。
デフォルト構成ファイルでは、GET、HEAD、OPTIONS、POST、および TRACE メソッド が使用可能であり、サポートされているその他すべての HTTP メソッドは使用不可です。現在使用可能になっているメソッドを使用不可にするには、そのメソッドを Enable ディレクティブから削除し、Disable ディレクティブに追加します。
Disable method
Disable PUT Disable DELETE Disable CONNECT
このディレクティブを使用して、どの環境変数を CGI プログラムに継承させないかを指定します (ただし、CGI 処理特有の CGI 環境変数は除きます)。
デフォルトでは、すべての環境変数が CGI プログラムによって継承されます。 このディレクティブは、個々の環境変数を継承から除外するときに使用します。
DisInheritEnv environment_variable
DisInheritEnv PATH DisInheritEnv LANG
この例では、PATH と LANG を除くすべての環境変数が CGI プログラムによって継承されます。
なし
このディレクティブは、サーバーが要求クライアントのホスト名を検索するかどうかを指定するときに使用します。
DNS-Lookup {on | off}
使用する値は、サーバーの働き方に関する以下のものに影響を与えます。
DNS-Lookup Off
このディレクティブは、サーバーがどの HTTP メソッドを受け入れるかを指定するときに使用します。
必要に応じていくつでも HTTP メソッドを使用可能にすることができます。サーバーが受け入れるメソッドごとに、別個の Enable ディレクティブを入力してください。
Enable method
特定の URL に Service ディレクティブがない場合は、Enable ディレクティブを使用して、任意の HTTP メソッドについてカスタマイズ済みプログラミングを行うことができます。このディレクティブに指定するプログラムは、そのメソッドの標準処理をオーバーライドします。
Enable method /path/fileDLL:function_name
Enable CONNECT メソッドのフォーマット および使用可能なオプションについては、 SSL トンネリングの構成を参照してください。
Enable GET Enable HEAD Enable POST Enable TRACE Enable OPTIONS
このディレクティブは、TCP NODELAY ソケット・オプションを使用可能にするために使用します。
EnableTcpNodelay ディレクティブは、 小さな IP パケット (SSL ハンドシェークまたは短い HTTP 応答など) が Caching Proxy と クライアントの間で送信される場合にパフォーマンスを高めます。 デフォルトでは、TCP NODELAY オプションはすべてのソケットで 使用可能にされています。
EnableTcpNodelay {All | HTTP | HTTPS | None}
EnableTcpNodelay All
このディレクティブを使用して、エラー・ステップ実行中にサーバーで呼び出したいカスタマイズ済みアプリケーション関数を指定します。このコードは、エラーが起こった場合に実行され、カスタマイズ済みエラー・ルーチンを提供します。
Error request_template /path/file:function_name
Error /index.html /ics/api/bin/icsext05.so:error_rtns
なし
このディレクティブを使用して、サーバーに内部エラーのログ記録に使用させたいファイルのパス名とファイル名を指定します。
サーバーが稼働中であれば、毎日真夜中に新規ログ・ファイルを開始します。それ以外の場合には、サーバーは、その日におけるサーバーの最初の始動時に新規ログ・ファイルを開始します。 ファイル作成時に、サーバーは、指定されたファイル名を使用し、日付接尾部を付加します。日付接尾部は、Mmmddyyyy という形式です。ここで、Mmm は月の最初の 3 文字を表し、dd は日を表し、また、yyyy は年を表します。
ErrorLog /path/logs_directory/file_name
このディレクティブを使用して、サーバーに特定のエラー条件が起こったときに、要求側クライアントに送信するファイルの名前を指定します。エラー・キーワードとエラー・メッセージ・ファイルを関連付ける ErrorPage ディレクティブは、構成ファイル ibmproxy.conf により提供されます。
エラー・メッセージをカスタマイズする場合は、ErrorPage ディレクティブを変更してエラー・キーワードを異なるファイルと関連付けたり、または提供されているエラー・メッセージ・ファイルを変更したりすることができます。例えば、メッセージを変更して問題の原因に関するより多くの情報を含め、それを解決する可能な方法を示すことができます。内部ネットワークの場合は、ユーザーの連絡先となる担当者を示すことができます。
ErrorPage ディレクティブは、構成ファイルの任意の場所に入れることができます。エラーが起こると、このファイルは構成ファイルに定義されたマッピング規則に従って処理されます。このため、送信するファイルは、Fail、Map、NameTrans、 Pass、Redirect、および Service の 各ディレクティブによって定義されたマッピング規則を介して到達可能な場所になければなりません。少なくとも、サーバーがエラー・メッセージ・ファイルを渡すことができるようにする Pass ディレクティブが必要です。
ErrorPage keyword /path/filename.html
ErrorPage scriptstart /HTML/errorpages/scriptstart.htmls
この例では、scriptstart 条件が生じると、サーバーは、/HTML/errorpages/ ディレクトリーで検出される scriptstart.htmls ファイルをクライアントに送信します。
以下の HTML テキストは、このファイルに含まれることがあるテキストの例です。
<HTML> <HEAD> <TITLE>Message for SCRIPTSTART condition</TITLE> </HEAD> <BODY> The CGI program could not be started. <P> <A HREF="mailto:admin@websvr.com">Notify the administrator</A> of this problem. </BODY> </HTML>
サーバーの構成ファイル内の上記のパスと一致するディレクティブが PASS /* /wwwhome/* であれば、このメッセージ・ファイルの絶対パスは /wwwhome/HTML/errorpages/scriptstart.htmls となります。
エラー条件はそれぞれキーワードによって識別されます。どのエラー・メッセージをカスタマイズするかを決めるには、まず、Caching Proxy で提供されたエラー・メッセージ・ファイルを調べます。これは、/HTML/errorpages の中にあります。エラー・ページには、エラー番号、デフォルト・メッセージ、原因の説明、および該当するリカバリー・アクションが含まれています。
次に、エラー・メッセージを変更するには、以下のいずれかを実行してください。
すべてのキーワードおよびデフォルトのエラー・メッセージ・ファイルは、ファイル ibmproxy.conf の ErrorPage ディレクティブ・セクションにリストされています。エラー・メッセージ・ファイルには、エラー・メッセージ番号、キーワード、デフォルト・メッセージ、説明、およびユーザー応答 (アクション) が含まれています。
ファイル ibmproxy.conf には、多数のデフォルトが組み込まれています。
ErrorPage ディレクティブをエラー条件に変更しないと、その条件に対するサーバーのデフォルトのエラー・ページが送信されます。
このディレクティブは、イベント・ログのパスとファイル名を指定するときに使用します。イベント・ログは、キャッシュ自体に関する通知メッセージを取り込みます。
サーバーが稼働中であれば、毎日真夜中に新規ログ・ファイルを開始します。それ以外の場合には、サーバーは、その日におけるサーバーの最初の始動時に新規ログ・ファイルを開始します。 ファイル作成時に、サーバーは、指定されたファイル名を使用し、日付接尾部を付加します。日付接尾部は、Mmmddyyyy という形式です。ここで、Mmm は月の最初の 3 文字を表し、dd は日を表し、また、yyyy は年を表します。
EventLog /path/logs_directory/file_name
このディレクティブを使用して、CGI プログラムの実行によって受け入れ、応答する要求のためのテンプレートを指定します。要求は、Exec ディレクティブのテンプレートに一致すると、後続のディレクティブの要求テンプレートとは比較されません。
Exec request_template program_path [Server_IP_address | host_name]
request_template と program_path の両方で、ワイルドカードとしてアスタリスク (*) を使用する必要があります。request_template のワイルドカードと一致する要求の一部は、CGI プログラムが入っているファイルの名前で始まっていなくてはなりません。
要求には、PATH_INFO 環境変数に入れて CGI プログラムに渡す追加データが含まれていることもあります。追加データは、要求にある CGI プログラム・ファイル名の後の最初のスラッシュ (/) の後に続きます。このデータは、CGI の指定に従って渡されます。
Exec ディレクティブは再帰的ディレクティブで、すべてのサブディレクトリーに適用されます。cgi-bin および admin-bin のそれぞれのディレクトリーごとに、別々の Exec ディレクティブを使用する必要はありません。
IP アドレス (例えば、240.146.167.72) またはホスト名 (例えば、hostA.bcd.com) を指定することができます。
このパラメーターはオプションです。このパラメーターを指定しない場合、サーバーは、要求を受信する IP アドレスや URL のホスト名に関係なく、このディレクティブを使用してすべての要求を処理します。
サーバー IP アドレスの指定にワイルドカード文字を使用することはできません。
以下の例において、サーバーが /idd/depts/plan/c92 という要求を受信すると、/depts/bin/plan.exe に入っている CGI プログラムを、c92 を入力としてそのプログラムに渡して実行します。
以下の例では、オプションの IP アドレス・パラメーターを使用しています。サーバーが /cgi-bin/ で始まる要求を受信した場合には、その要求が入ってきたネットワーク接続の IP アドレスを基にして、別のディレクトリーからの要求にサービスします。130.146.167.72 に入ってくる要求では、サーバーは /CGI-BIN/customerA ディレクトリーを使用します。 アドレス 0.83.100.45 の接続に入ってくる要求の場合には、サーバーは /CGI-BIN/customerB ディレクトリーを使用します。
Exec /cgi-bin/* /CGI-BIN/customerA/* 130.129.167.72 Exec /cgi-bin/* /CGI-BIN/customerB/* 0.83.100.45
以下の例では、オプションのホスト名パラメーターを使用しています。サーバーは、/cgi-bin で始まる要求を受信すると、URL 内のホスト名に基づいて、別のディレクトリーからの要求を処理します。 hostA.bcd.com に送信された要求に対して、サーバーは /CGI-BIN/customerA ディレクトリーを使用します。 hostB.bcd.com に送信された要求に対して、サーバーは /CGI-BIN/customerB ディレクトリーを使用します。
Exec /cgi-bin/* /CGI-BIN/customerA/* hostA.bcd.com Exec /cgi-bin/* /CGI-BIN/customerB/* hostB.bcd.com
Exec /cgi-bin/* /opt/ibm/edge/cp/server_root/cgi-bin/* Exec /admin-bin/* /opt/ibm/edge/cp/server_root/admin-bin/*
Exec server_root/cgi-bin/* Exec server_root/admin-bin/* Exec server_root/DOCS/admin-bin/*
このディレクティブを使用して、キャッシュのコンテンツをダンプ・ファイルにエクスポートします。再始動時にメモリー・キャッシュが破損したり、同じキャッシュを複数のプロキシーに配置する場合などに役立つ機能です。
ExportCacheImageTo export_file_name
なし
これは、リバース・プロキシー構成にのみ適用されます。
このディレクティブを使用して、動的リソースをキャッシングできる IBM WebSphere Application Server (Caching Proxy アダプター・モジュールで構成される) を 認識するための Caching Proxy を構成します。Caching Proxy では、アプリケーション・サーバー の動的キャッシュにも保管されている JSP の結果のコピーが保管されます。 Caching Proxy は、IBM WebSphere Application Server からそのグループ ID が ExternalCacheManager 項目と一致する内容だけをキャッシュします。
この機能を使用するために、Caching Proxy 構成ファイルに Service ディレクティブを追加する必要があることにも注意してください。 アプリケーション・ サーバーでも、追加の構成ステップが必要です。詳しくは、動的に生成されたコンテンツのキャッシングを 参照してください。
ExternalCacheManager External_Cache_Manager_ID Maximum_Expiry_Time
以下の項目は、www.xyz.com ドメイン内にある、そのリソースが 20 秒またはそれ以前に有効期限切れとなる外部キャッシュ・マネージャー (IBM WebSphere Application Server) を定義します。
ExternalCacheManager IBM-CP-XYZ-1 20 seconds
なし
このディレクティブは、サーバーが処理する必要のない要求のためのテンプレートを指定するときに使用します。要求は、Fail ディレクティブのテンプレートに一致すると、後続のディレクティブの要求テンプレートとは比較されません。
Fail request_template [Server_IP_address | host_name]
テンプレートではアスタリスクをワイルドカードとして使用できます。スラッシュ (/) の直後の波形記号 (~) は明示的に一致しなければならず、このためにワイルドカードを使用することはできません。
IP アドレス (例えば、240.146.167.72) またはホスト名 (例えば、hostA.bcd.com) を指定することができます。
このパラメーターはオプションです。このパラメーターを指定しない場合、サーバーは、要求を受信する IP アドレスや URL のホスト名に関係なく、このディレクティブを使用してすべての要求を処理します。
ワイルドカード文字をサーバーの IP アドレスとして指定することはできません。
以下の例で、サーバーは /usr/local/private/ で始まるすべての要求を拒否します。
Fail /usr/local/private/*
以下の例では、オプションの IP アドレス・パラメーターを使用しています。 サーバーは、要求が IP アドレス 240.146.167.72 のネットワーク接続で入ってきている場合には、/customerB/ で始まるすべての要求を拒否します。サーバーは、要求が IP アドレス 0.83.100.45 のネットワーク接続で入ってきている場合には、/customerA/ で始まるすべての要求を拒否します。
Fail /customerB/* 240.146.167.72 Fail /customerA/* 0.83.100.45
以下の例では、オプションのホスト名パラメーターを使用しています。 hostA.bcd.com に要求が出された場合は、サーバーは、/customerB/ で始まるすべての要求を拒否します。hostB.bcd.com に要求が出された場合は、サーバーは、 /customerA/ で始まるすべての要求を拒否します。
Fail /customerB/* hostA.bcd.com Fail /customerA/* hostB.bcd.com
なし
このディレクティブを使用して、SSL 接続における SSLV3 および TLS プロトコルの FIPS 承認済み暗号を使用可能にします。 このディレクティブが使用可能になると、サポートされる SSLV3 用暗号仕様 (V3CipherSpecs ディレクティブ) のリストは無視されます。また、 許可された TLS 暗号仕様は、352F0AFF09FE に設定され、SSLV3 暗号仕様は FFFE に設定されます。
FIPSEnable {on | off}
FIPSEnable off
SOCKS 構成ファイルを使用して、確立する接続のタイプを決定するようプロキシーに指示する とき、このディレクティブを使用します。
flexibleSocks {on | off}
flexibleSocks on
このディレクティブは、FTP サーバーがディレクトリーのウェルカム・メッセージまたは記述メッセージを生成できるようにする場合に使用します。このメッセージは、オプションで FTP リストの一部として表示することができます。FTPDirInfo ディレクティブを使用すると、メッセージを表示する場所が制御できるようになります。
FTPDirInfo {top | bottom | off}
FTPDirInfo top
プロキシー・サーバーがプロキシー・チェーンの一部である場合は、このサーバーが FTP 要求のために接続する必要がある別のプロキシーの名前を指定するために、このディレクティブを使用してください。 末尾のスラッシュ文字 (/) を含めた完全な URL を指定しなければなりません。オプショナルのドメイン名またはテンプレートの使用については、no_proxy - ドメインに直接接続するためのテンプレートを指定するを参照してください。
これは、フォワード・プロキシー構成にのみ適用されます。
ftp_proxy full_URL [domain_name_or_template]
ftp_proxy http:// outer.proxy.server/
なし
このディレクティブは、FTP URL にあるパス情報が、ログイン・ユーザーの作業ディレクトリーと相対的と解釈するか、あるいはルート・ディレクトリーと相対的と解釈するかを指定するときに使用します。
FTPUrlPath {relative | absolute}
FTPUrlPath ディレクティブを absolute に設定した場合は、ログイン・ユーザーの FTP 作業ディレクトリーを FTP URL パスに含める必要があります。FTPUrlPath Relative が指定されている場合は、ログイン・ユーザーの FTP 作業ディレクトリーは FTP URL から省略されていなければなりません。例えば、ログイン・ユーザーのための作業ディレクトリー /export/home/user1 に含まれているファイル test1.html にアクセスするには、FTPUrlPath ディレクティブの設定によって異なりますが、以下のような URL パスが必要です。
なし
このディレクティブは、ガーベッジ・コレクションが使用されるかどうかを指定するときに使用します。キャッシングが使用可能になっている場合に、サーバーは、ガーベッジ・コレクション・プロセスを使用して、キャッシュに格納してはならないファイルを削除します。ファイルは、有効期限および他の Proxy ディレクティブ値に基づいて削除されます。一般に、キャッシングが使用可能になっていれば、ガーベッジ・コレクションが使用されます。ガーベッジ・コレクションが使用されない場合は、プロキシー・キャッシュは効率的に使用されません。
Gc {on | off}
Gc On
このディレクティブは、サーバーをガーベッジ・コレクションに使用したいカスタマイズ済みアプリケーションを指定するときに使用します。
GCAdvisor /path/file:function_name
GCAdvisor /api/bin/customadvise.so:gcadv
このディレクティブは、ガーベッジ・コレクションのトリガーとなるために埋め込まれている必要がある全キャッシュ容量のパーセンテージを指定するときに使用します。このパーセンテージは、最高水準点 と呼ばれます。最高水準点は、全キャッシュ容量に対するパーセンテージとして指定します。ガーベッジ・コレクションは、 最低水準点に達するまで継続されます -- この設定については、GcLowWater - ガーベッジ・コレクションをいつ終了するかを指定するを参照してください。 最高水準点のパーセンテージは、50 と 95 間で設定できます。
GcHighWater percentage
GcHighWater 90
このディレクティブは、ガーベッジ・コレクションの終了のトリガーとなる全キャッシュ容量のパーセンテージを指定するときに使用します。このパーセンテージは、最低水準点 として知られています。最低水準点は、全キャッシュ容量に対するパーセンテージとして指定します。値は、最高水準点に設定した値より低い値に設定しなければなりません。最高水準点の設定については、GcHighWater - ガーベッジ・コレクションをいつ開始するかを指定するを参照してください。
GcLowWater percentage
GcLowWater 60
プロキシー・サーバーがプロキシー・チェーンの一部である場合は、このサーバーが Gopher 要求のために接続する必要がある別のプロキシーの名前を指定するために、このディレクティブを使用してください。 末尾のスラッシュ (/) を含めた完全な URL を指定しなければなりません。 オプショナルのドメイン名またはテンプレートの使用については、no_proxy - ドメインに直接接続するためのテンプレートを指定するを参照してください。
これは、フォワード・プロキシー構成にのみ適用されます。
gopher_proxy full_URL[domain_name_or_template]
gopher_proxy http://outer.proxy.server/
なし
このディレクティブは、サーバーがファイルにアクセスする前に変更する先のグループ名または番号を指定するときに使用します。
このディレクティブを変更した場合は、手動でサーバーを停止してから再始動しなければ、変更が有効になりません。サーバーを再始動しただけでは、変更は有効になりません。(Caching Proxy の開始および停止を参照してください。)
GroupId { group_name | group_number}
AIX: GroupId nobody
HP-UX: GroupId other
Linux:
Solaris: GroupId nobody
このディレクティブは、HTTP ヘッダーに戻されるプロキシー・サーバーの名前を指定するときに使用します。
HeaderServerName name
なし
このディレクティブは、ファイル要求からクライアントに戻されるドメイン・ネームまたは IP アドレスを指定する場合に使用します。ドメイン・ネームを指定する場合、ドメイン・ネーム・サーバーは名前を IP アドレスに変換できなければなりません。IP アドレスを指定する場合、ドメイン・ネーム・サーバーは必要なく、またアクセスもされません。
Hostname {name | IP address}
デフォルトでは、このディレクティブは初期構成ファイルには指定されません。構成ファイルにこのディレクティブを指定しないと、値はデフォルトによってユーザーのドメイン・ネーム・サーバーに定義されたホスト名となります。
プロキシー・サーバーがプロキシー・チェーンの一部である場合は、このサーバーが HTTP 要求のために接続する必要がある別のプロキシーの名前を指定するために、このディレクティブを使用してください。 末尾のスラッシュ (/) を含めた完全な URL を指定しなければなりません。 オプショナルのドメイン名またはテンプレートの使用については、no_proxy - ドメインに直接接続するためのテンプレートを指定するを参照してください。
http_proxy full_URL[domain_name_or_template]
http://outer.proxy.server/
なし
このディレクティブは、Caching Proxy が URL のためのセキュアでないホーム・ページを検索し、その中でラベルを見つけようとするかどうかを指定するときに使用します。ラベルが見つかると、それらはセキュア要求に適用されます。例えば、https://www.ibm.com/ を要求した場合に、Caching Proxy は http://www.ibm.com/ からラベルを検索し、見つかったラベルを使用して https://www.ibm.com/ をフィルターに掛けます。
HTTPSCheckRoot を Off に設定した場合には、Caching Proxy はセキュアでないホーム・ページと、その中のラベルを検索しません。
HTTPSCheckRoot {on | off}
HTTPSCheckRoot on
このサブディレクティブは、ICP 照会の送信および受信に使用する IP アドレスを指定するために使用します。これは、<MODULEBEGIN> ICP ディレクティブと <MODULEEND> ディレクティブの間に入れる必要があります。
ICP_Address IP_address
デフォルトでは、このディレクティブは初期構成ファイルには指定されません。構成ファイルにこのディレクティブを指定しないと、デフォルトはすべてのインターフェースで ICP 照会を受け入れおよび送信する値になります。
このサブディレクティブは、ICP 照会を listen するために作成されるスレッド数を指定するために使用します。これは、<MODULEBEGIN> ICP ディレクティブと <MODULEEND> ディレクティブの間に入れる必要があります。
ICP_MaxThreads number_of_threads
ICP_MaxThreads 5
プロキシー・サーバーが ICP クラスターの一部である場合に、このサブディレクティブは ICP ピアを指定するために使用します。これは、<MODULEBEGIN> ICP ディレクティブと <MODULEEND> ディレクティブの間に入れる必要があります。
ICP クラスターに新しいピアを追加する場合には、既存のすべてのピアの構成ファイルに ICP ピア情報を追加する必要が あります。それぞれのピアに 1 行を使用してください。ピア・リストには、現行のホストも含めることができます。 ICP の初期化時には、現行のホスト項目は無視されます。これにより、構成ファイルを編集して現行のホストを 除去しなくても、他のピア・マシンにコピーできる単一の構成ファイルを持つことができます。
ICP_Peer hostname http_port icp_port
以下の行は、プロキシー・ポートが 80 で ICP ポートが 3128 のホスト abc.xcompany.com をピアとして追加します。
ICP_Peer abc.xcompany.com 80 3128
なし
このサブディレクティブは、ICP サーバーが ICP 照会を listen するポート番号を指定するために使用します。これは、<MODULEBEGIN> ICP ディレクティブと <MODULEEND> ディレクティブの間に入れる必要があります。
ICP_Port port_number
ICP_Port 3128
このサブディレクティブは、Caching Proxy が ICP 照会に対する応答を待機する最長時間を指定するために使用します。この時間はミリ秒で指定します。 これは、<MODULEBEGIN> ICP ディレクティブと <MODULEEND> ディレクティブの間に入れる必要があります。
ICP_Timeout timeout_in_milliseconds
ICP_Timeout 2000
このディレクティブは、キャッシュ・エージェントがロードしない URL を指定するときに使用します。このディレクティブは、キャッシュ・エージェントが、キャッシュに格納されている URL からのリンクをたどってページをロードするときに便利です。IgnoreURL ディレクティブを複数回使用して、異なる URL または URL マスクを指定することができます。このディレクティブの値には、マスクに適用するワイルドカードとしてアスタリスク (*) を含めることができます。
IgnoreURL URL
IgnoreURL http://www.yahoo.com/ IgnoreURL http://*.ibm.com/*
IgnoreURL */cgi-bin/*
このディレクティブは、ファイル・システム、CGI プログラム、またはその両方から提供されたファイルについて、サーバー側インクルード処理を実行したいかどうかを指定するときに使用します。サーバー側インクルード処理は、コンテンツ・タイプが ext/x-ssi-html のファイルに対して行われます。オプションで、コンテンツ・タイプが text/html のファイルについてもサーバー側インクルード処理が実行されるように指定することができます。コンテンツ・タイプの詳細については、AddType - 特定の接尾部を持つファイルのデータ・タイプを指定するを参照してください。
サーバー側インクルード処理を使用すれば、戻されているファイルに情報を動的に挿入することができます。このような 情報には、日付、ファイルのサイズ、ファイルの最終変更日、CGI またはサーバー側インクルード環境変数、および テキスト・ファイルを含めることができます。サーバー側インクルード処理は、送信元がローカルであるファイルについてのみ 実行されます。Caching Proxy は、プロキシーまたはキャッシュ・オブジェクトに対してはサーバー側インクルード処理を 実行しません。
サーバー側インクルードを使用すると、サーバーは、特殊コマンドが使用されるつど、それらのコマンドをファイルの中から探し出します。このため、サーバーのパフォーマンスに影響が出てクライアントに対する応答時間が遅くなることがあります。
imbeds {on | off | files | cgi | noexec} {SSIOnly | html}
サーバーは、検索した各ファイルのコンテンツ・タイプと、処理した各 CGI プログラムの出力をチェックします。
通常、サーバー側インクルード処理は、text/x-ssi/html のコンテンツ・タイプを持つファイルに対してのみ行われます。ただし、text/html のコンテンツ・タイプを持つファイルをサーバー側インクルード処理するように指定することができます。
各接尾部には、正しいコンテンツ・タイプで AddType ディレクティブを定義する必要があります。.htm や .html 以外の接尾部を使用する場合は、AddType ディレクティブが text/x-ssi/html のコンテンツ・タイプで定義されていることを確認してください。
imbeds on SSIOnly
このディレクティブを使用して、キャッシュのコンテンツをダンプ・ファイルからインポートします。再始動時にメモリー・キャッシュが破損したり、同じキャッシュを複数のプロキシーに配置する場合などに役立つ機能です。
ImportCacheImageFrom import_file_name
なし
このディレクティブを使用して、どの環境変数を CGI プログラムに継承させるかを指定します (ただし、CGI 処理特有の CGI 環境変数は除きます)。
InheritEnv ディレクティブを含めないと、すべての環境変数が CGI プログラムによって継承されます。InheritEnv ディレクティブを含めると、InheritEnv ディレクティブに指定された環境変数だけが、CGI 特有の環境変数と一緒に継承されます。 このディレクティブを使用すると、継承した変数の値をオプションで初期化することができます。
InheritEnv environment_variable
InheritEnv PATH InheritEnv LANG=ENUS
この例では、PATH および LANG 環境変数だけが CGI プログラムによって継承され、LANG 環境変数は ENUS の値で初期化されます。
なし。デフォルトでは、すべての環境変数が CGI プログラムによって継承されます。
このディレクティブを使用して、クライアントがサーバーに接続した後に要求を送信できる時間を設定します。まずクライアントはサーバーに接続し、次に要求を送信します。このディレクティブによって指定された時間内にクライアントが要求を送信しなければ、サーバーは接続をクローズします。時間の値は、時間 (hours)、分 (minutes または mins)、および秒 (seconds または secs) を任意に組み合わせて指定します。
InputTimeout time
InputTimeout 3 mins 30 secs
InputTimeout 2 minutes
このディレクティブは JunctionRewrite プラグインのデフォルトのアクションをオーバーライドし、 プロキシーが HTML ページ中の特定の URL リンクを訂正することを可能にしています。 このディレクティブは JunctionRewrite ディレクティブと組み合わせて使用されます。
これは、リバース・プロキシー構成にのみ適用されます。
JunctionReplaceUrlPrefix ディレクティブは、 JunctionRewrite プラグインが URL の先頭に接頭部を挿入するのではなく、 url_pattern_1 か ら url_pattern_2 へと URL を置き換えるように指示します。
JunctionReplaceUrlPrefix url_pattern_1 url_pattern_2
JunctionReplaceUrlPrefix /server1.internaldomain.com/* /server1/*
この例では、URL が /server1.internaldomain.com/notes.nsf であるとし、 接頭部は /server1 であるとします。 URL を /server1/server1.internaldomain.com/notes.nsf に再書き込みす るために接頭部を挿入するのではなく、 JunctionRewrite プラグインは URL を /server1/notes.nsf に変更します。
なし
このディレクティブにより、Caching Proxy 内のジャンクション再書き込みルーチンは、発信元サーバーからの応答を再書き込みして、ジャンクションが使用された場合に、サーバーの相対 URL が適切な発信元サーバーにマップされるようにします。
これは、リバース・プロキシー構成にのみ適用されます。
UseCookie オプションを使用しないで「JunctionRewrite on」を設定した場合は、 ジャンクション再書き込みプラグインも使用可能にする必要があります。ジャンクションは、プロキシー・マッピング・ルールによって定義されます。
JunctionRewrite に関する追加情報については、JunctionRewrite に代わる UseCookieおよびJunctionRewrite 機能を拡張する Transmogrifier プラグインのサンプルを参照してください。
JunctionRewrite {on | on UseCookie | off}
JunctionRewrite off
このディレクティブは、Cookie 名が一致する際に、プロキシーが Set-Cookie ヘッダーのパス・オプションを 再書き込みすることを可能にします。 応答がジャンクションを必要としており、ジャンクションの接頭部が定義されている場合は、 各パスの先頭に接頭部が挿入されます。 このディレクティブは JunctionRewrite プラグインと併せて使用でき、 また RewriteSetCookieDomain ディレクティブと併せて使用できます。
これは、リバース・プロキシー構成にのみ適用されます。
JunctionRewriteSetCookiePath cookie-name1 cookie-name2...
なし
このディレクティブは JunctionRewrite プラグインのデフォルトのアクションをオーバーライドし、 プロキシーが URL パターンに既に一致している場合は URL の再書き込みをス キップさせます。 JunctionRewrite プラグインと併せて使用し、 HTML ページ内の一部の URL リンクを訂正する方法を提供します。 通常、このディレクティブは既に接頭部を含む URL をスキップするために使用されます。
これは、リバース・プロキシー構成にのみ適用されます。
JunctionSkipUrlPrefix url_pattern
JunctionSkipUrlPrefix /server1/*
この例では、URL が /server1/notes.nsf であるとし、 ジャンクション・接頭部は /server1/ であるとします。 URL を /server1/server1/notes.nsf に再書き込みする代わりに、 JunctionRewrite プラグインは URL の再書き込みをスキップし、 URL は /server1/notes.nsf のまま変更されません。
なし
このディレクティブを使用して、キャッシュ・オブジェクトが再検証されている間、 バックエンド・サーバーが要求であふれてしまうのを防ぐ助力をします。
キャッシュ・オブジェクトがバックエンド・サーバー上のコンテンツで再検証されている時、 同じリソースに対する要求は、バックエンド・サーバーに代理要求されます。 同じ要求のあふれが、バックエンド・サーバーをダウンさせる原因になることもあります。 このディレクティブを使用可能にすると、このような状態が発生するのを防ぐ助けとすることが可能です。 そのディレクティブが使用可能になると、リソースがプロキシーで更新済みである場合、 有効期限が切れた、または失効したリソースのコピーは戻されます。
KeepExpired {on | off}
KeepExpired off
このディレクティブは、サーバーが SSL 要求に使用する鍵リング・データベースへのファイル・パスを指定するときに使用します。鍵リング・ファイルは iKeyman 鍵管理ユーティリティーを介して生成されます。
KeyRing filename
Windows: KeyRing c:¥Program Files¥IBM¥edge¥cp¥¥key.kdb
Linux および UNIX: KeyRing /etc/key.kdb
なし
このディレクティブは、鍵リング・データベースのパスワード・ファイルへのファイル・パスを指定するときに使用します。パスワード・ファイルは、鍵リング・データベース・ファイルの構築時に、iKeyman 鍵管理ユーティリティーを介して生成されます。
KeyRingStash file_path
Windows: KeyRingStash c:¥Program Files¥IBM¥edge¥cp¥key.sth
Linux および UNIX: KeyRingStash /etc/key.sth
なし
このディレクティブは、PUT 要求または POST 要求の最大ボディ・サイズを制御するときに使用します。 LimitRequest ディレクティブは、アタックからプロキシーを保護するために使用されます。
その値は、キロバイト (K)、メガバイト (M)、またはギガバイト (G) で指定することができます。
LimitRequestBody max_body_size {K | M | G}
LimitRequestBody 10 M
このディレクティブを使用して、クライアント要求に送信できるヘッダーの最大数を指定します。LimitRequest ディレクティブは、アタックからプロキシーを保護するために使用されます。
LimitRequestFields number_headers
LimitRequestFields 32
このディレクティブを使用して、要求行の最大長および各要求内のヘッダーの最大長を指定します。LimitRequest ディレクティブは、アタックからプロキシーを保護するために使用されます。
その値は、バイト (B)、キロバイト (K) で指定することができます。
LimitRequestFieldSize max_hdr_length {B | K}
LimitRequestFieldSize 4096 B
このディレクティブは、サーバーが接続拒否を示すメッセージをクライアントに送信する前に持つ listen バックログ・クライアント接続の数を指定するときに使用します。この数は、サーバーが数秒で処理できる要求の数によって異なります。これは、クライアントがタイムアウトとなり、接続を打ち切るまでにサーバーが処理できる数より高い値にしないようにしてください。
ListenBacklog number_of_requests
ListenBacklog 128
このディレクティブは、キャッシュ・エージェントがインライン・イメージを検索するかどうかを指定するために使用します。 LoadInlineImages を On に設定すると、キャッシュに格納中のページに組み込まれているイメージもキャッシュに入れられます。Off に設定した場合には、組み込みイメージはキャッシュに入れられません。
LoadInlineImages {on | off}
LoadInlineImages on
このディレクティブは、前夜のキャッシュ・アクセス・ログにアクセスし、要求された回数の最も多い URL をロードするようキャッシュ・エージェントに指示するときに使用します。
LoadTopCached ディレクティブに値を設定する場合には、Caching ディレクティブを On に設定し、CacheAccessLog ディレクティブの値を設定する必要があります。
LoadTopCached number_of_pages
LoadTopCached 100
このディレクティブは、キャッシュ・エージェントがキャッシュにロードする URL を指定するために使用します。 構成ファイルには複数の LoadURL ディレクティブを組み込むことができますが、ワイルドカードは使用できません。
LoadURL url
LoadURL http://www.ibm.com/
なし
このディレクティブは、ログ・ステップ中にサーバーが呼び出すカスタマイズ済みアプリケーション関数を指定するときに使用します。このコードによって、接続がクローズされた後のログ記録およびその他の処理が提供されます。
Log request_template /path/file:function_name
Log /index.html /api/bin/icsextpgm.so:log_url
なし
このディレクティブは、アーカイブ・ルーチンの動作を指定するときに使用します。このディレクティブは、グローバル設定を持つすべてのログに影響します。これは、ログが圧縮されるか、パージされるか、あるいはログに何も実行されないかを指定します。
Compress を指定した場合は、CompressAge および CompressDeleteAge ディレクティブを使用して、ログがいつ圧縮または削除されるかを指定します。使用するコマンドとそのパラメーターの指定には、CompressCommand ディレクティブを使用します。
Purge を指定した場合は、PurgeAge および PurgeSize ディレクティブを使用して、ログがいつパージされるかを指定します。
LogArchive {Compress | Purge | none}
LogArchive Purge
このディレクティブは、アクセス・ログ・ファイルの形式を指定するときに使用します。
LogFileFormat {common | combined}
デフォルトでは、ログは、NCSA 共通ログ形式で表示されます。代わりに NCSA 結合ログ形式でログを表示するには、combined を指定します。 結合形式では、参照 URL (Referring URL)、ユーザー・エージェント (User Agent)、および Cookie (要求の中にある場合) のフィールドが追加されます。
LogFileFormat common
Windows システム専用です。コマンド行からプロキシーを実行するときには、このディレクティブを使用して、アクセス・ログに出力します。サーバーのパフォーマンスを最適化するために、このディレクティブはデフォルトで Off (使用不可) に設定されています。
LogToGUI {on | off}
LogToGUI off
Linux および UNIX システム専用です。このディレクティブは、サーバーが、アクセス要求とエラーをアクセスおよびエラー・ログ・ファイルだけでなく、システム・ログにも記録するかどうかを指定するときに使用します。
LogToSyslog {on | off}
システム・ログ・ファイルがサーバー上に存在していなければ、そのファイルにエラー・ログ情報を書き込むように指定してはなりません。アクセス情報またはエラー情報、あるいはその両方をログに記録する選択をすることができます。
エラー情報のみをシステム・ログに送るには、/etc/syslog.conf ファイルに以下の行を追加してください。
user.err syslog_output_file_for_error_information
アクセス情報のみをシステム・ログに送るには、/etc/syslog.conf ファイルに以下の行を追加してください。
user.info syslog_info_file_for_access_information
エラー情報とアクセス情報の両方をシステム・ログに送るには、/etc/syslog.conf ファイルに上記の両方の行を追加してください。
syslog_output_file および syslog_info_file は、以下の形式で指定します。
システム・ログ・ファイルを作成した後に、以下のコマンドを使用してそれを再始動できます。
kill -HUP 'cat /etc/syslog.pid'
LogToSyslog Off
このディレクティブを使用して、新しい要求ストリングに変更される要求のためのテンプレートを指定します。 サーバーは、要求を変更すると新しい要求ストリングを使用し、それを後続のディレクティブの要求テンプレートと比較します。
Map ディレクティブでは、 着信要求パス・ストリングを使用して、ルールの突き合わせを行います。 MapQuery - ルールの突き合わせを行うため、要求パスおよび照会ストリングを使用して、 マッチング要求を新規要求ストリングに変更する も参照してください。
Map request_template new_request [server_IP_address | host_name]
テンプレートではアスタリスク (*) をワイルドカードとして使用できます。 スラッシュ (/) の直後の波形記号 (~) は明示的に一致しなければならず、このためにワイルドカードを使用することはできません。
IP アドレス (例えば、240.146.167.72) を指定するか、またはホスト名 (例えば、hostA.raleigh.ibm.com ) を指定することができます。
このパラメーターはオプションです。このパラメーターを指定しない場合、サーバーは、要求を受信する IP アドレスや URL のホスト名に関係なく、このディレクティブを使用してすべての要求を処理します。
ワイルドカード文字をサーバーの IP アドレスとして指定することはできません。
Map /stuff/* /good/stuff/*
Map /stuff/* /customerA/good/stuff/* 240.146.167.72 Map /stuff/* /customerB/good/stuff/* 0.83.104.45
Map /stuff/* /customerA/good/stuff/* hostA.bcd.com Map /stuff/* /customerB/good/stuff/* hostB.bcd.com
なし
このディレクティブを使用して、新しい要求ストリングに変更される要求のためのテンプレートを指定します。 サーバーは、要求を変更すると新しい要求ストリングを使用し、それを後続のディレクティブの要求テンプレートと比較します。
このディレクティブの機能は、Map ルール (Map - ルールの突き合わせを行うため、要求パス・ストリングを使用して、マッチング要求を新規要求ストリングに変更する) とほとんど同じです。 ただし、照会ストリング付きの URL を処理するために、 MapQuery は、パス・ストリングと照会ストリングの両方を使用してルールの突き合わせをします。 着信 URL が MapQuery ルールで一致すると、 残りのルールとの突き合わせには、変換済みの URL が使用されます。
また MapQuery は、照会ストリング付きの URL を、 異なるパス・ストリングまたは異なる照会ストリングを持つ、 別の URL に変換することもできます。 ただし、他のすべてのマッピング・ディレクティブでは、要求パスのみが使用されるため、 要求パスが一致したときは、 変換済みの URL に変更済みの照会ストリングが付加されるだけになります。 パターンを突き合わせるために、変更済みの照会ストリングが使用されることはありません。
MapQuery request_template new_request [server_IP_address | host_name]
テンプレートではアスタリスク (*) をワイルドカードとして使用できます。 スラッシュ (/) の直後の波形記号 (~) は明示的に一致しなければならず、このためにワイルドカードを使用することはできません。
IP アドレス (例えば、240.146.167.72) を指定するか、またはホスト名 (例えば、hostA.raleigh.ibm.com ) を指定することができます。
このパラメーターはオプションです。このパラメーターを指定しない場合、サーバーは、要求を受信する IP アドレスや URL のホスト名に関係なく、このディレクティブを使用してすべての要求を処理します。
ワイルドカード文字をサーバーの IP アドレスとして指定することはできません。
着信 URL が以下であるとします。
/getsomthing?type=1
また、 MapQuery ルールは以下であるとします。
MapQuery /getsomething?type=* /gettype/*
変換済みの URL は /gettype/1 になり、 これが次のルール・マッピングで使用されます。
Proxy /gettype/* http://server/gettype/*
変換済みの URL は http://server/gettype/1 になります。
なし
このディレクティブを使用して、同時にアクティブにしておきたいスレッドの最大数を設定します。最大数に達すると、サーバーは、別の要求が終了してスレッドが使用可能になるまで、新しい要求を保留します。一般に、マシンの能力が高いほど、このディレクティブに設定する値も高くなります。マシンが、メモリー・スワップなどのオーバーヘッド・タスクにあまりに長く時間がかかるようになった場合は、この値を小さくしてみてください。
MaxActiveThreads number_of_threads
MaxActiveThreads 100
このディレクティブは、サーバーが生成した動的データのためのバッファーのサイズを設定するときに使用します。動的データは、CGI プログラム、サーバー側インクルード、および API プログラムからの出力です。
その値は、バイト (B)、キロバイト (K)、メガバイト (M)、またはギガバイト (G) で指定することができます。 数字と値 (B、K、M、G) の間にスペースが入っていても構いません。
MaxContentLengthBuffer size
MaxContentLengthBuffer 100 K
このディレクティブは、各ログ・ファイルの最大サイズを指定するときに使用します。各ログ・ファイルは、このディレクティブで定義されたサイズを超えることはできません。ログ・ファイルが定義された最大サイズに達すると、現在のログ・ファイルがクローズされ、次のインクリメンタル整数値を付加した新規ログ・ファイルが、同じ名前で作成されます。
MaxLogFileSize ディレクティブを設定するための推奨値は、 最小で 10 M、ただし 200 M より小さい値です。 実際のログ・ファイル・サイズは、ここで設定したサイズより若干大きくなります。 この値を低く設定しすぎると、 プロキシー・サーバーがログ・ファイルをクローズおよびオープンする頻度が高くなるため、 プロキシーのパフォーマンスに好ましくない影響が生じます。 一部のプラットフォームでは、この値を高く設定しすぎると、 プロキシーが入出力バッファーのために、より多くのメモリーを使用する原因になります。 ログ・ファイル・サイズがより大きくなると、 入出力バッファーはオペレーティング・システムによって制御されるようになりますが、 プロキシーがメモリー不足になったり、 メモリー・リークのように見える原因となる可能性があります。
その最大サイズは、バイト (B)、キロバイト (K)、メガバイト (M)、およびギガバイトのいずれかの単位で指定できます。
MaxLogFileSize maximum {B | K | M | G}
MaxLogfileSize 128 M
このディレクティブは、サーバーが持続接続で受け取る要求の最大数を指定するときに使用します。この数値を決定するときは、ページで使用するイメージの数を考慮に入れてください。 イメージごとに別々の要求が必要です。
MaxPersistRequest number
MaxPersistRequest 5
このディレクティブは、キャッシュ・エージェントの未解決ページ検索要求のキューの最大の 項目数を指定するために使用します。 大量のメモリーを備えた大きいシステムの場合には、使用可能なすべてのメモリーを使用しないで、ページ検索要求のキューをより大きく定義することができます。
キャッシュに入れる URL のキューは、キャッシュ・エージェントが実行されるたびに最初に判別されます。キャッシュ・エージェントが他の URL へのハイパーテキスト・リンクをたどるよう指示してある場合は、これら他の URL はキャッシュのキュー項目数には入りません。MaxURLs ディレクティブに指定された値に達すると、キューにそれ以上の URL があっても、キャッシュ・エージェントは停止します。
MaxQueueDepth maximum_depth
MaxQueueDepth 250
このディレクティブは、特定の実行中にキャッシュ・エージェントが URL を検索する最大時間数を指定するときに使用します。値が 0 の場合、完了するまでキャッシュ・エージェントが稼働することを意味します。
MaxRuntime {0 | maximum_time}
MaxRuntime 2 hours 10 minutes
MaxRuntime 2 hours
このディレクティブを使用して、 オープン・アイドル状態のソケットの最大数を設定し、 1 つの起点サーバーで保持できるようにします。このディレクティブは、ServerConnPool ディレクティブを On に設定した場合にのみ使用してください。
MaxSocketPerServer num
MaxSocketPerServer 10
MaxSocketPerServer 5
このディレクティブは、特定の実行中にキャッシュ・エージェントが検索する URL の最大数を指定するときに使用します。値が 0 の場合は、制限がないことを意味します。自動モードのキャッシュ・エージェントを使用している場合は、LoadURL および LoadTopCached ディレクティブが MaxURLs より優先します。
MaxURLs maximum_number
MaxURLs 2000
このディレクティブは、リモート・キャッシュ・アクセスを使用しているサーバーが共有する配列のメンバーを指定するために使用します。
Member name { subdirective subdirective . . }
以下のサブディレクティブが組み込まれています。
Member bittersweet.chocolate.ibm.com { RCAAddr 127.0.0.1 RCAPort 6294 CacheSize 25G Timeout 500 milliseconds BindSpecific On ReuseAddr Off }
なし
このディレクティブは、真夜中にログのアーカイブを実行するアプリケーション・プラグインを指定するために使用します。 このディレクティブは、インストールの実行中に初期化されます。このディレクティブが構成ファイルに含まれていない場合には、アーカイブは実行されません。
Midnight /path/file:function_name
このディレクティブは、名前変換中にサーバーが呼び出すカスタマイズ済みアプリケーション関数を指定するときに使用します。このコードは、要求内の仮想パスをサーバー上の物理パスに変換して、URL を特定のオブジェクトにマッピングするための機構を提供します。
NameTrans request_template /path/file:function_name [Server_IP_address | host_name]
ワイルドカード文字をサーバーの IP アドレスとして指定することはできません。
NameTrans /index.html /api/bin/icsextpgm.so:trans_url
なし
Linux および UNIX プラットフォームでは、このディレクティブは、Caching Proxy サーバー・プロセスが 自動的にバックグラウンドで実行されないようにするために使用します。 デフォルトでは off に設定されるこのディレクティブは、次の形式となります。
NoBG [on | off]
NoBG on
NoBG off
このディレクティブは、指定したテンプレートと URL が一致したファイルはサーバーがキャッシュに入れないことを指定するときに使用します。このディレクティブは、構成ファイル内で複数回使用することができます。 テンプレートごとに別々のディレクティブを組み込んでください。URL テンプレートにはプロトコルを指定しなければなりません。
CacheOnly ディレクティブまたは NoCaching ディレクティブのどちらも設定されていない場合は、任意の URL がキャッシュの対象になります。
NoCaching URL_pattern
NoCaching http://joke/*
なし
このディレクティブは、特定のホストまたは指定したテンプレートと一致するドメインからのアクセス要求はログに記録しないことを指定するときに使用します。例えば、ローカル・ホストからのアクセス要求をログに記録しないようにすることができます。
このディレクティブは、構成ファイル内で複数回使用することができます。 また、テンプレートを 1 つまたはそれ以上のスペースで区切ると、同一のディレクティブで複数のテンプレートを指定することもできます。テンプレートでは、ホスト名または IP 番号アドレスを使用することができます。
NoLog {host_name | IP_address} [...]
NoLog 128.0.* *.edu localhost.*
なし
プロキシー・チェーニングのためにディレクティブ http_proxy、ftp_proxy、または gopher_proxy を使用している場合には、このディレクティブを使用して、サーバーがプロキシー経由ではなく、直接接続するドメインを指定することができます。
値は、ドメイン・ネームまたはドメイン・ネーム・テンプレートのストリングとして指定します。 ストリング内の各項目はコンマ (,) で区切ってください。 ストリング内にはスペースを使用しない でください。
このディレクティブ上のテンプレートの入力は、他のディレクティブ上のテンプレートとは異なります。最も重要な 点は、ワイルドカード文字 (*) を使用できない ことです。ドメイン・ネームの最後の部分だけ を使用してテンプレートを指定できます。 サーバーは、指定されたテンプレートと一致する ストリングで終わるドメインに直接接続します。 このディレクティブは、プロキシー・チェーニングにのみ 適用され、SOCKS 構成ファイル内のダイレクト @/= 行と同等です。
no_proxy domain_name_or_template[,...]
no_proxy www.someco.com,.raleigh.ibm.com,.some.host.org:8080
この例では、以下の要求の場合はサーバーはプロキシー経由で接続されません。
なし
デフォルトでは、ブラウザーからの Range 要求を受信した際、 Caching Proxy は、バックエンド・サーバーからのフル応答を必要とします。Caching Proxy は、 要求の Range ヘッダーを除去し、その要求をバックエンド・サーバーに転送します。 応答がプロキシー・サーバーのキャッシュに入ると、 同じリソースに対する以降の要求は、 その要求が Range 要求であるかどうかを問わず、 プロキシー・サーバーからサービスを受けます。 通常、Caching Proxy のデフォルトのアクションにより、 パフォーマンスが向上し、クライアントの応答時間が短縮します。しかし、 応答をキャッシュに入れることができない場合や、応答が非常に大きい場合には、 デフォルトのアクションではパフォーマンスを低下させることがあります。
このデフォルト構成の使用時の問題を解決するには、 NoCacheOnRange ディレクティブを使用します。 このディレクティブで、Range 要求のキャッシングなしを指定します。
このディレクティブを、ibmproxy.conf ファイルでグローバルに使用可能にした場合、 または PROXY マッピング・ルールのオプションとして使用可能にした場合、 Caching Proxy は Range 要求ヘッダーをバックエンド・サーバーに転送します。ただし、 Caching Proxy は、バックエンド・サーバーからの 206 (部分コンテンツ) 応答を キャッシュに入れることはしません。
NoCacheOnRange ディレクティブを使用可能に設定すると、 以下の場合にプロキシーのパフォーマンスが改善されます。
NoCacheOnRange [on | off]
また、プロキシー・マッピング・ルールで NoCacheOnRange を有効にすることもできます。
Proxy /not-cachable/* http://server.com/no-cachable-resources/* NoCacheOnRange
NoCacheOnRange off
このディレクティブは、ブロックするクライアント URL ヘッダーを指定するために使用します。 クライアントによって 送信された任意の HTTP ヘッダーを、必須ヘッダーを含めてブロックすることができます。ヘッダーをブロックして いるときは、十分な注意が必要です。共通ヘッダーには、以下のものが含まれます。
上記およびその他のヘッダーの詳細については、HTTP のプロトコル仕様書を参照してください。このディレクティブは、複数回指定することができます。
NoProxyHeader header
NoProxyHeader Referer:
なし
このディレクティブは、キャッシュ・エージェントがキュー内のページを検索するときに使用するスレッドの数を指定するために使用します。 スレッドの数を、内部ネットワークおよびインターネットへの接続の速度を基にします。可能な範囲は、1 から 100 までです。
NumClients number
NumClients 4
このディレクティブは、オブジェクト・タイプ・ステップ中にサーバーが呼び出すカスタマイズ済みアプリケーション関数を 指定するときに使用します。このコードは、ファイル・システム内の要求されたオブジェクトを探し出して、その MIME タイプを識別します。
ObjectType request_template /path/file:function_name
ObjectType /index.html /api/bin/icsextpgm.so:obj_type
なし
このディレクティブは、ルールの数が増加したときに、 着信要求のルール・マッピング・プロセスを高速化します。
OptimizeRuleMapping ディレクティブを有効にすると、 プロキシーは、各ルールごとに 1 つずつ着信 URI 要求をマッピングする代わりに、 接頭部ツリーに対して URI をマップします。 接頭部ツリーは、 プロキシーがマッピング・ルール間の冗長なストリング比較を除去するのに役立ちます。 その結果、構成内のルール数が 300 より大きくなったときに、 Caching Proxy はより良いパフォーマンスが得られます。
OptimizeRuleMapping [on | off ]
OptimizeRuleMapping off
このディレクティブを使用して、サーバーがクライアントに出力を送信できる時間の最大値を設定します。 時間制限は、ローカル・ファイルに対する要求、およびサーバーがプロキシーとして機能する要求に適用されますが、ローカル CGI プログラムを開始する要求には適用されません。
このディレクティブに設定された時間制限内にサーバーが完全な応答を送信しなければ、サーバーは接続を終了します。時間の値は、時間 (hours)、分 (minutes または mins)、および秒 (seconds または secs) を任意に組み合わせて指定します。
OutputTimeout time
OutputTimeout 30 minutes
このディレクティブは、リモートの構成 PAC ファイル形式を使用して生成されたプロキシーの自動構成ファイルが入っているディレクトリーを指定するときに使用します。
PacFilePath directory_path
このディレクティブを使用して、サーバーからのファイルによって受け入れ、応答する要求のためのテンプレートを指定します。 要求は、Pass ディレクティブのテンプレートに一致すると、後続のディレクティブの要求テンプレートとは比較されません。
Pass request_template [file_path [server_IP_address | host_name]]
テンプレートではアスタリスク (*) をワイルドカードとして使用できます。 スラッシュ (/) の直後の波形記号 (~) は明示的に一致しなければならず、このためにワイルドカードを使用することはできません。
このパラメーターはオプションです。パスを指定しないと、要求そのものがパスとして使用されます。
IP アドレス (例えば、240.146.167.72) を指定するか、またはホスト名 (例えば、hostA.raleigh.ibm.com ) を指定することができます。
このパラメーターはオプションです。このパラメーターを指定しない場合、サーバーは、要求を受信する IP アドレスや URL のホスト名に関係なく、このディレクティブを使用してすべての要求を処理します。
ワイルドカード文字をサーバーの IP アドレスとして指定することはできません。
Pass /gooddoc/*
Pass /parts/* /customerA/catalog/* 240.146.167.72 Pass /parts/* /customerB/catalog/* 0.83.100.45
Pass /Admin/* /usr/lpp/internet/server_root/Admin/* Pass /Docs/* /usr/lpp/internet/server_root/Docs/* Pass /errorpages/* /usr/lpp/internet/server_root/pub/errorpages/* Pass /* /usr/lpp/internet/server_root/pub/*
Pass /Admin/* /opt/ibm/edge/cp/server_root/Admin/* Pass /Docs/* /opt/ibm/edge/cp/server_root/Docs/* Pass /errorpages/* /opt/ibm/edge/cp/server_root/pub/errorpages/* Pass /* /opt/ibm/edge/cp/server_root/pub/*
Pass /Admin/* /usr/lpp/internet/server_root/Admin/* Pass /Docs/* /usr/lpp/internet/server_root/Docs/* Pass /errorpages/* /usr/lpp/internet/server_root/pub/errporpages/* Pass /* /usr/lpp/internet/server_root/pub/*
Pass /Admin/* /opt/ibm/edge/cp/server_root/Admin/* Pass /Docs/* /opt/ibm/edge/cp/server_root/Docs/* Pass /errorpages/* /opt/ibm/edge/cp/server_root/pub/errorpages/* Pass /* /opt/ibm/edge/cp/server_root/pub/*
Pass /icons/* C:¥Program Files¥IBM¥edge¥cp¥icons¥* Pass /Admin/* C:¥Program Files¥IBM¥edge¥cp¥Admin¥* Pass /Docs/* C:¥Program Files¥IBM¥edge¥cp¥Docs¥* Pass /erropages/* C:¥Program Files¥IBM¥edge¥cp¥pub¥errorpages¥* Pass /* C:¥Program Files¥IBM¥edge¥cp¥pub¥*
このディレクティブは、サーバーが持続接続を取り消す前に、クライアント要求間で待機する時間の長さを指定するときに使用します。 この時間は、有効な任意の時間増分で指定できますが、通常は秒単位または分単位の数です。
サーバーは、別のタイムアウト・ディレクティブ InputTimeout を使用して、接続が確立された後に、クライアントが最初の要求を送信するまでどれだけ長く待機するかを決定します。入力タイムアウトについて詳しくは、InputTimeout - 入力タイムアウトを指定するを参照してください。
サーバーは、最初の応答を送信した後に、PersistTimeout ディレクティブの値を使用して、持続接続を取り消すまでにそれぞれの後続要求ごとにどれだけ長く待機するかを決定します。
PersistTimeout time
PersistTimeout 4 seconds
このディレクティブは、指定した URL の PICS ラベルを検索するためにサーバーが呼び出すカスタマイズ済み アプリケーション関数を指定するときに使用します。関数では、要求されたファイルの PICS ラベルを動的に作成 したり、あるいは代替ファイルまたはデータベースの中で PICS ラベルを検索することができます。
PICSDBLookup /path/file:function_name
PICSDBLookup /api/bin/icsext05.so:get_pics
なし
Linux および UNIX 専用です。 このディレクティブは、Caching Proxyのプロセス ID を入れるファイルの場所を指定するときに使用します。サーバー・プロセスが開始されると、そのプロセス ID (PID) をファイルに記録します。単一システム上でサーバーの複数インスタンスを実行している場合は、各インスタンスに固有の PidFile ディレクティブがなければなりません。
PidFile path_to_pid_file_info
PidFile /usr/pidinfo
AIX システムでは、IBM 4960 PCI 暗号アクセラレーター・カードをサポートするため、 追加のディレクティブが提供されています。
これらの 3 つのディレクティブを使用すると、プロキシーは、 デバイス・ドライバーを読み込む、 トークン・デバイスをオープンする、 およびデバイスに保管されている証明書にアクセスする、などが可能になります。 デバイス・ドライバーがロードされると、 プロキシー・サーバーは自動的にそのデバイスを使用して、SSL 通信速度を高速にします。
SSLCryptoCard - インストール済み暗号カードを指定するも参照してください。
PKCS11DefaultCert default_cert_label
トークン・デバイスに保管されている、デフォルトの SSL 証明書ラベルを指定します。
PKCS11DriverPath absolute_path_to_the_card_driver
暗号アクセラレーター・カード用の、デバイス・ドライバーの絶対パスを指定します。
PKCS11TokenPassword password
トークン・デバイスをオープンするためのパスワードを指定します。
PKCS11DefaultCert MyDefaultCertInTheToken PKCS11DriverPath /usr/lib/pkcs11/PKCS11_API.so PKCS11TokenPassword MyPasswordToOpenTheToken
なし
新しい機能やプラグインを使用可能にするために、以下にリストするディレクティブが Caching Proxy ibmproxy.conf ファイルに追加されました。これらのほとんどの ディレクティブの編集には、「構成および管理」フォームは使用できません。 それらの編集には、vi や emacs などの標準 テキスト・エディターを使用する必要があります。本書では、この 新しいディレクティブについて、それぞれの詳細をアルファベット順で示してあります。
ibmproxy.conf ファイルには、Caching Proxy プラグイン・モジュールの構成に使用するディレクティブは、以下の形式で入力する必要があります。
<MODULEBEGIN> plugin name subdirective1 subdirective2 <MODULEEND>
それぞれのプラグイン・プログラムは、ibmproxy.conf ファイルを解析して、それぞれのサブディレクティブのブロックのみを読み取ります。Caching Proxy パーサーは、<MODULEBEGIN> と <MODULEEND> の間にあるものはすべて無視します。
Caching Proxy プラグイン・モジュールと一部の新しい機能では、API ディレクティブを ibmproxy.conf ファイルに追加する必要があります。プロキシー・サーバーは、リストされた順序でプラグイン・モジュールと対話するので、プロキシー構成ファイルの中でディレクティブを順序付けする際には十分注意してください。プロトタイプのディレクティブ (コメント形式の) は、ibmproxy.conf ファイルの API セクションに追加されています。この API ディレクティブは目的別の順序で配列されています。 API ディレクティブを追加して新しい機能やプラグイン・モジュールを使用できるようにするには、各ディレクティブを構成ファイルのプロトタイプ・セクションに示されているように配列してください。あるいは、必要に応じて API ディレクティブをアンコメントして編集し、 それぞれ必要な機能やプラグインに対するサポートを組み込んでください。ユーザー生成のプラグイン・モジュールは、製品と一緒に提供されたモジュールの後に追加してください。
このディレクティブは、サーバーが要求を listen するポートの番号を指定するときに使用します。HTTP の標準のポート番号は、80 です。1024 未満の他のポート番号は、他の TCP/IP アプリケーション用に予約されているので使用できません。 Proxy Web サーバー用に使用される共通ポートは、8080 と 8008 です。
80 以上のポート番号を使用する場合、クライアントはサーバーへの要求の際、特定のポート番号を指定しなければなりません。ポート番号はコロン (:) の後に付き、URL のホスト名の後に記述します。 例えば、ブラウザーから、URL http://www.turfco.com:8008/ は、ポート 8008 で listen している www.turfco.com という名前のホストからのデフォルトのウェルカム・ページを要求します。
ibmproxy コマンドで -p オプションを指定すると、サーバーの始動時にこの設定値をオーバーライドすることができます。
Port number
このディレクティブを変更した場合は、手動でサーバーを停止してから再始動しなければ、変更が有効になりません。再始動しただけでは、サーバーは変更を認識しません。 (Caching Proxy の開始および停止を参照してください。)
Port 80
このディレクティブは、PostAuth ステップ中にサーバーが呼び出すカスタマイズ済みアプリケーション関数を指定するときに使用します。このコードは、前のステップまたは他の PostAuth ハンドラーからの戻りコードに関係なく実行されます。 このディレクティブを使用すると、要求を処理するために割り振られたすべてのリソースをクリーンアップすることができます。
PostAuth /path/file:function_name
AuthExit /ics/api/bin/icsext05.so:post_exit
なし
このディレクティブは、PostExit ステップ中にサーバーが呼び出すカスタマイズ済みアプリケーション関数を指定するときに使用します。このコードは、前のステップまたは他の PostExit ハンドラーからの戻りコードに関係なく実行されます。 このディレクティブを使用すると、要求を処理するために割り振られたすべてのリソースをクリーンアップすることができます。
PostExit /path/file:function_name
PostExit /ics/api/bin/icsext05.so:post_exit
なし
このディレクティブは、PreExit ステップ中にサーバーが呼び出すカスタマイズ済みアプリケーション関数を指定するときに使用します。このコードは、クライアント要求が読み取られてから、他の処理が行われるまでの間に実行されます。このステップの実行中に GoServe モジュールを呼び出すことができます。
PreExit /path/file:function_name
PreExit /ics/api/bin/icsext05.so:pre_exit
なし
このディレクティブを使用して、テンプレートと一致する要求のための保護セットアップ規則を活動化します。
保護セットアップは、保護サブディレクティブで定義されます。このディレクティブの形式は、保護サブディレクティブが入っているラベルまたはファイルを指すか、あるいは保護サブディレクティブを Protect ディレクティブの一部に組み込む必要があるかどうかによって異なります。
このパラメーターは、以下のどの形式であっても構いません。
Protect request_template [setup_file | label[ [FOR Server_IP_address | host_name]
Protect request_template [FOR Server_IP_address | hhost_name] subdirective value subdirective value . . . }
以下のパラメーターが使用されます。
このパラメーターはオプションです。このパラメーターを省略すると、保護セットアップは、一致するテンプレートが入っている最新の DefProt ディレクティブにより定義されます。
例:
Protect http://x.x.x.x PROT-ADMIN
Web ブラウザー内:
例:
Protect http://hostname.example.com PROT-ADMIN
Web ブラウザー内:
IP アドレス (例えば、FOR 240.146.167.72) を指定するか、あるいはホスト名 (例えば、FOR hostA.bcd.com) を指定することができます。
サーバー IP アドレスの指定にワイルドカード文字を使用することはできません。
このパラメーターはオプションです。このパラメーターを指定しない場合、サーバーは、要求を受信する IP アドレスや URL のホスト名に関係なく、このディレクティブを使用してすべての要求を処理します。
これらの例では、IP アドレスを使用しています。 サーバーは、/secret/ または /topsecret/ で 始まる要求を受信すると、その要求が入ってきたネットワーク接続の IP アドレスに基づいて、要求に対して異なる保護 セットアップを活動化します。
Protection BUS-PROT { UserID busybody GroupID webgroup AuthType Basic ServerID restricted PasswdFile /docs/WWW/restrict.pwd GroupFile /docs/WWW/restrict.grp GetMask authors PutMask authors } DefProt /secret/* /server/protect/setup1.acc Protect /secret/scoop/* Protect /secret/business/* BUS-PROT Protect /topsecret/* { AuthType Basic ServerID restricted PasswdFile /docs/WWW/restrict.pwd GroupFile /docs/WWW/restrict.grp GetMask topbrass PutMask topbrass } Pass /secret/scoop/* /WWW/restricted/* Pass /secret/business/* /WWW/confidential/* Pass /topsecret/* /WWW/topsecret/*
Protect /secret/* CustomerA-PROT FOR 0.67.106.79 Protect /secret/* CustomerB-PROT FOR 0.83.100.45 Protect /topsecret/* 0.67.106.79 { AuthType Basic ServerID restricted PasswdFile /docs/WWW/customer-A.pwd GroupFile /docs/WWW/customer-A.grp GetMask A-brass PutMask A-brass } Protect /topsecret/* 0.83.100.45 { AuthType Basic ServerID restricted PasswdFile /docs/WWW/customer-B.pwd GroupFile /docs/WWW/customer-B.grp GetMask B-brass PutMask B-brass }
Protect http://host1/* proxy-prot
Protect /secret/* CustomerA-PROT FOR hostA.bcd.com Protect /secret/* CustomerB-PROT FOR hostB.bcd.com Protect /topsecret/* hostA.bcd.com { AuthType Basic ServerID restricted PasswdFile /docs/WWW/customer-A.pwd GroupFile /docs/WWW/customer-A.grp GetMask A-brass PutMask A-brass } Protect /topsecret/* hostB.bcd.com { AuthType Basic ServerID restricted PasswdFile /docs/WWW/customer-B.pwd GroupFile /docs/WWW/customer-B.grp GetMask B-brass PutMask B-brass }
デフォルトで、「構成および管理」フォームのための保護は、/admin-bin/* という要求テンプレートを指定した Protect ディレクティブによって提供されます。
このディレクティブを使用して、保護セットアップを構成ファイル内に定義します。保護セットアップに名前を付け、保護サブディレクティブを使用して保護のタイプを定義します。
Protection label_name { subdirective value subdirective value . . . }
保護サブディレクティブの説明については、Protection subdirectives - 一連のリソースの保護方法を指定するを参照してください。
Protection NAME-ME { AuthType Basic ServerID restricted PasswdFile /WWW/password.pwd GroupFile /WWW/group.grp GetMask groupname PutMask groupname }
Protect /admin-bin/* { ServerId Private_Authorization AuthType Basic GetMask All@(*) PutMask All@(*) PostMask All@(*) Mask All@(*) PasswdFile /opt/ibm/edge/cp/server_root/protect/webadmin.passwd }
保護セットアップ内で使用できる保護サブディレクティブについて、以下に説明します。 サブディレクティブは、アルファベット順に並んでいます。
保護セットアップは、別個のファイルとしたり、あるいは DefProt、Protect、または Protection ディレクティブの一部として構成ファイルに組み込むことができます。
この保護サブディレクティブは、ユーザー名とパスワードに基づいてアクセスを制限するときに使用します。パスワードがクライアントからサーバーに送信されたときに使用される認証のタイプを指定します。基本認証 (AuthType Basic) では、パスワードは非暗号化テキストとしてサーバーに送信されます。パスワードはエンコードされますが、暗号化はされません。
AuthType Basic
この保護サブディレクティブは、保護ディレクトリーに対する DELETE 要求を出すことができるユーザー名、グループ、およびアドレス・テンプレートを指定するときに使用します。
DeleteMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
この保護サブディレクティブは、保護ディレクトリーに対する GET 要求を出すことができるユーザー名、グループ、およびアドレス・テンプレートを指定するときに使用します。
GetMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
GetMask All@(*)
この Protection サブディレクティブは、保護セットアップで使用するサーバー・グループ・ファイルのパスおよびファイル名を指定するときに使用します。これによって、サーバー・グループ・ファイル内で定義されているグループを以下の場所で使用することができます。
GroupFile /docs/etc/WWW/restrict.group
このサブディレクティブは、他のマスク・サブディレクティブでは扱われない HTTP 要求を出すことが許可されたユーザー名、グループ、およびアドレス・テンプレートを指定するときに使用します。
Mask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
MASK WEBADM,webadm
この保護サブディレクティブは、ユーザー名とパスワードに基づいてアクセスを制限するときに使用します。この保護セットアップが使用するパスワード・ファイルのパス名とファイル名を指定します。
一部のブラウザーは、ホスト内のセキュリティー・レルム (ServerID) によってユーザー ID やパスワードを キャッシュに入れるため、ServerID およびパスワード・ファイルを指定する際は、 以下のガイドラインに従ってください。
PasswdFile /docs/etc/WWW/restrict.password
PasswdFile "c:¥test this¥admin.pwd"
セキュア・サーバーの場合、保護ディレクトリーに対する POST 要求を出すことができるユーザー、グループ、およびアドレス・テンプレートを指定するとき、この保護サブディレクティブを使用します。
PostMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
この保護サブディレクティブは、保護ディレクトリーに対する PUT 要求を出すことができるユーザー、グループ、およびアドレス・テンプレートを指定するときに使用します。
PutMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
この保護サブディレクティブは、ユーザー名とパスワードに基づいてアクセスを制限するときに使用します。使用されるパスワード・ファイルに関連付けたい名前を指定します。 名前は実際のコンピューターの名前でなくても構いません。
この名前は、要求側に送信される ID として使用されます。それぞれの保護セットアップは別々のパスワード・ファイルを 使用できるので、保護セットアップに名前を関連付けておくと、クライアントはどのパスワードを送信すればよいかが わかります。ほとんどのクライアントは、ユーザー名とパスワードの入力を求めるプロンプトを表示するときに、この名前を表示します。
一部のブラウザーは、ホスト内のセキュリティー・レルム (ServerID) によってユーザー ID やパスワードを キャッシュに入れるため、ServerID およびパスワード・ファイルを指定する際は、 以下のガイドラインに従ってください。
ServerID restricted
このディレクティブは、Caching Proxy がどのプロトコルを処理すべきかを 指示し、要求をサーバーにマップするときに使用します。 有効なプロトコルは、http、ftp、および gopher です。
このプロキシー・ディレクティブは、要求をリモート・サーバーに渡します。例えば、次のディレクティブの場合は、すべての要求を指定の URL に転送します。
Proxy /* http://proxy.server.name/*
セキュア・リバース・プロキシー・サーバーの場合は、次のディレクティブを使用してください。
Proxy /* https://proxy.server.name/*
プロキシー・サーバーの制限を抑えたい場合は、構成ファイルから以下のディレクティブをアンコメントします。ただし、プロキシーがリバース・プロキシーとして構成されると、これらのディレクティブにセキュリティー上の問題が発生する場合があります。
Proxy http:* Proxy ftp:* Proxy gopher:*
オプション・パラメーター:
これは、リバース・プロキシー構成にのみ適用されます。
このオプションは、クライアント・サイドのソケットと発信側のソケットの間で、 1 対 1 のマッピングを維持するよう Caching Proxy に指示します。 このオプションは、接続ベースの認証など、一部のアプリケーションの場合に有用です。 例えば、プロキシーがサーバー・サイドのソケットを生かしたまま、 同じクライアント・サイド・ソケットからの要求のために、 そのソケットを再利用する必要があるようなアプリケーションの場合です。
プロキシー・ルールが一致すると、 このオプションは、対応する応答をキャッシュに入れないよう、 プロキシーに指示します。
プロキシー・ルールが一致し、 かつ要求に Range ヘッダーがある場合、 このオプションは、対応する応答をキャッシュに入れないよう、プロキシーに指示します。 詳しくは、NoCacheOnRange - Range 要求でキャッシングなしを指定する を参照してください。
これは、リバース・プロキシー構成にのみ適用されます。
このオプションは、 ジャンクション再書き込みプラグインが有効である場合に使用します。 このオプションでは、着信 URL が一致した場合、 対応する応答をプロキシーが再書き込みすることを許可しません。 詳細については、ジャンクション再書き込みの使用可能化 (オプショナル)とJunctionPrefix オプションを使用するジャンクションの定義 (推奨される方法)を参照してください。
これは、リバース・プロキシー構成にのみ適用されます。
このオプションは、 ジャンクション再書き込みプラグインが有効である場合に使用します。 このオプションでは、 プロキシー・ルール内の最初の URL パターンからジャンクションの接頭部を推論する代わりに、 明示的にジャンクションの再書き込み接頭部を宣言します。 詳細については、ジャンクション再書き込みの使用可能化 (オプショナル)とJunctionPrefix オプションを使用するジャンクションの定義 (推奨される方法)を参照してください。
Proxy request_template target_server_path [[ip]:port] [UseSession | NoCaching | NoCacheOnRange | NoJunction | JunctionPrefix:/url_prefix]
以下は、Proxy ディレクティブの UseSession オプションの例です。
Proxy /abc/* http://server1/default/abc/* :80 UseSession
着信クライアント要求がポート 80 から来るときに、 クライアント要求の URL が /abc/* というパターンに一致すると、 URL は http://server1/default/abc/* にマップされます。
なし。
このディレクティブは、サーバーにプロキシー要求のアクセス統計をログに記録させたい場所のファイルのパスおよびファイル名を指定するときに使用します。デフォルトでは、クライアント要求に対してプロキシーとして振る舞うたびに、サーバーがこのログに項目を書き込みます。特定のクライアントからの要求をログに記録したくない場合は、NoLog ディレクティブを使用することができます。
サーバーは、午前 0 時に新規ログ・ファイルを開始します (サーバーが稼働している場合)。午前 0 時にサーバーが稼働していない場合は、その日における最初のサーバー始動時に新規ログ・ファイルの記録を開始します。ログ・ファイル作成時に、サーバーは、指定されたファイル名を使用し、日付接尾部または拡張子を付加します。 日付接尾部または拡張子は、Mmmddyyyy という形式です。Mmm は月の最初の 3 文字、dd は日、yyyy は年です。
古いログ・ファイルは、ハード・ディスク上で大量のスペースを使用する可能性があるため、これらのファイルは除去するようにしてください。
ProxyAccessLog path/file
このディレクティブは、Proxy Advisor ステップ中にサーバーで呼び出したいカスタマイズ済みアプリケーションを指定するときに使用します。このコードは、要求に対応します。
ProxyAdvisor /path/file:function_name
ProxyAdvisor /api/bin/customadvise.so:proxyadv
なし
ProxyForwardLabels ディレクティブは、プロキシー・サーバーおよびクライアントでか、あるいはプロキシー階層内の 2 つのプロキシーで、PICS フィルター操作を指定するときに使用します。
ProxyForwardLabels を On に設定した場合に、プロキシー・サーバーは、起点サーバー、ラベル・ビューロー、Caching Proxy のラベル・キャッシュ、およびラベル提供側プラグインからのラベルを含め、見つかったすべての PICS ラベルについて PICS-Label: HTTP ヘッダーを生成します。
ProxyForwardLabels が Off の場合は、PICS-Label: HTTP ヘッダーは生成されません。
ProxyForwardLabels {on | off}
ProxyForwardLabels Off
このディレクティブは、From: ヘッダーを生成するために使用します。 これは、通常、プロキシー管理者の電子メール・アドレスを指定する場合に使用されます。
ProxyFrom e-mail_address
ProxyFrom webmaster@proxy.ibm.com の設定の結果として、以下のヘッダーが変更されます。
元のヘッダー | 変更後のヘッダー |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com/ |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
Pragma: no-cache | From: webmaster@proxy.ibm.com |
Pragma: no-cache |
なし
このディレクティブは、ユーザーがブラウザーで「再読み込み」をクリックした場合のサーバーの 反応を指定するときに使用します。ProxyIgnoreNoCache ディレクティブを On に設定すると、高負荷の期間中は、サーバーは 宛先サーバーにページを要求せず、ファイルのキャッシュ・コピーが使用できればこれを提供します。サーバーは、本質的 に、ブラウザーから送信された "Pragma: no-cache" ヘッダーを無視します。
ProxyIgnoreNoCache {on | off}
ProxyIgnoreNoCache off
このディレクティブは、クライアントとの持続接続を維持するかどうかを指定するときに使用します。持続接続機能によって、ユーザーの待ち時間が短縮されてプロキシー・サーバー上の CPU の負荷が軽減される一方で、より多くのリソースが必要とされます。 持続接続機能は、より多くのスレッドと、そのためにより多くのプロキシー・サーバー上のメモリーを必要とします。
プロキシーのいずれかが HTTP 1.1 に準拠していない場合、持続接続機能をマルチレベルのプロキシー・サーバー・セットアップに使用しないでください。
ProxyPersistence {on | off}
ProxyPersistence on
このディレクティブは、プロキシーがクライアントの IP アドレスを宛先サーバーに転送するかどうかを指定するときに使用します。
ProxySendClientAddress {Client_IP: | OFF}
ディレクティブ ProxySendClientAddress Client-IP: の結果として、以下のヘッダーが変更されます。
元のヘッダー | 変更後のヘッダー |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
Pragma: no-cache | Client-IP: 0.67.199.5 |
Pragma: no-cache |
なし
このディレクティブは、クライアントが送信したストリングを置き換える User Agent ストリングを指定するときに使用します。これにより、Web サイトを訪問中の匿名性がさらに高まります。しかし、User Agent ストリングに基づいてページをカスタマイズしてあるサイトもあります。ProxyUserAgent ディレクティブを使用することで、このようなカスタム・ページは表示されません。
ProxyUserAgent product_name/version
ディレクティブ ProxyUserAgent Caching Proxy/6.1 の結果として、以下のヘッダーが変更されます。
元のヘッダー | 変更後のヘッダー |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
User Agent: Mozilla/ 2.02 OS2 | User Agent: Caching Proxy/6.1 |
Pragma: no-cache | Pragma: no-cache |
なし
このディレクティブは、HTTP ヘッダーの形式を制御するときに使用します。このディレクティブに使用できる 4 つの 値があります。ProxyVia が Full に設定されると、Caching Proxy は Via ヘッダーを要求または 応答の中に追加します。Via ヘッダーがすでにストリーム内にある場合には、Caching Proxy はその終わりにホスト情報を追加 します。Set に設定されると、Caching Proxy は Via ヘッダーをホスト情報に設定し、Via ヘッダーがすでに ストリーム内にある場合は、Caching Proxy がそれを除去します。Pass に設定されると、Caching Proxy はすべての ヘッダー情報をそのまま転送します。Block に設定されると、Caching Proxy は Via ヘッダーを転送しません。
ProxyVia {Full | Set | Pass | Block}
ProxyVia Pass
ProxyVia Full
これは、リバース・プロキシー構成にのみ適用されます。
ProxyWAS マッピング・ディレクティブは Proxy ディレクティブと同様に作動しますが、 一致する要求を WebSphere Application Server に送ることも Caching Proxy に 指示します。このディレクティブの使用方法の例については、 Proxy - プロキシー・プロトコルまたはリバース・プロキシーを指定するを参照してください。
ProxyWAS request_template target_server_path [[ip]:port] [UseSession | NoCaching | NoCacheOnRange | NoJunction | JunctionPrefix:/url_prefix]
なし
このディレクティブは、サーバーがプロキシーとして機能するか、またはプロキシーとコンテンツ・サーバーの両方として機能するかを指定するために使用します。 Caching Proxy をプロキシーとしてだけ使用することをお勧めします。
PureProxy {on | off}
PureProxy on
このディレクティブは、ログがパージされるまでの経過時間 (日数) を指定するときに使用します。 PurgeAge が 0 の場合、ログが削除されることはありません。
PurgeAge number
PurgeAge 7
このディレクティブは、ログ・アーカイブがパージされるまでにどれだけの大きさ (メガバイト単位) になり得るかを指定するときに使用します。PurgeSize ディレクティブが 0 に設定されると、サイズに限界はなく、ファイルは削除されません。
PurgeSize の設定は、ログ・タイプのログのすべて を参照します。例えば、エラーをログに記録していて (すなわち、構成ファイルに ErrorLog 項目が作成されていて)、PurgeSize が 10 MB として定義されている場合には、Caching Proxy はすべてのエラー・ログのサイズを計算して合算し、次に、合計サイズが 10 MB 未満になるまでログを削除します。
PurgeSize number_of_MB
PurgeSize 0
このディレクティブは、リモート・キャッシュ・アクセス構成ファイルの名前および場所を指定する場合に使用します。
RCAConfigFile /etc/file_name
RCAConfigFile /etc/user2rca.conf
RCAConfigFile /etc/rca.conf
このディレクティブは、RCA ポート上で作動するスレッドの数を指定するときに使用します。
RCAThreads number_of_threads
RCAThreads 50
MaxActiveThreads x [(ArraySize -1) / (2 x ArraySize -1)]
このディレクティブを使用して、接続が取り消されるまでにネットワーク活動をせずにいられる時間の制限を指定します。
ReadTimeout time
ReadTimeout 5 minutes
このディレクティブは、受け入れて、別のサーバーに送信したい要求のテンプレートを指定するときに使用します。要求が Redirect ディレクティブ上のテンプレートと一致すると、その要求は構成ファイル内の他のディレクティブ上のテンプレートとは比較されません。
Redirect request_template URL [server_IP_address | host_name]
テンプレートではアスタリスク (*) をワイルドカードとして使用できます。 スラッシュ (/) の直後の波形記号 (~) は明示的に一致しなければならず、このためにワイルドカードを使用することはできません。
URL には、プロトコル指定と、要求の送信先であるサーバーの名前が含まれていなければなりません。パス名またはファイル名を入れることもできます。request_template でワイルドカードを使用した場合は、URL のパス名またはファイル名にもワイルドカードを使用することができます。 元の要求の request_template のワイルドカードに一致する部分が、URL のワイルドカードの代わりに挿入されます。
IP アドレス (例えば、240.146.167.72) またはホスト名 (例えば、hostA.bcd.com) を指定することができます。
このパラメーターはオプションです。このパラメーターを指定しない場合、サーバーは、要求を受信する IP アドレスや URL のホスト名に関係なく、このディレクティブを使用してすべての要求を処理します。
ワイルドカード文字をサーバーの IP アドレスとして指定することはできません。
Redirect /chief/stuff/* http://www.other.org/wahoo/*
Redirect /stuff/* http://www.chief.org/wahoo/* 240.146.167.72 Redirect /stuff/* http://www.dawg.com/pound/* 0.83.100.45
Redirect /stuff/* http://www.chief.org/wahoo/* hostA.bcd.com Redirect /stuff/* http://www.dawg.com/pound/* hostB.bcd.com
なし
このディレクティブを使用し、Caching Proxy によって、Cookie ヘッダーを基にしたリソースの 複数のバリアント (URI) をキャッシュに入れることができるようにします。
詳しくは、SupportVaryHeader - HTTP Vary ヘッダーを基にしたリソースの、 複数のバリアントをキャッシュに入れる を参照してください。
RegisterCacheIdTransformer Cookie cookie-name
cookie-name は、クライアントの要求の Cookie ヘッダーにおける 名前です。
RegisterCacheIdTransformer Cookie Usergroup
SupportVaryHeader と結合しているこのディレクティブの 使用例については、SupportVaryHeader - HTTP Vary ヘッダーを基にしたリソースの、 複数のバリアントをキャッシュに入れる を参照してください。
なし
これは、リバース・プロキシー構成にのみ適用されます。
ReversePass マッピング・ディレクティブは、サーバー応答ストリームを検査して、 自動リダイレクトの結果として再書き込みされる要求を検出します。通常、サーバーが 3xx クラス (例えば、301 (moved permanently)、または 303 (see other)) で HTTP コードを 戻す時に、サーバーは、要求側クライアントが以後の要求を正しい URL および IP アドレス に送信するように指示する応答を付けて、メッセージを送信します。リバース・プロキシー・ セットアップの場合、起点サーバーからのリダイレクト・メッセージは、以後の要求に 関してクライアント・ブラウザーにプロキシー・サーバーをバイパスさせることが 可能です。クライアントが起点サーバーと直接に連絡を取ることを避ける ために、ReversePass ディレクティブを使用して、起点サーバーに特定して送信される 要求をインターセプトします。
要求ストリームを処理する他のマッピング・ディレクティブとは異なり、ReversePass は、 そのテンプレートを応答ストリームと突き合わせます。応答ストリームとは、プロキシー・サーバーが 起点サーバーから取得し、クライアントへ送信する応答のことです。
ReversePass rewritten_URL proxy_URL [host:port]
host:port オプションは、 プロキシーが、バックエンド・サーバーのホスト名およびポートに基づいた 異なる ReversePass 規則を適用することを可能にします。
ReversePass http://backend.company.com:9080/* http://edge.company.com/*ポート 9080 は エッジでのアプリケーション・サービスのデフォルトのポートです。このタイプの要求は、 起点アプリケーション・サーバーが 3xx コードをクライアントに戻す場合に 生成されます。
ReversePass http://edge.company.com:9080/* http://edge.company.com/*
なし
これは、リバース・プロキシー構成にのみ適用されます。
このディレクティブは、再書き込みする必要のあるドメイン・パターンを指 定するために使用します。 このディレクティブは、ドメイン domain_pattern1 から domain_pattern2 に変換します。
RewriteSetCookieDomain domain_pattern1 domain_pattern2
RewriteSetCookieDomain .internal.com .external.com
なし
これは、リバース・プロキシー構成にのみ適用されます。
このディレクティブは、RTSP リダイレクトを使用可能または使用不可にします。オプションは、on または off です。
RTSPEnable {on | off}
RTSPEnable on
なし
これは、リバース・プロキシー構成にのみ適用されます。
このディレクティブは、リダイレクトされる要求を受信する RTSP プロキシー・サーバーを指定するときに使用します。タイプの異なるストリームに合わせて各種サーバーを指定できます。このディレクティブの形式は、次のとおりです。
rtsp_proxy_server server dns address[:port] default rank [list of mime types]
rtsp_proxy_server rproxy.mycompany.com:554 1 rtsp_proxy_server fw1.mycompany.com:554 2 rtsp_proxy_server fw1.mycompany.com:555 3 rtsp_proxy_server fw2.mycompany.com:557 4
なし
これは、リバース・プロキシー構成にのみ適用されます。
このディレクティブは、起点サーバーではなく、プロキシー・サーバーに RTSP 要求がリダイレクト されるまでに受信される要求の数を指定します。RealNetworks プロキシーは、最初の要求のストリームをキャッシュに格納し、キャッシングには、当初、ストリームの受信の 2 倍の帯域幅となります。しきい値 2 以上の値を指定すると、1 回だけの要求はキャッシュに格納されません。このディレクティブの形式は、次のとおりです。
rtsp_proxy_threshold number_of_hits
rtsp_proxy_threshold 5
なし
これは、リバース・プロキシー構成にのみ適用されます。
このディレクティブは、リダイレクトのためにメモリーに保持される固有の URL の数を指定します。プロキシーは、 特定の URL が以前に検索されているかどうかを判別するために、このリストを参照します。リストのサイズが大きいと、直前の要求を受信したのと同じプロキシー・サーバーに後続の要求をプロキシー・サーバーが送信できる可能性が高まります。しかし、リストの項目ごとに約 16 バイトのメモリーが消費されます。
rtsp_url_list_size size_of_list
rtsp_url_list_size 8192
なし
デフォルトでは、ibmproxy.conf ファイルに定義されているルールに対して Caching Proxy が要求をマップする際、マッチング・プロセスで大/小文字を区別します。 ただし、一部のアプリケーション URL は、大/小文字を区別していません。 これらの要求を正しく処理するために、 RuleCaseSense ディレクティブが用意されています。このディレクティブを off に設定すると、プロキシーは大/小文字の区別をせずに、 要求のマッチングを行います。
RuleCaseSense {on | off}
RuleCaseSense on
このディレクティブは、サーバーによって開始された CGI プログラムが終了するまでの時間を設定します。時間が期限切れになると、サーバーはプログラムを終了します。 Linux および UNIX プラットフォームでは、これは KILL シグナルによって実行されます。
時間の値は、時間 (hours)、分 (minutes または mins)、および秒 (seconds または secs) を任意に組み合わせて入力します。
ScriptTimeout timeout
ScriptTimeout 5 minutes
このディレクティブは、Caching Proxy からダウンストリーム・サーバーへ送信される要求は HTTP バージョン 1.0 プロトコルを使用する必要があることを指定するときに使用します。(ダウンストリーム・サーバーとは、要求を処理するプロキシーのチェーン内の別のプロキシー・サーバーあるいは起点サーバーです。)
このディレクティブが使用されると、Caching Proxy は HTTP 1.0 を要求行の中のプロトコルとして識別します。ほとんどの HTTP 1.0 サーバーでサポートされている Cache-control ヘッダーのような、HTTP 1.0 に特有の機能、および ある特定の HTTP 1.1 機能は、ダウンストリーム・サーバーへ送られます。このディレクティブは、HTTP 1.1 要求を正しく 処理しないダウンストリーム・サーバーがあった場合に使用してください。
SendHTTP10Outbound ディレクティブが指定されていない 場合には、Caching Proxy は HTTP 1.1 を要求行の中のプロトコルとして識別します。この要求では、持続接続機能のような HTTP 1.1 機能も使用することができます。
SendHTTP10Outbound url_pattern
このディレクティブは、複数回指定することができます。例えば、次のとおりです。
SendHTTP10Outbound http://www.hosta.com/* SendHTTP10Outbound http://www.hostb.com/*
逆方向の互換性のために、前の SendHTTP10Outbound の構文は、以下のように取り扱われることになりました。
なし
これは、リバース・プロキシー構成にのみ適用されます。
リバース・プロキシーとして機能する場合、Caching Proxy はクライアントから HTTP 要求 を受信し、その要求を起点サーバーに送信します。デフォルトで、Caching Proxy は、 起点サーバーに送信される要求の HOST ヘッダーに起点サーバーのホスト名を書き込みます。 SendRevProxyName ディレクティブが yes に設定された場合、Caching Proxy は、代わりに 自身のホスト名を HOST ヘッダーに書き込みます。 バックエンド・サーバーから別のバックエンド・サーバーへ要求がリダイレクトされる 場合であっても、起点サーバーへの要求が常にプロキシー・サーバーから来るように 見せることが可能なので、このディレクティブはバックエンド・サーバー用の 特別な構成を使用可能にするために使用されます。
このディレクティブは、次の点で ReversePass マッピング・ディレクティブとは 異なります。ReversePass ディレクティブは指定された構文によって要求を インターセプトし、ユーザーが指定した別の要求コンテンツで置き換えます。 一方、SendRevProxyName ディレクティブは 起点サーバーのホスト名を Caching Proxy のホスト名に置き換えるためにのみ 設定されます。このディレクティブは、エッジでのアプリケーション・サービスの構成には利用できません。
SendRevProxyName {yes | no}
このディレクティブは、ガーベッジ・コレクション・スレッドでサーバー接続がタイムアウト (ServerConnTimeout ディレクティブによる設定) になったかどうかを検査する間隔を設定します。 このディレクティブは、ServerConnPool ディレクティブを On に設定した場合にのみ使用してください。
ServerConnGCRun time_interval
ServerConnGCRun 2 minutes
ServerConnGCRun 2 minutes
このディレクティブによってプロキシーでは、起点サーバーへのその発信接続を 1 つにまとめてプールすることができます。このディレクティブを On に設定すると、パフォーマンスが向上し、持続接続が可能な起点サーバーの利点を活用できます。 また、ServerConnTimeout ディレクティブを通じて未使用接続をどれだけ長い期間保持するかを指定することもできます。
ServerConnPool {on | off}
ServerConnPool off
このディレクティブは、接続が取り消されるまでネットワーク活動をしないでいられる時間を制限するときに使用します。このディレクティブは、ServerConnPool ディレクティブを On に設定した場合にのみ使用してください。
ServerConnTimeout time-spec
ServerConnTimeout 30 seconds
ServerConnTimeout 10 seconds
このディレクティブは、その初期化ルーチンの実行中にサーバーが呼び出すカスタマイズ済みアプリケーション関数を指定するときに使用します。このコードは、クライアント要求が読み込まれる前、およびサーバーが再始動されるたびに実行されます。
GoServe モジュールを PreExit または Service ステップで使用する場合は、ここで gosclone モジュールを呼び出す必要があります。
ServerInit /path/file:function_name [initialization_string]
ServerInit /ics/api/bin/icsext05.so:svr_init
なし
このディレクティブは、サーバー・プログラムのインストール先ディレクトリー (サーバーの現行作業ディレクトリー) を指定するときに使用します。ディレクティブをログに記録する際には、相対パス名が使用されているときのデフォルト・ルートとしてこの現行作業ディレクトリーが使用されます。
Windows システムでは、このディレクトリーはインストール時に識別されます。
ServerRoot directory_path
このディレクティブは、サーバー終了ステップ中にサーバーが呼び出すカスタマイズ済みアプリケーション関数を指定 するときに使用します。このコードは、正常シャットダウンが行われたとき、およびサーバーが再始動されるごとに 実行されます。 このディレクティブを使用すると、PreExit アプリケーション関数によって割り振られたリソースを解放することができます。
ServerTerm /path/file:function_name
ServerTerm /ics/api/bin/icsext05.so:shut_down
なし
このディレクティブは、サービス・ステップ中にサーバーが呼び出すカスタマイズ済みアプリケーション関数を指定するときに使用します。このコードは、クライアント要求に対応します。 例えば、ファイルを送信したり、CGI プログラムを実行します。
このディレクティブにはデフォルトはありません。要求が Service 規則と一致する (Service ディレクティブで指定 されたアプリケーション関数が実行される) が、関数が HTTP_NOACTION を戻した場合は、サーバーはエラーを生成し、要求は失敗します。
Service request_template/path/file:function_name [server_IP_address | host_name]
ワイルドカード文字をサーバーの IP アドレスとして指定することはできません。
Service /index.html /ics/api/bin/icsext05.so:serve_req Service /cgi-bin/hexcalc* /ics/api/calculator:HEXcalc*
なし
このディレクティブは、URL 要求の終了コードを指定するために使用します。要求の中で終了コードを使用すると、Caching Proxy は、要求の処理時および結果がすでにキャッシングされたかどうかの評価時に、終了コードの前の文字だけを評価します。複数の終了コードが定義されている場合には、Caching Proxy は着信 URL を ibmproxy.conf ファイルに定義されている順序での終了コードと比較します。
SignificantURLTerminator terminating_string
SignificantURLTerminator &.
この例では、以下の 2 つの要求は同一として処理されます。
http://www.exampleURL.com/tx.asp?id=0200&.;x=004;y=001 http://www.exampleURL.com/tx.asp?id=0200&.;x=127;y=034
なし
このディレクティブは、Caching Proxy for Windows 内の内部 sendmail ルーチンによって使用される SMTP サーバーを設定するために使用します。 WebMasterEMail - 選ばれたサーバー報告書を受け取るための電子メール・アドレスを設定するおよびWebMasterSocksServer (Windows のみ) - sendmail ルーチン用に Socks サーバーを設定するで説明する 2 つのディレクティブも、このルーチンのために設定しなければなりません。
SMTPServer IP address or hostname of SMTP server
SMTPServer mybox.com
なし
このディレクティブを使用して、SNMP サポートを使用可能または使用不可にします。
SNMP {on | off}
SNMP off
このディレクティブは、Web サーバー分散プロトコル・インターフェース (DPI) サブエージェントと SNMP エージェント間 のパスワードを定義するときに使用します。SNMP コミュニティー名は、サーバーの指定されたコミュニティーに ついて SNMP がモニターするパフォーマンス変数をユーザーが表示するのを許可します。システム管理者 は、パスワードが入力された場合に表示できる変数を定義します。SNMP コミュニティー名を変更する ときは、/etc/snmpd.conf という名前のファイルに指定されたコミュニティー名も必ず変更してください。
SNMPCommunity name
SNMPCommunity public
このディレクティブは、リバース・プロキシーの使用時にセキュア要求の内容をキャッシュに入れるときに使用します。このディレクティブは、プロキシー・サーバーへのすべての接続 (クライアント接続とバックエンド・コンテンツ接続の両方) のためのキャッシュを構成します。
SSLCaching {on | off}
SSLCaching off
このディレクティブは、Caching Proxy が独自の SSL 証明書を発行する複数ドメインの単一リバース・プロキシーとして活動しているときに、クライアントにどの証明書を送るかを決定し、プロキシー・サーバーにクライアント認証のためにクライアント側の PKI 証明書を検索するかどうかをプロキシーが指示できる鍵ラベルを指定するために使用します。
Caching Proxy は、SSLCertificate ディレクティブを使用して、 認証局 (CA) 発行の証明書と、自己割り当ての証明書を区別することができます。 ただし、このディレクティブを使用して、 なんらかの CA 発行の証明書を受け入れる (ClientAuthRequired オプション) ことにより、 無効なユーザーにもプロキシー・サーバーへのアクセスを獲得することを許可できます。 SSLCertificate ディレクティブで ClientAuthRequired オプションを使用する場合、 どの正当なユーザーが SSL チャネルにアクセスできるかを判別するために、 論理式オプションを使用することができます。
追加の論理式を SSLCertificate ディレクティブに追加すると、 Caching Proxy は、クライアント証明書から値を取り出して、その論理式を計算します。 クライアント証明書の値でその式が満たされた場合、 Caching Proxy は、SSL 接続の使用についてクライアントを認可します。 満たされない場合、接続はシャットダウンされクローズされます。
SSLCertificate serverIP/hostname CertificateLabel [NoClientAuth | ClientAuthRequired logic-expression]
この論理式オプションが有効なのは、 ClientAuthRequired オプションと共に使用された場合のみです。 追加の論理式を SSLCertificate ディレクティブに追加すると、 Caching Proxy は、クライアント証明書から値を取り出して、その論理式を計算します。 クライアント証明書の値でその式が満たされた場合、 Caching Proxy は、SSL 接続の使用についてクライアントを認可します。 満たされない場合、接続はシャットダウンされクローズされます。
SSLCertificate www.abc.com ABCCert SSLCertificate 204.146.167.72 intABCCert SSLCertificate www.xyz.com XYZCert ClientAuthRequired SSLCertificate www.xyz.com XYZCert ClientAuthRequired CN="valid.user.common.name.pattern" && (L="accepted.location.pattern" || C!="not.valid.country.pattern")
なし
これは、リバース・プロキシー構成にのみ適用されます。
このディレクティブは、インストール済みの暗号カードがあることをプロキシー・サーバー に知らせ、そのカードを指定するために使用します。
AIX で、IBM 4960 PCI 暗号アクセラレーター・カードをサポートするためには、 PKCS11DefaultCert、PKCS11DriverPath、 PKCS11TokenPassword - IBM 4960 PCI 暗号アクセラレーター・ カードをサポートする (AIX のみ)を参照してください。
SSLCryptoCard {rainbowcs | nciphernfast} {on | off}
SSLCryptoCard rainbowcs on
なし
このディレクティブは、Caching Proxy がセキュア要求をポート 443 で listen するように指定するために使用します。
SSLEnable {on | off}
SSLEnable off
このディレクティブは、Caching Proxy が SSL をインプリメントすることによって HTTPS 要求にアップグレードする HTTP 要求をアドレス指定するポートを指定するときに使用します。 メイン HTTP ポート 80 または メイン SSL ポート 443 以外のポートを指定します。
SSLForwardPort port number
SSLForwardPort 8888
なし
このディレクティブは、SSL (通常はポート 443) が使用可能なときに、標準 HTTP 要求 (通常はポート 80 および 8080) に対するリスナー・スレッドを使用不可にするために使用します。
SSLOnly {on | off}
SSLOnly off
このディレクティブを使用して、ibmproxy のデフォルト HTTPS ポート 443 以外の HTTPS listen ポートを指定します。
SSLPort port value
ここで、port value は 0 より大きい整数値。さらに、port value がオペレーティング・システムに許可されており、他のアプリケーションに使用されていないことが必要です。
SSLPort 8443
443
これは、フォワード・プロキシー構成にのみ適用されます。
このディレクティブを on に設定すると、宛先サーバー上の任意のポートへの SSL トンネリングが許可されます。このディレクティブを off に設定すると、Proxy 規則で指定されているポートへのみの SSL トンネリングが許可されます。SSL トンネリングに対する Proxy 規則がなく、SSLTunneling ディレクティブが Off の場合は、SSL トンネリングは許可されません。SSLTunneling ディレクティブが on の場合、Enable ディレクティブを使用して、CONNECT メソッドも使用可能にしなければなりません。
Caching Proxy をフォワード・プロキシーとして使用する場合、 このディレクティブを使用可能にする必要があります。 ただし、 Caching Proxy をリバース・プロキシーとして使用する場合は、 このディレクティブを使用不可にしておく (デフォルト) と、 SSL トンネリングのぜい弱性に対するアタックから保護されます。
詳しくは、SSL トンネリング を参照してください。
SSLTunneling {on | off}
SSLTunneling off
このディレクティブは、使用する SSL のバージョン (V2、V3、またはすべてのバージョン) を指定するときに使用します。SSL バージョン 3 をサポートできないサーバーを使用している場合は、このディレクティブを V2 に設定してください。
SSLVersion {SSLV2 | SSLV3 | all}
SSLVersion SSLV3
このディレクティブは、SSL バージョン 2 のセッションがセッション有効期限切れになるまで活動なしに待機する長さ (秒単位) を指定するときに使用します。
SSLV2Timeout seconds
ここで、seconds は 0 と 100 の間の値を表します。
SSLV2Timeout 100
このディレクティブは、SSL バージョン 3 のセッションがセッション有効期限切れになるまで活動なしに待機する長さ (秒単位) を指定するときに使用します。
SSLV3Timeout seconds
ここで、seconds は 1 秒と 86400 秒 (秒数による 1 日) の間の値です。
SSLV3Timeout 100
このディレクティブは、ファイル接尾部を AddClient、AddCharSet、AddType、 AddEncoding、および、AddLanguage ディレクティブの接尾部パターンと比較する場合に、サーバーに大文字小文字を区別させたいかどうかを指定するときに使用します。デフォルトでは、サーバーは大文字小文字を区別しません。
SuffixCaseSense {on | Off}
SuffixCaseSense Off
このディレクティブを使用し、Caching Proxy によって、HTTP Vary ヘッダーを基にしたリソースの 複数のバリアント (URI) をキャッシュに入れることができるようにします。
SupportVaryHeader ディレクティブが使用可能になると、プロキシーは URI を基にしたキャッシュ ID と、 クライアント要求の選択済みヘッダー値を形成します。
選択済みヘッダーの名前は、サーバーからの事前応答で送信された Vary ヘッダーで 指定されます。サーバーがリソースに対する選択済みヘッダー名のセットを変更する場合、 リソースに対する以前のキャッシュ・オブジェクトはすべて、プロキシーのキャッシュから 除去されます。
このディレクティブは、RegisterCacheIdTransformer ディレクティブ (RegisterCacheIdTransformer - Cookie ヘッダーを基にしたリソースの、 複数のバリアントをキャッシュに入れる) と一緒に使用できます。
両方のディレクティブを使用すると、プロキシーは、サーバーおよびクライアントの要求ヘッダーから、Vary ヘッダーを基にした 内部キャッシュ ID 変換プログラムを作成します。このようにして、 プロキシーは、異なる要求と応答のペアに対して (要求された URI が同じであっても) 固有のキャッシュ ID を 生成することができます。
同じ URI のキャッシュ・オブジェクトは、それぞれ固有のデフォルト存続時間を持っており、それは 要求/応答、または他の構成設定値の「Expire」および「Cache-Control」ヘッダーに依存します。 Dynacache プラグインが使用される場合、同じ URI に関連づけられた複数のプレゼンテーションはすべて、 プロキシーのキャッシュ内で共に無効になります。
SupportVaryHeader {on | off}
この例として、以下のディレクティブが ibmproxy.conf で使用可能にされ、構成されています。次のとおりです。
SupportVaryHeader on RegisterCacheIdTransformer Cookie UserGroup
クライアントの Guest は、次のようにしてプロキシー・サーバーにアクセスします。
URI [<code>] http://www.dot.com/group.jpg [</code>]
そして要求/応答は、次のようになります。
GET /group.jpg HTTP/1.1 Host: www.dot.com Cookie: UserGroup=Guest Accept-Language: en_US HTTP/1.1 200 Server: my-server Vary: Accept-Language .......
次に、クライアントの Admin は、同じ URI でプロキシー・サーバーに アクセスします。
http://www.dot.com/group.jpg
そして要求/応答は、次のようになります。
GET /group.jpg HTTP/1.1 Host: www.dot.com Cookie: UserGroup=Admin Accept-Language: fr_FR HTTP/1.1 200 Server: my-server Vary: Accept-Language .......
結果として、応答がキャッシュ可能である場合、プロキシー・サーバーは、2 つの 異なるキャッシュ ID を生成します。
1. CacheID(URI, "Guest", "en_US") 2. CacheID(URI, "Admin", "fr_FR")
プロキシー・サーバーは、キャッシュにあるサーバーからの応答の 2 つの異なるバリアントを 保管しています。その後、クライアントのいずれかが、言語プリファレンスとユーザー・グループ値を 組み合わせて、リソース (.../group.jpg) を要求する時、プロキシー・サーバーは、 キャッシュからリソースの適切なバリアントを検索して、それをサービス供給します。
SupportVaryHeader off
このディレクティブは、SSL 接続で TLS バージョン 1 プロトコルを使用可能にするときに使用します。このディレクティブが on に設定されたら、SSL 接続は最初に TLS プロトコルを検査し、次に SSLv3 プロトコル、最後に SSLv2 プロトコルを検査します。
TLSV1Enable {on | off}
TLSV1Enable on
なし
このディレクティブは、データ操作ステップ中にサーバーが呼び出すカスタマイズ済みアプリケーション関数を指定するときに使用します。このコードは、3 つのアプリケーション関数を提供します。
サーバーの各インスタンスごとに複数の Transmogrifier をアクティブにすることができます。
Transmogrifier /path/file:function_name:function_name:function_name
Transmogrifier /ics/bin/icsext05.so:open_data:write_data:close_data
なし
このディレクティブは、データに関する以下の内容を通知するメッセージをクライアントへ送信するために使用します。
transmogrifiedwaning {yes|no}
Yes
これは、フォワード・プロキシー構成にのみ適用されます。
Linux システムの場合にのみ、このディレクティブを使用すると、 サーバーが透過プロキシー・サーバーとして稼働できるかどうかを指定できます。
TransparentProxy ディレクティブを on に設定すると、BindSpecific ディレクティブは無視されて、デフォルトで off となります。ほとんどの HTTP トラフィックがポート 80 を流れるため、ポート 80 を構成ポートの 1 つにすることをお勧めします。
TransparentProxy {on | off} Port 80
TransparentProxy off
IPCHAIN ファイアウォールを使用する場合、 このディレクティブを使用可能にするだけで、透過プロキシーを正常に構成できます。 IPTABLES ファイアウォールを使用する場合は、 IPTABLES ファイアウォール・ルールを手動で追加する必要があります。
IPTABLES ファイアウォールを使用していて、TransparentProxy ディレクティブを使用可能に設定した場合、 プロキシー・サーバーを開始する前に、 次のコマンドを実行して、ファイアウォール・ルールを IPTABLES に追加してください。
iptables -t nat -A PREROUTING -i your-network-interface -p tcp --dport 80 -j REDIRECT --to-port ibmproxy-listening-port
ファイアウォールとプロキシー・サーバーが同じボックス上にあると想定すると、 このルールでは、IPTABLES ファイアウォールに対し、 ポート 80 を宛先とするすべての TCP トラフィックを、 ローカル・プロキシー listen ポートにリダイレクトするよう指示します。 このルールを IPTABLES 構成に追加することもできます。これにより、 システム再始動時に、このルールが自動的に読み込まれます。
透過プロキシーの開始後に、 Caching Proxy サーバーを停止したい場合は、 ルートとして以下のコマンドを発行することも必要です。
ibmproxy -unload
Linux システムでは、 このコマンドでリダイレクト・ファイアウォール・ルールを除去します。サーバーを停止した後に、このコマンドを出さないでいると、ユーザーのマシンに宛先指定されたものでない要求を受信してしまうことになります。
このディレクティブは、キャッシュ・エージェントがどのプロキシー・サーバーを更新するかを指定するときに使用します。これは、キャッシュ・エージェントが稼働しているローカル・プロキシー・サーバー以外のプロキシー・サーバーをキャッシュ・エージェントが更新する必要がある場合に必要とされます。オプションで、ポートを指定することができます。
キャッシュ・エージェントは別のサーバー上のキャッシュを更新できますが、そのマシンからのキャッシュ・アクセス・ログを検索することはできません。したがって、UpdateProxy ディレクティブがローカル・ホスト以外のホストを指定している場合、LoadTopCached ディレクティブは無視されます。
UpdateProxy fully_qualified_host_name_of_proxy_server
UpdateProxy proxy15.ibm.com:1080
なし
このディレクティブは、サーバーがファイルにアクセスする前に変更する先のユーザー名または番号を指定するときに使用します。
このディレクティブを変更した場合には、サーバーを手動で停止してから再始動しなければ、変更が有効になりません。再始動しただけでは、サーバーは変更を認識しません。 (Caching Proxy の開始および停止を参照してください。)
UserId {ID_name | number}
AIX, Linux, Solaris: UserId nobody
HP-UX: UserId www
このディレクティブは、SSL バージョン 2 に使用可能な暗号仕様をリストします。
V2CipherSpecs specification
以下を任意に組み合わせたものが許容値となります。いずれも 2 回使用することはできません。
なし (デフォルトでは SSL は使用不可)
このディレクティブは、SSL バージョン 3 について使用可能な暗号仕様をリストします。
FIPSenable ディレクティブが「on」に設定されている場合、V3CipherSpecs ディレクティブは 無視されます。詳しくは、FIPSEnable - SSLV3 および TLS 用の Federal Information Processing Standard (FIPS) 承認済み暗号を使用可能にする を参照してください。
V3CipherSpecs specification
許容値として、以下の値があります。
なし (デフォルトでは SSL は使用不可)
このディレクティブは、SSL 証明書の有効期限切れ 30 日前の通知など、選ばれた Caching Proxy 報告書を受け取るための電子メール・アドレスを設定するために使用します。 Linux および UNIX システムでは、sendmail プロセスが実行されていなければなりません。 Windows システムの場合、sendmail プロセスは Caching Proxy 内に構築されるため、外部メール・サーバーは必要ありませんが、他にWebMasterSocksServer (Windows のみ) - sendmail ルーチン用に Socks サーバーを設定するおよびSMTPServer (Windows のみ) - sendmail ルーチン用に SMTP サーバーを設定するで説明する 2 つのディレクティブを設定しなければなりません。
WebMasterEMail webmastermailaddress
WebMasterEmail webmaster@computer.com
WebMasterEmail webmaster
このディレクティブは、Caching Proxy for Windows 内の内部 sendmail ルーチンによって使用される Socks サーバーを設定するために使用します。 WebMasterEMail - 選ばれたサーバー報告書を受け取るための電子メール・アドレスを設定するおよびSMTPServer (Windows のみ) - sendmail ルーチン用に SMTP サーバーを設定するで説明する 2 つのディレクティブも、このルーチンのために設定しなければなりません。
WebMasterSocksServer IP address or hostname of socks server
WebMasterSocksServer socks.mybox.com
なし
このディレクティブは、特定のファイル名を含んでいない要求に応答するためにサーバーが探索するウェルカム・ファイルの名前を指定するときに使用します。このディレクティブを構成ファイル内に複数回指定して、ウェルカム・ファイルのリストを作成することができます。
ファイル名またはディレクトリー名を含まない要求の場合、サーバーは、常にファイル・ルート・ディレクトリーを見て、Welcome ディレクティブに指定された名前と一致するファイルを探します。 一致するファイルが見つかると、そのファイルが要求側に戻されます。
ディレクトリー名を含むが、ファイル名は含まない要求の場合、AlwaysWelcome ディレクティブは、サーバーがディレクトリーで戻すべきウェルカム・ファイルを探すかどうかを指定します。デフォルトにより、AlwaysWelcome の値は On に設定されます。 つまり、サーバーは必ず要求されたディレクトリーを見て、Welcome ディレクティブに指定された名前に一致するファイルを探すということです。一致するファイルが見つかると、そのファイルが要求側に戻されます。
サーバーが、ディレクトリー内のファイルと Welcome ディレクティブに指定されたファイル名との間で一致するものを複数見つけた場合は、Welcome ディレクティブの順序によって、どのファイルが戻されるかが決まります。 サーバーは、構成ファイルの一番上に最も近い Welcome ディレクティブを使用します。
Welcome file_name [server_IP_address | host_name]
IP アドレス (例えば、240.146.167.72) を指定するか、またはホスト名 (例えば、hostA.bcd.com) を指定することができます。
このパラメーターはオプションです。このパラメーターを使用しないと、サーバーは、要求が入ってきた IP アドレスや URL のホスト名とは無関係に、このディレクティブをすべての要求に使用します。
ワイルドカード文字をサーバーの IP アドレスとして指定することはできません。
Welcome letsgo.html Welcome Welcome.html
Welcome CustomerA.html 0.67.106.79 Welcome CustomerB.html 0.83.100.45
Welcome CustomerA.html hostA.bcd.com Welcome CustomerB.html hostB.bcd.com
以下のデフォルトは、デフォルト構成で使用される順になっています。
Welcome Welcome.html Welcome welcome.html Welcome index.html Welcome Frntpage.html