test

Solaris のシステム管理 (ネットワークサービス)

第 6 章 ネットワークファイルシステムへのアクセス (リファレンス)

この章では、NFS コマンドについて説明します。また、NFS 環境のさまざまな部分とそれらが互いにどのように連係するかについても説明します。

注 –

システムでゾーンが有効なときに非大域ゾーンでこの機能を使用するには、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』を参照してください。

NFS ファイル

ファイルによっては、いずれのコンピュータ上でも NFS アクティビティーをサポートする必要があるファイルがあります。その多くは ASCII ファイルで、いくつかはデータファイルです。表 6–1 にこのようなファイルとその機能をまとめます。

表 6–1 NFS ファイル

ファイル名 

機能 

/etc/default/autofs

autofs 環境の構成情報を示します。 

/etc/default/fs

ローカルファイルシステムにおけるデフォルトファイルシステムのタイプを示します。 

/etc/default/nfs

lockd および nfsd の構成情報を示します。詳細は、「/etc/default/nfs ファイルのキーワード」および nfs(4) のマニュアルページを参照してください。

/etc/default/nfslogd

NFS サーバーログデーモン ( nfslogd) の構成情報を示します。

/etc/dfs/dfstab

共有するローカルリソースを示します。 

/etc/dfs/fstypes

リモートファイルシステムにおけるデフォルトファイルシステムのタイプを示します。 

/etc/dfs/sharetab

共有されるローカルとリモートのリソースを示します。sharetab(4) のマニュアルページを参照してください。このファイルは編集しないでください。

/etc/mnttab

自動マウントしたディレクトリを含む、現在マウントしているファイルシステムを示します。mnttab(4) のマニュアルページを参照してください。このファイルは編集しないでください。

/etc/netconfig

トランスポートプロトコルを示します。このファイルは編集しないでください。

/etc/nfs/nfslog.conf

NFS サーバーログのための一般的な構成情報を示します。 

/etc/nfs/nfslogtab

nfslogd によるログ後処理のための情報を示します。このファイルは編集しないでください。

/etc/nfssec.conf

NFS のセキュリティーサービスを示します。 

/etc/rmtab

NFS クライアントがリモートでマウントしたファイルシステムを示します。rmtab(4) のマニュアルページを参照してください。このファイルは編集しないでください。

/etc/vfstab

ローカルにマウントするファイルシステムを定義します。vfstab(4) のマニュアルページを参照してください。

/etc/dfs/fstypes の最初のエントリは、リモートファイルシステムにおけるデフォルトファイルシステムのタイプとして利用されることがよくあります。このエントリは、NFS ファイルシステムのタイプをデフォルトとして定義します。

/etc/default/fs には、エントリが 1 つしかありません。 ローカルディスクにおけるデフォルトファイルシステムのタイプです。クライアントやサーバーでサポートするファイルシステムのタイプは、/kernel/fs のファイルを確認して決定することができます。

/etc/default/autofs ファイル

Solaris 10 以降のリリースでは、/etc/default/autofs ファイルを使用して autofs 環境を設定することができます。特に、このファイルにより、autofs コマンドおよび autofs デーモンを設定する方法が追加されました。コマンド行と同じように、この設定ファイルで指定できます。ただし、コマンド行とは異なり、オペレーティングシステムのアップグレード中にも、このファイルは指定を保持します。さらに、autofs 環境の既存の動作が保持されているかを確認するために、クリティカルな起動ファイルを更新する必要がなくなります。指定を行うには、次のキーワードに値を割り当てます。

AUTOMOUNT_TIMEOUT

ファイルシステムがアンマウントされるまでアイドル状態を持続する時間を設定します。このキーワードは、automount の -t 引数と同等です。デフォルト値は 600 です。

AUTOMOUNT_VERBOSE

マウント、アンマウント、およびその他の重要でないイベントを通知します。このキーワードは、-automount の v 引数と同等です。デフォルトの値は FALSE です。

AUTOMOUNTD_VERBOSE

状態メッセージをコンソールに記録します。このキーワードは automountd デーモンの -v 引数と同等です。デフォルトの値は FALSE です。

AUTOMOUNTD_NOBROWSE

すべての autofs マウントポイントのブラウズをオンまたはオフにします。このキーワードは -automountd の n 引数と同等です。デフォルトの値は FALSE です。

AUTOMOUNTD_TRACE

各遠隔手続き呼び出し (RPC) を拡張し、拡張された RPC を標準出力に表示します。このキーワードは、-automountd の T 引数と同等です。デフォルト値は 0 です。値の範囲は 0 から 5 です。

AUTOMOUNTD_ENV

さまざまな値をさまざまな環境に割り当てることを許可します。このキーワードは、-automountd の D 引数と同等です。AUTOMOUNTD_ENV キーワードは、何度でも使用できます。ただし、環境割り当てごとに行を分けて使用する必要があります。

詳細は、automount(1M) および automountd(1M) のマニュアルページを参照してください。手順については、「/etc/default/autofs ファイルを使用する方法」を参照してください。

/etc/default/nfs ファイルのキーワード

NFS version 4 では、次のキーワードを /etc/default/nfs ファイルに設定できます。これらのキーワードは、クライアントとサーバーの両方で使用される NFS プロトコルを制御します。

NFS_SERVER_VERSMIN

サーバーが登録し提供する最小バージョンの NFS プロトコルを設定します。Solaris 10 以降のリリースでは、デフォルトは 2 です。有効な値はほかに 3 と 4 があります。「NFS サービスの設定」を参照してください。

NFS_SERVER_VERSMAX

サーバーが登録し提供する最大バージョンの NFS プロトコルを設定します。Solaris 10 以降のリリースでは、デフォルトは 4 です。有効な値はほかに 2 と 3 があります。「NFS サービスの設定」を参照してください。

NFS_CLIENT_VERSMIN

NFS クライアントが使用する最小バージョンの NFS プロトコルを設定します。Solaris 10 以降のリリースでは、デフォルトは 2 です。有効な値はほかに 3 と 4 があります。「NFS サービスの設定」を参照してください。

NFS_CLIENT_VERSMAX

NFS クライアントが使用する最大バージョンの NFS プロトコルを設定します。Solaris 10 以降のリリースでは、デフォルトは 4 です。有効な値はほかに 2 と 3 があります。「NFS サービスの設定」を参照してください。

NFS_SERVER_DELEGATION

NFS version 4 の委託機能をサーバーで有効にするかどうかを制御します。この機能が有効な場合、サーバーは NFS version 4 のクライアントに委託しようとします。デフォルトでは、サーバー委託は有効になっています。サーバー委託を無効にするには、「サーバー上で異なるバージョンの NFS を選択する方法」を参照してください。詳細は、「NFS version 4 における委託」を参照してください。

NFSMAPID_DOMAIN

クライアントとサーバーに共通のドメインを設定します。ローカル DNS ドメイン名を使用するデフォルトの動作は無効になります。作業の詳細は、「NFS サービスの設定」を参照してください。また、「nfsmapid デーモン」も参照してください。

/etc/default/nfslogd ファイル

このファイルは、NFS サーバーログ機能を使用するときに使用されるいくつかのパラメータを定義します。次のパラメータを定義することができます。

CYCLE_FREQUENCY

ログファイルを循環させる前に経過すべき時間数を決定するパラメータです。デフォルト値は 24 時間です。このパラメータはログファイルが大きくなり過ぎないように使用します。

IDLE_TIME

nfslogd が、バッファーファイル内のさらなる情報を検査する前にスリープすべき秒数を決定するパラメータです。このパラメータは、構成ファイルの検査頻度も決定します。このパラメータと MIN_PROCESSING_SIZE によりバッファーファイルの処理頻度が決まります。デフォルト値は 300 秒です。この数値を増加させると、検査の回数が減ってパフォーマンスが向上します。

MAPPING_UPDATE_INTERVAL

ファイルハンドルパスマッピングテーブル内でレコードを更新する間隔を秒数で指定します。デフォルト値は 86400 秒つまり 1 日です。このパラメータを使用すると、ファイルハンドルパスマッピングテーブルを常時更新しないで最新の状態に保つことができます。

MAX_LOGS_PRESERVE

保存するログファイル数を決めます。デフォルト値は 10 です。

MIN_PROCESSING_SIZE

バッファーファイルが処理してログファイルに書き込むための最小限のバイト数を設定します。このパラメータと IDLE_TIME によりバッファーファイルの処理頻度が決まります。デフォルト値は 524,288 バイトです。この数値を大きくするとバッファーファイルの処理回数が減ってパフォーマンスが向上します。

PRUNE_TIMEOUT

ファイルハンドルパスマッピングレコードを中断して削減できるようになるまでに経過しなければならない時間数を選択するパラメータです。デフォルト値は 168 時間、つまり 7 日間です。

UMASK

nfslogd によって作成されるログファイルのファイルモード生成マスクを指定します。デフォルト値は 0137 です。

/etc/nfs/nfslog.conf ファイル

このファイルは nfslogd で使用するログのパス、ファイル名、およびタイプを定義します。各定義はタグと関連づけられています。NFS サーバーのログを開始するためには、各ファイルシステムについてタグを付ける必要があります。広域タグはデフォルト値を定義します。必要に応じて、各タグに、次のパラメータを使用することができます。

defaultdir=path

ログファイルのデフォルトのディレクトリパスを指定するパラメータです。特に指定しないかぎり、デフォルトのディレクトリは /var/nfs です。

log=path/filename

ログファイルのパスとファイル名を指定するパラメータです。デフォルトは /var/nfs/nfslog です。

fhtable=path/filename

ファイルハンドルパスデータベースのパスとファイル名を選択するパラメータです。デフォルトは /var/nfs/fhtable です。

buffer=path/filename

バッファーファイルのパスとファイル名を決定するパラメータです。デフォルトは /var/nfs/nfslog_workbuffer です。

logformat=basic|extended

ユーザーから読み取り可能なログファイルを作成するときに使用するフォーマットを選択します。基本フォーマットでは、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 と共有するファイルシステムはすべて、次の値を使用します。

手順については、「NFS サーバーログを有効にする方法」を参照してください。

NFS デーモン

NFS アクティビティーをサポートするために、システムが実行レベル 3 またはマルチユーザーモードで稼動し始めたときに、複数のデーモンが起動されます。mountd デーモンおよび nfsd デーモンは、サーバーであるシステム上で実行されます。サーバーデーモンの自動起動は、NFS ファイルシステムのタイプでラベル付けされたエントリが /etc/dfs/sharetab に存在するかどうかで変わります。lockd デーモンおよび statd デーモンは、NFS クライアントおよび NFS サーバー上で実行され、NFS のファイルロックをサポートします。ただし、以前のバージョンの NFS とは異なり、NFS version 4 では、デーモン lockd、statd、mountd、および nfslogd は使用されません。

この節では、次のデーモンについて説明します。

automountd デーモン

このデーモンは autofs サービスからのマウントおよびアンマウント要求を処理します。このコマンドの構文は次のとおりです。

automountd [ -Tnv ] [ -D name= value ]

このコマンドは、次のように動作します。

自動マウントマップのデフォルト値は /etc/auto_master です。トラブルシューティングには -T オプションを使用してください。

lockd デーモン

このデーモンは NFS ファイルのレコードロックをサポートします。lockd デーモンは、ネットワークロックマネージャー (NLM) プロトコルについて、クライアントとサーバー間の RPC 接続を管理します。通常は、パラメータを指定しないで起動します。使用できるオプションは 3 つあります。lockd(1M) のマニュアルページを参照してください。これらのオプションは、コマンド行からも、/etc/default/nfs 内の適切な文字列を編集することによっても使用することができます。次は、/etc/default/nfs ファイルに設定可能なキーワードの説明です。

注 –

Solaris 10 以降のリリースでは、LOCKD_GRACE_PERIOD キーワードと-g オプションの使用は推奨されていません。推奨されていないキーワードは、新しいキーワード GRACE_PERIOD に置き換えられています。両キーワードが設定されている場合、GRACE_PERIOD の値は、LOCKD_GRACE_PERIOD の値に優先します。次の GRACE_PERIOD の説明を参照してください。

LOCKD_GRACE_PERIOD 同様、/etc/default/nfs に GRACE_PERIOD= graceperiod を追加すると、クライアントがサーバーのリブート後に NFS version 3 のロック (NLM が提供) と version 4 のロックを再要求する秒数を設定できます。つまり、GRACE_PERIOD の値は、NFS version 3 と NFS version 4 に対するロックリカバリの猶予期間を制御します。

/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 デーモン

このデーモンは、リモートシステムからのファイルシステムマウント要求を処理して、アクセス制御を行います。mountd デーモンは、/etc/dfs/sharetab を調べて、リモートマウントに使用可能なファイルシステムと、リモートマウントを実行できるシステムを判断します。このコマンドでは、-v オプションと -r オプションを使用できます。mountd(1M) のマニュアルページを参照してください。

-v オプションは、コマンドを冗長モードで実行します。クライアントが付与されるアクセス権を NFS サーバーが決定するたびに、コンソールにメッセージが表示されます。この情報は、クライアントがファイルシステムにアクセスできない理由を調べるときに役立ちます。

-r オプションは、その後のクライアントからのマウント要求をすべて拒絶します。このオプションを指定しても、すでにファイルシステムがマウントされているクライアントには影響しません。

注 –

NFS version 4 は、このデーモンを使用しません。

nfs4cbd デーモン

NFS version 4 クライアントの排他使用のための nfs4cbd は、NFS version 4 コールバックプログラムでの通信の終端を管理します。デーモンには、ユーザーがアクセス可能なインタフェースがありません。詳細は、nfs4cbd(1M) のマニュアルページを参照してください。

nfsd デーモン

これは、他のクライアントからのファイルシステム要求を処理するデーモンです。このコマンドに対してはいくつかのオプションを指定できます。オプションをすべて確認するには、nfsd(1M) のマニュアルページを参照してください。これらのオプションは、コマンド行からも、/etc/default/nfs 内の適切な文字列を編集することによっても使用することができます。

/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 パラメータを追加すると、サーバーが一度に処理する要求の最大数を選択できます。nservers のデフォルト値は 16 です。コマンド行から nservers オプションを指定して nfsd を起動すると、同じように最大数を選択できます。

以前のバージョンの nfsd デーモンとは異なり、現在のバージョンの nfsd では複数のコピーを作成して要求を同時に処理することはありません。処理テーブルを ps でチェックすると、動作しているデーモンのコピーが 1 つしかないことがわかります。

nfslogd デーモン

このデーモンは実行された処理のログ機能を提供します。サーバーに対して記録される NFS 操作は、/etc/default/nfslogd に定義されている構成オプションに基づくものです。NFS サーバーのログ機能がオンになると、選択されたファイルシステム上でのすべての RPC 操作の記録がカーネルによりバッファーファイルに書き込まれます。次に nfslogd がこれらの要求を後処理します。ログインおよび IP アドレスへの UID をホスト名に割り当てやすくするために、ネームサービススイッチが使用されます。識別されたネームサービスで一致するものが見つからない場合は、その番号が記録されます。

パス名へのファイルハンドルの割り当ても nfslogd により行われます。このデーモンは、ファイルハンドルパスマッピングテーブル内でこれらの割り当てを追跡します。/etc/nfs/nfslogd で識別される各タグについて 1 つのマッピングテーブルが存在します。後処理の後に、レコードが ASCII ログファイルに書き込まれます。

注 –

NFS version 4 は、このデーモンを使用しません。

nfsmapid デーモン

version 4 の NFS プロトコル (RFC3530) では、クライアントとサーバーの間でユーザー識別子またはグループ識別子を交換する方法が変更されました。このプロトコルでは、NFS version 4 クライアントと NFS version 4 サーバーとの間で、ファイルの所有者とグループの属性をそれぞれ user@nfsv4_domain、group@nfsv4_domain の形式で文字列として交換する必要があります。

たとえば、known_user ユーザーに完全指定のホスト名が system.example.com である NFS version 4 クライアント上に UID 123456 が割り当てられているとします。このクライアントが NFS version 4 サーバーに要求を行うには、UID 123456 を known_user@example.com に割り当ててから、この属性を NFS version 4 サーバーに送信する必要があります。NFS version 4 サーバーは、ユーザーとグループのファイル属性を user_or_group@nfsv4_domain 形式で受信することを予期します。サーバーがクライアントから known_user@example.com を受信すると、サーバーはこの文字列をローカルの UID 123456 に割り当て 、配下のファイルシステムがこれを認識します。この機能では、ネットワーク上のすべての UID と GID が一意であること、およびクライアント上の NFS version 4 のドメインがサーバー上の NFS version 4 のドメインと一致していることを前提としています。

注 –

NFS version 4 のドメインが一致している場合でも、渡されたユーザー名またはグループ名をサーバーが認識しない場合、そのサーバーはそのユーザー名またはグループ名を一意の ID (整数値) に割り当てることができません。そのような場合は、サーバーは着信ユーザー名または着信グループ名を nobody ユーザーに割り当てます。そうした状況が発生することを避けるために、管理者は NFS version 4 クライアントだけに存在する特別なアカウントを作成しないようにしてください。

NFS version 4 のクライアントとサーバーは、整数から文字列への変換と文字列から整数への変換に対応しています。たとえば、NFS version 4 サーバーが GETATTR 処理を受け取ると、配下のファイルシステムから取得した UID および GID をそれぞれの文字列表現に割り当てたうえで、この情報をクライアントに送信します。またクライアントでも、UID と GID を文字列表現に割り当てる必要があります。たとえば、クライアントが chown コマンドを受け取ると、新しい UID および GID を文字列表現に割り当ててから、SETATTR 処理をサーバーに送信します。

ただし、クライアントとサーバーでは、文字列が認識されない場合の対処が異なることに注意してください。

構成ファイルと nfsmapid

次に、nfsmapid デーモンが /etc/nsswitch.conf ファイルと /etc/resolv.conf ファイルをどのように使用するかについて説明します。

優先ルール

    nfsmapid が正しく動作するには、NFS version 4 のクライアントとサーバーが同じドメインに割り当てられている必要があります。NFS version 4 ドメインが確実に一致するように、nfsmapid は次の厳密な優先ルールに従って動作します。

  1. デーモンは、NFSMAPID_DOMAIN キーワードに割り当てられた値を /etc/default/nfs ファイルで最初に確認します。値が検出された場合、その割り当てられている値は他の設定よりも優先されます。割り当てられている値は、発信属性文字列に追加され、着信属性文字列と比較されます。/etc/default/nfs ファイル内のキーワードの詳細は、「/etc/default/nfs ファイルのキーワード」を参照してください。手順については、「NFS サービスの設定」を参照してください。

    注 –

    NFSMAPID_DOMAIN 設定を使用する方法はスケーラブルではないため、大規模な配備を行う場合には推奨されません。

  2. 値が NFSMAPID_DOMAIN に割り当てられていない場合、デーモンは DNS TXT RR でドメイン名を確認します。nfsmapid は、resolver の一連のルーチンによって使用される /etc/resolv.conf ファイル内の指令に依存します。resolver は、設定されている DNS サーバーから _nfsv4idmapdomain TXT RR を検索します。DNS TXT レコードを使用する方がよりスケーラブルです。このため、/etc/default/nfs ファイルにキーワードを設定するよりも、TXT レコードを継続して使用する方がよいでしょう。

  3. ドメイン名を提供する DNS TXT レコードが設定されていない場合、nfsmapid デーモンは /etc/resolv.conf ファイル内の domain または search 指令で指定された値を使用します。このとき、最後に指定された指令が優先されます。

    次の例では、domain および search の両方の指令が使用されています。nfsmapid デーモンは、search 指令のあとに最初に記載されているドメイン名である company.com を使用します。


    domain example.company.com
search company.com foo.bar.com

  4. /etc/resolv.conf ファイルが存在しない場合、nfsmapid は domainname コマンドの動作に従って NFS version 4 ドメインの名前を取得します。より詳しく説明すると、/etc/defaultdomain ファイルが存在する場合には、nfsmapid は NFS version 4 ドメインのためにそのファイルの内容を使用します。/etc/defaultdomain ファイルが存在しない場合には、nfsmapid はネットワークに設定されているネームサービスから渡されるドメイン名を使用します。詳細は、domainname(1M) のマニュアルページを参照してください。

nfsmapid と DNS TXT レコード

DNS は汎用性が高いので、NFS version 4 のドメイン名を格納して配布するための効率的な機構です。また、DNS は本質的にスケーラブルなので、DNS TXT リソースレコードを使用する方法は、大規模な配備の NFS version 4 のドメインを設定するうえで、もっとも推奨される方法です。エンタープライズレベルの DNS サーバーでは、_nfsv4idmapdomain TXT レコードを設定するようにしてください。このように設定すれば、NFS version 4 のクライアントまたはサーバーは DNS ツリーをたどることによって NFS version 4 ドメインを見つけることができます。

DNS サーバーから NFS version 4 のドメイン名を提供するように設定するときは、次の例のように入力することをお勧めします。


_nfsv4idmapdomain		IN		TXT			"foo.bar"

この例では、設定されるドメイン名は、二重引用符で囲まれている値です。ttl フィールドが指定されていないことと、ドメインが owner フィールドの値である _nfsv4idmapdomain に追加されていないことに注意してください。この設定により、TXT レコードで、Start-Of-Authority (SOA) レコードのゾーンの ${ORIGIN} エントリを使用できるようになります。たとえば、さまざまなレベルのドメイン名前空間で、レコードは次のように読み取ることができます。


_nfsv4idmapdomain.subnet.yourcorp.com.    IN    TXT    "foo.bar"
_nfsv4idmapdomain.yourcorp.com.           IN    TXT    "foo.bar"

この設定では、DNS クライアントが DNS ツリー階層を検索するときに、resolv.conf ファイルを使用して柔軟に検索することができます。resolv.conf(4) のマニュアルページを参照してください。この機能により、TXT レコードの検索での確率がより高くなります。柔軟性の向上により、低いレベルの DNS サブドメインが、自身の DNS TXT リソースレコード (RR) を定義できるようになりました。この機能により、低いレベルの DNS サブドメインを、高いレベルの DNS ドメインの定義した TXT レコードに優先させることができます。

注 –

TXT レコードで指定したドメインには、任意の文字列を使用できます。この文字列は、NFS version 4 を使用するクライアントとサーバーの DNS ドメインと同じである必要はありません。 NFS version 4 データをほかの DNS ドメインと共有しないようにするオプションがあります。

NFS version 4 のドメインを確認する

ネットワークの NFS version 4 ドメインの値を割り当てる前に、ネットワークに NFS version 4 ドメインがすでに設定されているかどうかを確認します。次の例は、ネットワークの NFS version 4 ドメインを確認する方法を示します。

詳細は、次のマニュアルページを参照してください。

NFS version 4 のデフォルトドメインを設定する

この節では、ネットワークがどのようにして目的のデフォルトドメインを取得するかについて説明します。

Solaris Express 5/06 リリースで NFS version 4 のデフォルトドメインを設定する

初期 Solaris 10 リリースでは、OS インストール後の初回システムリブート中に、ドメインの定義が行われていました。Solaris Express 5/06 リリースでは、OS のインストール中に NFS version 4 ドメインの定義が行われます。この機能を提供するために、次の機能が追加されました。

    次に、この機能の動作手順を説明します。

  1. sysidnfs4 プログラムは /etc/.sysIDtool.state ファイルをチェックし、NFS version 4 ドメインが特定されているかどうかを判定します。

    • .sysIDtool.state ファイルから、ネットワークの NFS version 4 ドメインが設定されていることが判明すると、sysidnfs4 プログラムはそれ以上のチェックを行いません。次の .sysIDtool.state ファイルの例を参照してください。


      1       # System previously configured?
1       # Bootparams succeeded?
1       # System is on a network?
1       # Extended network information gathered?
1       # Autobinder succeeded?
1       # Network has subnets?
1       # root password prompted for?
1       # locale and term prompted for?
1       # security policy in place
1       # NFSv4 domain configured
xterms

      # NFSv4 domain configured の前に 1 が表示されていれば、NFS version 4 ドメインが設定されています。

    • .sysIDtool.state ファイルから、ネットワークの NFS version 4 ドメインが設定されていないことが判明した場合、sysidnfs4 プログラムはさらなるチェックを行う必要があります。次の .sysIDtool.state ファイルの例を参照してください。


      1       # System previously configured?
1       # Bootparams succeeded?
1       # System is on a network?
1       # Extended network information gathered?
1       # Autobinder succeeded?
1       # Network has subnets?
1       # root password prompted for?
1       # locale and term prompted for?
1       # security policy in place
0       # NFSv4 domain configured
xterms

      # NFSv4 domain configured の前に 0 が表示されていれば、NFS version 4 ドメインは設定されていません。

  2. NFS version 4 ドメインが特定されていない場合、sysidnfs4 プログラムは sysidcfg ファイル内の nfs4_domain キーワードをチェックします。

    • nfs4_domain の値が存在する場合は、その値が /etc/default/nfs ファイル内の NFSMAPID_DOMAIN キーワードに設定されます。NFSMAPID_DOMAIN に値が設定されると、その値が何であれ、それが nfsmapid デーモンの動的ドメイン選択機能よりも優先されます。nfsmapid の動的ドメイン選択機能の詳細については、「優先ルール」を参照してください。

    • nfs4_domain の値が存在しない場合、sysidnfs4 プログラムは、オペレーティングシステムの設定済みネームサービスから nfsmapid によって派生されるドメインを特定します。この派生値はデフォルトドメインとして対話プロンプトに表示されますが、ユーザーは、そのデフォルト値を受け入れるか、異なる NFS version 4 ドメインを割り当てるかを選択できます。

この機能により、次のものが廃止になります。

注 –

DNS 特有のユビキタスでスケーラブルな性質のため、大規模な NFS version 4 配備のドメイン設定には DNS TXT レコードを引き続き使用することを強く推奨します。「nfsmapid と DNS TXT レコード」を参照してください。

Solaris のインストールプロセスに関する具体的な情報については、次を参照してください。

Solaris 10 リリースで NFS version 4 のデフォルトドメインを設定する

初期 Solaris 10 リリースの NFS version 4 では、ネットワーク内に複数の DNS ドメインが存在しているにもかかわらず、単一の UID および GID 名前空間しかない場合、すべてのクライアントが NFSMAPID_DOMAIN に対して単一の値を使用する必要があります。DNS を使用するサイトでは、nfsmapid が、_nfsv4idmapdomain に割り当てられた値からドメイン名を取得して、この問題を解決します。詳細は、「nfsmapid と DNS TXT レコード」を参照してください。ネットワークが DNS を使用する構成になっていない場合は、Solaris オペレーティングシステムの最初のブート時に、 sysidconfig(1M) ユーティリティーによって NFS version 4 のドメイン名に関する次のプロンプトが表示されます。


This system is configured with NFS version 4, which uses a 
domain name that is automatically derived from the system's 
name services. The derived domain name is sufficient for most 
configurations. In a few cases, mounts that cross different 
domains might cause files to be owned by nobody due to the 
lack of a common domain name.

Do you need to override the system's default NFS verion 4 domain 
name (yes/no)? [no]

デフォルトの応答は [no] です。[no] を選択すると、次のプロンプトが表示されます。


For more information about how the NFS version 4 default domain name is 
derived and its impact, refer to the man pages for nfsmapid(1M) and 
nfs(4), and the System Administration Guide: Network Services.

[yes] を選択すると、次のプロンプトが表示されます。


Enter the domain to be used as the NFS version 4 domain name.
NFS version 4 domain name []:
注 –

NFSMAPID_DOMAIN の値が /etc/default/nfs に存在する場合は、指定した [domain_name] が優先されます。

nfsmapid の追加情報

nfsmapid の詳細は、次を参照してください。

statd デーモン

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.168.255.255 -> 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.168.255.255 です。ほかのホストが myhost という名前を持ち、ファイルシステムをマウントしていると、myhost というホスト名に対するシンボリックリンクは 2 つ作成されます。

注 –

NFS version 4 は、このデーモンを使用しません。

NFS コマンド

次のコマンドは、root として実行しないと、十分な効果が得られません。ただし、情報の要求は、すべてのユーザーが行うことができます。

automount コマンド

このコマンドは autofs マウントポイントをインストールし、オートマスターファイル内の情報を各マウントポイントに関連付けます。このコマンドの構文は次のとおりです。

automount [ -t duration ] [ -v ]

-t duration はファイルシステムがマウントされた状態でいる時間 (秒) を設定し、-v は冗長モードを選択します。冗長モードでこのコマンドを実行するとトラブルシューティングが容易になります。

継続時間の値は、特に設定しないと 5 分に設定されます。通常はこの値が適切です。しかし、自動マウントされたファイルシステムの多いシステムでは、この値を増やす必要がある場合もあります。特に、サーバーを多くのユーザーが使用中の場合は、自動マウントされたファイルシステムを 5 分ごとにチェックするのは能率的でない場合があります。autofs ファイルシステムは 1800 秒 (30 分) ごとにチェックする方が適しています。5 分おきにファイルシステムマウントを解除しないと、/etc/mnttab が大きくなることがあります。df が /etc/mnttab にある各エントリをチェックしたときの出力を減らすには、-F オプション (df(1M) のマニュアルページを参照) または egrep を使用して、df の出力にフィルタをかけます。

この継続時間を調節すると、オートマウンタマップへの変更が反映される速さを変更できるということも考慮すべきです。変更はファイルシステムがアンマウントされるまでは見ることができません。オートマウンタマップの変更方法については、「マップの修正」を参照してください。

clear_locks コマンド

このコマンドを使用すると、ある NFS クライアントのファイル、レコード、または共有のロックをすべて削除できます。このコマンドを実行するには、スーパーユーザーでなければなりません。NFS サーバーから、特定のクライアントに対するロックを解除できます。また、NFS クライアントから、特定のサーバーにおけるそのクライアントに対するロックを解除できます。次の例では、現在のシステム上の tulip という NFS クライアントに対するロックが解除されます。 


# clear_locks tulip

-s オプションを指定すると、どの NFS ホストからロックを解除するかを指定できます。このオプションは、ロックを作成した NFS クライアントで実行する必要があります。次の場合、クライアントによるロックが bee という名前の NFS サーバーから解除されます。


# clear_locks -s bee
注意 – 注意 –

このコマンドは、クライアントがクラッシュしてロックを解除できないとき以外には使用しないでください。データが破壊されるのを避けるため、使用中のクライアントに関するロックは解除しないでください。

fsstat コマンド

Solaris 10 11/06 以降のリリースでは、fsstat ユーティリティーを使用して、ファイルシステムの種類およびマウントポイントごとに、ファイルシステムオペレーションを監視できます。出力のカスタマイズを可能にするオプションが多数用意されています。次に例を示します。

次の例では、NFS version 3、version 4、およびルートマウントポイントに対する出力を表示しています。


% fsstat nfs3 nfs4 /
  new     name   name    attr    attr   lookup   rddir   read   read   write   write
 file    remov   chng     get     set      ops     ops    ops  bytes     ops   bytes
3.81K       90  3.65K   5.89M   11.9K    35.5M   26.6K   109K   118M   35.0K   8.16G  nfs3
  759      503    457   93.6K   1.44K     454K   8.82K  65.4K   827M     292    223K  nfs4
25.2K    18.1K  1.12K   54.7M    1017     259M   1.76M  22.4M  20.1G   1.43M   3.77G  /

次の例では、-i オプションを使って NFS version 3、version 4、およびルートマウントポイントの入出力操作に関する統計を提供しています。


% fsstat -i nfs3 nfs4 /
 read    read    write   write   rddir   rddir   rwlock   rwulock
  ops   bytes      ops   bytes     ops   bytes      ops       ops
 109K    118M    35.0K   8.16G   26.6K   4.45M     170K      170K  nfs3
65.4K    827M      292    223K   8.82K   2.62M    74.1K     74.1K  nfs4
22.4M   20.1G    1.43M   3.77G   1.76M   3.29G    25.5M     25.5M  /

次の例では、-n オプションを使って NFS version 3、version 4、およびルートマウントポイントの命名操作に関する統計を提供しています。


% fsstat -n nfs3 nfs4 /
lookup   creat   remov  link   renam  mkdir  rmdir   rddir  symlnk  rdlnk
 35.5M   3.79K      90     2   3.64K      5      0   26.6K      11   136K  nfs3
  454K     403     503     0     101      0      0   8.82K     356  1.20K  nfs4
  259M   25.2K   18.1K   114    1017     10      2   1.76M      12  8.23M  /

詳細は、fsstat(1M) のマニュアルページを参照してください。

mount コマンド

このコマンドを使用すると、指定したファイルシステムをローカルまたはリモートで、指定したマウントポイントにマウントできます。詳細は、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 ファイルシステム用の mount オプション

NFS ファイルシステムのマウント時に -o フラグのあとに指定できるオプションの一部を、次に示します。オプションの完全な一覧については、mount_nfs(1M) のマニュアルページを参照してください。

bg|fg

これらのオプションは、マウントが失敗したときの再試行の方法を選択するオプションです。bg オプションの場合はバックグラウンドで、fg オプションの場合はフォアグラウンドでマウントが試みられます。デフォルトは fg です。常に使用可能にしておく必要のあるファイルシステムに対しては fg が適しています。fg オプションを指定すると、マウントが完了するまで、次の処理は行われません。bg は、マウント要求が完了しなくてもクライアントはほかの処理を実行できるため、クリティカルでないファイルシステムの処理に適しています。

forcedirectio

このオプションは、大規模の連続したデータ転送のパフォーマンスを向上させます。データは直接ユーザーバッファーにコピーされます。クライアント上のカーネル内ではキャッシュへの書き込みは行われません。この機能はデフォルトではオフです。

これまで、書き込み要求はすべて、NFS クライアントと NFS サーバーの両方で直列化されていました。今回の NFS クライアントの変更により、単一ファイルに対する並行書き込み、並行読み取り/書き込みを、アプリケーションから実行できるようになりました。この機能をクライアント上で有効にするには、mount コマンドオプション forcedirectio を使用します。このオプションを使用した場合、マウントされたファイルシステム内のすべてのファイルに対して、この機能が有効になります。この機能をクライアントの単一のファイルに対してのみ有効にするには、directio() インタフェースを使用します。この機能を有効にしないかぎり、ファイルへの書き込みは直列化されます。また、並行書き込みや並行読み取り/書き込みが実行されると、そのファイルに関しては、POSIX のセマンティクスはサポートされなくなります。

このオプションの使用例については、「mount コマンドの使用」を参照してください。

largefiles

このオプションを使用すると、Solaris 2.6 が稼働しているサーバー上に置かれた 2G バイトを超えるサイズのファイルにアクセスできるようになります。大規模ファイルにアクセスできるかどうかは、サーバーでしか制御できません。したがって、このオプションは NFS version 3 のマウントでは無視されます。デフォルトでは、Solaris 2.6 以降のリリースの UFS ファイルシステムはすべて largefiles オプション付きでマウントされます。NFS version 2 プロトコルを使用したマウントで largefiles オプションを指定すると、エラーが発生してマウントできません。

nolargefiles

この UFS マウント用のオプションを指定すると、ファイルシステム上に大規模ファイルが存在できないことが保証されます。mount_ufs(1M) のマニュアルページを参照してください。大規模ファイルの存在は NFS サーバー上でのみ制御できるため、NFS マウントを使用している場合は、nolargefiles オプションを指定できません。このオプションを指定してファイルシステムを NFS マウントしようとすると、エラーが発生して拒否されます。

nosuid|suid

Solaris 10 以降のリリースでは、nosuid オプションは、nodevices オプションを nosetuid オプションと同時に指定することと同等です。nodevices オプションが指定されている場合、マウントされたファイルシステム上のデバイス特殊ファイルを開くことができません。nosetuid オプションが指定されている場合、ファイルシステム上に置かれたバイナリファイルの setuid ビットと setgid ビットは無視されます。プロセスは、バイナリファイルを実行するユーザーの特権で実行します。

suid オプションは、devices オプションを setuid オプションと同時に指定することと同等です。devices オプションが指定されている場合、マウントされたファイルシステムのデバイス特殊ファイルを開くことができます。setuid オプションが指定されている場合、ファイルシステムに置かれたバイナリファイルの setuid ビットと setgid ビットは、カーネルが引き受けます。

いずれのオプションも指定されていない場合、デフォルトのオプションは suid になります。これにより、devices オプションを setuid オプションと同時に指定するデフォルトの動作になります。

次の表は、nosuid または suid を devices または nodevices、および setuid または nosetuid と組み合わせることによる結果を示しています。オプションの各組み合わせでは、もっとも制限の高いオプションが動作を決定します。

オプションの組み合わせによる動作 

オプション 

オプション 

オプション 

nosetuid と nodevices の同時指定と同等

nosuid

nosetuid

nodevices

nosetuid と nodevices の同時指定と同等

nosuid

nosetuid

devices

nosetuid と nodevices の同時指定と同等

nosuid

setuid

nodevices

nosetuid と nodevices の同時指定と同等

nosuid

setuid

devices

nosetuid と nodevices の同時指定と同等

suid

nosetuid

nodevices

nosetuid と devices の同時指定と同等

suid

nosetuid

devices

setuid と nodevices の同時指定と同等

suid

setuid

nodevices

setuid と devices の同時指定と同等

suid

setuid

devices

nosuid オプションを指定すると、信頼できないサーバーにアクセスする可能性のある NFS クライアントのセキュリティーを向上できます。このオプションを使用してリモートファイルシステムのマウントを行うと、信頼できないデバイスのインポートまたは信頼できない setuid バイナリファイルのインポートによって特権が拡大する可能性を減らすことができます。これらのオプションはすべて、Solaris ファイルシステム全体で使用可能です。

public

このオプションを指定すると、NFS サーバーにアクセスするときに必ず公開ファイルハンドルを使用するようになります。NFS サーバーが公開ファイルハンドルをサポートしていれば、MOUNT プロトコルが使用されないため、マウント操作は短時間で行われます。また、MOUNT プロトコルを使用しないため、ファイアウォールを越えたマウントが可能です。

rw|ro

-rw オプションと -ro オプションは、ファイルシステムが読み書き可能と読み取り専用のどちらでマウントされるかを示します。デフォルトは読み書き可能で、これはリモートホームディレクトリやメールスプールディレクトリなどの、ユーザーによる変更が必要なファイルシステムに適しています。読み取り専用オプションは、ユーザーが変更してはいけないディレクトリに適しています。具体的には、マニュアルページの共有コピーなどです。

sec=mode

このオプションは、マウント時に使用される認証メカニズムを指定します。mode の値は、次のいずれかです。

  • Kerberos version 5 認証サービス用の krb5 を使用する。

  • 整合性を指定する Kerberos version 5 用の krb5i を使用する。

  • 機密性を指定する Kerberos version 5 用の krb5p を使用する。

  • 認証なしの none を使用する。

  • Diffie-Hellman (DH) 認証用の dh を使用する。

  • UNIX 標準認証用の sys を使用する。

モードは、/etc/nfssec.conf ファイルにも定義されます。

soft|hard

soft オプションを指定してマウントされた NFS ファイルシステムは、サーバーが応答しなくなるとエラーを返します。hard オプションが指定されていると、サーバーが応答するまで続けて再試行が行われます。デフォルトは hard です。ほとんどのファイルシステムには hard を使用します。ソフトマウントされたファイルシステムからの値を検査しないアプリケーションが多いので、アプリケーションでエラーが発生してファイルが破壊される恐れがあるためです。アプリケーションが戻り値を確認する場合は、soft が使用されているとルーティングの問題などによってアプリケーションが正しく判断できず、ファイルが破壊されることがあります。原則として、soft は使用しないでください。hard オプションを指定した場合にファイルシステムが使用できなくなると、そのファイルシステムを使用するアプリケーションはファイルシステムが復旧するまでハングアップする可能性があります。

mount コマンドの使用

次の例を参照してください。

umount コマンド

このコマンドにより、現在マウントされているリモートファイルシステムが解除されます。umount コマンドは、テストのために -V オプションをサポートしています。また、-a オプションを使用することによって 1 度に複数のファイルシステムをアンマウントできます。-a オプションに mount-points を指定すると、そのファイルシステムがアンマウントされます。マウントポイントを指定しないと、/etc/mnttab のリストにあるファイルシステムのうち必須でないものすべてのアンマウントが試みられます。必須のファイルシステムとは、/、/usr、/var、/proc、/dev/fd、/tmp などです。 ファイルシステムがすでにマウントされていて、/etc/mnttab に項目が指定されている場合、ファイルシステムのタイプのフラグを指定する必要はありません。

-f オプションを指定すると、使用中のファイルシステムが強制的にアンマウントされます。このオプションを使用して、マウントできないファイルシステムのマウントを試みた最中にハングアップしたクライアントを復帰させることが可能です。

注意 – 注意 –

ファイルシステムを強制的にアンマウントすると、ファイルへの書き込み中だった場合には、データを損失することがあります。

次に例を示します。

例 6–1 ファイルシステムをアンマウントする

次の例は、/usr/man にマウントしたファイルシステムをアンマウントします。 


# umount /usr/man
例 6–2 umount でオプションを使用する

次の例では、umount -a -V の実行結果が表示されます。 


# umount -a -V
umount /home/kathys
umount /opt
umount /home
umount /net

このコマンドでは、ファイルシステムのアンマウント自体は実行されないことに注意してください。

mountall コマンド

このコマンドを使用すると、ファイルシステムテーブルに一覧表示されたすべてのファイルシステム、または特定グループのファイルシステムをマウントできます。このコマンドを実行すると、次の操作を実行することができます。

NFS ファイルシステムタイプと指定されているファイルシステムはすべてリモートファイルシステムなので、これらのオプションは余分な指定になることがあります。詳細は、mountall(1M) のマニュアルページを参照してください。

次の 2 つのユーザー入力例では、同じ結果が得られます。 


# mountall -F nfs


# mountall -F nfs -r

umountall コマンド

このコマンドを使用すると、ファイルシステムのグループをアンマウントできます。-k オプションは、mount-point に関連付けられているプロセスを終了させるために fuser -k mount-point コマンドを実行します。-s オプションは、アンマウントを並行処理しないことを示します。-l は、ローカルファイルシステムだけを使用することを、-r はリモートファイルシステムだけを使用することを示します。-h host オプションは、指定されたホストのファイルシステムをすべてアンマウントすることを指定します。-h オプションは、-l または -r と同時に指定できません。

次の例では、リモートホストからマウントしたすべてのファイルシステムがアンマウントされます。 


# umountall -r

次の例では、bee サーバーからマウントしたすべてのファイルシステムがアンマウントされます。 


# umountall -h bee

share コマンド

このコマンドを使用すると、NFS サーバーのローカルファイルシステムをマウントできるようになります。また、システム上のファイルシステムのうち、現在共有しているもののリストを表示します。NFS サーバーが動作していないと、share コマンドは使用できません。NFS サーバーソフトウェアは、/etc/dfs/dfstab にエントリがある場合、起動の途中で自動的に起動されます。NFS サーバーソフトウェアが動作していない場合、このコマンドはエラーを報告しません。そのため、ソフトウェアが動作していることを確認する必要があります。

すべてのディレクトリツリーは共有できるオブジェクトです。ただし、各ファイルシステムの階層構造は、そのファイルシステムが位置するディスクスライスやパーティションで制限されます。たとえば、ルート (/) ファイルシステムを共有しても、/usr が同じディスクパーティションかスライスに存在しなければ、/usr を共有することはできません。通常、ルートはスライス 0 に、/usr はスライス 6 にインストールされます。また、/usr を共有しても、/usr のサブディレクトリにマウントされているローカルディスクパーティションは共有できません。

すでに共有している大規模なファイルシステムの一部であるファイルシステムを共有することはできません。たとえば、/usr および /usr/local が同じディスクスライスにある場合は、/usr または /usr/local を共有できます。ただし、異なる共有オプションを指定してこれら両方のディレクトリを共有するには、/usr/local を別のディスクスライスに移動する必要があります。

読み取り専用で共有しているファイルシステムに、読み取りと書き込みが可能な状態で共有しているファイルシステムのファイルハンドルでアクセスすることができます。ただし、両方のファイルシステムが同じディスクスライスにある必要があります。より安全にこれらのファイルシステムを使用するには、読み取りと書き込みが設定されているファイルシステムを、読み取り専用で共有しているファイルシステムとは別のパーティションまたはディスクスライスに配置します。

注 –

ファイルシステムの共有を解除してから再度共有するとき、NFS version 4 がどのように動作するかについては、「NFS version 4 におけるファイルシステムの共有解除と再共有」を参照してください。

非ファイルシステム用 share オプション

-o フラグに指定できるオプションの一部を次に示します。

rw|ro

pathname に指定したファイルシステムを、すべてのクライアントに対して読み取りと書き込みの両方が可能な状態で共有するか、読み取り専用で共有するかを指定します。

rw=accesslist

ファイルシステムは、リストに示されているクライアントに対してだけ、読み取りと書き込みの両方が可能な状態で共有されます。それ以外の要求は拒否されます。accesslist に定義されるクライアントのリストは、Solaris 2.6 から拡張されました。詳細については、「share コマンドを使ってアクセスリストを設定する」を参照してください。このオプションは -ro オプションよりも優先されます。

NFS 用 share オプション

NFS ファイルシステムで指定できるオプションは、次のとおりです。

aclok

このオプションを指定すると、NFS version 2 プロトコルをサポートしている NFS サーバーが NFS version 2 クライアントのアクセス制御を行うように設定できます。このオプションを指定しないと、すべてのクライアントは最小限のアクセスしかできません。指定すると、最大限のアクセスができるようになります。たとえば -aclok オプションを指定して共有したファイルシステムでは、1 人のユーザーが読み取り権を持っていれば全員が読み取りを許可されます。このオプションを指定しないと、アクセス権を持つべきクライアントからのアクセスが拒否される可能性があります。ユーザーに与えるアクセス権は、既存のセキュリティーシステムによって決定します。アクセス制御リスト (ACL) の詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「アクセス制御リストによる UFS ファイルの保護」を参照してください。

注 –

アクセス制御リスト (ACL) を使用するには、クライアントとサーバーが、NFS version 3 プロトコルおよび NFS_ACL プロトコルをサポートしているソフトウェアを実行している必要があります。NFS version 3 プロトコルしかサポートしていないソフトウェアの場合、クライアントは正しいアクセス権を取得できますが、ACL を操作することはできません。NFS_ACL プロトコルをサポートしていれば、正しいアクセス権を取得した上で ACL の操作も可能です。この両方をサポートしているのは、Solaris 2.5 およびその互換バージョンです。

anon=uid

uid は、認証されていないユーザーのユーザー ID を選択するために使用します。uid を -1 に設定すると、認証されていないユーザーからのアクセスは拒否されます。anon=0 とするとルートアクセス権を与えることができますが、これのオプションを指定すると、認証されていないユーザーにルートアクセス権を与えることになるため、代わりに root オプションを使用してください。

index=filename

-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
log=tag

このオプションは、ファイルシステム用の NFS サーバーログ構成情報の入った /etc/nfs/nfslog.conf 内のタグを指定します。NFS サーバーログ機能を使用可能にするにはこのオプションを選択する必要があります。

nosuid

このオプションを使用すると、setuid モードまたは setgid モードを有効にしようとしても無視されます。NFS クライアントは、setuid か setgid のビットがオンの状態ではファイルを作成できません。

public

-public オプションは、WebNFS ブラウズのために追加されました。このオプションで共有できるのは、1 台のサーバーにつき 1 つのファイルシステムだけです。

root=accesslist

サーバーが、リスト上のホストに対してルートアクセス権を与えます。デフォルトでは、サーバーはどのリモートホストにもルートアクセス権は与えません。選択されているセキュリティーモードが -sec=sys 以外だと、accesslist に指定できるのはクライアントホスト名だけです。accesslist に定義されたクライアントのリストは、Solaris 2.6 で拡張されました。詳細については、「share コマンドを使ってアクセスリストを設定する」を参照してください。

注意 – 注意 –

ほかのホストにルートアクセス権を与えるには、広い範囲でセキュリティーが保証されていることが前提です。-root= オプションは十分慎重に使用してください。

root=client-name

client-name の値は、AUTH_SYS 認証で、exportfs(1B) で取得されたアドレスのリストにクライアントの IP アドレスが含まれているかどうかを検査するために使用します。リストに一致する IP アドレスが見つかった場合、クライアントに共有ファイルシステムへのルートアクセス権が与えられます。

root=host-name

AUTH_SYS または RPCSEC_GSS などのセキュリティー保護された NFS モードの場合、サーバーは、アクセスリストから派生したホストベースの主体名のリストに、クライアントの主体名が含まれているかどうかを検査します。クライアント主体名の汎用構文は root@hostname です。Kerberos V の場合、構文は root/hostname.fully.qualified@REALM です。host-name の値を使用する場合、アクセスリスト上のクライアントには主体名の資格が必要になります。Kerberos V の場合、クライアントには root/hostname.fully.qualified@REALM の主体名の有効な keytab エントリが必要です。詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「Kerberos クライアントの構成」を参照してください。

sec=mode[:mode]

mode は、ファイルシステムへのアクセス権を取得するために必要なセキュリティーモードです。デフォルトのセキュリティーモードは、UNIX の認証です。モードは複数指定できますが、コマンド行に指定するときは 1 行につき 1 つのセキュリティーモードだけにしてください。各 -mode オプションはほかの -mode が検出されるまで、後続のすべての -rw、-ro、-rw=、- ro=、-root=、および -window= オプションに適用されます。-sec=none とすると、すべてのユーザーがユーザー nobody にマップされます。

window=value

value は、NFS サーバーで資格が有効な時間の上限です。デフォルトは 30000 秒 (8.3 時間) です。

share コマンドを使ってアクセスリストを設定する

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.example.com ドメイン内のすべてのホストへのアクセスを許可するためのものです。


# share -F nfs -o ro=.:.eng.example.com /export/share/man

この例で、「.」はそれぞれ NIS または NIS+ 名前空間を通じて一致するすべてのホストに対応します。ネームサービスから返される結果にはドメイン名は含まれません。「.eng.example.com」というエントリは、名前空間の解決に DNS を使用するすべてのホストに一致します。DNS が返すホスト名は必ず完全指定の名前になるので、DNS と他の名前空間を組み合わせると長いエントリが必要です。

実際のネットワーク番号かネットワーク名の前に「@」を指定すると、アクセスリストの中でサブネット番号を使用できます。この文字は、ネットワーク名をネットグループ名や完全指定のホスト名と区別するためです。サブネットは、/etc/networks の中か NIS または NIS+ 名前空間の中で識別できなければなりません。次のエントリは、サブネット 192.168 が eng ネットワークと識別されている場合、すべて同じ意味を持ちます。


# share -F nfs -o ro=@eng /export/share/man
# share -F nfs -o ro=@192.168 /export/share/man
# share -F nfs -o ro=@192.168.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=@192.168.0/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 コマンド

このコマンドを使用すると、以前に使用可能な状態になっていたファイルシステムを、クライアントがマウントできないようにします。unshare コマンドを使用すると、share コマンドで共有したファイルシステムや、/etc/dfs/dfstab で自動的に共有しているファイルシステムが共有できないようになります。unshare コマンドを使って dfstab ファイルを使って共有していたファイルシステムの共有を解除する場合は、注意が必要です。一度実行レベル 3 を終了し再度実行すると、ファイルシステムは再度共有されます。実行レベル 3 を終了しても変更内容を継続させるには、そのファイルシステムを dfstab ファイルから削除する必要があります。

NFS ファイルシステムの共有を解除している場合、クライアントから既存マウントへのアクセスは禁止されます。クライアントにはファイルシステムがまだマウントされている可能性がありますが、ファイルにはアクセスできません。

注 –

ファイルシステムの共有を解除してから再度共有するとき、NFS version 4 がどのように動作するかについては、「NFS version 4 におけるファイルシステムの共有解除と再共有」を参照してください。

次の例では、指定したファイルシステムの共有が解除されます。


# unshare /usr/src

shareall コマンド

このコマンドを使用すると、複数のファイルシステムを共有することができます。オプションなしで使用すると、/etc/dfs/dfstab 内のすべてのエントリが共有されます。share コマンドを並べたファイルの名前を指定することができます。ファイル名を指定しないと、/etc/dfs/dfstab の内容が検査されます。「-」を使ってファイル名を置き換えれば、標準入力から share コマンドを入力できます。

次の例では、ローカルファイルに一覧表示されているすべてのファイルシステムが共有されます。 


# shareall /etc/dfs/special_dfstab

unshareall コマンド

このコマンドを使用すると、現在共有されているリソースがすべて使用できなくなります。-F FSType オプションによって、/etc/dfs/fstypes に定義されているファイルシステムタイプのリストを選択します。このフラグによって、特定のタイプのファイルシステムだけを共有解除できます。デフォルトのファイルシステムタイプは、/etc/dfs/fstypes に定義されています。特定のファイルシステムを選択するには、unshare コマンドを使います。

次の例では、NFS タイプのファイルシステムの共有がすべて解除されます。


# unshareall -F nfs

showmount コマンド

このコマンドは、次のいずれかを表示します。

注 –

showmount コマンドを使用すると、NFS version 2 と version 3 のエクスポートだけが表示され、NFS version 4 のエクスポートは表示されません。

コマンドは、次のような構文になります。

showmount [ -ade ] [ hostname ]

-a

すべてのリモートマウントのリストを出力します。各エントリには、クライアント名とディレクトリが含まれます。

-d

クライアントがリモートマウントしたディレクトリのリストを表示します。

-e

共有されているファイル、またはエクスポートされたファイルのリストを表示します。

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

setmnt コマンド

このコマンドを使用すると、/etc/mnttab テーブルが作成されます。このテーブルは、mount コマンドと umount コマンドで参照されます。通常、このコマンドは、システムのブート時に自動的に実行されるため、手動で実行する必要はありません。

NFS のトラブルシューティング用のコマンド

NFS のトラブルシューティングには次のコマンドを使用します。

nfsstat コマンド

このコマンドを使用すると、NFS と RPC 接続について統計情報を収集できます。このコマンドの構文は次のとおりです。

nfsstat [ -cmnrsz ]

-c

クライアント側の情報を表示します

-m

NFS マウントされた各ファイルシステムの統計を表示します

-n

クライアント側とサーバー側の両方で、NFS の情報が表示されるように指定します

-r

RPC 統計を表示します

-s

サーバー側の情報を表示します

-z

統計をゼロに設定するように指定します

コマンド行にオプションを指定しないと、-cnrs が使用されます。

新しいソフトウェアやハードウェアを処理環境に追加した場合、サーバー側の統計を収集することが、デバッグにたいへん役立ちます。このコマンドを週に最低 1 度は実行し、履歴を作成するようにしてください。統計を保存しておくと、以前のパフォーマンスの有効な記録となります。

次の例を参照してください。


# nfsstat -s

Server rpc:
Connection oriented:
calls      badcalls   nullrecv   badlen     xdrcall    dupchecks  dupreqs    
719949194  0          0          0          0          58478624   33         
Connectionless:
calls      badcalls   nullrecv   badlen     xdrcall    dupchecks  dupreqs    
73753609   0          0          0          0          987278     7254       

Server nfs:
calls                badcalls             
787783794            3516                 
Version 2: (746607 calls)
null       getattr    setattr    root       lookup     readlink   read       
883 0%     60 0%      45 0%      0 0%       177446 23% 1489 0%    537366 71% 
wrcache    write      create     remove     rename     link       symlink    
0 0%       1105 0%    47 0%      59 0%      28 0%      10 0%      9 0%       
mkdir      rmdir      readdir    statfs     
26 0%      0 0%       27926 3%   108 0%     
Version 3: (728863853 calls)
null          getattr       setattr       lookup        access        
1365467 0%    496667075 68% 8864191 1%    66510206 9%   19131659 2%   
readlink      read          write         create        mkdir         
414705 0%     80123469 10%  18740690 2%   4135195 0%    327059 0%     
symlink       mknod         remove        rmdir         rename        
101415 0%     9605 0%       6533288 0%    111810 0%     366267 0%     
link          readdir       readdirplus   fsstat        fsinfo        
2572965 0%    519346 0%     2726631 0%    13320640 1%   60161 0%      
pathconf      commit        
13181 0%      6248828 0%    
Version 4: (54871870 calls)
null                compound            
266963 0%           54604907 99%        
Version 4: (167573814 operations)
reserved            access              close               commit              
0 0%                2663957 1%          2692328 1%          1166001 0%          
create              delegpurge          delegreturn         getattr             
167423 0%           0 0%                1802019 1%          26405254 15%        
getfh               link                lock                lockt               
11534581 6%         113212 0%           207723 0%           265 0%              
locku               lookup              lookupp             nverify             
230430 0%           11059722 6%         423514 0%           21386866 12%        
open                openattr            open_confirm        open_downgrade      
2835459 1%          4138 0%             18959 0%            3106 0%             
putfh               putpubfh            putrootfh           read                
52606920 31%        0 0%                35776 0%            4325432 2%          
readdir             readlink            remove              rename              
606651 0%           38043 0%            560797 0%           248990 0%           
renew               restorefh           savefh              secinfo             
2330092 1%          8711358 5%          11639329 6%         19384 0%            
setattr             setclientid         setclientid_confirm verify              
453126 0%           16349 0%            16356 0%            2484 0%             
write               release_lockowner   illegal             
3247770 1%          0 0%                0 0%                

Server nfs_acl:
Version 2: (694979 calls)
null        getacl      setacl      getattr     access      getxattrdir 
0 0%        42358 6%    0 0%        584553 84%  68068 9%    0 0%        
Version 3: (2465011 calls)
null        getacl      setacl      getxattrdir 
0 0%        1293312 52% 1131 0%     1170568 47%

このリストは、NFS サーバーの統計の例です。最初の 5 行は RPC に関するもので、残りの部分は NFS のアクティビティーのレポートです。どちらの統計でも、badcalls または calls の平均値、および各週の calls の数がわかるので、問題を特定するのに役立ちます。badcalls 値は、クライアントからの不良メッセージ数を示しています。この値は、ネットワークのハードウェアに問題が発生したことを示す場合があります。

いくつかの接続では、ディスクに対する書き込みアクティビティーが発生します。この数値の急激な上昇は障害の可能性を示すものなので、調査が必要です。NFS version 2 の統計で注意が必要なのは、setattr、write、create、remove、rename、link、symlink、mkdir、および rmdir です。NFS version 3 と version 4 では、commit の値に特に注意します。ある NFS サーバーの commit レベルが、それと同等のサーバーと比較して高い場合は、NFS クライアントに十分なメモリーがあるかどうかを確認してください。サーバーの commit オペレーションの数は、クライアントにリソースがない場合に上昇します。

pstack コマンド

このコマンドを使用すると、各プロセスのスタックトレースが表示されます。pstack コマンドは、必ずプロセスの所有者、または root として実行してください。pstack を使用して、プロセスがハングアップした場所を判断します。使用できるオプションは、確認するプロセスの PID だけです。proc(1) のマニュアルページを参照してください。

次の例では、実行中の nfsd プロセスを確認しています。


# /usr/bin/pgrep nfsd
243
# /usr/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 のトラブルシューティングの手順」を参照してください。

rpcinfo コマンド

このコマンドは、システムで動作している RPC サービスに関する情報を生成します。RPC サービスの変更にも使用できます。このコマンドには、たくさんのオプションがあります。rpcinfo(1M) のマニュアルページを参照してください。次は、このコマンドで使用できるオプションの構文です。

rpcinfo [ -m | -s ] [ hostname ]

rpcinfo -T transport hostname [ progname ]

rpcinfo [ -t | -u ] [ hostname ] [ progname ]

-m

rpcbind 処理の統計テーブルを表示します

-s

登録されているすべての RPC プログラムを簡易リストで表示します

-T

特定のトランスポートまたはプロトコルを使用するサービスの情報を表示します

-t

TCP を使用する RPC プログラムを検索します

-u

UDP を使用する RPC プログラムを検索します

transport

サービスに使用するトランスポートまたはプロトコルを選択します

hostname

必要な情報の取得元のサーバーのホスト名を選択します

progname

情報の取得対象の RPC プログラムを選択します

hostname を指定しないと、ローカルホスト名が使用されます。progname の代わりに RPC プログラム番号が使用できますが、ユーザーが覚えやすいのは番号よりも名前です。NFS version 3 が実行されていないシステムでは、-s オプションの代わりに -p オプションを使用できます。

このコマンドを実行すると、次の項目を含むデータを生成することができます。

次の例では、サーバーで実行されている 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
    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 サービスの情報を収集する方法について説明しています。最初の例では、TCP で実行されている mountd サービスをチェックしています。2 番目の例では、UDP で実行されている NFS サービスをチェックしています。


% 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

snoop コマンド

このコマンドは、ネットワーク上のパケットの監視によく使用されます。snoop コマンドは、root で実行する必要があります。このコマンドは、クライアントとサーバーの両方で、ネットワークハードウェアが機能しているかどうかを確認する方法としてよく使用されます。使用できるオプションは多数あります。snoop(1m) のマニュアルページを参照してください。次で、このコマンドの概要を説明します。

snoop [ -d device ] [ -o filename ] [ host hostname ]

-d device

ローカルネットワークのインタフェースを指定します

-o filename

受信したすべてのパケットを指定したファイルに保存します

hostname

特定のホストが送受信したパケットを表示します

-d device オプションは、複数のネットワークインタフェースがあるサーバーで特に有効です。ホストの設定以外にも、使用できる式が多数あります。コマンド正規表現を grep で組み合わせることでも、十分に使用できるデータを生成できます。

トラブルシューティングをする場合は、パケットの発信元と送信先のホストが正しいことを確認してください。また、エラーメッセージも調べてください。パケットをファイルに保存すると、データを簡単に参照することができます。

truss コマンド

このコマンドを使用すると、プロセスがハングアップしたかどうかを確認できます。truss コマンドは、必ずプロセスの所有者、または root として実行してください。このコマンドに指定できるオプションは多数あります。truss(1) のマニュアルページを参照してください。次で、このコマンドの構文を説明します。

truss [ -t syscall ] -p pid

-t syscall

追跡するシステムコールを選択します

-p pid

追跡するプロセスの PID を指定します

syscall には、追跡するシステムコールをコンマで区切って指定することもできます。また、syscall の指定を ! で始めると、そのシステムコールは追跡されなくなります。

次の例は、プロセスが新しいクライアントからの接続要求を待っていることを示しています。 


# /usr/bin/truss -p 243
poll(0x00024D50, 2, -1)         (sleeping...)

これは正常な反応です。新規接続の要求が行われた後でも反応が変わらない場合、そのプロセスはハングアップしている可能性があります。「NFS サービスを再起動する方法」の指示に従ってハングアップの問題を解決してください。ハングアップしたプログラムによって問題が発生しているかどうかを確実に判断するには、「NFS のトラブルシューティングの手順」を参照してください。

RDMA 経由の NFS

Solaris 10 リリースでは、RDMA (Remote Direct Memory Access) プロトコルが導入されています。RDMAは、高速ネットワーク上でデータのメモリー間転送を行うテクノロジです。特に、RDMA により、CPU の介入なしでメモリーに遠隔データ転送を直接行えます。また、データを直接配置できます。これは、データのコピーを省略し、さらに CPU の介入も省略します。このように、RDMA はホストの CPU を解放するだけでなく、ホストのメモリーと入出力バスの接続も減らします。この機能を提供するために、RDMA は、SPARC プラットフォーム上の InfiniBand のインターコネクト入出力テクノロジと Solaris オペレーティングシステムを組み合わせます。次の図は、UDP や TCP など、その他のプロトコルとの RDMA の関係を示します。

図 6–1 その他のプロトコルとの RDMA の関係

図については本文で説明します。

RDMA トランスポートをクライアントとサーバーで使用できない場合、TCP トランスポートが初期フォールバックになります。TCP が使用できない場合は UDP がフォールバックになります。ただし、proto=rdma マウントオプションを使用する場合、NFS マウントは強制的に RDMA だけになることに注意してください。

NFS マウントオプションの詳細は、mount_nfs(1M) のマニュアルページおよび 「mount コマンド」を参照してください。

注 –

InfiniBand の RDMA は、IP アドレス指定形式および IP ルックアップインフラストラクチャーを使用して、ピアを指定します。ただし、RDMA は、独立したプロトコルスタックであるため、すべての IP のセマンティクスを完全には実装しません。たとえば、RDMA はピアと通信するための IP アドレス指定を使用しません。したがって、RDMA は、IP アドレスに基づいたさまざまなセキュリティーポリシーの設定を省略することがあります。ただし、mount 制限や Secure RPC などの NFS と RPC の管理ポリシーは省略されません。

NFS サービスのしくみ

次の節では、NFS の複雑な機能をいくつか紹介します。この節で紹介する機能のいくつかは、NFS version 4 専用であることに注意してください。

注 –

システムでゾーンが有効なときに非大域ゾーンでこの機能を使用するには、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』を参照してください。

NFS におけるバージョンのネゴシエーション

NFS 起動プロセスには、サーバーとクライアントのプロトコルレベルのネゴシエーションが含まれています。バージョンのレベルを指定しない場合、デフォルトにより最適なレベルが選択されます。たとえば、クライアントとサーバーの両方が version 3 をサポートしていると、version 3 が使用されます。クライアントまたはサーバーが version 2 しかサポートしていないと、version 2 が使用されます。

Solaris 10 以降のリリースでは、/etc/default/nfs ファイルにキーワード NFS_CLIENT_VERSMIN、NFS_CLIENT_VERSMAX、NFS_SERVER_VERSMIN、NFS_SERVER_VERSMAX を設定できます。これらのキーワードのデフォルト値に代わって、クライアントとサーバーに最小値と最大値を指定できます。クライアントとサーバーの最小値は 2 がデフォルトで、最大値は 4 がデフォルトです。「/etc/default/nfs ファイルのキーワード」 を参照してください。サーバーがサポートするバージョンを検出するために、NFS クライアントは NFS_CLIENT_VERSMAX の設定から始めて、NFS_CLIENT_VERSMIN のバージョン設定に到るまで各バージョンを試行し続けます。サポートされるバージョンが検出されるとすぐに、この処理は終了します。たとえば、NFS_CLIENT_VERSMAX=4 および NFS_CLIENT_VERSMIN=2 と設定すると、クライアントは version 4、version 3、version 2 の順に試行します。NFS_CLIENT_VERSMIN と NFS_CLIENT_VERSMAX が同じ値に設定されていると、クライアントは常にこの設定されたバージョンを使用し、その他のバージョンは試行しません。サーバーがこのバージョンをサポートしていない場合、マウントは失敗します。

注 –

ネゴシエーションによって決まった値を変更するには、mount コマンドで vers オプションを使用します。mount_nfs(1M) のマニュアルページを参照してください。

手順については、「NFS サービスの設定」を参照してください。

NFS version 4 における機能

version 4 の NFS は大幅に変更が行われました。この節では、これらの新しい機能を説明します。

注 –

Solaris 10 以降のリリースでは、NFS version 4 は LIPKEY/SPKM セキュリティー方式をサポートしません。また、mountd、nfslogd、および statd デーモンを使用しません。

NFS version 4 の使用に関する手順については、「NFS サービスの設定」を参照してください。

NFS version 4 におけるファイルシステムの共有解除と再共有

NFS version 3 と version 4 では、クライアントが共有を解除されたファイルシステムにアクセスしようとすると、サーバーはエラーコードを返します。ただし、NFS version 3 では、ファイルシステムが共有されなくなる前に、サーバーはクライアントが取得したロックを保持します。したがって、ファイルシステムが再度共有されるとき、NFS version 3 クライアントは、そのファイルシステムが共有解除されなかったかのように、ファイルシステムにアクセスできます。

NFS version 4 では、ファイルシステムの共有を解除するとき、そのファイルシステムにあるオープンファイルまたはファイルロックの状態がすべて削除されます。クライアントは、これらのファイルにアクセスしようとしたりロックしようとしたりすると、エラーを受け取ります。通常、このエラーは、アプリケーションに対する入出力エラーとして報告されます。ただし、オプションを変更するために現在共有されているファイルシステムを再共有しても、サーバーの状態は削除されません。

関連情報については、「NFS version 4 におけるクライアント回復」を参照するか、unshare_nfs(1M) のマニュアルページを参照してください。

NFS version 4 におけるファイルシステムの名前空間

NFS version 4 サーバーは、擬似ファイルシステムを作成し管理します。擬似ファイルシステムにより、クライアントは、サーバー上のエクスポートされた全ファイルにシームレスにアクセスできます。NFS version 4 より前のバージョンには、擬似ファイルシステムがありません。クライアントは、アクセスする各共有サーバーのファイルシステムに強制的にマウントされます。次のような例を考えます。

図 6–2 サーバーのファイルシステムとクライアントのファイルシステムの表示

図については本文で説明します。

クライアントには payroll ディレクトリと nfs4x ディレクトリは表示されません。これらのディレクトリはエクスポートされておらず、エクスポートされたディレクトリには通じていないためです。ただし、local ディレクトリは、エクスポートされたディレクトリであるため、クライアントに表示されます。projects ディレクトリは、エクスポートされたディレクトリ nfs4 に通じているため、クライアントに表示されます。このように、明示的にエクスポートされていないサーバーの名前空間の部分は、擬似ファイルシステムで橋渡しされます。この擬似ファイルシステムは、エクスポートされたディレクトリ、およびサーバーのエクスポートに通じるディレクトリだけを表示します。

擬似ファイルシステムは、ディレクトリだけを含む構造で、サーバーによって作成されます。擬似ファイルシステムにより、クライアントはエクスポートされたファイルシステムの階層を検索できるようになります。このようにして、クライアントの擬似ファイルシステムの表示は、エクスポートされたファイルシステムに通じるパスに限定されます。

以前のバージョンの NFS では、クライアントは、サーバーのファイルシステムを検索するには、各ファイルシステムをマウントする必要がありました。しかし、NFS version 4 では、サーバーの名前空間が次のことを行います。

POSIX に関連する理由により、Solaris NFS version 4 クライアントは、サーバーのファイルシステムの境界を越えません。境界を越えようとすると、クライアントはディレクトリを空のように見せます。この状況に対処するには、サーバーのファイルシステムごとにマウントを行う必要があります。

NFS version 4 における揮発性ファイルハンドル

ファイルハンドルは、サーバー上で作成され、ファイルとディレクトリを一意に識別する情報を持ちます。NFS version 2 と version 3 では、サーバーは持続的ファイルハンドルを返しました。したがって、クライアントは、サーバーが常に同じファイルを参照するファイルハンドルを生成することを保証できました。次に例を示します。

このように、サーバーがファイルハンドルを含むクライアントからの要求を受け取った場合、解決策は単純であり、ファイルハンドルは常に正しいファイルを参照します。

NFS を操作するためのファイルとディレクトリを識別するこの方法は、多くの UNIX ベースのサーバーに適しています。ただし、この方法は、ファイルのパス名などほかの識別方法を使用するサーバー上では実装できません。この問題を解決するために、NFS version 4 プロトコルは、サーバーがそのファイルハンドルが揮発性であることを宣言できるようにします。したがって、ファイルハンドルが変更されます。ファイルハンドルが変更された場合、クライアントは新しいファイルハンドルを検出する必要があります。

NFS version 2 と 3 のように、Solaris NFS version 4 サーバーは常に持続的ファイルハンドルを提供します。ただし、Solaris NFS version 4 以外のサーバーにアクセスする Solaris NFS version 4 クライアントは、そのサーバーが揮発性ファイルハンドルを使用する場合、揮発性ファイルハンドルをサポートする必要があります。特に、サーバーがクライアントにファイルハンドルが揮発性であることを知らせている場合は、クライアントはパス名とファイルハンドル間のマッピングをキャッシュする必要があります。クライアントは、期限切れになるまで、揮発性ファイルハンドルを使用します。期限が切れたとき、クライアントは次を実行します。

注 –

サーバーは、どのファイルハンドルが持続的あるいは揮発性かを、クライアントに常に知らせます。

揮発性ファイルハンドルは、次のいずれかの理由により期限切れになります。

クライアントが新しいファイルハンドルを検索できない場合、エラーメッセージが syslog ファイルに追加されます。このファイルにアクセスしようとすると、入出力エラーで失敗します。

NFS version 4 におけるクライアント回復

NFS version 4 プロトコルは、ステートフルプロトコルです。クライアントとサーバーが次の項目に関する現在の情報を管理するとき、プロトコルはステートフルです。

サーバーのクラッシュなどの障害が発生したとき、クライアントとサーバーは連携して、障害が発生する前のオープン状態とロック状態を再度確立します。

サーバーがクラッシュしてリブートしたとき、サーバーの状態は消失します。クライアントは、サーバーがリブートしたことを検出して、サーバーの状態の再構築を支援するプロセスを開始します。このプロセスは、クライアントがプロセスを指示するため、クライアント回復として知られています。

クライアントは、サーバーがリブートしたことを検出すると、ただちに現在の動作を停止して、クライアント回復のプロセスを開始します。回復プロセスが開始されたとき、次のようなメッセージが、システムエラーログ/var/adm/messages に表示されます。


NOTICE: Starting recovery server basil.example.company.com

回復プロセスの間、クライアントは、クライアントの以前の状態に関するサーバー情報を送信します。ただし、この間、クライアントはサーバーに新しい要求を送信しません。ファイルのオープンやファイルロックの設定の新しい要求は、サーバーが回復を完了するのを待ってから続行する必要があります。

クライアント回復プロセスが完了したとき、次のメッセージがシステムエラーログ /var/adm/messages に表示されます。


NOTICE: Recovery done for server basil.example.company.com

クライアントは、サーバーへの状態情報の送信を正常に完了しました。ただし、クライアントがこのプロセスを完了しても、その他のクライアントがサーバーに状態情報を送信するプロセスを完了していない可能性があります。したがって、しばらくの間、サーバーはオープンまたはロック要求を受け付けません。この期間は猶予期間として知られており、すべてのクライアントが回復を完了できるように指定されています。

猶予期間中に、クライアントが新しいファイルを開こうとしたり、新しいロックを確立しようとしたりすると、サーバーは GRACE エラーコードで要求を拒否します。このエラーを受け取ったとき、クライアントは猶予期間が終わるのを待ってから、要求をサーバーに再送信します。猶予期間中は、次のメッセージが表示されます。


NFS server recovering

猶予期間中、ファイルを開いたりファイルロックを設定したりしないコマンドは処理できることに注意してください。たとえば、コマンド ls と cd はファイルを開いたりファイルロックを設定したりしません。したがって、これらのコマンドは中断されません。ただし、ファイルを開く cat などのコマンドは、猶予期間が終わるまで中断されます。

猶予期間が終了すると、次のメッセージが表示されます。


NFS server recovery ok.

クライアントは、サーバーに新しいオープン要求またはロック要求を送信できるようになります。

クライアント回復は、さまざまな理由により失敗することがあります。たとえば、サーバーのリブート後にネットワークパーティションが存在する場合、クライアントは、猶予期間が終了する前にサーバーとの状態を再度確立できません。猶予期間が終了すると、新しい状態操作により競合が発生するため、サーバーはクライアントに状態の再確立を許可しません。たとえば、新しいファイルロックは、クライアントが回復しようとしている古いファイルロックと競合します。このような状況が発生すると、サーバーは NO_GRACE エラーコードをクライアントに返します。

特定のファイルに対するオープン操作の回復が失敗すると、クライアントはファイルを使用不可能としてマークし、次のメッセージが表示されます。


WARNING: The following NFS file could not be recovered and was marked dead 
(can't reopen:  NFS status 70):  file :  filename

番号 70 は 1 つの例です。

回復中にファイルロックの再確立が失敗した場合、次のエラーメッセージが送信されます。


NOTICE: nfs4_send_siglost:  pid PROCESS-ID lost
lock on server SERVER-NAME

この場合、SIGLOST シグナルがプロセスに送信されます。SIGLOST シグナルのデフォルトの動作は、プロセスを中断することです。

この状態から回復するには、障害発生時にファイルを開いていたすべてのアプリケーションを再起動する必要があります。次のことに注意してください。

このように、特定のファイルにアクセスできるプロセスとアクセスできないプロセスがあります。

NFS version 4 における OPEN 共有サポート

NFS version 4 プロトコルには、クライアントがほかのクライアントによるファイルアクセスの制御に使用するファイル共有モードがいくつかあります。クライアントは、次のように指定できます。

Solaris NFS version 4 サーバーは、これらのファイル共有モードを完全に実装します。したがって、クライアントが現在の共有モードと矛盾する方法でファイルを開こうとすると、サーバーは操作を失敗させて、その試行を拒否します。このような試行が、ファイルのオープン操作または作成操作の開始に失敗すると、Solaris NFS version 4 クライアントはプロトコルエラーを受け取ります。このエラーは、アプリケーションエラー EACCES にマップされます。

プロトコルにはいくつかの共有モードがありますが、現在のところ、Solaris でのオープン操作では、複数の共有モードを提供していません。ファイルを開くとき、Solaris NFS version 4 クライアントは、DENY_NONE モードだけを使用します。

また、Solaris fcntl システムコールには、ファイルの共有を制御する F_SHARE コマンドがありますが、fcntl コマンドは NFS version 4 では正しく実装されません。NFS version 4 クライアントで fcntl コマンドを使用すると、クライアントはアプリケーションに EAGAIN エラーを返します。

NFS version 4 における委託

NFS version 4 は、委託のクライアントサポートとサーバーサポートを提供します。委託とは、サーバーがファイルの管理をクライアントに委託するテクニックです。たとえば、サーバーは、読み取り委託または書き込み委託のいずれかをクライアントに付与できます。読み込み委託は互いに競合しないため、複数のクライアントに同時に付与できます。書き込み委託はほかのクライアントのファイルアクセスと競合するため、1 つのクライアントにだけ付与できます。書き込み委託を保持している間、クライアントは、ファイルへの排他的アクセスを保証されているために、さまざまな操作をサーバーに送信しません。同様に、読み込み委託を保持している間、クライアントはさまざまな操作をサーバーに送信しません。クライアントが書き込みモードでファイルを開けないことをサーバーが保証するためです。委託により、委託されたファイルに対するサーバーとクライアントの相互作用を大幅に減少することができます。したがって、ネットワークトラフィックが減少し、クライアントとサーバーのパフォーマンスが向上します。ただし、パフォーマンス向上の度合いは、アプリケーションが使用するファイルの相互作用の種類およびネットワークとサーバー輻輳の量によって異なります。

委託を付与するかどうかの決定は、サーバーがすべて行います。クライアントは、委託を要求しません。サーバーは、ファイルに対するアクセスパターンに基づいて、委託を付与するかどうかを決定します。複数の異なるクライアントから書き込みモードで、ファイルが最近アクセスされた場合、サーバーは委託を付与しないことがあります。このアクセスパターンは将来競合する可能性があることを示しているためです。

競合は、ファイルに付与されている委託と一致しない方法でクライアントがそのファイルにアクセスするときに発生します。たとえば、あるクライアントがファイルの書き込み委託を保持しており、2 番目のクライアントが読み取りまたは書き込みアクセス用にそのファイルを開くとサーバーは最初のクライアントの書き込み委託を再呼び出しします。同様に、あるクライアントが読み取り委託を保持しており、別のクライアントが書き込み用に同じファイルを開くと、サーバーは読み取り委託を再呼び出しします。どちらの場合も、競合が存在しているため、2 番目のクライアントは委託を付与されません。競合が発生すると、サーバーはコールバックメカニズムを使用して、委託を保持しているクライアントと連絡をとります。このコールバックを受信すると、クライアントはファイルの更新された状態をサーバーに送信し、委託を返します。クライアントが再呼び出しに対する応答に失敗すると、サーバーは委託を取り消します。こうした場合、サーバーはこのファイルに対するクライアントの操作をすべて拒否し、クライアントは要求された操作を失敗として報告します。一般的に、これらの失敗は入出力エラーとしてアプリケーションに報告されます。これらのエラーから回復するには、ファイルを閉じてから再度開く必要があります。取り消された委託による失敗は、クライアントが委託を保持している間にクライアントとサーバー間にネットワークパーティションが存在しているときに発生します。

サーバーは、別のサーバーに格納されているファイルに対するアクセスの競合を解決できません。つまり、NFS サーバーは、格納しているファイルに対する競合だけを解決します。さらに、さまざまなバージョンの NFS を実行しているクライアントによって発生する競合に対して、NFS サーバーは NFS version 4 を実行しているクライアントにだけ再呼び出しを開始します。以前のバージョンの NFS を実行しているクライアントに再呼び出しを開始できません。

競合を検出するプロセスはさまざまです。たとえば、NFS version 4 とは異なり、version 2 と version 3 にはオープン手順がないため、クライアントがファイルの読み取り、書き込み、またはロックを試行したあとでのみ、競合が検出されます。これらの競合に対するサーバーの応答もさまざまです。次に例を示します。

これらの状態は、委託の競合が解決されたときにクリアされます。

デフォルトでは、サーバー委託は有効になっています。/etc/default/nfs ファイルを変更すると、委託を無効にできます。手順については、「サーバー上で異なるバージョンの NFS を選択する方法」を参照してください。

クライアントの委託にキーワードは必要ありません。NFS version 4 コールバックデーモン nfs4cbd により、クライアント上のコールバックサービスが提供されます。このデーモンは、NFS version 4 のマウントが有効になると自動的に起動されます。デフォルトで、クライアントは、/etc/netconfig システムファイルに一覧表示されているすべてのインターネット転送に必要なコールバック情報を提供します。クライアントで IPv6 が有効であり、クライアントの名前の IPv6 アドレスが指定されている場合、コールバックデーモンは IPv6 接続を受け入れます。

コールバックデーモンは、一時的なプログラム番号と動的に割り当てられたポート番号を使用します。この情報は、サーバーに提供され、サーバーは委託を付与する前にコールバックパスをテストします。コールバックパスが正常にテストされない場合、サーバーは委託を付与しません。外部から見ることのできる動作だけになります。

コールバック情報は NFS version 4 要求に組み込まれているため、サーバーは、NAT (Network Address Translation) を使用するデバイスを通してクライアントと連絡を取ることができません。また、コールバックデーモンは、動的ポート番号も使用します。したがって、ファイアウォールがポート 2049 上で通常の NFS トラフィックを有効にしている場合でも、サーバーがファイアウォールを検索できない場合があります。この場合、サーバーは委託を付与しません。

NFS version 4 での ACL と nfsmapid

アクセス制御リスト (ACL) は、ファイルの所有者が、ファイル所有者、グループ、そのほかの固有のユーザーおよびグループに関するファイルアクセス権を定義できるようにすることで、ファイルのセキュリティーを高めます。ACL は、setfacl コマンドを使用することで、サーバーおよびクライアント上で設定されます。詳細については、setfacl(1) のマニュアルページを参照してください。NFS version 4 では、ID マッパー nfsmapid を使用して、サーバー上の ACL エントリ内のユーザーまたはグループ ID を、クライアント上の ACL エントリ内のユーザーまたはグループ ID にマッピングします。逆も同じです。ACL エントリのユーザーおよびグループ ID は、クライアントとサーバーの両方に存在する必要があります。

ID マッピングが失敗する理由

次の状態は、ID マッピングが失敗する原因になる可能性があります。

ACL を使用した ID マッピングの問題を回避する

ID マッピングの問題を回避するには、次の処置を行います。

ACL エントリ内のすべてのユーザーおよびグループ ID が NFS version 4 のクライアントとサーバーの両方に存在することを確認します。

サーバーまたはクライアント上でユーザーまたはグループをマッピングできるかどうかを判別するには、次のスクリプトを使用します。


#! /usr/sbin/dtrace -Fs

sdt:::nfs4-acl-nobody
{
     printf("validate_idmapping: (%s) in the ACL could not be mapped!", 
stringof(arg0));
}
注 –

このスクリプトで使用されているプローブ名は、将来変更される可能性があるインタフェースです。詳細については、『Solaris 動的トレースガイド』の「安定性レベル」を参照してください。

ACL または nfsmapid の追加情報

次を参照してください。

UDP と TCP のネゴシエーション

開始時には、トランスポートプロトコルもネゴシエートされます。デフォルトでは、クライアントとサーバーの両方がサポートしているコネクション型トランスポートの中で最初に見つかったものが選択されます。それが見つからない場合は、コネクションレス型トランスポートプロトコルの中で最初に見つかったものが使用されます。システムでサポートされているトランスポートプロトコルのリストは、/etc/netconfig にあります。TCP はコネクション型トランスポートプロトコルで、Solaris 2.6 からサポートされています。UDP はコネクションレス型トランスポートプロトコルです。

NFS プロトコルのバージョンとトランスポートプロトコルが両方ともネゴシエーションによって決まった場合は、NFS プロトコルのバージョンがトランスポートプロトコルよりも優先されます。UDP を使用する NFS version 3 プロトコルの方が、TCP を使用する NFS version 2 プロトコルよりも優先されます。mount コマンドでは NFS プロトコルのバージョンもトランスポートプロトコルも手動で選択できます。mount_nfs(1M) のマニュアルページを参照してください。ほとんどの場合、ネゴシエーションによって選択されるオプションの方が適切です。

ファイル転送サイズのネゴシエーション

ファイル転送サイズは、クライアントとサーバーの間でデータを転送するときに使用されるバッファーのサイズです。原則として、ファイル転送サイズが大きいほどパフォーマンスが向上します。NFS version 3 には転送サイズに上限はありませんが、Solaris 2.6 以降がデフォルトで提示するバッファーサイズは 32K バイトです。クライアントは、必要であればマウント時にこれより小さい転送サイズを提示することができますが、ほとんどの場合その必要はありません。

転送サイズは、NFS version 2 を使用しているシステムとはネゴシエートされません。このとき、ファイル転送サイズの上限は 8K バイトに設定されます。

mount コマンドに対して -rsize オプションと -wsize オプションを使用すると、転送サイズを手動で設定できます。PC クライアントの一部では転送サイズを小さくする必要があります。また、NFS サーバーが大きなファイル転送サイズに設定されている場合は、転送サイズを大きくすることができます。

注 –

Solaris 10 以降のリリースでは、書き込み転送サイズの制限が緩和されました。使用するトランスポートプロトコルに基づいて転送サイズが決定されるようになりました。たとえば、UDP 使用時の NFS 転送の上限は、以前と同じく 32K バイトです。これに対し、TCP は UDP のようなデータグラム制限を持たないストリーミングプロトコルであるため、TCP 使用時の最大転送サイズは、1M バイトまで拡張されています。

ファイルシステムがどのようにマウントされるか

次の説明は、NFS version 3 のマウントに適用されます。NFS version 4 のマウントプロセスは、ポートマップサービスおよび MOUNT プロトコルを含みません。

クライアントがサーバーからファイルシステムをマウントするとき、クライアントはサーバーからファイルハンドルを取得する必要があります。ファイルハンドルは、そのファイルシステムに対応していなければなりません。そのためには、クライアントとサーバーの間でいくつかのトランザクションが発生します。この例では、クライアントはサーバーから /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) が使用可能かどうかをテストします。また、そのファイルハンドルを使うファイルシステムに関する 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 ポート番号を決定するためのトランザクションはありません。

注 –

NFS version 4 は、揮発性ファイルハンドルをサポートします。詳細は、「NFS version 4 における揮発性ファイルハンドル」を参照してください。

マウント時の -public オプションと NFS URL の意味

-public オプションを使用すると、マウントが失敗することがあります。NFS URL を組み合わせると、状況がさらに複雑になる可能性があります。これらのオプションを使用した場合にファイルシステムがどのようにマウントされるかは、次のとおりです。

クライアント側フェイルオーバー機能

クライアント側のフェイルオーバー機能を使用すると、NFS クライアントは同じデータを利用できる複数のサーバーを知ることができるため、現在のサーバーが使用不能になっても、ほかのサーバーに切り替えることができます。ファイルシステムが使用不能になる原因には次のものがあります。

通常、このような場合のフェイルオーバー機能はユーザーにはわかりません。つまり、フェイルオーバー機能はクライアント上のプロセスを中断することなく実行されます。

フェイルオーバー機能が行われるためには、ファイルシステムが読み取り専用でマウントされている必要があります。また、ファイルシステムが完全に同じでないとフェイルオーバー機能は成功しません。ファイルシステムが同一になる条件については、「複製されたファイルシステムとは」を参照してください。フェイルオーバー機能の候補としては、静的なファイルシステム、または変更の少ないファイルシステムが適しています。

同じ NFS マウント上では、CacheFS 機能とクライアント側のフェイルオーバー機能の両方は使用できません。CacheFS ファイルシステムは、それぞれについて追加情報が格納されています。この情報はフェイルオーバーの際に更新できないため、ファイルシステムをマウントするときにはフェイルオーバー機能と CacheFS のどちらか片方の機能しか使用できません。

各ファイルシステムについて用意すべき複製の数を決める要素はさまざまです。理想的には、サーバーを 2 台以上設置します。それぞれのサーバーが複数のサブネットをサポートする必要があります。これは、各サブネットに一意のサーバーを設置するよりもよい方法です。フェイルオーバー処理の際にはリストにある各サーバーが確認されます。そのため、サーバーの台数を増やすと、それぞれのマウント処理が遅くなります。

フェイルオーバー機能に関する用語

フェイルオーバー機能のプロセスを完全に理解するには、次の 2 つの用語を理解する必要があります。

複製されたファイルシステムとは

フェイルオーバー機能に関して、あるファイルシステムのすべてのファイルが元のファイルシステムのファイルとサイズもファイルタイプも同じ場合に、そのファイルシステムを「複製」といいます。アクセス権、作成日付などのファイル属性は関係ありません。ファイルサイズまたはファイルタイプが異なると再マッピングは失敗し、元のサーバーが再び使用可能になるまでプロセスはハングアップします。NFS version 4 では、動作が異なります。「NFS version 4 におけるクライアント側フェイルオーバー機能」を参照してください。

複製されたファイルシステムを保守するには、rdist や cpio などのファイル転送メカニズムを使います。複製されたファイルシステムを更新すると不一致が発生するため、最良の結果を得るには次の予防策を考慮してください。

フェイルオーバー機能と NFS ロック

ソフトウェアパッケージの一部は、ファイルに読み取りロックをかける必要があります。そのようなソフトウェアが正常に動作できるようにするため、読み取り専用ファイルシステムに対しても読み取りロックがかけられるようになっています。ただし、これはクライアント側でしか認識されません。サーバー側で意識されないため、再マッピングされてもロックはそのまま残ります。ファイルはもともと変更が許されないので、サーバー側でファイルをロックする必要はありません。

NFS version 4 におけるクライアント側フェイルオーバー機能

NFS version 4 では、ファイルサイズが違うまたはファイルタイプが同じでないために複製が確立されない場合、次のことが起こります。

注 –

アプリケーションを再起動して、ファイルに再度アクセスすると、正常にアクセスできます。

NFS version 4 では、サイズが異なるディレクトリの複製エラーを受け取ることはありません。以前のバージョンの NFS では、この状態はエラーとして扱われ、再マッピングプロセスを妨げました。

さらに、NFS version 4 では、ディレクトリ読み取り操作が正常に行われない場合、次に一覧表示されたサーバーによって操作が行われます。以前のバージョンの NFS では、正常でない読み取り操作により、再マッピングが失敗し、プロセスは元のサーバーが使用可能になるまで停止しました。

大規模ファイル

Solaris 2.6 以降、Solaris OS は 2G バイトを超えるファイルをサポートします。デフォルトでは、UFS ファイルシステムはこの新機能をサポートするために -largefiles オプション付きでマウントされます。以前のリリースでは、2G バイトを超えるファイルは扱えません。具体的な方法については、「NFS サーバー上で大規模ファイルを無効にする方法」を参照してください。

-largefiles オプションを使ってサーバー上のファイルシステムをマウントする場合、大規模ファイルにアクセスするために Solaris 2.6 NFS クライアントを変更する必要はありません。ただし、Solaris 2.6 のコマンドすべてで大規模ファイルを扱えるわけではありません。大規模ファイルを扱えるコマンドについては、largefile(5) のマニュアルページを参照してください。大規模ファイル用機能拡張を備えた NFS version 3 プロトコルをサポートしていないクライアントは、大規模ファイルには一切アクセスできません。Solaris 2.5 クライアントでは、NFS version 3 プロトコルを使用することはできますが、大規模ファイルを扱う機能は含まれていません。

NFS サーバーログ機能のしくみ

NFS サーバーログ機能は NFS の読み取りと書き込み、およびこのファイルシステムを変更する操作の記録を提供します。このデータは情報へのアクセスを追跡するのに利用できます。さらに、この記録は、情報へのアクセスを測定する定量的な方法を提供します。

ログ機能が有効になっているファイルシステムにアクセスすると、カーネルが raw データをバッファーファイルに書き込みます。このデータには、次の内容が含まれています。

nfslogd デーモンはこの raw データを、ログファイルに保存される ASCII レコードに変換します。使用可能なネームサービス機能が一致しているものを見つけると、その変換中に IP アドレスはホスト名に変更され、UID はログインに変更されます。ファイルハンドルはパス名にも変換されます。デーモンはファイルハンドルを追跡し、情報を別のファイルハンドルパステーブルに保存して、変換を完了します。このようにすると、ファイルハンドルにアクセスされるたびに、パスを識別し直す必要がなくなります。nfslogd をオフにするとファイルハンドルパステーブルのマッピングが変更されなくなるため、デーモンは常に実行させておく必要があります。

注 –

サーバーロギングは NFS version 4 ではサポートされません。

WebNFS サービスのしくみ

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
注 –

NFS version 4 プロトコルは、WebNFS サービスに優先します。NFS version 4 は、MOUNT プロトコルと WebNFS サービスに追加されたすべてのセキュリティーネゴシエーションを完全に統合します。

WebNFS セキュリティーネゴシエーション機能のしくみ

Solaris 8 リリースから、WebNFS クライアントが WebNFS サーバーと、選択されたセキュリティーメカニズムについてネゴシエーションできるようにする新しいプロトコルがあります。この新しいプロトコルは、セキュリティーネゴシエーションマルチコンポーネントルックアップを使用しています。これは、WebNFS プロトコルの以前のバージョンで使用されていたマルチコンポーネントルックアップの拡張版です。

WebNFS クライアントは、公開ファイルハンドルを使って通常のマルチコンポーネントルックアップ要求を行うことにより、このプロセスを開始します。このクライアントには、サーバーがどのようにしてこのパスを保護しているかについての知識がないため、デフォルトのセキュリティーメカニズムが使用されます。デフォルトのセキュリティーメカニズムでは不十分な場合は、サーバーは AUTH_TOOWEAK エラーを返します。このメッセージは、そのデフォルトメカニズムが有効ではなく、クライアントはより強力なメカニズムを使用する必要があることを意味しています。

クライアントは、AUTH_TOOWEAK エラーを受信すると、サーバーに対してどのセキュリティーメカニズムが必要か決定するように要求します。この要求が成功すると、サーバーは、指定されたパスに必要なセキュリティーメカニズムの配列を返します。このセキュリティーメカニズムの配列のサイズによっては、クライアントは完全な配列を得るためにさらに要求を出さなければならない場合があります。サーバーが WebNFS セキュリティーネゴシエーションをサポートしていない場合は、この要求は失敗します。

要求が成功すると、WebNFS クライアントは、クライアントがサポートしている最初のセキュリティーメカニズムを配列から選択します。その後、クライアントは、選択したセキュリティーメカニズムを使用して、通常のマルチコンポーネントルックアップ要求を発行し、ファイルハンドルを獲得します。この後に続くすべての NFS 要求は、選択されたセキュリティーメカニズムとファイルハンドルを使って出されます。

注 –

NFS version 4 プロトコルは、WebNFS サービスに優先します。NFS version 4 は、MOUNT プロトコルと WebNFS サービスに追加されたすべてのセキュリティーネゴシエーションを完全に統合します。

Web ブラウザの使用と比較した場合の WebNFS の制約

HTTP を使用する Web サイトで実現可能な機能のいくつかは、WebNFS ではサポートされていません。この違いは、NFS サーバーはファイルを送るだけであるため、特別な処理はすべてクライアントで行う必要があることが原因です。ある Web サイトを WebNFS と HTTP 両方のアクセスに対応させるには、次を考慮してください。

Secure NFS システム

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 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 認証

DH 認証は、Data Encryption Standard (DES) と Diffie-Hellman 公開鍵暗号手法を使ってネットワーク上のユーザーとコンピュータの両方を認証します。DES は、標準の暗号化メカニズムです。Diffie-Hellman 公開鍵暗号手法は、2 つの鍵、つまり公開鍵と秘密鍵を持つ暗号方式です。 公開鍵と秘密鍵は名前空間に格納されます。NIS では、これらのキーは public-key マップに保存されています。これらのマップにはすべての認証の候補ユーザーの公開鍵と秘密鍵が入っています。このマップの設定方法については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

DH 認証のセキュリティーは、送信側が現在時刻を暗号化する機能に基づいていて、受信側はこれを復号化して、自分の時刻と照合します。タイムスタンプは DES を使用して暗号化されます。この方式が機能するには次の条件が必要です。

ネットワークが時間同期プログラムを実行する場合、クライアントとサーバー上の時間は自動的に同期がとられます。時間同期プログラムを使用できない場合、ネットワーク時間ではなく、サーバーの時間を使ってタイムスタンプを計算できます。クライアントは、RPC セッションを開始する前にサーバーに時間を要求し、自分のクロックとサーバーのクロックとの時間差を計算します。タイムスタンプを計算するときには、この差を使ってクライアントのクロックを補正します。クライアントとサーバーのクロックが同期していないと、サーバーはクライアントの要求を拒否します。その場合、クライアントの DH 認証システムはサーバーとの間で再び同期をとります。

クライアントとサーバーは、ランダムな「対話鍵」(「セッション鍵」とも呼ばれる) を生成したあと公開鍵暗号方式を使って「共通鍵」を推理することによって、同一の暗号化鍵に到達します。この共通鍵は、クライアントとサーバーだけが推理できる鍵です。対話鍵は、クライアントのタイムスタンプを暗号化および復号化するために使用されます。共通鍵は、この対話鍵を暗号化および復号化するために使用されます。

KERB 認証

Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos は、DES を含むさまざまな暗号化タイプを提供します。Kerberos サポートは Secure RPC の一部としては提供されなくなりましたが、Solaris 9 以降のリリースでは、サーバー側とクライアント側に実装されています。Kerberos 認証の実装に関する詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 21 章「Kerberos サービスについて」を参照してください。

NFS での Secure RPC の使用

Secure RPC を使用する場合は、次の点に注意してください。

autofs マップ

autofs は 3 種類のマップを使用します。

autofs マスターマップ

auto_master マップでは、ディレクトリからマップへの関連付けを行います。このマップは、すべてのマップを指定するマスターリストであり、autofs が参照します。auto_master ファイルの内容の例を次に示します。

例 6–3 /etc/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

mount-point は、ディレクトリのフル (絶対) パス名です。このディレクトリが存在しない場合、可能ならば autofs はこのディレクトリを作成します。このディレクトリが存在し、しかも空ではない場合、マウントすることによってその内容が隠されます。この場合、autofs は警告を出します。

マウントポイントとして /- を指定すると、この特定のマップが直接マップであり、マップに関連付けられている特定のマウントポイントがないことを表します。

map-name

map-name 名は、位置に対する指示またはマウント情報を検出するために、autofs が使用するマップです。この名前がスラッシュ (/) で始まる場合、autofs はこの名前をローカルファイルとして解釈します。そうでない場合、autofs はネームサービススイッチ構成ファイル (/etc/nsswitch.conf) で指定される検索によりマウント情報を検索します。また、/net には、特別なマップを使用します。詳細は、「/net マウントポイント」を参照してください。

mount-options

mount-options は省略できます。map-name のエントリにほかのオプションがある場合を除き、map-name で指定されたエントリのマウントに適用されるオプションをコンマで区切って並べます。特定のファイルシステムのマウントオプションについては、各ファイルシステムについてのマニュアルページを参照してください。たとえば、NFS に固有のマウントオプションについては、mount_nfs(1M) のマニュアルページを参照してください。NFS 固有のマウントポイントの場合、bg (バックグラウンド) オプションと fg (フォアグラウンド) オプションは適用されません。

# で始まる行はコメント行です。その行のテキストの最後まですべて無視されます。

長い行を短い行に分割するには、行末にバックスラッシュ (\) を入力します。入力できる文字数の上限は 1024 です。

注 –

2 つのエントリで同じマウントポイントが使用されるときは、1 番目のエントリは automount コマンドが使用します。2 番目のエントリは無視されます。

/home マウントポイント

/home マウントポイントは、/etc/auto_home (間接マップ) に記述されたエントリがマウントされるディレクトリです。

注 –

autofs はすべてのコンピュータで動作し、デフォルトでは /net と /home (自動マウントされるホームディレクトリ) をサポートします。このデフォルトは、NIS ならば auto.master マップ、NIS+ ならば auto_master テーブルを使用して、またはローカルの /etc/auto_master ファイルを編集することによって変更できます。

/net マウントポイント

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

key は直接マップでのマウントポイントのパス名です。

mount-options

mount-options は、このマウントに適用するオプションです。これらのオプションが必要なのは、マップのデフォルトと異なる場合だけです。特定のファイルシステムのマウントオプションについては、各ファイルシステムについてのマニュアルページを参照してください。たとえば、CacheFS に固有のマウントオプションについては、mount_cachefs(1M) のマニュアルページを参照してください。異なるバージョンの NFS での CacheFS オプションの使用については、「CacheFS を使用して NFS ファイルシステムにアクセスする」を参照してください。

location

location はファイルシステムの位置を示します。1 つまたは複数のファイルシステムを server: pathname (NFS ファイルシステムの場合)、または : devicename (High Sierra ファイルシステム (HSFS) の場合) で指定します。

注 –

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 がクライアント用のもっとも近い読み取り専用ファイルを選択する方法 (複数ロケーション)」を参照してください。

/- マウントポイント

例 6–3 にある /- というマウントポイントは、auto_direct の中のエントリを具体的なマウントポイントに関連付けないように autofs に指示します。間接マップの場合は、auto_master ファイルに定義されたマウントポイントを使います。直接マップの場合は、名前付きマップ内で指定したマウントポイントを使用します。直接マップ内では、キー、つまりマウントポイントはフルパス名であることに注意してください。

NIS または NIS+ の auto_master ファイルには、直接マップのエントリは 1 つしか存在できません。マウントポイントは 1 つの名前空間の中で一意でなければならないためです。auto_master がローカルファイルならば、重複しないかぎり直接マップのエントリがいくつあってもかまいません。

間接マップ

間接マップは、キーの置換値を使ってクライアント上のマウントポイントとサーバー上のディレクトリとを対応させます。間接マップは、ホームディレクトリなどの特定のファイルシステムをアクセスするのに便利です。auto_home マップは間接マップの一例です。

間接マップ内の行は次の一般的な構文になります。

key [ mount-options ] location

key

key は間接マップでの単純名 (スラッシュなし) です。

mount-options

mount-options は、このマウントに適用するオプションです。これらのオプションが必要なのは、マップのデフォルトと異なる場合だけです。特定のファイルシステムのマウントオプションについては、各ファイルシステムについてのマニュアルページを参照してください。たとえば、NFS に固有のマウントオプションについては、mount_nfs(1M) のマニュアルページを参照してください。

location

location はファイルシステムの位置を示します。1 つまたは複数のファイルシステムを server: pathname で指定します。

注 –

pathname に自動マウントされたマウントポイントを含めることはできません。pathname は、ファイルシステムの実際の絶対パスにするようにしてください。たとえば、ディレクトリの位置は、server:/net/server/usr/local ではなく、server :/usr/local として指定する必要があります。

マスターマップと同様、# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。長い行を短い行に分割するには、行の最後にバックスラッシュ (\) を入力します。例 6–3 に、次のエントリを含む 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 は、自動的に適切なファイルシステムをマウントするためのクライアント側のサービスです。自動マウントを行うのに、次のコンポーネントが相互に動作します。

自動マウントサービス svc:/system/filesystem/autofs は、システムの起動時に呼び出され、マスターマップファイル 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 は、ブート時にサービス svc:/system/filesystem/autofs によって起動されます。図 6–3 を参照してください。このサービスは automount コマンドも実行します。このコマンドはマスターマップを読み取り、autofs のマウントポイントをインストールします。詳細は、「autofs のナビゲーションプロセス開始法 (マスターマップ)」を参照してください。

図 6–3 svc:/system/filesystem/autofs サービスによる automount の起動

図については本文で説明します。

autofs は、自動マウント操作とアンマウント操作をサポートするカーネルファイルシステムの 1 つです。

    autofs マウントポイントで、ファイルシステムへのアクセスが要求された場合は、次の動作が行われます。

  1. autofs がその要求に介入します。

  2. autofs は要求されたファイルシステムをマウントするよう、automountd にメッセージを送信します。

  3. automountd がマップからファイルシステム情報を見つけ、マウントを実行します。

  4. autofs は、介入した要求の実行を続行させます。

  5. 一定時間そのファイルシステムがアクセスされないと、autofs はそのファイルシステムをアンマウントします。

注 –

autofs サービスによって管理されるマウントは、手動でマウントまたはアンマウントは行わないでください。たとえこの操作がうまくいったとしても、autofs サービスはオブジェクトがアンマウントされたことを認識しないので、一貫性が損なわれる恐れがあります。リブートによって、autofs のマウントポイントがすべて消去されます。

autofs のネットワークナビゲート (マップ)

autofs は一連のマップを探索することによって、ネットワークをナビゲートします。マップは、ネットワーク上の全ユーザーのパスワードエントリや、ネットワーク上の全ホストコンピュータの名前などの情報を含むファイルです。マップには UNIX の管理ファイルに相当するネットワーク規模の管理ファイルも含まれています。マップはローカルに使用するか、あるいは NIS や NIS+ のようなネットワークネームサービスを通じて使用できます。ユーザーは Solaris 管理コンソールツールを使用して、自分の環境ニーズに適合するマップを作成します。「autofs のネットワークナビゲート法の変更 (マップの変更)」を参照してください。

autofs のナビゲーションプロセス開始法 (マスターマップ)

automount コマンドはシステムの起動時にマスターマップを読み取ります。図 6–4 に示すように、マスターマップ内の各エントリは、直接または間接のマップ名、そのパス、およびそのマウントオプションです。エントリの順序は重要ではありません。automount は、マスターマップ内のエントリとマウントテーブル内のエントリを比較して、現在のリストを生成します。

図 6–4 マスターマップによるナビゲーション

図については本文で説明します。

autofs マウントプロセス

マウント要求が発生したときに autofs サービスが何を実行するかは、オートマウンタマップの設定によって異なります。マウントプロセスの基本はすべてのマウントで同じですが、指定されているマウントポイントとマップの複雑さによって結果が変わります。Solaris 2.6 ではマウントプロセスも変更され、トリガーノードも作成されるようになりました。

単純な autofs マウント

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 サービスは次の手順を実行します。

  1. サーバーのマウントサービスが使用可能かどうかを確認します。

  2. 要求されたファイルシステムを、/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 アンマウント」を参照してください。

autofs アンマウント

一定時間アクセスがないためにアンマウントされるときは、マウントと逆の順序で実行されます。あるディレクトリより上位のディレクトリが使用中であれば、それより下のディレクトリだけがアンマウントされます。アンマウントすると、トリガーノードがすべて削除され、ファイルシステムがアンマウントされます。ファイルシステムが使用中であれば、アンマウントは失敗してトリガーノードは再インストールされます。

注意 – 注意 –

階層的にマウントを指定する場合は、-soft オプションは使用しないでください。-soft オプションを使用すると、トリガーノードを再インストールする要求がタイムアウトすることがあります。トリガーノードを再インストールできないと、マウントの次の階層にアクセスできません。この問題を解決するには、オートマウンタを使用して、階層にあるすべてのコンポーネントのマウントを解除します。オートマウンタでアンマウントするには、ファイルシステムが自動的にアンマウントされるのを待つか、システムをリブートします。

autofs がクライアント用のもっとも近い読み取り専用ファイルを選択する方法 (複数ロケーション)

次は、直接マップの例です。


/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 プロトコルをサポートしているサーバーの数が数えられます。サポートしているサーバーの数が多いプロトコルがデフォルトになります。これによって、クライアントにとっては利用できるサーバーの数が最大になります。

プロトコルが同じバージョンのサーバーの組の中で数がもっとも多いものがわかると、サーバーのリストが距離によってソートされます。距離を判定するために、IPv4 アドレスが調査されます。IPv4 アドレスは、どのサーバーが各サブネットにあるかを示します。ローカルサブネット上のサーバーには、リモートサブネット上のサーバーよりも高い優先順位が付けられます。もっとも近いサーバーが優先されることにより、待ち時間とネットワークトラフィックが軽減されます。

注 –

IPv6 アドレスを使用している複製に対しては、距離を判定できません。

図 6–5 に、サーバーとの距離を示します。

図 6–5 サーバーとの距離

図については本文で説明します。

ローカルサブネット上に同じプロトコルをサポートしているサーバーが複数あるときは、それぞれのサーバーに接続する時間が計測され、速いものが使用されます。優先順位には、重み付けも関係します (「autofs と重み付け」を参照してください)。

たとえば、version 4 サーバーの方が多いと、version 4 がデフォルトで使用されるプロトコルになります。ただし、優先順位の決定は複雑になります。次に、優先順位の決定の例をいくつか示します。

注 –

また、重み付けも /etc/default/nfs ファイル内のキーワード値に影響されます。特に、NFS_SERVER_VERSMIN、NFS_CLIENT_VERSMIN、 NFS_SERVER_VERSMAX、および NFS_CLIENT_VERSMAX の値により、いくつかのバージョンを優先順位の決定から除外することができます。これらのキーワードについての詳細は、「/etc/default/nfs ファイルのキーワード」を参照してください。

フェイルオーバー機能を指定していると、この優先順位はサーバーが選択されるマウント時に確認されます。複数の場所を指定しておくと、個々のサーバーが一時的にファイルシステムをエクスポートできないときに便利です。

多くのサブネットを持つ大規模ネットワークでは、フェイルオーバーは特に便利です。autofs は適切なサーバーを選択して、ネットワークトラフィックをローカルネットワークのセグメントに限定することができます。サーバーが複数のネットワークインタフェースを持つ場合は、それぞれのインタフェースが別々のサーバーであるとみなして、各ネットワークインタフェースに対応付けられているホスト名を指定します。autofs はそのクライアントにいちばん近いインタフェースを選択します。

注 –

手動によるマウントでは、重み付けと距離の確認は行われません。mount コマンドは、左から右へ一覧表示されるサーバーの優先順位を付けます。

詳細は、automount(1M) のマニュアルページを参照してください。

autofs と重み付け

距離のレベルが同じサーバーから 1 つを選択するために、autofs マップに重み付けの値を追加することができます。次に例を示します。


/usr/man -ro oak,rose(1),willow(2):/usr/man

括弧内の数値が重み付けを表します。重み付けのないサーバーの値はゼロであり、選択される可能性が最高になります。重み付けの値が大きいほど、そのサーバーが選択される可能性は低くなります。

注 –

重み付けは、サーバーの選択に関係する要素の中でもっとも小さい影響力しかありません。ネットワーク上の距離が同じサーバーの間で選択を行う場合に考慮されるだけです。

マップエントリ内の変数

変数名の前にドル記号 ($) を付けることによって、クライアント固有の変数を作成できます。この変数は、同じファイルシステムの位置にアクセスする異なるアーキテクチャータイプの調整に役立ちます。変数名を括弧でくくることで、その後に続く文字や数字と変数とを区切ることができます。表 6–2 に定義済みのマップ変数を示します。

表 6–2 定義済みのマップ変数

変数 

意味 

提供元 

例 

ARCH

アーキテクチャータイプ 

uname -m

sun4

CPU

プロセッサタイプ 

uname -p

sparc

HOST

ホスト名 

uname -n

dinky

OSNAME

オペレーティングシステム名 

uname -s

SunOS

OSREL

オペレーティングシステムのリリース 

uname -r

5.8

OSVERS

オペレーティングシステムのバージョン (リリースのバージョン) 

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 変数は、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 構造を作成しなければならない場合は、実行可能な 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 のネットワークナビゲート法の変更 (マップの変更)

マップへのエントリを変更、削除、または追加して、ユーザーの環境ニーズに合わせることができます。ユーザーが必要とするアプリケーションやその他のファイルシステムがその位置を変更すると、マップはこれらの変更を反映しなければなりません。autofs のマップは、いつでも変更できます。automountd が次にファイルシステムをマウントしたときにその変更内容が有効になるかどうかは、変更したマップと変更内容によって決まります。

ネームサービスに対する autofs のデフォルトの動作

ブート時に、autofs は、サービス svc:/system/filesystem/autofs によって起動され、マスターマップ auto_master を確認します。次に説明する規則が適用されます。

autofs は、/etc/nsswitch.conf ファイルの自動マウントエントリで指定されたネームサービスを使用します。ローカルファイルや NIS ではなく NIS+ が指定された場合、マップ名はすべてそのまま使用されます。NIS を選択し、autofs が必要なマップを検出できない場合で、1 つまたは複数の下線を含むマップ名を検出したときには、それらの下線がドットに変更されます。こうすることにより、NIS の古いファイル名を利用することができます。次に autofs はもう 1 度マップを調べます。この手順を図 6–6 に示します。

図 6–6 autofs によるネームサービスの使用

図については本文で説明します。

このセッションでは、画面は次の例のようになります。 


$ 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 とメタキャラクタ

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 のマップ構文解析機能を混乱させる名前のディレクトリをマウントする必要があるかもしれません。autofs の構文解析機能は、名前に含まれるコロン、コンマ、スペースなどを認識します。これらの名前は二重引用符で囲んでください。 


/vms    -ro    vmsserver: -  -  - "rc0:dk1 - "
/mac    -ro    gator:/ - "Mr Disk - "