autofs のしくみ

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

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

• automount コマンド

• autofs ファイルシステム

• automountd デーモン

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

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

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

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

次の図では、autofs のしくみの概要を簡単に説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図 16-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/local          -ro \
   /bin                   ivy:/export/local/sun4\
   /share                 ivy:/export/local/share\
   /src                   ivy:/export/local/src
/usr/man            -ro   oak:/usr/man \
                          rose:/usr/man \
                          willow:/usr/man
/usr/games          -ro   peach:/usr/games
/usr/spool/news     -ro   pine:/usr/spool/news \
                          willow:/var/spool/news 

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

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

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

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

この例では、サーバー oak、rose、willow のどれからでもマニュアルページをマウントできます。どのサーバーが最適であるかは、次のいくつかの要素によって決まります。

• 特定レベルの NFS プロトコルをサポートしているサーバーの数

• サーバーとの距離

• 重み付け

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

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

図 16-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

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

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

マップエントリ内の変数

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

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

/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 はもう 1 度マップを調べます。この手順を図 16–4 に示します。

図 16-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 は、使用するネームサービスとは無関係に、スラッシュ (/) で始まるマップ名をローカルとして解釈します。