autofs は、自動的に適切なファイルシステムをマウントするためのクライアント側のサービスです。クライアントが現在マウントされていないファイルシステムをアクセスしようとすると、autofs ファイルシステムはその要求に介入し、automountd を呼び出して要求されたディレクトリをマウントします。automountd はディレクトリを検索してマウントし、応答します。応答を受け取ると、autofs は待たせてあった要求の処理を続行させます。それ以降のそのマウントへの参照は autofs によって切り替えられ、このファイルシステムが一定時間使われないために自動的にアンマウントされるまで、automountd は不要となります。
自動マウントを行うのに、次の 3 つのコンポーネントが相互に動作します。
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 が存在している必要があります。
一定時間アクセスがないためにアンマウントされるときは、マウントと反対の順序で実行されます。あるディレクトリより上位のディレクトリが使用中だと、それよりも下のディレクトリだけがアンマウントされます。
/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 は、使用するネームサービスとは無関係に、スラッシュで始まるマップ名をローカルとして解釈します。