autofs は、自動マウント操作とアンマウント操作をサポートするカーネルファイルシステムの 1 つです。自動マウントを行うために、次のコンポーネントが連動します。
autofs は自動的に適切なファイルシステムをマウントするクライアント側サービスです。自動マウントサービス (svc:/system/filesystem/autofs) は、システムが起動するときに呼び出され、マスターマップファイル auto_master を読み取って autofs マウントの初期セットを作成します。これらの autofs マウントは起動時ではなく、あとからファイルシステムがマウントされる時点に自動的にマウントされます。このようなポイントをトリガーノードと呼ぶこともあります。ナビゲーションプロセスの起動の詳細は、autofs のナビゲーションプロセス開始法を参照してください。
次の図は、autofs サービスが automount コマンドを起動する方法を示しています。
図 3 svc:/system/filesystem/autofs サービスによる automount の起動
autofs マウントが設定されると、これらのマウントはそれらに基づいたファイルシステムのマウントをトリガーできます。たとえば、autofs が、現在マウントされていないファイルシステムをアクセスする要求を受け取ると、automountd を呼び出して要求されたファイルシステムを実際にマウントさせます。
autofs マウントポイントで、ファイルシステムへのアクセスが要求された場合は、次の動作が行われます。
autofs がその要求に介入します。
autofs は要求されたファイルシステムをマウントするよう、automountd デーモンにメッセージを送信します。
automountd デーモンがマップからファイルシステム情報を見つけ、トリガーノードを作成し、マウントを実行します。
autofs は、介入した要求の実行を続行させます。
そのファイルシステムが一定期間非アクティブである場合、autofs はそのファイルシステムをアンマウントします。
最初に autofs マウントをマウントしたあとは、必要に応じて automount コマンドを使用し、autofs マウントを更新します。このコマンドは、auto_master マップにあるマウントのリストと、マウントテーブルファイル /etc/mnttab (前のバージョンでは /etc/mtab) にあるマウントされたファイルシステムのリストを比較します。その後、automount によって、適切な変更が加えられます。このプロセスにより、システム管理者は auto_master 内のマウント情報を変更し、autofs デーモンを停止したり再起動したりすることなく、それらの変更を autofs プロセスに使用させることができます。ファイルシステムがマウントされれば、以後のアクセスに automountd は不要になります。次に automountd が必要になるのは、ファイルシステムが自動的にアンマウントされたときです。
mount とは異なり、automount はマウントすべきファイルシステムのリストを調べるために /etc/vfstab ファイル (コンピュータごとに異なる) を参照しません。automount コマンドは、ドメイン内とコンピュータ上で名前空間とローカルファイルを通して制御されます。
autofs は一連のマップを検索することによって、ネットワークをナビゲートします。マップは、ネットワーク上の全ユーザーのパスワードエントリや、ネットワーク上の全ホストコンピュータの名前などの情報を含むファイルです。マップには UNIX の管理ファイルに相当するネットワーク規模の管理ファイルも含まれています。マップはローカルに使用するか、あるいは NIS や LDAP のようなネットワークネームサービスを通じて使用できます。
autofs は 3 種類のマップを使用します。
マスターマップ
直接マップ
間接マップ
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 ]
ディレクトリのフル (絶対) パス名です。このディレクトリが存在しない場合、可能ならば autofs はこのディレクトリを作成します。このディレクトリが存在し、しかも空ではない場合、マウントすることによってその内容が隠されます。この場合、autofs は警告を出します。
マウントポイントとして /- を指定すると、この特定のマップが直接マップであり、マップに関連付けられている特定のマウントポイントがないことを表します。
位置に対する指示またはマウント情報を検出するために autofs が使用するマップの名前です。この名前がスラッシュ (/) で始まる場合、autofs はこの名前をローカルファイルとして解釈します。それ以外の場合、autofs はネームサービススイッチ構成ファイル (/etc/nsswitch.conf) で指定される検索を使用してマウント情報を検索します。また、/net には、特別なマップを使用します。詳細は、/net マウントポイント を参照してください。
(オプション) map-name で指定されたエントリのマウントに適用されるオプションのコンマ区切りリスト (map-name のエントリがほかのオプションをリストしている場合を除く)。特定タイプのファイルシステムのオプションについては、そのファイルシステムの mount のマニュアルページを参照してください。NFS 固有のマウントオプションについては、mount_nfs(1M) のマニュアルページを参照してください。NFS 固有のマウントポイントの場合、bg (バックグラウンド) オプションと fg (フォアグラウンド) オプションは適用されません。
# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。
長い行を短い行に分割するには、行末にバックスラッシュ (\) を入力します。入力できる文字数の上限は 1024 です。
/home マウントポイントは、/etc/auto_home (間接マップ) にリストされたエントリがマウントされるディレクトリです。
autofs は、ホストデータベースのみを使用する特殊な組み込みマップ -hosts 内の全エントリを /net ディレクトリの下にマウントします。たとえば、hosts データベースにあるコンピュータ system1 が、そのファイルシステムをエクスポートするとします。次のコマンドを入力すると、現在のディレクトリがコンピュータ gumbo のルートディレクトリに変更されます。
# cd /net/gumbo
autofs はホスト system1 のエクスポート済みファイルシステム (つまり、ローカルディスク上のそれらのファイルシステムではなく、ネットワークユーザーが使用できるサーバー上のそれらのファイルシステム) だけをマウントできます。したがって、system1 上のすべてのファイルおよびディレクトリを /net/system1 から使用できるとは限らないこともあります。
/net を使用したアクセスでは、サーバー名はパスの中に指定されるため、位置に依存します。したがって、エクスポートされるファイルシステムを別のサーバーに移動すると、そのパスは使用できなくなります。代わりに、/net を使用するのでなく、マップ内でそのファイルシステムに対応するエントリを設定することをお勧めします。
/nfs4 マウントポイントは、擬似マップを使用して FedFS ドメインルートをマウントします。/nfs4/example.net を参照すると、ドメインルートで DNS ドメイン example.net を検索し、その場所でマウントしようとします。/nfs4 の下でパスをマウントするには、FedFS サーバー用の DNS レコードの設定 で説明されているとおり、DNS サーバーがレコードを返す必要があります。
直接マップは自動マウントポイントです。つまり、直接マップによって、クライアント上のマウントポイントとサーバー上のディレクトリが直接対応付けられます。直接マップにはフルパス名があり、明示的に関係を示します。次の例に典型的な /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
直接マップ内のマウントポイントのパス名。
この特定のマウントに適用するオプション。これらのオプションが必要なのは、マップのデフォルトと異なる場合だけです。特定タイプのファイルシステムのオプションについては、そのファイルシステムの mount のマニュアルページを参照してください。NFS 固有のマウントオプションについては、mount_nfs(1M) のマニュアルページを参照してください。
ファイルシステムの場所。NFS ファイルシステムの場合、1 つまたは複数のファイルシステムが server:pathname として指定されます。
マスターマップと同様、# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。長い行を短い行に分割するには、行の最後にバックスラッシュを入力します。
すべてのマップにおいて、直接マップ内のエントリは、/etc/vfstab 内の対応するエントリにもっともよく似ています。/etc/vfstab のエントリは、次のようになっているとします。
dancer:/usr/local - /usr/local/tmp nfs - yes ro
直接マップ内では、同じエントリが次のようになります。
/usr/local/tmp -ro dancer:/usr/local
直接 autofs マップの機能については、autofs がクライアント用のもっとも近い読み取り専用ファイルを選択する方法を参照してください。
使用例 1のマウントポイント /- は、auto_direct 内のエントリを特定のマウントポイントに関連付けないように autofs に指示します。間接マップは、auto_master ファイルに定義されたマウントポイントを使います。直接マップの場合は、名前付きマップ内で指定したマウントポイントを使用します。直接マップ内では、鍵、つまりマウントポイントはフルパス名です。
NIS の auto_master ファイルには、直接マップのエントリは 1 つしか存在できません。マウントポイントは 1 つの名前空間の中で一意の値にする必要があるためです。auto_master がローカルファイルならば、重複しないかぎり直接マップのエントリがいくつあってもかまいません。
間接マップは、鍵の置換値を使って、クライアント上のマウントポイントとサーバー上のディレクトリとの間の関連付けを確立します。間接マップは、ホームディレクトリなどの特定のファイルシステムをアクセスするのに便利です。auto_home マップは間接マップの一例です。
key [ mount-options ] location
間接マップでのスラッシュ (/) のない名前。
この特定のマウントに適用するオプション。これらのオプションが必要なのは、マップのデフォルトと異なる場合だけです。特定タイプのファイルシステムのオプションについては、そのファイルシステムの mount のマニュアルページを参照してください。たとえば、NFS 固有のマウントオプションについては、mount_nfs(1M) のマニュアルページを参照してください。
ファイルシステムの場所。1 つまたは複数のファイルシステムを server: pathname として指定します。
マスターマップと同様、# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。長い行を短い行に分割するには、行の最後にバックスラッシュ (\) を入力します。使用例 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 はこれらのコンピュータのいずれかで login や rlogin を実行し、自分のホームディレクトリを所定の場所にマウントさせることができます。
さらに、user7 はここで次のコマンドを入力することもできます。
# cd ~user1
autofs は user1 のために user7 のホームディレクトリをマウントします (すべてのアクセス権が許可する場合)。
ネームサービスのないネットワークで、Linda が自分のファイルにアクセスすることを許可するには、ネットワーク上のすべてのシステムで、すべての関連ファイル (/etc/passwd など) を変更する必要があります。NIS では、NIS マスターサーバーで変更を行い、関連するデータベースをスレーブのデータベースに伝達します。
automount コマンドはシステムの起動時にマスターマップを読み取ります。マスターマップ内の各エントリは、直接マップ名または間接マップ名、そのパス、およびそのマウントオプションです。エントリの具体的な順序は重要ではありません。
図 4 マスターマップによるナビゲーション
この図は、automount がマスターマップ内のエントリとマウントテーブル内のエントリとを比較して、現在のリストを生成することを示しています。
マウント要求がトリガーされたときに 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 サービスは次ような処理を完了します。
サーバーのマウントサービスが使用可能かどうかを確認します。
要求されたファイルシステムを、/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 オプションは使用しないでください。–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 には 1 つ以上の場所 (最初のマウントポイントには 3 つの場所、2 番目のマウントポイントには 2 つの場所) がリストされています。複製された場所のどこからマウントしてもユーザーは同じサービスを受けられます。ユーザーの書き込みまたは変更が可能ならば、その変更をロケーション全体で管理しなければならなくなるので、この手順は、読み取り専用のファイルシステムをマウントするときにだけ意味があります。あるときに、あるサーバー上のファイルを変更し、そのすぐあとに別のサーバー上で「同じ」ファイルを変更するといった作業は避けたいものです。この利点は、最善の利用可能なサーバーがユーザーの作業なしで自動的に使用されることです。
ファイルシステムを複製として構成してあると (複製されたファイルシステムとはを参照)、NFS クライアントはフェイルオーバー機能を使用できます。最適な NFS サーバーが自動的に決定されるだけでなく、そのサーバーが使用できなくなるとクライアントは自動的に 2 番目に適したサーバーを使います。
複製として構成するのに適しているファイルシステムの例は、マニュアルページです。大規模なネットワークでは、複数のサーバーがマニュアルページをエクスポートできます。どのサーバーからマニュアルページをマウントするかは、サーバーが実行中でそのファイルシステムをエクスポートしているかぎり、重要ではありません。直接マップの例では、複数のマウント場所は、マップエントリ内のマウント場所のリストとして表現されています。
/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man
この例では、サーバー oak、rose、または willow からマニュアルページをマウントできます。どのサーバーが最適であるかは、次のいくつかの要素によって決まります。
特定の NFS プロトコルレベルをサポートするサーバーの数
サーバーの近接性
重み付け
順位を決定するときには、各バージョンの NFS プロトコルをサポートしているサーバーの数が数えられます。サポートしているサーバーの数が多いプロトコルがデフォルトになります。これによって、クライアントにとっては利用できるサーバーの数が最大になります。
プロトコルが同じバージョンのサーバーの組の中で数がもっとも多いものがわかると、サーバーのリストが距離によってソートされます。近接性を判定するために、IPv4 アドレスが調査されてどのサーバーが各サブネットにあるかが判別されます。ローカルサブネット上のサーバーには、リモートサブネット上のサーバーよりも高い優先順位が付けられます。もっとも近いサーバーが優先されることにより、待ち時間とネットワークトラフィックが軽減されます。
図 5は、サーバー近接性を示しています。
図 5 サーバー近接性
ローカルサブネット上に同じプロトコルをサポートしているサーバーが複数あるときは、それぞれのサーバーに接続する時間が計測され、速いものが使用されます。重み付けを使用することで選別が影響されることもあります。重み付けの詳細は、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 サーバーが選択されます。
フェイルオーバー機能を指定していると、この優先順位はサーバーが選択されるマウント時に確認されます。複数の場所を指定しておくと、個々のサーバーが一時的にファイルシステムをエクスポートできないときに便利です。
多くのサブネットで構成される大きなネットワークでは、フェイルオーバーが特に便利です。autofs は適切なサーバーを選択して、ネットワークトラフィックをローカルネットワークのセグメントに限定することができます。サーバーが複数のネットワークインタフェースを持つ場合は、それぞれのインタフェースが別々のサーバーであるとみなして、各ネットワークインタフェースに対応付けられているホスト名を指定します。autofs はそのクライアントにいちばん近いインタフェースを選択します。
詳細は、automount(1M) のマニュアルページを参照してください。
距離のレベルが同じサーバーから 1 つを選択するために、autofs マップに重み付けの値を追加することができます。次に例を示します。
/usr/man -ro oak,rose(1),willow(2):/usr/man
括弧内の数値が重み付けを示します。重み付けのないサーバーの値はゼロであり、選択される可能性が最高になります。重み付けの値が大きいほど、そのサーバーが選択される可能性は低くなります。
名前の前にドル記号 ($) を付けることによって、クライアント固有の変数を作成できます。変数は、ファイルシステム内の同じ場所に異なるタイプのアーキテクチャーがアクセスできるようにするのに役立ちます。変数名を括弧でくくることで、その後に続く文字や数字と変数とを区切ることができます。次の表は、定義済みマップ変数を示しています。
|
鍵として使用する場合を除いて、変数はエントリ行内のどこにでも使用できます。たとえば、/usr/local/bin/sparc から SPARC アーキテクチャー、/usr/local/bin/x86 から x86 アーキテクチャーのバイナリをそれぞれエクスポートするファイルサーバーがあるとします。クライアントは、次のようなマップエントリを使ってマウントすることができます。
/usr/local/bin -ro server:/usr/local/bin/$CPU
これですべてのクライアントの同じエントリがすべてのアーキテクチャーに適用されます。
ファイルマップ内のマップエントリ内のマップ名で使用される特殊文字は、マップ名の処理方法に影響します。
マップエントリ +mapname がファイルマップで使用されている場合、automount は指定されたマップが現在のファイルに含まれていかのように読み取ります。
mapname の前にスラッシュがない場合、autofs はそのマップ名を文字列として扱い、ネームサービススイッチ方式を使用してマップ名を検出します。パス名が絶対パス名の場合、automount はその名前のローカルマップを検索します。
マップ名がダッシュ (-) で始まる場合、automount は hosts などの適切な組み込みマップを参照します。
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
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 がサービス 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 によるネームサービスの使用
このセッションでは、画面は次の例のようになります。
$ 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 は、使用するネームサービスとは無関係に、スラッシュ (/) で始まるマップ名をローカルとして解釈します。