NFS サービスの概要
NFS サービスの設定と障害回避方法 (トラブルシューティング)
NFS サービスの背景情報について
この章では、ネットワーク経由でファイルシステムにアクセスするために使用する NFS サービスの概要を説明します。また、NFS サービスを理解するために必要な概念、および NFS と autofs の最新の機能についても説明します。
ここでは、NFS サービスを使用するために必要な基本用語について説明します。NFS サービスの詳細は、第 15 章「ネットワークファイルシステムへのアクセス (リファレンス)」で説明します。
クライアントとサーバーという用語は、コンピュータがファイルシステムを共有するときの役割を示すものです。ネットワークを介してファイルシステムを提供するコンピュータは、サーバーの役割を果たします。そのファイルシステムにアクセスしているコンピュータをクライアントと呼びます。NFS を使用することによって、どのコンピュータからも他のコンピュータのファイルシステムにアクセスでき、同時に自分のファイルシステムへのアクセスも可能になります。ネットワーク上では 1 台のコンピュータがクライアントかサーバー、またはその両方の役割として動作することができます。
クライアントは、サーバーの共有ファイルシステムをマウントすることによってサーバーのファイルにアクセスします。クライアントがリモートファイルシステムをマウントしたとき、ファイルシステムがコピーされるのではありません。マウントプロセスでは一連のリモート手続き呼び出しによって、クライアントからサーバーのディスク上にあるファイルシステムに透過的にアクセスできるようになります。マウントはローカルマウントのように行われます。ユーザーはファイルシステムがローカルにあるのと同じようにコマンドを入力します。ファイルシステムをマウントする方法については、ファイルシステムのマウント を参照してください。
サーバーのファイルシステムは、NFS オペレーションによって共有すると、クライアントからアクセスできるようになります。NFS ファイルシステムは、autofs を使用すると自動的にマウントできます。share コマンドと autofs に関連する作業については、ファイルシステムの自動共有 と autofs 管理作業の概要 を参照してください。
NFS サービスで共有できるオブジェクトは、ファイル階層の全体、またはその一部です。ファイルを 1 つだけ共有することもできます。すでに共有しているファイル階層と重複するファイル階層は共有できません。モデムやプリンタなどの周辺機器も共有できません。
多くの UNIX システム環境で共有されるファイル階層構造は、1 つのファイルシステム、またはその一部です。しかし NFS サポートは複数のオペレーティングシステムにまたがって動作しますが、ファイルシステムという考え方は UNIX 以外の環境では通用しません。したがって、ファイルシステムという語は、NFS でマウントし共有したファイルまたはファイル階層構造を指します。
NFS サービスとは、アーキテクチャが異なり、別のオペレーティングシステムで動作しているコンピュータが、ネットワークを通じてファイルシステムを共有できるようにするサービスのことです。NFS サポートは、MS-DOS から VMS オペレーティングシステムまで多くのプラットフォームに実装されています。
NFS 環境は、異なるオペレーティングシステムで実現できます。NFS はアーキテクチャの仕様を定義するのではなく、ファイルシステムの抽象モデルを定義しているためです。それぞれのオペレーティングシステムでは、ファイルシステムセマンティクスに NFS 抽象モデルを適用します。このモデルにより、書き込みや読み出しのようなファイルシステムオペレーションが、ローカルファイルにアクセスするように機能することになります。
複数のコンピュータで同一のファイルを使用するため、ネットワーク上の誰もが同じデータにアクセスできる
各ユーザーアプリケーションがローカルのディスクスペースを占めるのではなく、複数のコンピュータでアプリケーションを共有するため、記憶領域を有効利用できる
すべてのユーザーが同一セットのファイルを読み出すので、データの整合性と信頼性が向上する
ファイルシステムをユーザーに透過的な形でマウントできる
リモートファイルに透過的にアクセスできる
さまざまな環境をサポートする
システム管理の手間を省ける
NFS サービスを使用すると、ファイルシステムの実際の場所をユーザーとは無関係に決めることができます。ユーザーは場所を気にすることなく、すべての適切なファイルにアクセスできるということです。NFS サービスでは、共通して使用するファイルのコピーをすべてのシステムに置くのではなく、コピーを 1 つのコンピュータのディスクに置き、他のシステムからネットワークを通じてアクセスできるようにします。NFS オペレーションでは、リモートファイルシステムとローカルファイルシステムの区別がありません。
NFS サービスで共有されるファイルシステムは、「自動マウント」と呼ばれる方法によってマウントできます。クライアント側のサービスである autofs は、自動マウントを実現するファイルシステム構造です。autofs のファイルシステムは、automount で作成されます。automount は、システムを起動すると自動的に実行されます。automountd という常駐型の自動マウントデーモンが、必要に応じてリモートディレクトリのマウントとアンマウントを行います。
automountd を実行しているクライアントコンピュータがリモートのファイルまたはディレクトリにアクセスしようとすると、リモートのファイルシステムがデーモンによってマウントされます。このリモートファイルシステムは、必要な間はマウントされたままです。リモートファイルシステムが一定時間アクセスされないと、自動的にアンマウントされます。
ブート時にマウントする必要はなく、ユーザーはディレクトリをマウントするためにスーパーユーザーのパスワードを知る必要はありません。ユーザーが mount と umount コマンドを使用する必要もありません。autofs は、ユーザーの介入なしに、必要に応じてファイルシステムをマウントまたはアンマウントします。
automountd によって一部のファイル階層をマウントするということは、mount によって他の階層をマウントしないということではありません。ディスクレスコンピュータは、mount と /etc/vfstab ファイルを使用して / (ルート)、/usr、および /usr/kvm をマウントしなければなりません。
autofs サービスについては、autofs 管理作業の概要と autofs のしくみで詳しく説明します。
バージョン 2 は、一般に広く使用された初めての NFS プロトコルです。バージョン 2 は、引き続き広範囲のプラットフォームで使用できます。Solaris のすべてのリリースが NFS プロトコルのバージョン 2 をサポートし、Solaris 2.5 より以前のリリースはバージョン 2 だけをサポートします。
NFS バージョン 3 のプロトコルは、Solaris 2.5 で新機能として追加されたものです。相互運用性とパフォーマンスを向上させるために、いくつかの変更が行われました。これらをすべて有効に利用するには、NFS サーバーとクライアントの両方で、バージョン 3 プロトコルを使用する必要があります。
バージョン 3 では、サーバーで非同期の書き込みが可能になります。サーバーがクライアントの書き込み要求をメモリーに保存するので、効率が向上しました。クライアントは、サーバーが変更内容をディスクに反映させるのを待つ必要がないため、応答時間が短縮されます。サーバーは要求をバッチ処理することもできるので、サーバー上の応答時間も短縮されました。
NFS バージョン 3 では、多くの操作でローカルキャッシュに保存されているファイル属性が返されます。キャッシュの更新頻度が増えたため、ローカルキャッシュのデータを更新する操作を独立して行う必要性が少なくなります。したがってサーバーに対する RPC コールの回数が減少し、パフォーマンスが向上します。
ファイルアクセス権の確認処理も改善されました。バージョン 2 では、ユーザーが適切なアクセス権を持っていないリモートファイルをコピーしようとすると、「書き込みエラー」や「読み出しエラー」というメッセージが出力されました。バージョン 3 では、ファイルを開く前に権利がチェックされるので、「オープンエラー」というメッセージが出力されます。
NFS バージョン 3 プロトコルでは、8K バイトの転送サイズ制限が解除されました。クライアントとサーバーは、バージョン 2 の 8K バイトの制限を受けることなく、サポートされている転送サイズをネゴシエートできます。Solaris 2.5 では、デフォルトで、転送サイズが 32K バイトに設定されていることに注意してください。
Solaris 2.5 で、アクセス制御リスト (ACL) サポートが追加されました。ACL では、ファイルアクセス権を通常の UNIX よりも厳密に設定します。この追加機能では効率は改善されませんが、ファイルへのアクセスがより厳密に制限されるので、セキュリティが向上します。ACL の詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「アクセス制御リスト (ACL) の使用」を参照してください。
NFS プロトコルのデフォルトのトランスポートプロトコルは、Solaris 2.5 で TCP (Transmission Control Protocol) に変更されました。TCP は、低速ネットワークとワイドエリアネットワークのパフォーマンスの向上に役立ちます。TCP には、トラフィック抑制機能とエラー回復機能もあります。TCP を利用した NFS は、バージョン 2 でもバージョン 3 でも動作します。Solaris 2.5 より前のバージョンでは、NFS のデフォルトプロトコルは UDP (User Datagram Protocol) でした。
Solaris 2.5 からネットワークロックマネージャの改良版も含まれています。このため NFS ファイルに対して UNIX のレコードロックと PC のファイル共有を使用できます。NFS ファイルのロックメカニズムの信頼性の向上により、ロックを使用するコマンドのハングが起こりにくくなりました。
Solaris 2.6 の NFS バージョン 3 プロトコルから、2G バイトを超えるサイズのファイル (大規模ファイル) も正しく処理できるようになりました。NFS バージョン 2 プロトコル、および Solaris 2.5 に実装されているバージョン 3 プロトコルでは 2G バイトを超えるサイズのファイルは処理できませんでした。
Solaris 2.6 では、読み取り専用ファイルシステムの動的フェイルオーバー機能が追加されました。フェイルオーバーによって、マニュアルページ、その他のドキュメント、共有バイナリなどのあらかじめ複製されている読み取り専用リソースを高度に利用できます。フェイルオーバー機能は、ファイルシステムがマウントされた後ならばいつでも実行可能です。手動マウントでは、今までのリリースのオートマウンタのように複数の複製をリストできるようになりました。オートマウンタは、フェイルオーバーの際にファイルシステムが再マウントされるまで待つ必要がなくなったこと以外は変更されていません。詳細は、クライアント側フェイルオーバーを使用する方法 と クライアント側フェイルオーバー機能 を参照してください。
Solaris 2.0 では、Kerberos V4 クライアントがサポートされていました。Solaris 2.6 では、mount と share コマンドが Kerberos V5 認証を使用する NFS バージョン 3 のマウントをサポートするように変更されました。share コマンドもクライアントごとに異なる複数の認証機能を使用できるように変更されました。各種のセキュリティ機能の詳細は、RPCSEC_GSS セキュリティ方式 を参照してください。Kerberos V5 認証の詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「SEAM NFS サーバーの構成」を参照してください。
Solaris 2.6 には、インターネット上のファイルシステムにファイアウォール経由でアクセスできるようにする機能も追加されました。この機能は、NFS プロトコルの拡張機能によって実現しました。 インターネットアクセスに WebNFSTM プロトコルを使用する利点の 1 つは、信頼性が高いことです。このサービスは、NFS バージョン 3 とバージョン 2 プロトコルの拡張として構築されています。さらに、WebNFS ではそうしたファイルを共有しても匿名 ftp サイトを管理するオーバーヘッドが生じません。WebNFS サービスのその他の変更については、WebNFS サービスのセキュリティネゴシエーション を参照してください。作業については、WebNFS の管理作業 を参照してください。
Solaris 7 から、新しいセキュリティ方式である RPCSEC_GSS がサポートされています。この方式では、標準的な GSS-API インタフェースを使用して、認証、一貫性、機密性を実現し、複数のセキュリティメカニズムをサポートしています。Kerberos V5 認証のサポートについての詳細は、NFS サービスのための Kerberos のサポート を参照してください。GSS-API についての詳細は、『GSS-API のプログラミング』を参照してください。
Solaris 7 で、mount コマンドと automountd コマンドが拡張され、マウント要求で MOUNT プロトコルの代わりに公開ファイルハンドルも使用できるようになりました。MOUNT プロトコルは、WebNFS サービスが使用するアクセス方法と同じです。公開ファイルハンドルを使用すると、ファイアウォールを越えたマウントが可能です。さらに、サーバーとクライアント間のトランザクションが少なくて済むため、マウントにかかる時間が短縮されます。
この機能拡張で、標準のパス名の代わりに NFS URL を使用することもできるようになりました。また、mount コマンドとオートマウンタのマップに public オプションを指定すると、必ず公開ファイルハンドルを使用するようになります。WebNFS サービスの変更の詳細は、WebNFS のサポート を参照してください。
Solaris 8 で、WebNFS クライアントが NFS サーバーとセキュリティメカニズムをネゴシエートするための新しいプロトコルが追加されました。このプロトコルの追加により、WebNFS サービスの使用時に、セキュリティ保護されたトランザクションを使用できます。詳細については、WebNFS セキュリティネゴシエーション機能のしくみ を参照してください。
Solaris 8 で、NFS サーバーはサーバーロギングによって、ファイルシステムに実行されたファイル操作の記録を提供できるようになりました。この記録には、どのファイルが、いつ、誰によってアクセスされたかという情報が含まれています。一連の構成オプションを使用して、これらの情報を含むログの場所を指定することができます。また、これらのオプションを使用して、ログに記録する処理を選択することもできます。この機能は、NFS クライアントや WebNFS クライアントで匿名 ftp を利用するサイトで特に便利です。詳細は、NFS サーバーログを有効にする方法 を参照してください。
autofs は、ローカルの名前空間に指定したファイルシステムで動作します。この情報は、NIS、NIS+、およびローカルファイルに保存されます。
Solaris 2.6 から、完全にマルチスレッド化された automountd が含まれています。この拡張によって autofs はさらに信頼性が高まりました。また、複数のマウントを同時にサービスできるようになったため、サーバーが使用できないときにサービスが停止することも避けられます。
この新しい automountd には、オンデマンドマウント機能もあります。Solaris 2.6 より前のリリースでは、階層に含まれるすべてのファイルシステムがマウントされていました。現在は、いちばん上のファイルシステムしかマウントされません。そのマウントポイントに関係する他のファイルシステムは、必要に応じてマウントされます。
autofs サービスで、間接マップを表示できるようになりました。これによりユーザーは、どのディレクトリがマウントできるかを確認するためにファイルシステムを実際に 1 つずつマウントする必要がなくなります。autofs マップに -nobrowse オプションが追加されたので、/net や /home などの大きなファイルが自動的に表示されることはありません。また、automount に対して -n を使用することによって、autofs の表示機能を各クライアントでオフにすることもできます。詳細は、autofs のブラウズ機能を無効にする を参照してください。
この章では、NFS サービスの設定、共有する新規ファイルシステムの追加、ファイルシステムのマウントなど、NFS の管理作業の実行方法について説明します。また、Secure NFS システムおよび WebNFS の機能の使用方法についても説明します。章の最後では障害追跡の手順を説明し、NFS のいくつかのエラーメッセージとその意味を示します。
NFS 管理者の責任は、サイトの要求やネットワーク上に存在するコンピュータの役割によって変わります。管理者がローカルネットワークのコンピュータすべてに責任を持つこともありえます。そのような場合は、以下の設定事項について判断する必要があります。
サーバー専用にするコンピュータの決定
サーバーとクライアントの両方として動作するコンピュータの決定
クライアントとしてのみ動作するコンピュータの決定
設定が完了したサーバーの保守には、以下の作業が必要です。
ファイルシステムの共有開始と共有解除
管理ファイルを修正し、コンピュータが共有したり、自動的にマウントしたファイルシステムのリストを更新したりすること
ネットワークの状態のチェック
NFS に関連した問題の診断と解決
autofs のマップの設定
コンピュータは、サーバーとクライアントのどちらにもなれることに注意してください。ローカルファイルシステムをリモートコンピュータと共有したり、リモートファイルシステムをマウントしたりできます。
NFS 環境でファイルシステムを共有することにより、サーバーのファイルシステムにアクセスできるようになります。共有するファイルシステムは、share コマンドや /etc/dfs/dfstab ファイルに指定します。
/etc/dfs/dfstab ファイルの項目は、NFS サーバーオペレーションを起動したときに自動的に共有されます。同じファイルシステムを定期的に共有する必要がある場合は、自動共有を設定しなければなりません。たとえばサーバーがホームディレクトリをサポートしている場合、ホームディレクトリを常に使用できるようにしておく必要があります。ファイルシステムの共有はほとんどが自動的に行われます。共有を手動で実行するのは、テストまたは障害追跡の場合だけです。
dfstab ファイルには、サーバーがクライアントと共有しているすべてのファイルシステムがリストされています。このファイルを使用して、ファイルシステムをマウントできるクライアントを制御します。dfstab ファイルを変更して、ファイルシステムを追加または削除したり、共有方法を変更したりできます。その場合は、vi などのサポートされているテキストエディタを使って dfstab ファイルを編集します。コンピュータが次に実行レベル 3 に入ったときに、システムが更新された dfstab を読み、ファイルシステムの共有方法が自動的に判断されます。
dfstab ファイルの各行は、share コマンドで構成されています。その share コマンドは、コマンド行プロンプトに入力してファイルシステムを共有するのと同じコマンドです。share コマンドは、/usr/sbin に保存されています。
表 14–1 ファイルシステムの共有 (作業マップ)
作業 |
説明 |
参照先 |
---|---|---|
自動ファイルシステムの共有を確立する |
サーバーのリブート時、ファイルシステムが自動的に共有されるようにサーバーを設定する手順 | |
WebNFS を有効にする |
ユーザーが WebNFS でファイルにアクセスできるようにサーバーを設定する手順 | |
NFS サーバーログを有効にする |
NFS ログが選択したファイルシステム上で動作するようにサーバーを設定する手順 |
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
共有する対象の各ファイルシステムに関してエントリを追加します。
/etc/dfs/dfstab を編集します。自動的に共有する各ファイルシステムのファイルにエントリを 1 つ追加します。各エントリは、ファイル中に 1 行で記述する必要があり、次のような構文を使用します。
share [-F nfs] [-o specific-options] [-d description] pathname |
/etc/dfs/dfstab ファイルについては、dfstab(4) のマニュアルページを、全オプションのリストについては、share_nfs(1M) のマニュアルページを参照してください。
NFS サービスがサーバー上で動作していることを確認します。
share コマンドまたは share コマンドセットをはじめて実行する場合、NFS サービスが動作していないことがあります。次のコマンドを使用して、NFS デーモンのどれかが動作していることをチェックします。
# pgrep nfsd 318 |
この例では、318 は nfsd のプロセス ID です。 ID が表示されない場合は、サービスが動作していないことを意味します。 次に、mountd が動作していることをチェックします。
(省略可能) NFS サービスを起動します。
前の手順を実行しても nfsd のプロセス ID が表示されない場合は、次のコマンドを使用して、NFS サービスを起動します。
# /etc/init.d/nfs.server start |
このコマンドを実行すると、NFS サービスがサーバーで実行されます。リブート時にサーバーが実行レベル 3 であるときには、NFS サービスが自動的に再起動されます。
(省略可能) ファイルシステムを共有します。
エントリを /etc/dfs/dfstab に追加したあと、システムをリブートするか、shareall コマンドを使用して、ファイルシステムを共有可能にできます。NFS サービスを起動したすぐ後は、このコマンドはスクリプトにより実行されているため、実行する必要はありません。
# shareall |
情報が正しいことを確認します。
share コマンドを実行し、適切なオプションが表示されていることを確認します。
# share - /export/share/man ro "" - /usr/src rw=eng "" - /export/ftp ro,public "" |
次の手順は、サーバー上で共有化したファイルシステムにクライアントがアクセスできるよう autofs マップを設定する手順です。autofs 管理作業の概要 を参照してください。
Solaris 2.6 から、デフォルトでは、NFS のマウントが利用可能なファイルシステムはすべて、WebNFS アクセスも自動的に利用できます。この手順を使用する必要があるのは、次のいずれかの場合だけです。
NFS マウントがまだ利用可能になっていないサーバーで NFS マウントができるようにする場合
public オプションを使用して、公共ファイルハンドルをリセットし NFS URL を短くする場合
index オプションを使用して、特定の html ファイルを強制的に読み込む場合
WebNFS サービスを起動する際の注意事項については、WebNFS アクセスの計画 を参照してください。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
WebNFS サービスを使用して、共有する各ファイルシステムのエントリを追加します。
/etc/dfs/dfstab を編集します。各ファイルシステムごとにエントリを 1 つ追加します。次の例の public タグおよび index タグは省略できます。
share -F nfs -o ro,public,index=index.html /export/ftp |
/etc/dfs/dfstab ファイルについては、dfstab(4) のマニュアルページを、全オプションのリストについては、share_nfs(1M) のマニュアルページを参照してください。
NFS サービスがサーバー上で動作していることを確認します。
share コマンドまたは share コマンドセットをはじめて実行する場合、NFS デーモンが動作していないことがあります。次のコマンドを使用して、NFS デーモンのどれかが動作していることをチェックします。
# pgrep nfsd 318 |
この例では、318 は nfsd のプロセス ID です。 ID が表示されない場合は、サービスが動作していないことを意味します。 次に、mountd が動作していることをチェックします。
(省略可能) NFS サービスを起動します。
前の手順を実行しても nfsd のプロセス ID が表示されない場合は、次のコマンドを使用して、NFS サービスを起動します。
# /etc/init.d/nfs.server start |
このコマンドを実行すると、NFS サービスがサーバーで実行されます。ブート時にサーバーが実行レベル 3 になったときには、NFS サービスが自動的に再起動されます。
(省略可能) ファイルシステムを共有します。
エントリを /etc/dfs/dfstab に追加したあと、システムをリブートするか、shareall コマンドを使用して、ファイルシステムを共有可能にできます。NFS サービスを起動したすぐ後は、このコマンドはスクリプトにより実行されているため、実行する必要はありません。
# shareall |
情報が正しいことを確認します。
share コマンドを実行し、適切なオプションが表示されていることを確認します。
# share - /export/share/man ro "" - /usr/src rw=eng "" - /export/ftp ro,public,index=index.html "" |
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
(省略可能) ファイルシステム構成の設定を変更します。
/etc/nfs/nfslog.conf で設定を変更する方法は 2 つあります。すべてのファイルシステムについてデフォルトの設定を編集するには、global タグに関連するデータを変更します。または、このファイルシステムについて新しいタグを追加します。これらの変更が必要でない場合には、このファイルを変更する必要はありません。/etc/nfs/nfslog.conf の書式については、nfslog.conf(4) を参照してください。
NFS サーバーログを使用して、共有する各ファイルシステムについてエントリを追加します。
/etc/dfs/dfstab を編集します。NFS サーバー記録を有効にするファイルシステムについてエントリを 1 つ追加します。log=tag オプションとともに使用するタグは、/etc/nfs/nfslog.conf にも記述する必要があります。次の例では、global タグ内のデフォルト設定を使用しています。
share -F nfs -o ro,log=global /export/ftp |
/etc/dfs/dfstab ファイルについては、dfstab(4) のマニュアルページを、全オプションのリストについては、share_nfs(1M) のマニュアルページを参照してください。
NFS サービスがサーバー上で動作していることを確認します。
share コマンドまたは share コマンドセットをはじめて実行する場合、NFS デーモンが動作していないことがあります。次のコマンドを使用して、NFS デーモンのどれかが動作していることをチェックします。
# pgrep nfsd 318 |
この例では、318 は nfsd のプロセス ID です。 ID が表示されない場合は、サービスが動作していないことを意味します。 次に、mountd が動作していることをチェックします。
(省略可能) NFS サービスを起動します。
前の手順を実行しても nfsd のプロセス ID が表示されない場合は、次のコマンドを使用して、NFS サービスを起動します。
# /etc/init.d/nfs.server start |
このコマンドを実行すると、NFS サービスがサーバーで実行されます。ブート時にサーバーが実行レベル 3 になったときには、NFS サービスが自動的に再起動されます。
(省略可能) ファイルシステムを共有します。
エントリを /etc/dfs/dfstab に追加したあと、システムをリブートするか、shareall コマンドを使用して、ファイルシステムを共有可能にできます。NFS サービスを起動したすぐ後は、このコマンドはスクリプトにより実行されているため、実行する必要はありません。
# shareall |
情報が正しいことを確認します。
share コマンドを実行し、適切なオプションが表示されていることを確認します。
# share - /export/share/man ro "" - /usr/src rw=eng "" - /export/ftp ro,log=global "" |
(省略可能) NFS ログデーモン nfslogd がすでに実行されていなければ、起動します。
nfs.server スクリプトを使用して NFS デーモンの再起動をすると、nfslog.conf ファイルが存在している場合、デーモンが起動されます。それ以外の場合は、サーバーのリブート時にコマンドが自動的に再起動されるように、一度手動でコマンドを実行してファイルを作成する必要があります。
# /usr/lib/nfs/nfslogd |
ファイルシステムをマウントするには、いくつかの方法があります。システムをブートするときに自動的にマウントされるようにするか、コマンド行から必要に応じてマウントするか、オートマウンタを使用します。オートマウンタには、ブート時のマウントやコマンド行からのマウントに比較していくつもの利点がありますが、状況によってこの 3 つの方法を組み合わせる必要があります。また、ファイルシステムのマウント時に使用するオプションに応じて、プロセスを有効または無効にする方法がいくつかあります。ファイルシステムのマウントに関するすべての作業のリストについては、次の表を参照してください。
表 14–2 ファイルシステムのマウントの作業マップ
作業 |
説明 |
参照先 |
---|---|---|
ブート時にファイルシステムをマウントする | システムがリブートされるときに必ずファイルシステムがマウントされるようにする手順 | ブート時のファイルシステムのマウント方法 |
コマンドを使用してファイルシステムをマウントする | システムの動作時にファイルシステムをマウントする手順。この手順はテストに有効 | コマンド行からファイルシステムをマウントする方法 |
オートマウンタによりマウントする | コマンド行を使用せずに、要求に応じてファイルシステムにアクセスする手順 | オートマウンタによるマウント |
大規模ファイルを避ける | ファイルシステム上に大規模ファイルが作成されないようにする手順 | NFS サーバー上で大規模ファイルを無効にする方法 |
クライアント側フェイルオーバーを開始する | サーバーの不良時、動作中のファイルシステムへの自動切り換えを有効にする手順 | クライアント側フェイルオーバーを使用する方法 |
クライアントに対するマウントアクセスを無効にする | 任意のクライアントがリモートシステムにアクセスする機能を無効にする手順 | 1 つのクライアントに対するマウントのアクセスを無効にする方法 |
ファイアウォールを越えてファイルシステムにアクセスを提供する | WebNFS プロトコルを使用してファイアウォールを越えてファイルシステムへのアクセスを許可する手順 | ファイアウォールを越えて NFS ファイルシステムをマウントする方法 |
NFS URL を使ってファイルシステムをマウントする | NFS URL を使ってファイルシステムへのアクセスを許可する手順。このプロセスによって、MOUNT プロトコルを使用しないでファイルシステムへのアクセスが可能になる | NFS URL を使用して NFS ファイルシステムをマウントする方法 |
autofs マップを使用するのではなく、ブート時にファイルシステムをマウントするには、次の手順に従います。リモートファイルシステムでは、この手順をクライアントごとに行います。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
ファイルシステムに関するエントリを /etc/vfstab に追加します。
/etc/vfstab ファイルのエントリ構文は、次のとおりです。
special fsckdev mountp fstype fsckpass mount-at-boot mntopts
詳細は、vfstab(4) のマニュアルページを参照してください。
NFS サーバーに NFS vfstab ファイルのエントリを作成するとデッドロックが発生する可能性があるため、作成しないでください。/etc/vfstab のエントリが確認された後、NFS サービスが起動します。次のようなことが考えられます。互いにファイルシステムをマウントしている 2 つのサーバーが同時に停止した場合、リブート時にハングアップする可能性があります。
wasp サーバーの /var/mail ディレクトリをクライアントマシンにマウントするとします。それには、クライアント側で、ファイルシステムを /var/mail としてマウントし、読み出しと書き込みの両方ができるようにします。この場合は、以下の項目をクライアントの vfstab ファイルに追加します。
wasp:/var/mail - /var/mail nfs - yes rw |
新規マウントポイントをテストするために、コマンド行からファイルシステムをマウントすることがあります。このようにしてマウントすると、オートマウンタでアクセスできないファイルシステムに、一時的にアクセスすることができます。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
ファイルシステムをマウントします。
# mount -F nfs -o ro bee:/export/share/local /mnt |
上の例では、bee サーバーの /export/share/local ファイルシステムが、ローカルシステムの /mnt に読み取り専用でマウントされます。コマンド行からこのようにマウントすることにより、ファイルシステムを一時的に表示することができます。umount を実行するかローカルホストをリブートすると、このマウントは解除されます。
Solaris 2.6 およびそれ以降に出たパッチに置き換えられた mount コマンドでは、無効なオプションを指定しても警告されません。解釈できないオプションがあると無視されるだけです。予想外の結果が生じるのを避けるために、使用するオプションはすべて確認してください。
autofs 管理作業の概要では、オートマウンタによるマウントの確立とサポートについて詳細に説明します。通常のシステムに変更を加えることなく、リモートファイルシステムが /net マウントポイントでアクセスできるようになります。前述の例の /export/share/local ファイルシステムをマウントする場合、次の内容を入力します。
% cd /net/bee/export/share/local |
オートマウンタでは、すべてのユーザーがファイルシステムをマウントできるので、root としてアクセスする必要はありません。またファイルシステムのマウントを自動的に解除できるので、作業の終了後、ファイルシステムのマウントを解除する必要はありません。
2G バイトを超えるファイルを処理できないクライアントをサポートしているサーバーについては、大規模ファイルを作成する機能を無効にしておく必要があります。
Solaris 2.6 より前の動作環境では、大規模ファイルは使用できません。クライアントが大規模ファイルにアクセスする必要がある場合には、NFS サーバーのクライアントが Solaris 2.6 以降のリリースで動作していることを確認してください。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
ファイルシステム上に大規模ファイルが存在していないことを確認してください。
次の例は、大規模ファイルを検索するためのコマンドです。
# cd /export/home1 # find . -xdev -size +2000000 -exec ls -l {} \; |
システム上に大規模ファイルが存在する場合には、削除するか、他のファイルシステムに移動する必要があります。
ファイルシステムをアンマウントします。
# umount /export/home1 |
ファイルシステムがマウントされている場合は、largefiles を使ってファイルシステムをリセットします。
fsck は、ファイルシステム上に大規模ファイルが存在しない場合に、ファイルシステムの状態をリセットします。
# fsck /export/home1 |
nolargefiles を使用して、ファイルシステムをマウントします。
# mount -F ufs -o nolargefiles /export/home1 |
コマンド行からマウントすることができますが、オプションをさらに固定的にするには、/etc/vfstab に次のようなエントリを追加してください。
/dev/dsk/c0t3d0s1 /dev/rdsk/c0t3d0s1 /export/home1 ufs 2 yes nolargefiles |
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
NFS クライアント上で、ro オプションを使用してファイルシステムをマウントします。
コマンド行からも、オートマウンタを使用しても、または /etc/vfstab ファイルに次のようなエントリを追加することによってもマウントできます。
bee,wasp:/export/share/local - /usr/local nfs - no ro |
この構文はオートマウンタでも指定できました。しかし、フェイルオーバー機能が使用できるのはサーバーが選択されているときだけで、ファイルシステムがマウントされるときには使用できませんでした。
NFS プロトコルの異なるバージョンを実行する複数のサーバーを、コマンド行や vfstab のエントリに混在させないでください。NFS バージョン 2 またはバージョン 3 のプロトコルをサポートしているサーバーを混在して使用できるのは、autofs を使用する場合だけです。autofs では、バージョン 2 またはバージョン 3 のサーバーの最適なサブセットが使用されます。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
/etc/dfs/dfstab にエントリを追加します。
最初の例では、rose という名称のホストを除き、eng ネットグループ内のすべてのクライアントへのマウントアクセスを許可しています。2 つ目の例では、rose を除き、eng.sun.com DNS ドメイン内にあるすべてのクライアントへのマウントアクセスを許可しています。
share -F nfs -o ro=-rose:eng /export/share/man share -F nfs -o ro=-rose:.eng.example.com /export/share/man |
アクセスリストに関する補足的な情報については、share コマンドを使ってアクセスリストを設定するを参照してください。/etc/dfs/dfstab については、dfstab(4) のマニュアルページを参照してください。
ファイルシステムを共有します。
/etc/dfs/dfstab への変更は、このファイルシステムがもう 1 度共有されるかサーバーがリブートされるまでは NFS サーバーに反映されません。
# shareall |
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
次のコマンドを使用して、ファイルシステムを手動でマウントします。
# mount -F nfs bee:/export/share/local /mnt |
この例では、/export/share/local というファイルシステムは、公共ファイルハンドルを使ってローカルクライアントにマウントしています。標準のパス名の代わりに、NFS URL を使用することができます。ただし bee サーバーで公共ファイルハンドルがサポートされていないと、マウント操作は失敗します。
この手順では、NFS サーバーのファイルシステムを public オプションで共有する必要があります。また、クライアントとサーバー間のファイアウォールでは、ポート 2049 で TCP 接続できるようにする必要があります。Solaris 2.6 から、共有しているすべてのファイルシステムに、公共ファイルハンドルでアクセスできます。そのため、デフォルトでは、public オプションが適用されています。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
(省略可能) NFS バージョン 2 またはバージョン 3 を使用している場合、次のコマンドを使用して、ファイルシステムを手動でマウントします。
# mount -F nfs nfs://bee:3000/export/share/local /mnt |
この例では、bee というサーバーの /export/share/local というファイルシステムが、NFS ポート番号 3000 を使ってマウントされます。ポート番号を指定する必要はありません。その場合、デフォルトの NFS ポート番号である 2049 が使用されます。NFS URL に、public オプションを含めるかどうかを選択できます。public オプションを指定しない場合、サーバーが公共ファイルハンドルをサポートしていなければ、MOUNT プロトコルが使用されます。public オプションを指定すると、必ず公共ファイルハンドルを使用するように指定され、公共ファイルハンドルがサポートされていないとマウントは失敗します。
NFS サーバーを起動および停止する
オートマウンタを起動および停止する
作業 |
説明 |
参照先 |
---|---|---|
NFS サーバーを起動する |
NFS サービスが自動的に起動されていない場合に、NFS サービスを起動する手順 | |
NFS サーバーを停止する |
NFS サービスを停止する手順。通常は、サービスを停止する必要はない | |
オートマウンタを起動する |
オートマウンタを起動する手順。オートマウンタマップが変更された場合、この手順が必要 | |
オートマウンタを停止する |
オートマウンタを停止する手順。オートマウンタマップが変更された場合、この手順が必要 |
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
NFS サービスデーモンを有効にします。
# /etc/init.d/nfs.server start |
/etc/dfs/dfstab にエントリがあると、このコマンドはデーモンを起動します。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
NFS サービスデーモンを無効にします。
# /etc/init.d/nfs.server stop |
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
autofs デーモンを有効にします。
# /etc/init.d/autofs start |
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
autofs デーモンを無効にします。
# /etc/init.d/autofs stop |
Secure NFS システムを使用するには、自分が責任を持つすべてのコンピュータにドメイン名が必要です。「ドメイン」とは管理上のエンティティであり、通常、大きなネットワークの一環となる複数のコンピュータから構成されます。ネームサービスを実行している場合、そのドメインに対してネームサービスを設定する必要があります。『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』 を参照してください。
NFS サービスでは、Kerberos バージョン 5 認証もサポートされています。Kerberos サービスについては、『Solaris のシステム管理 (セキュリティサービス)』の「SEAM について」で説明しています。
Secure NFS 環境は、Diffie-Hellman 認証を使用するようにも設定できます。この認証サービスについては、『Solaris のシステム管理 (セキュリティサービス)』の「認証サービスの使用 (手順)」で説明しています。
ドメインにドメイン名を割り当て、そのドメイン名をドメイン内の各コンピュータに知らせます。
NIS+ をネームサービスとして使用している場合は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。
newkey コマンドまたは nisaddcred コマンドを使用して、クライアントのユーザーの公開鍵と秘密鍵を設定します。chkey コマンドを使用して、各ユーザーに独自の Secure RPC パスワードを設定してもらいます。
これらのコマンドについての詳細は、newkey(1M)、nisaddcred(1M)、および chkey(1) のマニュアルページを参照してください。
ネームサービスが応答していることを確認します。NIS+ を実行している場合は、以下を入力してください。
# nisping -u Last updates for directory eng.acme.com. : Master server is eng-master.acme.com. Last update occurred at Mon Jun 5 11:16:10 1995 Replica server is eng1-replica-replica-58.acme.com. Last Update seen was Mon Jun 5 11:16:10 1995 |
NIS を実行している場合は、ypbind デーモンが動作していることを確認してください。
キーサーバーの keyserv デーモンが動作していることを確認します。
次のコマンドを入力します。
# ps -ef | grep keyserv root 100 1 16 Apr 11 ? 0:00 /usr/sbin/keyserv root 2215 2211 5 09:57:28 pts/0 0:00 grep keyserv |
keyserv デーモンが動作していない場合は、次の内容を入力してキーサーバーを起動します。
# /usr/sbin/keyserv |
通常、ログインパスワードはネットワークパスワードと同じです。この場合、keylogin は不要です。ログインパスワードとネットワークパスワードが異なる場合、ユーザーはログインしてから keylogin を実行しなければなりません。また、keylogin -r を root として実行し、復号化した秘密鍵を /etc/.rootkey に保存しなければなりません。
keylogin -r は、root の秘密鍵が変更されたか、/etc/.rootkey が損失した場合に、実行する必要があります。
ファイルシステムに対するマウントオプションを更新します。
Diffie-Hellman 認証を使用するには、/etc/dfs/dfstab ファイルを編集し、該当するエントリに sec=dh オプションを追加します。
share -F nfs -o sec=dh /export/home |
/etc/dfs/dfstab については、dfstab(4) のマニュアルページを参照してください。
ファイルシステムに対するオートマウンタマップを更新します。
auto_master
データを編集し、Diffie-Hellman 認証のエントリ内にマウントオプションとして sec=dh を含めます。
/home auto_home -nosuid,sec=dh |
Solaris 2.5 以前のリリースでは、その機能が制限されています。クライアントが、セキュリティ保護されている共有ファイルシステムにセキュリティモードでマウントしない場合、ユーザーは、そのユーザー自身ではなく、nobody ユーザーとしてアクセスすることになります。Solaris 2.5 以降の NFS バージョン 2 では、セキュリティモードが一致しないと、share コマンド行に -sec=none が指定されていないかぎり、NFS サーバーによってアクセスが拒否されます。NFS のバージョン 3 では、セキュリティ保護されていることを示すモードが NFS サーバーから引き継がれるので、クライアントが sec=dh を指定する必要はありません。ユーザーは、そのユーザー自身としてファイルにアクセスできます。
コンピュータを設置し直したり、移設したり、アップグレードしたりするときに、新しい鍵を設定せず、root 用の鍵も変更しない場合は、必ず /etc/.rootkey を保存してください。 /etc/.rootkey を削除するには、通常、次のコマンドを入力します。
# keylogin -r |
この節では、WebNFS システムを管理する方法について説明します。次の表に、関連する作業を示します。
表 14–4 WebNFS 管理の作業マップ
作業 |
説明 |
参照先 |
---|---|---|
WebNFS に関する計画を作成する | WebNFS サービスを有効にする前に考慮する項目 | WebNFS アクセスの計画 |
WebNFS を有効にする | WebNFS プロトコルを使用して NFS ファイルシステムのマウントを有効にする手順 | WebNFS アクセスを有効にする方法 |
ファイアウォール経由で WebNFS を有効にする | WebNFS プロトコルを使用して、ファイアウォール経由でファイルへのアクセスを許可する手順 | ファイアウォール経由で WebNFS アクセスを有効にする方法 |
NFS URL を使ってブラウズする | Web ブラウザ内での NFS URL の使用についての説明 | NFS URL を使ってブラウズする方法 |
autofs で公共ファイルハンドルを使用する | オートマウンタでファイルシステムをマウントする場合に、公共ファイルハンドルの使用を強制するための手順 | autofs で公共ファイルハンドルを使用する方法 |
autofs で NFS URL を使用する | オートマウンタマップに NFS URL を追加するための手順 | autofs で NFS URL を使用する方法 |
ファイアウォールを越えてファイルシステムにアクセスを提供する | WebNFS プロトコルでファイアウォールを越えてファイルシステムへのアクセスを許可する手順 | ファイアウォールを越えて NFS ファイルシステムをマウントする方法 |
NFS URL を使ってファイルシステムをマウントする | NFS URL を使ってファイルシステムへのアクセスを許可する手順。このプロセスによって、MOUNT プロトコルを使用しないファイルシステムへのアクセスが可能になる | NFS URL を使用して NFS ファイルシステムをマウントする方法 |
WebNFS を使用するには、まずアプリケーションを実行して NFS URL (nfs://server/path など) を読み込む必要があります。次に、WebNFS アクセスのためにエクスポートするファイルシステムを選択します。アプリケーションが Web ブラウザの場合は、Web サーバーのドキュメントルートがよく使用されます。WebNFS アクセスのためにエクスポートするファイルシステムを選択するときは、次の事項を検討する必要があります。
各サーバーには公共ファイルハンドルが 1 つずつあり、このハンドルはデフォルトではサーバーのルートファイルシステムに結び付けられています。NFS URL に示されたパスは、この公共ファイルハンドルが結び付けられているディレクトリからの相対パスとして評価されます。その結果としてパスが示す先のファイルまたはディレクトリが、エクスポートされたファイルシステムの中にあると、サーバーによってアクセスが実現されます。share コマンドの public オプションを使用すると、エクスポートされる特定のディレクトリにこの公開ファイルハンドルを結び付けることができます。このオプションを使用すると、URL はサーバーのルートファイルシステムではなく公共ファイルシステムからの相対パスになります。ルートファイルシステムを共有しないと、ルートファイルシステムへの Web アクセスはできません。
WebNFS 環境では、すでにマウント権限を持っているユーザーは、ブラウザからファイルにアクセスできます。ファイルシステムが public オプションを使ってエクスポートされているかどうかには関係ありません。ユーザーは NFS の設定によってファイルへのアクセス権を持っているため、ブラウザからのアクセスを許すことによって新たにセキュリティが損なわれる恐れはありません。ファイルシステムをマウントできないユーザーは、public オプションを使ってファイルシステムを共有するだけで、WebNFS アクセスを使用できるようになります。
すでに公開されているファイルシステムは、public オプションを使用するのに適しています。たとえば、ftp アーカイブの最上位のディレクトリや Web サイトのメイン URL ディレクトリなどです。
share コマンドで index オプションを使用すると、HTML ファイルを強制的に読み込むことができます。 そうしない場合は、NFS URL がアクセスされたときにディレクトリがリストされます。
ファイルシステムを選択したらファイルを確認し、必要に応じてファイルやディレクトリの表示を制限するようにアクセス権を設定します。アクセス権は、共有される NFS ファイルシステムに合わせて設定します。多くのサイトでは、ディレクトリに対しては 755、ファイルに対しては 644 が適切なアクセスレベルです。
また、NFS と HTTP URL の両方を使用して 1 つの Web サイトにアクセスする場合は、その他の事項も検討する必要があります。これについては、Web ブラウザの使用と比較した場合の WebNFS の制約で説明します。
ブラウザが WebNFS サービスをサポートしている場合は、次のような NFS URL にアクセスできます。
nfs://server<:port>/path |
ファイルサーバー名
使用するポート番号 (デフォルト値は 2049)
公共ファイルハンドラまたはルートファイルシステムに関連するファイルへのパス
ほとんどのブラウザでは、前のトランザクションで使用した URL サービスのタイプ (NFS や HTTP など) を次のトランザクションでも使用します。例外は、異なるタイプのサービスを含む URL を読み込んだ場合は、前のトランザクションで使用した URL サービスのタイプが使われることがあります。NFS URL を使用した後に、HTTP URL に対する参照が読み込まれることがあります。その場合、次のページは、NFS プロトコルではなく HTTP プロトコルを使って読み込まれます。
ローカルのサブネットに属していないクライアントに対して WebNFS アクセスを有効にするには、ポート 2049 での TCP 接続を許可するようにファイアウォールを設定します。httpd に対してアクセスを許可するだけでは、NFS URL が使えるようにはなりません。
この節では、ユーザー自身の環境で遭遇する可能性のあるもっとも一般的な作業について説明します。各シナリオについて、ユーザーのクライアントで必要とする条件に最も適合するように autofs を設定するために推奨される手順も示します。この節で説明する作業を実行するには、Solaris 管理コンソールツールを使用するか、『Solaris のシステム管理(ネーミングとディレクトリサービス: FNS、NIS+ 編)』を参照してください。
次の表に、autofs に関連する作業についての説明と参照箇所を示します。
表 14–5 autofs 管理の作業マップ
作業 |
説明 |
参照先 |
---|---|---|
autofs を起動する | システムをリブートすることなくオートマウントサービスを起動する | オートマウンタの起動方法 |
autofs を停止する | 他のネットワークサービスを使用不可にすることなくオートマウントサービスを停止する | オートマウンタの停止方法 |
autofs でファイルシステムにアクセスする | オートマウントサービスを使ってファイルシステムにアクセスする | オートマウンタによるマウント |
autofs マップを修正する | 他のマップをリストするために使用されるマスターマップの修正を行う手順 | マスターマップの修正方法 |
ほとんどのマップに対して使用される間接マップの修正を行う手順 | 間接マップの修正方法 | |
クライアント上のマウントポイントとサーバー間の直接の関係が必要な場合に使用される直接マップの修正を行う手順 | 直接マップの修正方法 | |
非 NFS ファイルシステムにアクセスするために autofs マップを修正する | CD-ROM アプリケーション用のエントリで autofs マップを設定する手順 | autofs で CD-ROM アプリケーションにアクセスする |
PC-DOS フロッピーディスク用のエントリで autofs マップの設定を行う手順 | autofs で PC-DOS データフロッピーディスクにアクセスする方法 | |
autofs を使用して CacheFS ファイルシステムにアクセスする手順 | CacheFS を使用して NFS ファイルシステムにアクセスする方法 | |
/home を使用する | 共通の /home マップの設定方法の例 | /home の共通表示の設定 |
複数のファイルシステムを参照する /home マップを設定する手順 | 複数のホームディレクトリファイルシステムで /home を設定する方法 | |
新しい autofs マウントポイントを使用する | プロジェクト関連の autofs マップを設定する手順 | /ws 下のプロジェクト関連ファイルを統合する方法 |
異なるクライアントアーキテクチャをサポートする autofs マップを設定する手順 | 共有名前空間にアクセスするために異なるアーキテクチャを設定する方法 | |
異なるオペレーティングシステムをサポートする autofs マップを設定する手順 | 非互換のクライアントオペレーティングシステムのバージョンをサポートする方法 | |
autofs でファイルシステムを複製する | フェイルオーバーしたファイルシステムへのアクセスを提供する | 複数のサーバーを通じて共用ファイルを複製する方法 |
autofs でセキュリティ制限を使用する | ファイルへのリモート root アクセスを制限する一方でファイルシステムへのアクセスを提供する | autofs セキュリティ制限を適用する方法 |
autofs で公共ファイルハンドルを使用する | ファイルシステムのマウント時に公共ファイルハンドルの使用を強制する | autofs で公共ファイルハンドルを使用する方法 |
autofs で NFS URL を使用する | オートマウンタが使用できるように、NFS URL を追加する | autofs で NFS URL を使用する方法 |
autofs のブラウズ機能を無効にする | autofs マウントポイントが 1 つのクライアント上で自動的に生成されないように、ブラウズ機能を無効にする手順 | 1 つの NFS クライアントの autofs ブラウズ機能を完全に無効にする方法 |
autofs マウントポイントがすべてのクライアント上で自動的に生成されないように、ブラウズ機能を無効にする手順 | すべてのクライアントの autofs ブラウズ機能を無効にする方法 | |
特定の autofs マウントポイントがある 1 つのクライアント上で自動的に生成されないように、ブラウズ機能を無効にする手順 | 選択したファイルシステムの autofs ブラウズ機能を無効にする方法 |
表 14–6 は、autofs マップの管理時に認識しておく必要のある事項について示したものです。選択したマップのタイプおよびネームサービスにより、autofs マップへの変更を行うために使用する必要があるメカニズムが異なります。
表 14–6 に、マップのタイプとその使用方法を示します。
表 14–6 autofs マップのタイプとその使用方法
マップのタイプ |
使用方法 |
---|---|
ディレクトリをマップに関連付ける |
|
autofs を特定のファイルシステム向けにする |
|
autofs をリファレンス指向のファイルシステム向けにする |
表 14–7 は、ネームサービスに基づいて autofs 環境に変更を加える方法を示したものです。
表 14–7 マップの保守
ネームサービス |
メソッド |
---|---|
ローカルファイル | |
NIS | |
NIS+ |
表 14–8 に、マップのタイプについて行なった修正に応じた automount コマンドを実行する場合を示します。たとえば、直接マップに対する追加または削除を行なった場合、ローカルシステム上で automount コマンドを実行する必要があります。automount コマンドを実行すると、変更が反映されます。ただし、既存のエントリを修正した場合は、変更を反映するために automount コマンドを実行する必要はありません。
表 14–8 automount コマンドを実行する場合
マップのタイプ |
automount を再実行するか否か |
|
---|---|---|
|
追加または削除 |
修正 |
Y |
Y |
|
Y |
N |
|
N |
N |
次の手順では、NIS+ をネームサービスとして使用している必要があります。
マップを変更する権限を持つユーザーとしてログインします。
nistbladm コマンドを使用して、マスターマップへの変更を行います。
『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。
各クライアントで、スーパーユーザーになるか、それと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
マップを変更したことを他のユーザーに通知します。
他のユーザーがコンピュータ上でスーパーユーザーとして automount コマンドを実行できるように、通知が必要になります。
automount コマンドは、実行時にマスターマップから情報を収集します。
マップを変更する権限を持つユーザーとしてログインします。
nistbladm コマンドを使用して、間接マップへの変更を行います。
『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。
変更は、マップを次に使用する時、つまり次回のマウント実行時に反映されます。
マップを変更する権限を持つユーザーとしてログインします。
nistbladm コマンドを使用して、直接マップに対する変更点の追加または削除を行います。
『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。
マップを変更したことを他のユーザーに通知します。
他のユーザーがコンピュータ上でスーパーユーザーとして automount コマンドを実行できるように、通知が必要になります。
既存の直接マップエントリの内容の変更だけを行なった場合は、automount コマンドを実行する必要はありません。
たとえば、異なるサーバーから /usr/src ディレクトリがマウントされるように auto_direct マップを修正するとします。/usr/src がその時点でマウントされていない場合、/usr/src にアクセスするとすぐにその新しいエントリが反映されます。/usr/src がその時点でマウントされている場合、オートアンマウントが実行されるまで待ちます。その後、アクセスが可能になります。
できるだけ間接マップを使用してください。間接マップは構築が容易であり、コンピュータのファイルシステムへの要求が少なくて済みます。また、間接マップは直接マップよりもマウントテーブル内のスペースを必要としません。
/src 上にマウントされたローカルなディスクパーティションがあり、他のソースディレクトリのマウントにもその autofs サービスを使用する場合、問題が発生する可能性があります。マウントポイント /src を指定する場合、ユーザーがアクセスするたびに、NFS サービスが対象のローカルパーティションを隠すことになります。
たとえば /export/src などの他の場所に、パーティションをマウントする必要があります。その後、次のようなエントリを /etc/vfstab に含める必要があります。
/dev/dsk/d0t3d0s5 /dev/rdsk/c0t3d0s5 /export/src ufs 3 yes - |
このエントリは、auto_src にも必要です。
terra terra:/export/src |
terra はコンピュータ名です。
autofs は NFS ファイル以外のファイルもマウントすることができます。autofs は、フロッピーディスクや CD-ROM など、削除可能な媒体上のファイルをマウントします。通常は、ボリュームマネージャを使って削除可能な媒体上のファイルをマウントすることになります。次の例では、autofs を利用してこのマウントがどのように行われるかを示します。ボリュームマネージャと autofs は同時に動作することができないため、まずボリュームマネージャを終了してから次に示すエントリを使用する必要があります。
サーバーからファイルシステムのマウントを行う代わりに、ドライブに媒体を配置してマップから参照します。autofs を使用して非 NFS ファイルシステムにアクセスする場合は、次の手順を参照してください。
ボリュームマネージャを使用していない場合に、この手順を行なってください。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
autofs マップを更新します。
次のような CD-ROM のファイルシステム用のエントリを追加します。
hsfs -fstype=hsfs,ro :/dev/sr0 |
ボリュームマネージャを使用していない場合に、この手順を行なってください。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
autofs マップを更新します。
次のようなフロッピーディスクのファイルシステム用のエントリを追加します。
pcfs -fstype=pcfs :/dev/diskette |
キャッシュファイルシステム (CacheFS) は、汎用不揮発性キャッシュメカニズムで、小型で高速なローカルディスクを利用して、特定のファイルシステムのパフォーマンスを向上させます。
CacheFS を使ってローカルディスク上に NFS ファイルシステムからデータをキャッシュすることにより、NFS 環境のパフォーマンスを改善できます。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
cfsadmin コマンドを実行して、ローカルディスク上にキャッシュディレクトリを作成します。
# cfsadmin -c /var/cache |
任意のオートマウンタマップに cachefs エントリを追加します。
たとえば、次に示すエントリをマスターマップに追加して、すべてのディレクトリがキャッシュされます。
/home auto_home -fstype=cachefs,cachedir=/var/cache,backfstype=nfs |
以下のエントリを auto_home マップに追加すると、rich という名称のユーザーのホームディレクトリのキャッシュだけが行われます。
rich -fstype=cachefs,cachedir=/var/cache,backfstype=nfs dragon:/export/home1/rich |
後から検索されるマップ内のオプションは、先に検索されたマップ内のオプションを無効にします。そのため、最後に検出されたオプションが使用されます。前述の例では、auto_home マップに追加されたエントリにマスターマップのオプションを含むのは、変更が必要なオプションがあった場合だけです。
オートマウンタマップの設定方法はいくつかあります。次に、オートマウンタマップをカスタマイズして簡単に使用できるディレクトリ構造を実現する方法について詳細に説明します。
ネットワークユーザーすべてにとって理想的なのは、自分自身のホームディレクトリ、または他の人のホームディレクトリを /home の下に配置できるようにすることです。この表示方法は通常、クライアントでもサーバーでも、すべてのコンピュータを通じて共通です。
Solaris をインストールすると、常にマスターマップ /etc/auto_master もインストールされます。
# Master map for autofs # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse |
auto_home 用のマップも、/etc の下にインストールされます。
# Home directory map for autofs # +auto_home |
外部 auto_home マップに対する参照を除き、このマップは空になります。/home に含まれるディレクトリをすべてのコンピュータに対して共通にする場合、この /etc/auto_home マップは修正しないでください。すべてのホームディレクトリのエントリは、NIS または NIS+ のネームサービスファイルで表示されなくてはなりません。
ユーザーは、各ホームディレクトリから setuid 実行可能ファイルを実行することが許可されていません。この制限がないと、すべてのユーザーがすべてのコンピュータ上でスーパーユーザーの権限を持つことになります。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
/export/home の下にホームディレクトリパーティションをインストールします。
システムに複数のパーティションがある場合は、/export/home1、/export/home2 のように、別のディレクトリにそれぞれインストールを行います。
Solaris 管理コンソールツールを使用して、auto_home マップを作成して維持します。
新しいユーザーアカウントを作成する場合は、そのユーザーのホームディレクトリの場所を auto_home マップに入力します。マップのエントリは、次のように単純な形式にすることができます。
rusty dragon:/export/home1/& gwenda dragon:/export/home1/& charles sundog:/export/home2/& rich dragon:/export/home3/& |
マップキーを置換する & (アンパサンド) の使い方に注意してください。このアンパサンドは、次の例の 2 つ目の rusty の使用を省略した形式です。
rusty dragon:/export/home1/rusty |
auto_home マップを配置すると、ユーザーは、/home/user というパスを使用して、ユーザー自身のホームディレクトリを含むあらゆるホームディレクトリを参照できます。user はログイン名で、マップ内でのキーになります。すべてのホームディレクトリを共通に表示するしくみは、他のユーザーのコンピュータにログインする場合に便利です。autofs は、ユーザー自身のホームディレクトリをマウントします。同様に、他のコンピュータ上でリモートのウィンドウシステムクライアントを実行するとウィンドウシステムクライアントと同じ /home ディレクトリが表示されます。
この共通表示は、サーバーにも拡張されています。前の例を使用すれば、rusty がサーバー dragon にログインする場合、autofs は、/export/home1/rusty を /home/rusty にループバックマウントすることにより、ローカルディスクへの直接アクセスを提供します。
ユーザーは、各ホームディレクトリの実際の位置を意識する必要はありません。rusty がさらにディスクスペースを必要とし、rusty 自身のホームディレクトリを他のサーバーに再配置する必要がある場合には、auto_home マップ内の rusty のエントリを新しい場所を反映するように変更することだけが必要になります。他のユーザーは、/home/rusty パスを継続して使用することができます。
大きなソフトウェアの開発プロジェクトの管理者を想定してください。そこで、プロジェクト関連のファイルをすべて /ws というディレクトリの下で利用できるようにすると仮定します。このようなディレクトリは、そのサイトのすべてのワークステーションで共通である必要があります。
/ws ディレクトリに対するエントリを、サイトの NIS または NIS+ の auto_master マップに追加します。
/ws auto_ws -nosuid |
auto_ws マップが、/ws ディレクトリの内容を決定します。
-nosuid オプションを用心のために追加しておきます。
このオプションは、すべての作業空間に存在する可能性のある setuid プログラムをユーザーが実行できないようにします。
auto_ws マップにエントリを追加します。
auto_ws マップは、各エントリがサブプロジェクトを記述するように構成されています。最初の操作により、マップが次のようになります。
compiler alpha:/export/ws/& windows alpha:/export/ws/& files bravo:/export/ws/& drivers alpha:/export/ws/& man bravo:/export/ws/& tools delta:/export/ws/& |
各エントリの最後のアンパサンド (&) は、エントリーキーを省略したものです。たとえば、最初のエントリは次のエントリと同じ意味です。
compiler alpha:/export/ws/compiler |
この最初の操作により、マップはシンプルなものになりますが、このマップでは不十分です。プロジェクトのオーガナイザーが、man エントリ内のドキュメントを各サブプロジェクトの下のサブディレクトリとして提供しようとしているとします。さらに、各サブプロジェクトは、ソフトウェアの複数のバージョンを記述するために、複数のサブディレクトリを必要とします。この場合、サーバー上のディスクパーティション全体に対して、これらのサブディレクトリをそれぞれ割り当てる必要があります。
次のように、マップ内のエントリを修正してください。
compiler \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /vers2.0 bravo:/export/ws/&/vers2.0 \ /man bravo:/export/ws/&/man windows \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /man bravo:/export/ws/&/man files \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /vers2.0 bravo:/export/ws/&/vers2.0 \ /vers3.0 bravo:/export/ws/&/vers3.0 \ /man bravo:/export/ws/&/man drivers \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /man bravo:/export/ws/&/man tools \ / delta:/export/ws/& |
現在のマップはかなり長くなっていますが、まだ 5 つのエントリを含んでいるだけです。各エントリは、複数のマウントがあるために長くなっています。たとえば、/ws/compiler に対する参照は、vers1.0、vers2.0、および man ディレクトリ用に 3 つのマウントを必要とします。各行の最後のバックスラッシュは、エントリが次の行まで続いていることを autofs に伝えるものです。実際、エントリは 1 つの長い行となっていますが、行ブレークやインデントのいくつかはエントリを読みやすくする目的で使用されています。tools ディレクトリには、すべてのサブプロジェクトに対するソフトウェア開発ツールが含まれているため、同じサブディレクトリ構造の対象とはなっていません。tools ディレクトリは単一のマウントのままです。
この配置は、システムの管理者に大きな柔軟性を提供します。ソフトウェアプロジェクトでは、非常に大きなディスクスペースを消費します。プロジェクトのすべての過程を通じて、さまざまなディスクパーティションを再配置し、拡張することになる可能性もあります。このような変更が auto_ws マップに反映される場合は、/ws 下のディレクトリ階層構造が変更されることもなく、ユーザーに対する通知の必要はありません。
サーバー alpha と bravo が同一の autofs マップを参照するため、それらのコンピュータにログインするすべてのユーザーは期待通りに /ws 名前空間を発見できます。このようなユーザーには、NFS マウントではなく、ループバックマウントを通じてのローカルファイルへの直接アクセスが提供されます。
表計算アプリケーションやワードプロセッサパッケージのようなローカルの実行可能ファイルやアプリケーションについて、共有名前空間を作成する必要があります。この名前空間のクライアントは、異なる実行可能フォーマットを必要とする複数の異なるワークステーションアーキテクチャを使用します。また、ワークステーションには、異なるリリースのオペレーシングシステムを使用するものもあります。
nistabladm コマンドで auto_local マップを作成します。
『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。
共有名前空間について、サイト固有の名称を 1 つ選択します。この名称により、その名前空間に属するファイルとディレクトリが簡単に識別できるようになります。
たとえば、その名称として /usr/local を選択した場合、/usr/local/bin パスは明らかにこの名前空間の一部です。
ユーザーのコミュニティ識別を簡単にするため、autofs 間接マップを作成します。autofs 間接マップを /usr/local にマウントします。NIS (または NIS+) の auto_master マップ内で、次のエントリを設定します。
/usr/local auto_local -ro |
なお、-ro マウントオプションは、クライアントがファイルやディレクトリのすべてに対して書き込みができないことを示します。
サーバー上の任意のディレクトリをエクスポートします。
auto_local マップ内に bin エントリを 1 つ含めます。
ディレクトリ構造は、次のようになります。
bin aa:/export/local/bin |
(省略可能) 異なるアーキテクチャのクライアントを処理するため、autofs CPU 変数を加えて、エントリの変更を行います。
bin aa:/export/local/bin/$CPU |
SPARC クライアント – 実行可能ファイルを /export/local/bin/sparc に配置する
x86 クライアント – 実行可能ファイルを /export/local/bin/i386 に配置する
クライアントのオペレーティングシステムのタイプを決定する変数と、アーキテクチャタイプを結合します。
autofs OSREL 変数と CPU 変数を結合して、CPU タイプと OS リリースの両方を示す名前を作成することができます。
次のようなマップエントリを作成します。
bin aa:/export/local/bin/$CPU$OSREL |
SunOS 5.6 を動作させているクライアントについて、次のファイルシステムをエクスポートします。
SPARC クライアント – /export/local/bin/sparc5.6 をエクスポートする
x86 クライアント – 実行可能ファイルを /export/local/bin/i3865.6 に配置する
読み取り専用の複製されたファイルシステムを共有する最良の方法は、フェイルオーバーの利用です。フェイルオーバーについての説明は、クライアント側フェイルオーバー機能を参照してください。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
autofs マップ内のエントリを修正します。
すべての複製サーバーのリストを、コンマ区切りのリストとして、次のように作成します。
bin aa,bb,cc,dd:/export/local/bin/$CPU |
autofs は、最も近いサーバーを選択します。サーバーが複数のネットワークインタフェースを持っている場合は、各インタフェースのリストを作成してください。autofs はクライアントに最も近接したインタフェースを選択し、NFS トラフィックの不必要なルーティングを避けるようにしています。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
NIS または NIS+ のネームサービス auto_master ファイル内に次のようなエントリを作成します。
/home auto_home -nosuid |
nosuid オプションは、setuid または setgid ビットを設定したファイルをユーザーが作成できないようにします。
このエントリは、汎用ローカルファイル /etc/auto_master 内の /home のエントリを無効にします。 前述の例を参照してください。これは、+auto_master が、ファイル内の /home エントリより先に、外部のネームサービスマップを参照するためです。auto_home マップ内のエントリにマウントオプションがある場合、nosuid オプションは無効になります。そのため、auto_home マップ内でオプションを使用しないようにするか、nosuid オプションを各エントリに含める必要があります。
サーバー上の /home またはその下に、ホームディレクトリのディスクパーティションをマウントしないでください。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
/usr/local -ro,public bee:/export/share/local |
public オプションは、公共ハンドルの使用を強制します。NFS サーバーが公共ファイルハンドルをサポートしない場合、マウントは失敗します。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
/usr/local -ro nfs://bee/export/share/local |
サービスは、NFS サーバー上で公共ファイルハンドルの使用を試みます。サーバーが公共ファイルハンドルをサポートしない場合、MOUNT プロトコルが使用されます。
Solaris 2.6 から、インストールされる /etc/auto_master のデフォルトバージョンには、/home と /net 用のエントリに追加された -nobrowse オプションが含まれます。さらに、アップグレード手順により、/home と /net のエントリが修正されていない場合は、-nobrowse オプションがそれらのエントリに追加されます。ただし、このような変更を手動で加えるか、あるいはインストール後にサイト固有の autofs マウントポイントに対するブラウズ機能をオフにすることが必要な場合もあります。
ブラウズ機能をオフにする方法はいくつかあります。automountd デーモンに対してコマンド行オプションを使用してブラウズ機能を無効にすると、そのクライアントに対する autofs ブラウズ機能は完全に無効になります。あるいは、NIS 名前空間または NIS+ 名前空間の autofs マップを使用して、すべてのクライアントにおける各マップエントリのブラウズ機能を無効にします。また、ネットワーク規模の名前空間を使用していない場合は、ローカルな autofs を使用して、各クライアントにおける各マップエントリのブラウズ機能を無効にすることができます。
NFS クライアント上で、スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
次のいずれかの手順を実行します。
autofs サービスを再起動します。
# /etc/init.d/autofs stop # /etc/init.d/autofs start |
すべてのクライアントに対するブラウズ機能を無効にするには、NIS または NIS+ のようなネームサービスを使用する必要があります。それ以外の場合には、各クライアント上でオートマウンタマップを手動で編集する必要があります。この例では、/home ディレクトリのブラウズ機能が無効にされています。無効にする必要がある各間接 autofs ノードに対して、この手順を実行してください。
ネームサービス auto_master ファイル内の /home エントリに -nobrowse オプションを追加します。
/home auto_home -nobrowse |
すべてのクライアント上で、automount コマンドを実行します。
新規の動作は、クライアントシステム上で automount コマンドを実行した後、またはリブートした後に反映されます。
# /usr/sbin/automount |
この例では、/net ディレクトリのブラウズ機能を無効にします。/home または他の autofs マウントポイントにも、同じ手順を使用できます。
automount エントリが /etc/nsswitch.conf にあることを確認します。
優先するローカルファイルエントリについては、ネームサービススイッチファイル内のエントリがネームサービスの前に files をリストする必要があります。たとえば:
automount: files nisplus |
これは、標準的な Solaris にインストールされるデフォルトの構成を示します。
/etc/auto_master 内の +auto_master エントリの位置を確認します。
名前空間内のエントリに優先するローカルファイルへの追加については、+auto_master エントリが /net の下に移動されている必要があります。
# Master map for automounter # /net -hosts -nosuid /home auto_home /xfn -xfn +auto_master |
標準的な構成では、+auto_master エントリがファイルの先頭に配置されます。このように配置することにより、ローカルな変更が使用されなくなります。
/etc/auto_master ファイル内の /net エントリに -nobrowse オプションを追加します。
/net -hosts -nosuid,nobrowse |
すべてのクライアント上で、automount コマンドを実行します。
新規の動作は、クライアントシステム上で automount コマンドを実行した後、またはリブートした後に反映されます。
# /usr/sbin/automount |
NFS の問題を追跡するには、問題が発生する可能性があるのは主に、サーバー、クライアント、およびネットワークであることを覚えておいてください。 この節で説明するのは、個々の構成要素を切り離して、正常に動作しない部分を見つけ出そうというものです。リモートマウントを正常に実行するには、サーバー上で mountd と nfsd が動作している必要があります。
/etc/dfs/dfstab ファイルに NFS 共有エントリがある場合、mountd と nfsd はブート時に自動的に起動します。そのため、はじめて共有を設定する場合は、mountd および nfsd を手動で起動する必要があります。
デフォルトでは、すべてのマウントに -intr オプションが設定されます。プログラムが「server not responding」(サーバーが応答しません) というメッセージを出してハングした場合、これはキーボード割り込み (Ctrl-C) で終了できます。
ネットワークまたはサーバーに問題がある場合、ハードマウントされたリモートファイルにアクセスするプログラムの障害と、ソフトマウントされたリモートファイルにアクセスするプログラムの障害とは異なります。ハードマウントされたリモートファイルシステムの場合、クライアントのカーネルは、サーバーがふたたび応答するまで要求を再試行します。ソフトマウントされたリモートファイルシステムの場合、クライアントのシステムコールは、しばらく試行した後にエラーを返します。このエラーによって予想外のアプリケーションエラーやデータ破壊が発生する恐れがあるため、ソフトマウントは行わないでください。
ファイルシステムがハードマウントされていると、サーバーが応答に失敗した場合は、これにアクセスしようとするプログラムはハングします。この場合、NFS は次のメッセージをコンソールに表示します。
NFS server hostname not responding still trying |
サーバーが少し後に応答すると、次のメッセージがコンソールに表示されます。
NFS server hostname ok |
サーバーが応答しないような、ソフトマウントされたファイルシステムにアクセスしているプログラムは、次のメッセージを表示します。
NFS operation failed for server hostname: error # (error_message) |
読み取りと書き込みをするデータを持つファイルシステム、または実行可能ファイルを持つファイルシステムは、ソフトマウントしないでください。エラーが発生する可能性があります。アプリケーションがそのようなソフトエラーを無視すれば、書き込み可能なデータが破壊される恐れがあります。またマウントされた実行可能ファイルが正常にロードされず、動作も正常に行われない可能性があります。
NFS サービスがエラーになった場所を判断するには、いくつかの手順を踏まなければなりません。次の項目をチェックしてください。
クライアントがサーバーに到達できるかどうか
クライアントがサーバー上の NFS サービスを受けられるかどうか
NFS サービスがサーバー上で動作しているかどうか
上記の項目をチェックする過程で、ネットワークの他の部分が機能していないことに気づく場合があります。たとえば、ネームサービスやネットワークのハードウェアが機能していない場合があります。複数のネームサービスでのデバッグ手順については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』 で説明しています。また、上記の項目をチェックする過程で、クライアント側には問題がないことが判明することもあります。たとえば、作業領域のすべてのサブネットから、少なくとも 1 つの障害が発生したことが通知された場合などです。このような場合は、問題がサーバーかサーバー周辺のネットワークハードウェアで発生しているとみなし、クライアントではなく、サーバーでデバッグを開始する必要があります。
クライアントから NFS サーバーに到達できることを確認します。クライアントで次のコマンドを入力します。
% /usr/sbin/ping bee bee is alive |
コマンドを入力した結果、サーバーが動作していることがわかったら、NFS サーバーをリモートで確認します。NFS サーバーをリモートで確認する方法 を参照してください。
クライアントからサーバーに到達できない場合は、ローカルネームサービスが動作していることを確認します。
NIS+ クライアントで次のコマンドを入力します。
% /usr/lib/nis/nisping -u Last updates for directory eng.acme.com. : Master server is eng-master.acme.com. Last update occurred at Mon Jun 5 11:16:10 1995 Replica server is eng1-replica-58.acme.com. Last Update seen was Mon Jun 5 11:16:10 1995 |
ネームサービスが実行されている場合は、クライアントが正しいホスト情報を受け取るために次のように入力します。
% /usr/bin/getent hosts bee 129.144.83.117 bee.eng.acme.com |
ホスト情報に誤りがなく、クライアントからサーバーに接続できない場合は、別のクライアントから ping コマンドを実行します。
ping コマンドが失敗したら、サーバーで NFS サービスを確認する方法 を参照してください。
別のクライアントからサーバーに到達できる場合は、ping コマンドを使って元のクライアントとローカルネット上の他のシステムとの接続性を確認します。
エラーになる場合は、そのクライアントのネットワークソフトウェアの構成を確認します (/etc/netmasks、/etc/nsswitch.conf など)。
ソフトウェアに問題がない場合は、ネットワークハードウェアを確認します。
クライアントをネットワークの別の場所へ移動して確認します。
NFS サーバーで NFS サービスが実行されていることを、次のコマンドを入力して確認します。
% rpcinfo -s bee|egrep 'nfs|mountd' 100003 3,2 tcp,udp,tcp6,upd6 nfs superuser 100005 3,2,1 ticots,ticotsord,tcp,tcp6,ticlts,udp,upd6 mountd superuser |
デーモンが起動していない場合、NFS サービスを再起動する方法 を参照してください。
サーバーで nfsd プロセスが応答することを確認します。
クライアント上で、次のコマンドを入力し、サーバーからの UDP NFS 接続をテストします。
% /usr/bin/rpcinfo -u bee nfs program 100003 version 2 ready and waiting program 100003 version 3 ready and waiting |
サーバーが動作している場合、プログラムとバージョン番号が表示されます。-t オプションを使用すると、TCP 接続を検査できます。上記コマンドでエラーになる場合は、サーバーで NFS サービスを確認する方法 に進んでください。
サーバーで mountd が応答することを確認します。次のコマンドを入力します。
% /usr/bin/rpcinfo -u bee mountd program 100005 version 1 ready and waiting program 100005 version 2 ready and waiting program 100005 version 3 ready and waiting |
サーバーが動作している場合は、UDP プロトコルに関連しているプログラムとそのバージョン番号が出力されます。 -t オプションを使用すると、TCP 接続を検査できます。エラーになる場合は、サーバーで NFS サービスを確認する方法 に進んでください。
ローカル autofs サービスを使用していた場合は、そのサービスを確認します。
% cd /net/wasp |
/net か /home マウントポイントのうち、適切に動作する方を確認します。エラーになる場合は、次のコマンドを root としてクライアントから入力し、autofs サービスを再起動します。
# /etc/init.d/autofs stop # /etc/init.d/autofs start |
サーバーのファイルシステムの共有が正常に行えることを確認します。
% /usr/sbin/showmount -e bee /usr/src eng /export/share/man (everyone) |
サーバーの項目とローカルマウントエントリにエラーがないことをチェックします。名前空間も確認します。この例で最初のクライアントが eng ネットグループの中にない場合、/usr/src ファイルシステムはマウントできません。
すべてのローカルファイルを調べて、マウント情報を含むエントリをすべて検査します。リストには、/etc/vfstab とすべての /etc/auto_* ファイルが含まれています。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
サーバーがクライアントに到達できることを確認します。
# ping lilac lilac is alive |
サーバーからクライアントに到達できない場合は、ローカルネームサービスが動作していることを確認します。NIS+ クライアントで次のコマンドを入力します。
% /usr/lib/nis/nisping -u Last updates for directory eng.acme.com. : Master server is eng-master.acme.com. Last update occurred at Mon Jun 5 11:16:10 1995 Replica server is eng1-replica-58.acme.com. Last Update seen was Mon Jun 5 11:16:10 1995 |
ネームサービスが動作している場合は、サーバーにあるネットワークソフトウェアの構成を確認します (/etc/netmasks、 /etc/nsswitch.conf など)。
次のコマンドを入力し、rpcbind デーモンが動作していることを確認します。
# /usr/bin/rpcinfo -u localhost rpcbind program 100000 version 1 ready and waiting program 100000 version 2 ready and waiting program 100000 version 3 ready and waiting |
サーバーが動作している場合は、UDP プロトコルに関連しているプログラムとそのバージョン番号が出力されます。 rpcbind がハングしている場合は、サーバーをリブートするか、rpcbind をウォームスタートする方法 に示す作業を行なってください。
次のコマンドを入力し、nfsd デーモンが動作していることを確認します。
# rpcinfo -u localhost nfs program 100003 version 2 ready and waiting program 100003 version 3 ready and waiting # ps -ef | grep nfsd root 232 1 0 Apr 07 ? 0:01 /usr/lib/nfs/nfsd -a 16 root 3127 2462 1 09:32:57 pts/3 0:00 grep nfsd |
サーバーが動作している場合は、UDP プロトコルに関連しているプログラムとそのバージョン番号が出力されます。 rpcinfo に -t オプションを指定し、TCP 接続も確認します。これらのコマンドを使用するとエラーになる場合は、NFS サービスを再起動します。NFS サービスを再起動する方法 を参照してください。
次のコマンドを入力し、mountd デーモンが動作していることを確認します。
# /usr/bin/rpcinfo -u localhost mountd program 100005 version 1 ready and waiting program 100005 version 2 ready and waiting program 100005 version 3 ready and waiting # ps -ef | grep mountd root 145 1 0 Apr 07 ? 21:57 /usr/lib/autofs/automountd root 234 1 0 Apr 07 ? 0:04 /usr/lib/nfs/mountd root 3084 2462 1 09:30:20 pts/3 0:00 grep mountd |
サーバーが動作している場合は、UDP プロトコルに関連しているプログラムとそのバージョン番号が出力されます。 rpcinfo に -t オプションを指定し、TCP 接続も確認します。これらのコマンドを使用するとエラーになる場合は、NFS サービスを再起動します。NFS サービスを再起動する方法 を参照してください。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
# /etc/init.d/nfs.server stop # /etc/init.d/nfs.server start |
/etc/dfs/dfstab に項目がある場合、デーモンは停止してから再起動します。
実行中の処理があるために NFS サーバーをリブートできなかった場合に、RPC を使用するすべてのサービスを再起動することなく rpcbind を再実行できます。この手順に従ってウォームスタートを完了します。
スーパーユーザー、またはそれと同等の役割になります。
役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。
rpcbind の PID を確認します。
ps を実行すると、PID の値が 2 列目に表示されます。
# ps -ef |grep rpcbind root 115 1 0 May 31 ? 0:14 /usr/sbin/rpcbind root 13000 6944 0 11:11:15 pts/3 0:00 grep rpcbind |
SIGTERM シグナルを rpcbind プロセスに送ります。
以下の例では、送信するシグナルは term で、プログラムの PID は 115 です (kill(1) のマニュアルページを参照)。このコマンドより、rpcbind は /tmp/portmap.file と /tmp/rpcbind.file に現在登録されているサービスのリストを作成します。
# kill -s term 115 |
-s term オプションを使用して rpcbind プロセスを終了させないと、rpcbind のウォームスタートを完了できません。その場合は、サーバーをリブートすることによってサービスを再開する必要があります。
rpcbind を再起動します。
rpcbind を再度ウォームスタートして、 kill コマンドにより作成されたファイルが参照されるようにします。ウォームスタートすると、すべての RPC サービスを再起動することなくプロセスを再開することができます。rpcbind(1M) のマニュアルページを参照してください。
# /usr/sbin/rpcbind -w |
-m オプションを指定して nfsstat コマンドを実行し、最新の NFS 情報を取得します。現在のサーバー名は、「currserver=」の後に表示されます。
% nfsstat -m /usr/local from bee,wasp:/export/share/local Flags: vers=3,proto=tcp,sec=sys,hard,intr,llock,link,synlink, acl,rsize=32768,wsize=32678,retrans=5 Failover: noresponse=0, failover=0, remap=0, currserver=bee |
Solaris 2.6 およびそれ以降のリリースに出たパッチに置き換えられた mount コマンドでは、無効なオプションを指定しても警告されません。コマンド行に入力したオプション、または /etc/vfstab から指定したオプションが有効であるかどうかを判断するには、次の手順に従います。
たとえば、次のコマンドが実行されたとします。
# mount -F nfs -o ro,vers=2 bee:/export/share/local /mnt |
次のコマンドを実行し、オプションを確認します。
% nfsstat -m /mnt from bee:/export/share/local Flags: vers=2,proto=tcp,sec=sys,hard,intr,dynamic,acl,rsize=8192,wsize=8192, retrans=5 |
bee からマウントされたファイルシステムは、プロトコルのバージョンが 2 に設定されています。 nfsstat コマンドを使用しても、一部のオプションの情報は表示されませんが、オプションを確認するにはこれが最も正確な方法です。
/etc/mnttab でエントリを確認します。
mount コマンドは、無効なオプションをマウントテーブルに追加することができません。そのため、mnttab ファイルに記述されているオプションとコマンド行のオプションが一致していることを特定してください。このようにすると、nfsstat コマンドにより報告されなかったオプションを特定することができます。
# grep bee /etc/mnttab bee:/export/share/local /mnt nfs ro,vers=2,dev=2b0005e 859934818 |
autofs の使用時、問題に遭遇することがあります。この節では、問題解決プロセスについてわかりやすく説明します。この節は、2 つのパートに分かれています。
この節では、autofs が生成するエラーメッセージのリストを示します。このリストは、2 つのパートに分かれています。
automount の詳細形式 (-v) オプションにより生成されるエラーメッセージ
通常表示されるエラーメッセージ
各エラーメッセージの後には、そのメッセージの説明と考えられる原因が続きます。
障害追跡時には、詳細形式 (-v) オプションで autofs プログラムを開始します。そうしないと、理由がわからないまま問題に遭遇することになります。
次の節は、autofs のエラー時に表示されがちなエラーメッセージと、起こりうる問題についての説明です。
直接マップのスキャン中、autofs が接頭辞 / のないエントリーキーを発見しました。直接マップ内のキーは、完全パス名でなくてはなりません。
間接マップのスキャン中、autofs が / を含むエントリーキーを発見しました。間接マップのキーは、パス名ではなく、単なる名称でなくてはなりません。
サーバー上のマウントデーモンが、server:pathname により (1 つまたは複数) 指定されます。サーバー上のエクスポートテーブルを確認してください。
autofs は、マウントに必要なマウントポイントを作成することができませんでした。この問題は、すべてのサーバーのエクスポートされたファイルシステムを階層的にマウントしようとする場合に頻繁に生じます。必要なマウントポイントは、マウントできないファイルシステム内にだけ存在するため、ファイルシステムはエクスポートできません。エクスポートされる親ファイルシステムは、読み取り専用でエクスポートされるため、マウントポイントを作成できません。
autofs はオートマウントマップ内に先頭にスペースを含むエントリを発見しました。この問題は、通常、マップエントリが不当である場合に発生します。次のような例があります。
fake /blat frobz:/usr/frotz |
この例では、autofs が 2 つ目の行に遭遇した場合に警告が生成されます。これは、最初の行がバックスラッシュ (\) で終端されていないためです。
必要とされるマップが配置されていません。このメッセージは、-v オプションが使用されている場合にだけ生成されます。マップ名のスペルとパス名を確認してください。
remount server:pathname on mountpoint: server not responding
autofs が、アンマウントしたファイルシステムの再マウントに失敗しました。
autofs が、既存のマウントポイント上にマウントしようとしました。このメッセージは、autofs 内で内部エラー (異常) が生じたことを意味しています。
オートマウンタのマウントポイントは、完全パス名で指定しなくてはなりません。マウントポイントのスペルとパス名を確認してください。
autofs は、マウントポイントが階層的な関係を持つことを許可しません。autofs マウントポイントは、他のオートマウントされたファイルシステムに含まれていてはなりません。
autofs が、server で示されるサーバーにコンタクトしようとしましたが、応答がありません。
hostname: exports: rpc_err
このエラーは、hostname からエクスポートリストを取得する場合に発生します。このメッセージは、サーバーまたはネットワークに問題があることを示します。
マップエントリが不適切な形式であり、autofs が処理できません。そのエントリを再確認してください。そのエントリにエスケープする必要のある文字が含まれている可能性があります。
mapname: nis_err
このエラーは、NIS マップのエントリを参照する場合に発生します。このメッセージは、NIS に問題がある可能性があることを示しています。
autofs がマウントに失敗しました。サーバーまたはネットワークに問題のある可能性があります。
autofs は、ディレクトリではない mountpoint に示される場所に自分自身をマウントすることができません。マウントポイントのスペルとパス名を確認してください。
autofs が、複製されたファイルシステムの場所を示すリスト内にあるサーバーへの照会パケットを送信できません。
autofs が、複製されたファイルシステムの場所を示すリスト内にあるいずれのサーバーからも応答を受けられません。
このようなエラーメッセージはすべて、複製されたファイルシステムのサーバーに対して ping を実行した際に問題が発生したことを示します。このメッセージは、ネットワークに問題がある可能性があることを示しています。
autofs が、パス名に関する pathconf 情報の取得に失敗しました。 (fpathconf(2) のマニュアルページを参照。)
autofs が、pathconf(2) に情報を提供する server に示されるサーバー上のマウントデーモンにコンタクトできませんでした。
/etc/auto* ファイルが実行ビットセットを持っている場合、オートマウンタは次のようなメッセージを生成するマップの実行を試みます。
/etc/auto_home: +auto_home: not found
この場合、auto_home ファイルは不適切な権限をもつことになります。このファイル内の各エントリは、よく似たエラーメッセージを生成します。ファイルへのこのような権限は、次のコマンドを入力することにより取り消す必要があります。
# chmod 644 /etc/auto_home |
この節では、エラーメッセージとそのエラーを発生させる原因となった状態について説明し、1 つ以上の解決策を提供しています。
Bad argument specified with index option - must be a file
Cannot establish NFS service over /dev/tcp: transport setup problem
このメッセージは、名前空間の中のサービス情報が更新されなかったときによく発生します。またこのメッセージは、UDP の状態を示すことがあります。この問題を解決するには、名前空間の中のサービスデータを更新します。NIS+ の場合、エントリは以下のとおりです。
nfsd nfsd tcp 2049 NFS server daemon nfsd nfsd udp 2049 NFS server daemon |
NIS と /etc/services の場合、エントリは以下のとおりです。
nfsd 2049/tcp nfs # NFS server daemon nfsd 2049/udp nfs # NFS server daemon |
Cannot use index option without public option
share コマンドの index オプションに public オプションを指定してください。index オプションを使用するには、公開ファイルハンドルを定義する必要があります。
Solaris 2.6 より前の Solaris では、share コマンドを使って公共ファイルハンドルを設定する必要があります。Solaris 2.6 以降では、公共ファイルハンドルはデフォルトで / に設定されるため、このエラーメッセージは出力されません。
Could not start daemon : error
このメッセージは、デーモンが異常終了するか、システムコールにエラーが発生した場合に表示されます。error の文字列によって、問題が特定されます。
Could not use public filehandle in request to server
このメッセージは、public オプションが指定されているにもかかわらず NFS サーバーが公共ファイルハンドルをサポートしていない場合に表示されます。この場合、マウントが失敗します。この問題を解決するには、公共ファイルハンドルを使用しないでマウント要求を行うか、NFS サーバーが公共ファイルハンドルをサポートするように設定し直します。
daemon running already with pid pid
error locking lock file
error checking lock file : error
NOTICE: NFS3: failing over from host1 to host2
filename: File too large
mount: ... server not responding:RPC_PMAP_FAILURE - RPC_TIMED_OUT
実行レベルの誤りか、rpcbind の停止かハングのため、マウント先のファイルシステムを共有しているサーバーがダウンしているかまたは到達できないことを示すメッセージです。
mount: ... server not responding: RPC_PROG_NOT_REGISTERED
マウント要求が rpcbind によって登録されているにもかかわらず、NFS マウントデーモン (mountd) が登録されていないことを示すメッセージです。
リモートディレクトリまたはローカルディレクトリが存在しないことを示すメッセージです。ディレクトリ名のスペルをチェックします。両方のディレクトリで ls コマンドを実行します。
mount: ...: Permission denied
コンピュータ名が、クライアントのリストに載っていないか、マウントするファイルシステムにアクセスできるネットグループに含まれていないことを示すメッセージです。showmount -e を実行し、アクセスリストを確認してください。
NFS fsstat failed for server hostname: RPC: Authentication error
さまざまな状況で発生するエラーです。もっともデバッグが困難なのは、ユーザーの属しているグループが多すぎる場合です。現在、ユーザーは最大 16 個のグループに属すことができますが、NFS マウントでファイルにアクセスしている場合は、それ以下になります。ただし、ユーザーが 17 個以上のグループに所属する方法もあります。NFS サーバーおよび NFS クライアントで Solaris 2.5 以降のリリースが動作している場合は、アクセス制御リストを使用して、必要なアクセス特権を与えることができます。
nfs mount: ignoring invalid option “ -option”
-option フラグが無効です。正しい構文を mount_nfs(1M) のマニュアルページで確認してください。
このエラーメッセージは、Solaris 2.6 以降、または Solaris 2.6 より前のバージョンにパッチを適用した状態で mount コマンドを実行したときには表示されません。
nfs mount: NFS can't support “nolargefiles”
NFS クライアントが、-nolargefiles オプションを使用して NFS サーバーからファイルシステムをマウントしようとしました。このオプションは、NFS ファイルシステムに対してはサポートされていません。
nfs mount: NFS V2 can't support “largefiles”
NFS バージョン 2 プロトコルでは、大規模ファイルを処理できません。大規模ファイルを扱う必要がある場合は、バージョン 3 を使用してください。
NFS server hostname not responding still trying
ファイル関連の作業中にプログラムがハングすると、NFS サーバーは停止します。このメッセージは、NFS サーバー (hostname) がダウンしているか、サーバーかネットワークに問題があることを示すものです。フェイルオーバー機能を使用している場合、hostname はサーバー名のリストになります。NFS クライアントの接続性を確認する方法を参照してください。
port number in nfs URL not the same as port number in port option
NFS URL のポート番号は、マウントの -port オプションのポート番号と一致していなければなりません。一致していないと、マウントは失敗します。同じポート番号にしてコマンドを再実行するか、ポート番号の指定を省略してください。原則として、NFS URL と -port オプションの両方にポート番号を指定しても意味がありません。
replicas must have the same version
NFS フェイルオーバー機能が正しく機能するためには、複製の NFS サーバーが同じバージョンの NFS プロトコルをサポートしていなければなりません。バージョンが混在することは許されません。
replicated mounts must be read-only
NFS フェイルオーバー機能は、読み書き可能としてマウントされたファイルシステムでは動作しません。ファイルシステムを読み書き可能としてマウントすると、ファイルが変更される可能性が高くなるためです。NFS のフェイルオーバー機能は、ファイルシステムがまったく同じであることが前提です。
replicated mounts must not be soft
複製されるマウントの場合、フェイルオーバーが発生するまでタイムアウトを待つ必要があります。soft オプションを指定すると、タイムアウトが開始してすぐにマウントが失敗するため、複製されるマウントには -soft オプションは指定できません。
share_nfs: Cannot share more than one filesystem with 'public' option
/etc/dfs/dfstab ファイルを調べて、-public オプションによって共有するファイルシステムを複数選択していないか確認してください。公開ファイルハンドルは、サーバーあたり 1 つしか設定できません。したがって、-public オプションで共有できるファイルシステムは 1 つだけです。
WARNING: No network locking on hostname:path: contact admin to install server change
NFS クライアントが、NFS サーバー上のネットワークロックマネージャと接続を確立できませんでした。この警告は、マウントできなかったことを知らせるためではなく、ロックが機能しないことを警告するために出力されます。
この章では、NFS コマンドの概要について説明します。また、NFS 環境のすべての構成要素とそれらが互いにどのように連係するかについても説明します。
ファイルによっては、いずれのコンピュータ上でも NFS アクティビティをサポートする必要があるファイルがあります。その多くは ASCII ファイルで、いくつかはデータファイルです。表 15–1 に、このようなファイルとその機能をまとめます。
表 15–1 NFS ファイル
ファイル名 |
機能 |
---|---|
ローカルファイルシステムにおけるデフォルトファイルシステムのタイプを示す |
|
lockd および nfsd の構成情報を示す |
|
NFS サーバーログデーモン (nfslogd) の構成情報を示す |
|
/etc/dfs/dfstab |
共有するローカルリソースを示す |
リモートファイルシステムにおけるデフォルトファイルシステムのタイプを示す |
|
共有されるローカルとリモートのリソースを示す。sharetab(4) のマニュアルページを参照。このファイルは編集しないこと |
|
自動マウントしたディレクトリを含む、現在マウントしているファイルシステムを示す。mnttab(4) のマニュアルページを参照。このファイルは編集しないこと |
|
/etc/netconfig | |
NFS サーバーログのための一般的な構成情報を示す |
|
nfslogd によるログ後処理のための情報を示す。このファイルは編集しないこと |
|
NFS のセキュリティサービスのリスト |
|
NFS クライアントがリモートでマウントしたファイルシステムを示す。rmtab(4) のマニュアルページを参照。このファイルは編集しないこと |
|
ローカルにマウントするファイルシステムを定義する。vfstab(4) のマニュアルページを参照 |
/etc/dfs/fstypes の最初の項目は、リモートファイルシステムにおけるデフォルトファイルシステムのタイプとして利用されることがしばしばあります。この項目は、NFS ファイルシステムのタイプをデフォルトとして定義します。
/etx/default/fs には、項目が 1 つしかありません。ローカルディスクにおけるデフォルトファイルシステムのタイプです。クライアントやサーバーでサポートするファイルシステムのタイプは、/kernel/fs のファイルを確認して決定することができます。
このファイルは、NFS サーバーログ機能を使用するときに使用されるいくつかのパラメータを定義します。次のパラメータを定義することができます。
ログファイルを元の状態に戻す前に経過させる必要がある時間数を決めるパラメータです。デフォルト値は 24 時間です。このパラメータはログファイルが大きくなり過ぎないように使用します。
nfslogd が、バッファーファイル内にさらに情報があるかどうかを確認するまでに休眠しなければならない秒数を設定するパラメータです。このパラメータは、構成ファイルの確認頻度も決定します。このパラメータと MIN_PROCESSING_SIZE によりバッファーファイルの処理頻度が決まります。デフォルト値は 300 秒です。この数値を増加させると、確認の回数が減ってパフォーマンスが向上します。
ファイルハンドルパスマッピングテーブル内でレコードを更新する間隔を秒数で指定します。デフォルト値は 86400 秒つまり 1 日です。このパラメータを使用すると、ファイルハンドルパスマッピングテーブルを常時更新しないで最新の状態に保つことができます。
バッファーファイルが処理してログファイルに書き込むための最小限のバイト数を設定します。このパラメータと IDLE_TIME によりバッファーファイルの処理頻度が決まります。デフォルト値は 524,288 バイトです。この数値を大きくするとバッファーファイルの処理回数が減ってパフォーマンスが向上します。
ファイルハンドルパスマッピングレコードを中断して除去できるようになるまでに経過しなければならない時間数を選択するパラメータです。デフォルト値は 168 時間、つまり 7 日間です。
このファイルは nfslogd で使用するログのパス、ファイル名、およびタイプを定義します。各定義はタグと関連付けられています。NFS サーバーのログを開始するためには、各ファイルシステムについてタグを付ける必要があります。広域タグはデフォルト値を定義します。必要に応じて、各タグに、次のパラメータを使用することができます。
ログファイルのデフォルトのディレクトリパスを指定するパラメータです。特に指定しない限り、デフォルトは /var/nfs です。
ファイルハンドルパスデータベースのパスとファイル名を選択するパラメータです。デフォルトは /var/nfs/fhtable です。
バッファーファイルのパスとファイル名を決定するパラメータです。デフォルトは /var/nfs/nfslog_workbuffer です。
ユーザーから読み取り可能なログファイルを作成するときに使用するフォーマットを選択します。基本フォーマットは、ftpd デーモンと同様なログファイルが作成されます。拡張フォーマットは、より詳細に表示されます。
パスが指定されていない場合は、defaultdir が定義するパスが使用されます。絶対パスを使用すると defaultdir を無効にすることができます。
ファイルを識別しやすくするために、ファイルを別々のディレクトリに入れておきます。次に、必要な変更の例を示します。
% cat /etc/nfs/nfslog.conf #ident "@(#)nfslog.conf 1.5 99/02/21 SMI" # . . # NFS server log configuration file. # global defaultdir=/var/nfs \ log=nfslog fhtable=fhtable buffer=nfslog_workbuffer publicftp log=logs/nfslog fhtable=fh/fhtables buffer=buffers/workbuffer |
この例では、log=publicftp と共有するファイルはすべて、次の値を使用します。
デフォルトのディレクトリは /var/nfs である
ログファイルは、/var/nfs/logs/nfslog* に保存される
ファイルハンドルパスデータベーステーブルは、/var/nfs/fh/fhtables に保存される
バッファーファイルは、/var/nfs/buffers/workbuffer に保存される
手順については、NFS サーバーログを有効にする方法を参照してください。
NFS アクティビティをサポートするには、システムが実行レベル 3 かマルチユーザーモードで動作したときに、いくつかのデーモンを開始します。mountd デーモンおよび nfsd デーモンは、サーバーであるシステム上で実行されます。サーバーデーモンの自動起動は、NFS ファイルシステムのタイプでラベル付けされた項目が /etc/dfs/sharetab に存在するかどうかで変わります。lockd デーモンおよび statd デーモンは、NFS クライアントおよび NFS サーバー上で実行され、NFS のファイルロックをサポートします。
この節では、次のデーモンについて説明します。
このデーモンは autofs サービスからのマウントおよびデマウント要求を処理します。このコマンドの構文は次のとおりです。
automountd [ -Tnv ] [ -D name= value ]
-T は、トレースを有効にする
-n は、すべての autofs ノード上で、ブラウズを無効にする
-v は、コンソールへのすべての状態メッセージを記録する
-D name= value は、name によって示されたオートマウントマップ変数の値を value に置き換える
このデーモンは NFS ファイルのレコードロックをサポートします。lockd デーモンは、ネットワークロックマネージャ (NLM) プロトコルについて、クライアントとサーバー間の RPC 接続を管理します。通常は、パラメータを指定しないで起動します。使用できるオプションは 3 つあります。lockd(1M) のマニュアルページを参照してください。これらのオプションは、コマンド行からも、/etc/default/nfs 内の任意の文字列を編集することによっても使用することができます。 /etc/default/nfs を変更すると、システムを再起動してもその変更は維持されます。 この機能は、Solaris 9 リリースでのみサポートされています。その他の Solaris リリースでこれらの変更を維持するには、/etc/init.d/nfs.client を変更します。
/etc/default/nfs に LOCKD_GRACE_PERIOD=graceperiod パラメータを追加すると、クライアントがサーバーのリブート後にロックを再要求する秒数を選択できます。NFS サーバーはこの秒数の間、それまでのロックの再要求処理しか実行しません。サービスに対する他の要求は、この時間が経過するまで待たされます。このオプションは NFS サーバーの応答性に関係するため、NFS サーバーでしか変更できません。デフォルト値は 45 秒です。この値を小さくすることにより、NFS クライアントは、サーバーのリブート後に、より迅速に処理を再開できます。ただし、この値を小さくすると、クライアントがすべてのロックを復元できない可能性が増します。デーモンに -g graceperiod オプションを指定して開始すると、コマンド行から同じ動作を実行することができます。
/etc/default/nfs に LOCKD_RETRANSMIT_TIMEOUT=timeout パラメータを追加すると、ロックの要求をリモートサーバーに再転送するまでの秒数を選択できます。このオプションは NFS クライアントのサービスに関係します。デフォルト値は 15 秒です。この値を小さくすると、トラフィックの多いネットワーク上の NFS クライアントに対する応答時間を改善できます。ただし、ロック要求が増えることによってサーバーの負荷が増す可能性があります。デーモンに -t timeout オプションを指定して開始すると、コマンド行から同じパラメータを使用できます。
/etc/default/nfs に LOCKD_SERVERS=nthreads パラメータを追加すると、サーバーが同時に処理できる各接続ごとのスレッドの最大数を指定できます。 この値は、NFS サーバーに対して予想される負荷に基づいて決定してください。デフォルト値は 20 です。TCP を使用する各 NFS クライアントは、NFS サーバーとの間で 1 つの接続を使用するため、各クライアントは、サーバー上で、最大 20 のスレッドを同時に使用することができます。UDP を使用するすべての NFS クライアントは、NFS サーバーと 1 つの接続を共有します。その場合、UDP 接続が使用できるスレッドの数を増やさなければならないことがあるかもしれません。各 UDP クライアントには、少なくとも 2 つのスレッドを許可します。ただし、この数は、クライアントの負荷により違います。そのため、クライアントごとに 2 つのスレッドを許可しても、十分ではない場合があります。多くのスレッドを使用する場合の不利な点は、これらのスレッドを使用すると、NFS サーバー上で使用するメモリーの容量が増えるという点です。ただし、スレッドを使用しない場合は、nthreads の値を増やしても影響がありません。デーモンに nthreads オプションを指定して開始すると、コマンド行から同じパラメータを使用できます。
このデーモンは、リモートシステムからのファイルシステムマウント要求を処理して、アクセス制御を行います。mountd デーモンは、/etc/dfs/sharetab を調べて、リモートマウントに使用可能なファイルシステムと、リモートマウントを実行できるシステムを判断します。このコマンドでは、-v オプションと -r オプションを使用できます。mountd(1M) のマニュアルページを参照してください。
-v オプションは、コマンドを詳細形式モードで実行します。クライアントが取得すべきアクセス権を NFS サーバーが決定するたびに、コンソールにメッセージが表示されます。この情報は、クライアントがファイルシステムにアクセスできない理由を調べるときに役立ちます。
-r オプションは、その後のクライアントからのマウント要求をすべて拒絶します。このオプションを指定しても、すでにファイルシステムがマウントされているクライアントには影響しません。
これは、他のクライアントからのファイルシステム要求を処理するデーモンです。このコマンドに対してはいくつかのオプションを指定できます。オプションをすべて確認するには nfsd(1M) のマニュアルページを参照してください。これらのオプションは、コマンド行からも、/etc/default/nfs 内の任意の文字列を編集することによっても使用することができます。 /etc/default/nfs を変更すると、システムをリブートしてもその変更は維持されます。 この機能は、Solaris 9 リリースでのみサポートされています。他のリリースで、これらの変更を維持するには、/etc/init.d/nfs.server を変更します。
/etc/default/nfs に NFSD_LISTEN_BACKLOG=length パラメータを追加すると、接続型トランスポートを使用した NFS および TCP の接続キューの長さを設定できます。デフォルト値は 32 エントリです。nfsd に -l オプションを指定して開始すると、コマンド行から同じ項目を選択できます。
/etc/default/nfs に NFSD_MAX_CONNECTIONS=#_conn パラメータを追加すると、接続型トランスポートごとの最大接続数を選択できます。#_conn のデフォルト値はありません。コマンド行から -c #_conn オプションを指定してデーモンを開始すると、同じパラメータを使用できます。
/etc/default/nfs に NFSD_SERVER=nservers パラメータを追加すると、サーバーが一度に処理する要求の最大数を選択できます。 デフォルト値は 1 ですが、起動スクリプトでは 16 が選択されます。コマンド行から nservers オプションを指定してnfsd を開始すると、同じように最大数を選択できます。
以前のバージョンの nfsd デーモンとは異なり、現在のバージョンの nfsd では複数のコピーを作成して要求を同時に処理することはありません。処理テーブルを ps でチェックすると、動作しているデーモンのコピーが 1 つしかないことがわかります。
このデーモンは実行された処理のログ機能を提供します。NFS オペレーションは、/etc/default/nfslogd で定義した構成オプションに基づいてサーバーのログに記録されます。NFS サーバーのログ機能がオンになると、選択されたファイルシステム上でのすべての RPC 操作の記録がカーネルによりバッファーファイルに書き込まれます。次に nfslogd がこれらの要求を後処理します。ログインおよび IP アドレスへの UID をホスト名に割り当てやすくするために、ネームサービススイッチが使用されます。識別されたネームサービスで一致するものが見つからない場合は、その番号が記録されます。
パス名へのファイルハンドルの割り当ても nfslogd により行われます。このデーモンは、ファイルハンドルパスマッピングテーブル内でこれらの割り当てを追跡します。/etc/nfs/nfslogd で識別される各タグについて 1 つのマッピングテーブルが存在します。後処理の後に、レコードが ASCII ログファイルに書き込まれます。
lockd とともに動作し、ロック管理機能にクラッシュ機能と回復機能を提供します。statd デーモンは、NFS サーバーにロックを保持するクライアントを追跡します。サーバーがクラッシュした場合は、サーバーのリブート中に、サーバー側 statd がクライアント側 statd にコンタクトします。次にクライアント側 statd は、サーバー上のすべてのロックを再要求します。クライアントがクラッシュすると、クライアント側 statd はサーバー側 statd にそのことを伝えるので、サーバー上のロックはクリアされます。このデーモンにオプションはありません。詳細は、statd(1M) のマニュアルページを参照してください。
Solaris 7 で、statd がクライアントを追跡する方法が改善されました。Solaris 7 より前のリリースの statd では、クライアントごとにそのクライアントの修飾されていないホスト名を使用して、/var/statmon/sm にファイルが作成されました。そのため、同じホスト名の 2 つのクライアントが異なるドメインに存在する場合や、クライアントが NFS サーバーと異なるドメインに存在する場合に、このファイルのネーミングが原因となり問題が発生していました。修飾されていないホスト名にはドメインや IP アドレスの情報がないため、このようなクライアントを区別する方法がありませんでした。これに対処するため、Solaris 7 の statd では、修飾されていないホスト名に対してクライアントの IP アドレスを使用して /var/statmon/sm にシンボリックリンクを作成します。このリンクは、次のようになります。
# ls -l /var/statmon/sm lrwxrwxrwx 1 daemon 11 Apr 29 16:32 ipv4.192.9.200.1 -> myhost lrwxrwxrwx 1 daemon 11 Apr 29 16:32 ipv6.fec0::56:a00:20ff:feb9:2734 -> v6host --w------- 1 daemon 11 Apr 29 16:32 myhost --w------- 1 daemon 11 Apr 29 16:32 v6host |
この例では、クライアントのホスト名は myhost で、IP アドレスは 192.9.200.1 です。他のホストが myhost という名前を持ち、ファイルシステムをマウントしていると、myhost というホスト名に対するシンボリックリンクは 2 つ作成されます。
次のコマンドは、スーパーユーザーとして実行しなければ、十分な効果がでません。しかし情報の要求は、すべてのユーザーが行うことができます。
このコマンドは autofs マウントポイントをインストールし、オートマスターファイル内の情報を各マウントポイントに関連付けます。このコマンドの構文は次のとおりです。
automount [ -t duration ] [ - v ]
-t duration はファイルシステムがマウントされた状態でいる時間 (秒) で、-v は詳細形式モードを選択します。詳細形式モードでこのコマンドを実行すると障害追跡が容易になります。
継続時間の値は、特に設定しないと 5 分に設定されます。通常はこの値が適切です。しかし、自動マウントされたファイルシステムの多いシステムでは、この値を増やす必要がある場合もあります。特に、サーバーを多くのユーザーが使用中の場合は、自動マウントされたファイルシステムを 5 分ごとにチェックするのは能率的でない場合があります。autofs ファイルシステムは 1800 秒 (30 分) ごとにチェックする方が適しています。5 分おきにファイルシステムのマウントを解除しないと、/etc/mnttab が大きくなることがあります。df が /etc/mnttab にある各エントリをチェックした時の出力を減らすには、-F オプション (df(1M) マニュアルページを参照) または egrep を使用して、df の出力にフィルタをかけます。
この継続時間を調節すると、オートマウンタマップへの変更が反映される速さを変更できるということも考慮すべきです。変更はファイルシステムがアンマウントされるまでは見ることができません。オートマウンタマップの変更方法については、マップの修正を参照してください。
このコマンドを使用すると、ある NFS クライアントのファイル、レコード、または共有のロックをすべて削除できます。このコマンドを実行するには、スーパーユーザーでなければなりません。NFS サーバーから、特定のクライアントに対するロックを解除できます。また、NFS クライアントから、特定のサーバーにおけるそのクライアントに対するロックを解除できます。次の例では、現在のシステム上の tulip という NFS クライアントに対するロックが解除されます。
# clear_locks tulip |
-s オプションを指定すると、どの NFS ホストからロックを解除するかを指定できます。このオプションは、ロックを作成した NFS クライアントで実行する必要があります。次の場合、クライアントによるロックが bee という名前の NFS サーバーから解除されます。
# clear_locks -s bee |
このコマンドは、クライアントがクラッシュしてロックを解除できないとき以外には使用しないでください。データが破壊されるのを避けるため、使用中のクライアントに関するロックは解除しないでください。
このコマンドを使用すると、指定したファイルシステムをローカルまたはリモートで、指定したマウントポイントに添付できます。詳細は、mount(1M) のマニュアルページを参照してください。引数を指定しないで mount を使用すると、現在コンピュータにマウントされているファイルシステムのリストが表示されます。
Solaris の標準インストールには、さまざまな種類のファイルシステムが含まれています。ファイルシステムの種類ごとにマニュアルページがあり、その種類に対して mount を実行するときに使用可能なオプションのリストが示されています。NFS ファイルシステムの場合は、mount_nfs(1M) です。UFS ファイルシステムの場合は、mount_ufs(1M) を参照してください。
Solaris 7 で、server:/pathname という標準の構文の代わりに NFS URL を使用して NFS サーバー上のマウントするパス名を指定することが可能になりました。詳細は、NFS URL を使用して NFS ファイルシステムをマウントする方法 を参照してください。
Solaris 2.6 以後の mount コマンドでは、無効なオプションがあっても警告されません。解釈できないオプションがあると無視されるだけです。予想外の結果が生じるのを避けるために、使用するオプションはすべて確認してください。
NFS ファイルシステムをマウントするときに -o フラグの後に指定できるオプションの一部を以下に示します。オプションの完全なリストについては、 mount_nfs(1M) のマニュアルページを参照してください。
この 2 つは、マウントが失敗したときの再試行の方法を選択するオプションです。-bg オプションの場合はバックグラウンドで、-fg オプションの場合はフォアグラウンドでマウントが試みられます。デフォルトは -fg です。常に使用可能にしておく必要のあるファイルシステムに対しては -fg が適しています。-fg オプションを指定すると、マウントが完了するまで、次の処理は行われません。-bg は、マウント要求が完了しなくてもクライアントは他の処理を実行できるため、必ずしも必要でないファイルシステムに適しています。
このオプションは大規模ファイル上で連続した読み取りをする際にパフォーマンスを向上させます。データは直接ユーザーバッファにコピーされます。クライアント上のカーネル内ではキャッシュへの書き込みは行なわれません。この機能はデフォルトではオフです。このオプションの使用例については、mount コマンドの使用を参照してください。
このオプションを使用すると、Solaris 2.6 を動作しているサーバーに置かれた 2G バイトを超えるサイズのファイルにアクセスできるようになります。大規模ファイルにアクセスできるかどうかは、サーバーでしか制御できません。したがって、このオプションは NFS バージョン 3 のマウントでは無視されます。デフォルトでは、Solaris 2.6 以後の UFS ファイルシステムはすべて largefiles オプション付きでマウントされます。NFS バージョン 2 プロトコルを使用したマウントで largefiles オプションを指定すると、エラーが発生してマウントできません。
この UFS マウント用のオプションを指定すると、ファイルシステム上に大規模ファイルが存在できないことが保証されます。mount_ufs(1M) のマニュアルページを参照してください。大規模ファイルの存在は NFS サーバー上でのみ制御できるため、NFS マウントを使用している場合は、nolargefiles オプションを指定できません。このオプションを指定してファイルシステムを NFS マウントしようとすると、エラーが発生して拒否されます。
このオプションを指定すると、NFS サーバーにアクセスするときに必ず公共ファイルハンドルを使用するようになります。NFS サーバーが公共ファイルハンドルをサポートしていれば、MOUNT プロトコルが使用されないため、マウント操作は短時間で行われます。また、MOUNT プロトコルを使用しないため、ファイアウォールを越えたマウントが可能です。
-rw オプションと -ro オプションは、ファイルシステムが読み書き可能と読み取り専用のどちらでマウントされるかを示します。デフォルトは読み書き可能で、これはリモートホームディレクトリやメールスプールディレクトリなどの、ユーザーによる変更が必要なファイルシステムに適しています。読み取り専用オプションは、ユーザーが変更してはいけないディレクトリに適しています。具体的には、マニュアルページの共有コピーなどです。
このオプションは、マウント時に使用される認証メカニズムを指定します。mode の値は、表 15–2 に示したもののいずれかでなければなりません。モードは、/etc/nfssec.conf ファイルにも定義されます。
表 15–2 NFS セキュリティモード
モード |
選択した認証サービス |
---|---|
krb5 |
Kerberos バージョン 5 |
krb5i |
Kerberos バージョン 5 で完成性を指定 |
krb5i |
Kerberos バージョン 5 で機密性を指定 |
none |
認証なし |
dh |
Diffie-Hellman (DH) 認証 |
sys |
UNIX の標準認証 |
soft オプションを指定してマウントされた NFS ファイルシステムは、サーバーが応答しなくなるとエラーを返します。hard オプションが指定されていると、サーバーが応答するまで再試行が続けられます。デフォルトは hard です。ほとんどのファイルシステムには hard を使用します。ソフトマウントされたファイルシステムからの値を検査しないアプリケーションが多いので、アプリケーションでエラーが発生してファイルが破壊される恐れがあるためです。アプリケーションが戻り値を確認する場合は、soft が使用されているとルーティングの問題などによってアプリケーションが正しく判断できず、ファイルが破壊されることがあります。原則として、soft は使用しないでください。hard オプションを指定した場合にファイルシステムが使用できなくなると、そのファイルシステムを使用するアプリケーションはファイルシステムが復旧するまでハングする可能性があります。
次の例を参照してください。
NFS バージョン 2 またはバージョン 3 では、次のコマンドはどちらもサーバー beeから NFS ファイルシステムを読み取り専用としてマウントします。
# mount -F nfs -r bee:/export/share/man /usr/man |
# mount -F nfs -o ro bee:/export/share/man /usr/man |
NFS バージョン 2 またはバージョン 3 では、次のコマンドは -O オプションを使用しているため、すでに /usr/man がマウントされている場合でも、強制的にマニュアルページをサーバー bee からローカルシステムにマウントします。次を参照してください。
# mount -F nfs -O bee:/export/share/man /usr/man |
NFS バージョン 2 またはバージョン 3 では、次のコマンドはクライアント側フェイルオーバー機能を使用します。
# mount -F nfs -r bee,wasp:/export/share/man /usr/man |
コマンド行から使用する場合、リスト内のサーバーがサポートしている NFS プロトコルは同じバージョンでなければなりません。コマンド行から mount を実行するときは、バージョン 2 とバージョン 3 のサーバーを混在させないでください。autofs を実行するときは、これらのサーバーを混在させることができます。autofs により、バージョン 2 またはバージョン 3 のサーバーの最適な組み合わせが自動的に選択されます。
次に、NFS バージョン 2 またはバージョン 3 において、mount コマンドに NFS URL を使用する例を示します。
# mount -F nfs nfs://bee//export/share/man /usr/man |
mount コマンドに引数を指定しないと、クライアントにマウントされたファイルシステムが表示されます。
% mount / on /dev/dsk/c0t3d0s0 read/write/setuid on Tues Jan 24 13:20:47 1995 /usr on /dev/dsk/c0t3d0s6 read/write/setuid on Tues Jan 24 13:20:47 1995 /proc on /proc read/write/setuid on Tues Jan 24 13:20:47 1995 /dev/fd on fd read/write/setuid on Tues Jan 24 13:20:47 1995 /tmp on swap read/write on Tues Jan 24 13:20:51 1995 /opt on /dev/dsk/c0t3d0s5 setuid/read/write on Tues Jan 24 13:20:51 1995 /home/kathys on bee:/export/home/bee7/kathys intr/noquota/nosuid/remote on Tues Jan 24 13:22:13 1995 |
このコマンドにより、現在マウントされているリモートファイルシステムが削除されます。umount コマンドは、テストのために -V オプションをサポートしています。また、-a オプションを使用することによって 1 度に複数のファイルシステムをアンマウントできます。-a オプションに mount_points を指定すると、そのファイルシステムがアンマウントされます。マウントポイントを指定しないと、/etc/mnttab のリストにあるファイルシステムのうち required でないものすべてのアンマウントが試みられます。required のファイルシステムとは、/、/usr、/var、/proc、/dev/fd、/tmp などです。ファイルシステムがすでにマウントされていて、/etc/mnttab に項目が指定されている場合、ファイルシステムのタイプのフラグを指定する必要はありません。
-f オプションを指定すると、使用中のファイルシステムがアンマウントされます。このオプションを使用して、マウントできないファイルシステムのマウントを試みたためにハングしたクライアントを復帰させることができます。
ファイルシステムのアンマウントを強制的に解除すると、ファイルへの書き込み中だった場合には、データを損失することがあります。
次の例では、/usr/man にマウントしたファイルシステムのマウントが解除されます。
# umount /usr/man |
次の例では、umount -a -V の実行結果が表示されます。
# umount -a -V umount /home/kathys umount /opt umount /home umount /net |
このコマンドでは、ファイルシステムのアンマウント自体は実行されないことに注意してください。
このコマンドを使用すると、ファイルシステムテーブルに指定したすべてのファイルシステム、または特定グループのファイルシステムをマウントできます。このコマンドを実行すると、次の操作を実行することができます。
-F FSType オプションを使用して、ファイルシステムのタイプを選択する
-r オプションを使用して、ファイルシステムテーブル中にリストされたリモートファイルシステムをすべて選択する
-l オプションを使用して、ローカルファイルシステムをすべて選択する
# mountall -F nfs |
# mountall -F nfs -r |
このコマンドを使用すると、ファイルシステムのグループをアンマウントできます。-k オプションは、mount_point に結び付けられているプロセスを終了させるには fuser -k mount_point コマンドを使用する必要があることを表します。-s オプションは、アンマウントを並行処理しないことを示します。-l は、ローカルファイルシステムだけを使用することを、-r はリモートファイルシステムだけを使用することを示します。-h host オプションは、指定されたホストのファイルシステムをすべてアンマウントすることを指定します。-h オプションは、-l または -r と同時に指定できません。
次のコマンドでは、リモートホストからマウントしたすべてのファイルシステムが切り離されます。
# umountall -r |
次のコマンドでは、bee サーバーからマウントしたすべてのファイルシステムが切り離されます。
# umountall -h bee |
このコマンドを使用すると、NFS サーバーのローカルファイルシステムをマウントできるようになります。また、システム上のファイルシステムのうち、現在共有しているもののリストを表示します。NFS サーバーが動作していないと、share コマンドは使用できません。NFS サーバーソフトウェアは、/etc/dfs/dfstab に項目がある場合、起動の途中で自動的に起動されます。NFS サーバーソフトウェアが動作していないと、このコマンドはエラーを報告しません。そのため、ソフトウェアが動作していることを確認する必要があります。
すべてのディレクトリツリーは共有できるオブジェクトです。ただし、各ファイルシステムの階層構造は、そのファイルシステムが位置するディスクスライスやパーティションで制限されます。たとえばルート (/) ファイルシステムを共有しても、/usr が同じディスクパーティションかスライスに存在しなければ、/usr を共有することはできません。通常、ルートはスライス 0 に、/usr はスライス 6 にインストールされます。また /usr を共有しても、/usr のサブディレクトリにマウントされているローカルディスクパーティションは共有できません。
すでに共有している大規模なファイルシステムの一部であるファイルシステムを共有することはできません。たとえば、/usr および /usr/local が同じディスクスライスにある場合は、/usr または /usr/local を共有できます。ただし、異なる共有オプションを指定してこれらのディレクトリを共有するには、/usr/local を別のディスクスライスに移動する必要があります。
読み取り専用で共有しているファイルシステムに、読み取りと書き込みが可能な状態で共有しているファイルシステムのファイルハンドルでアクセスすることができます。ただし、両方のファイルシステムが同じディスクスライスにある必要があります。より安全にこれらのファイルシステムを使用するには、読み取りと書き込みが設定されているファイルシステムを、読み取り専用で共有しているファイルシステムとは別のパーティションまたはディスクスライスに配置します。
pathname に指定したファイルシステムを、読み取りと書き込みの両方が可能な状態で共有するか、読み取り専用で共有するかを指定します。
ファイルシステムは、リストに記述されているクライアントに対してだけ、読み取り書き込みの両方が可能な状態で共有されます。それ以外の要求は拒否されます。accesslist に定義されるクライアントのリストは、Solaris 2.6 から拡張されました。詳細については、share コマンドを使ってアクセスリストを設定する を参照してください。このオプションは -ro オプションよりも優先されます。
NFS ファイルシステムで指定できるオプションは、次のとおりです。
このオプションを指定すると、NFS バージョン 2 プロトコルをサポートしている NFS サーバーが NFS バージョン 2 クライアントのアクセス制御を行うように設定できます。このオプションを指定しないと、すべてのクライアントは最小限のアクセスしかできません。指定すると、最大限のアクセスができるようになります。たとえば -aclok オプションを指定して共有したファイルシステムでは、1 人のユーザーが読み取り権を持っていれば全員が読み取りを許可されます。このオプションを指定しないと、アクセス権を持つべきクライアントからのアクセスが拒否される可能性があります。ユーザーに与えるアクセス権は、既存のセキュリティシステムによって決定します。アクセス制御リスト (ACL) の詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「アクセス制御リスト (ACL) の使用」を参照してください。
アクセス制御リスト (ACL) を使用するには、クライアントとサーバーが、NFS バージョン 3 プロトコルおよび NFS_ACL プロトコルをサポートしているソフトウェアを実行している必要があります。NFS バージョン 3 プロトコルしかサポートしていないソフトウェアの場合、クライアントは正しいアクセス権を取得できますが、ACL を操作することはできません。NFS_ACL プロトコルをサポートしていれば、正しいアクセス権を取得した上で ACL の操作も可能です。この両方をサポートしているのは、Solaris 2.5 およびその互換バージョンです。
uid は、認証されていないユーザーのユーザー ID を選択するために使用します。uid を -1 に設定すると、認証されていないユーザーからのアクセスは拒否されます。anon=0 とするとルートアクセス権を与えることができますが、これのオプションを指定すると、認証されていないユーザーにルートアクセス権を与えることになるため、代わりに root オプションを使用してください。
-index= filename オプションを使用すると、ユーザーが NFS URL にアクセスすると、ディレクトリのリストが表示されるのではなく、HTML (HyperText Markup Language) ファイルが強制的に読み込まれます。これは、HTTP URL がアクセスしているディレクトリに index.html ファイルが見つかるとブラウザのような動作をするというものです。このオプションを設定することは、httpd に対して DirectoryIndex オプションを指定するのと同じ意味です。たとえば、dfstab ファイルに、次のようなエントリがあるとします。
share -F nfs -o ro,public,index=index.html /export/web |
このとき、次の URL によって表示される情報はすべて同じです。
nfs://<server>/<dir> nfs://<server>/<dir>/index.html nfs://<server>//export/web/<dir> nfs://<server>//export/web/<dir>/index.html http://<server>/<dir> http://<server>/<dir>/index.html |
このオプションは、ファイルシステム用の NFS サーバーレコード構成情報の入った /etc/nfs/nfslog.conf 内のタグを指定します。NFS サーバーログ機能を使用可能にするにはこのオプションを選択する必要があります。
このオプションを使用すると、setuid モードまたは setgid モードを有効にしようとしても無視されます。NFS クライアントは、setuid か setgid のビットがオンの状態ではファイルを作成できません。
-public オプションは、WebNFS ブラウズのために追加されました。このオプションで共有できるのは、1 台のサーバーにつき 1 つのファイルシステムだけです。
サーバーが、リスト上のホストに対してルートアクセス権を与えます。デフォルトでは、サーバーはどのリモートホストにもルートアクセス権は与えません。選択されているセキュリティモードが -sec=sys 以外だと、accesslist に指定できるホストはクライアントだけです。accesslist に定義されたクライアントのリストは、Solaris 2.6 で拡張されました。詳細については、share コマンドを使ってアクセスリストを設定する を参照してください。
他のホストにルートアクセス権を与えるには、広い範囲でセキュリティが保証されていることが前提です。-root= オプションは十分慎重に使用してください。
mode は、ファイルシステムへのアクセス権を取得するために必要なセキュリティモードです。デフォルトのセキュリティモードは、UNIX の認証です。モードは複数指定できますが、コマンド行に指定するときは 1 行につき 1 つのセキュリティモードだけにしてください。-mode の各オプションは、次に -mode が出現するまでその後の -rw、-ro、-rw=、-ro=、-root=、-window= オプションに適用されます。-sec=none とすると、すべてのユーザーがユーザー nobody にマップされます。
value は、NFS サーバーで資格が有効な時間の上限です。デフォルトは 30000 秒 (8.3 時間) です。
Solaris 2.6 より前の Solaris では、share コマンドの -ro=、-rw=、-root= オプションに指定する accesslist の内容は、ホスト名かネットグループ名に限定されていました。Solaris 2.6 以降では、このアクセス制御リストにドメイン名、サブネット番号、およびアクセス権を与えないエントリも指定できます。この拡張により、名前空間を変更したり多数のクライアントを定義したリストを使用することなく、ファイルアクセス制御を単一のサーバーで簡単に管理できます。
次のコマンドでは、rose と lilac では読み取りと書き込みの両方のアクセスが認められますが、その他では、読み取りだけが許可されます。
# share -F nfs -o ro,rw=rose:lilac /usr/src |
次の例では、eng ネットグループのすべてのホストで読み取りだけができるようになります。rose クライアントでは、読み取りと書き込みの両方ができます。
# share -F nfs -o ro=eng,rw=rose /usr/src |
rw と ro には必ず引数が必要です。読み書き可能オプションを指定しないと、デフォルトによってすべてのクライアントが読み書き可能になります。
複数のクライアントが 1 つのファイルシステムを共有するには、同じ行にすべてのオプションを入力する必要があります。同じオブジェクトに対して share コマンドを何度も実行しても、最後に実行されたコマンドだけが有効になります。以下のコマンドでは、3 つのクライアントシステムで読み取りと書き込みができますが、rose と tulip では、ファイルシステムに root でアクセスできます。
# share -F nfs -o rw=rose:lilac:tulip,root=rose:tulip /usr/src |
複数の認証メカニズムを使ってファイルシステムを共有するときには、セキュリティモードの後に必ず -ro、-ro=、-rw、-rw=、-root、-window の各オプションを指定してください。この例では、eng というネットグループ内のすべてのホストに対して UNIX 認証が選択されています。これらのホストは、ファイルシステムを読み取り専用モードでしかマウントできません。ホスト tulip と lilac は、Diffie-Hellman (DH) 認証を使用すれば読み書き可能でファイルシステムをマウントできます。これらのオプションを指定すると、tulip および lilac は、DH 認証を使用していない場合でも、ファイルシステムを読み取り専用でマウントすることができます。ただし、ホスト名が eng ネットグループに含まれている必要があります。
# share -F nfs -o sec=dh,rw=tulip:lilac,sec=sys,ro=eng /usr/src |
デフォルトのセキュリティモードは UNIX 認証ですが、-sec オプションを使用している場合、この UNIX 認証は含まれなくなります。そのため、UNIX 認証を他の認証メカニズムとともに使用する場合は、-sec=sys オプションを指定する必要があります。
実際のドメイン名の前にドットを付けると、アクセスリスト中で DNS ドメイン名を使用できます。ドットの後の文字列はドメイン名です。完全指定のホスト名ではありません。次のエントリは、マウントから eng.sun.com ドメイン内のすべてのホストへのアクセスを許可するためのものです。
# share -F nfs -o ro=.:.eng.example.com /export/share/man |
この例で、「.」は、NIS または NIS+ 名前空間を通じて一致するすべてのホストに対応します。ネームサービスから返される結果にはドメイン名は含まれません。「.eng.example.com」というエントリは、名前空間の解決に DNS を使用するすべてのホストに一致します。DNS が返すホスト名は必ず完全指定の名前になるので、DNS と他の名前空間を組み合わせると長いエントリが必要です。
実際のネットワーク番号かネットワーク名の前に「@」を指定すると、アクセスリストの中でサブネット番号を使用できます。この文字は、ネットワーク名をネットグループ名や完全指定のホスト名と区別するためです。サブネットは、/etc/networks の中か NIS または NIS+ 名前空間の中で識別できなければなりません。次のエントリは、サブネット 129.144 が eng ネットワークと識別されている場合、すべて同じ意味を持ちます。
# share -F nfs -o ro=@eng /export/share/man # share -F nfs -o ro=@129.144 /export/share/man # share -F nfs -o ro=@129.144.0.0 /export/share/man |
2 番目と 3 番目のエントリは、ネットワークアドレス全体を指定する必要がないことを表しています。
ネットワークアドレスの先頭部分がバイトによる区切りでなく、CIDR (Classless Inter-Domain Routing) のようになっている場合には、マスクの長さをコマンド行で具体的に指定できます。この長さは、ネットワーク名かネットワーク番号の後ろにスラッシュで区切ってアドレスの接頭辞に有効ビット数として指定します。次に入力例を示します。
# share -f nfs -o ro=@eng/17 /export/share/man # share -F nfs -o ro=@129.144.132/17 /export/share/man |
この例で、「/17」はアドレスの先頭から 17 ビットがマスクとして使用されることを表します。CIDR の詳細は、RFC 1519 を参照してください。
また、エントリの前に「-」を指定することでアクセスの拒否を示すこともできます。エントリは左から右に読み込まれるため、アクセス拒否のエントリは次のようにそのエントリを適用するエントリの前に置く必要があることに注意してください。
# share -F nfs -o ro=-rose:.eng.example.com /export/share/man |
この例では、eng.example.com ドメイン内のホストのうち、rose を除いたすべてに対してアクセス権が許可されます。
このコマンドを使用すると、以前に使用可能な状態になっていたファイルシステムを、クライアントがマウントできないようにします。unshare コマンドを使用すると、share コマンドで共有したファイルシステムや、/etc/dfs/dfstab で自動的に共有しているファイルシステムが共有できないようになります。unshare コマンドを使って dfstab ファイルを使って共有していたファイルシステムの共有を解除する場合は、注意が必要です。一度実行レベル 3 を終了し再度実行レベル 3 を実行すると、ファイルシステムは再度共有されます。実行レベル 3 を終了しても変更内容を継続させるには、そのファイルシステムを dfstab ファイルから削除しなければなりません。
NFS ファイルシステムの共有を解除している場合、クライアントから既存マウントへのアクセスは禁止されます。クライアントにはファイルシステムがまだマウントされている可能性がありますが、ファイルにはアクセスできません。
次のコマンドでは、指定したファイルシステムの共有が解除されます。
# unshare /usr/src |
このコマンドを使用すると、複数のファイルシステムを共有することができます。オプションなしで使用すると、/etc/dfs/dfstab 内のすべてのエントリが共有されます。share コマンドを並べたファイルの名前を指定することができます。ファイル名を指定しないと、/etc/dfs/dfstab の内容が検査されます。「-」を使ってファイル名を置き換えれば、標準入力から share コマンドを入力できます。
次のコマンドでは、ローカルファイルに羅列されているすべてのファイルシステムが共有されます。
# shareall /etc/dfs/special_dfstab |
このコマンドを使用すると、現在共有されているリソースがすべて使用できなくなります。-F FSType オプションによって、/etc/dfs/fstypes に定義されているファイルシステムタイプのリストを選択します。このフラグによって、特定のタイプのファイルシステムだけを共有解除できます。デフォルトのファイルシステムタイプは、/etc/dfs/fstypes に定義されています。特定のファイルシステムを選択するには、unshare コマンドを使います。
次の例では、NFS タイプのすべてのファイルシステムの共有が解除されます。
# unshareall -F nfs |
このコマンドは、次のいずれかを表示します。
NFS サーバーから共有している、リモートマウントされたファイルシステムを持つすべてのクライアント
クライアントによってマウントされたファイルシステムのみ
共有されたファイルシステムおよびクライアントのアクセス情報
showmount [ -ade ] [ hostname ]
すべてのリモートマウントのリストを出力する。各エントリには、クライアント名とディレクトリが含まれる
クライアントがリモートマウントしたディレクトリのリストを表示する
共有されているファイル、またはエクスポートされたファイルのリストを表示する
表示する情報の取得元 NFS サーバーを指定する
hostname を指定しないと、ローカルホストを入力するように要求されます。
次のコマンドでは、すべてのクライアント、およびマウントしたディレクトリが表示されます。
# showmount -a bee lilac:/export/share/man lilac:/usr/src rose:/usr/src tulip:/export/share/man |
次のコマンドでは、マウントしたディレクトリが表示されます。
# showmount -d bee /export/share/man /usr/src |
次のコマンドでは、共有しているファイルシステムが表示されます。
# showmount -e bee /usr/src (everyone) /export/share/man eng |
このコマンドを使用すると、/etc/mnttab テーブルが作成されます。このテーブルは、mount コマンドと umount コマンドで参照されます。通常、このコマンドは、システムのブート時に自動的に実行されるため、手動で実行する必要はありません。
NFS の障害追跡には以下のコマンドを使用します。
このコマンドを使用すると、NFS と RPC 接続について統計情報を収集できます。このコマンドの構文は次のとおりです。
nfsstat [ -cmnrsz ]
クライアント側の情報を表示する
NFS マウントされた各ファイルシステムの統計を表示する
クライアント側とサーバー側の両方で、NFS の情報が表示されるように指定する
RPC 統計を表示する
サーバー側の情報を表示する
統計をゼロに設定するように指定する
コマンド行にオプションを指定しないと、-cnrs が使用されます。
新しいソフトウェアやハードウェアを処理環境に追加した場合、サーバー側の統計を収集することが、デバッグにたいへん役立ちます。このコマンドを週に最低 1 度は実行し、履歴を作成するようにしてください。統計を保存しておくと、以前のパフォーマンスの有効な記録となります。
# nfsstat -s Server rpc: Connection oriented: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 11420263 0 0 0 0 1428274 19 Connectionless: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 14569706 0 0 0 0 953332 1601 Server nfs: calls badcalls 24234967 226 Version 2: (13073528 calls) null getattr setattr root lookup readlink read 138612 1% 1192059 9% 45676 0% 0 0% 9300029 71% 9872 0% 1319897 10% wrcache write create remove rename link symlink 0 0% 805444 6% 43417 0% 44951 0% 3831 0% 4758 0% 1490 0% mkdir rmdir readdir statfs 2235 0% 1518 0% 51897 0% 107842 0% Version 3: (11114810 calls) null getattr setattr lookup access readlink read 141059 1% 3911728 35% 181185 1% 3395029 30% 1097018 9% 4777 0% 960503 8% write create mkdir symlink mknod remove rmdir 763996 6% 159257 1% 3997 0% 10532 0% 26 0% 164698 1% 2251 0% rename link readdir readdirplus fsstat fsinfo pathconf 53303 0% 9500 0% 62022 0% 79512 0% 3442 0% 34275 0% 3023 0% commit 73677 0% Server nfs_acl: Version 2: (1579 calls) null getacl setacl getattr access 0 0% 3 0% 0 0% 1000 63% 576 36% Version 3: (45318 calls) null getacl setacl 0 0% 45318 100% 0 0% |
このリストは、NFS サーバーの統計の例です。最初の 5 行は RPC に関するもので、残りの部分は NFS のアクティビティのレポートです。どちらの統計でも、badcalls または calls の平均値、および各週の calls の数がわかるので、問題を特定するのに役立ちます。badcalls 値は、クライアントからの不良メッセージ数を示しています。この値は、ネットワークのハードウェアに問題が発生したことを示す場合があります。
いくつかの接続では、ディスクに対する書き込みアクティビティが発生します。この数値の急激な上昇は障害の可能性を示すものなので、調査が必要です。NFS バージョン 2 の統計で注意が必要なのは、setattr、write、create、remove、rename、link、symlink、mkdir、および rmdir です。NFS バージョン 3 では、commit の値に特に注意します。ある NFS サーバーの commit レベルが、それと同等のサーバーと比較して高い場合は、NFS クライアントに十分なメモリーがあるかどうかを確認してください。サーバーの commit オペレーションの数は、クライアントにリソースがない場合に上昇します。
このコマンドを使用すると、各プロセスのスタックトレースが表示されます。pstack コマンドは、必ずプロセスの所有者、または root として実行してください。 pstack を使用して、プロセスがハングした場所を判断します。使用できるオプションは、チェックするプロセスの PID だけです。proc(1) のマニュアルページを参照してください。
以下の例では、実行中の nfsd プロセスをチェックしています。
# /usr/proc/bin/pstack 243 243: /usr/lib/nfs/nfsd -a 16 ef675c04 poll (24d50, 2, ffffffff) 000115dc ???????? (24000, 132c4, 276d8, 1329c, 276d8, 0) 00011390 main (3, efffff14, 0, 0, ffffffff, 400) + 3c8 00010fb0 _start (0, 0, 0, 0, 0, 0) + 5c |
この例では、プロセスが新規の接続要求を持っていることが示されています。これは正常な反応です。要求が行われた後でもプロセスがポーリングしていることがスタックからわかった場合、そのプロセスはハングしている可能性があります。NFS サービスを再起動する方法 の指示に従って問題を解決してください。ハングしたプログラムによって問題が発生しているかどうかを確実に判断するには、NFS の障害追跡の手順 を参照してください。
このコマンドは、システムで動作している RPC サービスに関する情報を生成します。RPC サービスの変更にも使用できます。このコマンドには、たくさんのオプションがあります。rpcinfo(1M) のマニュアルページを参照してください。以下は、このコマンドで使用できるオプションの構文です。
rpcinfo [ -m | -s ] [ hostname ]
rpcinfo -T transport hostname [ progname ]
rpcinfo [ -t | -u ] [ hostname ] [ progname ]
rpcbind 処理の統計テーブルを表示する
登録されているすべての RPC プログラムを簡易リストで表示する
特定のトランスポートまたはプロトコルを使用するサービスの情報を表示する
TCP を使用する RPC プログラムを検索する
UDP を使用する RPC プログラムを検索する
サービスに使用するトランスポートまたはプロトコルを選択する
必要な情報の取得元のサーバーのホスト名を選択する
情報の取得対象の RPC プログラムを選択する
hostname を指定しないと、ローカルホスト名が使用されます。progname の代わりに RPC プログラム番号が使用できますが、ユーザーが覚えやすいのは番号よりも名前です。NFS バージョン 3 が実行されていないシステムでは、-s オプションの代わりに -p オプションを使用できます。
このコマンドを実行すると、次の項目を含むデータを生成することができます。
RPC プログラム番号
特定プログラムのバージョン番号
使用されているトランスポートプロトコル
RPC サービス名
RPC サービスの所有者
次の例では、サーバーで実行されている RPC サービスに関する情報を収集しています。生成されたテキストには sort コマンドのフィルタをかけ、より読みやすくしています。この例では、RPC サービスの数行を省略しています。
% rpcinfo -s bee |sort -n program version(s) netid(s) service owner 100000 2,3,4 udp6,tcp6,udp,tcp,ticlts,ticotsord,ticots rpcbind superuser 100001 4,3,2 ticlts,udp,udp6 rstatd superuser 100002 3,2 ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 rusersd superuser 100003 3,2 tcp,udp,tcp6,udp6 nfs superuser 100005 3,2,1 ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 mountd superuser 100007 1,2,3 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 ypbind superuser 100008 1 ticlts,udp,udp6 walld superuser 100011 1 ticlts,udp,udp6 rquotad superuser 100012 1 ticlts,udp,udp6 sprayd superuser 100021 4,3,2,1 tcp,udp,tcp6,udp6 nlockmgr superuser 100024 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 status superuser 100029 3,2,1 ticots,ticotsord,ticlts keyserv superuser 100068 5 tcp,udp cmsd superuser 100083 1 tcp,tcp6 ttdbserverd superuser 100099 3 ticotsord autofs superuser 100133 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 100134 1 ticotsord tokenring superuser 100155 1 ticots,ticotsord,tcp,tcp6 smserverd superuser 100221 1 tcp,tcp6 - superuser 100227 3,2 tcp,udp,tcp6,udp6 nfs_acl superuser 100229 1 tcp,tcp6 metad superuser 100230 1 tcp,tcp6 metamhd superuser 100231 1 ticots,ticotsord,ticlts - superuser 100232 10 udp,udp6 sadmind superuser 100234 1 ticotsord gssd superuser 100235 1 tcp,tcp6 - superuser 100242 1 tcp,tcp6 metamedd superuser 100249 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 300326 4 tcp,tcp6 - superuser 300598 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 390113 1 tcp - unknown 805306368 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 1289637086 1,5 tcp - 26069 |
次の例では、サーバーの特定トランスポートを選択して、RPC サービスの情報を収集する方法について説明しています。
% rpcinfo -t bee mountd program 100005 version 1 ready and waiting program 100005 version 2 ready and waiting program 100005 version 3 ready and waiting % rpcinfo -u bee nfs program 100003 version 2 ready and waiting program 100003 version 3 ready and waiting |
最初の例では、TCP で実行されている mountd サービスをチェックしています。2 番目の例では、UDP で実行されている NFS サービスをチェックしています。
このコマンドは、ネットワーク上のパケットの監視によく使用されます。snoop コマンドは、root で実行する必要があります。このコマンドは、クライアントとサーバーの両方で、ネットワークハードウェアが機能しているかどうかを確認する方法としてよく使用されます。使用できるオプションは多数あります。snoop(1M) のマニュアルページを参照してください。以下で、このコマンドの概要を説明します。
snoop [ -d device ] [ -o filename ] [ host hostname ]
ローカルネットワークのインタフェースを指定する
受信したすべてのパケットを指定したファイルに保存する
特定のホストが送受信したパケットを表示する
-d device オプションは、複数のネットワークインタフェースがあるサーバーで特に有効です。ホストの設定以外にも、使用できる式が多数あります。コマンド式を grep で組み合わせることでも、十分に使用できるデータを生成できます。
障害追跡をする場合は、パケットの発信元と送信先のホストが正しいことを確認してください。また、エラーメッセージも調べてください。パケットをファイルに保存すると、データを簡単に参照することができます。
このコマンドを使用すると、プロセスがハングしたかどうかを確認できます。truss コマンドは、必ずプロセスの所有者、または root として実行してください。 このコマンドに指定できるオプションは多数あります。truss(1) のマニュアルページを参照してください。以下で、このコマンドの構文を説明します。
truss [ -t syscall ] -p pid
追跡するシステムコールを選択する
追跡するプロセスの PID を指定する
syscall には、追跡するシステムコールをコンマで区切って指定することもできます。また、syscall の指定を ! で始めると、そのシステムコールは追跡されなくなります。
次の例は、プロセスが新しいクライアントからの接続要求を待っていることを示しています。
# /usr/bin/truss -p 243 poll(0x00024D50, 2, -1) (sleeping...) |
これは正常な反応です。新規接続の要求が行われた後でも反応が変わらない場合、そのプロセスはハングしている可能性があります。NFS サービスを再起動する方法 の指示に従ってプログラムを修正してください。ハングしたプログラムによって問題が発生しているかどうかを確実に判断するには、NFS の障害追跡の手順 を参照してください。
以下の節では、NFS の複雑な機能をいくつか紹介します。
NFS サーバーがサポートしているクライアントが NFS バージョン 3 を使用していない場合に備えて、開始手順にはプロトコルレベルのネゴシエーションが含まれています。クライアントとサーバーの両方がバージョン 3 をサポートしていると、バージョン 3 が使用されます。どちらか片方でもバージョン 2 しかサポートしていないと、バージョン 2 が使用されます。
ネゴシエーションによって決まった値は、mount コマンドに -vers オプションを使用して変更できます。mount_nfs(1M) のマニュアルページを参照してください。ほとんどの場合、デフォルトによって最適なバージョンが選択されるため、ユーザーが指定する必要はありません。
開始時には、トランスポートプロトコルもネゴシエートされます。デフォルトでは、クライアントとサーバーの両方がサポートしているコネクション型トランスポートの中で最初に見つかったものが選択されます。それが見つからない場合は、コネクションレス型トランスポートプロトコルの中で最初に見つかったものが使用されます。システムでサポートされているトランスポートプロトコルのリストは、/etc/netconfig にあります。TCP はコネクション型トランスポートプロトコルで、Solaris 2.6 からサポートされています。UDP はコネクションレス型トランスポートプロトコルです。
NFS プロトコルのバージョンとトランスポートプロトコルが両方ともネゴシエーションによって決まった場合は、NFS プロトコルのバージョンがトランスポートプロトコルよりも優先されます。UDP を使用する NFS バージョン 3 プロトコルの方が、TCP を使用する NFS バージョン 2 プロトコルよりも優先されます。 mount コマンドでは NFS プロトコルのバージョンもトランスポートプロトコルも手動で選択できます。mount_nfs(1M) のマニュアルページを参照してください。ほとんどの場合、ネゴシエーションによって選択されるオプションの方が適切です。
ファイル転送サイズは、クライアントとサーバーの間でデータを転送するときに使用されるバッファーのサイズです。原則として、ファイル転送サイズが大きいほどパフォーマンスが向上します。NFS バージョン 3 には転送サイズに上限はありませんが、Solaris 2.6 以降がデフォルトで提示するバッファーサイズは 32K バイトです。クライアントは、必要であればマウント時にこれより小さい転送サイズを提示することができますが、ほとんどの場合その必要はありません。
転送サイズは、NFS バージョン 2 を使用しているシステムとはネゴシエートされません。このとき、ファイル転送サイズの上限は 8K バイトに設定されます。
mount コマンドに対して -rsize オプションと -wsize オプションを使用すると、転送サイズを手動で設定できます。PC クライアントの一部では転送サイズを小さくする必要があります。また、NFS サーバーが大きなファイル転送サイズに設定されている場合は、転送サイズを大きくすることができます。
クライアントがサーバーからファイルシステムをマウントするとき、クライアントはサーバーからファイルハンドルを取得する必要があります。ファイルハンドルは、そのファイルシステムに対応していなければなりません。そのためには、クライアントとサーバーの間でいくつかのトランザクションが発生します。この例では、クライアントはサーバーから /home/terry をマウントします。snoop によって追跡したトランザクションは、次のとおりです。
client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP server -> client PORTMAP R GETPORT port=33492 client -> server MOUNT3 C Null server -> client MOUNT3 R Null client -> server MOUNT3 C Mount /export/home9/terry server -> client MOUNT3 R Mount OK FH=9000 Auth=unix client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP server -> client PORTMAP R GETPORT port=2049 client -> server NFS C NULL3 server -> client NFS R NULL3 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OK |
この追跡結果では、クライアントがまずマウントポート番号を NFS サーバーの portmap サービスに要求します。クライアントが取得したマウントポート番号 (33492) は、サーバーに対する存在確認のために使用されます。このポート番号でサービスが実行中であることが確認できると、クライアントはマウントを要求します。この要求により、サーバーはマウントされるファイルシステムに対するファイルハンドル (9000) を送ります。これに対してクライアントは、NFS ポート番号を要求します。クライアントはサーバーからポート番号を受け取ると、NFS サービス (nfsd) を ping します。また、そのファイルハンドルを使うファイルシステムに関する NFS 情報を要求します。
次の追跡結果では、クライアントは public オプションを使ってファイルシステムをマウントしています。
client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry server -> client NFS R LOOKUP3 OK FH=9000 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OK |
デフォルトの公共ファイルハンドル (0000) を使用しているために、すべてのトランザクションにポートマップサービスから情報が与えられ、NFS ポート番号を決定するためのトランザクションはありません。
-public オプションを使用すると、マウントが失敗することがあります。NFS URL を組み合わせると、状況がさらに複雑になる可能性があります。これらのオプションを使用した場合にファイルシステムがどのようにマウントされるかは、次のとおりです。
public オプションと NFS URL – 公共ファイルハンドルが使用されます。公共ファイルハンドルがサポートされていないと、マウントは失敗します。
public オプションと通常のパス – 公共ファイルハンドルが使用されます。公共ファイルハンドルがサポートされていないと、マウントは失敗します。
NFS URL のみ – NFS サーバーでサポートされていれば、公共ファイルハンドルを使用します。公共ファイルハンドルを使用するとマウントが失敗する場合は、MOUNT プロトコルを使ってマウントします。
通常のパスのみ – 公共ファイルハンドルは使用しないでください。MOUNT プロトコルが使用されます。
クライアント側のフェイルオーバー機能を使用すると、NFS クライアントは同じデータを利用できる複数のサーバーを知ることができるため、現在のサーバーが使用不能になっても、ほかのサーバーに切り替えることができます。ファイルシステムが使用不能になる原因には次のものがあります。
ファイルシステムが接続しているサーバーのクラッシュ
サーバーの過負荷
ネットワーク障害
通常、このような場合のフェイルオーバー機能はユーザーにはわかりません。つまり、フェイルオーバー機能はクライアント上のプロセスを中断することなく実行されます。
フェイルオーバー機能が行われるためには、ファイルシステムが読み取り専用でマウントされている必要があります。また、ファイルシステムが完全に同じでないとフェイルオーバー機能は成功しません。ファイルシステムが同一になる条件については、複製されたファイルシステムとはを参照してください。フェイルオーバー機能の候補としては、静的なファイルシステム、または変更の少ないファイルシステムが適しています 。
同じ NFS マウント上では、CacheFS 機能とクライアント側のフェイルオーバー機能の両方は使用できません。CacheFS ファイルシステムは、それぞれについて追加情報が格納されています。この情報はフェイルオーバーの際に更新できないため、ファイルシステムをマウントするときにはフェイルオーバー機能と CacheFS のどちらか片方の機能しか使用できません。
各ファイルシステムについて用意すべき複製の数を決める要素はさまざまです。理想的には、サーバーを 2 台以上設置します。それぞれのサーバーが複数のサブネットをサポートする必要があります。これは、各サブネットに一意のサーバーを設置するよりもよい方法です。フェイルオーバー処理の際にはリストにある各サーバーが確認されます。そのため、サーバーの台数を増やすと、それぞれのマウント処理が遅くなります。
フェイルオーバー機能のプロセスを完全に理解するには、次の 2 つの用語を理解する必要があります。
フェイルオーバー – 複製されたファイルシステムをサポートしているサーバーのリストから、1 つのサーバーを選択するプロセス。通常、ソートされたリストの順番を元に、次のサーバーが応答するならばそのサーバーが使用される
再マッピング – 新しいサーバーを使用すること。クライアントは、正常な状態のときにリモートファイルシステム上のアクティブなファイルのそれぞれのパス名を格納する。再マッピング時には、そのパス名に基づいて新しいサーバー上のファイルを検出する
フェイルオーバー機能に関して、あるファイルシステムのすべてのファイルが元のファイルシステムのファイルとサイズも vnode タイプも同じ場合に、そのファイルシステムを「複製」といいます。アクセス権、作成日付などのファイル属性は関係ありません。ファイルサイズまたは vnode タイプが異なると再マッピングは失敗し、元のサーバーが再び使用可能になるまでプロセスはハングします。
複製されたファイルシステムを保守するには、rdist や cpio などのファイル転送メカニズムを使います。複製されたファイルシステムを更新すると不整合が発生するので、できるだけ以下を守ってください。
新しいバージョンのファイルをインストールするときは、あらかじめ古いバージョンのファイル名を変更する
クライアントによる使用が少ない夜間に更新を実行する
更新は小規模にとどめる
コピーの数を最小限にする
ソフトウェアパッケージの一部は、ファイルに読み取りロックをかける必要があります。そのようなソフトウェアが正常に動作できるようにするため、読み取り専用ファイルシステムに対しても読み取りロックがかけられるようになっています。ただし、これはクライアント側でしか認識されません。サーバー側で意識されないため、再マッピングされてもロックはそのまま残ります。ファイルはもともと変更が許されないので、サーバー側でファイルをロックする必要はありません。
Solaris 2.6 およびその互換バージョンでは、2G バイトを超えるファイルを扱えます。デフォルトでは、UFS ファイルシステムはこの新機能を活かすために -largefiles オプション付きでマウントされます。以前のリリースでは、2G バイトを超えるファイルは扱えません。具体的な方法については NFS サーバー上で大規模ファイルを無効にする方法 を参照してください。
-largefiles オプションを使ってサーバー上のファイルシステムをマウントする場合、大規模ファイルにアクセスするために Solaris 2.6 NFS クライアントを変更する必要はありません。ただし、Solaris 2.6 のコマンドすべてで大規模ファイルを扱えるわけではありません。大規模ファイルを扱えるコマンドについては、largefile(5) を参照してください。大規模ファイル用機能拡張を備えた NFS バージョン 3 プロトコルをサポートしていないクライアントは、大規模ファイルには一切アクセスできません。Solaris 2.5 クライアントでは、NFS バージョン 3 プロトコルを使用することはできますが、大規模ファイルを扱う機能は含まれていません。
NFS サーバーログ機能は NFS の読み取りと書き込み、およびこのファイルシステムを変更する操作の記録を提供します。このデータは情報へのアクセスを追跡するのに利用できます。さらに、この記録は、情報へのアクセスを測定する定量的な方法を提供します。
ログ機能が有効になっているファイルシステムにアクセスすると、カーネルが raw データをバッファーファイルに書き込みます。このデータには、次の内容が含まれています。
タイムスタンプ
クライアントの IP アドレス
要求者の UID
アクセスされているファイルまたはディレクトリオブジェクトのファイルハンドル
発生した処理のタイプ
nfslogd デーモンはこの raw データを、ログファイルに保存される ASCII レコードに変換します。使用可能なネームサービス機能が一致しているものを見つけると、その変換中に IP アドレスはホスト名に変更され、UID はログインに変更されます。ファイルハンドルはパス名にも変換されます。デーモンはファイルハンドルを追跡し、情報を別のファイルハンドルパステーブルに保存して、変換を完了します。このようにすると、ファイルハンドルにアクセスされるたびに、パスを識別し直す必要がなくなります。nfslogd をオフにするとファイルハンドルパステーブルのマッピングが変更されなくなるため、デーモンは常に実行させておく必要があります。
WebNFS サービスとは、あるディレクトリに置かれたファイルを、公開ファイルハンドルを使ってクライアントからアクセスできるようにするものです。ファイルハンドルは、NFS クライアントがファイルを識別できるようにカーネルが生成するアドレスです。公開ファイルハンドルの値はあらかじめ決まっているため、サーバーがクライアントに対してファイルハンドルを生成する必要はありません。定義済みのファイルハンドルを使用するというこの機能によって、MOUNT プロトコルが不要になってネットワークトラフィックが減り、クライアントにとってはプロセスが高速化します。
デフォルトでは、NFS サーバーの公開ファイルハンドルはルートファイルシステムに対して設定されます。このデフォルトのため、サーバーに対してマウント権限を持っているすべてのクライアントに対して WebNFS アクセス権が与えられます。公開ファイルハンドルは、share コマンドによって任意のファイルシステムに切り替えることができます。
あるファイルシステムに対するファイルハンドルをクライアントが持っているとき、アクセスするファイルに対応するファイルハンドルを知るには LOOKUP を実行します。 NFS プロトコルでは、パス名の構成要素を 1 度に 1 つしか評価できません。したがって、ディレクトリ階層のレベルが 1 つ増えるたびに 1 回ずつ LOOKUP を実行します。公開ファイルハンドルからの相対パスに対して LOOKUP を実行する場合には、WebNFS サーバーは複数構成要素参照によって 1 度にパス名全体を評価できます。複数構成要素参照により、WebNFS サーバーはパス名の中のディレクトリレベルを 1 つずつファイルハンドルに変換しなくても目的のファイルに対するファイルハンドルを配信できます。
また、NFS クライアントは、単一の TCP 接続を介して、複数のファイルを同時にダウンロードすることができます。このようにして接続すると、サーバーに複数の接続を設定することによる負荷をかけることなく、すばやくアクセスすることができます。Web ブラウザアプリケーションも複数ファイルを同時にダウンロードできますが、それぞれのファイルに独自の接続が確立されます。WebNFS ソフトウェアは接続を 1 つしか使用しないため、サーバーに対するオーバーヘッドを軽減できます。
パス名の中の最後の構成要素が他のファイルシステムに対するシンボリックリンクである場合、通常の NFS アクティビティによってあらかじめそのファイルへのアクセス権を持っていれば、クライアントはそのファイルにアクセスできます。
通常、NFS URL は公開ファイルハンドルからの相対位置として評価されます。パスの先頭にスラッシュを 1 つ追加すると、サーバーのルートファイルシステムからの相対位置に変更できます。次の例では、公開ファイルハンドルが /export/ftp ファイルシステムに設定されていればこの 2 つの NFS URL は同等です。
nfs://server/junk nfs://server//export/ftp/junk |
Solaris 8 リリースから、WebNFS クライアントが WebNFS サーバーと、選択されたセキュリティメカニズムについてネゴシエーションできるようにする新しいプロトコルがあります。この新しいプロトコルは、セキュリティネゴシエーションマルチコンポーネントルックアップを使用しています。これは、WebNFS プロトコルの以前のバージョンで使用されていたマルチコンポーネントルックアップの拡張版です。
WebNFS クライアントは、公共ファイルハンドルを使って通常のマルチコンポーネントルックアップ要求を行うことにより、このプロセスを開始します。このクライアントには、サーバーがどのようにしてこのパスを保護しているかについての知識がないため、デフォルトのセキュリティメカニズムが使用されます。デフォルトのセキュリティメカニズムでは不十分な場合は、サーバーは AUTH_TOOWEAK エラーを返します。このメッセージは、そのデフォルトメカニズムが有効ではなく、クライアントはより強力なメカニズムを使用する必要があることを意味しています。
クライアントは、AUTH_TOOWEAK エラーを受信すると、サーバーに対してどのセキュリティメカニズムが必要か決定するように要求します。この要求が成功すると、サーバーは、指定されたパスに必要なセキュリティメカニズムの配列を返します。このセキュリティメカニズムの配列のサイズによっては、クライアントは完全な配列を得るためにさらに要求を出さなければならない場合があります。サーバーが WebNFS セキュリティネゴシエーションをサポートしていない場合は、この要求は失敗します。
要求が成功すると、WebNFS クライアントは、クライアントがサポートしている最初のセキュリティメカニズムを配列から選択します。その後、クライアントは、選択したセキュリティメカニズムを使用して、通常のマルチコンポーネントルックアップ要求を発行し、ファイルハンドルを獲得します。この後に続くすべての NFS 要求は、選択されたセキュリティメカニズムとファイルハンドルを使って出されます。
HTTP を使用する Web サイトで実現可能な機能のいくつかは、WebNFS ではサポートされていません。この違いは、NFS サーバーはファイルを送るだけであるため、特別な処理はすべてクライアントで行う必要があることが原因です。ある Web サイトを WebNFS と HTTP 両方のアクセスに対応させるには、以下を考慮してください。
NFS によるブラウズでは CGI スクリプトは実行されません。したがって、CGI スクリプトを多用している Web サイトを含むファイルシステムは、NFS によるブラウズに適していない可能性があります。
ブラウザからは、形式の異なるファイルを扱うために別のビューアを起動されることがあります。NFS URL からそうしたファイルにアクセスすると、ファイル名からファイルタイプが判別できるならば外部のビューアが起動されます。ブラウザは、NFS URL が使用されている場合、標準の MIME タイプで決まっているファイル名拡張子をすべて認識します。WebNFS ソフトウェアは、ファイルの内容からファイルタイプを判別しません。したがって、ファイルタイプはファイル名の拡張子だけから判別されます。
NFS によるブラウズでは、サーバー側のイメージマップ (クリック可能なイメージ) は使用できません。ただし、クライアント側のイメージマップ (クリック可能なイメージ) は、場所とともに URL が定義されているため使用できます。文書サーバーからの応答は不要です。
NFS 環境は、アーキテクチャやオペレーティングシステムの異なるコンピュータから構成されるネットワーク上でファイルシステムを共有するためには、強力で使いやすい手段です。しかし、NFS の操作によるファイルシステムの共有を便利にする機能が、一方ではセキュリティ上の問題につながっています。今まで、NFS はほとんどのバージョンで UNIX (AUTH_SYS) 認証を使用してきましたが、現在では AUTH_DH のようなより強力な認証方式も使用可能です。UNIX 認証を使用している場合、NFS サーバーは、要求をしたユーザーではなくコンピュータを認証して、ファイル要求を認証します。そのため、クライアントユーザーは、su を実行してファイルの所有者を装ったりすることができます。DH 認証では、NFS サーバーはユーザーを認証するため、このような操作が困難になります。
スーパーユーザーへのアクセス権とネットワークプログラミングについての知識があれば、誰でも任意のデータをネットワークに入れ、ネットワークから任意のデータを取り出すことができます。ネットワークに対するもっとも危険な攻撃は、データをネットワークに持ち込むような攻撃です。たとえば、有効なパケットを生成したり、または「対話」を記録し後で再生することによってユーザーを装うなどの手段があります。これらはデータの整合性に影響を与えます。許可を持つユーザーを装うことなく、単にネットワークトラフィックを受信するだけの受動的な盗み聞きならば、データの整合性が損なわれることはないため、それほど危険ではありません。ネットワーク上でやりとりされるデータを暗号化すると、機密情報のプライバシを保護できます。
ネットワークのセキュリティ問題に対する共通の対処方法は、解決策を各アプリケーションにゆだねることです。さらに優れた手法としては、すべてのアプリケーションを対象として、標準の認証システムを導入することです。
Solaris オペレーティングシステムには、NFS が実装されるメカニズムであるリモート手続き呼び出し (RPC) のレベルで、認証システムが組み込まれています。このシステムは Secure RPC と呼ばれ、ネットワーク環境のセキュリティを大幅に向上させるとともに、NFS のセキュリティを強化します。Secure RPC の機能を利用した NFS システムを Secure NFS システムといいます。
Secure RPC は Secure NFS システムの基本となるメカニズムです。Secure RPC の目標は、少なくともタイムシェアリングシステム程度に安全なシステムを構築することです。タイムシェアリングシステムでは、すべてのユーザーが 1 台のコンピュータを共有します。タイムシェアリングシステムはログインパスワードによりユーザーを認証します。データ暗号化規格 (DES) 認証でも、同じ認証処理が実行されます。ユーザーは、ローカル端末の場合と同じように、任意のリモートコンピュータにログインできます。ユーザーのログインパスワードは、ネットワークセキュリティへのパスポートです。タイムシェアリングでは、システム管理者は信頼のおける人で、パスワードを変更して誰かを装うようなことはしないという道徳上の義務を負います。Secure RPC では、ネットワーク管理者は「公開鍵」を格納するデータベースのエントリを変更しないという前提で信頼されています。
RPC 認証システムを理解するには、 「資格 (credential)」と「ベリファイア」という 2 つの用語を理解する必要があります。ID バッジを例にとれば、資格とは、名前、住所、誕生日など人間を識別するものです。ベリファイアとはバッジに添付された写真です。バッジの写真をその所持者と照合することによって、そのバッジが盗まれたものではないことを確認できます。RPC では、クライアントプロセスは RPC 要求のたびに資格とベリファイアの両方をサーバーに送信します。クライアントはサーバーの資格をすでに知っているため、サーバーはベリファイアだけを送り返します。
RPC の認証機能は拡張が可能で、UNIX、DH、および KERB などのさまざまな認証システムを組み込むことができます。
ネットワークサービスで UNIX 認証を使用する場合、資格にはクライアントのコンピュータ名、UID、GID、グループアクセスリストが含まれ、べりファイアには何も含まれません。ベリファイアが存在しないため、root ユーザーは su などのコマンドを使用して、適切な資格を偽ることができます。UNIX 認証でのもう 1 つの問題は、ネットワーク上のすべてのコンピュータを UNIX コンピュータと想定していることです。UNIX 認証を異機種ネットワーク内の他のオペレーティングシステムに適用した場合、これは正常に動作しません。
UNIX 認証の欠点を補うために、Secure RPC では DH 認証を使います。
DH 認証は、Data Encryption Standard (DES) と Diffie-Hellman 公開鍵暗号手法を使ってネットワーク上のユーザーとコンピュータの両方を認証します。DES は、標準の暗号化メカニズムです。Diffie-Hellman 公開鍵暗号手法は、2 つの鍵、つまり公開鍵と秘密鍵を持つ暗号方式です。 公開鍵と秘密鍵は名前空間に格納されます。NIS では、これらのキーは public-key マップに保存されています。これらのマップにはすべての認証の候補ユーザーの公開鍵と秘密鍵が入っています。このマップの設定方法については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。
DH 認証のセキュリティは、送信側が現在時刻を暗号化する機能に基づいていて、受信側はこれを復号化して、自分の時刻と照合します。タイムスタンプは DES を使用して暗号化されます。この方式が機能するには次の条件が必要です。
2 つのエージェントの現在時刻が一致している。
送信側と受信側が同じ暗号化鍵を使用する。
ネットワークが時間同期プログラムを実行する場合、クライアントとサーバー上の時間は自動的に同期されます。時間同期プログラムを使用できない場合、ネットワーク時間ではなく、サーバーの時間を使ってタイムスタンプを計算できます。クライアントは、RPC セッションを開始する前にサーバーに時間を要求し、自分のクロックとサーバーのクロックとの時間差を計算します。タイムスタンプを計算するときには、この差を使ってクライアントのクロックを補正します。サーバーがクライアントの要求を拒否するほど、クライアントとサーバーのクロック同期がずれた場合、DH 認証システムはサーバーとの間で再び同期をとります。
クライアントとサーバーは、ランダムな対話鍵 (セッションキーとも呼ばれる) を生成することによって、同じ暗号化鍵に到達します。次に、公開鍵暗号手法 (公開鍵と秘密鍵を必要とする暗号化方式) を使って共通鍵を推理します。この共通鍵は、クライアントとサーバーだけが推理できる鍵です。対話鍵は、クライアントのタイムスタンプを暗号化および復号化するために使用されます。共通鍵は、この対話鍵を暗号化および復号化するために使用されます。
Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos での暗号化は DES に基づいています。Kerberos サポートは、現在では Secure RPC の一部としては供給されていませんが、Solaris 9 リリースには、サーバー側とクライアント側の実装が含まれています。Solaris 9 に実装されている Kerberos 認証については、『 Solaris のシステム管理 (セキュリティサービス)』の「SEAM について」を参照してください。
Secure RPC を使用する場合は、次の点に注意してください。
サーバーがクラッシュしたとき周囲に誰もいない場合 (停電の後など) には、システムに格納されていた秘密鍵はすべて消去されます。そのためどのプロセスからも、セキュリティ保護されたネットワークサービスにアクセスしたり NFS ファイルシステムをマウントしたりできません。リブート中の重要な処理は、通常 root として実行されます。そのため、root の秘密鍵を別に保存していればこれらのプロセスを実行できますが、その秘密鍵を復号化するパスワードを入力することはできません。keylogin -r を使用すると root の秘密鍵がそのまま /etc/.rootkey に格納され、keyserv がそれを読み取ります。
システムによっては、シングルユーザーモードで起動し、コンソールには root のログインシェルが表示されてパスワードの入力が要求されないことがあります。このような場合は、物理的なセキュリティが不可欠です。
ディスクレスコンピュータのブートは、完全に安全とはいえません。ブートサーバーになりすましてリモートコンピュータに対する秘密鍵の入力を記録するような、不正なカーネルを誰かがブートすることが考えられます。Secure NFS システムによって保護されているのはカーネルとキーサーバーが起動した後だけです。そうでないと、ブートサーバーからの応答を認証することができません。このような制限は重大な問題につながる可能性がありますが、この部分を攻撃するにはカーネルのソースコードを使用した高度な技術が必要です。また、不法行為の痕跡が残ります。つまり、ネットワークを通じてブートサーバーにポーリングすれば、不正なブートサーバーの場所がわかります。
ほとんどの setuid プログラムは root が所有者です。root の秘密鍵が /etc/.rootkey に格納されていれば、これらのプログラムは正常に動作します。しかし、ユーザーが所有者である setuid プログラムは動作しない可能性があります。たとえば、ある setuid プログラムの所有者が dave であり、ブート後 dave が 1 度もログインしていないとします。このプログラムはセキュリティ保護されたネットワークサービスにはアクセスできません。
リモートコンピュータに (login、rlogin、または telnet を使用して) ログインし、keylogin を使ってアクセスすると、自分のアカウントへのアクセスを許したことになります。これは、秘密鍵が相手側のコンピュータのキーサーバーに渡され、キーサーバーがその秘密鍵を格納したためです。このプロセスが問題になるのは、相手側のリモートコンピュータを信用できない場合だけです。しかし、疑いがある場合は、パスワードを要求するリモートコンピュータにはログインしないでください。代わりに NFS 環境を使用して、そのリモートコンピュータから共有されているファイルシステムをマウントします。または、keylogout を使ってキーサーバーから秘密鍵を消去します。
ホームディレクトリが共有されていて -o sec=dh オプションが指定されていると、リモートログインによって問題が生じる可能性があります。/etc/hosts.equiv ファイルまたは ~/.rhosts ファイルに、パスワードを要求するように設定されていない場合は、ログインが成功します。ただし、ローカルで認証されていないため、ユーザーは自分のホームディレクトリにアクセスできません。パスワードを要求され、入力したパスワードがネットワークパスワードと一致すれば、自分のホームディレクトリにアクセスできます。
autofs は 3 種類のマップを使用します。
マスターマップ
直接マップ
間接マップ
auto_master マップでは、ディレクトリからマップへの関連付けを行います。このマップは、すべてのマップを指定するマスターリストであり、autofs が参照します。auto_master ファイルの内容の例を次に示します。
# Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /- auto_direct -ro |
この例では、汎用の auto_master ファイルに auto_direct マップのための追加が行われています。マスターマップ /etc/auto_master の各行は、次の構文に従っています。
mount-point map-name [ mount-options ]
mount-point は、ディレクトリのフル (絶対) パス名です。このディレクトリが存在しない場合、可能ならば autofs はこのディレクトリを作成します。このディレクトリが存在し、しかも空ではない場合、マウントすることによってその内容が隠されます。この場合、autofs は警告を出します。
マウントポイントとして /- を指定すると、マップが直接マップであり、このマップ全体に関連付けられている特定のマウントポイントがないことを表します。
map-name 名は、位置に対する指示またはマウント情報を検出するために、autofs が使用するマップです。この名前がスラッシュ (/) で始まる場合、autofs はこの名前をローカルファイルとして解釈します。そうでない場合、autofs はネームサービススイッチ構成ファイル (/etc/nsswitch.conf) で指定される検索によりマウント情報を検索します。また、/net には、特別なマップを使用します。詳細は、マウントポイント /netを参照してください。
mount-options は省略できます。map-name のエントリに他のオプションがある場合を除き、map-name で指定されたエントリのマウントに適用されるオプションをコンマで区切って並べます。特定のファイルシステムのマウントオプションについては、各ファイルシステムについてのマニュアルページを参照してください。 たとえば、NFS 固有のマウントオプションについては、mount_nfs(1M) のマニュアルページを参照してください。 NFS 固有のマウントポイントの場合、bg (バックグラウンド) オプションと fg (フォアグラウンド) オプションは適用されません。
# で始まる行はコメント行です。その行のテキストの最後まですべて無視されます。
長い行を短い行に分割するには、行末にバックスラッシュ (\) を入力します。入力できる文字数の上限は 1024 です。
2 つのエントリで同じマウントポイントが使用されるときは、1 番目のエントリは automount コマンドが使用します。2 番目のエントリは無視されます。
マウントポイント /home は、/etc/auto_home (間接マップ) に記述されたエントリがマウントされるディレクトリです。
autofs はすべてのコンピュータで動作し、デフォルトでは /net と /home (自動マウントされるホームディレクトリ) をサポートします。このデフォルトは、NIS ならば auto.master マップ、NIS+ ならば auto_master テーブルを使用して、またはローカルの /etc/auto_master ファイルを編集することによって変更できます。
autofs は、特別なマップ -hosts 内の全エントリをディレクトリ /net の下にマウントします。これは hosts データベースだけを使用する組み込みマップです。たとえば、hosts データベースにあるコンピュータ gumbo が、ファイルシステムのどれかをエクスポートするとします。次のコマンドを入力すると、現在のディレクトリがコンピュータ gumbo のルートディレクトリに変更されます。
% cd /net/gumbo |
なお、autofs はホスト gumbo のエクスポートされたファイルシステムだけをマウントできます。つまり、ローカルディスク上のファイルシステムではなく、ネットワークユーザーが使用できるサーバー上のファイルシステムです。したがって、gumbo にあるすべてのファイルとディレクトリは、/net/gumbo では利用できない場合があります。
/net を使用したアクセスでは、サーバー名はパスの中に指定されるため、位置に依存します。したがって、エクスポートされるファイルシステムを別のサーバーに移動すると、そのパスは使用できなくなります。このような場合は /net を使用しないで、そのファイルシステムに対応するエントリをマップの中に設定します。
autofs はマウント時だけサーバーのエクスポートリストを調べます。サーバーのファイルシステムが一度マウントされると、そのファイルシステムがアンマウントされ、次にマウントされるまで autofs はそのサーバーをチェックしません。したがって、新たにエクスポートされたファイルシステムは、それがサーバーからアンマウントされ、再度マウントされるまでは見えません。
直接マップは自動マウントポイントです。つまり、直接マップによって、クライアント上のマウントポイントとサーバー上のディレクトリが直接対応付けられます。直接マップには完全パス名があり、明示的に関係を示します。次に一般的な /etc/auto_direct マップを示します。
/usr/local -ro \ /bin ivy:/export/local/sun4 \ /share ivy:/export/local/share \ /src ivy:/export/local/src /usr/man -ro oak:/usr/man \ rose:/usr/man \ willow:/usr/man /usr/games -ro peach:/usr/games /usr/spool/news -ro pine:/usr/spool/news \ willow:/var/spool/news |
key [ mount-options ] location
key は直接マップでのマウントポイントのパス名です。
mount-options は、このマウントに適用するオプションです。これらのオプションが必要なのは、マップのデフォルトと異なる場合だけです。特定のファイルシステムのマウントオプションについては、各ファイルシステムについてのマニュアルページを参照してください。 たとえば、CacheFS 固有のマウントオプションについては、mount_cachefs(1M) のマニュアルページを参照してください。
location はファイルシステムの位置を示します。NFS ファイルシステムならば server:pathname、High Sierra ファイルシステム (HSFS) ならば :devicename という形式で 1 つまたは複数のファイルシステムを指定します。
pathname にオートマウントされたマウントポイントを含めることはできません。 pathname は、実際のファイルシステムの絶対パスでなければなりません。 たとえば、ホームディレクトリの位置は、server:/home/username ではなく、server:/export/home/username として指定する必要があります。
マスターマップと同様、# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。長い行を短い行に分割するには、行の最後にバックスラッシュを入力します。
すべてのマップにおいて、直接マップ内のエントリは、/etc/vfstab 内の対応するエントリにもっともよく似ています。/etc/vfstab のエントリは、次のようになっているとします。
dancer:/usr/local - /usr/local/tmp nfs - yes ro |
直接マップ内では、同じエントリが次のようになります。
/usr/local/tmp -ro dancer:/usr/local |
オートマウンタマップの間では、オプションの連結はされません。オートマウンタマップに追加されたどのオプションも、前に検索されたマップに表示されているすべてのオプションを上書きします。たとえば、auto_master マップに指定されているオプションは、他のマップの中の対応するエントリによって上書きされます。
この種類のマップについては、他にも重要な機能があります。autofs がクライアント用のもっとも近い読み取り専用ファイルを選択する方法 (複数ロケーション) を参照してください。
例 15–1 にある /- というマウントポイントは、auto_direct の中のエントリを具体的なマウントポイントに関連付けないように autofs に指示します。間接マップの場合は、auto_master ファイルに定義されたマウントポイントを使います。直接マップの場合は、名前付きマップ内で指定したマウントポイントを使用します。直接マップ内では、キー、つまりマウントポイントは完全パス名であることに注意してください。
NIS または NIS+ の auto_master ファイルには、直接マップのエントリは 1 つしか存在できません。マウントポイントは 1 つの名前空間の中で一意でなければならないためです。auto_master がローカルファイルならば、重複しないかぎり直接マップのエントリがいくつあってもかまいません。
間接マップは、キーの置換値を使ってクライアント上のマウントポイントとサーバー上のディレクトリとを対応させます。間接マップは、ホームディレクトリなどの特定のファイルシステムをアクセスするのに便利です。auto_home マップは間接マップの一例です。
key [ mount-options ] location
key は間接マップでの単純名 (スラッシュなし) です。
mount-options は、このマウントに適用するオプションです。これらのオプションが必要なのは、マップのデフォルトと異なる場合だけです。特定のファイルシステムのマウントオプションについては、各ファイルシステムについてのマニュアルページを参照してください。 たとえば、NFS 固有のマウントオプションについては、mount_nfs(1M) のマニュアルページを参照してください。
location はファイルシステムの位置を示します。server:pathname の形式により 1 つまたは複数のファイルシステムを指定します。
pathname にオートマウントされたマウントポイントを含めることはできません。 pathname は、実際のファイルシステムの絶対パスでなければなりません。 たとえば、ディレクトリの位置は、server:/net/server/usr/local ではなく、server :/usr/local として指定する必要があります。
マスターマップと同様、# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。長い行を短い行に分割するには、行の最後にバックスラッシュ (\) を入力します。例 15–1 に、次のエントリを含む auto_master マップを示します。
/home auto_home -nobrowse |
auto_home は、/home のもとでマウントされるエントリを含む間接マップの名前です。通常、 auto_home マップには、次のパスが含まれています。
david willow:/export/home/david rob cypress:/export/home/rob gordon poplar:/export/home/gordon rajan pine:/export/home/rajan tammy apple:/export/home/tammy jim ivy:/export/home/jim linda -rw,nosuid peach:/export/home/linda |
例として、前のマップがホスト oak にあると想定します。パスワードデータベースに、ユーザー linda のホームディレクトリが /home/linda であることを示すエントリがあるとします。linda がコンピュータ oak にログインするたびに、autofs は、コンピュータ peach にあるディレクトリ /export/home/linda をマウントします。彼女のホームディレクトリは、読み書き可能な nosuid にマウントされます。
次のような状況が発生したと想定してください。ユーザー linda のホームディレクトリがパスワードデータベースに、/home/linda として表示されます。Linda も含め誰でも、前の例のマップを参照するマスターマップで設定されたどのコンピュータからでも、このパスにアクセスできます。
こうした状況のもとでは、ユーザー linda はこれらのどのコンピュータでも login や rlogin を実行し、代わりに彼女用のホームディレクトリをマウントさせることができます。
さらに、これで Linda は次のコマンドも入力できます。
% cd ~david |
autofs は彼女のために David のホームディレクトリをマウントします (すべてのアクセス権で許可されている場合)。
オートマウンタマップの間では、オプションの連結はされません。オートマウンタマップに追加されたどのオプションも、前に検索されたマップに表示されているすべてのオプションを上書きします。たとえば、auto_master マップに含まれているオプションは、他のいずれかのマップの対応するエントリによって上書きされます。
ネームサービスのないネットワークで、Linda が自分のファイルにアクセスするには、ネットワーク上のすべてのシステムで、すべての関連ファイル (/etc/passwd など) を変更する必要があります。NIS では、NIS マスターサーバーで変更を行い、関連するデータベースをスレーブのデータベースに伝達します。NIS+ を稼働中のネットワークでは、変更後に関連データベースがスレーブサーバーに自動的に伝達されます。
autofs は、自動的に適切なファイルシステムをマウントするためのクライアント側のサービスです。クライアントが現在マウントされていないファイルシステムをアクセスしようとすると、autofs ファイルシステムはその要求に介入し、automountd を呼び出して要求されたディレクトリをマウントします。automountd はディレクトリを検索してマウントし、応答します。応答を受け取ると、autofs は待たせてあった要求の処理を続行させます。以降にそのマウントを参照すると、その要求は autofs によってリダイレクトされます。ファイルシステムに最後にアクセスしてから一定時間が経過し、autofs がそのファイルシステムを自動的にアンマウントするまで、automountd の介入は不要となります。
自動マウントを行うのに、次のコンポーネントが相互に動作します。
automount コマンド
autofs ファイルシステム
automountd デーモン
automount コマンドは、システム起動時に呼び出され、マスターマップファイル auto_master を読み取って autofs マウントの最初のセットを作成します。これらの autofs のマウントは起動時に自動的にはマウントされません。後でファイルシステムがマウントされるポイントです。このようなポイントをトリガーノードと呼ぶこともあります。
autofs マウントが設定されると、要求があったときにファイルシステムをマウントすることができます。たとえば、autofs が、現在マウントされていないファイルシステムをアクセスする要求を受け取ると、automountd を呼び出して要求されたファイルシステムを実際にマウントさせます。
autofs マウントをマウントしたら、必要に応じて automount コマンドを実行し、autofs マウントを更新します。このコマンドは、auto_master マップにあるマウントのリストと、マウントテーブルファイル /etc/mnttab (前のバージョンでは /etc/mtab) にあるマウントされたファイルシステムのリストを比較します。その後、automount によって、適切な変更が加えられます。このプロセスにより、システム管理者は auto_master 内のマウント情報を変更し、autofs デーモンを停止したり再起動したりすることなく、それらの変更結果を autofs プロセスに使用させることができます。ファイルシステムがマウントされれば、以後のアクセスに automountd は不要になります。次に automountd が必要になるのは、ファイルシステムが自動的にアンマウントされたときです。
mount とは異なり、automount はマウントすべきファイルシステムを調べるために /etc/vfstab ファイル (これは各コンピュータごとに異なる) を参照しません。automount コマンドは、ドメイン内とコンピュータ上で名前空間とローカルファイルを通して制御されます。
次の図では、autofs のしくみの概要を簡単に説明します。
自動マウントデーモンである automountd は、ブート時に /etc/init.d/autofs スクリプトによって起動されます (図 15–1 を参照)。このスクリプトは automount コマンドも実行します。このコマンドはマスターマップを読み取り、autofs のマウントポイントをインストールします。詳細は、autofs のナビゲーションプロセス開始法 (マスターマップ) を参照してください。
autofs は、自動マウント操作とアンマウント操作をサポートするカーネルファイルシステムの 1 つです。
autofs マウントポイントで、ファイルシステムへのアクセスが要求された場合は、次の動作が行われます。
autofs がその要求に介入します。
autofs は要求されたファイルシステムをマウントするよう、automountd にメッセージを送信します。
automountd がマップからファイルシステム情報を見つけ、マウントを実行します。
autofs は、介入した要求の実行を続行させます。
一定時間そのファイルシステムがアクセスされないと、autofs はそのファイルシステムをアンマウントします。
autofs サービスによって管理されるマウントは、手動でマウントまたはアンマウントは行わないでください。たとえこの操作がうまくいったとしても、autofs サービスはオブジェクトがアンマウントされたことを認識しないので、一貫性が損なわれる恐れがあります。リブートによって、autofs のマウントポイントがすべて消去されます。
autofs は一連のマップを探索することによって、ネットワークをナビゲートします。マップは、ネットワーク上の全ユーザーのパスワードエントリや、ネットワーク上の全ホストコンピュータの名前などの情報を含むファイルです。マップには UNIX の管理ファイルに相当するネットワーク規模の管理ファイルも含まれています。マップはローカルに使用するか、あるいは NIS や NIS+ のようなネットワークネームサービスを通じて使用できます。ユーザーは Solaris 管理コンソールツールを使用して、自分の環境ニーズに適合するマップを作成します。autofs のネットワークナビゲート法の変更 (マップの変更) を参照してください。
automount コマンドはシステムの起動時にマスターマップを読み取ります。図 15–2 に示すように、マスターマップ内の各エントリは、直接または間接のマップ名、そのパス、およびそのマウントオプションです。エントリの順序は重要ではありません。automount は、マスターマップ内のエントリとマウントテーブル内のエントリを比較して、現在のリストを生成します。
マウント要求が発生したときに autofs サービスが何を実行するかは、オートマウンタマップの設定によって異なります。マウントプロセスの基本はすべてのマウントで同じですが、指定されているマウントポイントとマップの複雑さによって結果が変わります。Solaris 2.6 ではマウントプロセスも変更され、トリガーノードも作成されるようになりました。
autofs マウントプロセスの説明のために、以下のファイルがインストールされていると仮定します。
$ cat /etc/auto_master # Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /share auto_share $ cat /etc/auto_share # share directory map for automounter # ws gumbo:/export/share/ws |
/share ディレクトリがアクセスされると、autofs サービスは /share/ws に対するトリガーノードを作成します。これは、/etc/mnttab の中では以下のようなエントリになります。
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### |
/share/ws ディレクトリがアクセスされると、autofs サービスは以下の手順を実行します。
サーバーのマウントサービスが有効かどうかを確認するために、そのサービスに対して ping を行います。
要求されたファイルシステムを、/share の下にマウントします。これで、/etc/mnttab ファイルには以下のエントリが追加されます。
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### ##### |
オートマウンタファイルに複数の層が定義されていると、マウントプロセスは多少複雑になります。前の例の /etc/auto_shared ファイルを拡張して、次の行を追加したとします。
# share directory map for automounter # ws / gumbo:/export/share/ws /usr gumbo:/export/share/ws/usr |
この場合、/share/ws マウントポイントがアクセスされたときのマウントプロセスは基本的に最初の例と同じです。また、/share/ws ファイルシステムの中に次のレベル (/usr) へのトリガーノードを作成することにより、そのレベルがアクセスされたときにマウントできるようにします。この例でトリガーノードが作成されるためには、NFS に /export/share/ws/usr が存在している必要があります。
階層的にマウントを指定する場合は、-soft オプションは使用しないでください。この制限についての説明は、autofs アンマウント を参照してください。
一定時間アクセスがないためにアンマウントされるときは、マウントと反対の順序で実行されます。あるディレクトリより上位のディレクトリが使用中であれば、それより下のディレクトリだけがアンマウントされます。アンマウントすると、トリガーノードがすべて削除され、ファイルシステムがアンマウントされます。ファイルシステムが使用中であれば、アンマウントは失敗してトリガーノードは再インストールされます。
階層的にマウントを指定する場合は、-soft オプションは使用しないでください。-soft オプションを使用すると、トリガーノードを再インストールする要求がタイムアウトすることがあります。トリガーノードを再インストールできないと、マウントの次の階層にアクセスできません。この問題を解決するには、オートマウンタを使用して、階層にあるすべてのコンポーネントのマウントを解除します。オートマウンタでマウントを解除するには、ファイルシステムのマウントが自動的に解除されるのを待つか、システムをリブートします。
/usr/local -ro \ /bin ivy:/export/local/sun4\ /share ivy:/export/local/share\ /src ivy:/export/local/src /usr/man -ro oak:/usr/man \ rose:/usr/man \ willow:/usr/man /usr/games -ro peach:/usr/games /usr/spool/news -ro pine:/usr/spool/news \ willow:/var/spool/news |
マウントポイント /usr/man および /usr/spool/news には複数の場所があり、/usr/man のマウントポイントは 3 つ、/usr/spool/news のマウントポイントは 2 つの場所が記述されています。このような場合、複製された場所のどこからマウントしてもユーザーは同じサービスを受けられます。ユーザーの書き込みまたは変更が可能ならば、その変更をロケーション全体で管理しなければならなくなるので、この手順は、読み取り専用のファイルシステムをマウントするときにだけ意味があります。あるときに、あるサーバー上のファイルを変更し、またすぐに別のサーバー上で「同じ」ファイルを変更しなければならないとしたら、たいへん面倒な作業になります。この利点は、もっとも利用しやすいサーバーが、そのユーザーの手をまったく必要としないで自動的にマウントされるということです。
ファイルシステムを複製として設定してあると (複製されたファイルシステムとは を参照)、クライアントはフェイルオーバー機能を使用できます。最適なサーバーが自動的に決定されるだけでなく、そのサーバーが使用できなくなるとクライアントは自動的に 2 番目に適したサーバーを使います。フェイルオーバー機能は、Solaris 2.6 の新機能です。
複製として設定するのに適しているファイルシステムの例は、マニュアルページです。大規模なネットワークでは、複数のサーバーがマニュアルページをエクスポートできます。どのサーバーからマニュアルページをマウントしても、そのサーバーが動作しており、しかもそのファイルシステムをエクスポートしているかぎり、問題ありません。上の例では、複数のマウント位置は、マップエントリ内のマウント位置のリストになっています。
/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man |
この例では、サーバー oak、rose、willow のどれからでもマニュアルページをマウントできます。どのサーバーが最適であるかは、次のいくつかの要素によって決まります。
特定レベルの NFS プロトコルをサポートしているサーバーの数
サーバーとの距離
重み付け
順位を決定するときには、NFS バージョン 2 と NFS バージョン 3 のプロトコルをサポートしているサーバーの数が数えられます。サポートしているサーバーの数が多いプロトコルがデフォルトになります。これによって、クライアントにとっては利用できるサーバーの数が最大になります。
プロトコルのバージョンが同じサーバーの組の中で数がもっとも多いものがわかると、サーバーのリストが距離によってソートされます。ローカルサブネット上のサーバーには、リモートサブネット上のサーバーよりも高い優先順位が付けられます。もっとも近いサーバーが優先されることにより、待ち時間が短縮されネットワークトラフィックは軽減されます。図 15–3 に、サーバーとの距離を示します。
ローカルサブネット上に同じプロトコルをサポートしているサーバーが複数あるときは、それぞれのサーバーに接続する時間が計測され、速いものが使用されます。優先順位には、重み付けも関係します (autofs と重み付け を参照してください)。
バージョン 3 のサーバーの方が多いと、優先順位の決定は複雑になります。通常、ローカルサブネット上のサーバーはリモートサブネット上のサーバーよりも優先されます。バージョン 2 のサーバーがあり、それがもっとも近いバージョン 3 サーバーよりも近いと状況が複雑になる可能性があります。ローカルサブネットにバージョン 2 サーバーがあり、もっとも近いバージョン 3 サーバーがリモートサブネット上にあると、バージョン 2 サーバーが優先されます。このことは、バージョン 3 サーバーの方がバージョン 2 サーバーよりも多い場合にしかチェックされません。バージョン 2 サーバーの方が多いと、バージョン 2 サーバーしか選択されません。
フェイルオーバー機能を指定していると、この優先順位はマウント時に 1 回、マウントするサーバーを選択するときにチェックされ、その後は選択されたサーバーが使用できなくなるたびにチェックされます。複数の場所を指定しておくと、個々のサーバーが一時的にファイルシステムをエクスポートできないときに便利です。
多くのサブネットを持つ大規模なネットワークでは、この機能は特に便利です。autofs は最も近いサーバーを選択するため、NFS のネットワークトラフィックをローカルネットワークセグメントに制限します。複数のネットワークインタフェースを持つサーバーの場合は、それぞれのインタフェースが別々のサーバーであるとみなして、各ネットワークインタフェースに対応付けられているホスト名を指定します。autofs はそのクライアントにいちばん近いインタフェースを選択します。
距離のレベルが同じサーバーから 1 つを選択するために、autofs マップに重み付けの値を追加することができます。例として、次の状況が考えられます。
/usr/man -ro oak,rose(1),willow(2):/usr/man |
括弧内の数値が重み付けを表します。重み付けのないサーバーの値はゼロであり、選択される可能性が最高になります。重み付けの値が大きいほど、そのサーバーが選択される可能性は低くなります。
重み付けは、サーバーの選択に関係する要素の中でもっとも小さい影響力しかありません。ネットワーク上の距離が同じサーバーの間で選択を行う場合に考慮されるだけです。
変数名の前にドル記号 ($) を付けることによって、クライアント固有の変数を作成できます。この変数は、同じファイルシステムの位置にアクセスする異なるアーキテクチャタイプの調整に役立ちます。変数名を括弧で囲むことで、その後に続く文字や数字と変数とを区切ることができます。表 15–3 に定義済みのマップ変数を示します。
表 15–3 定義済みのマップ変数
変数 |
意味 |
提供元 |
例 |
---|---|---|---|
アーキテクチャタイプ |
uname -m |
sun4u |
|
プロセッサタイプ |
uname -p |
sparc |
|
ホスト名 |
uname -n |
dinky |
|
オペレーティングシステム名 |
uname -s |
SunOS |
|
オペレーティングシステムのリリース |
uname -r |
5.8 |
|
オペレーティングシステムのバージョン (リリースのバージョン) |
uname -v |
GENERIC |
キーとして使用する場合を除いて、変数はエントリ行内のどこにでも使用できます。たとえば、/usr/local/bin/sparc および /usr/local/bin/x86 から、SPARC アーキテクチャと x86 アーキテクチャのバイナリをそれぞれエクスポートするファイルサーバーがあるとします。クライアントは、次のようなマップエントリを使ってマウントすることができます。
/usr/local/bin -ro server:/usr/local/bin/$CPU |
これで、すべてのクライアント上の同じエントリがすべてのアーキテクチャに適用されます。
どの sun4 アーキテクチャ向けに書かれたアプリケーションでも、ほとんどはすべての sun4 プラットフォームで実行できます。したがって、-ARCH 変数は sun4m ではなく、sun4 に固定されています。
ファイルマップで使用されたマップエントリ +mapname により、automount は指定されたマップを、あたかも現在のマップに組み込まれているかのように読み取ります。mapname の前にスラッシュがない場合、autofs はそのマップ名を文字列として扱い、ネームサービススイッチ方式を使用してマップ名を検出します。パス名が絶対パス名の場合、automount はその名前のローカルマップを捜します。マップ名がダッシュ (-) で始まる場合、automount は hosts などの適切な組み込みマップを参照します。
このネームサービススイッチファイルには、automount と指定された autofs 用のエントリが収められています。そしてそのエントリには、ネームサービスが検索される順序が収められています。ネームサービススイッチファイルの例を次に示します。
# # /etc/nsswitch.nis: # # An example file that could be copied over to /etc/nsswitch.conf; # it uses NIS (YP) in conjunction with files. # # "hosts:" and "services:" in this file are used only if the /etc/netconfig # file contains "switch.so" as a nametoaddr library for "inet" transports. # the following two lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files nis group: files nis # consult /etc "files" only if nis is down. hosts: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: nis [NOTFOUND=return] files netmasks: nis [NOTFOUND=return] files bootparams: nis [NOTFOUND=return] files publickey: nis [NOTFOUND=return] files netgroup: nis automount: files nis aliases: files nis # for efficient getservbyname() avoid nis services: files nis |
この例では、ローカルマップが NIS マップよりも先に検索されます。そのため、ローカルマップ /etc/auto_home に、もっとも頻繁にアクセスするホームディレクトリ用のエントリを含めることができます。他のエントリについては、スイッチを使用して NIS マップにフォールバックすることができます。
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny |
組み込まれたマップを参照した後、一致するものがなければ、automount は現在のマップのスキャンを続けます。そのため、+ エントリの後にさらにエントリを追加できます。
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny +auto_home |
組み込まれたマップは、ローカルファイルまたは組み込みマップとすることができます。ローカルファイルだけが + エントリを持つことができることに注意してください。
+auto_home_finance # NIS+ map +auto_home_sales # NIS+ map +auto_home_engineering # NIS+ map +/etc/auto_mystuff # local map +auto_home # NIS+ map +-hosts # built-in hosts map |
NIS+ または NIS のマップでは「+」エントリを使用できません。
autofs マウントポイントを生成するコマンドを実行する autofs マップを作成することもできます。データベースやフラットファイルから autofs 構造を作成しなければならない場合は、実行可能な autofs マップが有効なことがあります。短所は、マップをすべてのホストにインストールしなければならないことです。実行可能なマップは、NIS と NIS+ のどちらのネームサービスにも含めることができません。
実行可能マップは、auto_master ファイルにエントリが必要です。
/execute auto_execute |
実行可能マップの例を示します。
#!/bin/ksh # # executable map for autofs # case $1 in src) echo '-nosuid,hard bee:/export1' ;; esac |
この例が機能するためには、ファイルが /etc/auto_execute としてインストールされ、実行可能ビットがオンになっている必要があります。アクセス権は 744 に設定します。この場合、次のコマンドを実行すると、bee のファイルシステム /export1 がマウントされます。
% ls /execute/src |
マップへのエントリを変更、削除、または追加して、ユーザーの環境ニーズに合わせることができます。ユーザーが必要とするアプリケーションやその他のファイルシステムがその位置を変更すると、マップはこれらの変更を反映しなければなりません。autofs のマップは、いつでも変更できます。automountd が次にファイルシステムをマウントしたときにその変更内容が有効になるかどうかは、変更したマップと変更内容によって決まります。
ブート時に、autofs は /etc/init.d/autofs にあるスクリプトを使って起動され、マスターマップ auto_master が検索されます。次に説明する規則が適用されます。
autofs は、/etc/nsswitch.conf ファイルの自動マウントエントリで指定されたネームサービスを使用します。ローカルファイルや NIS ではなく NIS+ が指定された場合、マップ名はすべてそのまま使用されます。NIS を選択し、autofs が必要なマップを検出できない場合で、1 つまたは複数の下線を含むマップ名を検出したときには、それらの下線がドットに変更されます。こうすることにより、NIS の古いファイル名を利用することができます。次に autofs はもう 1 度マップを調べます。この手順を図 15–4 に示します。
このセッションでは、画面は次の例のようになります。
$ grep /home /etc/auto_master /home auto_home $ ypmatch brent auto_home Can't match key brent in map auto_home. Reason: no such map in server's domain. $ ypmatch brent auto.home diskus:/export/home/diskus1/& |
ネームサービスとして「ファイル」が選択された場合、すべてのマップは /etc ディレクトリ内のローカルファイルとみなされます。autofs は、使用するネームサービスとは無関係に、スラッシュ (/) で始まるマップ名をローカルとして解釈します。
これ以降の節では、autofs の高度な機能を取り上げます。
autofs は一部の文字を、特別な意味を持つものとして認識します。置き換えに使用する文字や、autofs のマップ構文解析機能から他の文字を保護するために使用する文字もあります。
たとえば次のように、多数のサブディレクトリを指定したマップがある場合は、文字列置換を使用できます。
john willow:/home/john mary willow:/home/mary joe willow:/home/joe able pine:/export/able baker peach:/export/baker |
この場合、アンパサンド文字 (&) を使用して、任意の位置に記述されたこのキーを置換することができます。アンパサンド文字を使用すると、前述のマップは次のようになります。
john willow:/home/& mary willow:/home/& joe willow:/home/& able pine:/export/& baker peach:/export/& |
キー置換はまた、次のような直接マップでも使用できます。
/usr/man willow,cedar,poplar:/usr/man |
また、このエントリは、次のようにさらに簡単にすることができます。
/usr/man willow,cedar,poplar:& |
アンパサンド文字による置換では、キー文字列全体を使用していることに注意してください。そのため、直接マップ内のキーの最初の文字が / である場合は、そのスラッシュ (/) も引き継がれます。たとえば、次のように指定することはできません。
/progs &1,&2,&3:/export/src/progs |
これは、autofs が、この例を次のように解釈するためです。
/progs /progs1,/progs2,/progs3:/export/src/progs |
任意のキーを一致させるのに、任意の文字を表す置換文字であるアスタリスク (*) を使用できます。このマップエントリを使用して、すべてのホストから /export ファイルシステムをマウントできます。
* &:/export |
ここでは、各アンパサンドは特定のキーの値によって置換されています。autofs はこのアスタリスクをファイルの終わりとして解釈します。
特殊文字が含まれているマップエントリがある場合、autofs のマップ構文解析機能を混乱させるような名前のディレクトリについてはマウントする必要があります。autofs の構文解析機能は、名前に含まれるコロン、コンマ、スペースなどを認識します。これらの名前は二重引用符で囲んでください。
/vms -ro vmsserver: - - - "rc0:dk1 - " /mac -ro gator:/ - "Mr Disk - " |