autofs 管理作業の概要

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

この節で説明する作業を実行するには、『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。

autofs 管理の作業マップ

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

マップの管理作業

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

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

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

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

マップの修正

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

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

1. マップを変更する権限を持つユーザーとしてログインします。

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

   『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。

3. 各クライアントで、スーパーユーザーになるか、それと同等の役割になります。

   役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

5. マップを変更したことを他のユーザーに通知します。

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

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

間接マップの修正方法

マップを変更する権限を持つユーザーとしてログインします。

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

『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。

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

直接マップの修正方法

1. マップを変更する権限を持つユーザーとしてログインします。

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

   『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。

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

4. マップを変更したことを他のユーザーに通知します。

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

   ---

   注 -

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

   ---

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

   ---

   注 -

   できるだけ間接マップを使用してください。間接マップは構築が容易であり、コンピュータのファイルシステムへの要求が少なくて済みます。また、間接マップは直接マップよりもマウントテーブル内のスペースを必要としません。

   ---

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

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

たとえば /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 アプリケーションにアクセスする

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

1. スーパーユーザー、またはそれと同等の役割になります。

   役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

   次のような CD-ROM のファイルシステム用のエントリを追加します。

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

   マウントする CD-ROM 装置の名前が、コロンの後に続けて表示されます。

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

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

1. スーパーユーザー、またはそれと同等の役割になります。

   役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

   次のようなフロッピーディスクのファイルシステム用のエントリを追加します。

   pcfs -fstype=pcfs :/dev/diskette

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

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

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

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

1. スーパーユーザー、またはそれと同等の役割になります。

   役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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. スーパーユーザー、またはそれと同等の役割になります。

   役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

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

3. auto_home マップを作成して維持します。

   新しいユーザーアカウントを作成する場合は、そのユーザーのホームディレクトリの場所を 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 のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。

2. 共有名前空間について、サイト固有の名称を 1 つ選択します。この名称により、その名前空間に属するファイルとディレクトリが簡単に識別できるようになります。

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

3. ユーザーのコミュニティ識別を簡単にするため、autofs 間接マップを作成します。autofs 間接マップを /usr/local にマウントします。NIS (または NIS+) の auto_master マップ内で、次のエントリを設定します。

   /usr/local auto_local -ro

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

4. サーバー上の任意のディレクトリをエクスポートします。

5. auto_local マップ内に bin エントリを 1 つ含めます。

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

   bin aa:/export/local/bin

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

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

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

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

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

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

   autofs OSREL 変数と CPU 変数を結合して、CPU タイプと OS リリースの両方を示す名前を作成することができます。

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

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

   SunOS 5.6 を動作させているクライアントについて、次のファイルシステムをエクスポートします。

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

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

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

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

1. スーパーユーザー、またはそれと同等の役割になります。

   役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

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

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

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

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

1. スーパーユーザー、またはそれと同等の役割になります。

   役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

2. 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 で公共ファイルハンドルを使用する方法

1. スーパーユーザー、またはそれと同等の役割になります。

   役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

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

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

autofs で NFS URL を使用する方法

1. スーパーユーザー、またはそれと同等の役割になります。

   役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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. NFS クライアント上で、スーパーユーザー、またはそれと同等の役割になります。

   役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

   root として、/etc/init.d/autofs スクリプトを編集して、autmountd デーモンを開始する行に -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

選択したファイルシステムの 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