test

NFS の管理

パート III autofs の詳細

パートIII、autofs サービスと autofs を使う手順について説明します。

第 4 章 autofs の管理

この章では、autofs 管理タスクの実行方法について説明します。具体的には、オートマウンタマップの変更、オートマウンタから非 NFS タイプのデバイスに対するアクセス、マップの設定などです。

autofs の設定

この節では、autofs サービスの起動および停止の手順について説明します。

オートマウンタを起動する方法

    リブートせずにデーモンを起動するには、スーパーユーザになって次のコマンドを入力します。 


# /etc/init.d/autofs start

これでデーモンが起動します。

オートマウンタを停止する方法

    リブートせずにデーモンを停止するには、スーパーユーザになって次のコマンドを入力します。 


# /etc/init.d/autofs stop

一般的な作業と手順

この節では、ユーザの環境で遭遇する可能性のある最も一般的な問題について、そのいくつかを説明します。クライアントのニーズに最適な autofs を構成する際に役立つよう、各問題ごとに推奨する解決策を記載しています。

注 -

この節で説明されている作業を実行するには、Solstice システム管理ツールを使用するか、または『Solaris ネーミングの管理』を参照してください。

マップを含む管理作業

次のリストは、autofs 環境を変更するために実行する必要が生じる可能性のある、マップに関する各種の管理作業です。

表 4-1 autofs のマップの種類とその使用方法

マップの種類 

使用方法 

マスタ

ディレクトリとマップを対応付ける 

直接

autofs を特定のファイルシステムに割り当てる 

間接

autofs を参照だけを行うファイルシステムに割り当てる 

ネームサービスを基にして、ユーザの autofs 環境を変更する方法を表 4-2 に示します。

表 4-2 マップ管理

ユーザのネームサービス 

変更用のツール 

ローカルファイル 

テキストエディタ 

NIS 

make ファイル

NIS+ 

nistbladm

表 4-3 は、変更後に automount コマンドを実行すべきかどうかを、変更したマップの種類別に示しています。たとえば、直接マップに追加または削除を行なった場合には、その変更を反映させるためにローカルシステムで automount コマンドを実行する必要があります。しかし、既存のエントリに変更を行なった場合には、automount コマンドを実行してその変更を反映させる必要はありません。

表 4-3 automount コマンド実行タイミング

マップの種類 

automountを再起動する ?

 

追加または削除 

既存のエントリを変更 

auto_master

実行する

実行する

direct

実行する

実行しない

indirect

実行しない

実行しない

マップの変更

以下の手順では、ネームサービスとして NIS+ を使っていることが前提です。

マスタマップを変更する

  1. nistbladm コマンドを使って、マスタマップに必要な変更をします。

    『Solaris ネーミングの管理』を参照してください。

  2. 各クライアントに対して、プロンプトで su を入力し、スーパーユーザのパスワードを入力してスーパーユーザになります。

  3. 各クライアントに対して、automount コマンドを実行して、行った変更を確実に有効にします。

  4. ユーザに変更を通知します。

    ユーザでも自分のコンピュータ上でスーパーユーザとして automount コマンドを実行できることを通知してください。

automount コマンドが実行されると、マスタマップを参照します。

間接マップを変更する

    nistbladm コマンドを使用して、間接マップへの変更を行います。

    『Solaris ネーミングの管理』を参照してください。

次にこのマップが使用されると、マウントが行われ、変更内容が有効となります。

直接マップを変更する

  1. nistbladm コマンドを使用して、直接マップへの変更を追加または削除します。

    『Solaris ネーミングの管理』を参照してください。

  2. 手順 1 でマウントポイントエントリを追加または削除した場合、automount コマンドを実行します。

  3. ユーザに変更を通知します。

    ユーザでも自分のコンピュータ上でスーパーユーザとして automount コマンドを実行できることを、通知してください。

    注 -

    既存の直接マップエントリの内容を変更しただけの場合、automount コマンドを実行する必要はありません。

    たとえば、マップ auto_direct を変更し、ディレクトリ /usr/src は異なるサーバからマウントされると仮定します。このとき /usr/src がマウントされていない場合、ユーザが /usr/src をアクセスしようとすると、この新しいエントリはすぐに有効となります。/usr/src が現在マウントされている場合、自動アンマウントが行われるまで待ってから、アクセスすることができます。

    注 -

    これらの余分な手順が必要な上、間接マップではマウントテーブル内で直接マップほどのメモリ領域を占有しないため、できるだけ間接マップを使用してください。間接マップは作成が簡単で、コンピュータファイルシステムに関する条件も直接マップほど厳しくありません。

マウントポイント衝突の回避

ローカルディスクパーティションを /src にマウントし、しかも autofs サービスを使用して他のソースディレクトリもマウントしたい場合、問題が発生することがあります。ユーザがマウントポイント /src を指定した場合、ユーザがローカルパーティションを参照しようとすると、autofs サービスがこれを隠します。

このパーティションをどこか他 (たとえば、/export/src) にマウントする必要があります。すると、たとえば、/etc/vfstab 内には次のようなエントリが必要となります。


/dev/dsk/d0t3d0s5 /dev/rdsk/c0t3d0s5 /export/src ufs 3 yes -

そして、auto_src 内のエントリは次のようになります。


terra		terra:/export/src

terra はコンピュータの名前です。

NFS 以外のファイルシステムへのアクセス

autofs は、NFS ファイル以外のファイルもマウントできます。autofs は、ファイルをフロッピーディスクや CD-ROM などの取り外し可能メディア上にマウントします。通常は、ボリュームマネージャ機能を使って取り外し可能メディアにファイルをマウントします。以下の例では、autofs を使ってこのマウント操作をどのように行うかを示しています。ボリュームマネージャ機能と autofs とは併用できないので、通常はまずボリュームマネージャを無効にしてから、これらのエントリを使用することになります。

サーバからファイルシステムをマウントするのではなく、ユーザがメディアをドライブにセットして、それをマップから参照します。autofs を使っているときに、NFS 以外のファイルシステムをアクセスしたい場合は、次の手順を参照してください。

autofs を使って CD-ROM アプリケーションにアクセスする

注 -

ボリュームマネージャを使わない場合は、この手順に従ってください。

    次のように CD-ROM ファイルシステムの種類を指定してください。


    hsfs -fstype=hsfs,ro :/dev/sr0

    マウントする CD-ROM 装置の名前には、先頭にコロンを付けてください。

autofs を使って PC-DOS データのフロッピーディスクにアクセスする

注 -

ボリュームマネージャを使わない場合は、この手順に従ってください。

    フロッピーファイルシステムタイプを次のように指定します。 


     pcfs -fstype=pcfs :/dev/diskette

CacheFS による NFS ファイルシステムへのアクセス

キャッシュファイルシステム (CacheFS) は、小型で高速なローカルディスクを使用することによって、特定のファイルシステムの性能を向上させるための、汎用の不揮発性キャッシュ機能です。

CacheFS を使用して、NFS ファイルシステムからのデータをローカルディスク上に保存することによって、NFS 環境の性能を改善できます。

CacheFS を使って NFS ファイルシステムにアクセスする

  1. cfsadmin コマンドを実行してローカルディスク上にキャッシュディレクトリを作成します。 


    # cfsadmin -c /var/cache

  2. オートマウンタマップに cachefs エントリを追加します。

    たとえば、マスタマップに次のエントリを追加すると、すべてのホームディレクトリがキャッシュされます。 


    /home auto_home -fstype=cachefs,cachedir=/var/cache,backfstype=nfs

    次のエントリを auto_home マップに追加すると、rich という名前のユーザのホームディレクトリだけがキャッシュされます。


    rich  -fstype=cachefs,cachedir=/var/cache,backfstype=nfs  dragon:/export/home1/rich
    注 -

    マップに指定されたオプションは、後から見つかったものがそれより前に見つかったものよりも優先されます。つまり、最後のオプションが使用されます。上の例の auto_home マップに追加する個別のエントリで、オプションの一部を変更する場合に指定する必要があるのは、マスタマップに指定されているオプションだけです。

オートマウンタのカスタマイズ

オートマウンタマップを設定する方法はいくつかあります。以下のタスクでは、使いやすいディレクトリを作成するためにオートマウンタマップをカスタマイズする方法を説明します。

/home ディレクトリ構造を共通にする

ネットワークユーザにとって望ましいのは、自分や他人のホームディレクトリが /home の下に存在していることです。この /home 以下のディレクトリは、クライアントであれサーバであれすべてのコンピュータで共通になるようにしてください。

Solaris ソフトウェアをインストールすると、マスタマップ /etc/auto_master が設定されます。 


# Master map for autofs
#
+auto_master
/net		-hosts		-nosuid,nobrowse
/home		auto_home	-nobrowse
/xfn		-xfn

auto_home 用のマップも、/etc の下に設定されます。 


# Home directory map for autofs
#
+auto_home

外部の auto_home マップへの参照を除けば、このマップは空です。/home の下にあるディレクトリをすべてのコンピュータに共通とする場合、この /etc/auto_home マップを変更しないでください。すべてのホームディレクトリエントリは、NIS または NIS+ のネームサービスマップに登録されていなければなりません。

注 -

制限がなければ、どんなユーザでも任意のコンピュータ上でスーパーユーザ特権を持つことができるため、ユーザが自分のホームディレクトリから実行可能ファイル set uid を実行することを許可しないでください。

複数のホームディレクトリファイルシステムを持つ /home を設定する

  1. /export/home の下にホームディレクトリパーティションをインストールします。

    複数のパーティションがある場合、それらを別個のディレクトリ、たとえば /export/home1、/export/home2 などの下にインストールします。

  2. Solstice System Management Tools を使用して auto_home マップの作成と管理を行います。

    新規のユーザアカウントを作成するときには、ユーザのホームディレクトリの位置を auto_home マップに入力します。マップエントリは、たとえば次のように簡単な形式になっています。

    rusty     dragon:/export/home1/&
gwenda    dragon:/export/home1/&
charles   sundog:/export/home2/&
rich      dragon:/export/home3/&

    アンパサンド「&」を使用してマップキーを置換することに注意してください。これは次の例での rusty を 2 回入力する場合の省略表記です。


    rusty 	dragon:/export/home1/rusty

auto_home マップを適切な場所に配置することによって、ユーザはパス /home/user で任意のホームディレクトリ (自分のものを含む) を参照できます。ここで、user はユーザのログイン名で、マップのキーでもあります。他のユーザのコンピュータにログインするとき、全ホームディレクトリが共通の構造になっていると便利です。autofs は、そこにユーザのホームディレクトリをマウントします。同様に、リモートのウィンドウクライアントを他のコンピュータ上で実行する場合、そのクライアントプログラムは、ユーザがウィンドウ表示を提供するコンピュータ上で持つのと同じ /home ディレクトリの構造を持っています。

この共通の構造は、サーバにも影響します。上の例を使用し、rusty がサーバ dragon にログインした場合、autofs は、/export/home1/rusty を /home/rusty にループバックマウントすることによって、ローカルディスクへの直接アクセスを可能にします。

ユーザは、自分のホームディレクトリの実際の位置を知る必要がありません。rusty がより多くのディスク空き容量を必要とし、自分のホームディレクトリを他のサーバに再配置する必要がある場合、この新しい位置を反映するためには、auto_home マップ内の rusty のエントリを変更するだけですみます。すべてのユーザがパス /home/rusty を継続して使用できます。

プロジェクト関連ファイルの統合方法 (/ws ディレクトリ構造)

あなたが大規模なソフトウェア開発プロジェクトの管理者だとします。プロジェクトに関連するすべてのファイルを /ws (Work Space の略) と呼ばれるディレクトリの下で使用できるようにしたいとします。このディレクトリは、そのサイトのすべてのワークステーション間で共通となります。

  1. /ws ディレクトリ用のエントリを、NIS または NIS+ のサイトの auto_master マップに追加します。


    /ws auto_ws -nosuid

    auto_ws マップによって、/ws ディレクトリの内容が決まります。

  2. 用心のため、-nosuid オプションを追加します。

    このオプションを指定すると、ユーザは、ワークスペースに存在する setuid を実行できなくなります。

  3. auto_ws マップにエントリを追加します。

    この auto_ws マップは、各エントリがサブプロジェクトを指定するように作成されます。最初の試みによって、次のようなマップが得られます。

    compiler    alpha:/export/ws/&
windows     alpha:/export/ws/&
files       bravo:/export/ws/&
drivers	    alpha:/export/ws/&
man         bravo:/export/ws/&
tools       delta:/export/ws/&

    各エントリの最後にあるアンパサンド (&) は、エントリキーの単なる省略です。たとえば、最初のエントリは次のものと等しくなります。


    compiler		alpha:/export/ws/compiler

    この段階で得られるマップは単純で、まだ不十分なものです。プロジェクト責任者は、man エントリ内のドキュメントを各サブプロジェクトの下にあるサブディレクトリとして提供することを決定します。また各サブプロジェクトは、複数バージョンのソフトウェアを指定するためにサブディレクトリを必要とします。これらのサブディレクトリは、それぞれサーバ上のディスクパーティション全体に割り当てられなければなりません。

    マップ内のエントリを次のように変更します。


    compiler ¥
    /vers1.0    alpha:/export/ws/&/vers1.0 ¥
    /vers2.0    bravo:/export/ws/&/vers2.0 ¥
    /man        bravo:/export/ws/&/man
windows ¥
    /vers1.0    alpha:/export/ws/&/vers1.0 ¥
    /man        bravo:/export/ws/&/man
files ¥
    /vers1.0    alpha:/export/ws/&/vers1.0 ¥
    /vers2.0    bravo:/export/ws/&/vers2.0 ¥
    /vers3.0    bravo:/export/ws/&/vers3.0 ¥
    /man        bravo:/export/ws/&/man
drivers ¥
    /vers1.0    alpha:/export/ws/&/vers1.0 ¥
    /man        bravo:/export/ws/&/man
tools ¥
    /           delta:/export/ws/&

マップはとても大きくなったように見えますが、それでも 5 つのエントリが含まれているだけです。各エントリには多重マウントが含まれるため、大きくなっています。たとえば /ws/compiler への参照には、vers1.0、vers2.0、および man ディレクトリ用の 3 つのマウントが必要です。各行の最後にあるバックスラッシュは、エントリが次の行に続いていることを示します。このエントリは 1 行なのですが、行ブレークとインデントを使用して読み易くなっています。tools ディレクトリには全サブプロジェクト用のソフトウェア開発支援ツールが収められているため、これは同じサブディレクトリ構造になっていません。tools ディレクトリは依然として単一のマウントです。

この配置によって、管理者には高い柔軟性が与えられます。ソフトウェアプロジェクトは、大量のディスク領域を消費することが知られています。このプロジェクトの有効期間中には、さまざまなディスクパーティションの再配置と拡張が要求されます。これらの変更内容が auto_ws マップに反映される限り、/ws のもとのディレクトリ階層は変更されないため、ユーザに通知する必要はありません。

サーバ alpha と bravo は同じ autofs マップを参照するため、これらのコンピュータにログインしたユーザは、予想通りの名前空間 /ws を見ることになります。これらのユーザには、NFS マウントの代わりにループバックマウントを通じて、ローカルファイルへの直接アクセスが提供されます。

さまざまなアーキテクチャによる共有名前空間へのアクセスを設定する方法

ローカルの実行可能ファイル、また、表計算ツールやワードプロセッシングのパッケージなどのアプリケーション用に、共有名前空間を 1 つにまとめる必要があります。この名前空間のクライアントは、異なる実行可能形式を必要とするさまざまなワークステーションアーキテクチャを使用します。また、一部のワークステーションはオペレーティングシステムの異なるバージョンを実行しています。

  1. nistbladm コマンドを使用して auto_local マップを作成します。

    『Solaris ネーミングの管理』を参照してください。

  2. 共有名前空間に対して 1 つのサイト名を選択し、この空間に属するファイルとディレクトリを容易に識別できるようにします。

    たとえば、この名前として /usr/local を選択した場合、/usr/local/bin というパスは、明らかにこの名前空間の一部となります。

  3. ユーザを簡単に認識できるよう、autofs の間接マップを作成して、/usr/local にマウントします。NIS+ (または NIS) の auto_master マップ内に次のエントリを設定します。


    /usr/local      auto_local      -ro

    なお、マウントオプション ro は、クライアントがどのファイルやディレクトリにも書き込みできないことを意味します。

  4. 適切なディレクトリをサーバ上にエクスポートします。

  5. bin のエントリを auto_local マップに作成します。

    ディレクトリ構造は次のようになります。 


     bin      aa:/export/local/bin

    異なるアーキテクチャのクライアントに対応するというニーズを満足するため、この bin ディレクトリに対する参照は、クライアントのアーキテクチャタイプに応じて、サーバ上の異なるディレクトリに対して行う必要があります。

  6. 異なるアーキテクチャのクライアントに対応するため、autofs の「CPU」変数を追加することによって、エントリを変更します。


    bin      aa:/export/local/bin/$CPU
    注 -

    SPARCstationTM クライアントの場合は、実行可能ファイルはサーバ上の /export/local/bin/sparc のもとで使用できるようにしてください。x86 クライアントの場合、/export/local/bin/i386 です。

互換性のないクライアントオペレーティングシステムをサポートする

  1. クライアントのオペレーティングシステムタイプを判定する変数を、アーキテクチャタイプに結合します。

    autofs の「OSREL」変数を CPU 変数と結合することによって、CPU タイプと OS リリースの両方を決める名前を作成することができます。

  2. 次のマップエントリを作成します。 


    bin     aa:/export/local/bin/$CPU$OSREL

バージョン 5.6 のオペレーティングシステムを実行している SPARC クライアントの場合、サーバから /export/local/bin/sparc5.6 をエクスポートし、同様に他のリリースもエクスポートする必要があります。オペレーティングシステムは実行可能形式での下方互換性を維持しようとするため、OS のリリースについては問題ないと想定し、このあとの例では、OS のリリースによる区別は省略します。

これまで、1 つのサーバ「aa」用のエントリを設定しました。大規模ネットワークでは、これらの共有ファイルを複数のサーバ間で複写したいという要望があります。NFS のトラフィックがローカルネットワークセグメントに限定されるよう、各サーバは、サービスを提供するクライアントに近いネットワークにある必要があります。

複数のサーバ間で共有ファイルを複写する

複製された読み取り専用のファイルシステムを共有する最良の方法は、障害時回避機能を使うことです。障害時回避機能については、「クライアント側障害時回避機能」 を参照してください

    エントリを変更して、次のようにすべての複製サーバのリストをカンマで区切って作成します。 


bin     aa,bb,cc,dd:/export/local/bin/$CPU

autofs は最も近いサーバを選択します。サーバに複数のネットワークインタフェースがある場合、各インタフェースを指定します。autofs はクライアントに最も近いインタフェースを選択し、NFS トラフィックの不必要な経路指定を回避します。

セキュリティを適用する

    NIS または NIS+ のネームサービス auto_master ファイル内に、次のエントリを作成します。 


	/home     auto_home     -nosuid

nosuid オプションが指定されていると、ファイルを作成するときに setuid ビットも setgid ビットも設定することができません。

このエントリは、ローカル /etc/auto_master ファイル内の /home エントリを無効にします (前の例を参照)。その理由は、外部ネームサービスマップへの +auto_master 参照がこのファイルの /home エントリよりも前に行われるためです。auto_home マップのエントリにマウントオプションが指定されている場合、nosuid オプションは上書きされます。したがって、auto_home マップではオプションを一切使わないか、各エントリに nosuid オプションを指定します。

注 -

サーバ上の /home の上またはその下に、ホームディレクトリのディスクパーティションをマウントしないでください。

autofs で公共ファイルハンドルを使う方法

    次のようなエントリを作成します。 


    /usr/local     -ro,public    bee:/export/share/local

    public オプションによって、公共ファイルハンドルが使用されます。NFS サーバが公共ファイルハンドルをサポートしていないと、マウントは失敗します。

autofs で NFS URL を使う方法

    次のようなエントリを作成します。 


    /usr/local     -ro    nfs://bee/export/share/local

    autofs は NFS サーバ上の公共ファイルハンドルを使おうとしますが、サーバが公共ファイルハンドルをサポートしていないと、MOUNT プロトコルが使用されます。

autofs の表示機能の無効化

Solaris 2.6 およびその互換バージョンでインストールされる /etc/auto_master では、/home と /net のエントリに -nobrowse オプションが追加されています。また、/etc/auto_master の中の /home と /net のエントリが変更されていなければ、アップグレードによってこれらのエントリに -nobrowse オプションが追加されます。しかし、これらの変更を手動で行なったり、各サイトの autofs マウントポイントの表示機能を無効にしなければならないこともあります。

表示機能を無効にする方法はいくつかあります。1 つは automountd に対してコマンド行オプションを使用して無効にする方法です。この場合、クライアントに対する autofs の表示機能は完全に無効になります。もう 1 つは、NIS または NIS+ 名前空間の autofs マップを使っているクライアントすべてに対して、またはネットワーク全体で使用している名前空間がない場合にはローカルの autofs マップを使っている各クライアントごとに、マップエントリで表示機能を無効にする方法です。

単一の NFS クライアントに対して autofs の表示機能を完全に無効にする方法

  1. 起動スクリプトに -n オプションを追加します。

    スーパーユーザになって /etc/init.d/autofs スクリプトを編集して、automountd デーモンを起動している行に -n オプションを追加します。


    	/usr/lib/autofs/automountd -n ¥
		< /dev/null > /dev/console 2>&1	# start daemon

  2. autofs サービスを再起動します。 


    # /etc/init.d/autofs stop
# /usr/init.d/autofs start

すべてのクライアントに対して autofs の表示機能を無効にする

すべてのクライアントに対して表示機能を無効にするには、NIS や NIS+ といったネームサービスを使用している必要があります。使用していない場合は、クライアントごとにオートマウンタマップを手動で編集する必要があります。この例では、/home ディレクトリの表示機能を無効にします。この手順を、無効にする間接 autofs ノードそれぞれについて実行します。

  1. ネームサービスの auto_master ファイルにある /home エントリに対して、-nobrowse オプションを追加します。 


    /home     auto_home     -nobrowse

  2. すべてのクライアントで、automount コマンドを実行します。

    変更は、このクライアントで automount コマンドを実行するかクライアントをリブートすると反映されます。


    # /usr/sbin/automount

1 台の NFS クライアントに対して autofs の表示機能を無効にする

この例では、/net ディレクトリの表示機能を無効にします。同様の手順は、/home などの autofs マウントポイントにも適用できます。

  1. /etc/nsswitch.conf の automount エントリを調べます。

    ローカルファイルエントリを優先させるためには、ネームサービスの切り替えファイルでネームサービスより前に files を指定します。たとえば次のようにします。


    automount: files nisplus

    これは、Solaris をインストールしたときのデフォルト設定です。

  2. /etc/auto_master の中で +auto_home エントリの位置を確認します。

    ローカルファイルへの追加を名前空間のエントリよりも優先させるために、+auto_master エントリを /net よりも下の位置に移動します。


    # Master map for automounter
#
/net	-hosts	-nosuid
/home	auto_home
/xfn	-xfn
+auto_master
    標準の設定では、+auto_master エントリはファイルの先頭に置かれます。そのため、ローカルの変更は一切できません。

  3. -nobrowse オプションを /etc/auto_master ファイルの /net エントリに追加します。


    /net     -hosts     -nosuid,nobrowse

  4. すべてのクライアントで、automount コマンドを実行します。

    変更は、このクライアントで automount コマンドを実行するかクライアントをリブートすると反映されます。


    # /usr/sbin/automount

autofs での問題発生時の対処

autofs を使用していて問題が発生することもあります。この節の目的は、問題解決のプロセスを容易にすることです。これは 2 つの節に分かれています。

この節では、autofs が生成するエラーメッセージのリストを提供します。このリストは 2 つの部分に分かれています。

それぞれのエラーメッセージには説明が続き、考えられる原因を示します。

問題を解決する際は、詳細 (-v) オプションを使って起動してください。そうしないと、問題が発生しても原因がわからない可能性があります。

以下では Autofs で問題が発生したときに表示される可能性のあるエラーメッセージを取り上げ、問題の内容について説明します。

自動マウンタで生成されるエラーメッセージ


bad key key in direct map mapname

直接マップの走査中、autofs は「/」が付いていないエントリキーを検出しました。直接マップ内のキーはフルパス名でなければなりません。


bad key key in indirect map mapname

間接マップの走査中、autofs が「/」を含むエントリキーを検出しました。間接マップのキーは、パス名ではなく、単純な名前でなければなりません。


can't mount server:pathname: reason

サーバ上のマウントデーモンが、server:pathname 用のファイルハンドル提供を拒否しています。サーバ上のエクスポートテーブルをチェックしてください。


couldn't create mount point mountpoint: reason

マウントに必要なマウントポイントを autofs が作成できませんでした。このメッセージが最もよく表示されるのは、サーバのエクスポートされたファイルシステムをすべて階層的にマウントしようとしたときです。必要なマウントポイントが、マウントできない (エクスポートできない) ファイルシステムにだけ存在する可能性があります。しかもエクスポートされた親ファイルシステムが読み取り専用でエクスポートされているため、これを作成できません。


leading space in map entry entry text in mapname

autofs は、先頭にスペースが含まれるエントリを自動マウントマップ内に発見しました。これは通常、たとえば次のように誤って続けて入力したマップエントリが原因です。


fake
/blat 		frobz:/usr/frotz

上の例では、最初の行はバックスラッシュ (¥) で終了しなければならないため、autofs が 2 番目の行を検出したとき、この警告が生成されます。


mapname: Not found

必要なマップを検出できません。このメッセージは、-v オプションが指定された場合にだけ出力されます。マップ名のスペルとパス名をチェックしてください。


remount server:pathname on mountpoint: server not responding

autofs は、以前にアンマウントしたファイルシステムの再マウントに失敗しました。このメッセージは、ファイルシステムが正常に再マウントされるまで、一定間隔ごとに表示されます。


WARNING: mountpoint already mounted on

autofs は既存のマウントポイントの上にマウントしようとしています。これは、autofs に内部エラー (異常) があることを意味しています。

一般的なエラーメッセージ


dir mountpoint must start with `/'

自動マウンタのマウントポイントはフルパス名で指定しなければなりません。マウントポイントのスペルとパス名をチェックしてください。


hierarchical mountpoints: pathname1 and pathname2

autofs では、マウントポイントが階層関係を持つことはできません。つまり、オートマウンタのマウントポイントが、他のオートマウントされたファイルシステム内に含まれてはいけません。


host server not responding

autofs は server に対して通信を試みましたが、応答を受信しませんでした。


hostname: exports: rpc_err

hostname からのエクスポートリストの獲得エラー。これはサーバまたはネットワークのトラブルを示します。


map mapname, key key: bad

マップエントリの形式が誤っており、autofs はこれを解釈できません。エントリを再チェックしてください。おそらく、この中にエスケープを必要とする文字があります。


mapname: nis_err

NIS マップ内のエントリを検索する際のエラー。NIS のトラブルの可能性あり。


mount of server:pathname on mountpoint:reason

autofs はマウントの実行に失敗しました。これはサーバまたはネットワークのトラブルを意味します。


mountpoint: Not a directory

autofs は、マウントポイントがディレクトリではないため、これにそれ自身をマウントできません。マウントポイントのスペルとパス名をチェックしてください。


nfscast: cannot send packet: reason

autofs は、複写されたファイルシステム位置のリストにあるサーバに対して、問い合わせパケットを送信できません。


nfscast: cannot receive reply: reason

autofs は、複写されたファイルシステム位置のリストにあるどのサーバからも応答を受信できません。


nfscast:select: reason

これらのエラーメッセージは、複写されたファイルシステム用のサーバに対し ping を実行しようとしていることを示します。ネットワークに問題がある可能性があります。


pathconf: no info for server:pathname

autofs は、pathname 用の pathconf を獲得できませんでした。


pathconf: server: server not responding

autofs は、(POSIX) pathconf() 情報を提供するサーバ上のマウントデーモンと通信できません。

autofs に関するその他のエラー

/etc/auto* ファイルに実行ビットセットがある場合、自動マウンタはマップを実行しようとして、次のようなメッセージを作成します。

/etc/auto_home: +auto_home: not found

この場合、auto_home ファイルには間違ったパーミッションが入ることになります。ファイルの各エントリはほぼ上記のようなエラーメッセージを生成します。以下のコマンドを入力して、ファイルへのパーミッションをリセットする必要があります。


# chmod 644 /etc/auto_home

第 5 章 autofs について

この章では、autofs サービスの構成要素と autofs マップの詳細について説明します。

autofs プログラム

autofs サービスをサポートするプログラムには、automount と automountd の 2 つがあります。どちらもシステムを起動すると実行されますが、常駐するのは automountd だけです。

automount

このコマンドは autofs マウントポイントをインストールし、オートマスタファイルの情報を各マウントポイントと関連づけます。コマンドの構文は次のようになります。

automount [ -t duration ] [ -v ]

-t duration にはファイルシステムがマウントされたままの時間を秒単位で指定し、-v を指定すると詳細表示モードになります。詳細表示モードでこのコマンドを実行すると、問題の解決が容易になります。

特定の値を指定しないと、-t duration は 5 分に設定されます。ほとんどの状況ではこの値で大丈夫ですが、多くのファイルシステムを自動マウントしているシステムでは、この間隔を延ばす必要もでてきます。特にサーバに多くのアクティブユーザがいる場合、自動マウントしたファイルシステムを 5 分毎にチェックするのは効率が悪くなる恐れがあります。autofs ファイルシステムを 1800秒 (30 分) 毎にチェックさせた方がより最適です。ファイルシステムを 5 分毎にアンマウントさせないことで、df によってチェックされる /etc/mnttab が非常に大きくなることもあります。-F オプション (df(1M) のマニュアルページ参照) を使用して df からの出力をフィルタ処理するか、egrep を使用すればこの問題を解決するのに役立ちます。

もう一つ考慮すべき点としては、間隔を変更することで、マップに対する変更内容をどれだけ迅速に反映させるかも変更になることが挙げられます。変更は、ファイルシステムがアンマウントされるまでは無効です。オートマウンタマップの変更方法については、「マップの変更」 を参照してください。

automountd

このデーモンは autofs サービスからのマウントとアンマウント要求を処理します。コマンドの構文は次のようになります。

automountd [ -Tnv ] [ -D name=value ]

-T を指定すると、RPC コールがすべて標準出力に表示されます。-n を指定すると、すべての autofs ノードで表示機能が無効になります。-v を指定すると、コンソールへのすべてのステータスメッセージが記録されます。-D name=value を使うと、name で表された自動マウントマップの値の代わりに value が使われます。自動マウントマップのデフォルト値は /etc/auto_master です。-T オプションは障害追跡のために使います。

autofs マップ

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

mount-point はディレクトリのフル (絶対) パス名です。このディレクトリが存在しない場合、可能ならば autofs はこれを作成します。このディレクトリが存在し、しかも空ではない場合、マウントすることによってその内容が隠されます。この場合、autofs は警告を出します。

マウントポイントとして /- を指定すると、マップが直接マップであり、このマップ全体に関連付けられている特定のマウントポイントがないことを表します。

map-name

map-name 名は、位置に対する指示またはマウント情報を検出するために、autofs が使用するマップです。この名前がスラッシュ (/) で始まる場合、autofs はこの名前をローカルファイルとして解釈します。そうでない場合、autofs はネームサービススイッチ構成ファイルで指定される検索によりマウント情報を検索します。/net と /xfn に対して使われる特殊なマップもあります (「マウントポイント /net」 と「マウントポイント /xfn」 を参照してください)。

mount-options

mount-options は、オプションです。map-name のエントリに他のオプションがある場合を除き、map-name で指定されたエントリのマウントに適用されるオプションをカンマで区切って並べます。これらのマウントオプションは、標準の NFS マウント用のものと同じですが、bg (バックグラウンド) と fg (フォアグラウンド) は使用できません。「mount」 を参照してください。具体的なファイルシステムごとのオプションについては、そのファイルシステムのマニュアルページで「mount」を参照してください (たとえば NFS 固有のマウントオプションについては、mount_nfs(1M))。NFS 固有のマウントポイントの場合、bg (バックグラウンド) オプションと fg (フォアグラウンド) オプションは適用されません。

# で始まる行はコメント行です。この場合、その行の最後まですべて無視されます。

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

マウントポイント /home

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

注 -

autofs はすべてのコンピュータで動作し、デフォルトでは /net と /home (自動マウントされるホームディレクトリ) をサポートします。このデフォルトは、NIS ならば auto.master マップ、NIS+ ならば auto_master テーブルを使って、またはローカルの /etc/auto_master ファイルを編集することによって変更できます。

マウントポイント /net

autofs は、特別のマップ -hosts 内の全エントリをディレクトリ /net の下にマウントします。これは hosts データベースだけを使用する組み込みマップです。たとえば、コンピュータ gumbo が hosts データベース内にあり、しかもそのファイルシステムのどれかをエクスポートする場合、次のコマンドによって、カレントディレクトリがコンピュータ gumbo のルートディレクトリに変更されます。 


%cd /net/gumbo

なお、autofs はホスト gumbo のエクスポートされたファイルシステムだけをマウントできます。つまり、ローカルディスク上のファイルシステムではなく、ネットワークユーザが使用できるサーバ上のファイルシステムです。したがって、gumbo にあるすべてのファイルとディレクトリは、/net/gumbo では利用できない場合があります。

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

注 -

autofs はマウント時だけサーバのエクスポートリストを調べます。サーバのファイルシステムが一度マウントされると、そのファイルシステムがアンマウントされ、次にマウントされるまで autofs はそのサーバをチェックしません。したがって、新たにエクスポートされたファイルシステムは、それがサーバからアンマウントされ、再度マウントされるまでは見えません。

マウントポイント /xfn

このマウントポイントは、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

key は直接マップでのマウントポイントのパス名です。

mount-options

mount-options は、このマウントに適用したいオプションです。これらのオプションは、マップのデフォルトと異なる場合だけ必要です。各ファイルシステムの種類ごとのオプションについては、そのファイルシステムのマニュアルページで「mount」を参照してください (たとえば CacheFS に固有のマウント操作については、マニュアルページの mount_cachefs(1M) を参照してください)。

location

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

key は間接マップでの単純名 (スラッシュなし) です。

mount-options

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

location

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 は、自動的に適切なファイルシステムをマウントするためのクライアント側のサービスです。クライアントが現在マウントされていないファイルシステムをアクセスしようとすると、autofs ファイルシステムはその要求に介入し、automountd を呼び出して要求されたディレクトリをマウントします。automountd はディレクトリを検索してマウントし、応答します。応答を受け取ると、autofs は待たせてあった要求の処理を続行させます。それ以降のそのマウントへの参照は 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 のマウントポイントをインストールします。

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

Graphic

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

autofs のマウントポイントにおいてファイルシステムへのアクセス要求が出された場合、autofs は次のように機能します。

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

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

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

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

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

注 -

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

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

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

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

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

図 5-2 マスタマップによる探索

Graphic

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

これは、サーバをコンマで区切ったリストにし、その後にコロンとパス名を指定することによって入力することもできます (複製されるサーバすべてでパス名が同じ場合に限ります)。 


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

これで、サーバ oak、rose、willow のどれからでもマニュアルページをマウントできます。どのサーバが最適であるかは、いくつかの要素によって決まります。具体的には、ある特定の NFS プロトコルレベルをサポートしているサーバの数、サーバのとの距離、重み付けです。

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

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

図 5-3 サーバとの距離

Graphic

ローカルサブネット上に同じプロトコルをサポートしているサーバが複数あるときは、それぞれのサーバに接続する時間が計測され、速いものが使われます。優先順位には、重み付けも関係します (「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

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

注 -

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

マップエントリ内の変数

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

表 5-2 定義済みのマップ変数

変数 

意味 

情報提供元 

例 

ARCH

アーキテクチャタイプ 

uname -m

sun4

CPU

プロセッサタイプ 

uname -p

sparc

HOST

ホスト名 

uname -n

dinky

OSNAME

オペレーティングシステム名 

uname -s

SunOS

OSREL

オペレーティングシステムのリリース 

uname -r

5.4

OSVERS

オペレーティングシステムのバージョン (リリースのバージョン) 

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 構造を作成しなければならない場合には、実行可能な 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 のネットワークナビゲート法の変更 (マップの変更)

マップへのエントリを変更、削除、または追加して、ユーザの環境ニーズに合わせることができます。ユーザが必要とするアプリケーションやその他のファイルシステムがその位置を変更すると、マップはこれらの変更を反映しなければなりません。autofs のマップは、いつでも変更できます。automountd が次にファイルシステムをマウントしたときにその変更内容が有効となるかどうかは、変更したマップと変更内容によって決まります。

ネームサービスに対する autofs のデフォルトの動作

ブート時に、autofs は /etc/init.d/autofs にあるスクリプトを使用して起動され、マスタマップ auto_master が検索されます (次に説明する規則が適用されます)。

autofs は、/etc/nsswitch.conf ファイルの自動マウントエントリで指定されたネームサービスを使用します。ローカルファイルや NIS ではなく NIS+ が指定された場合、マップ名はすべてそのまま使用されます。NIS が選択されていて autofs が必要なマップを検出できず、1 つまたは複数の下線を含むマップを検出した場合、以前の NIS ファイル名を使えるようにするため、autofs はその下線をドットに変換します。次に autofs はもう 1 度マップを調べます。この手順を 図 5-4 に示します。

図 5-4 autofs によるネームサービスの使用

Graphic

このセッションでの画面の動きは次の例のようになります。


$ 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 は一部の文字を、特別な意味を持つものとして認識します。これらの文字には、置換に使用される文字や、他の文字を 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 - "