autofs 管理作業の概要

このセクションでは、ユーザー自身の環境で遭遇する可能性のある最も一般的な作業について説明します。ユーザーのクライアントの必要に最良な形で適合するように autofs を設定するのに役立つ、各シナリオについて推奨される手順も示します。

このセクションで説明される作業を実行するには、Solstice System Management Tools を使用するか、『Solaris ネーミングの管理』を参照してください。

autofs 管理の作業マップ

表 30-5 に、autofs に関連する作業についての説明と参照箇所を示します。

管理作業を含むマップ

表 30-6 は、autofs マップの管理時に認識しておく必要のある事項について示したものです。選択したマップのタイプおよびネームサービスにより、autofs マップへの変更を行うために使用する必要があるメカニズムが異なります。

表 30-6 に、マップのタイプとその使用方法を示します。

表 30-7 は、ネームサービスに基づいて autofs 環境に変更を加える方法を示したものです。

表 30-8 に、マップのタイプについて行なった修正に応じた automount コマンドを実行する場合を示します。たとえば、直接マップに対する追加または削除を行なった場合、ローカルシステム上で automount コマンドを実行し、変更が反映されるようにする必要があります。しかし、既存のエントリを修正した場合は、変更を反映するために、automount コマンドを実行する必要はありません。

マップの修正

次の手順では、NIS+ をネームサービスとして使用している必要があります。

マスターマップの修正方法

1. nistbladm コマンドを使用して、マスターマップへの変更を行います。

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

2. 各クライアントで、スーパーユーザーになります。

3. 各クライアントで、automount コマンドを実行し、変更が反映されるようにします。

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

   他ユーザーがコンピュータ上でスーパーユーザーとして automount コマンドを実行するように、通知が必要になります。

automount コマンドは、実行時にマスターマップからの情報の収集を行います。

間接マップの修正方法

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

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

変更はマップを次に使用する時、つまり次回のマウント実行時に反映されます。

直接マップの修正方法

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

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

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

3. 変更した点を他のユーザーに通知します。

   他ユーザーがコンピュータ上でスーパーユーザーとして automount コマンドを実行するように、通知が必要になります。

   ---

   注 -

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

   ---

   たとえば、異なるサーバーから /usr/src ディレクトリがマウントされるように auto_direct マップを修正するとします。/usr/src がその時点でマウントされていない場合、/usr/src にアクセスするとすぐにその新しいエントリが反映されます。/usr/src がその時点でマウントされている場合、オートアンマウントが実行されるまで待ちます。そのあと、アクセスが可能になります。

   ---

   注 -

   これらの追加の手順が必要だったり、直接マップほどにはマウントテーブル内のスペースを必要としないので、可能であれば必ず間接マップを使用してください。間接マップは構築が容易であり、コンピュータのファイルシステムへの要求が少なくて済みます。

   ---

マウントポイントの重複回避

/src 上にマウントされたローカルなディスクパーティションがあり、他のソースディレクトリのマウントにもその autofs サービスを使用したい場合、問題が発生する可能性があります。マウントポイント /src を指定する場合、ユーザーがアクセスするたびに、そのサービスが対象のローカルパーティションを隠すことになります。

その場合、そのパーティションはたとえば /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 など、削除可能な媒体上のファイルをマウントします。通常は、Volume Manager を使用して削除可能な媒体上のファイルをマウントすることになります。次の例では、autofs を利用してこのマウントがどのように行われるかを示します。Volume Manager と autofs は同時に動作することができないため、まず Volume Manager を終了してから次に示すエントリを使用する必要があります。

サーバーからファイルシステムのマウントを行う代わりに、ドライブに媒体を配置してマップから参照します。autofs を使用し非 NFS ファイルシステムにアクセスを行いたい場合は、次の手順を参照してください。

autofs で CD-ROM アプリケーションにアクセスする

Volume Manager を使用していない場合に、この手順を行なってください。

1. スーパーユーザーになります。

2. autofs マップを更新します。

   CD-ROM のファイルシステムに対するエントリを追加する場合、次のようになります。

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

   マウントしたい CD-ROM 装置の名前が、コロンのあとに続けて表示されます。

autofs で PC-DOS データフロッピーディスクにアクセスする方法

Volume Mananger を使用していない場合に、この手順を行なってください。

1. スーパーユーザーになります。

2. autofs マップを更新します。

   ファイルシステムに対するエントリを追加する場合、次のようになります。

   pcfs -fstype=pcfs :/dev/diskette

CasheFS を使用して NFS ファイルシステムにアクセスする

キャッシュファイルシステム (CacheFS) は、汎用不揮発性キャッシュメカニズムで、小型で高速ローカルディスクを利用して、特定のファイルシステムの性能を向上させます。

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

CasheFS を使用して NFS ファイルシステムにアクセスする方法

1. スーパーユーザーになります。

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

   # cfsadmin -c /var/cache

3. 任意のオートマウンタマップに 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 の下に配置できるようにすることです。この表示方法は通常、クライアントでもサーバーでも、すべてのコンピュータを通じて共通です。

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+ のネームサービスファイルで表示されなくてはなりません。

ユーザーは、各ホームディレクトリから setuid 実行可能ファイルを実行することが許可されていません。この制限がないと、すべてのユーザーがすべてのコンピュータ上でスーパーユーザーの権限を持つことになります。

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

1. スーパーユーザーになります。

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

   複数のパーティションがある場合には、/export/home1、/export/home2 のように、別のディレクトリにそれぞれインストールを行います。

3. auto_home マップを作成して維持するため、Solstice System Management Tools を使用します。

   新しいユーザーアカウントを作成する場合には、そのユーザーのホームディレクトリの位置を auto_home マップに入力します。マップのエントリは、次のように単純な形式にできます。

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

   マップキーの代用する & (アンパサンド) の使い方に注意してください。これは、次の例での、2 つ目の rusty の使用を省略した形式です。

   rusty dragon:/export/home1/rusty

   auto_home マップが適切に配置されている場合、ユーザーは /home/user パスを使用して、ユーザー自身のホームディレクトリを含むすべてのホームディレクトリが参照できます。user がログイン名であり、マップ内でのキーです。すべてのホームディレクトリを共通に表示する仕組みは、他ユーザーのコンピュータにログインする場合に便利です。autofs は、ユーザー自身のホームディレクトリをマウントします。同様に、他のコンピュータ上でリモートウィンドウシステムのクライアントを動作させる場合、クライアントプログラムは、ウィンドウシステム表示を提供するコンピュータと同じ /home ディレクトリを表示します。

   この共通表示は、サーバーにも拡張されています。前の例を使用すれば、rusty がサーバー dragon にログインする場合、autofs は、/export/home1/rusty を /home/rusty にループバックマウントすることにより、ローカルディスクへの直接アクセスを提供します。

   ユーザーは、各ホームディレクトリの実際の位置を意識する必要はありません。rusty がさらにディスクスペースを必要とし、rusty 自身のホームディレクトリを他のサーバーに再配置する必要がある場合には、auto_home マップ内の rusty のエントリを新しい位置を反映するように変更することだけが必要になります。すべてのユーザーは、/home/rusty パスを継続して使用することができます。

/ws 下のプロジェクト関連ファイルを統合する方法

大きなソフトウェアの開発プロジェクトの管理者を想定してください。そこで、プロジェクト関連のファイルをすべて /ws というディレクトリの下で利用できるようにしたいと仮定します。このようなディレクトリは、そのサイトのすべてのワークステーションで共通である必要があります。

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 つのマウントを必要とします。各行の最後のバックスラッシュは、エントリが次の行まで続いていることを autofs に伝えるものです。実際、エントリは 1 つの長い行となっていますが、行ブレークやインデントのいくつかはエントリを読みやすくする目的で使用されています。tools ディレクトリには、すべてのサブプロジェクトに対するソフトウェア開発ツールが含まれているため、同じサブディレクトリ構造の対象とはなっていません。tools ディレクトリは単一のマウントのままです。

   この配置は、システムの管理者に大きな柔軟性を提供します。ソフトウェアプロジェクトでは、非常に大きなディスクスペースを消費します。プロジェクトのすべての過程を通じて、さまざまなディスクパーティションを再配置し、拡張することになる可能性もあります。このような変更が auto_ws マップに反映される限り、/ws 下のディレクトリ階層構造が変更されることもなく、ユーザーに対する通知の必要はありません。

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

共有名前空間にアクセスするために異なるアーキテクチャを設定する方法

表計算ツールやワードプロセッサパッケージのようなローカルな実行可能ファイルやアプリケーションについて、共有名前空間を作成する必要があります。この名前空間のクライアントは、異なる実行可能フォーマットを必要とする複数の異なるワークステーションアーキテクチャを使用します。また、ワークステーションには、異なるリリースのオペレーシングシステムを使用するものもあります。

1. nistabladm コマンドで 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. auto_local マップ内に bin エントリを 1 つ含めます。

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

   bin aa:/export/local/bin

   異なるアーキテクチャのクライアントを処理するため、クライアントのアーキテクチャタイプに応じて、その bin ディレクトリへの参照をサーバー上の異なるディレクトリに割り当てる必要があります。

6. 異なるアーキテクチャのクライアントを処理するため、autofs CPU 変数を加えて、エントリの変更を行います。

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

   • SPARC クライアント - 実行可能ファイルを /export/local/bin/sparc に配置する

   • IA クライアント - 実行可能ファイルを /export/local/bin/i386 に配置する

非互換のクライアントオペレーティングシステムのバージョンをサポートする方法

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

   CPU タイプと OS リリースの両方を特定する名称を作成するために、autofs OSREL 変数は CPU 変数と結合することができます。

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

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

   バージョン 5.6 のオペレーティングシステムを動作させているクライアントについて、次のファイルシステムをエクスポートします。

   • SPARC クライアント - /export/local/bin/sparc5.6 をエクスポートする

   • IA クライアント - /export/local/bin/i3865.6 に実行可能ファイルを配置する

複数のサーバーを通じて共用ファイルを複製する方法

読み取り専用の複製されたファイルシステムを共有する最良の方法は、フェイルオーバーの利用です。フェイルオーバーについての説明は、「クライアント側フェイルオーバー機能」を参照してください。

1. スーパーユーザーになります。

2. autofs マップ内のエントリを修正します。

   すべての複製サーバーのリストを、コンマ区切りのリストとして、次のように作成します。

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

   autofs は、最も近いサーバーを選択します。サーバーが複数のネットワークインタフェースを持っている場合は、各インタフェースのリストを作成してください。autofs はクライアントに最も近接したインタフェースを選択し、NFS トラフィックの不必要なルーティングを避けるようにしています。

セキュリティ制限を適用する方法

1. スーパーユーザーになります。

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

   /home auto_home -nosuid

   nosuid オプションは、setuid または setgid ビットを設定したファイルをユーザーが作成できないようにします。

   このエントリは、通常のローカルな /etc/auto_master ファイル内の /home に関するエントリを無効にします (前述の例を参照)。これは、ファイル内の /home エントリの前に、+auto_master の外部ネームサービスマップへの参照が生じるためです。auto_home マップ内のエントリがマウントオプションを含む場合、nosuid オプションは無効になります。そのため、オプションを auto_home マップで使用しないか、nosuid オプションを各エントリに含むことになります。

   ---

   注 -

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

   ---

autofs で公共ファイルハンドルを使用する方法

1. スーパーユーザーになります。

2. 次のように、autofs マップ内にエントリを作成します。

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

   public オプションは、公共ハンドルの使用を強制します。NFS サーバーが公共ファイルハンドルをサポートしない場合、マウントは失敗します。

autofs で NFS URL を使用する方法

1. スーパーユーザーになります。

2. 次のように、autofs エントリを作成します。

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

   サービスは、NFS サーバー上で公共ファイルハンドルの使用を試みますが、そのサーバーが公共ファイルハンドルをサポートしない場合、MOUNT プロトコルが使用されます。

autofs のブラウザ機能を無効にする

Solaris 2.6 リリースから使い始めた場合、インストールされる /etc/auto_master のデフォルトバージョンには、/home と /net 用のエントリに追加された -nobrowse オプションが含まれます。さらに、アップグレード手順により、/home と /net のエントリが修正されていない場合には、-nobrowse オプションが それらエントリに追加されます。ただし、このような変更を手動で加えるか、またはインストール後にサイト固有の autofs マウントポイントに対するブラウズ機能をオフにすることが必要な場合もあります。

ブラウズ機能をオフにする方法はいくつかあります。automountd デーモンに対してコマンド行オプションを使用してオフにすると、そのクライアントに対する autofs ブラウザ機能は完全に無効になります。あるいは、NIS または NIS+ 名前空間内の autofs マップを使用してすべてのクライアント上の各マップエントリに対してブラウザ機能をオフにできます。またネットワーク全体に渡る名前空間が使用されていない場合には、ローカルな autofs マップを使用して、各クライアント上の各マップエントリに対してブラウザ機能をオフにできます。

1 つの NFS クライアント上の autofs ブラウズ機能を完全に無効にする方法

1. スーパーユーザーになります。

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

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

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

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

   # /etc/init.d/autofs stop # /etc/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. automount エントリが /etc/nsswitch.conf にあることを確認します。

   優先するローカルファイルエントリについては、ネームサービススイッチファイル内のエントリがネームサービスの前に files をリストする必要があります。たとえば、次のようになります。

   automount: files nisplus

   これは、標準的な Solaris にインストールされるデフォルトの構成です。

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

   名前空間内のエントリに優先するローカルファイルへの追加については、+auto_master エントリが /net の下に移動されている必要があります。

   # Master map for automounter # /net -hosts -nosuid /home auto_home /xfn -xfn +auto_master

   標準的な構成では、+auto_master エントリがファイルの先頭に配置されます。これにより、ローカルな変更が使用されなくなります。

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

   /net -hosts -nosuid,nobrowse

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

   新規の動作は、クライアントシステム上で automount コマンドを実行したあと、またはリブートしたあとで反映されます。

   # /usr/sbin/automount