この章では、autofs 管理タスクの実行方法について説明します。具体的には、オートマウンタマップの変更、オートマウンタから非 NFS タイプのデバイスに対するアクセス、マップの設定などです。
この節では、autofs サービスの起動および停止の手順について説明します。
リブートせずにデーモンを起動するには、スーパーユーザになって次のコマンドを入力します。
# /etc/init.d/autofs start |
これでデーモンが起動します。
リブートせずにデーモンを停止するには、スーパーユーザになって次のコマンドを入力します。
# /etc/init.d/autofs stop |
この節では、ユーザの環境で遭遇する可能性のある最も一般的な問題について、そのいくつかを説明します。クライアントのニーズに最適な autofs を構成する際に役立つよう、各問題ごとに推奨する解決策を記載しています。
この節で説明されている作業を実行するには、Solstice システム管理ツールを使用するか、または『Solaris ネーミングの管理』を参照してください。
次のリストは、autofs 環境を変更するために実行する必要が生じる可能性のある、マップに関する各種の管理作業です。
マップの種類とその使用方法を表 4-1 に示します。
マップの種類 |
使用方法 |
---|---|
ディレクトリとマップを対応付ける |
|
autofs を特定のファイルシステムに割り当てる |
|
autofs を参照だけを行うファイルシステムに割り当てる |
ネームサービスを基にして、ユーザの autofs 環境を変更する方法を表 4-2 に示します。
表 4-2 マップ管理
ユーザのネームサービス |
変更用のツール |
---|---|
ローカルファイル |
テキストエディタ |
NIS |
make ファイル |
NIS+ |
nistbladm |
表 4-3 は、変更後に automount コマンドを実行すべきかどうかを、変更したマップの種類別に示しています。たとえば、直接マップに追加または削除を行なった場合には、その変更を反映させるためにローカルシステムで automount コマンドを実行する必要があります。しかし、既存のエントリに変更を行なった場合には、automount コマンドを実行してその変更を反映させる必要はありません。
表 4-3 automount コマンド実行タイミング
マップの種類 |
automountを再起動する ? |
|
---|---|---|
|
追加または削除 |
既存のエントリを変更 |
実行する |
実行する |
|
実行する |
実行しない |
|
実行しない |
実行しない |
以下の手順では、ネームサービスとして NIS+ を使っていることが前提です。
nistbladm コマンドを使って、マスタマップに必要な変更をします。
『Solaris ネーミングの管理』を参照してください。
各クライアントに対して、プロンプトで su を入力し、スーパーユーザのパスワードを入力してスーパーユーザになります。
各クライアントに対して、automount コマンドを実行して、行った変更を確実に有効にします。
ユーザに変更を通知します。
ユーザでも自分のコンピュータ上でスーパーユーザとして automount コマンドを実行できることを通知してください。
automount コマンドが実行されると、マスタマップを参照します。
nistbladm コマンドを使用して、間接マップへの変更を行います。
『Solaris ネーミングの管理』を参照してください。
次にこのマップが使用されると、マウントが行われ、変更内容が有効となります。
nistbladm コマンドを使用して、直接マップへの変更を追加または削除します。
『Solaris ネーミングの管理』を参照してください。
手順 1 でマウントポイントエントリを追加または削除した場合、automount コマンドを実行します。
ユーザに変更を通知します。
ユーザでも自分のコンピュータ上でスーパーユーザとして 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 はコンピュータの名前です。
autofs は、NFS ファイル以外のファイルもマウントできます。autofs は、ファイルをフロッピーディスクや CD-ROM などの取り外し可能メディア上にマウントします。通常は、ボリュームマネージャ機能を使って取り外し可能メディアにファイルをマウントします。以下の例では、autofs を使ってこのマウント操作をどのように行うかを示しています。ボリュームマネージャ機能と autofs とは併用できないので、通常はまずボリュームマネージャを無効にしてから、これらのエントリを使用することになります。
サーバからファイルシステムをマウントするのではなく、ユーザがメディアをドライブにセットして、それをマップから参照します。autofs を使っているときに、NFS 以外のファイルシステムをアクセスしたい場合は、次の手順を参照してください。また、ボリュームマネージャについての詳細は『Solaris のシステム管理』を参照してください。
ボリュームマネージャを使わない場合は、この手順に従ってください。
次のように CD-ROM ファイルシステムの種類を指定してください。
hsfs -fstype=hsfs,ro :/dev/sr0 |
マウントする CD-ROM 装置の名前には、先頭にコロンを付けてください。
ボリュームマネージャを使わない場合は、この手順に従ってください。
キャッシュファイルシステム (CacheFS) は、小型で高速なローカルディスクを使用することによって、特定のファイルシステムの性能を向上させるための、汎用の不揮発性キャッシュ機能です。
CacheFS を使用して、NFS ファイルシステムからのデータをローカルディスク上に保存することによって、NFS 環境の性能を改善できます。
cfsadmin コマンドを実行してローカルディスク上にキャッシュディレクトリを作成します。
# cfsadmin -c /var/cache |
オートマウンタマップに 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+ のネームサービスマップに登録されていなければなりません。
制限がなければ、どんなユーザでも任意のコンピュータ上でスーパーユーザ特権を持つことができるため、ユーザが自分のホームディレクトリから実行可能ファイル set uid を実行することを許可しないでください。
/export/home の下にホームディレクトリパーティションをインストールします。
複数のパーティションがある場合、それらを別個のディレクトリ、たとえば /export/home1、/export/home2 などの下にインストールします。
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 (Work Space の略) と呼ばれるディレクトリの下で使用できるようにしたいとします。このディレクトリは、そのサイトのすべてのワークステーション間で共通となります。
/ws ディレクトリ用のエントリを、NIS または NIS+ のサイトの auto_master マップに追加します。
/ws auto_ws -nosuid |
auto_ws マップによって、/ws ディレクトリの内容が決まります。
用心のため、-nosuid オプションを追加します。
このオプションを指定すると、ユーザは、ワークスペースに存在する setuid を実行できなくなります。
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 つにまとめる必要があります。この名前空間のクライアントは、異なる実行可能形式を必要とするさまざまなワークステーションアーキテクチャを使用します。また、一部のワークステーションはオペレーティングシステムの異なるバージョンを実行しています。
nistbladm コマンドを使用して auto_local マップを作成します。
『Solaris ネーミングの管理』を参照してください。
共有名前空間に対して 1 つのサイト名を選択し、この空間に属するファイルとディレクトリを容易に識別できるようにします。
たとえば、この名前として /usr/local を選択した場合、/usr/local/bin というパスは、明らかにこの名前空間の一部となります。
ユーザを簡単に認識できるよう、autofs の間接マップを作成して、/usr/local にマウントします。NIS+ (または NIS) の auto_master マップ内に次のエントリを設定します。
/usr/local auto_local -ro |
なお、マウントオプション ro は、クライアントがどのファイルやディレクトリにも書き込みできないことを意味します。
適切なディレクトリをサーバ上にエクスポートします。
bin のエントリを auto_local マップに作成します。
ディレクトリ構造は次のようになります。
bin aa:/export/local/bin |
異なるアーキテクチャのクライアントに対応するというニーズを満足するため、この bin ディレクトリに対する参照は、クライアントのアーキテクチャタイプに応じて、サーバ上の異なるディレクトリに対して行う必要があります。
異なるアーキテクチャのクライアントに対応するため、autofs の「CPU」変数を追加することによって、エントリを変更します。
bin aa:/export/local/bin/$CPU |
SPARCstationTM クライアントの場合は、実行可能ファイルはサーバ上の /export/local/bin/sparc のもとで使用できるようにしてください。x86 クライアントの場合、/export/local/bin/i386 です。
クライアントのオペレーティングシステムタイプを判定する変数を、アーキテクチャタイプに結合します。
autofs の「OSREL」変数を CPU 変数と結合することによって、CPU タイプと OS リリースの両方を決める名前を作成することができます。
次のマップエントリを作成します。
bin aa:/export/local/bin/$CPU$OSREL |
バージョン 5.1 のオペレーティングシステムを実行している SPARC クライアントの場合、サーバから /export/local/bin/sparc5.1 をエクスポートし、同様に他のリリースもエクスポートする必要があります。オペレーティングシステムは実行可能形式での下方互換性を維持しようとするため、OS のリリースについては問題ないと想定し、このあとの例では、OS のリリースによる区別は省略します。
これまで、1 つのサーバ「aa」用のエントリを設定しました。大規模ネットワークでは、これらの共有ファイルを複数のサーバ間で複写したいという要望があります。NFS のトラフィックがローカルネットワークセグメントに限定されるよう、各サーバは、サービスを提供するクライアントに近いネットワークにある必要があります。
複製された読み取り専用のファイルシステムを共有する最良の方法は、障害時回避機能を使うことです。障害時回避機能については、「クライアント側障害時回避機能」 を参照してください
bin aa,bb,cc,dd:/export/local/bin/$CPU |
autofs は最も近いサーバを選択します。サーバに複数のネットワークインタフェースがある場合、各インタフェースを指定します。autofs はクライアントに最も近いインタフェースを選択し、NFS トラフィックの不必要な経路指定を回避します。
/home auto_home -nosuid |
nosuid オプションが指定されていると、ファイルを作成するときに setuid ビットも setgid ビットも設定することができません。
このエントリは、ローカル /etc/auto_master ファイル内の /home エントリを無効にします (前の例を参照)。その理由は、外部ネームサービスマップへの +auto_master 参照がこのファイルの /home エントリよりも前に行われるためです。auto_home マップのエントリにマウントオプションが指定されている場合、nosuid オプションは上書きされます。したがって、auto_home マップではオプションを一切使わないか、各エントリに nosuid オプションを指定します。
サーバ上の /home の上またはその下に、ホームディレクトリのディスクパーティションをマウントしないでください。
Solaris 2.6 でインストールされる /etc/auto_master では、/home と /net のエントリに -nobrowse オプションが追加されています。また、/etc/auto_master の中の /home と /net のエントリが変更されていなければ、アップグレードによってこれらのエントリに -nobrowse オプションが追加されます。しかし、これらの変更を手動で行なったり、各サイトの autofs マウントポイントの表示機能を無効にしなければならないこともあります。
表示機能を無効にする方法は 2 通りあります。1 つは automountd に対してコマンド行オプションを使用して無効にする方法です。この場合、クライアントに対する autofs の表示機能は完全に無効になります。もう 1 つは、NIS または NIS+ 名前空間の autofs マップを使っているクライアントすべてに対して、またはネットワーク全体で使用している名前空間がない場合にはローカルの autofs マップを使っている各クライアントごとに、マップエントリで表示機能を無効にする方法です。
起動スクリプトに -n オプションを追加します。
スーパーユーザになって /etc/init.d/autofs スクリプトを編集して、automountd デーモンを起動している行に -n オプションを追加します。
/usr/lib/autofs/automountd -n ¥ < /dev/null > /dev/console 2>&1 # start daemon |
autofs サービスを再起動します。
# /etc/init.d/autofs stop # /usr/init.d/autofs start |
すべてのクライアントに対して表示機能を無効にするには、NIS や NIS+ といったネームサービスを使用している必要があります。使用していない場合は、クライアントごとにオートマウンタマップを手動で編集する必要があります。この例では、/home ディレクトリの表示機能を無効にします。この手順を、無効にする間接 autofs ノードそれぞれについて実行します。
ネームサービスの auto_master ファイルにある /home エントリに対して、-nobrowse オプションを追加します。
/home auto_home -nobrowse |
すべてのクライアントで、automount コマンドを実行します。
変更は、このクライアントで automount コマンドを実行するかクライアントをリブートすると反映されます。
# /usr/sbin/automount |
この例では、/net ディレクトリの表示機能を無効にします。同様の手順は、/home などの autofs マウントポイントにも適用できます。
/etc/nsswitch.conf の automount エントリを調べます。
ローカルファイルエントリを優先させるためには、ネームサービスの切り替えファイルでネームサービスより前に files を指定します。たとえば次のようにします。
automount: files nisplus |
これは、Solaris をインストールしたときのデフォルト設定です。
/etc/auto_master の中で +auto_home エントリの位置を確認します。
ローカルファイルへの追加を名前空間のエントリよりも優先させるために、+auto_master エントリを /net よりも下の位置に移動します。
# Master map for automounter # /net -hosts -nosuid /home auto_home /xfn -xfn +auto_master |
-nobrowse オプションを /etc/auto_master ファイルの /net エントリに追加します。
/net -hosts -nosuid,nobrowse |
すべてのクライアントで、automount コマンドを実行します。
変更は、このクライアントで automount コマンドを実行するかクライアントをリブートすると反映されます。
# /usr/sbin/automount |
autofs を使用していて問題が発生することもあります。この節の目的は、問題解決のプロセスを容易にすることです。これは 2 つの節に分かれています。
この節では、autofs が生成するエラーメッセージのリストを提供します。このリストは 2 つの部分に分かれています。
automount の詳細 (-v) オプションによって生成されたエラーメッセージ
任意の時点で表示されるエラーメッセージ
それぞれのエラーメッセージには説明が続き、考えられる原因を示します。
問題を解決する際は、詳細 (-v) オプションを使って起動してください。そうしないと、問題が発生しても原因がわからない可能性があります。
以下では Autofs で問題が発生したときに表示される可能性のあるエラーメッセージを取り上げ、問題の内容について説明します。
直接マップの走査中、autofs は「/」が付いていないエントリキーを検出しました。直接マップ内のキーはフルパス名でなければなりません。
bad key key in indirect map mapname
間接マップの走査中、autofs が「/」を含むエントリキーを検出しました。間接マップのキーは、パス名ではなく、単純な名前でなければなりません。
サーバ上のマウントデーモンが、server:pathname 用のファイルハンドル提供を拒否しています。サーバ上のエクスポートテーブルをチェックしてください。
マウントに必要なマウントポイントを autofs が作成できませんでした。このメッセージが最もよく表示されるのは、サーバのエクスポートされたファイルシステムをすべて階層的にマウントしようとしたときです。必要なマウントポイントが、マウントできない (エクスポートできない) ファイルシステムにだけ存在する可能性があります。しかもエクスポートされた親ファイルシステムが読み取り専用でエクスポートされているため、これを作成できません。
autofs は、先頭にスペースが含まれるエントリを自動マウントマップ内に発見しました。これは通常、たとえば次のように誤って続けて入力したマップエントリが原因です。
fake /blat frobz:/usr/frotz |
上の例では、最初の行はバックスラッシュ (¥) で終了しなければならないため、autofs が 2 番目の行を検出したとき、この警告が生成されます。
必要なマップを検出できません。このメッセージは、-v オプションが指定された場合にだけ出力されます。マップ名のスペルとパス名をチェックしてください。
remount server:pathname on mountpoint: server not responding
autofs は、以前にアンマウントしたファイルシステムの再マウントに失敗しました。このメッセージは、ファイルシステムが正常に再マウントされるまで、一定間隔ごとに表示されます。
autofs は既存のマウントポイントの上にマウントしようとしています。これは、autofs に内部エラー (異常) があることを意味しています。
自動マウンタのマウントポイントはフルパス名で指定しなければなりません。マウントポイントのスペルとパス名をチェックしてください。
autofs では、マウントポイントが階層関係を持つことはできません。つまり、オートマウンタのマウントポイントが、他のオートマウントされたファイルシステム内に含まれてはいけません。
autofs は通信を試みましたが、応答を受信しませんでした。
hostname からのエクスポートリストの獲得エラー。これはサーバまたはネットワークのトラブルを示します。
マップエントリの形式が誤っており、autofs はこれを解釈できません。エントリを再チェックしてください。おそらく、この中にエスケープを必要とする文字があります。
NIS マップ内のエントリを検索する際のエラー。NIS のトラブルの可能性あり。
autofs はマウントの実行に失敗しました。これはサーバまたはネットワークのトラブルを意味します。
autofs は、マウントポイントがディレクトリではないため、これにそれ自身をマウントできません。マウントポイントのスペルとパス名をチェックしてください。
autofs は、複写されたファイルシステム位置のリストにあるサーバに対して、問い合わせパケットを送信できません。
autofs は、複写されたファイルシステム位置のリストにあるどのサーバからも応答を受信できません。
これらのエラーメッセージは、複写されたファイルシステム用のサーバに対し ping を実行しようとしていることを示します。ネットワークに問題がある可能性があります。
autofs は、pathname 用のパス構成情報を獲得できませんでした。
/etc/auto* ファイルに実行ビットセットがある場合、自動マウンタはマップを実行しようとして、次のようなメッセージを作成します。
/etc/auto_home: +auto_home: not found
この場合、auto_home ファイルには間違ったパーミッションが入ることになります。ファイルの各エントリはほぼ上記のようなエラーメッセージを生成します。以下のコマンドを入力して、ファイルへのパーミッションをリセットする必要があります。
# chmod 644 /etc/auto_home |