第 31 章 リモートファイルシステムリファレンスへのアクセス

この章では、NFS コマンドの概要について説明します。また、NFS 環境のすべての構成要素とそれらが互いにどのように連携するかについても説明します。

• 「NFS ファイル」

• 「NFS デーモン」

• 「NFS コマンド」

• 「その他のコマンド」

• 「コマンドを組み合わせて使用する」

• 「autofs マップ」

• 「autofs のしくみ」

• 「autofs リファレンス」

NFS ファイル

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

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

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

/etc/default/nfslogd

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

CYCLE_FREQUENCY

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

IDLE_TIME

nfslogd が、バッファーファイル内にさらに情報があるかどうかを確認するまでに休眠しなければならない秒数を設定するパラメータです。このパラメータは、構成ファイルの確認頻度も決定します。このパラメータと MAN_PROCESSING_SIZE によりバッファーファイルの処理頻度が決まります。デフォルト値は 300 秒です。この数値を増加させると、確認の回数が減って性能が向上します。

MAPPING_UPDATE_INTERVAL

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

MAX_LOG_PRESERVE

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

MAN_PROCESSING_SIZE

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

PRUNE_TIMEOUT

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

UMASK

nfslogd が作成するログファイルに対するアクセス権を指定します。デフォルト値は 0137 です。

/etc/nfs/nfslog.conf

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

defaultdir=path

ログファイルのデフォルトのディレクトリパスを指定するパラメータです。

log=path/filename

ログファイルのパスとファイル名を指定するパラメータです。

fhtable=path/filename

ファイルハンドルパスデータベースのパスとファイル名を選択するパラメータです。

buffer=path/filename

バッファーファイルのパスとファイル名を決定するパラメータです。

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 と共有するファイルはすべて、次の値を使用します。デフォルトのディレクトリは /var/nfs になり、ログファイルは /var/nfs/logs/nfslog* に保存され、ファイルハンドルパスデータベーステーブルは /var/nfs/fh/fhtables に保存され、バッファーファイルは /var/nfs/buffers/workbuffer に保存されます。

NFS デーモン

NFS アクティビティをサポートするには、システムが実行レベル 3 かマルチユーザーモードで動作したときに、いくつかのデーモンを開始します。mountd と nfsd の 2 つのデーモンは、NFS サーバーであるシステム上で動作します。サーバーデーモンの自動起動は、NFS ファイルシステムのタイプでラベル付けされた項目が /etc/dfs/sharetab に存在するかどうかで変わります。

lockd と statd の 2 つのデーモンは NFS クライアントで動作し、NFS ファイルロッキングをサポートします。NFS サーバーでも動作させなければなりません。

automountd

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

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

-T は標準出力への各 RPC 呼び出しの表示を選択し、-n はすべての autofs ノードでのブラウズを無効にし、-v はコンソールへのすべての状態メッセージのレコードを選択し、-D name=value は、name により示された自動マウント変数を value に置き換えます。自動マウントマップのデフォルト値は /etc/auto_master です。障害追跡には -T オプションを使用してください。

lockd

このデーモンは NFS ファイルのレコードロックをサポートします。ロック要求をクライアントから NFS サーバーに送り、NFS サーバーでローカルのロックを開始します。通常は、パラメータを指定せずに起動します。使用できるオプションは 3 つあります (lockd(1M) のマニュアルページを参照してください)。

-g graceperiod オプションは、サーバーがリブートした場合に、その何秒後にロックを再要求するかを示します。NFS サーバーはこの秒数の間、それまでのロックの再要求処理しか実行しません。他のサービスに対する要求は、この時間が経過するまで待たされます。このオプションは NFS サーバーの応答性に関係するため、NFS サーバーでしか変更できません。デフォルト値は 45 秒です。この値を小さくすると、サーバーをリブートしてからオペレーションに復帰するまでの時間は短縮されますが、クライアントがすべてのロックを復旧できなくなる可能性が増します。

-t timeout オプションは、ロック要求をリモートサーバーに再送信するまで何秒待つかを示します。このオプションは NFS クライアントのサービスに関係します。デフォルト値は 15 秒です。この値を小さくすると、雑音の多いネットワーク上の NFS クライアントに対する応答時間を改善できますが、ロック要求が増えることによってサーバーの負荷が増す可能性があります。

nthreads オプションは、サーバーが 1 つの接続について同時に処理できるスレッドの数の上限を示します。この値は、NFS サーバーに対して予想される負荷に基づいて決定してください。デフォルト値は 20 です。TCP を使用する NFS クライアントはそれぞれ NFS サーバーと 1 つの接続を設定するため、各 TCP クライアントはサーバー上で同時に 20 までのスレッドを使用することが許されます。UDP (ユーザーデーモンプロトコル) を使用する NFS クライアントは、すべてが NFS サーバーと 1 つの接続を共有します。その場合、UDP 接続が使用できるスレッドの数を増やさなければならないことがあるかもしれません。簡単な目安は 1 つの UDP クライアントにつき 2 つのスレッドですが、クライアントに対する作業負荷によってはこれで不十分なこともあります。使用するスレッドを増やすことによるマイナスは、スレッドの使用によって NFS サーバーで使用されるメモリーが増えることです。しかしスレッドが使用されないならば、nthreads を大きくしても影響はありません。

mountd

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

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

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

nfsd

これは、他のクライアントからのファイルシステム要求を処理するデーモンです。このコマンドに対してはいくつかのオプションが指定できます。オプションをすべて確認するには nfsd(1M) のマニュアルページを参照してください。

-l オプションは、接続指向トランスポートでの NFS/TCP に対する接続キューの長さを設定します。デフォルト値は 25 エントリです。

-c #_conn オプションは、接続指向トランスポート 1 つあたりの接続数の上限を選択します。デフォルト値はありません。

nservers オプションは、1 台のサーバーが同時に処理可能な要求の数の上限です。デフォルト値は 1 ですが、起動スクリプトでは 16 が選択されます。

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

nfslogd

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

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

statd

lockd とともに動作し、ロック管理機能にクラッシュ機能と回復機能を提供します。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 root          11 Apr 29 16:32 ipv4.192.9.200.1 -> myhost
--w-------   1 root          11 Apr 29 16:32 myhost

この例では、クライアントのホスト名は myhost で、IP アドレスは 192.9.200.1 です。他のホストが myhost という名前を持ち、ファイルシステムをマウントしていると、myhost というホスト名に対するシンボリックリンクは 2 つ作成されます。

NFS コマンド

次のコマンドは、root 権限で実行しなければ、十分な効果がでません。しかし情報の要求は、すべてのユーザーが行えます。

• 「automount」

• 「clear_locks」

• 「mount」

• 「mountall」

• 「setmnt」

• 「share」

• 「shareall」

• 「showmount」

• 「umount」

• 「umountall」

• 「unshare」

• 「unshareall」

automount

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

automount [ -t duration ] [ -v ]

-t duration はファイルシステムがマウントされた状態でいる時間 (秒) で、-v は詳細形式モードを選択します。詳細形式モードでこのコマンドを実行すると障害追跡が容易になります。

継続時間の値は、特に設定しないと 5 分に設定されます。ほとんどの場合この時間は適切な値ですが、自動マウントされたファイルシステムを多く持つシステムではこの時間を長くする必要がある場合があります。特に、サーバーを多くのユーザーが使用中の場合は、自動マウントされたファイルシステムを 5 分ごとにチェックするのは能率的でない場合があります。autofs ファイルシステムは 1800 秒 (30 分) ごとにチェックする方が適しています。このファイルシステムを 5 分ごとにアンマウントしないことで、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

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

mount

このコマンドを使用すると、指定したファイルシステムをローカルかリモートで、指定したマウントポイントに添付できます。詳細は、mount(1M) のマニュアルページを参照してください。引数を指定しないと、現在ユーザーのコンピュータにマウントされているファイルシステムのリストが表示されます。

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 フラグの後に指定できるオプションの一部を以下に示します。

bg|fg

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

forcedirectio

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

largefiles

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

nolargefiles

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

public

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

rw|ro

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

sec=mode

このオプションは、マウント時に使用される認証機構を指定します。mode の値は、表 31-2 に示したもののいずれかでなければなりません。モードは、 /etc/nfssec.conf ファイルにも定義されます。

表 31-2 NFS セキュリティモード

モード	選択される認証サービス
krb5	Kerberos バージョン 5
none	認証なし
dh	Diffie-Hellman (DH) 認証
sys	UNIX の標準認証

soft|hard

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

mount コマンドの使用

次のコマンドのどちらも、bee サーバーから NFS ファイルシステムを読み取り専用としてマウントします。

# mount -F nfs -r bee:/export/share/man /usr/man

# mount -F nfs -o ro bee:/export/share/man /usr/man

このコマンドでは -O オプションによって、/usr/man がすでにマウントされていても bee サーバーのマニュアルページがローカルシステムにマウントされます。

# mount -F nfs -O bee:/export/share/man /usr/man

このコマンドでは、クライアント側フェイルオーバー機能が使用されています。

# mount -F nfs -r bee,wasp:/export/share/man /usr/man

コマンド行から使用する場合、リスト内のサーバーがサポートしている NFS プロトコルは同じバージョンでなければなりません。コマンド行から mount を実行するときは、バージョン 2 とバージョン 3 のサーバーを混在させないでください。autofs では混在が可能なので、バージョン 2 サーバーとバージョン 3 サーバーの最適な組み合わせを使用できます。

mount コマンドで NFS URL を使用する例を示します。

# mount -F nfs nfs://bee//export/share/man /usr/man

mount コマンドに引数を指定しないと、クライアントにマウントされたファイルシステムが表示されます。

% mount
/ on /dev/dsk/c0t3d0s0 read/write/setuid on Tues Jan 24 13:20:47 1995
/usr on /dev/dsk/c0t3d0s6 read/write/setuid on Tues Jan 24 13:20:47 1995
/proc on /proc read/write/setuid on Tues Jan 24 13:20:47 1995
/dev/fd on fd read/write/setuid on Tues Jan 24 13:20:47 1995
/tmp on swap read/write on Tues Jan 24 13:20:51 1995
/opt on /dev/dsk/c0t3d0s5 setuid/read/write on Tues Jan 24 13:20:51 1995
/home/kathys on bee:/export/home/bee7/kathys              
  intr/noquota/nosuid/remote on Tues Jan 24 13:22:13 1995

umount

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

ファイルシステムがすでにマウントされていて、/etc/mnttab に項目が指定されている場合、ファイルシステムのタイプのフラグを指定する必要はありません。

ファイルシステムが使用中だと、このコマンドは実行できません。たとえば、あるユーザーが cd コマンドによってファイルシステムにアクセスしていると、作業ディレクトリが他に変更されるまでそのファイルシステムは使用中となります。umount コマンドは、NFS サーバーに接続できないと一時的にハングすることがあります。

umount コマンドの使用

次の例では、/usr/man にマウントしたファイルシステムのマウントが解除されます。

# umount /usr/man

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

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

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

mountall

このコマンドを使用すると、ファイルシステムテーブルに指定したすべてのファイルシステム、または特定グループのファイルシステムをマウントできます。アクセスするファイルシステムタイプを選択するための -F FSType オプション、ファイルシステムテーブル内のリモートファイルシステムをすべて選択する -r オプション、ローカルファイルシステムをすべて選択する -l オプションがあります。 NFS ファイルシステムタイプと指定されているファイルシステムはすべてリモートファイルシステムなので、これらのオプションは余分な指定になることがあります。詳細は、mountall(1M) のマニュアルページを参照してください。

mountall コマンドの使用

次の 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 コマンドの使用

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

# umountall -r

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

# umountall -h bee

share

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

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

すでに共有している大きいファイルシステムの一部であるファイルシステムを共有することはできません。たとえば /usr と /usr/local が同じディスクスライスにある場合、/usr も /usr/local も共有することができますが、両方を別々の共有オプションで共有する場合、/usr/local は別のディスクスライスに移動しなければなりません。

2 つのファイルシステムが同じディスクスライスにある場合、読み取り専用で共有しているファイルシステムに、読み取りと書き込みが可能な状態で共有しているファイルシステムのファイルハンドルでアクセスすることができます。読み取りと書き込みの両方を行うファイルシステムは、読み取り専用で共有する必要があるファイルシステムとは別のパーティションかディスクスライスに保存するほうが安全です。

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

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

rw|ro

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

rw=accesslist

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

NFS 用 share オプション

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

aclok

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

---

注 -

ACL を活用するためには、クライアントでもサーバーでも NFS バージョン 3 と NFS_ACL プロトコルをサポートしているソフトウェアを実行します。NFS バージョン 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= option は十分慎重に使用してください。

---

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 は、そのホスト名が eng ネットグループのリストに含まれていれば、DH 認証を使用していなくても読み取り専用でマウントすることは可能です。

# share -F nfs -o sec=dh,rw=tulip:lilac,sec=sys,ro=eng /usr/src

UNIX 認証はデフォルトのセキュリティモードですが、-sec を指定するとデフォルトは無効になります。他の認証機構とともに UNIX 認証も使用する場合には、必ず -sec=sys オプションを指定してください。

実際のドメイン名の名前にドットを付けると、アクセスリストの中で DNS ドメイン名が使えます。ドットは、その後の文字列が完全に修飾されたホスト名ではなくドメイン名であることを表します。次のエントリは、マウントから eng.sun.com ドメイン内のすべてのホストへのアクセスを許可するためのものです。

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

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

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

# share -F nfs -o ro=@eng /export/share/man
# share -F nfs -o ro=@129.144 /export/share/man
# share -F nfs -o ro=@129.144.0.0 /export/share/man

2 番目と 3 番目のエントリは、ネットワークアドレス全体を指定する必要がないことを表しています。

ネットワークアドレスの先頭部分がバイトによる区切りでなく、CIDR (Classless Inter-Domain Routing) のようになっている場合には、マスクの長さをコマンド行で具体的に指定できます。この長さは、ネットワーク名かネットワーク番号の後ろにスラッシュで区切ってアドレスの接頭辞に有効ビット数として指定します。たとえば、次のようにします。

# share -f nfs -o ro=@eng/17 /export/share/man
# share -F nfs -o ro=@129.144.132/17 /export/share/man

この例で、"/17" はアドレスの先頭から 17 ビットがマスクとして使用されることを表します。CIDR について詳細は、RFC 1519 を参照してください。

また、エントリの前に "-" を指定することでアクセスの拒否を示すこともできます。エントリは左から右に読み込まれるため、アクセス拒否のエントリはそのエントリを適用するエントリの前に置く必要があることに注意してください。

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

この例では、eng.sun.com ドメイン内のホストのうち、rose を除いたすべてに対してアクセス権が許可されます。

unshare

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

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

unshare コマンドの使用

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

# unshare /usr/src

shareall

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

shareall コマンドの使用

次のコマンドでは、ローカルファイルに羅列されているすべてのファイルシステムが共有されます。

# shareall /etc/dfs/special_dfstab

unshareall

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

unshareall コマンドの使用

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

# unshareall -F nfs

showmount

このコマンドを使用すると、NFS サーバーから共有したファイルシステムをリモートにマウントしたすべてのクライアントや、クライアントがマウントしたファイルシステム、または共有しているファイルシステムとクライアントのアクセス情報が表示されます。構文は以下のとおりです。

showmount [ -ade ] [ hostname ]

-a を指定すると、すべてのリモートマウント (クライアント名とディレクトリ) のリストが表示されます。-d を指定すると、クライアントがリモートにマウントしたディレクトリのリストが表示されます。-e では、共有 (またはエクスポート) しているファイルのリストが表示されます。hostname には、表示する情報が保存されている NFS サーバーを指定します。hostname を指定しないと、ローカルホストを入力するように要求されます。

showmount コマンドの使用

次のコマンドでは、すべてのクライアント、およびマウントしたディレクトリが表示されます。

# 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 の障害追跡には以下のコマンドを使用します。

nfsstat

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

nfsstat [  -cmnrsz ]

-c を指定すると、クライアント側の情報が表示され、-m を指定すると、NFS マウントされた各ファイルシステムの統計が表示されます。-n では、クライアントとサーバーの両方の NFS 情報が表示され、-r では、RPC の統計が表示されます。-s を指定すると、サーバー側の情報が表示され、-z を指定すると、統計がゼロに設定されます。コマンド行にオプションを指定しないと、-cnrs が使用されます。

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

nfsstat コマンドの使用

# nfsstat -s

Server rpc:
Connection oriented:
calls      badcalls   nullrecv   badlen      xdrcall    dupchecks  dupreqs
11420263   0          0          0           0          1428274    19
Connectionless:
calls      badcalls   nullrecv   badlen      xdrcall    dupchecks  dupreqs
14569706   0          0          0           0          953332     1601

Server nfs:
calls      badcalls
24234967   226
Version 2: (13073528 calls)
null       getattr    setattr    root        lookup     readlink   read
138612 1%  1192059 9% 45676 0%   0 0%        9300029 71% 9872 0%   1319897 10%
wrcache    write      create     remove      rename     link       symlink
0 0%       805444 6%  43417 0%   44951 0%    3831 0%    4758 0%    1490 0%
mkdir      rmdir      readdir    statfs
2235 0%    1518 0%    51897 0%   107842 0%
Version 3: (11114810 calls)
null       getattr    setattr    lookup      access     readlink   read
141059 1%  3911728 35% 181185 1% 3395029 30% 1097018 9% 4777 0%   960503 8%
write      create     mkdir      symlink     mknod      remove     rmdir
763996 6%  159257 1%  3997 0%    10532 0%    26 0%      164698 1%  2251 0%
rename     link       readdir    readdirplus fsstat     fsinfo     pathconf
53303 0%   9500 0%    62022 0%   79512 0%    3442 0%    34275 0%   3023 0%
commit    
73677 0%  

Server nfs_acl:
Version 2: (1579 calls)
null       getacl     setacl     getattr     access    
0 0%       3 0%       0 0%       1000 63%    576 36%   
Version 3: (45318 calls)
null       getacl     setacl    
0 0%       45318 100% 0 0%

上記は、NFS サーバーの統計です。最初の 5 行は RPC に関するもので、残りの部分は NFS のアクティビティのレポートです。どちらの統計でも総コール数に対する badcalls の数や 1 週間あたりの calls 数がわかるので、障害が発生した時点を突き止めのに役立ちます。badcallsの値は、クライアントからの不良メッセージの数を表すもので、ネットワーク上のハードウェアにおける問題を突き止められます。

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

pstack

このコマンドを使用すると、各プロセスにおけるスタックトレースが表示されます。root で実行しなければなりません。プロセスがハングした場所を判断するのに使用します。使用できるオプションは、チェックするプロセスの PID だけです (proc(1) のマニュアルページを参照)。

以下の例では、実行中の nfsd プロセスをチェックしています。

# /usr/proc/bin/pstack 243
243:    /usr/lib/nfs/nfsd -a 16
 ef675c04 poll     (24d50, 2, ffffffff)
 000115dc ???????? (24000, 132c4, 276d8, 1329c, 276d8, 0)
 00011390 main     (3, efffff14, 0, 0, ffffffff, 400) + 3c8
 00010fb0 _start   (0, 0, 0, 0, 0, 0) + 5c

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

rpcinfo

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

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

-m は rpcbind 操作の統計テーブル、-s は登録済みの RPC プログラムすべての簡易リスト、-t は TCP を使用する RPC プログラム、-u は UDP を使用する RPC プログラムを表示します。hostname は情報を取得する元のサーバー、progname は情報を収集する対象の RPC プログラムです。hostname を指定しないと、ローカルホスト名が使用されます。progname の代わりに RPC プログラム番号が使えますが、ユーザーが覚えやすいのは番号よりも名前です。NFS バージョン 3 が実行されていないシステムでは、-s オプションの代わりに -p オプションが使えます。

このコマンドで生成されるデータには、以下のものがあります。

• RPC プログラム番号

• 特定プログラムのバージョン番号

• 使用されているトランスポートプロトコル

• RPC サービス名

• RPC サービスの所有者

rpcinfo コマンドの使用

次の例では、サーバーで実行している RPC サービスに関する情報を収集しています。生成されたテキストには sort コマンドのフィルタをかけ、より読みやすくしています。この例では、RPC サービスの数行を省略しています。

% rpcinfo -s bee |sort -n
   program version(s) netid(s)                         service     owner
    100000  2,3,4     udp,tcp,ticlts,ticotsord,ticots  portmapper  superuser
    100001  4,3,2     ticlts,udp                       rstatd      superuser
    100002  3,2       ticots,ticotsord,tcp,ticlts,udp  rusersd     superuser
    100003  3,2       tcp,udp                          nfs         superuser
    100005  3,2,1     ticots,ticotsord,tcp,ticlts,udp  mountd      superuser
    100008  1         ticlts,udp                       walld       superuser
    100011  1         ticlts,udp                       rquotad     superuser
    100012  1         ticlts,udp                       sprayd      superuser
    100021  4,3,2,1   ticots,ticotsord,ticlts,tcp,udp  nlockmgr    superuser
    100024  1         ticots,ticotsord,ticlts,tcp,udp  status      superuser
    100026  1         ticots,ticotsord,ticlts,tcp,udp  bootparam   superuser
    100029  2,1       ticots,ticotsord,ticlts          keyserv     superuser
    100068  4,3,2     tcp,udp                          cmsd        superuser
    100078  4         ticots,ticotsord,ticlts          kerbd       superuser
    100083  1         tcp,udp                          -           superuser
    100087  11        udp                              adm_agent   superuser
    100088  1         udp,tcp                          -           superuser
    100089  1         tcp                              -           superuser
    100099  1         ticots,ticotsord,ticlts          pld         superuser
    100101  10        tcp,udp                          event       superuser
    100104  10        udp                              sync        superuser
    100105  10        udp                              diskinfo    superuser
    100107  10        udp                              hostperf    superuser
    100109  10        udp                              activity    superuser
	.
	.
    100227  3,2       tcp,udp                          -           superuser
    100301  1         ticlts                           niscachemgr superuser
    390100  3         udp                              -           superuser
1342177279  1,2       tcp                              -           14072

次の例では、サーバーの特定トランスポートを使用している RPC サービスの情報を収集する方法について説明しています。

% rpcinfo -t bee mountd
program 100005 version 1 ready and waiting
program 100005 version 2 ready and waiting
program 100005 version 3 ready and waiting
% rpcinfo -u bee nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting

最初の例では、TCP で実行している mountd サービスをチェックしています。2 番目の例では、UDP で実行している NFS サービスをチェックしています。

snoop

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

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

-d device には、ローカルネットワークインタフェースを指定します。-o filename には、取り込んだすべてのパケットを保存するファイルを指定します。hostname には、表示するパケットが通過したホストを指定します。

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

障害追跡をする場合は、パケットの発信元と送信先のホストが正しいことを確認してください。また、エラーメッセージも調べてください。パケットをファイルに保存すると、データの検査が容易になります。

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 における障害追跡の手順」 を参照してください。

コマンドを組み合わせて使用する

以下の節では、NFS の複雑な機能をいくつか紹介します。

バージョン 2 とバージョン 3 のネゴシエーション

NFS サーバーがサポートしているクライアントが NFS バージョン 3 を使用していない場合に備えて、開始手順にはプロトコルレベルのネゴシエーションが含まれています。クライアントとサーバーの両方がバージョン 3 をサポートしていると、バージョン 3 が使用されます。どちらか片方でもバージョン 2 しかサポートしていないと、バージョン 2 が使用されます。

ネゴシエーションによって決まった値は、mount コマンドに対して -vers オプションを使用することで変更できます (mount_nfs(1M) のマニュアルページを参照してください)。ほとんどの場合、デフォルトによって最適なバージョンが選択されるため、ユーザーが指定する必要はありません。

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

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

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

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

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

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

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

ファイルシステムのマウントの詳細

クライアントがサーバーからファイルシステムをマウントするとき、そのファイルシステムに対応するファイルハンドルをサーバーから取得する必要があります。そのためには、クライアントとサーバーの間でいくつかのトランザクションが発生します。この例では、クライアントはサーバーから /home/terry をマウントします。snoop によって追跡したトランザクションは、次のとおりです。

client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP
server -> client PORTMAP R GETPORT port=33492
client -> server MOUNT3 C Null
server -> client MOUNT3 R Null 
client -> server MOUNT3 C Mount /export/home9/terry
server -> client MOUNT3 R Mount OK FH=9000 Auth=unix
client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP
server -> client PORTMAP R GETPORT port=2049
client -> server NFS C NULL3
server -> client NFS R NULL3 
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

この追跡結果では、クライアントがまずマウントポート番号を NFS サーバーの portmap サービスに要求します。クライアントが取得したマウントポート番号 (33492) は、サーバーに対する存在確認のために使用されます。このポート番号でサービスが実行中であることが確認できると、クライアントはマウントを要求します。この要求により、サーバーはマウントされるファイルシステムに対するファイルハンドル (9000) を送ります。これに対してクライアントは、NFS ポート番号を要求します。クライアントはサーバーからポート番号を受け取り、NFS サービス (nfsd) を ping してから、ファイルハンドルを使用してファイルシステムに関する NFS 情報を要求します。

次の追跡結果では、クライアントは -public オプションを使用してファイルシステムをマウントしています。

client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry
server -> client NFS R LOOKUP3 OK FH=9000
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

デフォルトの公共ファイルハンドル (0000) を使用しているために、すべてのトランザクションにポートマップサービスから情報が与えられ、NFS ポート番号を決定するためのトランザクションはありません。

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

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

public オプションと NFS URL - 公共ファイルハンドルが使用されます。公共ファイルハンドルがサポートされていないと、マウントは失敗します。




public オプションと通常のパス - 公共ファイルハンドルが使用されます。公共ファイルハンドルがサポートされていないと、マウントは失敗します。




NFS URL のみ - NFS サーバーでサポートされていれば、公共ファイルハンドルを使用します。公共ファイルハンドルを使用するとマウントが失敗する場合は、MOUNT プロトコルを使用してマウントします。




通常のパスのみ - 公共ファイルハンドルは使用しないでください。MOUNT プロトコルが使用されます。

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

クライアント側のフェイルオーバー (障害時回避) 機能を使用すると、複製されたファイルシステムをサポートしているサーバーが使用不能になったときに、NFS クライアントは別のサーバーに切り替えることができます。ファイルシステムが使用不能になる原因としては、接続しているサーバーのクラッシュ、サーバーの過負荷、ネットワーク障害が考えられます。通常、このような場合のフェイルオーバー機能はユーザーにはわかりません。設定が行われていれば、フェイルオーバー機能はクライアント上のプロセスを中断することなく実行されます。

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

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

各ファイルシステムについて用意すべき複製の数を決める要素はさまざまです。一般的に、サーバーを何台か用意してそれぞれが複数のサブネットをサポートするという環境の方が、サブネット 1 つについて 1 台のサーバーを用意するよりもすぐれています。この場合、リストにあるサーバーを 1 台ずつチェックする必要があるため、リスト上のサーバーが増えるにつれてマウントにかかる時間も増えます。

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

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

• フェイルオーバー機能 - 複製されたファイルシステムに対応するサーバーのリストから、サーバーを選択すること。通常、ソートされたリストの順番を元に、次のサーバーが応答するならばそのサーバーが使用されます。

• 再マッピング - 新しいサーバーを使用すること。クライアントは、正常な状態のときにリモートファイルシステム上のアクティブなファイルそれぞれのパス名を格納します。再マッピング時には、そのパス名に基づいて新しいサーバー上のファイルを見つけます。

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

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

複製されたファイルシステムを保守するには、rdist や cpio などのファイル転送機構を使います。複製されたファイルシステムを更新すると不整合が発生するので、できるだけ以下を守ってください。

• 新しいバージョンのファイルをインストールするときは、あらかじめ古い方の名前を変更する

• クライアントによる使用が少ない夜間に更新を実行する

• 更新は小規模にとどめる

• コピーの数を最小限にする

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

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

大型ファイル

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

サーバーのファイルシステムが -largefiles オプション付きでマウントされていれば、Solaris 2.6 の NFS クライアントでは何も変更しなくても大型ファイルにアクセスできます。しかし、Solaris 2.6 のコマンドすべてで大型ファイルが扱えるわけではありません。大型ファイルを処理可能なコマンドのリストは、largefile(5) を参照してください。大型ファイル用機能拡張を備えた NFS バージョン 3 プロトコルをサポートしていないクライアントは、大型ファイルには一切アクセスできません。Solaris 2.5 クライアントでは、NFS バージョン 3 プロトコルを使用することはできますが、大型ファイルを扱う機能は含まれていません。

NFS サーバーログ機能の働き

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

ログ機能が有効になっているファイルシステムにアクセスすると、カーネルが raw データをバッファーファイルに書き込みます。このデータには、時刻表示、クライアント IP アドレス、要求者の UID、アクセスされているファイルまたはディレクトリオブジェクトのファイルハンドル、および発生している操作のタイプがあります。

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

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

WebNFS セキュリティネゴシエーション機能の働き方

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

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

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

要求が正常に受け入れられたら、WebNFS クライアントは、配列からの 1 番目のセキュリティメカニズムを選択します。クライアントはこの配列をサポートしていて、ファイルハンドルを取得するために選択されたセキュリティメカニズムを使用して通常のマルチコンポーネントルックアップ要求を発行します。このあとに続くすべての NFS 要求は、選択されたセキュリティメカニズムとファイルハンドルを使用して出されます。

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

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

• NFS によるブラウズでは CGI スクリプトは実行されません。したがって、CGI スクリプトを多用している Web サイトを含むファイルシステムは、NFS によるブラウズに適していない可能性があります。

• ブラウザからは、形式の異なるファイルを扱うために別のビューアを起動されることがあります。NFS URL からそうしたファイルにアクセスすると、ファイル名からファイルタイプが判別できるならば外部のビューアが起動されます。ブラウザは、NFS URL が使用されている場合、標準の MIME タイプで決まっているファイル名拡張子をすべて認識します。WebNFS は一部の Web ブラウザとは異なり、ファイルタイプを決定するときにファイルの内部は調べません。ファイル名拡張子だけで判断します。

• NFS によるブラウズでは、サーバー側のイメージマップ (クリッカブルイメージ) は使えません。しかしクライアント側のイメージマップ (クリッカブルイメージ) は、位置とともに URL が定義されているため使えます。文書サーバーからの応答は不要です。

Secure NFS システム

NFS 環境は、アーキテクチャやオペレーティングシステムの異なるコンピュータから構成されるネットワーク上でファイルシステムを共有するためには、強力で使いやすい手段です。しかし、NFS の操作によるファイルシステムの共有を便利にする機能が、一方ではセキュリティ上の問題につながっています。今まで、NFS はほとんどのバージョンで UNIX (AUTH_SYS) 認証を使用してきましたが、現在では AUTH_DH のようなより強力な認証方式も使用可能です。UNIX 認証の場合、NFS サーバーはファイル要求を認証するために、その要求を行なったユーザーではなくコンピュータを認証します。したがって、クライアント側のユーザーがスーパーユーザーでログインすると、ファイルの所有者になりすますことができます。DH 認証では、NFS サーバーはユーザーを認証するため、このような操作が困難になります。

ルートへのアクセス権とネットワークプログラミングについての知識があれば、だれでも任意のデータをネットワークに入れ、ネットワークから任意のデータを取り出すことができます。ネットワークに対する最も危険な攻撃は、有効なパケットを生成したり、または「対話」対話を記録し後で再生することによってユーザーを装うなどの手段により、データをネットワークに持ち込むことです。これらはデータの整合性に影響を与えます。許可を持つユーザーを装うことなく、単にネットワークトラフィックを受信するだけの受動的な盗み聞きならば、データの整合性が損なわれることはないため、それほど危険ではありません。ユーザーはネットワークに送信されるデータを暗号化することによって、機密情報のプライバシを守ることができます。

ネットワークのセキュリティ問題における共通の対処方法は、解決策を各アプリケーションにゆだねることです。さらに優れた手法としては、すべてのアプリケーションを対象として、標準の認証システムを導入することです。

Solaris オペレーティングシステムには、NFS が実装されるメカニズムであるリモート手続き呼び出し (RPC) のレベルで、認証システムが組み込まれています。このシステムは Secure RPC と呼ばれ、ネットワーク環境のセキュリティを大幅に向上させるとともに、NFS のセキュリティを強化します。Secure RPC の機能を利用した NFS システムを Secure NFS システムと呼びます。

Secure RPC

Secure RPC は Secure NFS システムの基本となるメカニズムです。Secure RPC の目標は、少なくともタイムシェアリングシステム (すべてのユーザーが 1 台のコンピュータを共有するシステム) 程度に安全なシステムを構築することです。タイムシェアリングシステムはログインパスワードによりユーザーを認証します。DES (Data Encryption Service) 認証でもこれは同じです。ユーザーは、ローカル端末の場合と同じように、任意のリモートコンピュータにログインできます。ユーザーのログインパスワードは、ネットワークセキュリティへのパスポートです。タイムシェアリングでは、システム管理者は信頼のおける人で、パスワードを変更して誰かを装うようなことはしないという道徳上の義務を負います。Secure RPC では、ネットワーク管理者は「公開鍵」を格納するデータベースのエントリを変更しないという前提で信頼されています。

RPC 認証システムを理解するには、「資格 (credential)」と「ベリファイア」という 2 つの用語を理解する必要があります。ID バッジを例にとれば、資格とは、名前、住所、誕生日など人間を識別するものです。ベリファイアとはバッジに添付された写真であり、バッジの写真をその所持者と照合することによって、そのバッジが盗まれたものではないことを確認できます。RPC では、クライアントプロセスは RPC 要求のたびに資格とベリファイアの両方をサーバーに送信します。クライアントはサーバーの資格をすでに知っているため、サーバーはベリファイアだけを送り返します。

RPC の認証機能は拡張が可能で、さまざまな認証システムを組み込むことができます。現在のところ、このようなシステムには UNIX と DH の 2 つがあります。

ネットワークサービスで UNIX 認証を使用する場合、資格にはクライアントのコンピュータ名、UID、GID、グループアクセスリストが含まれ、ベリファイアには何も含まれません。ベリファイアが存在しないため、ルートユーザーは su などのコマンドを使用して、適切な資格を偽ることができます。UNIX 認証でのもう 1 つの問題は、ネットワーク上のすべてのコンピュータを UNIX コンピュータと想定していることです。UNIX 認証を異機種ネットワーク内の他のオペレーティングシステムに適用した場合、これは正常に動作しません。

UNIX 認証の欠点を補うために、Secure RPC では DH 認証を使います。

DH 認証

DH 認証は、Data Encryption Standard (DES) と Diffie-Hellman 公開鍵暗号手法を使用してネットワーク上のユーザーとコンピュータの両方を認証します。DES は標準暗号化機能であり、Diffie-Hellman 公開鍵暗号手法は、公開鍵と非公開鍵という 2 つの鍵を使用する暗号方式です。公開鍵と非公開鍵は名前空間に格納されます。NIS の場合、それらの鍵を publickey マップに格納し、NIS+ は cred テーブルに格納します。これらのマップにはすべての認証の候補ユーザーの公開鍵と非公開鍵が入っています。マップとテーブルの設定については、『Solaris ネーミングの管理』を参照してください。

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

• 2 つのエージェントの現在時刻が一致している。

• 送信側と受信側が同じ暗号化鍵を使用する。

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

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

KERB 認証

Kerberos は MIT で開発された認証方式です。Kerberos での暗号化は DES に基づいています。Kerberos サポートは、現在では Secure RPC の一部としては供給されていませんが、Solaris 8 リリースにはクライアント側の実装が含まれています。

NFS での Secure RPC の使用

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

• サーバーがクラッシュしたとき周囲に誰もいない場合 (停電の後など) には、システムに格納されていた秘密鍵はすべて消去されます。そのためどのプロセスからも、セキュリティ保護されたネットワークサービスにアクセスしたり NFS ファイルシステムをマウントしたりできません。リブートの際に重要なプロセスは、通常は root として実行されます。したがって、root の秘密鍵を別に保存してあればこれらのプロセスを実行できますが、周囲に誰もいない状況では秘密鍵を復号化するパスワードを入力するユーザーがいません。keylogin -r を使用すると root の秘密鍵がそのまま /etc/.rootkey に格納され、keyserv がそれを読み取ります。

• システムによっては、シングルユーザーモードでブートし、コンソールには root のログインシェルが表示されてパスワードの入力が要求されないことがあります。このような場合には、物理的なセキュリティが不可欠です。

• ディスクレスコンピュータのブートは、完全に安全とはいえません。ブートサーバーになりすましてリモートコンピュータに対する秘密鍵の入力を記録するような、不正なカーネルを誰かがブートすることが考えられます。Secure NFS システムによって保護されているのはカーネルとキーサーバーが起動した後だけです。それまでの間に、ブートサーバーからの応答を認証する手段はありません。これは重大な問題につながる可能性がありますが、この部分を攻撃するにはカーネルのソースコードを使用した高度な技術が必要です。また、不法行為の痕跡が残ります。すなわち、ネットワークを通じてブートサーバーにポーリングすれば、不正なブートサーバーの位置が分かります。

• ほとんどの setuid プログラムは root が所有者です。root の秘密鍵が /etc/.rootkey に格納されていれば、これらのプログラムは正常に動作します。しかし、ユーザーが所有者である setuid プログラムは動作しない可能性があります。たとえば、ある setuid プログラムの所有者が dave であり、ブート以降 dave が 1 度もログインしていないと、このプログラムはセキュリティ保護されたネットワークサービスにはアクセスできません。

• リモートコンピュータに (login、rlogin、または telnet を使用して) ログインし、keylogin を使用してアクセスすると、自分のアカウントへのアクセスを許したことになります。これは、秘密鍵が相手側のコンピュータのキーサーバーに渡され、キーサーバーがその秘密鍵を格納したためです。これが問題になるのは、相手側のリモートコンピュータを信用できない場合だけです。しかし、疑いがある場合にはパスワードを要求するリモートコンピュータにはログインしないでください。代わりに NFS 環境を使用して、そのリモートコンピュータから共有されているファイルシステムをマウントします。または、keylogout を使用してキーサーバーから秘密鍵を消去します。

• ホームディレクトリが共有されていて -o sec=dh オプションが指定されていると、リモートログインによって問題が生じる可能性があります。/etc/hosts.equiv ファイルか /.rhosts ファイルでパスワードを要求しないように設定すると、ユーザーはログインできますが、ローカルで認証が行われていないために自分のホームディレクトリにアクセスできません。パスワードを要求され、入力したパスワードがネットワークパスワードと一致すれば自分のホームディレクトリにアクセスできます。

autofs マップ

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

• マスターマップ

• 直接マップ

• 間接マップ

autofs マスターマップ

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

例 31-1 /etc/auto_master ファイルの例

# Master map for automounter 
# 
+auto_master 
/net            -hosts           -nosuid,nobrowse 
/home           auto_home        -nobrowse 
/xfn            -xfn
/-              auto_direct     -ro

この例では、汎用の auto_master ファイルに auto_direct マップのための追加が行われています。マスターマップ /etc/auto_master の各行は、次の構文に従っています。

mount-point map-name [ mount-options ]

# で始まる行はコメント行です。この場合、その行の最後まですべて無視されます。

長い行を短い行に分割するには、行末にバックスラッシュ (¥) を入力します。入力できる文字数の上限は 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 データベースだけを使用する組み込みマップです。たとえば、コンピュータ gumbo が hosts データベース内にあり、しかもそのファイルシステムのどれかをエクスポートする場合、次のコマンドによって、カレントディレクトリがコンピュータ gumbo のルートディレクトリに変更されます。

%cd /net/gumbo

なお、autofs はホスト gumbo のエクスポートされたファイルシステムだけをマウントできます。つまり、ローカルディスク上のファイルシステムではなく、ネットワークユーザーが使用できるサーバー上のファイルシステムです。したがって、 gumbo にあるすべてのファイルとディレクトリは、/net/gumbo では利用できない場合があります。

/net を使用したアクセスでは、サーバー名はパスの中に指定されるため、位置に依存します。したがって、エクスポートされるファイルシステムを別のサーバーに移動すると、そのパスは使えなくなります。このような場合は /net を使用せずに、そのファイルシステムに対応するエントリをマップの中に設定します。

autofs はマウント時だけサーバーのエクスポートリストを調べます。サーバーのファイルシステムが一度マウントされると、そのファイルシステムがアンマウントされ、次にマウントされるまで autofs はそのサーバーをチェックしません。したがって、新たにエクスポートされたファイルシステムは、それがサーバーからアンマウントされ、再度マウントされるまでは見えません。

マウントポイント /xfn

このマウントポイントは、FNS 名前空間を使用して共有されるリソースの autofs ディレクトリ構造がマウントされます (FNS については、『Solaris ネーミングの設定と構成』を参照してください)。

直接マップ

直接マップは自動マウントポイントです。つまり、直接マップによって、クライアント上のマウントポイントとサーバー上のディレクトリが直接対応付けられます。直接マップには完全なパス名があり、明示的に関係を示します。次に一般的な /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

マスターマップと同様、# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。長い行を短い行に分割するには、行の最後にバックスラッシュを入力します。

すべてのマップの中で、直接マップのエントリが、/etc/vfstab (vfstab にはマウントされるすべてのファイルシステムのリストが含まれる) の対応するエントリと最もよく似ています。/etc/vfstab のエントリは次のとおりです。

dancer:/usr/local - /usr/local/tmp nfs - yes ro 

直接マップでは次のようになります。

/usr/local/tmp     -ro     dancer:/usr/local 

オートマウンタマップの間では、オプションの連結はされません。あるオートマウンタマップでオプションが追加されると、それまでに見つかったマップに指定されているオプションはすべて無視され、新しいオプションだけが使用されます。たとえば、auto_master マップに指定されているオプションは、他のマップの中の対応するエントリによって上書きされます。

この種類のマップについては、他にも重要な機能があります。「autofs がクライアント用の最も近い読み取り専用ファイルを選択する方法 (複数ロケーション)」 を参照してください。

マウントポイント /-

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

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

間接マップ

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

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

key [ mount-options ] location

マスターマップと同様、# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。長い行を短い行に分割するには、行の最後にバックスラッシュ (¥) を入力します。例 31-1 に、次のエントリを含む auto_master マップを示します。

/home      auto_home        -nobrowse    

auto_home は、/home のもとでマウントされるエントリを含む間接マップの名前です。一般的な auto_home マップには次の構文が含まれます。

david                  willow:/export/home/david
rob                    cypress:/export/home/rob
gordon                 poplar:/export/home/gordon
rajan                  pine:/export/home/rajan
tammy                  apple:/export/home/tammy
jim                    ivy:/export/home/jim
linda    -rw,nosuid    peach:/export/home/linda

例として、前のマップがホスト oak にあると想定します。ユーザー linda がホームディレクトリを /home/linda として指定するパスワードデータベースにエントリがある場合、コンピュータ oak にログインするたびに、autofs はコンピュータ peach に常駐する /export/home/linda ディレクトリをマウントします。彼女のホームディレクトリは、読み書き可能な nosuid にマウントされます。

次のような状況が発生したと想定してください。ユーザー linda のホームディレクトリがパスワードデータベースに、/home/linda として表示されます。Linda も含め誰でも、前の例のマップを参照するマスターマップで設定されたどのコンピュータからでも、このパスにアクセスできます。

こうした状況のもとでは、ユーザー linda はこれらのどのコンピュータでも login や rlogin を実行し、代わりに彼女用のホームディレクトリをマウントさせることができます。

さらに、これで linda は次のコマンドも入力できます。

% cd ‾david

autofs は彼女のために David のホームディレクトリをマウントします (すべてのアクセス権で許可されている場合)。

オートマウンタマップの間には、オプションの連結はありません。オートマウンタマップに追加されたいずれのオプションも、前に検索されたマップに表示されているすべてのオプションを上書きします。たとえば、auto_master マップに含まれているオプションは、その他いずれのマップの対応するエントリによって上書きされます。

ネームサービスのないネットワークでこれを行うには、ネットワーク上のすべてのシステムで、すべての関連ファイル (/etc/passwd など) を変更する必要があります。NIS では、NIS マスターサーバーで変更を行い、関連するデータベースをスレーブのデータベースに伝達します。NIS+ を稼働中のネットワークでは、変更後に関連データベースがスレーブサーバーに自動的に伝達されます。

autofs のしくみ

autofs は、自動的に適切なファイルシステムをマウントするためのクライアント側のサービスです。クライアントが現在マウントされていないファイルシステムをアクセスしようとすると、autofs ファイルシステムはその要求に介入し、automountd を呼び出して要求されたディレクトリをマウントします。automountd はディレクトリを検索してマウントし、応答します。応答を受け取ると、autofs は待たせてあった要求の処理を続行させます。それ以降のそのマウントへの参照は autofs によって切り替えられ、このファイルシステムが一定時間使用されないために自動的にアンマウントされるまで、automountd は不要となります。

自動マウントを行うのに、次のコンポーネントが相互に動作します。

• automount コマンド

• autofs ファイルシステム

• automountd デーモン

automount コマンドは、システム起動時に呼び出され、マスターマップファイル auto_master を読み取って autofs マウントの最初のセットを作成します。これらの autofs のマウントは起動時に自動的にはマウントされません。後でファイルシステムがマウントされるポイントです。このようなポイントをトリガーノードと呼ぶこともあります。

autofs マウントが設定されると、要求があったときにファイルシステムをマウントすることができます。たとえば、autofs が、現在マウントされていないファイルシステムをアクセスする要求を受け取ると、automountd を呼び出して要求されたファイルシステムを実際にマウントさせます。

Solaris 2.5 からは、automountd デーモンは完全に automount コマンドから独立しました。そのため、automountd デーモンを 1 度停止してから起動し直さなくてもマップ情報を追加、削除、および変更できるようになりました。

最初に autofs マウントをマウントすると、automount コマンドを使用して、auto_master 内のマウントのリストをマウントテーブルファイル /etc/mnttab (以前は /etc/mtab) 内のマウントされているファイルシステムのリストと比較し、必要な変更を行うことにより、autofs マウントを更新します。こうすることにより、システム管理者は auto_master 内のマウント情報を変更し、autofs デーモンを停止したり、再起動したりすることなく、それらの変更結果を autofs プロセスに使用させることができます。ファイルシステムがマウントされれば、以後のアクセスに automountd は不要となります。次に automountd が必要になるのは、ファイルシステムが自動的にアンマウントされるときです。

mount とは異なり、automount はマウントすべきファイルシステムを調べるために /etc/vfstab ファイル (これは各コンピュータごとに異なる) を参照しません。automount コマンドは、ドメイン内とコンピュータ上で名前空間とローカルファイルを通して制御されます。

autofs のしくみの概要を簡単に説明します。

自動マウントのデーモンである automountd は、ブート時に /etc/init.d/autofs スクリプトから起動されます (図 31-1 を参照してください)。このスクリプトは automount コマンドも実行します。このコマンドはマスターマップを読み取り (「autofs のナビゲーションプロセス開始法 (マスターマップ)」 を参照)、autofs のマウントポイントをインストールします。

図 31-1 /etc/init.d/autofs スクリプトによる automount の起動

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

autofs のマウントポイントにおいてファイルシステムへのアクセス要求が出された場合、autofs は次のように機能します。

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

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

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

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

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

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

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

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

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

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

図 31-2 マスターマップによるナビゲーション

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
/xfn        -xfn
/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. サーバーのマウントサービスが有効かどうかを確認するために、サービスに対して ping を行います。

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/man と /usr/spool/news には、複数のロケーション (/usr/man には 3 つ、/usr/spool/news には 2 つ) が記述されています。

/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 

このような場合、複製された位置のどれからマウントしてもユーザーは同じサービスを受けられます。ユーザーの書き込みまたは変更が可能ならば、その変更をロケーション全体で管理しなければならなくなるので、この手順は、読み取り専用のファイルシステムをマウントするときにだけ意味があります。あるときに、あるサーバー上のファイルを変更し、またすぐに別のサーバー上で「同じ」ファイルを変更しなければならないとしたら、大変面倒な作業になります。この利点は、最も利用しやすいサーバーが、そのユーザーの手をまったく必要としないで自動的にマウントされるということです。

ファイルシステムを複製として設定してあると (「複製されたファイルシステムとは」 を参照)、クライアントはフェイルオーバー機能を使用できます。最適なサーバーが自動的に決定されるだけでなく、そのサーバーが使用できなくなるとクライアントは自動的に 2 番目に適したサーバーを使います。フェイルオーバー機能は、Solaris 2.6 の新機能です。

複製として設定するのに適しているファイルシステムの例は、マニュアルページです。大規模なネットワークでは、複数のサーバーがマニュアルページをエクスポートできます。どのサーバーからマニュアルページをマウントしても、そのサーバーが動作しており、しかもそのファイルシステムをエクスポートしている限り、問題ありません。上の例では、複数のマウント位置は、マップエントリ内のマウント位置のリストになっています。

/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man 

これで、サーバー oak、rose、willow のどれからでもマニュアルページをマウントできます。どのサーバーが最適であるかは、いくつかの要素によって決まります。具体的には、ある特定の NFS プロトコルレベルをサポートしているサーバーの数、サーバーとの距離、重み付けです。

順位を決定するときには、NFS バージョン 2 と NFS バージョン 3 のプロトコルをサポートしているサーバーの数が数えられます。サポートしているサーバーの数が多いプロトコルがデフォルトになります。そのため、クライアントにとっては利用できるサーバーの数が最大になります。

プロトコルのバージョンが同じサーバーの組の中で数が最も多いものがわかると、サーバーのリストが距離によってソートされます。ローカルサブネット上のサーバーには、リモートサブネット上のサーバーよりも高い優先順位が付けられます。最も近いサーバーが優先されることにより、待ち時間が短縮されネットワークトラフィックは軽減されます。図 31-3 に、サーバーとの距離を示します。

図 31-3 サーバーとの距離

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

バージョン 3 のサーバーの方が多いと、優先順位の決定は複雑になります。通常、ローカルサブネット上のサーバーはリモートサブネット上のサーバーよりも優先されます。バージョン 2 のサーバーがあり、それが最も近いバージョン 3 サーバーよりも近いと状況が複雑になる可能性があります。ローカルサブネットにバージョン 2 サーバーがあり、最も近いバージョン 3 サーバーがリモートサブネット上にあると、バージョン 2 サーバーが優先されます。このことは、バージョン 3 サーバーの方がバージョン 2 サーバーよりも多い場合にしかチェックされません。バージョン 2 サーバーの方が多いと、バージョン 2 サーバーしか選択されません。

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

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

autofs と重み付け

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

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

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

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

マップエントリ内の変数

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

キーとして使用する場合を除いて、変数はエントリ行内のどこにでも使用できます。たとえば、SPARC と IA のアーキテクチャ用のバイナリを、それぞれ /usr/local/bin/sparc と /usr/local/bin/x86 からエクスポートしているファイルサーバーがある場合、クライアントは次のようにマップエントリを通じてマウントできます。

/usr/local/bin	 -ro	server:/usr/local/bin/$CPU

これで、すべてのクライアント上の同じエントリがすべてのアーキテクチャに適用されます。

どの sun4 アーキテクチャ向けに書かれたアプリケーションでも、ほとんどはすべての sun4 プラットフォームで実行できます。したがって、-ARCH 変数は sun4m ではなく、sun4 に固定されています。

他のマップを参照するマップ

ファイルマップで使用されたマップエントリ +mapname により、automount は指定されたマップを、あたかも現在のマップに組み込まれているかのように読み取ります。mapname の前にスラッシュがない場合、autofs はそのマップ名を文字列として扱い、ネームサービススイッチ方式を使用してこれを検出します。パス名が絶対パス名の場合、automount はその名前のローカルマップを捜します。マップ名がダッシュ「-」で始まる場合、automount は xfn や 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 は /etc/init.d/autofs にあるスクリプトを使用して起動され、マスターマップ auto_master が検索されます (次に説明する規則が適用されます)。

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

図 31-4 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 のマップ構文解析機能から保護する目的のものがあります。

アンパサンド (&)

たとえば次のように、多数のサブディレクトリを指定したマップがあるとします。

john        willow:/home/john
mary        willow:/home/mary
joe         willow:/home/joe
able        pine:/export/able
baker       peach:/export/baker

この場合、文字列の置換が使えます。アンパサンド文字 (&) を使用して、任意の位置に記述されたこのキーを置換することができます。アンパサンドを使用した場合、上記のマップは次のようになります。

john        willow:/home/&
mary        willow:/home/&
joe         willow:/home/&
able        pine:/export/&
baker       peach:/export/&

キー置換はまた、次のような直接マップでも使用できます。

/usr/man						willow,cedar,poplar:/usr/man

これは次のようにも記述できます。

/usr/man						willow,cedar,poplar:&

なお、アンパサンドによる置換ではキー文字列全体を使用するため、直接マップでキーが / で始まる場合、そのスラッシュは引き継がれます。したがって、次のような指定はできません。

/progs				&1,&2,&3:/export/src/progs 

これは、autofs が次のように解釈するためです。

/progs 				/progs1,/progs2,/progs3:/export/src/progs

アスタリスク (*)

任意のキーを一致させるのに、任意の文字を表す置換文字であるアスタリスク (*) を使用できます。このマップエントリを使用して、すべてのホストから /export ファイルシステムをマウントできます。

*						&:/export

ここでは、各アンパサンドは特定のキーの値によって置換されています。autofs はこのアスタリスクをファイルの終わりとして解釈します。

特殊文字

特殊文字が含まれているマップエントリがある場合、autofs のマップ構文解析機能を混乱させるような名前のディレクトリについてはマウントする必要があります。autofs の構文解析機能は、名前に含まれるコロン、コンマ、スペースなどを認識します。これらの名前は二重引用符で囲んでください。

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