目次
このマニュアルについて
第 1 章 iPlanet Web Server の基礎知識
第 2 章 iPlanet Web Server の管理
第 3 章 管理プリファレンスの設定
第 4 章 ユーザとグループの管理
第 5 章 サーバ セキュリティ
第 6 章 サーバ クラスタの管理
第 7 章 サーバのプリファレンスの設定
第 8 章 ログ ファイルの理解
第 9 章 SNMP によるサーバのモニタ
第 10 章 サーバの設定によるパフォーマンス チューニング
第 11 章 プログラムによるサーバの拡張
第 12 章 コンフィグレーション スタイルの操作
第 13 章 サーバのコンテンツ管理
第 14 章 サーバへのアクセスの制御
第 15 章 Web パブリッシングの設定
第 16 章 検索機能の使用
付録 A HTTP (HyperText Transfer Protocol)
付録 B ACL ファイルのシンタックス
付録 C 国際化 iPlanet Web Server
付録 D Microsoft FrontPage のサーバ拡張機能
付録 E iPlanet Web Server
用語集
索引
戻る 次へ 目次 索引 ブックシェルフ


第 7 章 サーバのプリファレンスの設定

この章では、iPlanet Web Server のプリファレンスの設定方法について説明します。

この章には次の節があります。


サーバの起動と停止
インストールしたサーバは、HTTP リクエストのリッスンと受け入れを実行しながら、連続動作します。サーバのステータスは、「Server On/Off」ページに表示されます。 サーバの起動と停止には、次の方法があります。

  • 「Server On/Off」ページで、[Server On] または [Server Off]をクリックする。
  • コントロール パネルの [サービス] ウィンドウを使う (Windows NT)。
  • start のスクリプトを使う。このスクリプトを init と併用する場合、/etc/inittab に起動コマンド http:2:respawn:server_root/type-identifier/start -start -i をインクルードする必要があります (Unix/Linux)。
  • stop のスクリプトを使う。この場合、サーバは完全にシャットダウンし、再起動するまでサービスは停止します。 etc/inittab ファイルを使って、サーバが自動的に再起動するよう設定した場合は (respawn コマンドを使用)、 サーバをシャットダウンする前に、etc/inittab 内の Web サーバに関連する行を削除する必要があります。これを実行しないと、サーバは自動的に再起動します (Unix/Linux)。
サーバをシャットダウンした後、サーバが完全に停止し、サーバのステータスがオフになるまで数秒かかる場合があります。

マシンがクラッシュしたり電源を切断されたりすると、サーバが停止し、処理中のリクエストが失われる可能性があります。

終了のタイムアウトの設定
サーバがオフの状態になると、新規コネクションの受け入れを停止し、未処理のコネクションが完了するのを待ちます。タイムアウトまでのサーバの待ち時間は、 magnus.conf ファイルを使って設定します。デフォルトは3 秒です。この値を変更するには、次の行を magnus.conf ファイルに追加します。

ここでは、seconds がタイムアウトまでのサーバの待ち時間 (秒単位) を表します。

この値を設定して、コネクションが完了するまでのサーバの待ち時間を延長することができます。ただし、サーバは応答のないクライアントに接続された状態になっている場合が多いため、終了のタイムアウトの時間を延長すると、サーバのシャットダウンにかかる時間が長くなる場合があります。

サーバの再起動 (Unix/Linux)
サーバを再起動するには、次の方法があります。

/etc/rc.local ファイルや /etc/inittab ファイルは、インストール用スクリプトを使って編集することができないため、テキスト エディタを使って編集する必要があります。これらのファイルの編集方法については、システム管理者に相談するか、システムのマニュアルを参照してください。

通常、SSL 対応サーバの起動にはパスワードが必要なため、これらのファイルを使って起動することはできません。この場合、パスワードを簡単なテキスト形式でファイルに保存すれば自動的に SSL 対応サーバを起動することができますが、この方法はお勧めしません。

警告 SSL 対応サーバのパスワードをテキスト形式でサーバの起動スクリプトに保 存することは、セキュリティ上問題があります。 ファイルにアクセスできれ ば、パスワードを入手することができるためです。テキスト形式でパスワー ドを保存する前に、セキュリティ上のリスクを考慮する必要があります。

サーバの起動スクリプト、キー ペア ファイル、およびキー パスワードは、オーナだけが読み込みおよび書き込みアクセスを行えるルートに保存します (ルート ユーザ以外のユーザがサーバをインストールした場合は、ユーザ アカウントを使います) 。

セキュリティ上の問題がない場合、次の手順に従って、SSL 対応サーバを自動的に起動します。

  1. テキスト エディタを使って、server_root/https-server-id にある起動ファイルを開きます。
  2. スクリプトの上から 10 行目に、次の行を追加します。
Inittab による再起動 (Unix/Linux)
inittab を使ってサーバを再起動するには、次のテキストを/etc/inittab ファイルの行に追加します。

ここでは、server_root にサーバをインストールしたディレクトリを、type-identifier にサーバのディレクトリを入力します。

-i オプションは、サーバがバックグラウンド処理モードに切り替わるのを防ぎます。

サーバを停止する前に、必ずこの行を削除してください。

システム RC スクリプトによる再起動 (Unix/Linux)
/etc/rc.local、またはこれに相当するスクリプトを使う場合、次の行を/etc/rc.local に追加します。

ここでは、server_root に、サーバをインストールしたディレクトリを入力します。

手作業によるサーバの再起動 (Unix/Linux)
コマンド ラインを使ってサーバを再起動するには、サーバのポート番号が 1024 より小さい場合はルート ユーザとしてログ インし、それ以外の場合は、ルート ユーザとして、またはサーバのユーザ アカウントを使ってログ インします。コマンドラインのプロンプトで次の行を入力して、Enter キーを押します。

ここでは、server_root にサーバをインストールしたディレクトリを入力します。

また、オプションで行の最後に -p-i パラメータを追加することができます。

-p オプションを使うと、特定のポート番号のサーバを起動します。 これは、magnus.conf ファイルの設定をオーバーライドします。

-i オプションを使うと、サーバを inittab モードで起動します。その結果、サーバのプロセスが中断またはクラッシュした場合、inittab が自動的にサーバを再起動します。また、このオプションは、サーバがバックグラウンド処理モードに切り替わるのを防ぎます。

ノート サーバの動作中は、start コマンドは無効です。start コマンドは、サーバを停止してから使います。 また、サーバの起動に失敗した場合、再起動する前にプロセスを中断する必要があります。

手作業によるサーバの停止 (Unix/Linux)
etc/inittab ファイルを使ってサーバを再起動した場合、サーバを停止する前に、サーバを起動する行を/etc/inittab ファイルから削除して、「kill -1 1 」と入力します。そうしないと、サーバは停止後に自動的に再起動します。

サーバを手作業で停止するには、サーバを起動した方法に応じて、ルート ユーザとして、またはサーバのユーザ アカウントを使ってログインし 、コマンド ラインに次のように入力します。

サーバの再起動 (Windows NT)
サーバの再起動には、次の方法があります。

  • [サービス] コントロール パネルを使ってサーバを再起動する。
  • [サービス] コントロール パネルを使ってオペレーティング システムを設定し、マシンを再起動するたびにサーバまたは Administration Server を再起動する。
Windows NT 3.51 では、次の手順を実行します。

  1. [メイン] グループの [コントロールパネル] アイコンをダブルクリックします。
  2. [ サービス] アイコンをダブルクリックします。
  3. サービスのリストをスクロールし、サーバに適したサービスを選択します。
  4. [自動] チェック ボックスをオンにして、コンピュータが起動または再起動するたびにサーバを自動的に起動するように設定します。
  5. [OK] をクリックします。
Windows NT 4.0 では、次の手順を実行します。

  1. [スタート] メニューから、[設定] を選択し、次に [コントロール パネル] を選択します。
  2. [サービス] アイコンをダブルクリックします。
  3. サービスのリストをスクロールして、サーバに適したサービスを選択します。
  4. [自動] チェック ボックスをオンにして、コンピュータが起動または再起動するたびにサーバを自動的に起動するように設定します。
  5. [OK] をクリックします。

ノート [サービス] ダイアログ ボックスを使って、サーバが使うアカウントを変更することもできます。サーバが使うアカウントの変更については、サーバのユーザ アカウントの変更(Windows NT)を参照してく ださい。

通常、SSL 対応サーバの起動にはパスワードが必要なため、自動的に起動することはできません。パスワードを簡単なテキスト形式でテキスト ファイルに保存すれば、パスワードを入力しないでサーバを起動することができますが、この方法はお勧めしません。

警告 SSL 対応サーバのパスワードをテキスト ファイル形式でシステムに保存すると、セキュリティ上、問題があります。 セキュリティを捨てて利便性を採ることになります。ファイルにアクセスできれば、サーバのパスワードを入手できるためです。SSL 対応サーバのパスワードをテキスト形式でシステムに保存する前に、セキュリティ上の問題を考慮してください。

セキュリティ上の問題がない場合、次の手順に従って、SSL 対応サーバを自動的に起動します。

  1. server_root\https-server_id\config ディレクトリに、ノートパッドなどのテキスト エディタで、 password.txt という名前の新規テキスト ファイルを作成します。デフォルトの Web サーバのインストールでは、password.txt はC:\Netscape\server4\https-server_id\config ディレクトリに保存されます。
  2. 1 行目に秘密キー パスワードを入力します。パスワードを入力した後に、改行しないよう注意します。このファイルには、パスワード以外は入力しません。

警告 NTFS ファイル システムを使っている場合、アクセスを制限して、password.txt ファイルがあるディレクトリを保護する必要があります。このファイルを使わない場合も同様です。このディレクトリの読み込み/書き込みパーミッションは、 管理サーバ ユーザとWeb サーバ ユーザにのみ与えられます。このディレクトリを保護することによって、不正な password.txt ファイルの作成を防ぐことができます。

FAT ファイル システムを使っている場合、アクセスを制限してディレクトリやファイルを保護することはできません。

Automatic Restart Utility の使用 (Windows NT)
サーバがクラッシュすると、サーバ モニタ ユーティリティを使って自動的に再起動します。デバッグ用ツールがインストールされているシステムでは、サーバがクラッシュすると、デバッグ情報の入ったダイアログ ボックスが表示されます。タイムアウトを非常に大きい値に設定して、サーバの自動起動機能を無効にすると、サーバのプラグイン API プログラム (NSAPI プログラムなど) のデバッグが促進されます。また、レジストリ エディタを使って、デバッグのダイアログ ボックスをオフにすることもできます。

タイム インターバルの変更 (Windows NT)

サーバが起動してから自動的に再起動するまでのタイム インターバルを変更するには、次の手順を実行します。

  1. レジストリ エディタを起動します。
  2. [レジストリ エディタ] ウィンドウの左側の、HKEY_LOCAL_MACHINE\ SOFTWARE\Netscape\ にあるサーバのキーを選択します。
  3. [編集] メニューから [値の追加] を選択します。[キーの追加] ダイアログ ボックスが表示されます。
  4. [値の名前] フィールドに、「MortalityTimeSecs」 と入力します。
  5. [データの種類] プルダウン リストから、REG_DWORD を選択します。
  6. [OK] をクリックすると、[DWORD エディタ] ダイアログ ボックスが表示されます。
  7. サーバの起動から自動的に再起動するまでの時間として、タイム インターバル (秒単位) を入力します。
  8. 前の手順で入力した値の フォーマット(2 進数、10 進数、16 進数) をクリックします。
  9. [OK] をクリックします。
デバッグのダイアログ ボックスをオフにする(Windows NT)

システムのデバッグ設定を変更したアプリケーション (コンパイラなど) をインストールした状態でサーバがクラッシュすると、システム生成アプリケーション エラーのダイアログが表示される場合があります。この場合、[OK] をクリックするまで、サーバは再起動されません。

サーバがクラッシュした後に、デバッグのダイアログ ボックスが表示されないようにするには、次の手順を実行します。

  1. レジストリ エディタを起動します。
  2. レジストリ ウィンドウの左側の、HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows NT\CurrentVersion にある AeDebugキーを選択します。
  3. ウィンドウの右側にある、[自動] の値をダブルクリックします。
  4. 文字列値を 1 に変更します。

サーバの設定の表示
サーバの動作を確認し、サーバの技術的な設定とコンテンツの設定を表示することができます。技術的な設定は、magnus.conf ファイルに、コンテンツの設定は obj.conf ファイルにそれぞれ保存されています。これらのファイルは、サーバのルートの、https-server_id\config ディレクトリにあります。magnus.conf ファイルとobj.conf ファイルの詳細については、『NSAPI Programmer's Guide for iPlanet Web Server』を参照してください。

サーバの設定を表示する方法については、サーバ マネージャの「View Server Settings」ページを参照してください。

「View Server Settings」ページに表示されるコンテンツの設定は、サーバの設定方法によって異なります。一般的なサーバのコンテンツの設定には、サーバのドキュメント ディレクトリ、索引ファイルの名前、アクセス ログの名前と場所、デフォルトのMIME タイプが含まれます。


スレッド プールの追加と使用
一定の数のスレッドを特定のサービスに割り当てるには、スレッド プールを使います。たとえば、サーバサイド JavaScript アプリケーションのために特別にスレッド プールをセットアップすることができます。サーバサイド JavaScript スレッド プールを追加する過程でサーバサイド JavaScript アプリケーションに割り当てるスレッドの最大数を指定します。これらのアプリケーションは、割り当てられた数より多いスレッドを処理することができません。

スレッド プールは、スレッドセーフでないプラグインを実行するときにも使います。スレッドの最大数を 1 に設定した状態でプールを定義すると、1 つのリクエストだけが指定したサービス機能に許容されます。

スレッド プールを追加するときに指定する情報には、スレッドの最小数および最大数、スタック サイズ、およびキュー サイズがあります。

ネイティブ スレッド プールと一般スレッド プール (Windows NT)
Windows NT では 2 種類のスレッド プール、すなわちネイティブ スレッド プール (NativePool) と追加の一般スレッド プールを使うことができます。

Netscape Enterprise Server 3.6 との後方互換性を維持するために、デフォルトではネイティブ スレッド プールが定義されます。ネイティブ スレッド プールを編集するには、サーバ マネージャの「Native Thread Pool」ページ (NT)を参照してください。

一般スレッド プールは、目的に応じて必要な数だけ作成することができます。一般スレッド プールを作成するには、サーバ マネージャの「Generic Thread Pools」ページ (NT)を参照してください。

スレッド プール (Unix/Linux)
Unix/Linux ではスレッドは常に OS によってスケジュールされるため (ユーザがスケジュールするのとは対照的に)、Unix/Linux ユーザは NativePool を使う必要がなく、その設定を編集するためのサーバ マネージャのページはありません。ただし、Unix/Linux ユーザはスレッド プールを作成することができます。スレッド プールを作成するには、サーバ マネージャの「Thread Pools」ページ (Unix/Linux)を参照してください。

スレッド プールの編集
スレッド プールを追加した後、サーバ マネージャを使ってスレッド プールの設定値 (スレッドの最小数、最大数など) を変更することはできません。obj.conf 内でスレッド プールの設定を編集する必要があります。

スレッド プールは obj.conf 内で次のように表示されます。

スレッド プールを変更するには、パラメータ MinThreadsMaxThreadsQueueSize、および StackSize を使います。

Windows NT ユーザは常に、サーバ マネージャを使ってネイティブ プールの設定を編集することができます。

スレッド プールの使用
スレッド プールをセットアップした後、特定のサービスのためのスレッド プールとして指定して使います。たとえば、サーバサイド JavaScript (SSJS) アプリケーションに使うスレッド プールをセットアップする場合 (それによって、 SSJS アプリケーションと分離に使うスレッドの数を制限することができます)、サーバ マネージャの「Activate Server-Side JavaScript」ページを使ってサーバサイド JavaScript スレッド プールとして指定することができます。

スレッド プールを設定するには、Administration Server の [Preferences] タブに進み、[Thread Pool] を選択します。スレッド プールを設定すると、そのプール内で実行するSSJS を設定するために使用可能なスレッドプールが [Javascript Thread Pool] リストに表示されます。

obj.conf 内のload-module 関数のプール パラメータを使ってスレッド プールを指定することもできます。

さらに、その NSAPI 関数だけがユーザ指定のプール上で実行されるように、どの NSAPI 関数上でも pool パラメータを使うことができます。


ネットワーク設定
サーバのユーザ、名前、ポート、バインド アドレス、MTA ホストなどの、サーバのネットワーク設定を変更することができます。

サーバの場所の変更 (Unix/Linux)
何らかの理由により、サーバを他のディレクトリに移動する場合、 サーバが参照する場所を変更して、バイナリ ファイルの場所を明確にする必要があります。 場所の変更後は、必ずサーバをシャットダウンして、サーバ ファイルとサブ ディレクトリを新しい場所にコピーしてください。

サーバの場所を変更するには、Administration Server の「Network Settings」ページの [Server Location] フィールドを編集します。

サーバのユーザ アカウントの変更 (Unix/Linux)
サーバのユーザは、サーバが使う Unix/Linux のユーザ アカウントを指定します。すべてのサーバ プロセスで、指定されたユーザ アカウントを使います。

選択したポート番号が1024 より大きく、 ルート ユーザとしてログオンしていない場合、サーバ ユーザを指定する必要はありません (ルート ユーザとしてログオンしない場合でも、サーバを起動することができます) 。ここでユーザ アカウントを指定しないと、サーバは起動時のユーザ アカウントを使って起動します。サーバを起動するときは、ユーザ アカウントが正しいかどうか注意してください。

ノート システム上で新規ユーザを作成する方法については、システム管理者に相談するか、ご使用のシステムのマニュアルを参照してください。

ルート ユーザとしてサーバを起動した場合でも、常にルート ユーザとして サーバを動作することは避けてください。サーバによるシステム リソースに 対するアクセスを制限して、権限を持たないユーザとしてサーバを動作しま す。サーバ ユーザとして入力するユーザ名は、通常の Unix/Linux ユーザ アカ ウントとして既に存在するものを使います。起動後は、このユーザとしてサー バを動作します。

新規ユーザ アカウントを作成しない場合、nobody のユーザを選択するか、同じホスト上のHTTP サーバで使われているアカウントを選択します。ただし、システムによっては、nobody のユーザはファイルを所有できても、プログラムを実行できない場合もあります。

サーバのユーザ アカウントを変更するには、Administration Server の「Network Settings」ページの [Server User] フィールドを編集します。

サーバのユーザ アカウントの変更(Windows NT)
LocalSystem 以外の特定のユーザ アカウントを使って、サーバのシステム機能を制限したり、可能にしたりすることができます。たとえば、他のマシンからファイルをマウントできるユーザ アカウントを使うことができます。

Web サーバのインストール後にユーザ アカウントを変更するには、次の手順を実行します。

  1. Windows NT のユーザ マネージャを使ってユーザを作成します。ユーザは "Log in as a service"権限を持つ必要があります。
  2. サーバを停止します。
  3. Windows のコントロール パネルから、[サービス] を選択します。
  4. [iPlanet Web Server] サービスを選択します。
  5. [サービス] ポップアップ メニューの[ログオン ユーザ名] で、[このアカウントをログオン] ラジオ ボタンをクリックします。
  6. Web サーバで使うユーザ アカウントを入力します。
  7. アカウントのパスワードを入力します。確認のため、同じパスワードをもう一度入力します。
  8. [OK] をクリックします。
  9. [サービス] プログラム、または「Server Administration」ページを使って、サーバを再起動します。
サーバ名の変更
サーバ名は、ご使用のサーバ マシンの完全なホスト名です。クライアントがサーバにアクセスするとき、このサーバ名を使います。サーバ名のフォーマットは machinename.yourdomain.domain です。たとえば、完全なドメイン名が iplanet.com であれば、www.iplanet.com という名前を使ってサーバをインストールすることができます。

システム管理者によってサーバのDNS エイリアスがセットアップされている場合、このエイリアスを Administration Server の「Network Settings」ページで使います。DNS エイリアスが設定されていない場合は、マシンの名前とドメイン名を組み合わせて、完全なホスト名を作成します。

サーバ名を変更するには、Administration Server の「Network Settings」ページの [Server Name] フィールドを編集します。

サーバ ポート番号の変更
サーバ ポート番号を使って、サーバがリッスンする TCP ポートを指定します。選択するポート番号はユーザに影響を与えるため、標準以外のポートを使うと、サーバにアクセスするすべてのユーザがURL でサーバ名とポート番号を指定する必要があります。たとえば、ポート番号が 8090 の場合、ユーザは次のような URL を指定します。

最も一般的なネットワーク アクセスが可能なサービスで使われているポート 番号は、 /etc/services ファイル (Unix/Linux) 、または
\WINNT\System32\ drivers\etc\services ファイル (Windows NT)  に保存されています。

ポート番号には、1 〜65535 の任意の番号を使うことができますが、保護されていない標準の Web サーバのポート番号は 80 、保護されている標準の Web サーバのポート番号は 443 です。

Unix/Linux では、サーバのインストール時や起動時にルート ユーザとしてログインしない場合、1024 より大きいポート番号を使う必要があります。

サーバ ポート番号を変更するには、Administration Server の「Network Settings」ページの [Server Port] フィールドを編集します。

サーバのバインド アドレスの変更
サーバ マシンを 2 つのURL に応答するように設定することができます。たとえば、1 台のマシンで、http://www.iplanet.com/
http://www.mozilla.com/ に応答することができます。

複数の IP アドレスをリッスンするようにセットアップしたシステムでこの機能を使う場合、[Network Settings] ウィンドウの [Bind To Address] フィールドを使って、ホスト名に関連付けられた IP アドレスを持つサーバを指定します。

サーバのバインド アドレスを変更するには、Administration Server の「Network Settings」ページの [Bind To Address] フィールドを編集します。

サーバの MTA ホストの変更
サーバの MTA (メッセージ転送エージェント) ホストを変更することができます。このエージェントの電子メール機能を使うには、有効な MTA ホストを入力する必要があります。

MTA ホストを変更するには、Administration Server の「Network Settings」ページの [MTA host] フィールドを編集します。


エラー レスポンスのカスタマイズ
独自のエラー レスポンスを指定して、サーバのエラー発生時に、クライアントに詳細なメッセージを送信することができます。送信するファイルを指定する方法と、実行する CGI プログラムを指定する方法があります。

特定のディレクトリのエラー発生に対するサーバの動作を変更すると、デフォルトのファイルを送信する代わりに、カスタム エラー レスポンスを送信することができます。たとえば、アクセス コントロールによって保護されているサーバの一部にクライアントが繰り返し接続を試みた場合、アカウントの取得方法についての説明を伴うエラー ファイルを返すことができます。

カスタム エラー レスポンスを有効にする前に、エラーの発生時に送信する HTML ファイルか、実行する CGI プログラムを作成する必要があります。ファイルの作成後、Administration Server の「Network Settings」ページを使って、エラー レスポンスを有効にします。


ダイナミック コンフィグレーション ファイルの操作
サーバのすべてのコンテンツを 1 人で管理することはまれです。そのため、設定オプションのサブセットに対するアクセス権をエンド ユーザに与え、必要に応じてエンド ユーザが部分的に設定できるようにします。ただし、エンド ユーザには、iPlanet Web Server に対するアクセス権は与えません。設定オプションのサブセットは、ダイナミック コンフィグレーション ファイルに保存されています。iPlanet Web Server は、.htaccess ファイルと .nsconfig ファイルの 2 種類のダイナミック コンフィグレーション ファイルをサポートしています。.nsconfig ファイルは、iPlanet Web Server を使って有効にすることができますが、.htaccess ファイルは手作業で有効にする必要があります。

ノート ダイナミック コンフィグレーション ファイルでは、LDAP および Netscape 3.0 ユーザ データベースはサポートされていません。 LDAP を使っている場合、ダイナミック コンフィグレーション ファイルを使うことはできません。.htaccess ファイルを使うには、NCSA スタイルのユーザ データベースが必要です。.nsconfig ファイルを使うには、NCSA スタイルのユーザ データベースか、Enterprise 2.x DBM フォーマットのユーザ データベースが必要です。ユーザ データベースの詳細については、『Managing Servers with Netscape Console』を参照してください。

現在使っている .nsconfig ファイルは、そのまま使うことができますが、 iPlanet Web Server には .nsconfig ファイルを .htaccess ファイルに変換するユーティリティがあります。

.htaccess ファイルの使用
.htaccess をサポートするファイルは、 server_root/plugins/htaccess ディレクトリにあります。これらのファイルには、 .htaccess ファイルの使用を有効にするプラグインや、.nsconfig ファイルを .htaccess ファイルに変換するスクリプトが含まれています。

.htaccess チェックの実行
.htaccess ファイルを使うには、まずサーバの obj.conf ファイルを変更して、プラグインの読み込み、初期化、および実行を行います。obj.conf ファイルの一番上に、他の Init ディレクティブに続いて次の行を追加します。

Unix/Linux の場合

Windows NT の場合

これらの行は、サーバの起動時に、モジュールを読み込んで初期化します。 server_root は、サーバ ルートのパスです。

サーバを使って管理しているすべてのディレクトリの .htaccess ファイルの処理を実行するには、 次のPathCheck ディレクティブを追加します。

追加先は、次の区切り文字列のある、デフォルトのサーバ オブジェクトです。

一般的に、.htaccess ファイルの処理を実行するディレクティブは、オブジェクトの最後のPathCheck ディレクティブです。

特定のサーバ ディレクトリの .htaccess ファイルの処理を実行するには、 PathCheck ディレクティブを、obj.conf ファイルの対応するオブジェクト定義に配置します。

.htaccess ファイルに .htaccess 以外の名前を付けるには、次のフォーマットを使って、PathCheck ディレクティブでファイル名を指定します。

filename に、実際に使っているファイル名を入力します。

コンフィグレーション ファイルの編集後、サーバを再起動します。[Apply] ボタンをクリックして、iPlanet Web Server のコンフィグレーション ファイルの変更を適用します。サーバへの以降のアクセスは、指定したディレクトリの .htaccess のアクセス コントロールによって制御されます。

.htaccess ファイルの書き込みアクセスを制限するには、ファイルのコンフィグレーション スタイルを作成して、このスタイルにアクセス コントロールを適用します。詳細については、コンフィグレーション スタイルの操作サーバへのアクセスの制限を参照してください。

既存の .nsconfig ファイルを .htaccess ファイルに変換する

iPlanet Web Server では、既存の .nsconfig ファイルを .htaccess ファイルに変換するスクリプトを使うことができます。ファイルを変換するには、コマンド プロンプトを使って、システム上のPerl、スクリプト、 obj.conf ファイルへのパスをそれぞれ入力します。次のスクリプトは入力の例ですが、 実際に入力するときはスクリプト全体を 1 行に入力します。

このスクリプトによって、すべての .nsconfig ファイルが .htaccess ファイルに変換されますが、.nsconfig ファイルは削除されません。

サポート可能な .htaccess ディレクティブ

このリリースでは、次の .htaccess ディレクティブがサポートされています。

  • AuthName

  • AuthGroupFile
オプションとして、非常に多くのユーザ グループの処理を支援するgroups-with-users があります。グループに属するユーザの人数が多い場合は、次の手順を実行します。

  1. ユーザのファイル フォーマットを変更して、ユーザが属するすべてのグループをリストします。
  2. AuthGroupFile ディレクティブを変更して、AuthUserFile と同じファイルに設定します。
また、次の手順を実行することも可能です。

  1. AuthGroupFile のディレクティブを完全に削除します。
  2. obj.confファイルの 'Init fn=htaccess-init' の行に次のオプションを追加します。
.htaccess ファイルの例

次の例は、.htaccess ファイルを示しています。

.nsconfig ファイルの使用
.nsconfig ファイルを使って、エンド ユーザにCGI やパース HTML の使用許可を与えずに、エンド ユーザによるアクセス コントロールや、エラー メッセージのカスタマイズを許可することができます。これらのダイナミック コンフィグレーション ファイルのフォーマットと機能については、.nsconfig ファイルの作成を参照してください。

ダイナミック コンフィグレーションが有効なリソースが要求されると、サーバは該当するリソースの 1 つ以上のディレクトリのコンフィグレーション ファイルを検索する必要があります。この検索は、サーバのパフォーマンスの大きな負担となる場合があるので、柔軟性を設定することによって、効率性コストの調整を図ります。

サーバにベース ディレクトリを指定することもできますが、この場合、サーバはコンフィグレーション ファイルの検索を filesystem ディレクトリから開始します。また、ベース ディレクトリを指定しない場合、サーバは URL からベース ディレクトリを推測します。つまり、要求された URL がドキュメント ルートのファイルを指すものであれば、サーバはドキュメント ルートから検索を開始します。

また、ベース ディレクトリ内で検索するコンフィグレーション ファイルの名前も指定します。

すべてのベース ディレクトリのサブディレクトリの設定情報を、ベース ディレクトリのコンフィグレーション ファイルにまとめると、サブディレクトリのコンフィグレーション ファイルを検索する必要がなくなるので、サーバの効率が向上します。

ただし、サブディレクトリの検索が必要な場合、サーバはトップレベルのディレクトリから .nsconfig ファイルの検索を開始し、参照したリソースのあるディレクトリが見つかるまでサブディレクトリの検索を続けます。.nsconfig ファイルは、検索された順番に処理されます。トップレベルのファイルのユーザによるアクセスが制限されている場合は、これより低いレベルのファイルへのアクセスが可能であっても、サーバがユーザにアクセス許可を与えることはありません。

サーバは、すべての制限を、ファイルの中にある IP アドレスと DNS エントリ (RestrictAccess のディレクティブ) に基づいて適用します。IP アドレスまたは DNS エントリを理由にユーザのアクセスを拒否するファイルが見つかると、サーバはファイルの処理を中止します。サーバは、ユーザ名 (RequireAuth のディレクティブ) を基にして制限情報を収集し、IP アドレスまたは DNS エントリを理由に要求が拒否された場合以外は、最後に制限を適用します。

たとえば、URL 変換から推測したベース ディレクトリを選択し、ファイル名を .nsconfig にして、サブディレクトリの検索を選択した場合は、次の検索が実行されます。

C:\Netscape\server4\docs\icons\gfx\logo.gif の filesystem パスをユーザが要求すると、サーバは C:\Netscape\server4\docs\.nsconfig を検索する代わりに、すべてのサブディレクトリを検索します。

ここでは、ダイナミック コンフィグレーションが有効なディレクトリで無効にしたいファイル タイプの、ワイルドカード パターンを入力することもできます。 たとえば、CGI プログラムとパース HTML を無効にするには、 *(cgi|parsed-html) と入力します。

.nsconfig ファイルを 設定するには、次の手順を実行します。

  1. サーバ マネージャで、[Server Preferences] を選択します。
  2. [Dynamic Configuration Files] リンクをクリックします。
  3. [Resource Picker]を使って、リソースを選択します。
  4. ベース ディレクトリに URL を使うか、ディレクトリを指定するかを選択します。
  5. ファイル名を入力します。
  6. 検索をベース ディレクトリに限定するかどうかを選択します。
  7. 無効化されているタイプを入力します。
  8. [OK] をクリックします。
  9. [Save and Apply] をクリックします。
.nsconfig ファイルの作成

.nsconfig ファイルは、サーバを制御するディレクティブのセットで構成されています。これらのディレクティブは、Files のディレクティブの間にあります。Files のディレクティブは、ディレクティブの適用の対象となるコンフィグレーション ファイルのディレクトリ内のファイルをサーバに通知します。その例を次に示します。

PATTERN1PATTERN2 は、ディレクティブの適用の対象となる filesystem パスをサーバに対して指定するワイルドカード パターンです。たとえば、 *を使うと、すべての filesystem のパス名にディレクティブが適用されます。ここでは、すべてのパターンに、コンフィグレーション ファイルを含むディレクトリ名のプレフィックスを付けて、ディレクティブの適用の対象をサブディレクトリに限定します。.nsconfig ファイルには、任意の数のFiles ディレクティブのセットを入れることができます。

このファイルの行は、空白にしておくこともできます。 # で始まる行は、コメントとして扱われます。また、1 行に入力できる文字数は、1024 文字に限定されています。

Windows NT では、すべてのパスに、バックスラッシュ (\) の代わりに普通のスラッシュ (/) を使います。バックスラッシュを使うと、「パスが見つかりません」というエラー メッセージが表示されます。

パラメータの数は、ディレクティブによってさまざまですが、すべてのパラメータには小文字を使います。Files のディレクティブは次のとおりです。

.nsconfig Fileの例

次に、 .nsconfig ファイルの例を紹介します。

<Files *
ErrorFile reason="Unauthorized" code="401" path="/errors/unauthorized.html">
ErrorFile reason="Forbidden" code="403" path="/errors/forbidden.html"
ErrorFile reason="Not Found" code="404" path="/errors/notfound.html"
ErrorFile reason="Server Error" code="500" path="/errors/server-error.html"
RestrictAccess method="(GET|HEAD|POST)" type="allow" ip="*"
RestrictAccess method="(GET|HEAD|POST)" type="deny" ip="198.95.251.30" return-code="404"
</Files
<Files *.gif
AddType exp=*.gif type=application/octet-stream
</Files
<Files *.txt
RequireAuth dbm="server_root/authdb/default" realm=Text userpat="user*"
</Files


シンボリック リンクの制御 (Unix/Linux)
サーバの filesystem リンクの使用を制限することができます。filesystem リンクは、他のディレクトリ、または filesystem に保存されたファイルに対する参照です。この参照によって、カレント ディレクトリにあるファイルと同じように、リモート ファイルに簡単にアクセスすることができます。filesystem リンクには、次の 2 種類があります。

  • ハード リンク ハード リンクは、同じデータ ブロックのセットを指す 2 つのファイル名で、元のファイルとリンクは同一であるため、ハード リンクに異なるfilesystem を使うことはできません。
  • シンボリック (ソフト) リンク シンボリック リンクは、2 つのファイルで構成されており、元のファイルにはデータが保存され、もう 1 つのファイルは元のファイルを指します。シンボリック リンクは、ハード リンクよりも柔軟性が高く、異なった filesystem 上で使うことができ、ディレクトリにリンクすることもできます。
ハード リンクとシンボリック リンクの詳細については、ご使用の Unix/Linux システムのマニュアルを参照してください。

filesystem リンクは、プライマリ ドキュメント ディレクトリの外部で、ドキュメントのポインタを作成するための簡単な方法で、誰でも作成することができます。そのため、機密ファイル (極秘ドキュメントやシステム パスワードのファイルなど) のポインタが作成される懸念もあります

シンボリック リンクを制限するには、サーバ マネージャの「Limit Symbolic Links」ページ (Unix/Linux)を使います。


ウォッチドッグ (uxwdog) プロセスの使用 (Unix/Linux)
uxwdog プロセスは、Enterprise Server 3.01 で導入された、Web サーバのウォッチドッグ プロセスの名前です。Enterprise Server 3.01 以前のリリースでは、起動時にサーバのコピーが作成され、親サーバのプロセスが子サーバのウォッチドッグとして機能していました。 Enterprise Server 2.x では、サーバの再起動時に、親サーバのプロセス (ns-httpd) が子サーバの ns-httpd プロセスを終了した後、子プロセスが再度作成されました。この場合、保護されているサーバのキー ファイルのパスワードが親プロセスによってそのまま保管されたため、サーバの再起動時にサーバの管理者がパスワードを再入力する必要がないという利点がありました。

ところが、Enterprise Server 3.0 では、多くのサブシステムがサーバに追加されたため、すべてのサブシステムを確実に初期化する最良の方法として、再起動時にはサーバを完全に停止し、最初から起動すべきであるとの結論に至りました。しかし、この方法にはいくつかの欠点があることが判明しました。まず、再起動時に、保護されているサーバのキー ファイルのパスワードを再入力する必要が生じました。ログのローテーションは、サーバの再起動オペレーションに依存するため、ログの自動ローテーションが有効になっている保護されたサーバで、特に問題になりました。さらに、サーバの設定を変更するたびに、サーバを完全に停止して、起動する必要が生じました。

uxwdog の基本的な考えは、サーバの再起動オペレーションの実行時に、新規のサーバ プロセスを開始する十分なステート情報を含む、完全に自動化されたライトウェイト プロセスを提供することです。 このステートは、保護されたサーバの起動に必要なパスワードまたは PIN と、サーバがリッスンするソケットのオープン ファイル ディスクリプタによって構成されます。ソケットのファイル ディスクリプタには、権限 TCP ポートのためのものが含まれている可能性があるため、このディスクリプタは不可欠です。このようなTCP ポートのバインドには、プロセスをルート ユーザとして実行する必要があり、ポート 80 がその一例です。この場合、通常 Administration Server はルートとして動作して、uxwdog を起動します。または、ルートとしてログインしている管理者が、サーバの start スクリプトを実行します。uxwdog がサーバの listen ポートをバインドすると、 uid をサーバの uid に変更し (多くの場合 nobody) 、この uid を使ってサーバ プロセスを開始します。

その結果、NSAPI の初期化ディレクティブが、常にサーバの uid を使って動作します。これは、Enterprise Server 3.0 以前のリリースでは、ルートとして動作することが可能だったものです。そのため、サーバのアップグレードのとき、プラグインの初期化機能によって、初期化の実行中にファイルが作成されるという問題が発生しました。旧バージョンのサーバでは、 ルートがこのファイルのオーナとなり、Enterprise 3.01 以上のバージョンをインストールするときは、移行したファイルのオーナシップや保護を変更する必要がありました。

uxwdog は、サーバがリッスンするポートを決定するために、 magnus.conf ファイルと obj.conf ファイルを読み込む必要があります。この読み込みは、サーバを再起動するたびに実行され、ポート番号が変更されていないことを確認します。ポート番号が変更された場合は、再起動のオペレーションは実行されず、uxwdog が終了し、サーバを手作業で起動する必要があります。これは、セキュリティがオンになった場合と、サーバの uid または PidLog のファイル名が変更された場合も同様です。

restartstop のスクリプトは、uxwdogSIGHUPSIGTERM をそれぞれ送信します。この場合、uxwdog は、SIGTERMns-httpd プロセスに送信してサーバをシャットダウンします。再起動のオペレーションでは、uxwdog は新規のサーバ プロセスを作成して、listen ポートのファイル ディスクリプタと、保存されたパスワードまたは PIN をこれに渡します。

サーバのウォッチドッグ プロセスのデフォルトによって、サーバのプロセスが予期せず終了した場合は、サーバが自動的に再起動します。また、この場合、元のデフォルト設定に戻して、ウォッチドッグ プロセスを終了することもできます。元のデフォルト設定に戻すには、次のようにサーバの起動スクリプトの最初に、 UXWDOG_NO_AUTOSTART の環境変数を設定します。

("#!/bin/sh" 行の続き):

また、サーバのプロセスが 0 以外の引数値の exit() を呼び出した場合、ウォッチドッグがサーバを再起動するオプションも使うことができます。デフォルトではこの機能は無効ですが、次のようにサーバの起動スクリプトのUXWDOG_RESTART_ON_EXIT の環境変数を設定して、有効にすることができます。

Enterprise Server 3.01 から Enterprise Server 3.5.1 では、設定が変更された場合には、サーバの起動と停止ではなく、再起動するようにAdministration Server のCGI が変更されています。この変更の一環として、これらのCGI は、サーバのログ ディレクトリに、wdnotify ファイルを作成します。このファイルには、ウォッチドッグのステータスをCGI がリッスンする TCP ポート番号が含まれています。起動または再起動のオペレーションの実行時には、uxwdog がこのファイルの有無を確認し、このファイルがある場合は、該当するポートに接続して、stderr をリダイレクトするファイル名を読み込みます。uxwdog は、このファイルを開き、ここに stderr をリダイレクトして、オペレーションを実行します。オペレーションが成功すると、uxwdog は、0 のシングル バイトの値をCGI に書き込みます。成功しなかった場合は、0 以外のステータス バイト (通常は 1) を書き込みます。最後に、 uxwdog は CGI へのコネクションを終了し、stderr /dev/console にリダイレクトします。

wdnotify が正常に削除されない場合、サーバの起動または再起動の代わりに、uxwdog が終了する場合もあります。この問題は、 logs ディレクトリから、手作業で wdnotify ファイルを削除することにより解決することができます。

 

(C) Copyright (C) 2000 Sun Microsystems, Inc. Some preexisting portions Copyright (C) 2000 Netscape Communications Corp. All rights reserved.