この章では、セルを構成する際および管理する際の注意事項の多くについて説明し、詳細な関連情報が記載されている本書内の場所を示します。この章は、ユーザーがすでに AFS 管理の概要 の資料に精通していることを想定しています。
セルの最初のファイル・サーバー・マシンをインストールするか、あるいは、ほかの管理用タスクのどれかを実行する前にこの章を読むことが最適です。
AFS の振る舞いは、ほとんどの点で、標準 UNIX ファイル・システムと類似していますし、AFS により セル内およびセル間のファイルの共用も容易になります。このセクションでは、AFS ファイル・システムと UNIX ファイル・システムの相違点について、適宜詳細な参照情報を示しながら説明します。
AFS は、標準 UNIX ファイル保護メカニズムを 2 通りの方法で強化しています。まず、AFS はアクセス制御リスト (ACL) を各ディレクトリーに関連付けます。そして、ユーザーが多数のユーザー独自のグループ (ACL 上に配置できます) を定義することを可能にします。
AFS は、排他的にモード・ビットに依存するのではなく、 ACL を使用してファイルとディレクトリーを保護します。これには多くの言外の意味があり、それについては、指示された機能グループで詳細に説明します。
AFS を使用すると、ユーザーは他のユーザーからなるグループを定義することができます。このように定義されたグループを ACL に配置すると、同じアクセス権を正確に指定された多くのユーザーに同時に広まります。この方が、個人を ACL に直接配置するより、はるかに便利です。保護データベースの管理 を参照してください。
システムが定義するグループ、system:anyuser と system:authuser もあります。このようなグループが ACL にあることで、幅広いユーザーに同時にアクセスできるようになります。システム・グループ および ACL 上でのグループの使用 を参照してください。
AFS ファイル・スペースが各マシンのローカル・ファイル・システムと別個であるのと同様に、 AFS 認証はローカル・ログインとは分離されています。これには実用上 2 つの言外の意味があり、それについては AFS の変更済みログイン・ユーティリティーを使用する場合 で説明しています。
AFS は、1 つのパスワードに基づき、 1 つのステップでローカル・ログインと AFS 認証の両方を完了する変更済みのログイン・ユーティリティーを提供します。 AFS の変更済みログイン・ユーティリティーを使用しないことを選択すると、ユーザーは、AFS 使用者の手引き で説明するように、別個のステップでログインと認証を実行しなければなりません。
このセクションでは、AFS が一部の UNIX コマンドの機能をどのように変更しているのかについて要約します。
一部のシステム・タイプ用の AFS 配布には、変更済みの rlogind プログラムが含まれていないかもしれません。AFS Release Notes を参照してください。
AFS ファイル・サーバー・マシンでは決して標準 UNIX の fsck コマンドは実行しないでください。このコマンドは、ファイル・サーバーがどのようにディスク上にボリューム・データを編成するのかを理解していません。そのため、このコマンドはすべての AFS データを区画上の lost+found ディレクトリーに移動します。
代わりに、AFS 配布に組み込まれているバージョンの fsck プログラムを使用してください。 AFS インストールの手引き では、各サーバー・マシンをインストールするときに、製造元から提供されている fsck プログラムを AFS バージョンで置き換える方法を説明します。
AFS バージョンの fsck プログラムは、 UFS パーティションに保管されているデータ、および AFS パーティションに保管されているデータの両方に対して、標準の fsck プログラムと同じように機能します。 fsck プログラムが初期化されるときに、次のようなバナーが表示されることで、正しいバージョンを実行していることが確認できます。
--- AFS (R) version fsck---
version は、AFS のバージョンです。正しい結果を得るには、これがマシンで使用しているサーバー・バイナリーの AFS バージョンと一致していなければなりません。
標準バージョンのプログラムを誤って実行した場合は、すぐに AFS 製品サポートに連絡してください。 lost+found ディレクトリーからボリュームのデータを回復することが可能な場合があります。
AFS では、異なるディレクトリーに常駐するファイルの間に、ハード・リンク (UNIX ln コマンドで作成された) を作成することは許可されません。そのようなリンクでは、ディレクトリーのどの ACL をリンクに関連付けるかが不明だからです。
ツリーとして編成されたファイル・システムを保持するために、 AFS では、ディレクトリーに対するハード・リンクも許可されません。
2 つの異なる AFS ディレクトリーの要素間で、または AFS の要素とマシンのローカル UNIX ファイル・システムの要素の間でも、シンボリック・リンクを作成する (ln -s コマンドで) ことができます。ただし、番号記号 (#) またはパーセント記号 (%) のいずれかで始まる名前を持つファイルへのシンボリック記号は作成しないでください。キャッシュ・マネージャーはそのようなリンクを、それぞれ標準ボリュームまたは読み取り / 書き込みボリュームに対するマウント・ポイントと解釈します。
アプリケーションがファイルに対して UNIX の close システム呼び出しを発行すると、キャッシュ・マネージャーは、そのファイルの最重要コピーを保守しているファイル・サーバーにデータを同期書き込みします。キャッシュ・マネージャーは、ファイル・サーバーがそのデータの受け入れを許可してはじめて制御をアプリケーションに戻します。 fsync システム呼び出しの場合は、ファイル・サーバー・マシン上の不揮発性記憶域にデータを書き込んだことをファイル・サーバーが示してはじめてアプリケーションに制御が戻ります。
アプリケーションが UNIX の write システム呼び出しを発行すると、キャッシュ・マネージャーは変更をローカルの AFS クライアント・システムにだけ書き込みます。ローカル・マシンがクラッシュしたり、アプリケーションが close システム呼び出しを発行せずに終了した場合、ファイル・システムが保守しているファイルの最重要コピーに変更が記録されない可能性があります。キャッシュ・マネージャーはこのタイプの変更済みデータを、close または fsync システム呼び出しを受け取らずにキャッシュからファイル・サーバーに書き込むことがあります。たとえば、新規データをキャッシュに入れるために、キャッシュ・チャンクを解放する必要がある場合などです。ただし、一般には、いつキャッシュ・マネージャーが変更済みデータをこのようにしてファイル・サーバーに転送するかを予測することはできません。
これが言外に意味していることは、アプリケーションのSave オプションが close または fsync ではなく、write システム呼び出しを発行した場合、変更が必ずしもファイル・サーバー・マシンに永続的に保管されるとは限らないということです。ほとんどのアプリケーション・プログラムは、ファイル処理を終了する場合およびプログラムを終了する場合だけでなく、保管操作の場合も close システム呼び出しを発行します。
UNIX の setuid ビットは、ローカルのスーパーユーザー root だけに設定してください。これによって、セキュリティー上のリスクが自動的に発生することはありません。ローカルのスーパーユーザーは AFS には特権を持っていません。ローカル・マシンの UNIX ファイル・システムおよびカーネルにのみ特権を持っています。
任意のファイルに setuid ビットでマークすることができますが、chown システム呼び出しまたは /etc/chown コマンドを発行できるのは、system:administrators グループのメンバーだけです。
fs setcell コマンドによって、外部のセルで発信する setuid プログラムを、与えられたクライアント・マシンで実行できるかどうかが決定します。 クライアントが Setuid プログラムを実行できるかどうかを決定する を参照してください。
この機能グループでは、セル名の選択方法と適切なセル名を選択することが重要な理由を説明します。
セル名は、セルを AFS グローバル・ネーム・スペースにあるほかのすべての名前から区別しなければなりません。通例、セル名はどの AFS パス名においても 2 番目の要素になります。したがって、セルがローカルの AFS ファイル・スペースの下位レベルにおいて同じディレクトリー名を使用していたとしても、固有のセル名により、あらゆる AFS パス名がファイルを一意に識別することが保証されます。たとえば、ABC Corporation セルと State University セルの両方が、ユーザー pat のホーム・ディレクトリーをもつことができます。 /afs/abc.com/usr/pat と /afs/stateu.edu/usr/pat のようにパス名が異なるからです。
規則では、セル名は、サイト名のための ARPA インターネット・ドメイン・システムの規則に従います。すでにインターネット・サイトにいる場合には、インターネット・ドメイン名をセル名として選択するのが最も簡単です。
インターネット・サイトにいない場合、特に、近い将来インターネットに接続する予定である場合には、固有のインターネット・スタイルの名前を選択するのが最適です。AFS プロダクト・サポートは、適切な名前を選択する際に役立てるために使用できます。 AFS のセル名には、以下のようないくつかの制約があります。
NIC では、ユーザーのセル名をインターネット・ドメイン名として登録するために必要な形式も提供します。管理者名を登録すると、その後では別のインターネット・サイトはその名前を選ぶことができなくなります。
セル名は、それぞれのファイル・サーバーとクライアント・マシンのローカル・ディスクの 2 つのファイルに記録されます。ほかの機能の中で、これらのファイルがマシンのセル・メンバーシップを定義するため、プログラムとプロセスをマシンで実行する方法に影響を及ぼします。 適切なセル名を選択することが重要な理由 を参照してください。セル名の設定の手順は、マシンの 2 つのタイプによって、異なります。
ファイル・サーバー・マシンの場合、セル名を記録する 2 つのファイルは、/usr/afs/etc/ThisCell ファイルと /usr/afs/etc/CellServDB ファイルです。 AFS インストールの手引き でより明らかに説明したように、ユーザーのセルにインストールする最初のファイル・サーバー・マシンで bos setcellname コマンドを発行することによって、両方のファイルでセル名を設定します。コマンドを再度発行する必要は通常ありません。米国版の AFS を実行し、更新サーバーを使用する場合は、更新サーバーは、更新サーバー用の ThisCell ファイルと CellServDB ファイルのコピーを、インストールする追加サーバー・マシンに配布します。国際版の AFS を使用する場合は、AFS インストールの手引き に手動でそれらのファイルをコピーする方法が説明されています。
クライアント・マシンの場合、セル名を記録する 2 つのファイルは、/usr/vice/etc/ThisCell ファイルと /usr/vice/etc/CellServDB ファイルです。管理者は、これらのファイルを、クライアントごとをベースとして、テキスト・エディターを使用するか、それらのファイルを AFS の最重要ソースからマシンにコピーして作成します。詳細については、データベース・サーバー・マシンの情報を保持する を参照してください。
マシンを異なるセルに移動したいときにだけ、これらのファイルにあるセル名を変更します (同時に 1 つのセルにしか属することができません)。マシンがファイル・サーバーである場合には、新規のセルを構成するためには、AFS インストールの手引き の完全な一連の手順に従う必要があります。マシンがクライアントである場合には、実行する必要があるのは、ファイルを適切に変更し、マシンをリブートすることだけです。次の機能グループでは、既存のセル名の変更の負の結果について詳しく説明します。
ローカルの /usr/vice/etc/ThisCell ファイルを変更しないで、ほとんどの AFS コマンドが使用するデフォルトのセル名を設定するには、コマンド・シェルで AFSCELL 環境変数を設定します。外部セルで大量の管理作業を完成する必要がある場合には、この変数を設定するだけの価値はあります。
注: | fs checkservers コマンドと、 fs mkmount コマンドは、AFSCELL 変数を使用しません。fs checkservers コマンドは、 -cell 引き数を使用しないかぎり、常に ThisCell ファイルで命名されたセルをデフォルト指定します。fs mkmount コマンドは、新規のマウント・ポイントの親ディレクトリーが常駐するセルをデフォルト指定します。 |
長期間の使用に適したセル名を注意して選択してください。セル名を後で変更することは、複雑です。適切なセル名は重要です。それは、セル名は、セルのファイル・ツリーにあるすべてのファイルのパス名の 2 番目の要素だからです。各セル名は固有であるため、その名前が AFS パス名にあると、たとえ複数のセルが下位レベルで類似のファイル・スペース編成を使用していても、そのパス名は AFS グローバルネーム・スペースでは一意になります。たとえば、競合を引き起こすことなく、あらゆるセルが /afs/cellname/usr/pat というホーム・ディレクトリーをもつことができる、ということを意味しています。パス名の中にセル名があることは、そのファイルがユーザーのローカル・セルまたは外部セルのいずれに常駐しようと、あらゆるセルのユーザーが同じパス名を使用してファイルにアクセスすることも意味します。
セルをインストールするプロセスの早い時期に正しいセル名を選択する別の理由は、各マシンの ThisCell ファイルで定義されるセル・メンバーシップが、そのマシンで実行される多くのプログラムとプロセスのパフォーマンスに影響を及ぼすことです。たとえば、デフォルトでは、AFS コマンド (fs、kas、pts および vos コマンド) は、これらのコマンドが発行されるマシンのセルで実行されます。コマンド・インタープリターは、ローカル・ディスクで ThisCell ファイルを検査し、指示されたセルの CellServDB ファイルにリストされたデータベース・サーバー・マシンと交信します (bos コマンドの動作は異なります。発行者はコマンドを実行するマシンの名前を常に指定しなければならないからです)。
また ThisCell ファイルは、ユーザーがマシンにログインする際に、AFS トークンを受け取るためのセルも決定します。セル名は、セキュリティーの役割も果たします。セル名はユーザーのパスワードを暗号化鍵に変換して認証データベースに保管するので、認証サーバーはそのパスワードと、ThisCell ファイルにあるセル名を組み合わせます。 AFS で変更されたログイン・ユーティリティーは、同じアルゴリズムを使用して、ユーザーのパスワードを暗号化鍵にしてから認証サーバーに接続し、ユーザーのためのトークンを取得します。 (AFS のセキュリティー・システムがどのように暗号化鍵を使用するかについての説明は、相互認証の詳細 を参照してください。)
パスワードを暗号化鍵に変換するこのメソッドは、結果として、同じパスワードが異なるセルの異なる鍵になることを意味しています。ユーザーが複数のセルで同じパスワードを使用していて、あるセルからユーザーのトークンを取得しても、別のセルにあるそのユーザーのアカウントには無許可ではアクセスできません。
セル名を変更した場合は、すべてのサーバーおよびクライアント・マシン上の ThisCell ファイルと CellServDB ファイルを変更しなければなりません。これらの変更のどれか 1 つでも失敗すると、ログインできなくなる場合があります。それは、ログイン・ユーティリティーで作成された暗号化鍵が、認証データベースに保管されている鍵と一致しないからです。さらに、AFS の組の多くのコマンドは、期待通りに動作しません。
AFS グローバル・ネーム・スペースに加わると、ユーザーのローカル・ファイル・ツリーをAFS ユーザーが外部のセルで見ることができるようになり、ほかのセルのファイル・ツリーをユーザーのローカル・ユーザーが見ることができるようになります。AFS グローバル・ネーム・スペースに加わることによって、セル間のファイルの共用が、セル内での共用と同じくらい簡単になります。この機能グループでは、グローバル・ネーム・スペースに加わるために必要な手順の概略を説明します。
AFS グローバル・ネーム・スペースは、その中に加わるすべての AFS セルと同じように見えます。それは、これらのすべてのセルは、パス名を組み立てる際の規則のスモール・セットに従うことに同意するからです。
最初の規則は、すべての AFS パス名を文字列 /afs で開始して、パス名が AFS グローバル・ネーム・スペースに属することを示す、というものです。
2 番目の規則は、セル名を AFS パス名の 2 番目の要素とする、というものです。すなわち、セル名はファイルが常駐する場所 (つまり、ファイル・サーバー・マシンがファイルを収容するセル) を示します。前述したように、パス名にセル名があると、グローバル・ネーム・スペースが可能になります。それは、AFS ファイル・スペースの下位レベルにある同じディレクトリー名をセルが使用しても、すべての AFS パス名は固有であることが保証されるからです。
パス名の 3 番目以下のレベルで表示される内容は、セルがそのファイル・スペースの配置を選択した方法によって異なります。3 番目のレベルには、示唆された基本ディレクトリーがいくつかあります。 3 番目のレベル を参照してください。
管理者は、セル名とデータベース・サーバー・マシンを公示することにより、セルを他のセルから見えるようにすることができます。ローカル・セルのクライアント・マシンと全く同じように、外部セルにあるマシン上のキャッシュ・マネージャーは、その情報を使用して、ボリュームおよびファイルの場所情報が必要になると、公示されたセルのボリューム・ロケーション (VL) サーバーにアクセスします。同様に、外部セルで実行しているクライアント側の認証プログラムはその情報を使用して、公示されたセルの認証サービスに接続します。
この情報を使用可能にすることができる場所は、2 つあります。
セルのリストをこのファイルで追加または変更するには、サイトの正式なサポート担当に、 AFS プロダクト・サポートに電話または書面で連絡するように依頼してください。このファイルには頻繁に変更が行われるため、 AFS プロダクト・サポートでは変更を毎回アナウンスすることはしていません。このファイルに変更が行われていないか定期的に確認することをお勧めします。
セルのデータベース・サーバー・マシンの識別を変更した場合は、必ずこれらのファイルを更新してください。また、(/usr/afs/etc ディレクトリー内の) すべてのサーバー・マシンと (/usr/vice/etc ディレクトリー内の) すべてのクライアント・マシン上の CellServDB ファイルのコピーを更新してください。手順については、サーバー CellServDB ファイルの保守 および データベース・サーバー・マシンの情報を保持する を参照してください。
データベース・サーバー・マシンを公示すると、公示したセルを再度不可視にすることは難しくなる可能性があります。CellServDB.local ファイルを自分で削除し、グローバル CellServDB ファイルから項目を削除するように、 AFS プロダクト・サポートに要請することができます。しかし、ほかのセルのローカルの CellServDB ファイルに、すでにその項目がある可能性があります。それらの項目を無効にするには、データベース・サーバー・マシンの名前または IP アドレスを変更しなければなりません。
ただし、セルは、表示できないようにしなくてもアクセス不能にすることができます。セルを外部のユーザーに対して完全にアクセス不能にするには、ファイル・スペースの上位 3 つのレベルで、すべての ACL から system:anyuser グループを除去します。 ユーザーのセルへの外部ユーザーのアクセスに対する許可と禁止 を参照してください。
外部セルのファイル・スペースをユーザーのセル内のクライアント・マシンで見ることができるようにするには、次の 3 つのステップを実行します。
あらゆるクライアント・マシンのローカル・ディスク上の /usr/vice/etc/CellServDB ファイルには、ローカル・セルと外部セルのデータベース・サーバー・マシンがリストされています。afsd プログラムは、キャッシュ・マネージャーを初期化するときに、CellServDB ファイルの内容を読み取ってカーネル・メモリーに入れます。また、fs newcell コマンドを使用すると、マシンのリブートとリブートの間に、カーネル・メモリーの項目を直接追加または更新できます。データベース・サーバー・マシンの情報を保持するを参照してください。
外部セルをクライアント・マシンが見ることができるようにしても、ユーザーがその外部セルのファイル・スペースにアクセスできる保証はありません。外部セル内の ACL が、必要なアクセス権をユーザーに許可しなければなりません。
AFS グローバル・ネーム・スペースでセルを可視にしても、外部セルのユーザーがファイル・ツリーにアクセスする方法を管理者が制御できなくなるわけではありません。
デフォルトでは、外部ユーザーはユーザー anonymous としてセルにアクセスします。このことは、外部ユーザーは各ディレクトリーの ACL で、system:anyuser グループに対して付与された許可しか持っていないことを意味します。通常、これらの許可は、l (検索) および r (読み取り) アクセス権に制限されています。
外部ユーザーに対してさらに広いアクセス権を認める方法としては、次の 2 つがあります。
この機能グループでは、AFS ファイル・スペースを構成する際の考慮事項を要約します。ファイル・スペースのディレクトリー構造に最適な対応をするボリュームの作成に関する説明は、管理を簡単にするためのボリュームの作成 を参照してください。
Windows ユーザーへの注: Windows は、パス名の要素を区切るのに円記号 ( \ ) を使用し、スラッシュ (/) を使用しません。ただし、ファイル・スペースの階層構成は UNIX マシンの場合と同じです。
AFS パス名は多少の規則に従わなければなりません。これは、AFS グローバル・ネーム・スペースが AFS クライアント・マシンから同じように見えるようにするためです。ファイル・ツリーを作成する際に従わなければならない対応する規則があります。これは、パス名がファイル・ツリーの構造を反映するだけでなく、 AFS キャッシュ・マネージャーが一定の構成を予期するためです。
1 番目の規則は、ファイル・ツリーの最上位のレベルを /afs ディレクトリーと呼ぶことです。それ以外の名前を付ける場合には、 -mountdir 引き数を指定した afsd プログラムを使用して、キャッシュ・マネージャーが AFS を正しく取り付けるようにしなければなりません。その場合、 AFS グローバル・ネーム・スペースに参加することはできません。
2 番目の規則は、/afs ディレクトリーのすぐ下に、ローカル・セルからファイル・ツリーを見たりアクセスしたりできる、それぞれのセルに対応するディレクトリーを配置しなければならないことです。最小限でも、ローカル・セルのディレクトリーがなければなりません。このようなディレクトリーのそれぞれは、指示されたセルの root.cell ボリュームに対するマウント・ポイントになります。たとえば、 ABC Corporation セルでは、 /afs/abc.com はこのセル自体の root.cell ボリュームのマウント・ポイントであり、 stateu.edu は、 State University セルの root.cell ボリュームのマウント・ポイントです。fs lsmount コマンドはマウント・ポイントを表示します。
% fs lsmount /afs/abc.com '/afs/abc.com' is a mount point for volume '#root.cell' % fs lsmount /afs/stateu.edu '/afs/stateu.edu' is a mount point for volume '#stateu.edu:root.cell'
パス名に必要な入力の量を少なくするために、ユーザーが頻繁にアクセスするセル (特にホーム・セル) のマウント・ポイントに、省略した名前を持つシンボリック・リンクを作成することができます。たとえば、ABC Corporation セルの場合、 /afs/abc は /afs/abc.com マウント・ポイントを指すシンボリック・リングです。これは fs lsmount コマンドで確認できます。
% fs lsmount /afs/abc '/afs/abc' is a symbolic link, leading to a mount point for volume '#root.cell'
ユーザーが希望する任意の方法で、ユーザーのセルのファイル・ツリーの 3 番目のレベルを編成することができます。以下のリストでは、一般的な構成でこのレベルに現れるディレクトリーを説明しています。
たとえば、ほかのセルが、このディレクトリーの etc サブディレクトリーで見つかると予想しているファイルには、以下のファイルがあります。
そのような各ディレクトリー内に、bin、etc、usr、などの名前のディレクトリーを作成し、通常ローカル・ディスク上の /bin、/etc および /usr ディレクトリーに保持されているプログラムを保管します。次に、クライアント・マシンのローカル・ディレクトリーから AFS へのシンボリック・リンクを作成します (ローカル・ディスクの構成 を参照してください)。たとえ、この方法でシンボリック・リンクを使用することを選択しない場合でも、 AFS のシステム・バイナリーの中央コピーを持つことが便利なことがあります。バイナリーが間違ってマシンから除去される場合には、テープからそれを回復しなければならないのではなく、 AFS からローカル・ディスクにコピーを取り直すことができます。
ユーザーのセルがかなり大きい場合には、すべてのホーム・ディレクトリーを単一の usr ディレクトリーに入れると、ディレクトリー検索が遅くなることがあります。ユーザーのホーム・ディレクトリーを複数のグループ化ディレクトリーに分散させることに関する提案は、 ホーム・ディレクトリーのグループ化 を参照してください。
この機能グループでは、ユーザーのシステムの管理を容易にする方法でボリュームを作成する方法について説明します。
ユーザーのファイル・ツリーの上位のレベル (少なくても 3 番目のレベルまで) では、一般的に、それぞれのディレクトリーは別々のボリュームに対応します。セルの中には、別々のボリュームとして、 3 番目のレベルのディレクトリーのいくつかに、サブディレクトリーを作成するものもあります。一般的な例は、/afs/cellname/common および /afs/cellname/usr ディレクトリーです。
ツリーのすべてのディレクトリー・レベルに別のボリュームを作成する必要はありませんが、そうする方が、各ボリュームは、ロード・バランシングのためにはより小さくより移動しやすくなるという利点があります。マウント・ポイントのオーバーヘッドは、標準ディレクトリーのものより大きくありません。また、ボリューム構造そのものも多量のディスク・スペースを必要としません。ほとんどのセルでは、ツリーの 4 番目のレベルの下で、それぞれのディレクトリーに別々のボリュームを使用することは、もう有効ではないことが分かります。たとえば、各ユーザーのホーム・ディレクトリー (ツリーの 4 番目のレベルの) は、別々のボリュームに対応している一方で、通常、ホーム・ディレクトリーにあるすべてのサブディレクトリーは、同じボリュームに常駐しています。
ツリーの指定された位置では、1 つのボリュームしか取り付けられないことに留意してください。それとは反対に、ボリュームを複数の場所に取り付けることもできますが、これはお勧めできません。そのようにするとファイル・ツリーの階層的な性質がゆがめられ、混乱の原因になる可能性があるからです。
次に示す制約に従えば、ボリュームにはどのような名前でも付けることができます。
これらの名前から逸脱すると、混乱と余分な作業が発生するだけです。たとえば root.afs ボリュームの名前を変更するということは、代替ボリュームに名前を付けるために、すべてのクライアント・マシン上の afsd プログラムに -rootvol 引き数を使用しなければならない、ということです。
同様に、root.cell ボリュームの名前を変更すると、ファイル・スペース内のセルのマウント・ポイントが標準の root.cell 名を使用していれば、外部セルのユーザーがファイル・スペースにアクセスできなくなります。もちろん、これはセルを他のセルから見えなくしてしまう方法ではありますが。
ボリュームには、そのボリュームに含まれるデータのタイプを示すボリューム名を割り当て、類似の内容を持つボリュームには類似の名前を使用するのが最適です。ボリューム名は、ボリュームを取り付けるディレクトリーの名前に似ている (少なくても、共通の要素をもっている) 場合も、役に立ちます。このパターンを理解しておけば、ボリュームに含まれている内容とそれが取り付けられている場所を正確に推測することができます。
多くのセルは、最も効果的なボリューム命名体系は、すべての関連したボリュームに共通の接頭部を書き込むことだということに気付きます。表 1 では、推奨される接頭部変換について説明します。
接頭部 | 内容 | 名前の例 | マウント・ポイントの例 |
---|---|---|---|
common. | 一般的なプログラムとファイル | common.etc | /afs/cellname/common/etc |
src. | ソース・コード | src.afs | /afs/cellname/src/afs |
proj. | プロジェクト・データ | proj.portafs | /afs/cellname/proj/portafs |
test. | テストあるいは他の一時データ | test.smith | /afs/cellname/usr/smith/test |
user. | ユーザーのホーム・ディレクトリーのデータ | user.terry | /afs/cellname/usr/terry |
sys_type. | オペレーティング・システムのタイプ用にコンパイルされたプログラム | rs_aix42.bin | /afs/cellname/rs_aix42/bin |
表 2 は、セルの rs_aix42 システム・ボリュームとディレクトリーの、より具体的な例です。
例の名前 | 例のマウント・ポイント |
---|---|
rs_aix42.bin | /afs/cellname/rs_aix42/bin/afs/cell/rs_aix42/bin |
rs_aix42.etc | /afs/cellname/rs_aix42/etc |
rs_aix42.usr | /afs/cellname/rs_aix42/usr |
rs_aix42.usr.afsws | /afs/cellname/rs_aix42/usr/afsws |
rs_aix42.usr.lib | /afs/cellname/rs_aix42/usr/lib |
rs_aix42.usr.bin | /afs/cellname/rs_aix42/usr/bin |
rs_aix42.usr.etc | /afs/cellname/rs_aix42/usr/etc |
rs_aix42.usr.inc | /afs/cellname/rs_aix42/usr/inc |
rs_aix42.usr.man | /afs/cellname/rs_aix42/usr/man |
rs_aix42.usr.sys | /afs/cellname/rs_aix42/usr/sys |
rs_aix42.usr.local | /afs/cellname/rs_aix42/usr/local |
この体系には、いくつかの利点があります。
セルが、実用上問題のないくらい十分に大きい場合は、関連するボリュームをグループ化して 1 つの区画にまとめることを考えてください。一般的には、ボリュームのグループ化を効果的に行うためには、少なくても 3 つのファイル・サーバー・マシンが必要です。グループ化にはいくつかの利点があります。ファイル・サーバー・マシンがアクセス不能になる場合にその利点が最も顕著に現れます。
関連したボリュームを区分でグループ化することの利点は、必然的に、関連したすべてのボリュームを 1 つのファイル・サーバー・マシンでグループ化するまでに及ぶわけではありません。たとえば、一方のマシンにすべてのシステム・ボリュームを置き、他方のマシンにすべてのユーザー・ボリュームを置くというのは、 2 つのファイル・サーバー・マシンをもつセルではおそらく不得策です。どちらかのマシンが故障すると、すべての人に影響を及ぼすと考えられます。
実をいえば、ロード・バランシングの目的のためにボリュームを移動する必要があることで、関連したボリュームのグループ化の実用性を制限することができます。補足的な利点を事例ごとに評価する必要があります。
複写 で説明したように、複写とは、読み取り / 書き込みソース・ボリュームのコピー、すなわち複製を作成し、次にそのコピーを 1 つ以上の追加ファイル・サーバー・マシンに置くことを指します。ボリュームを複写すると、内容の可用性が向上します。ボリュームを収容している 1 つのファイル・サーバー・マシンがアクセス不能になっても、ユーザーは別のマシンに保管されているそのボリュームのコピーにアクセスすることができます。どのマシンも、アクセスの多いファイルに対する要求で煩わされるようになることはありません。これは、複数のマシンからファイルを使用することができるからです。
ただし、複写はすべてのセルに適しているわけではありません。セルにディスク・スペースの余裕がない場合には、複写は必要以上に高くつくことがあります。それは、読み取り / 書き込みソースと同じ区画にない各複製は、それが作成されたときに、そのソース・ボリュームが占めていたのと同じサイズのディスク・スペースを占有するからです。また、1 つのファイル・サーバー・マシンしかない場合には、可用性を増加させることなく、複写でディスク・スペースを使い果たします。
複写は頻繁に変更されるボリュームにも適していません。読み取り専用ボリュームを更新して、変更をそのボリュームの読み取り / 書き込みソースに反映させる必要が生じるたびに、vos release コマンドを発行しなければなりません。
このような両方の理由から、複写が適しているのは、システム・バイナリーや、ファイル・スペースの高位レベルに取り付けられた他のボリュームなど、それほど頻繁には変更されることのない内容を持つ一般的なボリュームです。通常ユーザー・ボリュームは頻繁に変更されるために、読み取り / 書き込みバージョンにのみ存在します。
ボリュームを複写する場合は、(セルに 2 つあるいは 3 つのファイル・サーバー・マシンしかない場合でも) できればそれぞれ 2 つまたは 3 つのサイトにある root.afs および root.cell ボリュームを複写しなければなりません。キャッシュ・マネージャーは、任意のパス名を解釈するときに、 root.afs ボリュームと root.cell ボリュームに対応するディレクトリーに移動する必要があります。これらのボリュームを使用できない場合は、他のボリュームを保管しているファイル・サーバー・マシンが機能していたとしても、他のボリュームを使用できなくなります。
root.afs ボリュームを複写するもう 1 つの理由は、ファイル・サーバー・マシンの負荷を削減できることです。キャッシュ・マネージャーは、root.afs ボリュームが複写の場合にはそれにアクセスする傾向があります。そのため、キャッシュ・マネージャーは AFS ファイル・スペースの 読み取り専用パス におかれます。キャッシュ・マネージャーは、読み取り専用パスにある間は、複写されたボリュームの読み取り専用コピーにアクセスしようとします。ファイル・サーバーは、読み取り専用ボリュームにあるすべてのデータに対して、キャッシュ・マネージャーごとにコールバックを 1 つだけ追跡する必要があります。これに対して、読み取り / 書き込みボリュームに対してはファイルごとに 1 つのコールバックを追跡しなければなりません。コールバックが少ない方が、ファイル・サーバーへの負荷が軽くなります。
root.afs ボリュームが複写されていなければ、キャッシュ・マネージャーがファイル・スペース内で読み取り / 書き込みパスをたどり、各ボリュームの読み取り / 書き込みボリュームにアクセスします。ファイル・サーバーは読み取り / 書き込みボリューム内のファイルごとに異なるコールバックを配布し、追跡して、このボリュームにさらに大きな負荷をかけます。
読み取り / 書き込みパスと読み取り専用パスの詳細は、マウント・ポイント横断の規則を参照してください。
多くの場合、/afs/cellname/usr ディレクトリーに対応するボリュームと /afs/cellname/common ディレクトリーとそのサブディレクトリーに対応するボリュームと同様、システム・バイナリー・ボリュームを複写することも意味のあることです。
複写を読み取り / 書き込みソースと同じ区画に配置するのも良い考えです。この場合、読み取り専用ボリュームは (バックアップ・ボリュームと同様) 複製です。このボリュームはボリュームの内容の完全コピーではなく、ソース・ボリュームの vnode index のコピーです。読み取り / 書き込みボリュームが別の区画に移動した場合、あるいは大きな変更が加えられた場合に限り、読み取り専用ボリュームは大量のディスク・スペースを消費します。他の区画に保持されている読み取り専用ボリュームは、常に、読み取り専用ボリュームの作成時に読み取り / 書き込みソースが消費したディスク・スペースの量をすべて消費します。
あらゆる AFS ボリュームには、使用できるディスク・スペースの量を制限する割り当て量があります。割り当て量を設定し、変更するには、ボリューム割り当て量および現行サイズの設定および表示 で説明されているコマンドを使用します。
vos create コマンドに -maxquota 引き数を組み込んでいないかぎり、デフォルトでは、あらゆる新規のボリュームには 5000 KB ブロックのスペース割り当て量が割り当てられます。同じくデフォルトで、新規に作成されたすべてのボリュームのルート・ディレクトリーにある ACL は、 system:administrators グループのメンバーに全アクセス権を付与します。個々のコマンドでアカウントを作成するときにこれらの値を変更する方法については、個別のコマンドを使用して単一ユーザー・アカウントを作成する を参照してください。 uss コマンドを使ってアカウントを作成するときは、代替 ACL と代替割り当て量の値をテンプレート・ファイルの V 命令に指定します。 V 命令によるボリュームの作成 を参照してください。
このセクションでは、AFS データを保管し、それを要求時にクライアント・マシンに転送し、そして AFS 管理データベースを収容するサーバー・マシンを構成する際に考慮しておかなければならない問題について検討します。クライアント・マシンについて確認するには、クライアント・マシンの構成 を参照してください。
セルに複数の AFS サーバーがある場合には、そのサーバーを構成して、特別な機能を実行することができます。マシンは、以下のリストで説明されている役割を 1 つ以上担うことができます。詳しくは、ファイル・サーバー・マシンの 4 つの役割 を参照してください。
AFS インストールの手引き では、4 つの役割すべてを担う、セルの最初のファイル・サーバー・マシンを構成する方法について説明しています。 AFS インストールの手引き の章では、追加サーバー・マシンのインストールの他に、1 つ以上の役割を実行するようにそれらのマシンを構成する方法についても説明しています。
AFS 管理データベースは、データベース・サーバー・マシン上に保持されており、セルが正常に機能するために必要な情報を保管しています。サーバー・プロセスおよびキャッシュ・マネージャーは頻繁にその情報にアクセスします。
最初のマシンが、データベース・サーバー・マシンとして使用する予定のあるマシンの最低位の IP アドレスを持っている場合は、セルの保守が最も簡単になります。低位アドレスをもつマシンをデータベース・サーバー・マシンとして使用することを後で決めると、新規マシンを導入する前に、すべてのクライアントで CellServDB ファイルを更新しなければなりません。
セルに複数のサーバー・マシンがある場合は、複数のマシンをデータベース・サーバー・マシンとして実行するのが最適です (ただし、4 台以上のマシンを実行する必要はほとんどありません)。この方法で管理データベースを複写すると、ボリュームの複写と同じ利点、すなわち可用性と信頼性の向上が生まれます。 1 つのデータベース・サーバー・マシンあるいはプロセスが機能を停止しても、他のマシンからはデータベース内の情報を使用することができます。データベース情報に対する要求のロードが複数のマシンに分散し、いずれのマシンも過負荷になることがないようにします。
ただし、複写されたボリュームと異なり、複写されたデータベースは頻繁に変更されます。一貫したシステム・パフォーマンスを得るためには、データベースのすべてのコピーが常に同一であることが要求されるので、変更をそれらのコピーの一部にだけ記録することはできません。データベースのコピーを同期化するために、データベース・サーバー・プロセスでは、 AFS の分散データベース・テクノロジーである Ubik を使用します。 AFS 管理データベースの複写 を参照してください。
セルにファイル・サーバー・マシンが 1 つしかない場合、ファイル・サーバー・マシンはデータベース・サーバー・マシンとしても機能しなければなりません。セルにファイル・サーバー・マシンが 2 つある場合、両方をデータベース・サーバー・マシンとして実行することには必ずしも利点がありません。サーバー、プロセス、あるいはネットワークの障害により、2 つのマシン上のデータベース・サーバー・プロセス間の通信が途絶えた場合は、どちらのマシンも単独で自らを同期サイトとして立ち上げることができないため、データベース内の情報を更新することは不可能になります。
プロセスの一部がマシン上でアクティブに実行されなくても、すべてのファイル・サーバー・マシン上の /usr/afs/bin ディレクトリーにすべての AFS サーバー・プロセスのバイナリーを保管するのが一般には最も簡単です。これによって、新規の役割を果たすためにマシンを再構成することが簡単になります。
セキュリティー上の理由から、ファイル・サーバー・マシン上の /usr/afs ディレクトリーとそのサブディレクトリーおよびファイルはすべて、ローカルのスーパーユーザー root が所有し、最初の w (書き込み) モード・ビットのみをオンにしなければなりません。ファイルによっては 最初の r (読み取り) モード・ビットだけをオンにしているものもあります (たとえば、AFS サーバーの暗号化鍵をリストする /usr/afs/etc/KeyFile ファイル)。 BOS サーバーは、開始する度に、特定のファイルおよびディレクトリーのモード・ビットが、期待されている値に一致するかどうかを検査します。リストについては、機密の AFS ディレクトリーの保護に関する AFS インストールの手引き セクション、あるいは、サーバー・プロセスの状況とその BosConfig 項目を表示する方法 の bos status コマンドの結果に関する説明を参照してください。
ファイル・サーバー・マシンのローカル・ディスク上のすべての AFS ディレクトリーの内容の説明については、サーバー・マシンの管理 を参照してください。
ファイル・サーバー・マシンに AFS ボリュームを収容する区分は、以下の名前が付いたディレクトリーに取り付けなくてはなりません。
/vicepindex
ここで、index は、1 文字または 2 文字の小文字です 通例、最初に作成された AFS 区画は、/vicepa ディレクトリーに取り付けられ、2 番目の AFS 区画は /vicepb ディレクトリーに取り付けられる、というように /vicepz ディレクトリーまで取り付けられます。このようにして名前は /vicepaa から /vicepaz まで、/vicepba から /vicepbz までというように、サーバー区画のサポート数 (AFS Release Notes で指定されています) まで続きます。
各 /vicepx ディレクトリーは、区画全体あるいは論理ボリュームに対応しなければなりません。また、ルート・ディレクトリー (/) のサブディレクトリーでなければなりません。 (たとえば) /usr 区画の一部を AFS サーバー区画として構成し、それを /usr/vicepa というディレクトリーに取り付けることはできません。
また、非 AFS ファイルは AFS サーバー区画には保管しないでください。ファイル・サーバーおよびボリューム・サーバーは、パーティション上のすべてのスペースが使用可能であると予期します。 UNIX ファイルが頻繁に使用される場合は特にそうですが、AFS ファイルとローカルの UNIX ファイルがその区画にアクセスする場合には、その両ファイル間で競合が生じます。
AFS は、scout プログラムおよび afsmonitor プログラムをはじめとする、ファイル・サーバーをモニターするためのツールをいくつか提供しています。これらのツールは、特定のしきい値を超えた場合に、たとえばサーバー区画が全体の 95% を超えた場合に、警告を発するように構成することができます。 AFS パフォーマンスのモニターおよび監査 を参照してください。
ファイル・サーバー・マシンをリブートするには AFS プロセスを終了する必要があるので、必然的にサーバーが停止してしまいます。ファイル・サーバー・マシンのリブートは、できるだけ少なくしてください。説明については、 サーバー・マシンのリブート を参照してください。
デフォルトでは、1 週間に一度、日曜日の午後 4 時に、各ファイル・サーバー・マシンの BOS サーバーが停止し、そのマシンの (マシン自身を含め) のすべての AFS サーバー・プロセスが即時に再始動します。これによって、延長時間に任意のプロセスが実行されるようになるかもしれない、コア・リークの可能性が削減されます。
BOS サーバーは、毎朝 5 時に、 /usr/afs/bin ディレクトリーに新規にインストールされたバイナリー・ファイルを検査します。 BOS サーバーは各バイナリー・ファイルのタイム・スタンプを、該当するプロセスが最後に再始動した時刻と比較します。バイナリー・ファイルのタイム・スタンプの方が後の場合は、BOS サーバーはそのバイナリー・ファイルを使用して、開始すべき該当するプロセスを再始動します。
デフォルトの時刻は、プロセスの再始動により生じる停止により妨害を受ける人の数がおそらくは最も少ないであろう早朝になっています。 bos getrestart コマンドを使用すると、マシンごとに再始動時刻を表示することができます。さらに、bos setrestart コマンドを使用して再始動時刻を設定することができます。後者のコマンドを使用すると、時刻を never に設定することによって、自動再始動を完全に使用不可にすることができます。BOS サーバーの再始動時を設定するを参照してください。
この機能グループでは、クライアント・マシンをセルにインストールして構成する際の考慮事項について要約します。
標準 UNIX ファイルを AFS に保管し、ローカル・ディスクからそれらのファイルへのシンボリック・リンクを作成することにより、多くの場合 AFS クライアント・マシン上のローカルのディスク・スペースのかなりのサイズを解放することができます。@sys パス名変数は、システム固有のファイルへのリンクで役に立ちます。パス名での @sys 変数の使用 を参照してください。
実際にローカル・ディスク上に常駐しなければならないファイルには、afsd プログラムを呼び出す前に必要になるブート・シーケンス・ファイルと、ファイル・サーバー・マシンの停止中に役立てることのできるファイルの 2 つのタイプがあります。
リブート中は、afsd プログラムがキャッシュ・マネージャーを実行してそれを初期化するまで、AFS はアクセス不能になっています。 (標準構成では、マシンの初期化シーケンスには AFS 初期化ファイルが含まれており、このファイルが afsd プログラムを呼び出しています。) リブート中のその時点よりも前に必要なファイルは、ローカル・ディスクに常駐しなければなりません。これらのファイルには、以下のファイルが含まれますが、このリストは必ずしもすべてを網羅しているわけではありません。
これらのファイルに関する詳細については、ローカル・ディスク上の構成ファイルおよびキャッシュ関連ファイル を参照してください。
ローカルのディスク上に保持されるその他のタイプのファイルとプログラムは、ファイル・サーバーの停止によって引き起こされる問題を診断し、修正する場合に必要となるものです。それは、ファイル・サーバーの停止により AFS に保管されているコピーにアクセスできなくなるからです。例には、テキスト・エディター (ed あるいは vi など) と fs および bos コマンドのためのバイナリーが含まれています。 AFS コマンドのバイナリーのコピーは、/usr/afsws ディレクトリー (これは通常 AFS へのリンクになっています) に含めると共に、/usr/vice/etc ディレクトリーに保管してください。次に、/usr/afsws ディレクトリーを、ユーザーの PATH 環境変数の定義の /usr/vice/etc ディレクトリーの前に挿入してください。 AFS が正常に機能していれば、ユーザーは /usr/afsws ディレクトリー内のコピーにアクセスします。こちらのコピーの方がローカルのコピーよりも新しい可能性が高いと考えられます。
ローカル・ディスクの内容を更新して、構成ファイルに一致させる package プログラムを使用すると、クライアント・マシンのローカル・ディスクの構成を自動化することができます。パッケージ・プログラムを使用したクライアント・マシンの構成を参照してください。
ユーザーのセルでほかのセルを見ることができるようにする で詳説したように、キャッシュ・マネージャーを使用すると、ローカルの /usr/vice/etc/CellServDB ファイルにある、セルのデータベース・サーバー・マシンのリストを保管することにより、そのセルの AFS ファイル・スペースにアクセスすることができます。キャッシュ・マネージャーは、そのリストの取り出しをより高速に行うために、リブート時にそのリストをカーネル・メモリーに読み込みます。 fs newcell コマンドを使用すると、リブートとリブートの間に、カーネル・メモリー内のリストを変更することができます。 CellServDB ファイルの最重要バージョンを AFS に保管し、package プログラムを定期的に使用して各クライアントのバージョンをソース・コピーで更新すると実際に役に立つことがよくあります。データベース・サーバー・マシンの情報を保持するを参照してください。
各クライアント・マシンは、CellServDB ファイルのそのマシン用のコピーを保守しているので、理論上は、別のクライアント・マシン上の別の外部セルにアクセスすることができます。ただし、通常はこれでは実際の役には立ちません。特にユーザーが常に同じマシン上で作業をしているわけではないような場合にはそうです。
ローカル・ディスク上の AFS にシンボリック・リンクを作成する場合には、パス名に @sys 変数を使用すると役に立つことがよくあります。キャッシュ・マネージャーは @sys を自動的にローカル・マシンの AFS システム名 (CPU/オペレーティング・システムのタイプ) で置き換えます。これは、さまざまなタイプのマシン上に同じリンクを配置しても、各マシンから、そのシステム・タイプのバイナリーにアクセスできることを意味します。たとえば、AIX 4.2 を実行しているマシン上のキャッシュ・マネージャーは、/afs/abc.com/@sys を /afs/abc.com/rs_aix42 に変換し、Solaris 7 を実行しているマシンは、それを /afs/abc.com/sun4x_57 に変換します。
@sys 変数を使用したい場合は、AFS Release Notes で指定されている標準名の AFS システム・タイプ名を使用するのが最も簡単です。キャッシュ・マネージャーは、初期化時にカーネル・メモリーにローカル・マシンのシステム・タイプ名を記録します。標準名を使用しない場合は、キャッシュ・マネージャーの初期化直後に、関連するシステム・タイプのすべてのクライアント・マシン上で、fs sysnameコマンドを使用してカーネル・メモリー内の値をそのデフォルトから変更しなければなりません。 fs sysname コマンドは現行値も表示します。システム・タイプ名の表示および設定 を参照してください。
AFS ファイル・スペースそれ自体にあるパス名では、@sys 変数は注意して使用し、かつあまり使用しないようにしてください。それは、この変数を使用すると予期しない結果になりかねないからです。一般には、この変数はファイル・スペースの 1 つのレベルだけに限定して使用するのが最適です。3 番目のレベルを選択するのが一般的です。それは、このレベルには多くのセルが異なるマシン・タイプ用のバイナリーを保管するからです。
パス名に @sys 変数の複数のインスタンスがある場合、(たとえば cd コマンドを使用して) ディレクトリーを、作業しているマシン以外のシステム・タイプのバイナリーを保管しているディレクトリーに移動する人 (そのようなディレクトリーを保守する管理者あるいは開発者) には特に危険です。このような人々には、ディレクトリーを変更した後、希望するディレクトリーにいることを検証するようにお勧めします。
キャッシュ・マネージャーは、ファイル・サーバー・マシンのプリファレンスの表をカーネル・メモリーに保管します。プリファレンスのランクは、ファイル・サーバー・マシンのインターフェースの IP アドレスと、1 から 65,534 までの範囲の整数をペアにします。ファイルにアクセスする必要が生じた場合は、キャッシュ・マネージャーはそのファイルを収容しているすべてのマシンのインターフェースのランクを比較し、最初に、最も高いランクを持つインターフェースを介してそのファイルにアクセスしようとします。キャッシュ・マネージャーは、初期化時に、ネットワーク・トポロジーから見てキャッシュ・マネージャーに近いインターフェースを介してファイルにアクセスしやすくするよう、バイアスをかけるデフォルトのランクを設定します。パフォーマンスの改良を望むのであれば、プリファレンスのランクを調整すればそれも可能です。
キャッシュ・マネージャーは、ボリューム・ロケーション (VL) サーバー・マシンに対しても類似のプリファレンスを使用します。プリファレンスのランクを表示するには、fs getserverprefs を使用してください。また、プリファレンスのランクを設定するには、fs setserverprefs コマンドを使用してください。サーバーのプリファレンス・ランクの保守を参照してください。
この機能グループでは、AFS ユーザー・アカウントを構成する際の考慮事項を説明します。AFS は UNIX のファイル・システムとは分離されているため、ユーザーの AFS アカウントはそのユーザーの UNIX のアカウントとは分離されています。
ユーザー・アカウントの作成のための望ましい方法は、uss 組のコマンドを使用することです。アカウントの作成を手引きするテンプレート・ファイルを準備した後、単一のコマンドを使い、 1 つまたはたくさんのアカウントのすべてのコンポーネントを作成することができます。uss コマンド組によるユーザー・アカウントの作成と削除 を参照してください。
あるいは、アカウントの各コンポーネントを作成する個々のコマンドを発行することができます。そのための手順と、ユーザー・アカウントの削除、およびユーザーのパスワード、ユーザーのボリューム割り当て量、そしてユーザー名の変更のための手順については、ユーザー・アカウントの管理 を参照してください。
ユーザーが自分のシステムを離れる場合には、アカウントを削除するのはよいポリシーです。これについての説明は、uss delete コマンドによる個別アカウントの削除 および ユーザー・アカウントの削除 にあります。
AFS のユーザー・アカウントは、以下のコンポーネントで構成されています。これらのコンポーネントは、AFS ユーザー・アカウントのコンポーネント で詳細に説明されています。
一部のコンポーネントを作成し、それ以外は作成しないようにすることにより、uss コマンド組によるユーザー・アカウントの作成と削除 で説明されている uss コマンドまたは ユーザー・アカウントの管理 で説明されているここのコマンドを使用して、異なる機能レベルのアカウントを作成することができます。機能レベルには以下のものが含まれます。
セル内に AFS を導入する前の UNIX のユーザー・アカウントを持つユーザーがいる場合は、それらユーザーのアカウントを AFS のアカウントに変換したいでしょう。この場合、主に以下に示した 3 つの項目を考慮する必要があります。
詳しくは、uss による既存の UNIX アカウントの変換 または 既存の UNIX アカウントの変換 を参照してください。
この機能グループでは、ユーザー名、AFS UID、ユーザー・ボリューム名およびマウント・ポイント名を選択するためのスキームを提案し、選択上のいくつかの制約事項の概略も説明します。
ユーザー名
AFS がユーザー名の形式に課す制約はごくわずかです。多くのユーティリティーとアプリケーションが 8 文字以下のユーザー名を処理することができるという理由と、一般には AFS のアカウントの多くのコンポーネントがその名前を含んでいるという 2 つの理由から、ユーザー名は短くしておくのが最適です。アカウントのコンポーネントは、保護および認証データベースの項目、ボリューム、およびマウント・ポイントを組み込んでいます。電子メールの送信システムによっては、ユーザー名をユーザーのメール・アドレスの一部にすることができます。ユーザー名は、ユーザーがクライアント・マシンにログインするときに入力する文字列でもあります。
一般にユーザー名として選ばれるのは、ラストネーム、ファーストネーム、イニシャル、あるいはそれらの組み合わせですが、数字が追加されることもあります。また、以下の文字は使用しないことが最適です。これらの文字の多くは、コマンド・シェルに対して特別な意味をもっています。
AFS UID と UNIX UID
AFS は固有の識別番号 AFS UID をすべてのユーザー名に関連付け、ユーザーの保護データベースの項目にそのマッピングを記録します。AFS の AFS UID は、ローカル・ファイル・システムの UNIX UID とよく似た機能を果たします。 AFS サーバー・プロセスおよびキャッシュ・マネージャーは、内部的にユーザー名ではなく AFS UID を使用して、ユーザーを識別します。
あらゆる AFS ユーザーは、UNIX UID も持っていなければなりません。この UNIX UID は、AFS ユーザーがログインする各クライアント・マシンのローカル・パスワード・ファイル (/etc/passwd または同等のファイル) に記録されています。 AFS UID および UNIX UID が一致していれば、管理およびユーザー両方の AFS アクセスは最も簡単です。 UID 一致の重要な結果の 1 つは、ls -l コマンドで報告される所有者が AFS ユーザー名と一致することです。
通常は、保護サーバーで保護データベース項目を作成するときに、 AFS UID を割り振ることを許可するのが最適です。ただし、ユーザー・アカウントを作成する pts createuser コマンドおよび uss コマンドの両方で、 AFS UID を明示的に割り当てることができます。これは 2 つの場合に適切です。
保護サーバーは、初めてセルの最初のファイル・サーバー・マシンで初期化後、デフォルト値で AFS UID の割り当てを開始します。ユーザー・アカウントを作成する前、または任意の時にデフォルトを変更するには、 pts setmax コマンドを使って max user id カウンターをリセットします。カウンターを表示するには、pts listmax コマンドを使用します。AFS UID および GID カウンターの表示および設定 を参照してください。
AFS は、32766 という 1 つの AFS UID をユーザー anonymous 用に予約しています。 AFS サーバーはこの識別と AFS UID を、ローカル・セルのトークンを所有していないユーザーに割り当てます。この AFS UID は、将来のリリースで変更されることがあるため、他のどのユーザーにも割り当てないでください。また、この AFS UID の現行値をプログラムまたはファイルの所有者フィールドにハードコーディングしないでください。
ユーザー・ボリューム名
どのボリューム名もそうですが、ユーザー・ボリュームの基本 (読み取り / 書き込み) 名の長さは、22 文字を超えることはできず、.readonly または .backup 拡張子を含むこともできません。管理を簡単にするためのボリュームの作成を参照してください。標準では、ユーザー・ボリューム名は user.username という形式をしています。 user. という接頭辞を使用すると、ボリュームの内容が識別しやすくなるだけでなく、単一の vos backupsys コマンドを発行することにより、すべてのユーザー・ボリュームのバックアップ・バージョンを作成するのが簡単になります。
マウント・ポイント名
通例、ユーザーのボリュームのマウント・ポイントの名前は、ユーザー名をとって付けられます。多くのセルは、 3 番目のレベル で説明したように、規則に従って、 /afs/cellname/usr ディレクトリーにユーザー・ボリュームを取り付けます。ただし非常に大きなセルの場合は、同じディレクトリーにすべてのユーザー・ボリュームを取り付けると、ディレクトリー検索が遅くなることがあります。そのための代替としては、次のセクションを参照してください。
/afs/cellname/usr ディレクトリーにユーザー・ボリュームを取り付けるというのは、ユーザーのホーム・ディレクトリーを /usr サブディレクトリーの下に置くという、標準 UNIX の慣例を AFS に適するように変えたものです。ただし、数百より多いユーザーがいるセルでは、すべてのユーザー・ボリュームを単一のディレクトリーに取り付けると、ディレクトリーの検索が遅くなることがあります。解決法は、ユーザー・ボリューム・マウント・ポイントをいくつかのディレクトリーに配布することです。これを完了するための代替のメソッドは、たくさんあります。
uss プログラムを使用してユーザー・アカウントを作成するときに、さまざまなスキームをインプリメントする方法に関する説明については、 G 命令によるユーザー・ホーム・ディレクトリーの均等配布 と V 命令によるボリュームの作成 を参照してください。
ユーザーのボリュームのバックアップ・バージョンを取り付けるのが、ユーザーが誤って除去または削除したデータをユーザー自身が復元できるようにするための簡単な方法です。バックアップ・バージョンは、ユーザーのホーム・ディレクトリーのサブディレクトリー (おそらく OldFiles というサブディレクトリー) に取り付けるのが通例ですが、他のスキームも可能です。一日に 1 回、新規のバックアップ・バージョンを作成して、その日に行われた変更を取り込み、前日のバックアップ・バージョンを新規のバックアップ・バージョンで上書きします。ユーザーは、管理者の助けがなくても常に前日のファイルのコピーを取り出すことができ、管理者はより緊急のタスクを処理する時間がとれます。
ユーザーは、自分のバックアップ・ボリュームのマウント・ポイントを削除したがることがあります。それは、バックアップ・ボリューム内の内容によってボリュームの割り当て量が減るとユーザーが誤解しているからです。そのような場合には、バックアップ・ボリュームは分離しているので、バックアップ・ボリュームがユーザー・ボリュームで使用するスペースは、マウント・ポイントに必要な量だけであることをユーザーに気付かせてください。
バックアップ・ボリュームの詳しい説明は、AFS データのバックアップ と バックアップ・ボリュームの作成 を参照してください。
UNIX 管理者としてのユーザーの経験から、ユーザーは多分ログインとシェルの初期設定ファイル (.login ファイルと .cshrc ファイルなど) を使ってアカウントを使いやすくすることに慣れているでしょう。
いくつかの AFS 固有のディレクトリーを、以下を含めて、ユーザーの PATH 環境変数の定義に追加しておくと実際に役に立つことがよくあります。
AFS を変更したログイン・ユーティリティーをユーザーが使用していない場合には、 .login ファイルの klog コマンドを呼び出すことがユーザーの役に立ち、ログインのパーツとして AFS トークンを獲得できるようにします。以下の例のコマンド・シーケンスでは、最初の行は文字列 klog を標準出力ストリームにそのまま繰り返します。その結果、2 行目を実行すると表示される Password: プロンプトの目的をユーザーが理解することができます。-setpag フラグは、プロセス認証グループ (PAG) をもつ新規トークンに関連します。このプロセス認証グループについては、 PAG による AFS トークンの識別 で詳しく説明しています。
echo -n "klog " klog -setpag
以下のコマンド・シーケンスは、 pagshコマンドは、PAG とトークンを関連付ける新規のシェルを fork することを除いて、同様の効果があります。
pagsh echo -n "klog " klog
ユーザーが AFS を変更したログイン・ユーティリティーを使用する場合には、このシーケンスは必要ありません。それは、このようなユーティリティーは、ユーザーをローカルでログオンすることと、 AFS トークンを獲得することの両方を行うからです。
AFS を使用すると、ユーザーは、他のユーザーあるいはマシンのグループを独自に定義することができます。そのグループは ACL に配置され、各ユーザーを個別にリストすることなく、同じアクセス権を多くのユーザーに許可します。グループの作成手順については、保護データベースの管理 を参照してください。
ユーザーに AFS ID 番号があるように、グループにも AFS ID 番号があります。ただし AFS のグループ ID (GID) は、負の整数であるのに対し、ユーザーの AFS UID は正の整数です。デフォルトでは、保護サーバーが新規のグループの AFS GID を自動的に割り振りますが、pts creategroup コマンドを発行すると、system:administrators グループのメンバーが GID を割り当てることができます。明示的に GID を割り当てる前に、その GID がまだ使用されていないことを検証するようにしてください。
グループは別のグループに属することはできませんが、グループ (所有グループ) が少なくとも 1 つのメンバーを持っている限り、別のグループあるいは自分自身さえも所有することができます。グループの現行の所有者は、新規の所有者の許可がなくても、グループの所有権を別のユーザーあるいはグループに移すことができます。その時点で、前の所有者は、グループに対する管理上の制御を失います。
デフォルトでは、それぞれのユーザーは、20 のグループを作成することができます。システム管理者は、 pts setfields コマンドでこのグループ作成割り当て量を増やすか、または減らすことができます。
各保護データベース項目 (グループまたはユーザー) は、項目の管理者と、管理者が行う管理内容を制限する 5 つのプライバシー・フラグ のセットで保護されます。デフォルトのプライバシー・フラグはかなり限定的ですが、ユーザー項目に対しては特に限定的です。データベース項目のプライバシー・フラグを設定 を参照してください。
保護サーバーは、セルの最初のデータベース・サーバー・マシンではじめて初期化を行う際に、system:anyuser、system:authuser、および system:administrators グループという 3 つのグループ項目を自動的に作成します。
最初の 2 つのシステム・グループは、保護データベースにあるほかのグループとは異なります。ほかのグループは、保護データベース内で継続的なメンバーシップをもっていません。
このグループは継続的なメンバーシップを持っていないので、 pts membership コマンドはこのグループに対しては何の出力も生成しません。同様に、このグループはユーザーが属するグループのリストにも表示されません。
system:administrators グループには、継続的メンバーシップはありません。このグループは特権管理者で構成されます。このグループのメンバーは、任意の pts コマンドを発行できます。また、このメンバーだけが、いくつかのほかの制限付きコマンド (AFS ファイルの chown コマンドなど) を発行することができます。デフォルトでは、このグループは暗黙で a (管理者) および l (検索) アクセス権をファイル・スペースのすべての ACL に持っています。このデフォルトの変更については、 system:administrators グループの管理 を参照してください。
ACL でシステム・グループを効果的に使用する方法については、ACL 上でのグループの使用 を参照してください。
すべてのユーザーは正規 グループを作成することができます。正規グループの名前にはコロンで区切られた 2 つのフィールドがあり、その最初のフィールドはそのグループの所有権を示していなければなりません。結果が所有権を正確に指示しない場合には、保護サーバーはグループの名前の作成または変更を拒否します。
system:administrators グループのメンバーは、所有権を示す第 1 フィールドを持たない名前を持つ接頭部なし のグループを作成することができます。2 つのタイプのグループを効果的に使用することに関する提案については、グループの効果的な使用 を参照してください。
認証における相違 で説明したように、AFS 認証と UNIX 認証は分離されています。これは 2 つのファイル・システムが分離されているからです。この分離には、2 つの実用的な意味があります。
ユーザーが正常に認証されると、AFS 認証サービスはトークン をユーザーのキャッシュ・マネージャーに渡します。このトークンは、ユーザーが特定の AFS 識別に関連付けられているパスワードを正しく提示したことを証明するデータの小さなコレクションです。キャッシュ・マネージャーはサービス要求と共にトークンを、そのユーザーが本人であることを証明するものとして AFS サーバー・プロセスに提供します。 AFS サーバー・プロセスが識別を確立するために使用する相互認証の手続きについては、相互認証の詳細 を参照してください。
キャッシュ・マネージャーはトークンを、カーネル・メモリー内のユーザーの資格認定構造に保管します。あるユーザーの資格認定構造と別のユーザーの資格認定構造とを見分けるために、キャッシュ・マネージャーはユーザーの UNIX UID 、またはセル内で一意であることが保証された識別番号である プロセス認証グループ (PAG) のいずれかによって相互に識別します。詳しくは、PAG による AFS トークンの識別 を参照してください。
1 人のユーザーは、個別に識別された資格認定構造においてはセルごとに 1 つのトークンしか持つことができません。同じセルに 2 番目のトークンを得るには、ユーザーは別のマシンにログインするか、既存の資格認定構造以外の識別子を持つ資格認定構造を得なければなりません。pagsh コマンドを発行すれば、後者の方法が最も簡単に実現できます (PAG による AFS トークンの識別 を参照)。単一の資格認定構造では、ユーザーは多くのセルの各セルごとに 1 つのトークンを同時に持つことができます。これが暗に示すように、1 つのマシンまたは PAG の認証状態は、ほかのマシンまたは PAG の認証状態には関係なく、これは、ユーザーまたはシステム管理者にとっては非常に役に立ちます。
AFS 配布には、AFS でユーザーを認証して、ローカル・ファイル・システムを 1 ステップでログインさせることを、各システム・タイプのログイン・ユーティリティーで可能にするライブラリー・ファイルが組み込まれています。AFS の変更済みログイン・ユーティリティーをクライアント・マシンで構成しない場合は、そのマシン上のユーザーは、ログインした後に klog コマンドを発行して AFS で認証しなければなりません。
注: | AFS で変更されたライブラリーは、オペレーティング・システムのプロプラエタリー・ログイン・ユーティリティーで使用できるすべての機能を必ずしもサポートしていません。場合によっては、ユーティリティーがまったくサポートされていません。それぞれの AFS バージョンでサポートされているユーティリティーの詳細については、 AFS Release Notes を参照してください。 |
前述のように、キャッシュ・マネージャーは UNIX または PAG のいずれかによって資格認定構造を識別します。 PAG の使用は望ましいことです。それは、PAG は固有であることが許可されているからです。キャッシュ・マネージャーは、それぞれの使用とともに増分するカウンターを基に、 PAG を割り振ります。対照的に、マシン上の複数のユーザーは同じ UNIX UID を共用または想定します。それによって、潜在的なセキュリティー上の問題が発生します。以下に一般的なそのような状態を 2 つ示します。
さらに、UID を超える PAG の別の利点は、ユーザーが作成するプロセスがその PAG を継承し、その結果、トークンを共用することです。このようにして、2 人のユーザーは、認証済みのユーザーとして AFS にアクセスすることができるようになります。たとえば、多くの環境では、プリンターとほかのデーモンは、 AFS サーバー・プロセスが anonymous ユーザーとしてだけ認める識別 (ローカル・スーパーユーザー root など) の下で実行されます。PAG を使用しなければ、そのようなデーモンは、 system:anyuser グループが必要な ACL アクセス権をもたないファイルにアクセスすることができません。
ユーザーが PAG をもってしまうと、ユーザーが獲得するどんなトークンも、その PAG に関連付けられます。 PAG の有効期限は、関連付けられたトークンの有効期限が切れるか、または破棄されてから2 時間です。PAG の有効期限が切れる前にユーザーが klog コマンドを発行すれば、新規のトークンが既存の PAG に関連付けられます (この場合 PAG は 再生される と呼ばれます)。
AFS で変更されたログイン・ユーティリティーは、次のセクションで説明されているように、PAG を自動的に生成します。標準のログイン・ユーティリティーを使用する場合には、ユーザーは、pagsh コマンドを klog コマンドの前に発行するか、後者のコマンドの -setpag フラグを組み込まなければなりません。説明については、2 ステップ・ログインおよび認証の使用 を参照してください。
ユーザーはどちらかのコマンドを好きなときに使用して、新規の PAG を作成することもできます。これら 2 つのコマンドの違いは、klog コマンドは現行のコマンド・シェルとトークンに関連付けられている PAG を置き換えるという点です。 pagsh コマンドは、新規の PAG を作成する前に、新規のコマンド・シェルを初期化します。ユーザーがすでに PAG を持っている場合は、実行中のプロセスまたはジョブは、古い PAG に関連付けられているトークンを使用し続けます。これに対して、新規のジョブまたはプロセスは、新規の PAG と、それに関連付けられているトークンを使用します。新規のセルを (たとえば、<Ctrl-d> を押して) 終了すると、元の PAG とシェルに戻ります。デフォルトでは、 pagsh コマンドは Bourne シェルを初期化しますが、-c 引き数を組み込めば、その代わりに C シェル (多くのシステム・タイプでは /bin/csh プログラム) または Korn シェル ( /bin/ksh プログラム) を初期化することができます。
前述のとおり、AFS の変更済みログイン・ユーティリティーは、AFS トークンを取得すると同時に、ユーザーをローカル・ファイル・システムにログインさせます。この機能グループでは、ログイン・プロセスおよび認証プロセス、そのプロセスとローカル・パスワード・ファイルのパスワード・フィールドの値の相互作用について概要を説明します。
AFS の変更済みログイン・ユーティリティーは、以下と同様のステップの順序を実行します。オペレーティング・システムにより詳細が異なる場合があります。
AFS(R) version Login
説明したように、AFS の変更済みログイン・ユーティリティーを使用する場合は、ローカル・パスワード・ファイルのパスワード・フィールドは、システムにアクセスするための 1 次ゲートではなくなります。ユーザーが正しい AFS パスワードを提供している場合には、プログラムがローカル・パスワード・ファイルを調べることはありません。ただし、以下の方法で、ユーザーはまだパスワード・フィールドを使用して、アクセスを制御することができます。
プラグ可能認証モジュール (PAM) を使ってログインおよび AFS 認証を行うシステムでは、ローカル・パスワード・ファイルをまったく調べる必要がない場合もあります。その場合は、認証およびログインの試行を制御するためにパスワード・フィールドを使用することはありません。代わりに、PAM 構成ファイル (多くのシステム・タイプでは、/etc/pam.conf) 内の命令が同じ機能を果たします。 AFS の変更済みログイン・ユーティリティーのインストールに関する指示については、AFS インストールの手引き を参照してください。
AFS で変更されたログイン・ユーティリティーを使用しないセルでは、AFS 使用者の手引き で詳細に説明されているように、次のようにしてユーザーは別々のコマンドを発行して、ログインし、認証を受けなければなりません。
新規の AFS アカウントでの標準ファイルの作成 で説明したように、ユーザーの.login ファイル (または同等のファイル) で klog -setpag コマンドを呼び出せば、ユーザーはログイン後にコマンドを発行する必要がありません。しかしまだ、ユーザーはパスワードを 2 回入力しなければなりません。ログイン・ユーティリティーが表示するプロンプトで 1 回、klog コマンドのプロンプトで 1 回です。これによって、2 つのパスワードが異なることを暗黙指定しますが、同じ方が混乱は少なくなります。
AFS が変更したログイン・ユーティリティーを使用しないことのもう 1 つの結果は、 AFS サーバーが標準 login プログラムを anonymous ユーザーとして認識しないことです。login プログラムが AFS ファイル (ユーザーのホーム・ディレクトリーの .login ファイルなど) にアクセスする必要がある場合には、そのファイルを ACL に、system:anyuser グループに対する l (lookup) および r (read) のアクセス権を許可する項目が含まれていなければなりません。
AFS が変更したログイン・ユーティリティーを使用しない場合は、実際の (スクランブルされた) パスワードが、それぞれのユーザーのローカル・パスワード・ファイルに示されていなければなりません。/bin/passwd ファイルを使用して、これらのパスワードを挿入または変更します。ローカル・パスワード・ファイルのパスワードが AFS パスワードと一致している方が簡単ですが、その必要はありません。
ログインしてしまうと、ユーザーは klog コマンドを使っていつでもトークンを入手することができます。有効なトークンがすでにある場合には、新規のトークンがそれを上書きします。PAG がすでに存在する場合には、新規トークンはその PAG に関連付けられます。
デフォルトでは、klog コマンドは、現在ローカルのファイル・システムにログインしている識別を使用して、発行者を認証します。異なる識別として認証するには、-principal 引き数を使用します。外部セルのトークンを獲得するには、-cell 引き数を使用します (この引き数は -principal 引き数と組み合わせることができます)。 AFS 使用者の手引き および AFS Administration Reference の klog コマンドの項目を参照してください。
すべてのトークンあるいは特定のセルのトークンのいずれかを破棄するには、unlog コマンドを発行します。このコマンドは、現行のコマンド・シェルに関連付けられているトークンにのみ影響します。AFS 使用者の手引き および AFS Administration Reference の unlog コマンドの項目を参照してください。
現行のコマンド・シェルに関連付けられているトークンを表示するには、tokens コマンドを発行します。以下の例は、さまざまな状態での出力を示しています。
発行者がどのセルでも認証されない場合は、以下が出力されます。
% tokens Tokens held by the Cache Manager: --End of list--
以下に示すのは、ABC Corporation セルの AFS UID 1000 のユーザーの出力です。
% tokens Tokens held by the Cache Manager: User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00] --End of list--
以下に示すのは、ABC Corporation セル、State University セルおよび DEF Company セルで認証されるユーザーの出力です。ユーザーは、3 つのセルで別々の AFS UID をもっています。最後のセルのトークンは有効期限が切れています。
% tokens Tokens held by the Cache Manager: User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00] User's (AFS ID 4286) tokens for afs@stateu.edu [Expires Jun 3 1:34] User's (AFS ID 22) tokens for afs@def.com [>>Expired<<] --End of list--
tokens コマンドの Kerberos バージョン (tokens.krb コマンド) は、以下の例のように、チケットの所有者、チケット付与サービス、および有効期限日付をはじめとする、チケットを付与するチケットに関する情報を報告します。 ケルベロス認証のサポート も参照してください。
% tokens.krb Tokens held by the Cache Manager: User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00] User smith's tokens for krbtgt.ABC.COM@abc.com [Expires Jun 2 10:00] --End of list--
ユーザー・トークンの最大存続時間は、次の 3 つの認証データベースの項目に記録されている チケットの存続時間 の最小値です。 kas examine コマンドは、存続時間を Max ticket lifetime として報告します。自分の認証データベース項目に ADMIN フラグを持つ管理者は、kas setfields コマンドに -lifetime 引き数を使用して、項目のチケット存続時間を設定することができます。
注: | AFS が変更したログイン・ユーティリティーは、常に、前述の 3 つの値から計算した存続時間をトークンに与えます。klog コマンドを発行しているときには、ユーザーは、-lifetime 引き数を使用して、デフォルトより短い存続時間を要求することができます。詳しくは、AFS 使用者の手引き および AFS Administration Reference の klog 解説ページを参照してください。 |
正規の AFS ユーザーは、自分のパスワードを、kpasswd または kas setpassword コマンドを使用して変更することができます。これらのコマンドは、現行のパスワードを要求するプロンプトを出し、次にタイプミスを除外するために、新規のパスワードを 2 回要求します。
自分の認証データベース項目に ADMIN フラグを持つ管理者は、 kpasswd コマンド (現行のパスワードが何であるかを要求します) または kas setpassword コマンドのいずれかを使用して、任意のユーザーのパスワードを変更することができます。
セルが AFS で変更されたログイン・ユーティリティーを使用しない場合は、オペレーティング・システムのパスワード変更コマンドを使用して、忘れずにローカルのパスワードを変更してください。パスワードの変更に関する詳細については、AFS パスワードの変更 を参照してください。
ユーザーのパスワードおよび認証試行に対して制限を課すことにより、セルをより安全なものにすることができます。アカウントの作成時に制限を課すには、A 命令によるアカウント・セキュリティーの強化 で説明されているように、uss テンプレート・ファイルの A 指示を使用します。既存のアカウントに値を設定したり値を変更するには、パスワードおよび認証セキュリティーの改善 で説明されている kas setfields コマンドを使用します。
デフォルトでは、AFS のパスワードには有効期限がありません。パスワードの存続時間を制限すると、ハッカーがパスワード試行に使える時間が短くなるので、セキュリティーを向上させるのに役に立ちます。存続時間は、パスワードが最後に変更されてから 1 から 254 日の範囲で選択できます。存続時間は、新規のパスワードが設定されたときに自動的に各パスワードに適用されます。ユーザーがパスワードを変更する場合、管理者は、新規のパスワードがすでに使用された 20 のパスワードのどれにも似ていないものにすることを要求できます。
悪意を持ったユーザーが、認証ユーザーのパスワードを推測して AFS セルにアクセスする可能性があります。このタイプの攻撃から保護するために、ユーザーが連続して正しいパスワードの提示に失敗することのできる回数を制限することができます。この制限を越えると、認証サービスは指定された時間 (ロックアウト・タイム) の間、それ以上の認証試行を拒否します。ロックアウト時間が満了する前に認証の試行を再度可能にするには、管理者は kas unlock コマンドを発行しなければなりません。
ユーザーの認証アカウントの設定値の他に、新規のユーザー・パスワードの品質を自動的に検査することにより、セキュリティーを向上することができます。 kpasswd および kas setpassword コマンドは、提示されたパスワードをプログラムまたは kpwvalid というスクリプト (存在する場合) に渡します。 kpwvalid は品質検査を行い、パスワードが受け入れ可能であるかどうかを示すコードを戻します。管理者は自分独自のプログラムを作成するか、あるいは AFS 配布に組み込まれているサンプル・プログラムを変更することができます。 AFS Administration Reference にある kpwvalid の解説ページを参照してください。
パスワード品質を向上できる品質検査にはいくつかのタイプがあります。
サイトが AFS 認証サーバーではなく標準 Kerberos 認証を使用している場合は、 Kerberos 認証をサポートする klog、pagsh、および tokens コマンドの変更済みバージョンを使用しなければなりません。これらのコマンドの変更済みバージョン用のバイナリーの名前は、 .krb 拡張子を追加した標準バイナリーと同じです。
セル内では Kerberos バージョンまたは標準コマンドを使用してください。その場合、この 2 つのバージョンを混合して使用しないでください。AFS プロダクト・サポートは、これらの 4 つのコマンドのケルベロス・バージョンのインストールに関する説明を提供することができます。これらのコマンドの 2 つのバージョン間にある相違については、 AFS Administration Reference を参照してください。
AFS はいくつかの機能を組み込んで、認証されたユーザーだけがデータにアクセスすることができるようにすることを保証します。この機能グループでは、それらの機能の中で最も重要な機能について要約し、ユーザーのセルのセキュリティーを改善するメソッドを提案します。
ディレクトリーの ACL
AFS のファイルは、その親ディレクトリーに関連したアクセス制御リスト (ACL) で保護されます。ACL は、何らかの方法で、そのディレクトリーのデータにアクセスできるユーザーまたはグループを定義します。アクセス制御リスト (ACL) の管理を参照してください。
クライアントとサーバー間の相互認証
AFS クライアントとサーバー・プロセスが通信するときには、相互認証中に、お互いの識別を証明し合う必要があります。相互認証には、有効な通話者だけが復号して、応答することができる暗号化された情報の交換を含みます。相互認証プロセスの詳細については、 相互認証の詳細を参照してください。
AFS サーバー・プロセスは、サーバー・プロセス間およびユーザーを示すプロセス間の両方を相互に認証します。相互認証の完了後は、サーバーとクライアントの間には、接続の有効期限が切れるか、通話者の一方が接続をクローズするまで、もう一度認証する必要なく繰り返し通信することができる、認証済みの接続が確立されています。認証済みの接続の存続時間は異なります。
トークン
AFS ファイルにアクセスするには、ユーザーは正しい AFS パスワードを提供して、AFS 認証サービスに自分の識別を証明しなければなりません。パスワードが正しければ、認証サーバーは、認証された状態の証拠として、ユーザーにトークン を送ります。AFS でのログインと認証を参照してください。
サーバーは、有効なトークンを持っていないユーザーとプロセスに、識別として anonymous を割り当てます。 anonymous 識別には、ACL の system:anyuser グループに許可されたアクセス権だけが与えられます。
許可検査
相互認証では、相互に通信している 2 人の通話者が、実際に、承認を求める当人であることを確認します。AFS サーバー・プロセスは、識別を検証されたクライアントが、多くの機能を要求することも許可されているかどうかも検査します。異なる要求には、異なった種類の特権が必要です。3 つのタイプの特権 を参照してください。
AFS サーバー・プロセスは、クライアントに情報を返送する前に、特に注意が必要な情報を暗号化します。たとえ、許可されない通話者が認証済みの接続で盗聴することができても、適切な鍵がなければ暗号化されたデータを解読することはできません。
以下の AFS コマンドにはサーバーの暗号化鍵とパスワードが関係するので、これらのコマンドはデータを暗号化します。
さらに、更新サーバーの米国版は、配布時に、注意が必要な情報 (KeyFile のコンテンツなど) を暗号化します。bos 組の残りのコマンドと、fs、pts および vos 組のコマンドは、データの転送前に、そのデータを暗号化しません。
AFS は、個別の特権を持つ理由 で説明されている理由から、以下に示した 3 つの異なるタイプの特権を使用します。
AFS は、認証と許可検査を区別します。認証 とは、識別を証明するプロセスを指します。 認証検査 は、認証された識別が特定のアクションの実行を許可されているかどうかを検証するプロセスを指します。
AFS は接続のレベルで認証をインプリメントします。2 人の対話者は、新規接続を確立するたびに、相互に認証します。一般的に、AFS コマンドの発行のたびに、 AFS サーバー・プロセスとクライアントの間に新規の接続を確立します。
AFS は、サーバー・マシンのレベルで許可検査をインプリメントします。認証検査がサーバー・マシン上で使用可能になっていれば、そのマシン上で実行されているサーバー・プロセスはすべて許可されたユーザーのみにサービスを提供します。認証検査がサーバー・マシン上で使用不可になっていれば、サーバー・プロセスはすべてどのユーザーに対しても任意のアクションを実行します。認証検査を使用不可にすると、明らかにセキュリティーが重大な危険にさらされます。詳細については、認証と許可の要件の管理 を参照してください。
ユーザー・アカウント、サーバー・マシン、およびシステム管理者のアカウントを指示された方法で構成することによって、セル内でのセキュリティーのレベルを向上させることができます。
ユーザー・アカウント
サーバー・マシン
システム管理者
任意のファイル・システムのように、セキュリティーは AFS の基本用務です。ファイル共用を容易にするファイル・システムは、ファイル共用を強制した場合は有用ではありません。そのため AFS には、許可されないユーザーがデータにアクセスできないようにするいくつかの機能を組み込まれています。ネットワーク化された環境のセキュリティーは、困難です。それは、ほとんどすべての手順で、だれでもつなぐことができるワイヤーを介して、情報を伝送する必要があるからです。また、ネットワーク上の多くのマシンは十分に強力で、悪意を持ったユーザーがトランザクションをモニターしたり、転送を代行受信することすら可能です。さらに、関係者の 1人の識別を模造することもできます。
盗聴および情報の窃取あるいはなりすましに対する最も効果的な予防措置は、サーバーとクライアントが、もう一方の対話者が本物であると主張している識別を十分に証明してから受け入れることです。言い換えれば、ネットワークの性質上、ネットワーク上のすべての対話者は、トランザクション内の他の対話者は、証明されるまで本物ではないと想定することを強制されます。 相互認証 は、対話者がそれぞれ自分が本物であることを証明するための手段です。
模造を防ぐために必要な基準は、非常に精巧でなければならないため、相互認証手順のインプリメンテーションは複雑です。ただし、基本概念は単純です。対話者は、共用シークレット に関する知識を明示して自分たちの識別を証明します。共用シークレットは、相互に認証している対話者しか知らない情報の一部です (対話者は、信頼される第三者または何らかのほかのソースの最初の場所でその情報を確認する場合があります)。トランザクションの発信元の対話者は共用シークレットを提供し、相手の対話者がそのシークレットを知っていることを示すまで、その対話者が有効な対話者であるとして受け入れることを拒否します。
AFS トランザクションにおける共用シークレットの最も一般的な形式は、 暗号化鍵 であり、簡単に鍵 とも呼びます。 2 人の対話者は、自分たちの共用鍵を使用して、送信する情報のパケットを暗号化し、受信したパケットの暗号を復号します。鍵を使用する暗号化は実際には 2 つの関連する目的にかなうものです。第一に、鍵を使った暗号化は、その鍵を知らないだれかが盗聴するのを防ぎ、ネットワークを上のメッセージを保護します。第二に、メッセージを正常に暗号化し復号できるということは、対話者がその鍵を使用していることを示しています (その鍵が共用シークレットなのです)。対話者が異なる鍵を使用している場合は、暗号化解除の後でもメッセージはスクランブルされて判読できない状態のままです。
以下のセクションでは、AFS の相互参照の手続きについてさらに詳しく説明します。相互認証プロセスに関心がない場合は、この機能グループを自由にスキップしてかまいません。
簡単な相互認証には、1 つだけの暗号化鍵と 2 人の対話者、一般的にはクライアントとサーバーが含まれます。クライアントは、2 人の対話者しか知らない鍵を使って暗号化した申し込み メッセージ送信して、サーバーと交信します。サーバーは、同じシークレットを共用していれば、クライアントの鍵と同じ自分の鍵を使用して、そのメッセージを復号します。サーバーはその申し込みに応答し、自分の鍵を使用してその応答を暗号化します。クライアントは自分の鍵を使用してサーバーの応答を復号します。その鍵が正しければ、クライアントは、そのサーバーが本物であると確信することができます。申し込みを復号し、それに正しく答えることができるのは、クライアントと同じ鍵を知っている人だけです。サーバー側では、そのクライアントは本物であると結論を下します。それは、サーバーがその申し込みのメッセージを復号したときに、そのメッセージが意味をなしたからです。
AFS は簡単な相互認証を使用して、ログイン手続きの最初の部分でユーザーを検証します。このような場合には、鍵はユーザーのパスワードを基にしています。
複雑な相互認証には、3 つの暗号化鍵と 3 人の対話者が含まれます。すべてのセキュア AFS トランザクション (ログイン・プロセスの最初の部分を除く) では、複雑な相互認証を使用します。
クライアントがサーバーと通信することを希望するときには、まず、チケット授与者 と呼ばれる三人目の通話者と交信します。チケット授与者とクライアントは、簡単な手順を使用して相互に認証します。相互認証が終了すると、チケット授与者は、クライアントの識別を事前に検証した証明として、クライアントに サーバー・チケット (または単に チケット) を与えます。チケット付与者は、3 つの鍵のうち、サーバー暗号化鍵 と呼ばれる最初の鍵を使って、そのチケットを暗号化します。それは、チケット授与者と、クライアントが交信したいサーバーしかその鍵を知らないからです。クライアントはこの鍵を知りません。
チケット付与者は、情報の他の一部を、そのチケットと一緒に送信します。その情報を使用してクライアントは、チケットそれ自体を復号することができないにもかかわらず、チケットを実際に使用することができます。このチケットだけでなく、項目もトークン を構成します。
チケット授与者は、複雑な相互認証に含まれる 3 番目の鍵ですべてのトークンを封印します。この鍵については、チケット授与者とクライアントしか知りません。この 3 番目の鍵は、クライアントが表す人間のユーザーのパスワードから派生される場合があります。
クライアントが有効なチケットを入手したので、サーバーと更新する準備ができました。クライアントはサーバーに 2 つのものを送信します。
この時点では、チケット授与者がセッション鍵を作成したばかりであるため、サーバーはその鍵については知りません。ただし、チケット授与者は、チケット内にセッション鍵のコピーを書き込みました。サーバーは、サーバー暗号化鍵を使用してチケットを復号し、セッション鍵を知ります。次に、サーバーはセッション鍵を使用して、クライアントの要求メッセージを復号します。応答を生成し、それをクライアントに送信します。サーバーはその応答をセッション鍵で暗号化し、ネットワークを渡るメッセージを保護します。
このステップは、クライアントとサーバー間の相互認証の核心です。それは、このステップによって、両方の通話者が同じシークレットを知っていることを証明するからです。
(たとえ、チケット授与者とサーバーの関連が、チケット・ベースの相互認証の中心であっても、これらの間には直接の通信が内ことに注意してください。チケット授与者とサーバーは、自分たちの共用シークレットで封印したチケットをクライアントが所有することを介して、間接的に対話するだけです。)
AFS は、管理者が AFS データをバックアップするのに役に立つ、バックアップ・ボリュームと AFS バックアップ・システムという 2 つの関連機能を提供します。
最初の機能はバックアップ・ボリュームです。これは、管理者が読み取り / 書き込みボリュームを複製することによって作成します。バックアップ・ボリュームは読み取り専用であるため、複製の作成時の読み取り / 書き込みボリュームの状態を保持します。
バックアップ・ボリュームをファイル・システムに取り付け、そのコンテンツをユーザーが使用できるようにすれば、バックアップ・ボリュームによって、管理がしやすくなります。たとえば、各ユーザー・ボリュームのバックアップ・バージョンをユーザーのホーム・ディレクトリーのサブディレクトリーとして取り付けることが意味のあることである場合がよくあります。このマウント・ポイントの通例の名前は、OldFiles です。一日に一度はバックアップ・ボリュームの新規バージョンを作成し (すなわち、読み取り / 書き込みを再複製し)、前回のバックアップ以降に加えられた変更をすべて取り込みます。ユーザーが誤ってデータを削除または変更した場合でも、ユーザーは、管理者にそのデータの復元を依頼しなくても、自分でバックアップ・ボリュームからそのデータを復元することができます。
AFS 使用者の手引き ではバックアップ・ボリュームについては何も説明していません。そのため、管理者がバックアップ・ボリュームを使用しないと決めてしまえば、通常のユーザーはバックアップ・ボリュームのことは何も知りません。これは、管理者がユーザー・ボリュームのバックアップ・バージョンを作成する場合には、バックアップの作業方法およびそれの取り付け場所をユーザーに知らさなければなりません。
ユーザーは、バックアップ・ボリューム内のデータによってボリュームの割り当て量が減ると考えることがよくあり、OldFiles マウント・ポイントを除去することを望むユーザーさえ存在します。しかしそのようなことはありません。それは、バックアップ・ボリュームは 別のボリュームだからです。バックアップ・ボリュームがユーザーのボリュームで使用する唯一のスペースの量は、マウント・ポイントに必要な量です。その量は、標準ディレクトリー要素に必要な量と同じくらいです。
バックアップ・ボリュームについては、バックアップ・ボリュームの作成 で詳しく説明しています。
バックアップ・ボリュームによって復元要求が削減されますが、バックアップ・ボリュームはディスク上に常駐するため、ハードウェアの故障のために、データが失われるのを防ぎません。任意のファイル・システムのように、 AFS はこの種のデータの損失に対しては無防備です。
データを永久に失うことからユーザーのセルのユーザーを保護するには、ユーザーのファイル・システムを定期的にかつ頻繁に、磁気テープにバックアップすることを強くお勧めします。 AFS バックアップ・システムは、管理とバックアップのパフォーマンス容易にするために使用できます。 AFS バックアップ・システムに関する詳細については、 AFS バックアップ・システムの構成 および AFS データのバックアップと復元 を参照してください。
AFS 配布には、リモート・サービスを提供するいくつかの標準 UNIX コマンド、デーモン、およびプログラムの変更済みバージョンが組み込まれています。
これらの変更によって、コマンドが AFS 認証情報 (トークン) を処理できるようになります。これによって、発行者は、認証された AFS ユーザーとしてリモート・マシン上で認識されます。
ユーザーのファイル・ツリーにあるこれらのプログラムの標準バージョンを、 AFS を変更したバージョンと置き換えることは、任意選択です。AFS の透過的なアクセスによって、一部のプログラム、特に、ftpd や rcp プログラムのような、マシンからマシンへのファイル転送に関係するプログラムの必要性が少なくなります。
これらのコマンドの AFS バージョンを使用することを決めたら、このコマンドには互に依存する物があることに注意してください。たとえば、 AFS 認証情報の受け渡しが rcp コマンドで正常に動作するのは、 rcp コマンドおよび inetd コマンドの両方とも AFS バージョンを使用している場合だけです。
変更済みのリモート・コマンドのインストール場所は、標準では /usr/afsws/bin および /usr/afsws/etc ディレクトリーです。コマンドの機能の詳細については、AFS Administration Reference の各コマンドの解説ページを参照してください。
NFS クライアント・マシンのユーザーは、NFS/AFS 変換プログラム を実行している AFS クライアント・マシンの /afs ディレクトリーを取り付けることによって、AFS ファイル・スペースにアクセスすることができます。これは、AFS を使用できないクライアント・マシンを使用して AFS にアクセスしたい NFS をすでに実行しているセルでは、特に有利になります。付録 A, NFS/AFS 変換プログラムの管理を参照してください。