あなたが大規模なソフトウェア開発プロジェクトの管理者だとします。プロジェクトに関連するすべてのファイルを /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 マウントの代わりにループバックマウントを通じて、ローカルファイルへの直接アクセスが提供されます。