# 管理の手引き

# セルの構成と管理における発行

この章では、セルを構成する際および管理する際の注意事項の多くについて説明し、詳細な関連情報が記載されている本書内の場所を示します。この章は、ユーザーがすでに AFS 管理の概要 の資料に精通していることを想定しています。

セルの最初のファイル・サーバー・マシンをインストールするか、あるいは、ほかの管理用タスクのどれかを実行する前にこの章を読むことが最適です。

## AFS と UNIX の間の相違: 要約

AFS の振る舞いは、ほとんどの点で、標準 UNIX ファイル・システムと類似していますし、AFS により セル内およびセル間のファイルの共用も容易になります。このセクションでは、AFS ファイル・システムと UNIX ファイル・システムの相違点について、適宜詳細な参照情報を示しながら説明します。

### ファイル保護とディレクトリー保護の相違

AFS は、標準 UNIX ファイル保護メカニズムを 2 通りの方法で強化しています。まず、AFS はアクセス制御リスト (ACL) を各ディレクトリーに関連付けます。そして、ユーザーが多数のユーザー独自のグループ (ACL 上に配置できます) を定義することを可能にします。

AFS は、排他的にモード・ビットに依存するのではなく、 ACL を使用してファイルとディレクトリーを保護します。これには多くの言外の意味があり、それについては、指示された機能グループで詳細に説明します。

- AFS の ACL は 7 つのアクセス権を使用します (UNIX では 3 つのモード・ビットを使用)。AFS ACL アクセス権を参照してください。
- ディレクトリーの場合は、AFS は UNIX のモード・ビットを無視します。ファイルの場合は、AFS はモード・ビットの最初のセット (所有者ビット) のみを使用します。このモード・ビットの意図するところと、ディレクトリーの ACL のアクセス権とは相互作用します。AFS が UNIX モード・ビットを解釈する方法 を参照してください。
- ディレクトリーの ACL は、ディレクトリーにあるすべてのファイルを同じ方法で保護する。より制限された AFS アクセス権のセットを一定のファイルに適用するには、異なる ACL をもつディレクトリーにそのセットを配置します。
- ファイルを異なるディレクトリーに移動すると、そのファイルの保護が変更されます。UFS と AFS のデータ保護の違い を参照してください。
- ACL には、アクセス権の異なる組み合わせを異なるユーザーまたはグループに許可する約 20 の項目を組み込むことができます。これに対し、UNIX ではモード・ビットの 3 つのセットで表される 3 つのエンティティーだけです。UFS と AFS のデータ保護の違い を参照してください。
- AFS ファイルは、w (書き込み) モード・ビットを設定するだけで、UNIX のファイル・システムの場合と同様、書き込み専用として指定することができます。 AFS はディレクトリーのモード・ビットを無視するので、AFS ディレクトリーを書き込み専用と指定することはできません。AFS が UNIX モード・ビットを解釈する方法 を参照してください。

AFS を使用すると、ユーザーは他のユーザーからなるグループを定義することができます。このように定義されたグループを ACL に配置すると、同じアクセス権を正確に指定された多くのユーザーに同時に広まります。この方が、個人を ACL に直接配置するより、はるかに便利です。保護データベースの管理 を参照してください。

システムが定義するグループ、system:anyuser と system:authuser もあります。このようなグループが ACL にあることで、幅広いユーザーに同時にアクセスできるようになります。システム・グループ および ACL 上でのグループの使用 を参照してください。

### 認証における相違

AFS ファイル・スペースが各マシンのローカル・ファイル・システムと別個であるのと同様に、 AFS 認証はローカル・ログインとは分離されています。これには実用上 2 つの言外の意味があり、それについては AFS の変更済みログイン・ユーティリティーを使用する場合 で説明しています。

- AFS ファイルにアクセスするには、ユーザーはローカル・マシンの UNIX ファイル・システムにログインし、かつ AFS 認証サービスで認証を受けなければなりません。 (ローカルの UNIX ファイル・システムにログインする必要があるのは、AFS ファイル・スペースには、ローカル・マシンのカーネルに常駐するキャッシュ・マネージャーを介してアクセスするからです。)

  AFS は、1 つのパスワードに基づき、 1 つのステップでローカル・ログインと AFS 認証の両方を完了する変更済みのログイン・ユーティリティーを提供します。 AFS の変更済みログイン・ユーティリティーを使用しないことを選択すると、ユーザーは、AFS 使用者の手引き で説明するように、別個のステップでログインと認証を実行しなければなりません。

- パスワードは 2 つの異なる場所に保管されます。それらの場所とは、AFS の認証データベースと、各マシンの UNIX ファイル・システム用ローカル・パスワード・ファイル (/etc/passwd または同等のファイル) です。 2 つの場所にあるユーザーのパスワードは、そう望むのであれば別のものにすることができます。ただし、それによって生じる振る舞いは、セルが AFS によって変更されたログイン・ユーティリティーを使用しているかどうか、およびその使用方法によって異なります。

### 標準 UNIX コマンドの意味の相違

このセクションでは、AFS が一部の UNIX コマンドの機能をどのように変更しているのかについて要約します。

chmod コマンド
  system:administrators グループのメンバーだけが、このコマンドを使用して、AFS ファイルの setuid、setgid、あるいは sticky モード・ビットをオンにすることができます。詳細については、クライアントが Setuid プログラムを実行できるかどうかを決定する を参照してください。

chown コマンド
  system:administrators グループのメンバーだけがこのコマンドを AFS ファイルに対して発行することができます。

chgrp コマンド
  system:administrators のメンバーだけが、 AFS ファイルとディレクトリーに対してこのコマンドを発行することができます。

ftpd デーモン
  このデーモンの AFS によって変更されたバージョンは、ローカルの AFS 認証サービスで、ftp コマンドのリモート発行者を認証しようとします。AFS 環境における UNIX リモート・サービスの使用 を参照してください。

groups コマンド
  ユーザーの AFS トークンがプロセス認証グループ (PAG) に関連する場合には、このコマンドの出力には 2 つの大きな数字が組み込まれることがあります。 PAG について確認するには、 PAG による AFS トークンの識別 を参照してください。

inetd デーモン
  このデーモンの AFS によって変更されたバージョンは、ローカルの AFS 認証サービスを使って、AFS によって変更された rcp および rsh コマンドの発行者を認証します。AFS 環境における UNIX リモート・サービスの使用 を参照してください。

ログイン・ユーティリティー
  AFS によって変更されたログイン・ユーティリティーは、発行者をローカルのファイル・システムにログインさせると共に、そのユーザーを AFS 認証サービスで認証します。AFS の変更済みログイン・ユーティリティーを使用する場合 を参照してください。

ln コマンド
  このコマンドは、異なる AFS ディレクトリーにあるファイル間にハード・リンクを作成できません。 ハード・リンクの作成 を参照してください。

rcp コマンド
  AFS の変更済みバージョンのこのコマンドを使用すると、発行者は、認証された AFS ユーザーとして、リモート・マシン上のファイルにアクセスすることができます。AFS 環境における UNIX リモート・サービスの使用 を参照してください。

rlogind デーモン
  このデーモンの AFS によって変更されたバージョンは、ローカルの AFS 認証サービスを使って、rlogin コマンドのリモート発行者を認証します。AFS 環境における UNIX リモート・サービスの使用 を参照してください。

  一部のシステム・タイプ用の AFS 配布には、変更済みの rlogind プログラムが含まれていないかもしれません。AFS Release Notes を参照してください。

remsh コマンドまたは rsh コマンド
  AFS の変更済みバージョンのこのコマンドを使用すると、発行者は、認証された AFS ユーザーとして、リモート・マシン上でコマンドを実行することができます。AFS 環境における UNIX リモート・サービスの使用 を参照してください。

### AFS バージョンの fsck コマンド

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 コマンドで) ことができます。ただし、番号記号 (#) またはパーセント記号 (%) のいずれかで始まる名前を持つファイルへのシンボリック記号は作成しないでください。キャッシュ・マネージャーはそのようなリンクを、それぞれ標準ボリュームまたは読み取り / 書き込みボリュームに対するマウント・ポイントと解釈します。

### AFS がインプリメントするクローズ時の保管

アプリケーションがファイルに対して UNIX の close システム呼び出しを発行すると、キャッシュ・マネージャーは、そのファイルの最重要コピーを保守しているファイル・サーバーにデータを同期書き込みします。キャッシュ・マネージャーは、ファイル・サーバーがそのデータの受け入れを許可してはじめて制御をアプリケーションに戻します。 fsync システム呼び出しの場合は、ファイル・サーバー・マシン上の不揮発性記憶域にデータを書き込んだことをファイル・サーバーが示してはじめてアプリケーションに制御が戻ります。

アプリケーションが UNIX の write システム呼び出しを発行すると、キャッシュ・マネージャーは変更をローカルの AFS クライアント・システムにだけ書き込みます。ローカル・マシンがクラッシュしたり、アプリケーションが close システム呼び出しを発行せずに終了した場合、ファイル・システムが保守しているファイルの最重要コピーに変更が記録されない可能性があります。キャッシュ・マネージャーはこのタイプの変更済みデータを、close または fsync システム呼び出しを受け取らずにキャッシュからファイル・サーバーに書き込むことがあります。たとえば、新規データをキャッシュに入れるために、キャッシュ・チャンクを解放する必要がある場合などです。ただし、一般には、いつキャッシュ・マネージャーが変更済みデータをこのようにしてファイル・サーバーに転送するかを予測することはできません。

これが言外に意味していることは、アプリケーションのSave オプションが close または fsync ではなく、write システム呼び出しを発行した場合、変更が必ずしもファイル・サーバー・マシンに永続的に保管されるとは限らないということです。ほとんどのアプリケーション・プログラムは、ファイル処理を終了する場合およびプログラムを終了する場合だけでなく、保管操作の場合も close システム呼び出しを発行します。

### Setuid プログラム

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 のセル名には、以下のようないくつかの制約があります。

- 64 文字まで含めることができますが、短い名前の方が適しています。それは、セル名はマシン名およびファイル名の一部であることが多いからです。セル名が長くても、ファイル・ツリーの第 2 レベルに完全なセル名へのシンボリック・リンクを作成すれば、パス名の長さを短くすることができます。 2 番目の (セル名) レベル を参照してください。
- 異なるタイプのオペレーティング・システムに AFS セル名が適していることを保証するために、セル名には小文字、数字、下線、ダッシュ、およびピリオドしか含めることができません。コマンド・シェルのメタ文字は含めないでください。
- 任意の数のフィールドを組み込むことができます。これらのフィールドは、規則通りに、ピリオドで区切ります (下記の例を参照)。
- 名前は、機関のタイプを示すサフィックスか、その機関が置かれている国を示すサフィックスで終わらなければなりません。標準的なサフィックスは、以下のとおりです。

  .com
    会社とほかの商業の組織用。例: ABC Corporation セル用の abc.com

  .edu
    大学などの教育機関用。例: State University セル用の stateu.edu

  .gov
    米国の政府機関用。

  .mil
    米国の軍事施設。

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 を使用して、セル内でのファイル共用を容易にするけれども、そのセルのユーザーが外部のセルにアクセスできるようにすることに、関心がないものがあります。
- ユーザーのファイル・ツリーを表示することは、そのファイル・ツリーを無防備にすることではありません。ローカル・ユーザーのアクセスを制御するのと同じ保護メカニズムを使用して、外部のユーザーがユーザーのセルにアクセスする方法を制御します。ユーザーのセルへの外部ユーザーのアクセスに対する許可と禁止 を参照してください。
- 参加の 2 つの局面は、独立しています。セルのユーザーが外部のセルのファイル・ツリーを見ることを許可することなく、セルは、そのファイル・ツリーを表示することができます。あるいは、セルのユーザーが、自身を公示することなく、ほかのファイル・ツリーを見ることができるようにします。
- ユーザーは、自分のデータベース・サーバー・マシンを公示することなく、自分のセルを表示することができます。ユーザーのセルをほかのユーザーが見ることができるようにする を参照してください。
- ユーザーは、クライアントごとのマシンをベースにして、外部のセルへのアクセスを制御します。すなわち、管理しているセル内のあるクライアント・マシンから外部セルへのアクセスは可能にし、別のクライアント・マシンからのアクセスは不可にすることができます。ユーザーのセルでほかのセルを見ることができるようにする を参照してください。

### グローバル・ネーム・スペースの外観

AFS グローバル・ネーム・スペースは、その中に加わるすべての AFS セルと同じように見えます。それは、これらのすべてのセルは、パス名を組み立てる際の規則のスモール・セットに従うことに同意するからです。

最初の規則は、すべての AFS パス名を文字列 /afs で開始して、パス名が AFS グローバル・ネーム・スペースに属することを示す、というものです。

2 番目の規則は、セル名を AFS パス名の 2 番目の要素とする、というものです。すなわち、セル名はファイルが常駐する場所 (つまり、ファイル・サーバー・マシンがファイルを収容するセル) を示します。前述したように、パス名にセル名があると、グローバル・ネーム・スペースが可能になります。それは、AFS ファイル・スペースの下位レベルにある同じディレクトリー名をセルが使用しても、すべての AFS パス名は固有であることが保証されるからです。

パス名の 3 番目以下のレベルで表示される内容は、セルがそのファイル・スペースの配置を選択した方法によって異なります。3 番目のレベルには、示唆された基本ディレクトリーがいくつかあります。 3 番目のレベル を参照してください。

### ユーザーのセルをほかのユーザーが見ることができるようにする

管理者は、セル名とデータベース・サーバー・マシンを公示することにより、セルを他のセルから見えるようにすることができます。ローカル・セルのクライアント・マシンと全く同じように、外部セルにあるマシン上のキャッシュ・マネージャーは、その情報を使用して、ボリュームおよびファイルの場所情報が必要になると、公示されたセルのボリューム・ロケーション (VL) サーバーにアクセスします。同様に、外部セルで実行しているクライアント側の認証プログラムはその情報を使用して、公示されたセルの認証サービスに接続します。

この情報を使用可能にすることができる場所は、2 つあります。

- AFS プロダクト・サポート・グループによって保守されるグローバルな CellServDB ファイル内。このファイルは、この情報をほかのセルが使用できるようにすることに同意した、あらゆるセルの名前とデータベース・サーバー・マシンのリストを作成します。

  セルのリストをこのファイルで追加または変更するには、サイトの正式なサポート担当に、 AFS プロダクト・サポートに電話または書面で連絡するように依頼してください。このファイルには頻繁に変更が行われるため、 AFS プロダクト・サポートでは変更を毎回アナウンスすることはしていません。このファイルに変更が行われていないか定期的に確認することをお勧めします。

- セルのファイル・スペースの /afs/cellname/service/etc ディレクトリーにある、 CellServDB.local というファイル。セルのデータベース・サーバー・マシンのみをリストします。

セルのデータベース・サーバー・マシンの識別を変更した場合は、必ずこれらのファイルを更新してください。また、(/usr/afs/etc ディレクトリー内の) すべてのサーバー・マシンと (/usr/vice/etc ディレクトリー内の) すべてのクライアント・マシン上の CellServDB ファイルのコピーを更新してください。手順については、サーバー CellServDB ファイルの保守 および データベース・サーバー・マシンの情報を保持する を参照してください。

データベース・サーバー・マシンを公示すると、公示したセルを再度不可視にすることは難しくなる可能性があります。CellServDB.local ファイルを自分で削除し、グローバル CellServDB ファイルから項目を削除するように、 AFS プロダクト・サポートに要請することができます。しかし、ほかのセルのローカルの CellServDB ファイルに、すでにその項目がある可能性があります。それらの項目を無効にするには、データベース・サーバー・マシンの名前または IP アドレスを変更しなければなりません。

ただし、セルは、表示できないようにしなくてもアクセス不能にすることができます。セルを外部のユーザーに対して完全にアクセス不能にするには、ファイル・スペースの上位 3 つのレベルで、すべての ACL から system:anyuser グループを除去します。 ユーザーのセルへの外部ユーザーのアクセスに対する許可と禁止 を参照してください。

### ユーザーのセルでほかのセルを見ることができるようにする

外部セルのファイル・スペースをユーザーのセル内のクライアント・マシンで見ることができるようにするには、次の 3 つのステップを実行します。

1. /afs のすぐ下にある、ユーザーのセルのファイル・ツリーの 2 番目のレベルで、セルの root.cell ボリュームを取り付ける。 セルラー・マウント・ポイントを作成する方法 で説明されているように、fs mkmount コマンドを -cell 引き数を指定して使用します。
2. クライアント・マシンの /afs ディレクトリーに AFS を取り付ける。キャッシュ・マネージャーを初期化する afsd プログラムは、ローカルの /usr/vice/etc/cacheinfo ファイルで 1 番目のフィールドに指定されたディレクトリー、またはコマンドの -mountdir 引き数に指定されたディレクトリーに、自動的に取り付けを実行します。代替の位置に AFS を取り付けると、 root.afs ボリュームおよび root.cell ボリュームを従来の位置に取り付けるセルのファイル・スペースにアクセスすることは不可能になります。 キャッシュのサイズおよびロケーションの表示および設定 を参照してください。
3. キャッシュ・マネージャーがカーネル・メモリーに保守しているデータベース・サーバー・マシンのリストにセルの項目を作成します。

   あらゆるクライアント・マシンのローカル・ディスク上の /usr/vice/etc/CellServDB ファイルには、ローカル・セルと外部セルのデータベース・サーバー・マシンがリストされています。afsd プログラムは、キャッシュ・マネージャーを初期化するときに、CellServDB ファイルの内容を読み取ってカーネル・メモリーに入れます。また、fs newcell コマンドを使用すると、マシンのリブートとリブートの間に、カーネル・メモリーの項目を直接追加または更新できます。データベース・サーバー・マシンの情報を保持するを参照してください。

外部セルをクライアント・マシンが見ることができるようにしても、ユーザーがその外部セルのファイル・スペースにアクセスできる保証はありません。外部セル内の ACL が、必要なアクセス権をユーザーに許可しなければなりません。

### ユーザーのセルへの外部ユーザーのアクセスに対する許可と禁止

AFS グローバル・ネーム・スペースでセルを可視にしても、外部セルのユーザーがファイル・ツリーにアクセスする方法を管理者が制御できなくなるわけではありません。

デフォルトでは、外部ユーザーはユーザー anonymous としてセルにアクセスします。このことは、外部ユーザーは各ディレクトリーの ACL で、system:anyuser グループに対して付与された許可しか持っていないことを意味します。通常、これらの許可は、l (検索) および r (読み取り) アクセス権に制限されています。

外部ユーザーに対してさらに広いアクセス権を認める方法としては、次の 2 つがあります。

- 特定の ACL で、system:anyuser グループに追加のアクセス権を許可する。ただし、その時には、指示された方法ですべてのユーザーが、そのディレクトリーにアクセスできることを心に留めておいてください (ユーザーが意図した特定の外部のユーザーだけではありません)。
- 保護および認証データベースとローカルのパスワード・ファイルに項目を作成して、特定の外部ユーザーにローカルな認証アカウントを作成する。外部ユーザー名を ACL に入れることはできません。また、ACL にアカウントがなければ外部セルで認証することもできません。

## AFS ファイル・スペースの構成

この機能グループでは、AFS ファイル・スペースを構成する際の考慮事項を要約します。ファイル・スペースのディレクトリー構造に最適な対応をするボリュームの作成に関する説明は、管理を簡単にするためのボリュームの作成 を参照してください。

Windows ユーザーへの注: Windows は、パス名の要素を区切るのに円記号 ( \ ) を使用し、スラッシュ (/) を使用しません。ただし、ファイル・スペースの階層構成は UNIX マシンの場合と同じです。

AFS パス名は多少の規則に従わなければなりません。これは、AFS グローバル・ネーム・スペースが AFS クライアント・マシンから同じように見えるようにするためです。ファイル・ツリーを作成する際に従わなければならない対応する規則があります。これは、パス名がファイル・ツリーの構造を反映するだけでなく、 AFS キャッシュ・マネージャーが一定の構成を予期するためです。

### 最上位 /afs レベル

1 番目の規則は、ファイル・ツリーの最上位のレベルを /afs ディレクトリーと呼ぶことです。それ以外の名前を付ける場合には、 -mountdir 引き数を指定した afsd プログラムを使用して、キャッシュ・マネージャーが AFS を正しく取り付けるようにしなければなりません。その場合、 AFS グローバル・ネーム・スペースに参加することはできません。

### 2 番目の (セル名) レベル

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 番目のレベル

ユーザーが希望する任意の方法で、ユーザーのセルのファイル・ツリーの 3 番目のレベルを編成することができます。以下のリストでは、一般的な構成でこのレベルに現れるディレクトリーを説明しています。

common
  このディレクトリーには、すべてのシステム・タイプのマシン上で作業するユーザーが必要とするプログラムおよびファイル (テキスト・エディター、オンライン・ドキュメンテーション・ファイルなど) が含まれます。/etc サブディレクトリーは、 ThisCell ファイルや CellServDB ファイルなどの、ユーザーのセルのすべてのクライアント・マシンで使用するファイルの中央更新ソースを保持するための論理的な場所です。

public
  ACL が system:anyuser グループに l (lookup) アクセス権と r (read) アクセス権を許可しているために、ユーザーのファイル・スペースにアクセスできるすべての人がアクセス可能なディレクトリーです。選択された情報をユーザーがすべての人に使用できるようにさせたいけれども、ユーザーのホーム・ディレクトリーを収容している (そして、このレベルにある) usr ディレクトリーの内容へのアクセス権を外部ユーザーに許可したくない場合には、これが役に立ちます。ユーザーのセルのユーザーごとにサブディレクトリーを作成するのが通例です。

service
  このディレクトリーには、セルが資源共有を調整するのに役立つファイルとサブディレクトリーが含まれます。作成するように提案されている標準ファイルおよびサブディレクトリーのリストについては、 AFS プロダクト・サポートに電話または書面でお問い合わせください。

  たとえば、ほかのセルが、このディレクトリーの etc サブディレクトリーで見つかると予想しているファイルには、以下のファイルがあります。

  - CellServDB.export (多くのセルのデータベース・サーバー・マシンのリスト)
  - CellServDB.local (セル自身のデータベース・サーバー・マシンのリスト)
  - passwd (セルのクライアント・マシンのローカル・ディスクに保存されているローカル・パスワード・ファイル (/etc/passwd または同等のファイル) のコピー)
  - group (セルのクライアント・マシンのローカル・ディスクに保存されているローカル・グループ・ファイル (/etc/group または同等のファイル) のコピー)

sys_type
  セル内で使用するシステム・タイプごとに、サーバーおよびクライアントのバイナリーを格納するための分離したディレクトリー。 AFS の配布で割り当てられたシステム・タイプ名を使用する場合、特に、パス名に @sys 変数を使用することを望む場合は、構成は最も単純です (パス名での @sys 変数の使用 を参照してください)。AFS Release Notes では、サポートされているシステム・タイプごとに通例の名前をリストしています。

  そのような各ディレクトリー内に、bin、etc、usr、などの名前のディレクトリーを作成し、通常ローカル・ディスク上の /bin、/etc および /usr ディレクトリーに保持されているプログラムを保管します。次に、クライアント・マシンのローカル・ディレクトリーから AFS へのシンボリック・リンクを作成します (ローカル・ディスクの構成 を参照してください)。たとえ、この方法でシンボリック・リンクを使用することを選択しない場合でも、 AFS のシステム・バイナリーの中央コピーを持つことが便利なことがあります。バイナリーが間違ってマシンから除去される場合には、テープからそれを回復しなければならないのではなく、 AFS からローカル・ディスクにコピーを取り直すことができます。

usr
  このディレクトリーには、ローカル・ユーザー用のホーム・ディレクトリーが含まれます。public ディレクトリーに関する前の項目で説明したように、多くの場合は、このディレクトリーを保護して、ローカルで認証されたユーザーだけがそのディレクトリーにアクセスできるようにするのが実際的です。これによって、ユーザーのホーム・ディレクトリーのコンテンツが、できる限り安全に保持されます。

  ユーザーのセルがかなり大きい場合には、すべてのホーム・ディレクトリーを単一の usr ディレクトリーに入れると、ディレクトリー検索が遅くなることがあります。ユーザーのホーム・ディレクトリーを複数のグループ化ディレクトリーに分散させることに関する提案は、 ホーム・ディレクトリーのグループ化 を参照してください。

wsadmin
  このディレクトリーには、package プログラムで使用するためのプロトタイプ、構成およびライブラリー・ファイルが含まれます。パッケージ・プログラムを使用したクライアント・マシンの構成を参照してください。

## 管理を簡単にするためのボリュームの作成

この機能グループでは、ユーザーのシステムの管理を容易にする方法でボリュームを作成する方法について説明します。

ユーザーのファイル・ツリーの上位のレベル (少なくても 3 番目のレベルまで) では、一般的に、それぞれのディレクトリーは別々のボリュームに対応します。セルの中には、別々のボリュームとして、 3 番目のレベルのディレクトリーのいくつかに、サブディレクトリーを作成するものもあります。一般的な例は、/afs/cellname/common および /afs/cellname/usr ディレクトリーです。

ツリーのすべてのディレクトリー・レベルに別のボリュームを作成する必要はありませんが、そうする方が、各ボリュームは、ロード・バランシングのためにはより小さくより移動しやすくなるという利点があります。マウント・ポイントのオーバーヘッドは、標準ディレクトリーのものより大きくありません。また、ボリューム構造そのものも多量のディスク・スペースを必要としません。ほとんどのセルでは、ツリーの 4 番目のレベルの下で、それぞれのディレクトリーに別々のボリュームを使用することは、もう有効ではないことが分かります。たとえば、各ユーザーのホーム・ディレクトリー (ツリーの 4 番目のレベルの) は、別々のボリュームに対応している一方で、通常、ホーム・ディレクトリーにあるすべてのサブディレクトリーは、同じボリュームに常駐しています。

ツリーの指定された位置では、1 つのボリュームしか取り付けられないことに留意してください。それとは反対に、ボリュームを複数の場所に取り付けることもできますが、これはお勧めできません。そのようにするとファイル・ツリーの階層的な性質がゆがめられ、混乱の原因になる可能性があるからです。

### ボリューム名の割り当て

次に示す制約に従えば、ボリュームにはどのような名前でも付けることができます。

- 読み取り / 書き込みボリューム名の長さは 22 文字までとする。ボリューム名の最大長は 31 文字ですが、読み取り専用ボリュームには、拡張子 .readonly を追加するための余裕を残しておかなければなりません。
- ボリューム名には、適切な拡張子であっても、.readonly および .backup 拡張子を追加しないでください。それらの拡張子は、ボリューム・サーバーがボリュームの読み取り専用またはバックアップ・バージョンを作成する際に自動的に追加します。
- root.afs および root.cell という名前のボリュームが、それぞれ、ファイル・スペース内の最上位レベル (/afs) とそのすぐ下のレベルのセル名 (たとえば、ABC Corporation セルの場合 /afs/abc.com) になければなりません。

  これらの名前から逸脱すると、混乱と余分な作業が発生するだけです。たとえば root.afs ボリュームの名前を変更するということは、代替ボリュームに名前を付けるために、すべてのクライアント・マシン上の afsd プログラムに -rootvol 引き数を使用しなければならない、ということです。

  同様に、root.cell ボリュームの名前を変更すると、ファイル・スペース内のセルのマウント・ポイントが標準の root.cell 名を使用していれば、外部セルのユーザーがファイル・スペースにアクセスできなくなります。もちろん、これはセルを他のセルから見えなくしてしまう方法ではありますが。

ボリュームには、そのボリュームに含まれるデータのタイプを示すボリューム名を割り当て、類似の内容を持つボリュームには類似の名前を使用するのが最適です。ボリューム名は、ボリュームを取り付けるディレクトリーの名前に似ている (少なくても、共通の要素をもっている) 場合も、役に立ちます。このパターンを理解しておけば、ボリュームに含まれている内容とそれが取り付けられている場所を正確に推測することができます。

多くのセルは、最も効果的なボリューム命名体系は、すべての関連したボリュームに共通の接頭部を書き込むことだということに気付きます。表 1 では、推奨される接頭部変換について説明します。

表 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 システム・ボリュームとディレクトリーの、より具体的な例です。

表 2. ボリューム接頭部体系の例

例の名前 | 例のマウント・ポイント
--- | ---
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

この体系には、いくつかの利点があります。

- ボリューム名は、ファイル・スペース内のマウント・ポイント名に類似しています。たとえば、表 2 のすべての項目では、ボリューム名とマウント・ポイント名の唯一の違いは、前者は区切り記号としてピリオドを使用するのに対して、後者はスラッシュを使用するという点です。もう 1 つの利点は、ボリューム名は内容を示すということです。あるいは少なくとも、内容を知るために、ls コマンドが発行されるディレクトリーを示唆するという点です。
- ボリューム名を使用すると、関連したボリュームのグループを簡単に一度に操作できます。特に、vos backupsys コマンドの -prefix 引き数を使用すると、同じ文字列で始まる名前をもつあらゆるボリュームのバック・バージョンを作成することができます。各ボリュームのバックアップ・バージョンを作成することは、 AFS バックアップ・システムを使ってボリュームをバックアップする最初のステップの 1 つであり、 1 つのコマンドで多くのボリュームにそのステップを実行することで、ユーザーが多くを入力する手間が省けます。バックアップ・ボリュームを作成するための手順については、 バックアップ・ボリュームの作成 を参照してください。AFS のバックアップ・システムについては、AFS バックアップ・システムの構成 と AFS データのバックアップと復元 を参照してください。
- ボリューム名を使用すると、関連したボリュームを 1 つの区分にまとめて簡単にグループ化することができます。関連したボリュームをまとめてグループ化することには、 区分における関連したボリュームのグループ化 で説明する、いくつかの独特な利点があります。

### 区分における関連したボリュームのグループ化

セルが、実用上問題のないくらい十分に大きい場合は、関連するボリュームをグループ化して 1 つの区画にまとめることを考えてください。一般的には、ボリュームのグループ化を効果的に行うためには、少なくても 3 つのファイル・サーバー・マシンが必要です。グループ化にはいくつかの利点があります。ファイル・サーバー・マシンがアクセス不能になる場合にその利点が最も顕著に現れます。

- ある区画上のボリュームのハードコピー・レコードを保持していれば、どのボリュームが使用不可なのかが分かります。関連したボリュームをグループ化しないで、そのようなレコードを保持することもできますが、関連していないボリュームで構成されるリストは、保守がかなり困難です。レコードは用紙に記録しなければならないことに注意してください。それは、故障によってオンライン・コピーにアクセスできなくなったり、あるいは、ユーザーに同じ情報を提供する vos listvol コマンドを発行できなくなるかもしれないからです。
- 障害の影響がさらに限定されます。たとえば、与えられたシステム・タイプのすべてのバイナリーが 1 つの区分にある場合には、そのシステム・タイプのユーザーだけが影響を受けます。区分に複数のシステム・タイプのバイナリー・ボリュームが収容されている場合、故障がもっと多くの人々に影響を及ぼす可能性があります。使用可能な状態を維持しているバイナリーと使用可能でないバイナリーが相互に依存している場合は、特にそうです。

関連したボリュームを区分でグループ化することの利点は、必然的に、関連したすべてのボリュームを 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 のコピーです。読み取り / 書き込みボリュームが別の区画に移動した場合、あるいは大きな変更が加えられた場合に限り、読み取り専用ボリュームは大量のディスク・スペースを消費します。他の区画に保持されている読み取り専用ボリュームは、常に、読み取り専用ボリュームの作成時に読み取り / 書き込みソースが消費したディスク・スペースの量をすべて消費します。

### デフォルトの割り当て量と新規ボリュームの ACL

あらゆる AFS ボリュームには、使用できるディスク・スペースの量を制限する割り当て量があります。割り当て量を設定し、変更するには、ボリューム割り当て量および現行サイズの設定および表示 で説明されているコマンドを使用します。

vos create コマンドに -maxquota 引き数を組み込んでいないかぎり、デフォルトでは、あらゆる新規のボリュームには 5000 KB ブロックのスペース割り当て量が割り当てられます。同じくデフォルトで、新規に作成されたすべてのボリュームのルート・ディレクトリーにある ACL は、 system:administrators グループのメンバーに全アクセス権を付与します。個々のコマンドでアカウントを作成するときにこれらの値を変更する方法については、個別のコマンドを使用して単一ユーザー・アカウントを作成する を参照してください。 uss コマンドを使ってアカウントを作成するときは、代替 ACL と代替割り当て量の値をテンプレート・ファイルの V 命令に指定します。 V 命令によるボリュームの作成 を参照してください。

## サーバー・マシンの構成

このセクションでは、AFS データを保管し、それを要求時にクライアント・マシンに転送し、そして AFS 管理データベースを収容するサーバー・マシンを構成する際に考慮しておかなければならない問題について検討します。クライアント・マシンについて確認するには、クライアント・マシンの構成 を参照してください。

セルに複数の AFS サーバーがある場合には、そのサーバーを構成して、特別な機能を実行することができます。マシンは、以下のリストで説明されている役割を 1 つ以上担うことができます。詳しくは、ファイル・サーバー・マシンの 4 つの役割 を参照してください。

- シンプル・ファイル・サーバー・マシンは、 AFS ファイルをクライアント・マシンに保管し、引き渡すプロセスだけを実行します。ユーザーのセルのパフォーマンスとディスク空間の要件を満たすのに必要なだけの、シンプル・ファイル・サーバー・マシンを実行することができます。
- データベース・サーバー・マシン は、 AFS の複写された管理用データベースを保守する 4 つのプロセス、認証、バックアップ、保護、およびボリューム・ロケーション (VL) のサーバー・プロセスを実行します。
- バイナリー配布マシン は、そのマシンのシステム型の AFS サーバー・バイナリーを、そのシステム型のほかのすべてのサーバー・マシンに配付します。
- 単一のシステム制御マシンは、共通のサーバー構成ファイルを、セル内のほかのすべてのサーバー・マシンに配付します。セル内では、AFS の米国版を実行します (AFS の国際版を使用するセルでは、この目的のためにシステム制御マシンを使用してはいけません)。従来通り、マシンは、セルの時間同期ソースとしても稼働し、セルの外部の時間ソースに従って時刻を調整します。

AFS インストールの手引き では、4 つの役割すべてを担う、セルの最初のファイル・サーバー・マシンを構成する方法について説明しています。 AFS インストールの手引き の章では、追加サーバー・マシンのインストールの他に、1 つ以上の役割を実行するようにそれらのマシンを構成する方法についても説明しています。

### AFS 管理データベースの複写

AFS 管理データベースは、データベース・サーバー・マシン上に保持されており、セルが正常に機能するために必要な情報を保管しています。サーバー・プロセスおよびキャッシュ・マネージャーは頻繁にその情報にアクセスします。

- キャッシュ・マネージャーが、前にアクセスしたことのないディレクトリーからファイルを取り出す場合、キャッシュ・マネージャーはボリューム・ロケーション・データベース (VLDB) でファイルの位置を検索しなければなりません。
- ユーザーが認証サーバーから AFS トークンを取得するたびに、サーバーは認証データベースでユーザーのパスワードを検索します。
- ユーザーが特定のファイル・サーバー・マシン上に存在するボリュームに初めてアクセスすると、ファイル・サーバーは保護サーバーと交信して、保護データベースに記録されているユーザーのグループ・メンバーシップのリストを取得します。
- AFS バックアップ・システムを使ってボリュームをバックアップするたびに、バックアップ・サーバーはバックアップ・データベースにそのバックアップのレコードを作成します。

最初のマシンが、データベース・サーバー・マシンとして使用する予定のあるマシンの最低位の IP アドレスを持っている場合は、セルの保守が最も簡単になります。低位アドレスをもつマシンをデータベース・サーバー・マシンとして使用することを後で決めると、新規マシンを導入する前に、すべてのクライアントで CellServDB ファイルを更新しなければなりません。

セルに複数のサーバー・マシンがある場合は、複数のマシンをデータベース・サーバー・マシンとして実行するのが最適です (ただし、4 台以上のマシンを実行する必要はほとんどありません)。この方法で管理データベースを複写すると、ボリュームの複写と同じ利点、すなわち可用性と信頼性の向上が生まれます。 1 つのデータベース・サーバー・マシンあるいはプロセスが機能を停止しても、他のマシンからはデータベース内の情報を使用することができます。データベース情報に対する要求のロードが複数のマシンに分散し、いずれのマシンも過負荷になることがないようにします。

ただし、複写されたボリュームと異なり、複写されたデータベースは頻繁に変更されます。一貫したシステム・パフォーマンスを得るためには、データベースのすべてのコピーが常に同一であることが要求されるので、変更をそれらのコピーの一部にだけ記録することはできません。データベースのコピーを同期化するために、データベース・サーバー・プロセスでは、 AFS の分散データベース・テクノロジーである Ubik を使用します。 AFS 管理データベースの複写 を参照してください。

セルにファイル・サーバー・マシンが 1 つしかない場合、ファイル・サーバー・マシンはデータベース・サーバー・マシンとしても機能しなければなりません。セルにファイル・サーバー・マシンが 2 つある場合、両方をデータベース・サーバー・マシンとして実行することには必ずしも利点がありません。サーバー、プロセス、あるいはネットワークの障害により、2 つのマシン上のデータベース・サーバー・プロセス間の通信が途絶えた場合は、どちらのマシンも単独で自らを同期サイトとして立ち上げることができないため、データベース内の情報を更新することは不可能になります。

### ローカル・ディスク上の AFS ファイル

プロセスの一部がマシン上でアクティブに実行されなくても、すべてのファイル・サーバー・マシン上の /usr/afs/bin ディレクトリーにすべての AFS サーバー・プロセスのバイナリーを保管するのが一般には最も簡単です。これによって、新規の役割を果たすためにマシンを再構成することが簡単になります。

セキュリティー上の理由から、ファイル・サーバー・マシン上の /usr/afs ディレクトリーとそのサブディレクトリーおよびファイルはすべて、ローカルのスーパーユーザー root が所有し、最初の w (書き込み) モード・ビットのみをオンにしなければなりません。ファイルによっては 最初の r (読み取り) モード・ビットだけをオンにしているものもあります (たとえば、AFS サーバーの暗号化鍵をリストする /usr/afs/etc/KeyFile ファイル)。 BOS サーバーは、開始する度に、特定のファイルおよびディレクトリーのモード・ビットが、期待されている値に一致するかどうかを検査します。リストについては、機密の AFS ディレクトリーの保護に関する AFS インストールの手引き セクション、あるいは、サーバー・プロセスの状況とその BosConfig 項目を表示する方法 の bos status コマンドの結果に関する説明を参照してください。

ファイル・サーバー・マシンのローカル・ディスク上のすべての AFS ディレクトリーの内容の説明については、サーバー・マシンの管理 を参照してください。

### AFS データを保管するための区分の構成

ファイル・サーバー・マシンに AFS ボリュームを収容する区分は、以下の名前が付いたディレクトリーに取り付けなくてはなりません。

/vicepindex

ここで、index は、1 文字または 2 文字の小文字です 通例、最初に作成された AFS 区画は、/vicepa ディレクトリーに取り付けられ、2 番目の AFS 区画は /vicepb ディレクトリーに取り付けられる、というように /vicepz ディレクトリーまで取り付けられます。このようにして名前は /vicepaa から /vicepaz まで、/vicepba から /vicepbz までというように、サーバー区画のサポート数 (AFS Release Notes で指定されています) まで続きます。

各 /vicep x ディレクトリーは、区画全体あるいは論理ボリュームに対応しなければなりません。また、ルート・ディレクトリー (/) のサブディレクトリーでなければなりません。 (たとえば) /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 プログラムを呼び出しています。) リブート中のその時点よりも前に必要なファイルは、ローカル・ディスクに常駐しなければなりません。これらのファイルには、以下のファイルが含まれますが、このリストは必ずしもすべてを網羅しているわけではありません。

- 以下またはそれと等価なユーティリティーを含む、標準 UNIX ユーティリティー
  - マシン初期設定ファイル (多くのシステム・タイプでは /etc または /sbin ディレクトリーに保管)
  - fstab ファイル
  - mount コマンド・バイナリー
  - umount コマンド・バイナリー
- /usr/vice ディレクトリー以下のすべてのサブディレクトリーとファイル (以下を含む)
  - /usr/vice/cache ディレクトリー
  - /usr/vice/etc/afsd コマンド・バイナリー
  - /usr/vice/etc/cacheinfo ファイル
  - /usr/vice/etc/CellServDB ファイル
  - /usr/vice/etc/ThisCell ファイル

  これらのファイルに関する詳細については、ローカル・ディスク上の構成ファイルおよびキャッシュ関連ファイル を参照してください。

ローカルのディスク上に保持されるその他のタイプのファイルとプログラムは、ファイル・サーバーの停止によって引き起こされる問題を診断し、修正する場合に必要となるものです。それは、ファイル・サーバーの停止により 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 ファイルのそのマシン用のコピーを保守しているので、理論上は、別のクライアント・マシン上の別の外部セルにアクセスすることができます。ただし、通常はこれでは実際の役には立ちません。特にユーザーが常に同じマシン上で作業をしているわけではないような場合にはそうです。

### パス名での @sys 変数の使用

ローカル・ディスク上の 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 ユーザー・アカウントを構成する際の考慮事項を説明します。AFS は UNIX のファイル・システムとは分離されているため、ユーザーの AFS アカウントはそのユーザーの UNIX のアカウントとは分離されています。

ユーザー・アカウントの作成のための望ましい方法は、uss 組のコマンドを使用することです。アカウントの作成を手引きするテンプレート・ファイルを準備した後、単一のコマンドを使い、 1 つまたはたくさんのアカウントのすべてのコンポーネントを作成することができます。uss コマンド組によるユーザー・アカウントの作成と削除 を参照してください。

あるいは、アカウントの各コンポーネントを作成する個々のコマンドを発行することができます。そのための手順と、ユーザー・アカウントの削除、およびユーザーのパスワード、ユーザーのボリューム割り当て量、そしてユーザー名の変更のための手順については、ユーザー・アカウントの管理 を参照してください。

ユーザーが自分のシステムを離れる場合には、アカウントを削除するのはよいポリシーです。これについての説明は、uss delete コマンドによる個別アカウントの削除 および ユーザー・アカウントの削除 にあります。

AFS のユーザー・アカウントは、以下のコンポーネントで構成されています。これらのコンポーネントは、AFS ユーザー・アカウントのコンポーネント で詳細に説明されています。

- 保護データベース項目
- 認証データベース項目
- ボリューム
- ボリュームを取り付けるホーム・ディレクトリー
- ホーム・ディレクトリーの所有権とその ACL におけるすべてのアクセス権
- ユーザーがログインする必要がある各マシンのローカル・パスワード・ファイル (/etc/passwd または同等のファイル) の項目
- オプションとして、アカウントをさらに役に立つようにしている標準ファイルとサブディレクトリー

一部のコンポーネントを作成し、それ以外は作成しないようにすることにより、uss コマンド組によるユーザー・アカウントの作成と削除 で説明されている uss コマンドまたは ユーザー・アカウントの管理 で説明されているここのコマンドを使用して、異なる機能レベルのアカウントを作成することができます。機能レベルには以下のものが含まれます。

- 認証専用アカウント を使用すると、ユーザーは、 AFS トークンを入手でき、したがって、保護された AFS データにアクセスして特権コマンドを発行できます。このアカウントは、認証データベースと保護データベースの項目だけで構成されます。このタイプのアカウントは、管理アカウント、および保護されたデータにアクセスする必要がある外部セルのユーザーに対して適切です。また、ローカル・ユーザーも、通常、ボリュームおよびホーム・ディレクトリーを必要とします。
- 基本ユーザー・アカウント は、認証および保護データベース項目に加えて、ユーザー用のボリュームを含みます。ボリュームは、AFS ファイル・スペースにユーザーのホーム・ディレクトリーとしてマウントされ、ユーザーの個人ファイル用のリポジトリーを提供します。
- フルアカウント は、ログイン、印刷、メール送信などの基本機能の構成ファイルを基本アカウントに追加して、基本アカウントをさらに便利で有用にします。いくつかの有用なタイプの構成ファイルについての説明は、 新規の AFS アカウントでの標準ファイルの作成 を参照してください。

セル内に AFS を導入する前の UNIX のユーザー・アカウントを持つユーザーがいる場合は、それらユーザーのアカウントを AFS のアカウントに変換したいでしょう。この場合、主に以下に示した 3 つの項目を考慮する必要があります。

- UNIX と AFS UID を一致させる
- ローカル・パスワード・ファイルにパスワード・フィールドを適切に設定する
- ファイルを UNIX ファイル・システムから AFS へ移動する

詳しくは、uss による既存の UNIX アカウントの変換 または 既存の UNIX アカウントの変換 を参照してください。

### ユーザー名の選択とほかのアカウント・コンポーネントの命名

この機能グループでは、ユーザー名、AFS UID、ユーザー・ボリューム名およびマウント・ポイント名を選択するためのスキームを提案し、選択上のいくつかの制約事項の概略も説明します。

ユーザー名

AFS がユーザー名の形式に課す制約はごくわずかです。多くのユーティリティーとアプリケーションが 8 文字以下のユーザー名を処理することができるという理由と、一般には AFS のアカウントの多くのコンポーネントがその名前を含んでいるという 2 つの理由から、ユーザー名は短くしておくのが最適です。アカウントのコンポーネントは、保護および認証データベースの項目、ボリューム、およびマウント・ポイントを組み込んでいます。電子メールの送信システムによっては、ユーザー名をユーザーのメール・アドレスの一部にすることができます。ユーザー名は、ユーザーがクライアント・マシンにログインするときに入力する文字列でもあります。

一般にユーザー名として選ばれるのは、ラストネーム、ファーストネーム、イニシャル、あるいはそれらの組み合わせですが、数字が追加されることもあります。また、以下の文字は使用しないことが最適です。これらの文字の多くは、コマンド・シェルに対して特別な意味をもっています。

- コンマ ( , )
- コロン ( : )。AFS では、保護グループ名のフィールド区切り記号に予約済みです。 ユーザー定義のグループの 2 つのタイプ を参照してください。
- セミコロン ( ; )
- "アットマーク" ( @ )。この文字は、インターネット・メール・アドレスに予約済みです。
- スペース
- 改行文字
- ピリオド ( . )。この文字は、 pat.admin のように、管理者が特権タスクを実行する際に採用する特別なユーザー名でだけ使用するのが通例です。

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 をグループ化したい場合
- 既存の UNIX アカウントを AFS アカウントに変換し、AFS UID を既存の UNIX UID に一致させたい場合

保護サーバーは、初めてセルの最初のファイル・サーバー・マシンで初期化後、デフォルト値で 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 に適するように変えたものです。ただし、数百より多いユーザーがいるセルでは、すべてのユーザー・ボリュームを単一のディレクトリーに取り付けると、ディレクトリーの検索が遅くなることがあります。解決法は、ユーザー・ボリューム・マウント・ポイントをいくつかのディレクトリーに配布することです。これを完了するための代替のメソッドは、たくさんあります。

- ユーザーのホーム・ディレクトリーを、教育部門や企業の部門など、組織の部門を反映する複数のディレクトリーに分散させる。たとえば、会社であれば usr/marketing、usr/research、usr/finance というグループ・ディレクトリーを作成することができます。このスキームの優れた機能は、ユーザーの部門についての知識が十分で、ユーザーのホーム・ディレクトリーを検出できることです。また、この機能によって、アクセス権をその部門のメンバーだけに制限するよう ACL を設定するのが容易になります。大きい部門のユーザーの検索の速さが、小さい部門のユーザーが検索するより遅いというくらい、部門のサイズが偏っている場合には、潜在的な欠点が現れます。このスキームは、ユーザーが部門間を頻繁に替わるようなセルには適していません。
- ホーム・ディレクトリーを usr ディレクトリー (usr/a サブディレクトリー、 usr/b サブディレクトリーなど) の英字サブディレクトリーに、ユーザー名の先頭の文字に基づき、分散する。セルが非常に大きな場合は、各文字の下に、ユーザー名の 2 番目の文字に対応するサブディレクトリーを作成します。このスキームには、部門ベースのスキームの同じ利点と欠点があります。ユーザーのユーザー名を知っている人はだれでも、ユーザーのホーム・ディレクトリーを検出することができますが、一般的な文字で始まる名前をもつユーザーは、検索が遅いという経験をする場合があります。
- ホーム・ディレクトリーを複数のグループ・ディレクトリーにランダムにかつ等しく分散させる。このスキームを使用する 1 つのセルには、 usr1 ディレクトリー、usr2 ディレクトリーなどというディレクトリーが 20 以上あります。このスキームが特に適しているのは、ほかの 2 つのスキームが実行できそうに見えないセル内です。このスキームは、検索速度の違いという潜在的な問題を除去します。それは、すべてのディレクトリーがほぼ同じサイズだからです。このスキームの欠点は、指定されるユーザーのボリュームが取り付けられるディレクトリーを推測する方法がないことですが、解決法は、実際のマウント・ポイントを参照する正規の usr ディレクトリーで、シンボリック・リンクを作成することです。たとえば、ユーザー smith のボリュームが、 /afs/bigcell.com/usr17/smith ディレクトリーで取り付けられると、 /afs/bigcell.com/usr/smith が、 ../usr17/smith ディレクトリーに対するシンボリック・リンクになります。このようにして、どのディレクトリーにユーザー smith がいるのか知らない人がいる場合には、その人物は、usr/smith としてディレクトリーにアクセスすることができます。適切なディレクトリーを知っている人々は、そのディレクトリーを指定すれば検索時間を短くすることができます。

uss プログラムを使用してユーザー・アカウントを作成するときに、さまざまなスキームをインプリメントする方法に関する説明については、 G 命令によるユーザー・ホーム・ディレクトリーの均等配布 と V 命令によるボリュームの作成 を参照してください。

### 使用可能なユーザー・ボリュームのバックアップ・バージョンの作成

ユーザーのボリュームのバックアップ・バージョンを取り付けるのが、ユーザーが誤って除去または削除したデータをユーザー自身が復元できるようにするための簡単な方法です。バックアップ・バージョンは、ユーザーのホーム・ディレクトリーのサブディレクトリー (おそらく OldFiles というサブディレクトリー) に取り付けるのが通例ですが、他のスキームも可能です。一日に 1 回、新規のバックアップ・バージョンを作成して、その日に行われた変更を取り込み、前日のバックアップ・バージョンを新規のバックアップ・バージョンで上書きします。ユーザーは、管理者の助けがなくても常に前日のファイルのコピーを取り出すことができ、管理者はより緊急のタスクを処理する時間がとれます。

ユーザーは、自分のバックアップ・ボリュームのマウント・ポイントを削除したがることがあります。それは、バックアップ・ボリューム内の内容によってボリュームの割り当て量が減るとユーザーが誤解しているからです。そのような場合には、バックアップ・ボリュームは分離しているので、バックアップ・ボリュームがユーザー・ボリュームで使用するスペースは、マウント・ポイントに必要な量だけであることをユーザーに気付かせてください。

バックアップ・ボリュームの詳しい説明は、AFS データのバックアップ と バックアップ・ボリュームの作成 を参照してください。

### 新規の AFS アカウントでの標準ファイルの作成

UNIX 管理者としてのユーザーの経験から、ユーザーは多分ログインとシェルの初期設定ファイル (.login ファイルと .cshrc ファイルなど) を使ってアカウントを使いやすくすることに慣れているでしょう。

いくつかの AFS 固有のディレクトリーを、以下を含めて、ユーザーの `PATH` 環境変数の定義に追加しておくと実際に役に立つことがよくあります。

- ユーザーが作成したバイナリー用のユーザーのホーム・ディレクトリーにある bin サブディレクトリーへのパス (すなわち、/afs/ cellname/usr/ username/bin)
- /usr/afsws/bin パス。通例では、 fs、klog、kpasswd、pts、tokens、および unlog などのプログラムを含みます。
- ユーザーが管理者の場合は、/usr/afsws/etc パス。このパスには、通常、特権を必要とする AFS コマンドの組 (backup、butc、kas、uss、vos コマンド)、package プログラム、およびその他が含まれます。

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 保護グループの使用

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 つのプライバシー・フラグ のセットで保護されます。デフォルトのプライバシー・フラグはかなり限定的ですが、ユーザー項目に対しては特に限定的です。データベース項目のプライバシー・フラグを設定 を参照してください。

### 3 つのシステム・グループ

保護サーバーは、セルの最初のデータベース・サーバー・マシンではじめて初期化を行う際に、system:anyuser、system:authuser、および system:administrators グループという 3 つのグループ項目を自動的に作成します。

最初の 2 つのシステム・グループは、保護データベースにあるほかのグループとは異なります。ほかのグループは、保護データベース内で継続的なメンバーシップをもっていません。

- system:anyuser グループには、セルの AFS ファイル・スペースにアクセスできるすべてのユーザーが含まれます。このようなユーザーとしては、ローカル・セルのトークンを持っているユーザー、ローカルの AFS クライアント・マシンにログインしたけれどもトークンを取得していないユーザー (ローカルのスーパーユーザー root など)、およびセルの外部からローカル・マシンに接続したユーザーがいます。system:anyuser グループを ACL に配置することによって、できるだけ幅広い範囲のユーザーにアクセスが許可されます。これが、ローカル・アカウントを所有していない外部の AFS セルからのユーザーにアクセスを拡張する唯一の方法です。
- system:authuser グループには、セルの AFS 認証サービスから取得した有効なトークンを持つすべてのユーザーが含まれます。

このグループは継続的なメンバーシップを持っていないので、 pts membership コマンドはこのグループに対しては何の出力も生成しません。同様に、このグループはユーザーが属するグループのリストにも表示されません。

system:administrators グループには、継続的メンバーシップはありません。このグループは特権管理者で構成されます。このグループのメンバーは、任意の pts コマンドを発行できます。また、このメンバーだけが、いくつかのほかの制限付きコマンド (AFS ファイルの chown コマンドなど) を発行することができます。デフォルトでは、このグループは暗黙で a (管理者) および l (検索) アクセス権をファイル・スペースのすべての ACL に持っています。このデフォルトの変更については、 system:administrators グループの管理 を参照してください。

ACL でシステム・グループを効果的に使用する方法については、ACL 上でのグループの使用 を参照してください。

### ユーザー定義のグループの 2 つのタイプ

すべてのユーザーは正規 グループを作成することができます。正規グループの名前にはコロンで区切られた 2 つのフィールドがあり、その最初のフィールドはそのグループの所有権を示していなければなりません。結果が所有権を正確に指示しない場合には、保護サーバーはグループの名前の作成または変更を拒否します。

system:administrators グループのメンバーは、所有権を示す第 1 フィールドを持たない名前を持つ接頭部なし のグループを作成することができます。2 つのタイプのグループを効果的に使用することに関する提案については、グループの効果的な使用 を参照してください。

## AFS でのログインと認証

認証における相違 で説明したように、AFS 認証と UNIX 認証は分離されています。これは 2 つのファイル・システムが分離されているからです。この分離には、2 つの実用的な意味があります。

- AFS ファイルにアクセスするには、ユーザーはローカル・ファイル・システムにログインし、AFS 認証サービスで認証を受けなければなりません。 (ローカル・ファイル・システムにログインする必要があるのは、AFS ファイル・スペースにアクセスする唯一の方法が、ローカル・マシンのカーネルに常駐するキャッシュ・マネージャーを介することであるからです。)
- パスワードは 2 つの異なる場所に保管されます。それらの場所とは、AFS の認証データベースと、各マシンのローカル・ファイル・システム用ローカル・パスワード・ファイル (/etc/passwd ファイルまたは同等のファイル) です。

ユーザーが正常に認証されると、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 を参照してください。

### PAG による AFS トークンの識別

前述のように、キャッシュ・マネージャーは UNIX または PAG のいずれかによって資格認定構造を識別します。 PAG の使用は望ましいことです。それは、PAG は固有であることが許可されているからです。キャッシュ・マネージャーは、それぞれの使用とともに増分するカウンターを基に、 PAG を割り振ります。対照的に、マシン上の複数のユーザーは同じ UNIX UID を共用または想定します。それによって、潜在的なセキュリティー上の問題が発生します。以下に一般的なそのような状態を 2 つ示します。

- ローカル・スーパーユーザー root は、ユーザーのパスワードを提供することなく、su コマンドを発行して、任意のほかのユーザーの UNIX UID をいつでも想定することができます。資格認定構造がユーザーの UNIX UID に関連付けられている場合は、UID を想定するということは、AFS トークンを継承することを意味します。
- 異なる NFS クライアントで作業する 2 人のユーザーには、それぞれのローカル・ファイル・システムに同じ UNIX UID があります。どちらのユーザーも同じ NFS/AFS 変換プログラム・マシンにアクセスし、キャッシュ・マネージャーがそのマシンでこれらのユーザーをその UNIX UID で識別する場合には、どちらのユーザーも区別できなくなります。この問題を除去するには、変換プログラム・マシン上のキャッシュ・マネージャーは、各ユーザーに PAG を自動的に生成し、 UNIX UID ではなく、その PAG を使用し、ユーザーにお互いに時間を隔てるように指示します。

さらに、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 の変更済みログイン・ユーティリティーは、以下と同様のステップの順序を実行します。オペレーティング・システムにより詳細が異なる場合があります。

1. ローカル・パスワード・ファイル (/etc/passwd ファイルまたは同等のファイル) にあるユーザーの項目をチェックする。
2. 項目がない場合、あるいは項目のパスワード・フィールドにアスタリスク (`*`) が表示されている場合は、ログインに失敗する。項目が存在する場合は、ログイン試行は次のステップに進む。
3. ユーティリティーが PAG を獲得する。
4. ユーティリティーがユーザーが提供するパスワードを暗号化鍵に変換し、その鍵でデータ・パケットを暗号化する。ユーティリティーはそのパケットを AFS 認証サービス (標準構成の AFS 認証サーバー) に送信します。
5. 認証サービスはそのパケットの暗号を解除し、暗号化解除に成功したかどうかによって、そのパスワードが正しいか正しくないかを判断する。(詳しくは、相互認証の詳細 を参照してください。)
   - 認証サービスがそのパスワードは不正であると判断した場合は、ユーザーは AFS トークンを受け取りません PAG はそのまま保持され、後で獲得されるトークンにすぐに関連付けられる状態になっています。試行は、 6 のステップに進みます。
   - 認証サービスが、そのパスワードは正しいと判断した場合は、AFS 認証の証明として、ユーザーにトークンを発行する。ログイン・ユーティリティーは、ローカルの UNIX ファイル・システムにユーザーをログインさせます。ログイン・ユーティリティーによっては、以下のバナーを画面に表示し、ユーザーに AFS による認証の注意を促します。6 のステップはスキップされます。

            AFS(R) version Login

6. AFS トークンが 4 のステップで許可された場合には、ログイン・ユーティリティーは、提供されたパスワードをローカル・パスワード・ファイルと比較して、ユーザーをローカル・ファイル・システムにログインさせようとします。
   - パスワードが誤りであるか、暗号化された 13 文字の文字列以外の値がパスワード・フィールドに入っている場合には、ログインの試行は失敗する。
   - パスワードが正しければ、ユーザーはローカル・ファイル・システムだけにログインできる。

説明したように、AFS の変更済みログイン・ユーティリティーを使用する場合は、ローカル・パスワード・ファイルのパスワード・フィールドは、システムにアクセスするための 1 次ゲートではなくなります。ユーザーが正しい AFS パスワードを提供している場合には、プログラムがローカル・パスワード・ファイルを調べることはありません。ただし、以下の方法で、ユーザーはまだパスワード・フィールドを使用して、アクセスを制御することができます。

- ローカル・ログインと AFS 認証の両方を防止するには、フィールドにアスタリスク (*) を入れます。これは、主に、特定のユーザーがマシンにログインするのを阻止したいときなど、緊急の場合に有用です。
- ユーザーが正しい AFS パスワードを提供しない場合にローカル・ファイル・システムへのログインを防止するには、標準の 13 文字以外の任意の長さの文字列をフィールドに入れます。ローカル AFS アカウントを持っている人だけにマシンへのログインを許可したい場合には、これが適しています。これを行うには、単一の X またはほかの文字が最も容易に認識できる方法です。
- 誤った AFS パスワードを提供した後でもユーザーがローカル・ファイル・システムにログインできるようにするには、標準 UNIX パスワード設定コマンド (passwd または同等のコマンド) を発行して、標準の UNIX 暗号化パスワードをフィールドに記録します。

プラグ可能認証モジュール (PAM) を使ってログインおよび AFS 認証を行うシステムでは、ローカル・パスワード・ファイルをまったく調べる必要がない場合もあります。その場合は、認証およびログインの試行を制御するためにパスワード・フィールドを使用することはありません。代わりに、PAM 構成ファイル (多くのシステム・タイプでは、/etc/pam.conf) 内の命令が同じ機能を果たします。 AFS の変更済みログイン・ユーティリティーのインストールに関する指示については、AFS インストールの手引き を参照してください。

### 2 ステップ・ログインおよび認証の使用

AFS で変更されたログイン・ユーティリティーを使用しないセルでは、AFS 使用者の手引き で詳細に説明されているように、次のようにしてユーザーは別々のコマンドを発行して、ログインし、認証を受けなければなりません。

1. ユーザーは標準の login プログラムを使用してローカル・ファイル・システムにログインし、ローカルのパスワード・ファイル (/etc/passwd ファイルまたはそれと等価なファイル) にリストされているパスワードを提供しなければなりません。
2. ユーザーは klog コマンドを発行して、AFS 認証サービスで認証を受けなければなりません。この際、-setpag フラグを指定して、新規のトークンをプロセス認証グループ (PAG) に関連付けなければなりません。

新規の 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 項目。AFS サーバー・プロセスに対応します。デフォルトは 100 時間です。
- krbtgt.cellname 項目。トークンの生成時に内部で使用されるチケット付与チケットに対応します。デフォルトは 720 時間 (30 日) です。
- AFS で変更されたログイン・ユーティリティーのユーザーまたは klog コマンドの発行者の項目。デフォルトは、認証サーバー AFS 3.1 またはそれ以降のバージョンを使用して作成したユーザー項目の場合は 25 時間、認証サーバー AFS 3.0 のバージョンを使用して作成したユーザー項目の場合は 100 時間です。ユーザーは、kas examine コマンドを使用して、ユーザー独自の認証データベース項目を表示することができます。

注: | 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 におけるセキュリティーと認証

AFS はいくつかの機能を組み込んで、認証されたユーザーだけがデータにアクセスすることができるようにすることを保証します。この機能グループでは、それらの機能の中で最も重要な機能について要約し、ユーザーのセルのセキュリティーを改善するメソッドを提案します。

### いくつかの重要なセキュリティー機能

ディレクトリーの ACL

AFS のファイルは、その親ディレクトリーに関連したアクセス制御リスト (ACL) で保護されます。ACL は、何らかの方法で、そのディレクトリーのデータにアクセスできるユーザーまたはグループを定義します。アクセス制御リスト (ACL) の管理を参照してください。

クライアントとサーバー間の相互認証

AFS クライアントとサーバー・プロセスが通信するときには、相互認証中に、お互いの識別を証明し合う必要があります。相互認証には、有効な通話者だけが復号して、応答することができる暗号化された情報の交換を含みます。相互認証プロセスの詳細については、 相互認証の詳細を参照してください。

AFS サーバー・プロセスは、サーバー・プロセス間およびユーザーを示すプロセス間の両方を相互に認証します。相互認証の完了後は、サーバーとクライアントの間には、接続の有効期限が切れるか、通話者の一方が接続をクローズするまで、もう一度認証する必要なく繰り返し通信することができる、認証済みの接続が確立されています。認証済みの接続の存続時間は異なります。

トークン

AFS ファイルにアクセスするには、ユーザーは正しい AFS パスワードを提供して、AFS 認証サービスに自分の識別を証明しなければなりません。パスワードが正しければ、認証サーバーは、認証された状態の証拠として、ユーザーにトークン を送ります。AFS でのログインと認証を参照してください。

サーバーは、有効なトークンを持っていないユーザーとプロセスに、識別として anonymous を割り当てます。 anonymous 識別には、ACL の system:anyuser グループに許可されたアクセス権だけが与えられます。

許可検査

相互認証では、相互に通信している 2 人の通話者が、実際に、承認を求める当人であることを確認します。AFS サーバー・プロセスは、識別を検証されたクライアントが、多くの機能を要求することも許可されているかどうかも検査します。異なる要求には、異なった種類の特権が必要です。3 つのタイプの特権 を参照してください。

暗号化されたネットワーク通信

AFS サーバー・プロセスは、クライアントに情報を返送する前に、特に注意が必要な情報を暗号化します。たとえ、許可されない通話者が認証済みの接続で盗聴することができても、適切な鍵がなければ暗号化されたデータを解読することはできません。

以下の AFS コマンドにはサーバーの暗号化鍵とパスワードが関係するので、これらのコマンドはデータを暗号化します。

- bos addkey コマンド、サーバー暗号化鍵を /usr/afs/etc/KeyFile ファイルに追加する
- bos listkeys コマンド、 /usr/afs/etc/KeyFile ファイルから、サーバー暗号化鍵のリストを作成する
- kpasswd コマンド、認証データベースでパスワードを変更する
- kas コマンド組のほとんどのコマンド

さらに、更新サーバーの米国版は、配布時に、注意が必要な情報 (KeyFile のコンテンツなど) を暗号化します。bos 組の残りのコマンドと、fs、pts および vos 組のコマンドは、データの転送前に、そのデータを暗号化しません。

### 3 つのタイプの特権

AFS は、個別の特権を持つ理由 で説明されている理由から、以下に示した 3 つの異なるタイプの特権を使用します。

- system:administrators グループのメンバーシップ。メンバーに名称を与えて、任意の pts コマンドと、ボリューム割り当て量を設定する fs コマンドを発行します。デフォルトでは、これらのメンバーは、たとえ ACL に a (管理者) および l (検索) アクセス権の項目が含まれていなくても、ファイル・ツリーのすべての ACL にこれらのアクセス権を暗黙で持っています。
- 認証データベース項目の `ADMIN` フラグ。このフラグが付いている管理者は、任意の kas コマンドを発行することができます。
- /usr/afs/etc/UserList ファイルへの組み込み。ユーザー名がこのファイルに表示される管理者は、任意の bos コマンド、vos コマンド、または backup コマンドを発行することができます (ただし、 バックアップ操作への管理特権の許可 で説明しているように、backup コマンドには、追加の特権が必要なものがあります)。

### 認証に対する

AFS は、認証と許可検査を区別します。認証 とは、識別を証明するプロセスを指します。 認証検査 は、認証された識別が特定のアクションの実行を許可されているかどうかを検証するプロセスを指します。

AFS は接続のレベルで認証をインプリメントします。2 人の対話者は、新規接続を確立するたびに、相互に認証します。一般的に、AFS コマンドの発行のたびに、 AFS サーバー・プロセスとクライアントの間に新規の接続を確立します。

AFS は、サーバー・マシンのレベルで許可検査をインプリメントします。認証検査がサーバー・マシン上で使用可能になっていれば、そのマシン上で実行されているサーバー・プロセスはすべて許可されたユーザーのみにサービスを提供します。認証検査がサーバー・マシン上で使用不可になっていれば、サーバー・プロセスはすべてどのユーザーに対しても任意のアクションを実行します。認証検査を使用不可にすると、明らかにセキュリティーが重大な危険にさらされます。詳細については、認証と許可の要件の管理 を参照してください。

### セル内のセキュリティー改善

ユーザー・アカウント、サーバー・マシン、およびシステム管理者のアカウントを指示された方法で構成することによって、セル内でのセキュリティーのレベルを向上させることができます。

ユーザー・アカウント

- AFS の変更済みログイン・ユーティリティーを使用するか、 klog コマンドに -setpag フラグを組み込んで、資格認定構造を UNIX UID ではなく、PAG に関連付けます。これによって、ユーザーが UNIX 識別を想定して、ほかのだれかのトークンを継承することを防ぐことができます。詳しくは、 PAG による AFS トークンの識別 を参照してください。
- ユーザーが unlog コマンドを発行し、ログアウトする前にトークンを破棄することをお勧めします。そうすることによって、カーネル・メモリーに残されたトークンへのアクセスを未然に防止できます。 unlog コマンドをユーザーの .logout ファイルまたは同等のファイルに組み込むことを考慮してください。

サーバー・マシン

- 認証検査を使用不可にするのは、緊急時あるいはほんのわずかの時間の間だけにしてください。最もよいのは、この間は、影響を受けたマシンのコンソールで作業して、ほかのだれかがキーボードを介してそのマシンにアクセスするのを防ぐことです。
- AFS サーバー暗号化鍵を頻繁にかつ規則的はスケジュールで変更します。推測を困難にします (たとえば、アルファベット以外の文字を組み込んだ長い文字列)。ユーザー・パスワードと異なり、 AFS 鍵が派生されるパスワードは、8 文字より長くできます。このパスワードはログイン時には使用されないからです。kas setpassword コマンドは、数百文字の長さのパスワードを受け入れます。指示については、サーバー暗号化鍵の管理 を参照してください。
- サーバー・マシンのコンソールでログインまたはリモートでログインできる人の数をできるだけ制限する。この制限を課することは、必要というより、特別なセキュリティー上の予防処置です。この場合、マシンは AFS クライアントの役割を果たすことはできません。
- 特に、サーバー・マシン上のローカルのスーパーユーザー root のアカウントへのアクセスを制御する。ローカルのスーパーユーザー root は、ローカル・ディスク上の AFS ファイル で説明しているように、/usr/afs ディレクトリーの重要な管理サブディレクトリーに自由にアクセスできます。
- すべての計算環境の場合と同様、サーバー・マシンは保護された領域に設置しなければなりません。許可されない人々がコンピューター・ハードウェアにアクセスできる場合、任意のほかのセキュリティー基準は、実際上役に立ちません。

システム管理者

- ユーザーのセルのシステム管理者の数を制限します。公にアクセス可能なワークステーションでは、システム管理者アカウントの使用を制限します。このようなマシンは安全ではありません。したがって、悪意を持ったユーザーがトークンまたはパスワードを盗もうとするプログラムをインストールすることが可能です。管理者が公にアクセス可能なワークステーションを使用しなければならないときがある場合は、unlog コマンドを発行してからマシンを離れなければなりません。
- 管理者ごとに、個人アカウントとは別個の管理アカウントを作成し、管理アカウントだけに AFS 特権を割り当てます。管理者は、特権を必要とする任務を実行するために、管理アカウントに対して認証を行わなければなりません。これは有用な監査証跡にもなります。
- 管理者が有効なトークンを持っている間は、マシンを無人のまま放置してはいけません。マシンを離れる前に unlog コマンドを発行してください。
- kas setfields コマンドで -lifetime 引き数を使用し、管理用アカウントのチケット (トークン) 存続時間を、かなり短い時間に設定します。AFS トークンのデフォルトの存続時間は 25 時間ですが、管理トークンの場合は、30 分または 60 分がおそらく妥当でしょう。AFS バックアップ・システム・オペレーションを開始する管理者のトークンは、存続期間が多少長くなければなりません。それは、磁気テープ装置と、アクセスしているボリュームを収容するファイル・サーバー・マシンにその装置を接続しているネットワークの速さによって、ダンプ・オペレーションの完了まで数時間かかることがあるからです。
- 管理者が telnet プログラムを使用するのを制限します。このプログラムは、ネットワークを介して暗号化されていないパスワードを送信します。同様に、ネットワークを介して暗号化されていないトークンを送信する rsh や rcp のようなその他のリモート・プログラムの使用を制限します。

### 相互認証の詳細

任意のファイル・システムのように、セキュリティーは AFS の基本用務です。ファイル共用を容易にするファイル・システムは、ファイル共用を強制した場合は有用ではありません。そのため AFS には、許可されないユーザーがデータにアクセスできないようにするいくつかの機能を組み込まれています。ネットワーク化された環境のセキュリティーは、困難です。それは、ほとんどすべての手順で、だれでもつなぐことができるワイヤーを介して、情報を伝送する必要があるからです。また、ネットワーク上の多くのマシンは十分に強力で、悪意を持ったユーザーがトランザクションをモニターしたり、転送を代行受信することすら可能です。さらに、関係者の 1人の識別を模造することもできます。

盗聴および情報の窃取あるいはなりすましに対する最も効果的な予防措置は、サーバーとクライアントが、もう一方の対話者が本物であると主張している識別を十分に証明してから受け入れることです。言い換えれば、ネットワークの性質上、ネットワーク上のすべての対話者は、トランザクション内の他の対話者は、証明されるまで本物ではないと想定することを強制されます。 相互認証 は、対話者がそれぞれ自分が本物であることを証明するための手段です。

模造を防ぐために必要な基準は、非常に精巧でなければならないため、相互認証手順のインプリメンテーションは複雑です。ただし、基本概念は単純です。対話者は、共用シークレット に関する知識を明示して自分たちの識別を証明します。共用シークレットは、相互に認証している対話者しか知らない情報の一部です (対話者は、信頼される第三者または何らかのほかのソースの最初の場所でその情報を確認する場合があります)。トランザクションの発信元の対話者は共用シークレットを提供し、相手の対話者がそのシークレットを知っていることを示すまで、その対話者が有効な対話者であるとして受け入れることを拒否します。

AFS トランザクションにおける共用シークレットの最も一般的な形式は、 暗号化鍵 であり、簡単に鍵 とも呼びます。 2 人の対話者は、自分たちの共用鍵を使用して、送信する情報のパケットを暗号化し、受信したパケットの暗号を復号します。鍵を使用する暗号化は実際には 2 つの関連する目的にかなうものです。第一に、鍵を使った暗号化は、その鍵を知らないだれかが盗聴するのを防ぎ、ネットワークを上のメッセージを保護します。第二に、メッセージを正常に暗号化し復号できるということは、対話者がその鍵を使用していることを示しています (その鍵が共用シークレットなのです)。対話者が異なる鍵を使用している場合は、暗号化解除の後でもメッセージはスクランブルされて判読できない状態のままです。

以下のセクションでは、AFS の相互参照の手続きについてさらに詳しく説明します。相互認証プロセスに関心がない場合は、この機能グループを自由にスキップしてかまいません。

#### 簡単な相互認証

簡単な相互認証には、1 つだけの暗号化鍵と 2 人の対話者、一般的にはクライアントとサーバーが含まれます。クライアントは、2 人の対話者しか知らない鍵を使って暗号化した申し込み メッセージ送信して、サーバーと交信します。サーバーは、同じシークレットを共用していれば、クライアントの鍵と同じ自分の鍵を使用して、そのメッセージを復号します。サーバーはその申し込みに応答し、自分の鍵を使用してその応答を暗号化します。クライアントは自分の鍵を使用してサーバーの応答を復号します。その鍵が正しければ、クライアントは、そのサーバーが本物であると確信することができます。申し込みを復号し、それに正しく答えることができるのは、クライアントと同じ鍵を知っている人だけです。サーバー側では、そのクライアントは本物であると結論を下します。それは、サーバーがその申し込みのメッセージを復号したときに、そのメッセージが意味をなしたからです。

AFS は簡単な相互認証を使用して、ログイン手続きの最初の部分でユーザーを検証します。このような場合には、鍵はユーザーのパスワードを基にしています。

#### 複雑な相互認証

複雑な相互認証には、3 つの暗号化鍵と 3 人の対話者が含まれます。すべてのセキュア AFS トランザクション (ログイン・プロセスの最初の部分を除く) では、複雑な相互認証を使用します。

クライアントがサーバーと通信することを希望するときには、まず、チケット授与者 と呼ばれる三人目の通話者と交信します。チケット授与者とクライアントは、簡単な手順を使用して相互に認証します。相互認証が終了すると、チケット授与者は、クライアントの識別を事前に検証した証明として、クライアントに サーバー・チケット (または単に チケット) を与えます。チケット付与者は、3 つの鍵のうち、サーバー暗号化鍵 と呼ばれる最初の鍵を使って、そのチケットを暗号化します。それは、チケット授与者と、クライアントが交信したいサーバーしかその鍵を知らないからです。クライアントはこの鍵を知りません。

チケット付与者は、情報の他の一部を、そのチケットと一緒に送信します。その情報を使用してクライアントは、チケットそれ自体を復号することができないにもかかわらず、チケットを実際に使用することができます。このチケットだけでなく、項目もトークン を構成します。

- セッション鍵、相互認証に含まれる 2 番目の暗号化鍵です。チケット授与者は、クライアントとサーバー間の共用シークレットとして、セッション鍵をランダムに創作します。以下で詳しく説明する理由から、チケット授与者は、チケットの内部にもセッション鍵のコピーを書き込みます。クライアントとサーバーはセッション鍵を使用して、トランザクション中にお互いに送信するメッセージを暗号化します。チケット授与者は、クライアントとサーバー間のそれぞれの接続のために、別のセッション鍵を創作します (1 つの接続中に複数のトランザクションがある場合もあります)。
- チケットが有効になっているサーバーの名前 (したがって、サーバー暗号化鍵によってチケットそれ自体が暗号化されるサーバーの名前)。
- チケットの存続時間のインディケーター。AFS サーバー・チケットのデフォルトの存続時間は、100 時間です。クライアントが、チケットの有効期限が切れた後に、もう一度サーバーと交信したい場合には、チケット授与者と交信して、新規のチケットを入手しなければなりません。

チケット授与者は、複雑な相互認証に含まれる 3 番目の鍵ですべてのトークンを封印します。この鍵については、チケット授与者とクライアントしか知りません。この 3 番目の鍵は、クライアントが表す人間のユーザーのパスワードから派生される場合があります。

クライアントが有効なチケットを入手したので、サーバーと更新する準備ができました。クライアントはサーバーに 2 つのものを送信します。

- サーバー・チケット。このチケットはサーバーの暗号化鍵によって暗号化されます。
- クライアントの要求メッセージ、セッション鍵で暗号化されています。メッセージを暗号化することによって、ネットワークをわたるメッセージを保護します。それは、そのためにチケット授与者がセッション鍵を作成したサーバー / クライアントの組しか、そのセッション鍵を知らないからです。

この時点では、チケット授与者がセッション鍵を作成したばかりであるため、サーバーはその鍵については知りません。ただし、チケット授与者は、チケット内にセッション鍵のコピーを書き込みました。サーバーは、サーバー暗号化鍵を使用してチケットを復号し、セッション鍵を知ります。次に、サーバーはセッション鍵を使用して、クライアントの要求メッセージを復号します。応答を生成し、それをクライアントに送信します。サーバーはその応答をセッション鍵で暗号化し、ネットワークを渡るメッセージを保護します。

このステップは、クライアントとサーバー間の相互認証の核心です。それは、このステップによって、両方の通話者が同じシークレットを知っていることを証明するからです。

- サーバーがセッション鍵を使って要求メッセージを復号したときに、そのメッセージが意味をなすため、サーバーは、そのクライアントが要求することを許可されていると結論を下します。クライアントが、サーバーがチケット内で検出する鍵とは異なる鍵を使用している場合は、その要求メッセージは、復号後も判読できない状態のままです。セッション鍵の 2 つのコピー (1 つはチケット内に、もう 1 つはクライアントが使用) は、その両方がそのチケット授与者から出されたものであれば、同じはずです。クライアントはセッション鍵の情報を模造することはできません。それは、サーバーとチケット授与者しか知らないサーバー暗号化鍵でチケットが封印されているため、クライアントはチケットの内部を見ることができないからです。サーバーはチケット授与者を信頼し、そのチケット授与者が認証したクライアントだけにトークンを与えます。したがって、サーバーは、そのクライアントは本物であると決定します。

  (たとえ、チケット授与者とサーバーの関連が、チケット・ベースの相互認証の中心であっても、これらの間には直接の通信が内ことに注意してください。チケット授与者とサーバーは、自分たちの共用シークレットで封印したチケットをクライアントが所有することを介して、間接的に対話するだけです。)

- クライアントは、そのサーバーが本物であるという結論を下し、サーバーから戻された応答を信用します。それは、クライアントがセッション鍵を使用して複号後、その応答は意味をなすからです。これは、そのサーバーが、クライアントが知っているセッション鍵と同じ鍵で応答を暗号化したことを示しています。サーバーがセッション鍵が一致していることを確認する唯一の方法は、まずチケットを複号することです。サーバーだけがそのチケットを複号することができます。それは、サーバーが、サーバー・暗号化鍵のシークレットをチケット授与者と共用するからです。クライアントはそのチケット授与者を信用し、本物のサーバーにだけチケットを配布します。したがって、クライアントはそのチケットを復号できるサーバーを本物として受け入れ、その応答を受け入れます。

## AFS データのバックアップ

AFS は、管理者が AFS データをバックアップするのに役に立つ、バックアップ・ボリュームと AFS バックアップ・システムという 2 つの関連機能を提供します。

### バックアップ・ボリューム

最初の機能はバックアップ・ボリュームです。これは、管理者が読み取り / 書き込みボリュームを複製することによって作成します。バックアップ・ボリュームは読み取り専用であるため、複製の作成時の読み取り / 書き込みボリュームの状態を保持します。

バックアップ・ボリュームをファイル・システムに取り付け、そのコンテンツをユーザーが使用できるようにすれば、バックアップ・ボリュームによって、管理がしやすくなります。たとえば、各ユーザー・ボリュームのバックアップ・バージョンをユーザーのホーム・ディレクトリーのサブディレクトリーとして取り付けることが意味のあることである場合がよくあります。このマウント・ポイントの通例の名前は、OldFiles です。一日に一度はバックアップ・ボリュームの新規バージョンを作成し (すなわち、読み取り / 書き込みを再複製し)、前回のバックアップ以降に加えられた変更をすべて取り込みます。ユーザーが誤ってデータを削除または変更した場合でも、ユーザーは、管理者にそのデータの復元を依頼しなくても、自分でバックアップ・ボリュームからそのデータを復元することができます。

AFS 使用者の手引き ではバックアップ・ボリュームについては何も説明していません。そのため、管理者がバックアップ・ボリュームを使用しないと決めてしまえば、通常のユーザーはバックアップ・ボリュームのことは何も知りません。これは、管理者がユーザー・ボリュームのバックアップ・バージョンを作成する場合には、バックアップの作業方法およびそれの取り付け場所をユーザーに知らさなければなりません。

ユーザーは、バックアップ・ボリューム内のデータによってボリュームの割り当て量が減ると考えることがよくあり、OldFiles マウント・ポイントを除去することを望むユーザーさえ存在します。しかしそのようなことはありません。それは、バックアップ・ボリュームは 別のボリュームだからです。バックアップ・ボリュームがユーザーのボリュームで使用する唯一のスペースの量は、マウント・ポイントに必要な量です。その量は、標準ディレクトリー要素に必要な量と同じくらいです。

バックアップ・ボリュームについては、バックアップ・ボリュームの作成 で詳しく説明しています。

### AFS バックアップ・システム

バックアップ・ボリュームによって復元要求が削減されますが、バックアップ・ボリュームはディスク上に常駐するため、ハードウェアの故障のために、データが失われるのを防ぎません。任意のファイル・システムのように、 AFS はこの種のデータの損失に対しては無防備です。

データを永久に失うことからユーザーのセルのユーザーを保護するには、ユーザーのファイル・システムを定期的にかつ頻繁に、磁気テープにバックアップすることを強くお勧めします。 AFS バックアップ・システムは、管理とバックアップのパフォーマンス容易にするために使用できます。 AFS バックアップ・システムに関する詳細については、 AFS バックアップ・システムの構成 および AFS データのバックアップと復元 を参照してください。

## AFS 環境における UNIX リモート・サービスの使用

AFS 配布には、リモート・サービスを提供するいくつかの標準 UNIX コマンド、デーモン、およびプログラムの変更済みバージョンが組み込まれています。

- ftpd プログラム
- inetd デーモン
- rcp プログラム
- rlogind デーモン
- rsh コマンド

これらの変更によって、コマンドが AFS 認証情報 (トークン) を処理できるようになります。これによって、発行者は、認証された AFS ユーザーとしてリモート・マシン上で認識されます。

ユーザーのファイル・ツリーにあるこれらのプログラムの標準バージョンを、 AFS を変更したバージョンと置き換えることは、任意選択です。AFS の透過的なアクセスによって、一部のプログラム、特に、ftpd や rcp プログラムのような、マシンからマシンへのファイル転送に関係するプログラムの必要性が少なくなります。

これらのコマンドの AFS バージョンを使用することを決めたら、このコマンドには互に依存する物があることに注意してください。たとえば、 AFS 認証情報の受け渡しが rcp コマンドで正常に動作するのは、 rcp コマンドおよび inetd コマンドの両方とも AFS バージョンを使用している場合だけです。

変更済みのリモート・コマンドのインストール場所は、標準では /usr/afsws/bin および /usr/afsws/etc ディレクトリーです。コマンドの機能の詳細については、AFS Administration Reference の各コマンドの解説ページを参照してください。

## NFS を介した AFS へのアクセス

NFS クライアント・マシンのユーザーは、NFS/AFS 変換プログラム を実行している AFS クライアント・マシンの /afs ディレクトリーを取り付けることによって、AFS ファイル・スペースにアクセスすることができます。これは、AFS を使用できないクライアント・マシンを使用して AFS にアクセスしたい NFS をすでに実行しているセルでは、特に有利になります。付録 A, NFS/AFS 変換プログラムの管理を参照してください。

[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]

(C) IBM Corporation 2000. All Rights Reserved