この章では、autofs サービスの構成要素と autofs マップの詳細について説明します。
autofs サービスをサポートするプログラムには、automount と automountd の 2 つがあります。どちらもシステムを起動すると実行されますが、常駐するのは automountd だけです。
このコマンドは autofs マウントポイントをインストールし、オートマスタファイルの情報を各マウントポイントと関連づけます。コマンドの構文は次のようになります。
automount [ -t duration ] [ -v ]
-t duration にはファイルシステムがマウントされたままの時間を秒単位で指定し、-v を指定すると詳細表示モードになります。詳細表示モードでこのコマンドを実行すると、問題の解決が容易になります。
特定の値を指定しないと、-t duration は 5 分に設定されます。ほとんどの状況ではこの値で大丈夫ですが、多くのファイルシステムを自動マウントしているシステムでは、この間隔を延ばす必要もでてきます。特にサーバに多くのアクティブユーザがいる場合、自動マウントしたファイルシステムを 5 分毎にチェックするのは効率が悪くなる恐れがあります。autofs ファイルシステムを 1800秒 (30 分) 毎にチェックさせた方がより最適です。ファイルシステムを 5 分毎にアンマウントさせないことで、df によってチェックされる /etc/mnttab が非常に大きくなることもあります。-F オプション (df(1M) のマニュアルページ参照) を使用して df からの出力をフィルタ処理するか、egrep を使用すればこの問題を解決するのに役立ちます。
もう一つ考慮すべき点としては、間隔を変更することで、マップに対する変更内容をどれだけ迅速に反映させるかも変更になることが挙げられます。変更は、ファイルシステムがアンマウントされるまでは無効です。オートマウンタマップの変更方法については、「マップの変更」 を参照してください。
このデーモンは autofs サービスからのマウントとアンマウント要求を処理します。コマンドの構文は次のようになります。
automountd [ -Tnv ] [ -D name=value ]
-T を指定すると、RPC コールがすべて標準出力に表示されます。-n を指定すると、すべての autofs ノードで表示機能が無効になります。-v を指定すると、コンソールへのすべてのステータスメッセージが記録されます。-D name=value を使うと、name で表された自動マウントマップの値の代わりに value が使われます。自動マウントマップのデフォルト値は /etc/auto_master です。-T オプションは障害追跡のために使います。
autofs は 3 種類のマップを使用します。
マスタマップ
直接マップ
間接マップ
auto_master マップでは、ディレクトリからマップへの関連付けを行います。これは、すべてのマップを指定するマスタリストであり、autofs が参照します。auto_master ファイルの内容の例を示します。
表 5-1 /etc/auto_master ファイルの例
# cat /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 ]
mount-point はディレクトリのフル (絶対) パス名です。このディレクトリが存在しない場合、可能ならば autofs はこれを作成します。このディレクトリが存在し、しかも空ではない場合、マウントすることによってその内容が隠されます。この場合、autofs は警告を出します。
マウントポイントとして /- を指定すると、マップが直接マップであり、このマップ全体に関連付けられている特定のマウントポイントがないことを表します。
map-name 名は、位置に対する指示またはマウント情報を検出するために、autofs が使用するマップです。この名前がスラッシュ (/) で始まる場合、autofs はこの名前をローカルファイルとして解釈します。そうでない場合、autofs はネームサービススイッチ構成ファイルで指定される検索によりマウント情報を検索します。/net と /xfn に対して使われる特殊なマップもあります (「マウントポイント /net」 と「マウントポイント /xfn」 を参照してください)。
mount-options は、オプションです。map-name のエントリに他のオプションがある場合を除き、map-name で指定されたエントリのマウントに適用されるオプションをカンマで区切って並べます。これらのマウントオプションは、標準の NFS マウント用のものと同じですが、bg (バックグラウンド) と fg (フォアグラウンド) は使用できません。「mount」 を参照してください。具体的なファイルシステムごとのオプションについては、そのファイルシステムのマニュアルページで「mount」を参照してください (たとえば NFS 固有のマウントオプションについては、mount_nfs(1M))。NFS 固有のマウントポイントの場合、bg (バックグラウンド) オプションと fg (フォアグラウンド) オプションは適用されません。
# で始まる行はコメント行です。この場合、その行の最後まですべて無視されます。
長い行を短い行に分割するには、行末にバックスラッシュ (¥) を入力します。入力できる文字数の上限は 1024 です。
マウントポイント /home は、/etc/auto_home (間接マップ) に記述されたエントリがマウントされるディレクトリです。
autofs はすべてのコンピュータで動作し、デフォルトでは /net と /home (自動マウントされるホームディレクトリ) をサポートします。このデフォルトは、NIS ならば auto.master マップ、NIS+ ならば auto_master テーブルを使って、またはローカルの /etc/auto_master ファイルを編集することによって変更できます。
autofs は、特別のマップ -hosts 内の全エントリをディレクトリ /net の下にマウントします。これは hosts データベースだけを使用する組み込みマップです。たとえば、コンピュータ gumbo が hosts データベース内にあり、しかもそのファイルシステムのどれかをエクスポートする場合、次のコマンドによって、カレントディレクトリがコンピュータ gumbo のルートディレクトリに変更されます。
%cd /net/gumbo |
なお、autofs はホスト gumbo のエクスポートされたファイルシステムだけをマウントできます。つまり、ローカルディスク上のファイルシステムではなく、ネットワークユーザが使用できるサーバ上のファイルシステムです。したがって、gumbo にあるすべてのファイルとディレクトリは、/net/gumbo では利用できない場合があります。
/net を使ったアクセスでは、サーバ名はパスの中に指定されるため、位置に依存します。したがって、エクスポートされるファイルシステムを別のサーバに移動すると、そのパスは使えなくなります。このような場合は /net を使わずに、そのファイルシステムに対応するエントリをマップの中に設定します。
autofs はマウント時だけサーバのエクスポートリストを調べます。サーバのファイルシステムが一度マウントされると、そのファイルシステムがアンマウントされ、次にマウントされるまで autofs はそのサーバをチェックしません。したがって、新たにエクスポートされたファイルシステムは、それがサーバからアンマウントされ、再度マウントされるまでは見えません。
このマウントポイントは、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
key は直接マップでのマウントポイントのパス名です。
mount-options は、このマウントに適用したいオプションです。これらのオプションは、マップのデフォルトと異なる場合だけ必要です。各ファイルシステムの種類ごとのオプションについては、そのファイルシステムのマニュアルページで「mount」を参照してください (たとえば CacheFS に固有のマウント操作については、マニュアルページの mount_cachefs(1M) を参照してください)。
location にはファイルシステムの位置を、NFS ファイルシステムならば server:pathname、High Sierra ファイルシステム (HSFS) ならば :devicename という形式で指定します。
pathname には自動マウントしたマウントポイントを含めず、ファイルシステムへの実際の絶対パスである必要があります。たとえば、ホームディレクトリの位置は、server:/home/username ではなく、server:/export/home/username として表示する必要があります。
マスタマップと同様、# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。長い行を短い行に分割するには、行の最後にバックスラッシュを入力します。
すべてのマップの中で、直接マップのエントリが、/etc/vfstab (vfstab にはマウントされるすべてのファイルシステムのリストが含まれる) で対応するエントリと一番単純な形式において最もよく似ています。/etc/vfstab に現れるエントリは次のようになります。
dancer:/usr/local - /usr/local/tmp nfs - yes ro |
直接マップでは次のようになります。
/usr/local/tmp -ro dancer:/usr/local |
オートマウンタマップの間では、オプションの連結はされません。あるオートマウンタマップでオプションが追加されると、それまでに見つかったマップに指定されているオプションはすべて無視され、新しいオプションだけが使われます。たとえば、auto_master マップに指定されているオプションは、他のマップの中の対応するエントリによって上書きされます。
この種類のマップについては、ほかにも重要な機能があります。「autofs がクライアント用の最も近い読み取り専用ファイルを選択する方法 (複数ロケーション)」 を参照してください。
表 5-1 にある /- というマウントポイントは、auto_direct の中のエントリを具体的なマウントポイントに関連付けないように autofs に指示します。間接マップの場合は、auto_master ファイルに定義されたマウントポイントを使います。直接マップの場合は、ここに示されたマップの中で指定されたマウントポイントを使います (直接マップのキーとマウントポイントはフルパス名であることに注意してください)。
NIS または NIS+ の auto_master ファイルには、直接マップのエントリは 1 つしか存在できません。マウントポイントは 1 つの名前空間の中で一意でなければならないためです。auto_master がローカルファイルならば、重複しないかぎり直接マップのエントリがいくつあってもかまいません。
間接マップは、キーの置換値を使用してクライアント上のマウントポイントとサーバ上のディレクトリとを対応させます。間接マップは、ホームディレクトリなどの特定のファイルシステムをアクセスするのに便利です。auto_home マップは間接マップの一例です。
key [ mount-options ] location
key は間接マップでの単純名 (スラッシュなし) です。
mount-options は、このマウントに適用するオプションです。これらのオプションが必要なのは、マップのデフォルトと異なる場合だけです。各ファイルシステムタイプごとのオプションについては、そのファイルシステムのマニュアルページで「mount」を参照してください (たとえば NFS 固有のマウントオプションについては、マニュアルページの mount_nfs(1M)を参照してください)。
location はファイルシステムステムの位置を示し、server:pathname により (1 つまたは複数) 指定されます。
pathname には自動マウントしたマウントポイントを含めず、ファイルシステムへの実際の絶対パスである必要があります。たとえば、ディレクトリの位置は、server:/net/server/usr/local ではなく、server:/usr/local として表示する必要があります。
マスタマップと同様、# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。長い行を短い行に分割するには、行の最後にバックスラッシュ (¥) を入力します。表 5-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 ファイルシステムはその要求に介入し、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 スクリプトから起動されます (図 5-1 を参照してください)。このスクリプトは automount コマンドも実行します。このコマンドはマスタマップを読み取り (「autofs のナビゲーションプロセス開始法 (マスタマップ)」 を参照)、autofs のマウントポイントをインストールします。
autofs は、自動マウント操作とアンマウント操作をサポートするカーネルファイルシステムの 1 つです。
autofs のマウントポイントにおいてファイルシステムへのアクセス要求が出された場合、autofs は次のように機能します。
autofs がその要求に介入します。
autofs は要求されたファイルシステムをマウントするよう、automountd にメッセージを送信します。
automountd がマップからファイルシステム情報を見つけ、マウントを実行します。
autofs は、介入した要求の実行を続行させます。
一定時間そのファイルシステムがアクセスされないと、autofs はそれをアンマウントします。
autofs サービスによって管理されるマウントは、手動でマウントしたりアンマウントは行わないでください。たとえこの操作がうまくいったとしても、autofs サービスはオブジェクトがアンマウントされたことを認識しないので、一貫性が損なわれる恐れがあります。リブートによって、autofs のマウントポイントがすべて消去されます。
autofs は一連のマップを探索することによって、ネットワークをナビゲートします。マップとは、ネットワーク上の全ユーザのパスワードエントリ、またはネットワーク上の全ホストコンピュータの名前などの情報が収められているファイルです。つまり、UNIX 管理ファイルのネットワーク版といえます。マップはローカルに使用するか、または NIS や NIS+ のようなネットワークネームサービスを通じて使用できます。Solstice システム管理ツールを使用して、ユーザは自分の環境ニーズに適合するマップを作成します。「autofs のネットワークナビゲート法の変更 (マップの変更)」 を参照してください。
automount コマンドはシステムの起動時にマスタマップを読み取ります。図 5-2 に示すように、マスタマップ内の各エントリは、直接または間接のマップ名、そのパス、およびそのマウントオプションです。エントリの順序は重要ではありません。automount は、マスタマップ内のエントリとマウントテーブル内のエントリを比較して、現在のリストを生成します。
マウント要求が発生したときに autofs サービスが何を実行するかは、オートマウンタマップの設定によって異なります。マウントプロセスの基本はすべてのマウントで同じですが、指定されているマウントポイントとマップの複雑さによって結果が変わります。Solaris 2.6 ではマウントプロセスも変更され、トリガーノードも作成されるようになりました。
autofs マウントプロセスの説明のために、以下のファイルがインストールされていると仮定します。
$ cat /etc/auto_master # Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /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 サービスは以下の手順を実行します。
サーバのマウントサービスが有効かどうかを確認するために、サービスに対して ping を行います。
要求されたファイルシステムを、/share の下にマウントします。これで、/etc/mnttab ファイルには以下のエントリが追加されます。
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### ##### |
オートマウンタファイルに複数の層が定義されていると、マウントプロセスは多少複雑になります。上記の例の /etc/auto_shared ファイルを拡張して以下のエントリを追加したとします。
# share directory map for automounter # ws / gumbo:/export/share/ws /usr gumbo:/export/share/ws/usr |
この場合、/share/ws マウントポイントがアクセスされたときのマウントプロセスは基本的に最初の例と同じです。また、/share/ws ファイルシステムの中に次のレベル (/usr) へのトリガーノードを作成することにより、そのレベルがアクセスされたときにマウントできるようにします。 この例でトリガーノードが作成されるためには、NFS に /export/share/ws/usr が存在している必要があります。
階層を指定するときに、-soft オプションは使用しないでください。 この制限に関する説明は、「autofs アンマウント」を参照してください。
一定時間アクセスがないためにアンマウントされるときは、マウントと反対の順序で実行されます。あるディレクトリより上位のディレクトリが使用中であれば、それより下のディレクトリだけがアンマウントされます。 アンマウントすると、トリガーノードがすべて削除され、ファイルシステムがアンマウントされます。ファイルシステムが使用中であれば、アンマウントは失敗してトリガーノードは再インストールされます。
階層的にマウントを指定する場合は、-soft オプションは使用しないでください。-soft オプションを使用すると、トリガーノードを再インストールする要求がタイムアウトすることがあります。トリガーノードを再インストールできないと、マウントの次の階層にアクセスできません。この問題は、オートマウンタがすべての階層の構成要素をアンマウントすることでしか回避できません。具体的には、ファイルシステムが自動的にアンマウントされるのを待つか、システムをリブートすることになります。
/usr/local -ro ¥ /bin ivy:/export/local/sun4¥ /share ivy:/export/local/share¥ /src ivy:/export/local/src /usr/man -ro oak:/usr/man ¥ rose:/usr/man ¥ willow:/usr/man /usr/games -ro peach:/usr/games /usr/spool/news -ro pine:/usr/spool/news ¥ willow:/var/spool/news |
マウントポイント /usr/man と /usr/spool/news には、複数のロケーション (/usr/man には 3 つ、/usr/spool/news には 2 つ) が記述されています。このような場合、複製された位置のどれからマウントしてもユーザは同じサービスを受けられます。ユーザの書き込みまたは変更が可能ならば、その変更をロケーション全体で管理しなければならなくなるので、この手順は、読み取り専用のファイルシステムをマウントするときにだけ意味があります。あるときに、あるサーバ上のファイルを変更し、またすぐに別のサーバ上で「同じ」ファイルを変更しなければならないとしたら、大変面倒な作業になります。この利点は、最も利用しやすいサーバが、そのユーザの手をまったく必要としないで自動的にマウントされるということです。
ファイルシステムを複製として設定してあると (「複製されたファイルシステムとは」 を参照してください)、クライアントは障害時回避機能を使用できます。最適なサーバが自動的に決定されるだけでなく、そのサーバが使用できなくなるとクライアントは自動的に 2 番めに適したサーバを使います。障害時回避機能は、Solaris 2.6 の新機能です。
複製として設定するのに適しているファイルシステムの例は、マニュアルページです。大規模なネットワークでは、複数のサーバがマニュアルページをエクスポートできます。どのサーバからマニュアルページをマウントしても、そのサーバが動作しており、しかもそのファイルシステムをエクスポートしている限り、問題ありません。上の例では、複数のマウント位置は、マップエントリ内のマウント位置のリストになっています。
/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man |
これは、サーバをコンマで区切ったリストにし、その後にコロンとパス名を指定することによって入力することもできます (複製されるサーバすべてでパス名が同じ場合に限ります)。
/usr/man -ro oak,rose(1),willow(2):/usr/man |
これで、サーバ oak、rose、willow のどれからでもマニュアルページをマウントできます。どのサーバが最適であるかは、いくつかの要素によって決まります。具体的には、ある特定の NFS プロトコルレベルをサポートしているサーバの数、サーバのとの距離、重み付けです。
順位を決定するときには、NFS バージョン 2 と NFS バージョン 3 のプロトコルをサポートしているサーバの数が数えられます。サポートしているサーバの数が多いプロトコルがデフォルトになります。そのため、クライアントにとっては利用できるサーバの数が最大になります。
プロトコルのバージョンが同じサーバの組の中で数が最も多いものが分かると、サーバのリストが距離によってソートされます。ローカルサブネット上のサーバには、リモートサブネット上のサーバよりも高い優先順位が付けられます。最も近いサーバが優先されることにより、待ち時間が短縮されネットワークトラフィックは軽減されます。94 ページの 図 5-3 に、サーバとの距離を図示します。
ローカルサブネット上に同じプロトコルをサポートしているサーバが複数あるときは、それぞれのサーバに接続する時間が計測され、速いものが使われます。優先順位には、重み付けも関係します (「autofs と重み付け」 を参照してください)。
バージョン 3 のサーバの方が多いと、優先順位の決定は複雑になります。通常、ローカルサブネット上のサーバはリモートサブネット上のサーバよりも優先されます。バージョン 2 のサーバがあり、それが最も近いバージョン 3 サーバよりも近いと状況が複雑になる可能性があります。ローカルサブネットにバージョン 2 サーバがあり、最も近いバージョン 3 サーバがリモートサブネット上にあると、バージョン 2 サーバが優先されます。このことは、バージョン 3 サーバの方がバージョン 2 サーバよりも多い場合にしかチェックされません。バージョン 2 サーバの方が多いと、バージョン 2 サーバしか選択されません。
障害時回避機能を指定していると、この優先順位はマウント時に 1 回、マウントするサーバを選択するときにチェックされ、その後は選択されたサーバが使用できなくなるたびにチェックされます。複数位置を指定しておくと、個々のサーバが一時的にファイルシステムをエクスポートできないときに便利です。
多くのサブネットを持つ大規模なネットワークでは、この機能は特に便利です。autofs は最も近いサーバを選択するため、NFS のネットワークトラフィックをローカルネットワークセグメントに制限します。複数のネットワークインタフェースを持つサーバの場合は、それぞれが別々のサーバであるとみなして、各ネットワークインタフェースに対応付けられているホスト名を指定します。autofs はそのクライアントに一番近いインタフェースを選択します。
距離のレベルが同じサーバから 1 つを選択するために、autofs マップに重み付けの値を追加することができます。たとえば次のようにします。
/usr/man -ro oak,rose(1),willow(2):/usr/man |
括弧内の数値が重み付けを表します。重み付けのないサーバの値はゼロです (選択される可能性が最高です)。重み付けの値が大きいほど、そのサーバが選択される可能性は低くなります。
重み付けは、サーバの選択に関係する要素の中で最も小さい影響力しかありません。ネットワーク上の距離が同じサーバの間で選択を行う場合に考慮されるだけです。
変数名の前にドル記号 ($) を付けることによって、クライアント固有の変数を作成できます。この機能は、同じファイルシステムの位置にアクセスする異なるアーキテクチャタイプの調整に役立ちます。変数名を括弧でくくることで、そのうしろに続く文字や数字と変数とを区切ることができます。表 5-2 に定義済みのマップ変数を示します。
表 5-2 定義済みのマップ変数
変数 |
意味 |
情報提供元 |
例 |
---|---|---|---|
アーキテクチャタイプ |
uname -m |
sun4 |
|
プロセッサタイプ |
uname -p |
sparc |
|
ホスト名 |
uname -n |
dinky |
|
オペレーティングシステム名 |
uname -s |
SunOS |
|
オペレーティングシステムのリリース |
uname -r |
5.4 |
|
オペレーティングシステムのバージョン (リリースのバージョン) |
uname -v |
FCS1.0 |
キーとして使用する場合を除いて、変数はエントリ行内のどこにでも使用できます。たとえば、SPARC と x86 のアーキテクチャ用のバイナリを、それぞれ /usr/local/bin/sparc と /usr/local/bin/x86 からエクスポートしているファイルサーバがある場合、クライアントは次のようにマップエントリを通じてマウントできます。
/usr/local/bin -ro server:/usr/local/bin/$CPU |
これで、すべてのクライアント上の同じエントリがすべてのアーキテクチャに適用されます。
どの sun4 アーキテクチャ向けに書かれたアプリケーションでも、ほとんどはすべての sun4 プラットフォームで実行できます。したがって、-ARCH 変数は sun4m でも sun4c でもなく、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 マップが有効なことがあります。短所は、マップをすべてのホストにインストールしなければならないことです。実行可能なマップは、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) になっている必要があります。これらの条件のときに次のコマンドを実行すると、
% ls /execute/src |
bee から /export1 ファイルシステムがマウントされます。
マップへのエントリを変更、削除、または追加して、ユーザの環境ニーズに合わせることができます。ユーザが必要とするアプリケーションやその他のファイルシステムがその位置を変更すると、マップはこれらの変更を反映しなければなりません。autofs のマップは、いつでも変更できます。automountd が次にファイルシステムをマウントしたときにその変更内容が有効となるかどうかは、変更したマップと変更内容によって決まります。
ブート時に、autofs は /etc/init.d/autofs にあるスクリプトを使用して起動され、マスタマップ auto_master が検索されます (次に説明する規則が適用されます)。
autofs は、/etc/nsswitch.conf ファイルの自動マウントエントリで指定されたネームサービスを使用します。ローカルファイルや NIS ではなく NIS+ が指定された場合、マップ名はすべてそのまま使用されます。NIS が選択されていて autofs が必要なマップを検出できず、1 つまたは複数の下線を含むマップを検出した場合、以前の NIS ファイル名を使えるようにするため、autofs はその下線をドットに変換します。次に autofs はもう 1 度マップを調べます。この手順を 図 5-4 に示します。
このセッションでの画面の動きは次の例のようになります。
$ grep /home /etc/auto_master /home auto_home $ ypmatch brent auto_home Can't match key brent in map auto_home. Reason: no such map in server's domain. $ ypmatch brent auto.home diskus:/export/home/diskus1/& |
ネームサービスとして「ファイル」が選択された場合、すべてのマップは /etc ディレクトリ内のローカルファイルとみなされます。autofs は、使用するネームサービスとは無関係に、スラッシュで始まるマップ名をローカルとして解釈します。
これ以降の節では、autofs の高度な機能を取り上げます。
autofs は一部の文字を、特別な意味を持つものとして認識します。これらの文字には、置換に使用される文字や、他の文字を autofs のマップ構文解析機能から保護する目的のものがあります。
たとえば次のように、多数のサブディレクトリを指定したマップがある場合、
john willow:/home/john mary willow:/home/mary joe willow:/home/joe able pine:/export/able baker peach:/export/baker |
この場合、文字列の置換が使えます。アンパサンド文字 (&) を使用して、任意の位置に記述されたこのキーを置換することができます。アンパサンドを使用した場合、上のマップは次のようになります。
john willow:/home/& mary willow:/home/& joe willow:/home/& able pine:/export/& baker peach:/export/& |
キー置換はまた、次のような直接マップでも使用できます。
/usr/man willow,cedar,poplar:/usr/man |
これは次のようにも記述できます。
/usr/man willow,cedar,poplar:& |
なお、アンパサンドによる置換ではキー文字列全体を使用するため、直接マップでキーが / で始まる場合、そのスラッシュは引き継がれます。したがって、次のような指定はできません。
/progs &1,&2,&3:/export/src/progs |
その理由は、autofs がこれを次のように解釈するためです。
/progs /progs1,/progs2,/progs3:/export/src/progs |
任意のキーを一致させるのに、任意の文字を表す置換文字であるアスタリスク (*) を使用できます。このマップエントリを使って、すべてのホストから /export ファイルシステムをマウントできます。
* &:/export |
ここでは、各アンパサンドは特定のキーの値によって置換されています。autofs はこのアスタリスクをファイルの終わりとして解釈します。
特殊文字が含まれているマップエントリがある場合、autofs のマップ構文解析機能を混乱させるような名前のディレクトリについてはマウントする必要があります。autofs の構文解析機能は、名前に含まれるコロン、カンマ、スペースなどを認識します。これらの名前は二重引用符で囲んでください。
/vms -ro vmsserver: - - - "rc0:dk1 - " /mac -ro gator:/ - "Mr Disk - " |