前へ
目次
索引
DocHome
次へ
|
| iPlanet Web Server, Enterprise Edition 管理者ガイド |
第 16 章 コンテンツ管理
この章では、仮想サーバのクラスと仮想サーバについて、コンテンツを構成して管理する方法を説明します。
プライマリドキュメントディレクトリの設定
プライマリドキュメントディレクトリの設定
プライマリドキュメントディレクトリ (ドキュメントルートとも呼ぶ) は、リモートクライアントで利用したいすべてのファイルを格納するための中央ディレクトリです。クラスを追加する場合は、絶対パスでドキュメントディレクトリを指定します。この絶対パスの一部として変数を使用しない場合は、クラス内のすべての仮想サーバに対するドキュメントルートがデフォルトで同じディレクトリになります。Class Manager でドキュメントルートを個別に変更することもできます。
別の方法として、クラスに対してパスを設定するとき、変数を使用することもできます。たとえば、$id 変数を使用して、クラス内のすべての仮想サーバに対して、仮想サーバの ID を名前に使用したディレクトリを作成することができます。クラスのドキュメントルートを class_doc_root/$id に設定することができます。このパスを使用すると、クラスのドキュメントディレクトリが /iplanet/servers/docs/$id の場合、そのクラスに属している仮想サーバ vs1 のデフォルトのドキュメントディレクトリは /iplanet/servers/docs/vs1 です。
ドキュメントディレクトリと、サーバインスタンス、クラス、および仮想サーバのレベルでのドキュメントディレクトリの使用方法の詳細については、「ドキュメントルート」を参照してください。
プライマリドキュメントディレクトリを変更して別のパスや変数を使用するには、次の手順に従います。
Class Manager の「Content Mgmt」タブをクリックします。
詳細は、オンラインヘルプの「「User Document Directories」ページ」を参照してください。「Primary Document Directory」をクリックします。
仮想サーバの横に、ディレクトリへの絶対パスや変数、または、パスと変数の組み合わせを入力します。
「OK」をクリックします。
- ドキュメントルートの絶対パスの末尾に変数 $id を組み込む場合、すべての仮想サーバのデフォルトのドキュメントルートが class_doc_root/virtual_server_ID になります。たとえば、クラスのドキュメントディレクトリが /iplanet/servers/docs/$id の場合、クラスに属している仮想サーバ vs1 のデフォルトドキュメントディレクトリは /iplanet/servers/docs/vs1 です。
- 変数の詳細については、「変数の使用法」を参照してください。
注 通常、各仮想サーバには固有プライマリドキュメントディレクトリがあります。
追加ドキュメントディレクトリの設定
ほとんどの場合、仮想サーバ、またはサーバインスタンスのドキュメントは、プライマリドキュメントディレクトリにあります。ただし、ドキュメントルート外のディレクトリからドキュメントを参照する場合もあります。追加ドキュメントディレクトリを設定すると、ドキュメントルート外のディレクトリからドキュメントを参照できます。ドキュメントルート外のドキュメントディレクトリを参照できるようにすることで、ほかのユーザにプライマリドキュメントルートへアクセスすることなくドキュメントのグループを管理することを許可できます。変数を使用しないで追加ドキュメントディレクトリを設定する場合は、そのディレクトリがクラスレベルで設定され、クラス内のすべての仮想サーバによって使用されます。
クラス内の個々の仮想サーバに対して追加ドキュメントディレクトリを設定する場合、URL 接頭辞がマッピングされるディレクトリを仮想サーバごとに変えるため、変数を使用する必要があります。
追加ドキュメントディレクトリを追加するには、次の手順に従います。
Class Manager の「Content Mgmt」タブをクリックします。
詳細は、オンラインヘルプの「「Additional Document Directories」ページ」を参照してください。「Additional Document Directories」をクリックします。
URL をマッピングするディレクトリを指定します。
- クライアントはドキュメントが必要なとき、この URL をサーバに送信します。
デフォルトでは、サーバインスタンスにいくつかの追加ドキュメントディレクトリがあります。そのディレクトリには、次の接頭辞が付いています。
これらのディレクトリへのアクセスを制限して、ユーザが書き込めないようにする必要があります。サンプル ACL は次のとおりです。
- deny (all) anyone;
- allow (rxli) all;
- allow (wd) privileged_user;
ユーザ公開情報ディレクトリのカスタマイズ (UNIX/Linux)
ユーザが独自の Web ページを維持管理する場合もあります。サーバ上のすべてのユーザが、自由にホームページやその他のドキュメントを作成できるように、公開情報ディレクトリを構成することができます。この設定ができるのは、クラス全体を対象とする場合だけです。仮想サーバごとにカスタマイズする方法はありません。
このシステムでは、クライアントは公開情報ディレクトリとしてサーバに認識されている特定の URL を使用してサーバにアクセスできます。たとえば、接頭辞 ~ とディレクトリ public_html を選択するとします。http://www.iplanet.com/~jdoe/aboutjane.htmlが要求された場合、サーバは ~jdoe がユーザの公開情報ディレクトリを参照していると認識します。サーバはシステムのユーザデータベースの jdoe で Jane のホームディレクトリを検索します。次に、サーバは ~/jdoe/public_html/aboutjane.html を検索します。
公開ディレクトリを使用するようにサーバを構成するには、次の手順に従います。
Class Manager の「Content Mgmt」タブをクリックします。
詳細は、オンラインヘルプの「「User Document Directories」ページ」を参照してください。「User Document Directories」をクリックします。
サーバが HTML ファイルを検索する、ユーザのホームディレクトリ内にあるサブディレクトリを選択します。
- チルド文字がユーザのホームディレクトリにアクセスするための標準の UNIX/Linux 接頭辞であるため、通常の接頭辞は ~ です。
パスワードファイルを指定します。
- 通常のディレクトリは public_html です。
起動時にパスワードデータベースを読み込むかどうかを選択します。
- サーバでは、システム上のユーザのリストがあるファイルを検索する場所を認識している必要があります。サーバはこのファイルを使用して、ユーザ名が有効であるかどうかを判断し、そのユーザのホームディレクトリを検索します。この目的でシステムのパスワードファイルを使用する場合、サーバは標準のライブラリコールを使用してユーザを検索します。あるいは、別のユーザファイルを作成して、ユーザを検索することもできます。ユーザファイルを絶対パスで指定することができます。
- ファイルの各行を次の構造にする必要があります (/etc/passwd ファイル内の必要のない要素は * で表示されています)。
- username:*:*:groupid:*:homedir:*
構成スタイルを適用するかどうかを選択します。
- 詳細は、「起動時のパスワードファイル全体の読み込み」を参照してください。
ユーザに個別のディレクトリを提供するもう 1 つの方法は、すべてのユーザが修正できる中央ディレクトリへの URL マッピングを作成することです。
コンテンツ発行の制限
システム管理者が、ユーザドキュメントディレクトリからコンテンツを発行できるユーザアカウントを制限したい場合もあります。ユーザによる発行を制限するには、/etc/passwd ファイルのユーザのホームディレクトリのパスに最後のスラッシュを追加します。
を次のように修正します。
- jdoe::1234:1234:John Doe:/home/jdoe:/bin/sh
この修正を行うと、iPlanet Web Server はこのユーザのディレクトリのページを提供しなくなります。URI を要求するブラウザは「404 File Not Found」エラーを受信し、 Web サーバのアクセスログに 404 エラーが記録されます。エラーログにはエラーが記録されません。
- jdoe::1234:1234:John Doe:/home/jdoe/:/bin/sh
この修正のあと、このユーザにコンテンツの発行を許可する場合は、/etc/passwd エントリから最後のスラッシュを削除して、Web サーバを再起動します。
起動時のパスワードファイル全体の読み込み
また、起動時にパスワードファイル全体を読み込むオプションもあります。このオプションを選択する場合、サーバは起動時にパスワードファイルをメモリに読み込んで、ユーザの検索速度を大きく向上させます。ただし、パスワードファイルが非常に大きい場合は、このオプションでメモリを使い過ぎる可能性があります。
構成スタイルの使用
サーバに構成スタイルを適用して、公開情報ディレクトリからディレクトリへのアクセスを制御することができます。これによって、管理者が公開したくない情報にユーザがシンボリックリンクを作成するのを防止できます。構成ファイルの詳細については、第 17 章「構成スタイルの適用」を参照してください。
リモートファイル操作の有効化
リモートファイル操作を有効にする場合、クライアントはファイルのアップロード、ファイルの削除、ディレクトリの作成、ディレクトリの削除、ディレクトリの中身のリスト表示、サーバ上のファイルの名前変更などを実行できます。ディレクトリ server_root/https-serve-id/config 内のファイル obj.conf には、リモートファイル操作を有効にした場合にアクティブになるコマンドが格納されています。これらのコマンドをアクティブにすると、リモートブラウザでサーバのドキュメントを変更できるようになります。アクセス制御を使用して、これらのリソースへの書き込みを制限し、認証を受けていないユーザによる変更を防止する必要があります。リモートファイル操作を有効にしても、Microsoft Frontpage などのコンテンツ管理システムの使用に影響を及ぼすことはありません。
UNIX/Linux の場合: ファイルへのアクセス権がないと、この機能は動作しません。つまり、ドキュメントルートユーザをサーバユーザと同じにする必要があります。
リモートファイル操作を有効にするには、次の手順を実行します。
詳細は、オンラインヘルプの「「Remote File Manipulation」ページ」を参照してください。
ドキュメント設定の構成
「Document Preferences」ページを使用して、ドキュメント設定を行います。この節では、次の内容を説明します。
ドキュメント設定の変更
これらの設定はすべて、個々の仮想サーバではなく、クラスに対して構成されます。
ドキュメント設定の変更
ドキュメント設定を変更するには、次の手順に従います。変更できる設定については、次の節で詳しく説明します。詳細は、オンラインヘルプの 「「Document Preferences」ページ」を参照してください。
インデックスファイル名の入力
URL でドキュメント名が指定されていない場合は、自動的にインデックスファイルが表示されます。デフォルトのインデックスファイルは index.html と home.html です。複数のインデックスファイルが指定されている場合、どれか見つかるまでこのフィールドに表示される名前順に検索されます。たとえば、インデックスファイル名が index.html と home.html の場合、サーバは index.html を検索し、見つからない場合は home.html を検索します。
ディレクトリのインデックス作成を選択
ほとんどの場合、ドキュメントディレクトリにはいくつかのサブディレクトリがあります。たとえば、products や people などの名前が付いたディレクトリがあるとします。クライアントがこのようなディレクトリの概要 (またはインデックス) にアクセスできると多くの場合に便利です。サーバは index.html または home.html という名前のインデックスファイルをディレクトリ内で検索して、ディレクトリのインデックスを作成します。index.html または home.html は、ディレクトリの中身の概要として作成し、維持管理するファイルです。詳細は、「インデックスファイル名の入力」を参照してください。デフォルト名の 1 つを付けることによって、どのファイルでもディレクトリのインデックスファイルとして指定することができます。つまり、CGI が有効な場合には、CGI プログラムをインデックスとして使用することもできます。
インデックスファイルが見つからない場合、サーバはドキュメントルート内のすべてのファイルをリスト表示するインデックスファイルを生成します。
サーバがファイアウォール外にある場合は、ディレクトリのインデックス作成を無効にして、ディレクトリ構造やファイル名にアクセスできないようにします。
サーバのホームページの指定
エンドユーザが最初にサーバにアクセスしたときに表示されるファイルは、通常、ホームページと呼ばれます。通常、このファイルにはサーバについての一般情報とほかのドキュメントへのリンクがあります。デフォルトでは、サーバは「Document Preferences」ページの「Index Filenames」フィールドで指定されているインデックスファイルを検索し、ホームページとして使用します。ただし、ホームページとして使用するファイルを指定することもできます。
デフォルト MIME タイプの指定
ドキュメントがクライアントに送信されるとき、クライアントがドキュメントを正しく表示できるように、ドキュメントのタイプを指定する部分を含めて送信されます。ただし、サーバに対してドキュメントの拡張子が定義されていないために、サーバがドキュメントのタイプを判断できない場合もあります。このような場合は、デフォルト値が送信されます。デフォルトは通常、text/plain ですが、サーバに格納されているもっとも一般的なタイプに設定する必要があります。次に一般的な MIME タイプの一部を示します。
Accept-Language ヘッダーの解析
クライアントが HTTP 1.1 を使用してサーバに接続する場合、受け入れる言語を説明したヘッダー情報を送信できます。この言語情報を解析するようにサーバを構成できます。たとえば、ドキュメントを日本語または英語で保存する場合、Accept-Language ヘッダーを解析するように選択できます。Accept-Language ヘッダーとして日本語が設定されたクライアントがサーバに接続する場合、日本語版のページを受信します。Accept-Language ヘッダーとして英語が設定されたクライアントがサーバに接続する場合、英語版のページを受信します。
複数の言語をサポートしていない場合は、Accept-Language ヘッダーを解析する必要はありません。
Accept-Language ヘッダー使用についての詳細は、「Accept-Language ヘッダーの使用」節を参照してください。
URL 転送の構成
URL 転送を使用すると、ドキュメント要求を別のサーバにリダイレクトできます。URL の転送またはリダイレクションは、サーバがユーザに URL を変更したこと (たとえば、ファイルを別のディレクトリサーバに移動した場合) を通知するための方法です。また、リダイレクションを使用して、あるサーバのドキュメントを要求するユーザをスムーズに別のサーバのドキュメントに送信することができます。たとえば、http://www.iplanet.com/info/movies を接頭辞 film.iplanet.com に転送する場合、http://www.iplanet.com/info/movies という URL は http://film.iplanet.com/info/movies にリダイレクトされます。
変数を使用して、ディレクトリを新しいディレクトリにマッピングすることができます。たとえば、/new を /$docroot/new にマッピングすることができます。マッピングによって、仮想サーバのドキュメントルートに移動します。
変数についての詳細は、「変数の使用法」を参照してください。
1 つのサブディレクトリ内のすべてのドキュメントに対する要求を特定の URL にリダイレクトする場合もあります。たとえば、あまりにも多くのトラフィックが生じるため、または、何らかの理由でドキュメントが公開されなくなったために、ディレクトリを移動する必要がある場合、ドキュメントに対する要求を、ドキュメントを利用できなくなった理由を説明するページに誘導することができます。たとえば、/info/movies の接頭辞を http://www.iplanet.com/explain.html にリダイレクトできます。
Class Manager の「Content Mgmt」タブをクリックします。
詳細は、オンラインヘルプの「「URL Forwarding」ページ」を参照してください。リダイレクトする URL 接頭辞を入力し、リダイレクト先を別の接頭辞にするか、または静的な URL にするかを指定します。
エラー応答のカスタマイズ
仮想サーバでエラーが発生した場合にクライアントに詳細なメッセージを送信する、カスタムエラー応答を指定できます。送信するファイルまたは実行する CGI プログラムを指定できます。たとえば、特定のディレクトリでエラーが発生した場合のサーバの動作を変更することができます。クライアントがアクセス制御によって保護されているサーバの一部に接続しようとする場合、アカウントの取得方法についての情報が記載されたエラーファイルを返すように設定できます。
カスタムエラー応答を有効にするには、エラー応答として送信する HTML ファイルまたは 実行する CGI プログラムを作成する必要があります。そのあと、Class Manager で応答を有効にします。
カスタマイズされたエラー応答を有効にするには、次の手順に従います。
Class Manager の「Content Mgmt」タブをクリックします。
詳細は、オンラインヘルプの「「Error Responses」ページ」を参照してください。リソースピッカーから「The entire server」を選択し、クラス全体に対して変更を適用するか、特定の仮想サーバに対するドキュメントルートまたは特定の仮想サーバ内の特定のディレクトリを指定します。
文字セットの変更
ドキュメントの文字セットは、記述されている言語によってある程度決まります。1 つのドキュメント、ドキュメントのセット、またはディレクトリに対するクライアントのデフォルト文字セットの設定は、リソースを選択し、リソースに対する文字セットを入力することによって変更できます。Netscape Navigator では、HTTP で MIME タイプの charset パラメータを使用して、文字セットを変更できます。サーバが応答でこのパラメータを指定する場合、それに応じて Netscape Navigator の文字セットが変更されます。次に、その例を示します。
Netscape Navigator で認識される次の charset 名は、RFC 1700 で指定されています (x- で始まる名前を除く)。
さらに、us-ascii に対して次のエイリアスが認識されます。
iso_8859-1 に対して、次のエイリアスが認識されます。
Class Manager の「Content Mgmt」タブをクリックします。
詳細は、オンラインヘルプの「「International Characters」ページ」を参照してください。「International Characters」をクリックします。
リソースピッカーから「The entire server」を選択し、クラス全体に対して変更を適用するか、特定の仮想サーバに対するドキュメントルートまたは特定の仮想サーバ内の特定のディレクトリを指定します。
「OK」をクリックします。
- このフィールドを空白にしておくと、文字セットが「NONE」に設定されます。
ドキュメントのフッターの変更
サーバの特定の部分にあるすべてのドキュメントに対して、フッターを指定できます。フッターには、最後に修正を行った日時を含めることができます。このフッターは、CGI スクリプトの出力や解析される HTML (.shtml) ファイルを除くすべてのファイルに対して挿入できます。CGI スクリプトの出力または解析される HTML ファイルにドキュメントフッターを表示する必要がある場合は、別のファイルにフッターのテキストを入力し、1 行のコードまたは別のサーバサイドインクルードを追加して、そのファイルをページの出力に追加します。
Class Manager の「Content Mgmt」タブをクリックします。
詳細は、オンラインヘルプの「「Document Footer」ページ」を参照してください。リソースピッカーから「The entire server」を選択し、クラス全体に対して変更を適用するか、特定の仮想サーバに対するドキュメントルートまたは特定の仮想サーバ内の特定のディレクトリを指定します。
フッターを挿入するファイルのタイプを指定します。
- ディレクトリを選択する場合、ドキュメントフッターは、サーバがそのディレクトリまたはディレクトリ内のファイルの URL を受信したときにだけ適用されます。
- ドキュメントフッターの最大文字数は 765 文字です。ドキュメントが最後に修正された日付を挿入する場合は、「:LASTMOD:」という文字列を入力します。
htaccess の使用
htaccess の使用についての詳細は、「.htaccess ファイルの使用」を参照してください。
シンボリックリンクの制限 (UNIX/Linux)
サーバでのファイルシステムリンクの使用を制限することができます。ファイルシステムリンクは、ほかのディレクトリやファイルシステムに格納されているファイルへの参照です。参照によって、現在のディレクトリにあるかのようにリモートファイルにアクセスできるようになります。次の 2 つのタイプのファイルシステムリンクがあります。
ハードリンク−ハードリンクは、同じデータブロックセットをポイントする 2 つの実際のファイル名です。元のファイルとリンクは同一です。このため、別のファイルシステム上にハードリンクを作成することはできません。
ハードリンクとシンボリックリンクについての詳細は、各 UNIX/Linux システムのマニュアルを参照してください。シンボリック (ソフト) リンク−シンボリックリンクは、データを含む元のファイルと、元のファイルをポイントする別のファイルの 2 つのファイルで構成されます。シンボリックリンクは、ハードリンクより柔軟です。シンボリックリンクは、複数のファイルシステム間で使用でき、ディレクトリにリンクできます。
ファイルシステムリンクは、プライマリドキュメントディレクトリ外にあるドキュメントへのポインタを簡単に作成するための方法で、誰でもリンクを作成できます。このため、ほかのユーザが重要なファイル (たとえば、機密ドキュメントやシステムのパスワードファイル) へのポインタを作成する可能性が心配される場合もあるでしょう。
Class Manager の「Content Mgmt」タブをクリックします。
詳細は、オンラインヘルプの「「Symbolic Links」ページ」を参照してください。リソースピッカーから「The entire server」を選択し、クラス全体に対して変更を適用するか、特定の仮想サーバに対するドキュメントルートまたは特定の仮想サーバ内の特定のディレクトリを指定します。
サーバが解析する HTML の設定
HTML は通常、ディスク上に実際に存在している通りの状態で、サーバに介入されずに、クライアントに送信されます。ただし、サーバはドキュメントを送信する前に、HTML ファイル内にある特別なコマンドを検索できます (つまり、HTML を解析できます)。サーバでこのようなファイルを解析し、要求に固有の情報またはファイルをドキュメントに挿入したい場合、HTML の解析を事前に有効にしておく必要があります。
Class Manager の「Content Mgmt」タブをクリックします。
解析される HTML を受け入れるためのサーバの設定についての詳細は、オンラインヘルプの「「Parse HTML」ページ」を参照してください。
サーバによる HTML の解析を有効にするかどうかを選択します。
- リソースピッカーから「The entire server」を選択し、クラス全体に対して変更を適用するか、特定の仮想サーバに対するドキュメントルートまたは特定の仮想サーバ内の特定のディレクトリを指定します。
- ディレクトリを選択する場合、サーバはそのディレクトリまたはそのディレクトリ内のファイルの URL を受信したときにだけ HTML を解析します。
解析するファイルを選択します。
- exec タグは有効にしないで HTML ファイルの解析を有効にすることも、exec タグも含めて HTML ファイルの解析を有効にすることもできます。exec タグを使用すると、HTML ファイルでサーバ上のほかのプログラムを実行できます。
「OK」をクリックします。
- .shtml という拡張子が付いているファイルだけを解析するか、すべての HTML ファイルを解析するかを選択できます。すべての HTML ファイルを解析する場合、パフォーマンスが低下します。UNIX/Linux を使用している場合、実行権限が有効な UNIX/Linux ファイルの解析を選択することもできます。ただし、この場合は信頼性が損なわれる可能性があります。
サーバが解析する HTML の使用についての詳細は、『プログラマーズガイド』を参照してください。
キャッシュ制御指令の設定
キャッシュ制御指令は、プロクシサーバによってキャッシュに保存される情報を iPlanet Web Server で制御するための手段です。キャッシュ制御指令を使用すると、デフォルトのプロクシのキャシングがオーバーライドされ、重要な情報がキャッシュに保存されてあとから取得される可能性がないように保護されます。このような指令を実行するには、プロクシサーバが HTTP 1.1 に準拠している必要があります。HTTP 1.1 の詳細については、Hypertext Transfer Protocol--HTTP/1.1 仕様 (RFC 2068) を参照してください。サイトは次のとおりです。
Class Manager の「Content Mgmt」タブをクリックします。
詳細は、オンラインヘルプの「「Cache Control Directives」ページ」を参照してください。「Cache Control Directives」をクリックします。
フィールドに必要事項を入力します。応答指令として有効な値を次に示します。
「OK」をクリックします。
Stronger Ciphers の使用
Stronger Ciphers の設定についての詳細は、「Stronger Ciphers を設定する」を参照してください。
前へ 目次 索引 DocHome 次へ
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.
Last Updated October 17, 2001