Go to main content
Oracle® Solaris 11.3 でのネットワークファイルシステムの管理

印刷ビューの終了

更新: 2016 年 11 月
 
 

autofs のしくみ

autofs は、自動マウント操作とアンマウント操作をサポートするカーネルファイルシステムの 1 つです。自動マウントを行うために、次のコンポーネントが連動します。

  • automount コマンド

  • autofs ファイルシステム

  • automountd デーモン

autofs は自動的に適切なファイルシステムをマウントするクライアント側サービスです。自動マウントサービス (svc:/system/filesystem/autofs) は、システムが起動するときに呼び出され、マスターマップファイル auto_master を読み取って autofs マウントの初期セットを作成します。これらの autofs マウントは起動時ではなく、あとからファイルシステムがマウントされる時点に自動的にマウントされます。このようなポイントをトリガーノードと呼ぶこともあります。ナビゲーションプロセスの起動の詳細は、autofs のナビゲーションプロセス開始法を参照してください。

次の図は、autofs サービスが automount コマンドを起動する方法を示しています。

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

image:この図は、autofs サービスが automount コマンドを起動することを示しています。

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

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

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

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

  3. automountd デーモンがマップからファイルシステム情報を見つけ、トリガーノードを作成し、マウントを実行します。

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

  5. そのファイルシステムが一定期間非アクティブである場合、autofs はそのファイルシステムをアンマウントします。

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

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


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

autofs のネットワークナビゲート

autofs は一連のマップを検索することによって、ネットワークをナビゲートします。マップは、ネットワーク上の全ユーザーのパスワードエントリや、ネットワーク上の全ホストコンピュータの名前などの情報を含むファイルです。マップには UNIX の管理ファイルに相当するネットワーク規模の管理ファイルも含まれています。マップはローカルに使用するか、あるいは NIS や LDAP のようなネットワークネームサービスを通じて使用できます。

autofs マップ

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

  • マスターマップ

  • 直接マップ

  • 間接マップ

autofs マスターマップ

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

使用例 1  /etc/auto_master ファイルの例
# Master map for automounter 
# 
+auto_master 
/net            -hosts           -nosuid,nobrowse 
/home           auto_home        -nobrowse 
/nfs4           -fedfs           -ro,nosuid,nobrowse
/-              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 はネームサービススイッチ構成ファイル (/etc/nsswitch.conf) で指定される検索を使用してマウント情報を検索します。また、/net には、特別なマップを使用します。詳細は、/net マウントポイント を参照してください。

mount-options

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

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

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


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

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


注 -  autofs はすべてのコンピュータで動作し、デフォルトでは /net/home (自動マウントされるホームディレクトリ) をサポートします。これらのデフォルトエントリは、NIS auto.master マップ内でまたは /etc/auto_master ファイルをローカル編集することで、オーバーライドできます。
/net マウントポイント

autofs は、ホストデータベースのみを使用する特殊な組み込みマップ -hosts 内の全エントリを /net ディレクトリの下にマウントします。たとえば、hosts データベースにあるコンピュータ system1 が、そのファイルシステムをエクスポートするとします。次のコマンドを入力すると、現在のディレクトリがコンピュータ gumbo のルートディレクトリに変更されます。

# cd /net/gumbo

autofs はホスト system1エクスポート済みファイルシステム (つまり、ローカルディスク上のそれらのファイルシステムではなく、ネットワークユーザーが使用できるサーバー上のそれらのファイルシステム) だけをマウントできます。したがって、system1 上のすべてのファイルおよびディレクトリを /net/system1 から使用できるとは限らないこともあります。

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


注 -  NFS Version 3 およびそれより前のプロトコルを使用すると、autofs はマウント時のみサーバーのエクスポートリストを調べます。サーバーのファイルシステムが一度マウントされると、そのファイルシステムがアンマウントされ、次にマウントされるまで autofs はそのサーバーをチェックしません。したがって、新たにエクスポートされたファイルシステムは、それがサーバーからアンマウントされ、再度マウントされるまでは見えません。NFS Version 4 を使用するシステムでは、ミラーマウントによって、エクスポート済みファイルシステムのリストに加えられた動的変更がサーバーに反映されます。
/nfs4 マウントポイント

/nfs4 マウントポイントは、擬似マップを使用して FedFS ドメインルートをマウントします。/nfs4/example.net を参照すると、ドメインルートで DNS ドメイン example.net を検索し、その場所でマウントしようとします。/nfs4 の下でパスをマウントするには、FedFS サーバー用の DNS レコードの設定 で説明されているとおり、DNS サーバーがレコードを返す必要があります。

直接 autofs マップ

直接マップは自動マウントポイントです。つまり、直接マップによって、クライアント上のマウントポイントとサーバー上のディレクトリが直接対応付けられます。直接マップにはフルパス名があり、明示的に関係を示します。次の例に典型的な /etc/auto_direct マップを示します。

/usr/local          -ro \
   /bin                   system1:/export/local/sun4 \
   /share                 system1:/export/local/share \
   /src                   system1:/export/local/src
/usr/man            -ro   system2:/usr/man \
                          system3:/usr/man \
                          system4:/usr/man 
/usr/games          -ro   system5:/usr/games 
/usr/spool/news     -ro   system6:/usr/spool/news \
                          system4:/var/spool/news 

直接マップ内の行は、次の構文に従います。

key [ mount-options ] location

key

直接マップ内のマウントポイントのパス名。

mount-options

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

location

ファイルシステムの場所。NFS ファイルシステムの場合、1 つまたは複数のファイルシステムが server:pathname として指定されます。


注 -  パス名に自動マウントされたマウントポイントを含めるべきではありません。パス名は、ファイルシステムへの実際の絶対パスにするようにしてください。たとえば、ホームディレクトリの位置は、server:/home/username ではなく、server:/export/home/username としてリストするようにしてください。

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

すべてのマップにおいて、直接マップ内のエントリは、/etc/vfstab 内の対応するエントリにもっともよく似ています。/etc/vfstab のエントリは、次のようになっているとします。

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

直接マップ内では、同じエントリが次のようになります。

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

注 -  オートマウンタマップの間では、オプションの連結はされません。オートマウンタマップに追加されたどのオプションも、前に検索されたマップに表示されているすべてのオプションをオーバーライドします。たとえば、auto_master マップに指定されているオプションは、他のマップの中の対応するエントリによってオーバーライドされます。

直接 autofs マップの機能については、autofs がクライアント用のもっとも近い読み取り専用ファイルを選択する方法を参照してください。

/- マウントポイント

使用例 1のマウントポイント /- は、auto_direct 内のエントリを特定のマウントポイントに関連付けないように autofs に指示します。間接マップは、auto_master ファイルに定義されたマウントポイントを使います。直接マップの場合は、名前付きマップ内で指定したマウントポイントを使用します。直接マップ内では、鍵、つまりマウントポイントはフルパス名です。

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

間接 autofs マップ

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

間接マップ内の行は次の汎用構文に従います。

key [ mount-options ] location

key

間接マップでのスラッシュ (/) のない名前。

mount-options

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

location

ファイルシステムの場所。1 つまたは複数のファイルシステムを server: pathname として指定します。


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

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

/home      auto_home        -nobrowse    

auto_home は、/home の下にマウントされるエントリを含む間接マップの名前です。通常、auto_home マップには、次のパスが含まれています。

user1                  server1:/export/home/user1
user2                  server2:/export/home/user2
user3                  server3:/export/home/user3
user4                  server4:/export/home/user4
user5                  server5:/export/home/user5
user6                  server6:/export/home/user6
user7    -rw,nosuid    server7:/export/home/user7

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

次の状況が発生したと想定してください。ユーザー user7 のホームディレクトリがパスワードデータベースに、/home/user7 としてリストされます。user7 も含むだれでもが、auto_home マップを参照するマスターマップで設定された任意のコンピュータからこのパスにアクセスできます。

これらの状況では、ユーザー user7 はこれらのコンピュータのいずれかで loginrlogin を実行し、自分のホームディレクトリを所定の場所にマウントさせることができます。

さらに、user7 はここで次のコマンドを入力することもできます。

# cd ~user1

autofs は user1 のために user7 のホームディレクトリをマウントします (すべてのアクセス権が許可する場合)。


注 -  オートマウンタマップの間では、オプションの連結はされません。オートマウンタマップに追加されたどのオプションも、前に検索されたマップに表示されているすべてのオプションをオーバーライドします。たとえば、auto_master マップに含まれているオプションは、他のいずれかのマップの対応するエントリによってオーバーライドされます。

ネームサービスのないネットワークで、Linda が自分のファイルにアクセスすることを許可するには、ネットワーク上のすべてのシステムで、すべての関連ファイル (/etc/passwd など) を変更する必要があります。NIS では、NIS マスターサーバーで変更を行い、関連するデータベースをスレーブのデータベースに伝達します。

autofs のナビゲーションプロセス開始法

automount コマンドはシステムの起動時にマスターマップを読み取ります。マスターマップ内の各エントリは、直接マップ名または間接マップ名、そのパス、およびそのマウントオプションです。エントリの具体的な順序は重要ではありません。

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

image:この図は、ファイルシステムをマウントまたはアンマウントするために automount コマンドによってどのような情報が使用されるかを示しています。

この図は、automount がマスターマップ内のエントリとマウントテーブル内のエントリとを比較して、現在のリストを生成することを示しています。

autofs マウントプロセス

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

単純な autofs マウント

autofs マウントプロセスの説明のために、次のファイルがインストールされていると仮定します。

$ cat /etc/auto_master
# Master map for automounter
#
+auto_master
/net        -hosts        -nosuid,nobrowse
/home       auto_home     -nobrowse
/share      auto_share
$ cat /etc/auto_share
# share directory map for automounter
#
ws          gumbo:/export/share/ws

/share ディレクトリがアクセスされると、autofs サービスは /share/ws に対するトリガーノードを作成します。これは、/etc/mnttab の中では次のようなエントリになります。

-hosts  /share/ws     autofs  nosuid,nobrowse,ignore,nest,dev=###

    /share/ws ディレクトリがアクセスされると、autofs サービスは次ような処理を完了します。

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

  2. 要求されたファイルシステムを、/share の下にマウントします。これで、/etc/mnttab ファイルには次のエントリが追加されます。

    -hosts  /share/ws     autofs  nosuid,nobrowse,ignore,nest,dev=###
    gumbo:/export/share/ws /share/ws   nfs   nosuid,dev=####    #####

階層型マウント

オートマウンタファイルに複数の層が定義されているときは、マウントプロセスは複雑になります。前の例の /etc/auto_shared ファイルを拡張して、次の行を追加したとします。

# share directory map for automounter
#
ws       /       gumbo:/export/share/ws
         /usr    gumbo:/export/share/ws/usr

/share/ws マウントプロセスは基本的に、マウントポイントがアクセスされる前の例と同じです。さらに、/share/ws ファイルシステム内に次のレベル (/usr) へのトリガーノードが作成されるので、次のレベルがアクセスされたときにマウントできます。この例でトリガーノードが作成されるためには、NFS に /export/share/ws/usr が存在している必要があります。


Caution

注意  -  階層的にマウントを指定する場合は、–soft オプションは使用しないでください。詳細は、autofs アンマウント を参照してください。


autofs アンマウント

一定のアイドル時間後に発生するアンマウントは、下位から上位方向です (マウントと逆の順序)。あるディレクトリより上位のディレクトリが使用中であれば、それより下のディレクトリだけがアンマウントされます。アンマウントすると、トリガーノードがすべて削除され、ファイルシステムがアンマウントされます。ファイルシステムが使用中であれば、アンマウントは失敗してトリガーノードは再インストールされます。


Caution

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


autofs がクライアント用のもっとも近い読み取り専用ファイルを選択する方法

このセクションでは、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 には 1 つ以上の場所 (最初のマウントポイントには 3 つの場所、2 番目のマウントポイントには 2 つの場所) がリストされています。複製された場所のどこからマウントしてもユーザーは同じサービスを受けられます。ユーザーの書き込みまたは変更が可能ならば、その変更をロケーション全体で管理しなければならなくなるので、この手順は、読み取り専用のファイルシステムをマウントするときにだけ意味があります。あるときに、あるサーバー上のファイルを変更し、そのすぐあとに別のサーバー上で「同じ」ファイルを変更するといった作業は避けたいものです。この利点は、最善の利用可能なサーバーがユーザーの作業なしで自動的に使用されることです。

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

複製として構成するのに適しているファイルシステムの例は、マニュアルページです。大規模なネットワークでは、複数のサーバーがマニュアルページをエクスポートできます。どのサーバーからマニュアルページをマウントするかは、サーバーが実行中でそのファイルシステムをエクスポートしているかぎり、重要ではありません。直接マップの例では、複数のマウント場所は、マップエントリ内のマウント場所のリストとして表現されています。

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

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

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

  • サーバーの近接性

  • 重み付け

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

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


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

図 5は、サーバー近接性を示しています。

図 5  サーバー近接性

image:この図は、サーバーとの距離を示しています。

ローカルサブネット上に同じプロトコルをサポートしているサーバーが複数あるときは、それぞれのサーバーに接続する時間が計測され、速いものが使用されます。重み付けを使用することで選別が影響されることもあります。重み付けの詳細は、autofs と重み付け. を参照してください。

    たとえば、ローカルサブネット上で NFS Version 4 サーバーの方が多い場合には、NFS Version 4 がデフォルトで使用されるプロトコルになります。ただし、ローカルサブネット上のサーバーが異なるプロトコルをサポートするときは、選別プロセスが複雑になります。次に、優先順位の決定の例をいくつか示します。

  • ローカルサブネット上のサーバーには、リモートサブネット上のサーバーよりも高い優先順位が付けられます。ローカルサブネット上に NFS Version 3 サーバーがあり、もっとも近い NFS Version 4 サーバーがリモートサブネット上にある場合は、NFS Version 3 サーバーが優先されます。同様に、ローカルサブネットが NFS Version 2 サーバーで構成される場合は、それらが NFS Version 3 と NFS Version 4 サーバーで構成されるリモートサブネットより優先されます。

  • ローカルサブネットが NFS Version 2、NFS Version 3、および NFS Version 4 サーバーで構成されていて、それぞれ数が異なる場合は、より複雑な選別が必要になります。オートマウンタは、ローカルサブネット上でもっとも高いバージョンを優先します。この場合、NFS Version 4 がもっとも高いバージョンです。ただし、ローカルサブネット上で NFS Version 4 サーバーよりも NFS Version 3 または NFS Version 2 サーバーが多い場合には、オートマウンタはローカルサブネット上のもっとも高いバージョンから 1 バージョン「競り下げ」ます。たとえば、ローカルサブネットが NFS Version 4 で 3 サーバー、NFS Version 3 で 3 サーバー、NFS Version 2 で 10 サーバーで構成される場合は、NFS Version 3 サーバーが選択されます。

  • 同じように、ローカルサブネットが NFS Version 2 と NFS Version 3 サーバーで構成され、それぞれ数が異なる場合は、オートマウンタは最初にどのバージョンがローカルサブネット上でもっとも高いバージョンを示しているかを見つけます。次に、オートマウンタは各バージョンを実行するサーバーの数を数えます。ローカルサブネット上でもっとも高いバージョンが、同時にもっとも多いサーバーの場合、もっとも高いバージョンが選択されます。低いバージョンのサーバーの数が多い場合、オートマウンタはローカルサブネットのもっとも高いバージョンから 1 つ下のバージョンを選択します。たとえば、ローカルサブネット上で NFS Version 2 サーバーが NFS Version 3 サーバーよりも多い場合、NFS Version 2 サーバーが選択されます。


注 -  重み付けには、SMF リポジトリに保存されているパラメータも影響します。具体的には、server_versminclient_versminserver_versmax、および client_versmax の値によって、いくつかのバージョンを選別プロセスから除外できます。これらのパラメータの詳細は、NFS デーモン を参照してください。

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

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


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

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

autofs と重み付け

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

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

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


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

autofs マップエントリ内の変数

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

表 1  定義済みのマップ変数
変数
意味
派生元
ARCH
アーキテクチャータイプ
uname -m
sun4
CPU
プロセッサタイプ
uname -p
sparc
HOST
ホスト名
uname -n
system1
OSNAME
オペレーティングシステム名
uname -s
SunOS
OSREL
オペレーティングシステムリリース
uname -r
5.10
OSVERS
オペレーティングシステムのバージョン (リリースのバージョン)
uname -v
GENERIC

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

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

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


注 -  どの sun4 アーキテクチャー向けに書かれたアプリケーションでも、ほとんどはすべての sun4 プラットフォームで実行できます。–ARCH 変数は、sun4 にハードコードされています。

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

ファイルマップ内のマップエントリ内のマップ名で使用される特殊文字は、マップ名の処理方法に影響します。

  • マップエントリ +mapname がファイルマップで使用されている場合、automount は指定されたマップが現在のファイルに含まれていかのように読み取ります。

  • mapname の前にスラッシュがない場合、autofs はそのマップ名を文字列として扱い、ネームサービススイッチ方式を使用してマップ名を検出します。パス名が絶対パス名の場合、automount はその名前のローカルマップを検索します。

  • マップ名がダッシュ (-) で始まる場合、automounthosts などの適切な組み込みマップを参照します。

svc:system/name-service/switch サービスはネームサービスの検索順序を保持しています。config プロパティーグループの automount プロパティーは、自動マウントエントリを探すときのネームサービスデータベースの検索順序を指定します。特定の config/automount プロパティーが指定されていない場合は、config/default プロパティーで定義された順序が使用されます。

使用例 2  automount コマンドでマップの検索順序を表示する
# svcprop -p config svc:/system/name-service/switch
config/value_authorization astring solaris.smf.value.name-service.switch
config/printer astring user\ files
config/default astring files\ nis
config/automount astring files\ nis

この例は、ローカルファイル内のマップが NIS マップよりも先に検索されることを示しています。config/automount プロパティーが指定されていなかったとしても、config/default エントリが使用されるため、結果は同じになります。そのため、ローカルマップ /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 

組み込まれたマップは、ローカルファイルまたは組み込みマップとすることができます。ローカルファイルだけが + エントリを含めることができます。

+/etc/auto_mystuff      # local map
+auto_home              # NIS map
+-hosts                 # built-in hosts map 

注 -  NIS マップでは「+」エントリを使用できません。

実行可能な autofs マップ

autofs マウントポイントを生成するコマンドを実行する autofs マップを作成できます。データベースやフラットファイルから autofs 構造を作成できる必要がある場合は、実行可能 autofs マップが役立ちます。短所は、マップをすべてのホストにインストールしなければならないことです。実行可能なマップは、NIS および LDAP ネームサービスに含めることができません。

実行可能マップは、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 がサービス svc:/system/filesystem/autofs によって起動され、autofs がマスター auto_master マップを確認します。

autofs は、svc:/system/name-service/switch サービスの config/automount プロパティーで指定されたネームサービス順序を使用します。config/automount プロパティーが定義されていない場合は、config/default プロパティーが使用されます。NIS が選択されていて、autofs が使用できるマップを autofs が検出できないけれども、1 つまたは複数の下線を含むマップ名を検出した場合は、従来の NIS ファイル名が機能するように下線がドットに変更されます。次に autofs はもう一度マップを調べます。automount: files nis ldap というネームサービススイッチ設定の場合、マップは次の図のように検索されます。

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

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