# 管理の手引き

# サーバー・マシンの管理

この章では、AFS サーバー・マシンの管理方法について説明します。この章では、以下の構成情報と管理用タスクについて説明します。

- あらゆるサーバー・マシンのローカル・ディスクにある /usr/afs ディレクトリーのサブディレクトリーに常駐しなければならないバイナリー・ファイルと構成ファイル。 サーバー・マシン上のローカル・ディスク・ファイル を参照してください。
- AFS サーバー・マシンで実行できるさまざまな役割 または機能、およびある役割を果しているマシンがどれであるかを判別する方法。 ファイル・サーバー・マシンの 4 つの役割 を参照してください。
- データベース・サーバー・マシンの保守の方法。データベース・サーバー・マシンの管理 を参照してください。
- /usr/afs/etc/CellServDB ファイルのデータベース・サーバー・マシンのリストを保守する方法。 サーバー CellServDB ファイルの保守 を参照してください。
- サーバー・マシンで許可検査を制御する方法。 認証と許可の要件の管理 を参照してください。
- ファイル・サーバー・マシンで新規のディスクまたは区分をインストールする方法。 ディスクと区分の追加または除去 を参照してください。
- サーバー・マシンの IP アドレスおよび管理 VLDB サーバー項目の変更方法は、 サーバー IP アドレスおよび VLDB サーバー項目の管理 を参照してください。
- ファイル・サーバー・マシンをリブートする方法。 サーバー・マシンのリブート を参照してください。

新規サーバー・マシンのインストールと構成の方法を確認するには、 AFS インストールの手引き を参照してください。

サーバー・プロセスそのものを管理する方法を確認するには、 サーバー・プロセスの監視および制御 を参照してください。

ボリュームの管理方法を確認するには、 ボリュームの管理 を参照してください。

## 説明の要約

本章では、指示されたコマンドを使用した以下のタスクの実行方法を説明します。

新規バイナリーのインストール | bos install
チェックと再始動時のバイナリーの検査 | bos getrestart
バイナリーの検査と再始動の時刻の設定 | bos setrestart
バイナリー・ファイルのコンパイル日付の検査 | bos getdate
新規バイナリーを使用するプロセスの再始動 | bos restart
バイナリーの古いバージョンへの復帰 | bos uninstall
古くなった .BAK および .OLD バージョンの除去 | bos prune
ファイル・サーバー・マシンの区分のリスト作成 | vos listpart
AFS サーバー・プロセスの終了 | bos shutdown
区分のボリュームのリスト作成 | vos listvldb
読み取り / 書き込みボリュームの移動 | vos move
セルのデータベース・サーバー・マシンのリスト作成 | bos listhosts
CellServDB ファイルへのデータベース・サーバー・マシンの追加 | bos addhost
サーバー CellServDB ファイルからのデータベース・サーバー・マシンの除去 | bos removehost
許可検査の要件の設定 | bos setauth
bos コマンド、pts コマンド、および vos コマンドの認証の回避 | -noauth フラグを組み込む
kas コマンドの認証の回避 | いくつかのコマンドに -noauth フラグを組み込むか、対話モードで noauthentication を発行する
すべての VLDB サーバー項目の表示 | vos listaddrs
VLDB サーバー項目の削除 | vos changeaddr
サーバー・マシンをリモートでリブート | bos exec reboot_command

## サーバー・マシン上のローカル・ディスク・ファイル

いくつかのタイプのファイルは、 AFS サーバー・マシンのローカル・ディスクにある /usr/afs ディレクトリーのサブディレクトリーに常駐しなければなりません。これらのファイルには、バイナリー・ファイル、構成ファイル、管理用データベース・ファイル (データベース・サーバー・マシン上の)、ログ・ファイル、およびボリューム・ヘッダー・ファイルが含まれます。

Windows ユーザー向けの注: この文書で説明されているファイルには、 Windows オペレーティング・システムの稼働するマシン上にはないものがあります。また Windows では、パス名を区切るのに ( / ) の代わりに円記号 ( \ ) を使用します。

### /usr/afs/bin ディレクトリーにあるバイナリー

/usr/afs/bin ディレクトリーには、マシンのシステム (CPU またはオペレーティング・システム) タイプに適した AFS サーバー・プロセスとコマンドの組のバイナリーが保管されます。プロセスにサーバー部分とクライアント部分がある場合 (更新サーバーを使った場合)、あるいは、別のコンポーネントがある場合 (fs プロセスを使った場合) には、それぞれのコンポーネントは別々のファイルに常駐します。

予測可能なシステム・パフォーマンスを保証するには、すべてのファイル・サーバー・マシンは、所定のプロセスの同じ AFS 作成バージョンを実行しなければなりません。整合性を簡単に保守するには、更新サーバー・プロセスを使用して、それぞれのシステム・タイプのバイナリー配布マシン から、バイナリーを配布します。詳しくは、バイナリー配布マシン を参照してください。

たとえ、そのプロセスをマシン上で実際に実行しなくても、すべてのプロセスのバイナリーを /usr/afs/bin ディレクトリーに保持するとよいでしょう。バイナリーは、マシンの構成のプロセス (たとえば、データベース・サーバー機能を既存のファイル・サーバー・マシンに追加すること) を単純化します。同様に、たとえサーバー・マシンでの作業中に頻繁にコマンドを発行しなくても、ディレクトリーにコマンドの組のバイナリーを保持するのもよいことです。コマンドの組のバイナリーを使用すると、ユーザーは、サーバーとマシンの停止から回復中にコマンドを発行することができます。

以下は、AFS サーバー・プロセスまたはコマンドの組に直接関連する /usr/afs/bin ディレクトリーにあるバイナリー・ファイルのリストです。ほかのバイナリー (たとえば、klog コマンド用) は、特定のファイル・サーバー・マシンのディスクまたは AFS 配布にあるこのディレクトリーに表示されます。

backup
  AFS バックアップ・システム用のコマンドの組 (バックアップ・サーバー用のバイナリーは、buserver です)。

bos
  基本制御 (BOS) サーバーと通信するためのコマンドの組 (BOS サーバー用のバイナリーは bosserver)

bosserver
  基本制御 (BOS) サーバー・プロセス用のバイナリー

buserver
  バックアップ・サーバー・プロセス用のバイナリー

fileserver
  fs プロセスのファイル・サーバー・コンポーネント用のバイナリー

kas
  認証サーバーと通信するためのコマンドの組 (認証サーバー用のバイナリーは kaserver)

kaserver
  認証サーバー・プロセス用のバイナリー。

ntpd
  ネットワーク・タイム・プロトコル・デーモン (NTPD) 用のバイナリー。 AFS はこのバイナリーを再配布し、 runntp プログラムを使用して、NTPD プロセスを構成し初期化します。

ntpdc
  ntpd プログラムに備え付けられたデバッグ・ユーティリティー

pts
  保護サーバー・プロセスと通信するためのコマンドの組 (保護サーバー用のバイナリーは ptserver)

ptserver
  保護サーバー・プロセス用のバイナリー

runntp
  AFS で使用するのに最も適した NTPD を構成するために使用するプログラム用のバイナリー

salvager
  fs プロセスのサルベージャー・コンポーネント用のバイナリー

udebug
  AFS の分散データベース・テクノロジー、Ubik の状態を報告するプログラム用のバイナリー

upclient
  更新サーバー・プロセスのクライアント部分用のバイナリー

upserver
  更新サーバー・プロセスのサーバー部分用のバイナリー

vlserver
  ボリューム・ロケーション (VL) サーバー・プロセス用のバイナリー

volserver
  fs プロセスのボリューム・サーバー・コンポーネント用のバイナリー

vos
  ボリューム・サーバー・プロセスおよび VL サーバー・プロセスと通信するためのコマンドの組 (これらのサーバー用のバイナリーは、それぞれ volserver と vlserver)

### /usr/afs/etc ディレクトリーにある共通構成ファイル

あらゆるファイル・サーバー・マシンのローカル・ディスクにあるディレクトリー /usr/afs/etc には、 ASCII とマシンから独立したバイナリー形式の構成ファイルが含まれます。セル全体の予測可能な AFS パフォーマンスのためには、すべてのサーバー・マシンのバージョンは、それぞれの構成ファイルと同じでなければなりません。

- しきたり通りに AFS の米国版を実行するセルでは、更新サーバーを使用し、それぞれのファイルの共通バージョンを、セルのシステム制御マシンからほかのサーバー・マシンに配布します (システム制御マシンに関する詳細については、システム制御マシン を参照してください)。システム制御マシンで更新サーバーのサーバー部分を実行し、ほかのすべてのサーバー・マシンでクライアント部分を実行します。緊急事態に対処するための指示によって送信される場合を除いて、システム制御マシンだけでファイルを更新します。
- AFS の国際版を実行するセルでは、更新サーバーを使用して、 /usr/afs/etc ディレクトリーのコンテンツを配布しなければなりません。米国政府の規定により、このディレクトリーのファイルがネットワークを渡るときに、これらのファイルを保護するために AFS で使用するデータ暗号化ルーチンは、 AFS の国際版の更新サーバーに使用することができません。代わりに、それぞれのサーバー・マシンで個別にそのファイルを更新し、それぞれのマシンに対して同じ bos コマンドを正確に発行しなければなりません。必要なデータ暗号化ルーチンは、bos コマンドに使用可能です。したがって、bos コマンドが発行されるマシンから、サーバー・マシンへとネットワークを渡る情報は安全です。

緊急事態に対処するための指示によって送信される場合を除いて、 /usr/afs/etc ディレクトリーにあるどのようなファイルも直接編集してはいけません。通常の環境では、適切な bos コマンドを使用してファイルを変更します。以下のリストには、指示を指すポインターが組み込まれます。

このディレクトリーのファイルには、以下が組み込まれます。

CellServDB
  セルのデータベース・サーバー・マシンを命名する ASCII ファイルで、認証、バックアップ、保護、および VL サーバー・プロセスを実行します。ユーザーのセルの最初のサーバー・マシンをインストール中に、 bos setcellname コマンドを発行して、このファイルの初期バージョンを作成します。ユーザーのセルのデータベース・サーバー・マシンの識別を変更するときには、このファイルの更新は非常に重要です。

  サーバー CellServDB ファイルは、クライアント・マシンの /usr/vice/etc ディレクトリーに保管される CellServDB ファイルとは異なります。クライアント・バージョンは、ユーザーがクライアント・マシンからアクセスできるように選択した、あらゆる AFS セルのデータベース・サーバー・マシンのリストを作成します。サーバー CellServDB ファイルは、ローカル・セルだけのデータベース・サーバーのリストを作成します。それは、サーバー・プロセスがほかのセルのプロセスと更新することはないからです。

  このファイルの保守については、サーバー CellServDB ファイルの保守 を参照してください。

KeyFile
  マシンから独立したバイナリー形式のファイルで、 AFS サーバー・プロセスがチケットを暗号化したり複号するために使用する、サーバー暗号化鍵のリストを作成します。このファイルにある情報は、セルにおける安全な通信の基礎となるため、極めて重要です。このファイルは特別に保護され、特権ユーザーだけが読み取ったり変更することができます。

  このファイルの保守については、サーバー暗号化鍵の管理 を参照してください。

ThisCell
  セルの完全なインターネット・ドメイン形式の名前 (`abc.com` など) を定義する単一行で構成される ASCII ファイル。AFS インストールの手引き で説明しているように、セルの最初のファイル・サーバー・マシンのインストール時に、 bos setcellname コマンドを使用してこのファイルを作成します。

  このファイルを変更することは、セルの名前を変更する 1 つのステップにしかすぎません。説明は、セル名の選択 を参照してください。

UserList
  特権付き bos コマンド、vos コマンド、および backup コマンドを発行することを許可されたシステム管理者のリストを作成する ASCII ファイル。このファイルの保守については、UserList ファイルの管理 を参照してください。

### /usr/afs/local ディレクトリーのローカル構成ファイル

ディレクトリー /usr/afs/localには、セルにあるそれぞれのファイル・サーバー・マシンごとに異なる構成ファイルが含まれます。したがって、それらの構成ファイルは、/usr/afs/bin および /usr/afs/etc ディレクトリーにあるファイルのように、中央ソースから自動的に更新されることはありません。最も重要なファイルは、BosConfig ファイルです。このファイルはそのマシンで実行するサーバー・プロセスを定義します。

/usr/afs/etc にある共通構成ファイルと同じように、これらのファイルを直接編集してはいけません。適切な場合は、 bos コマンドの組のコマンドを使用します。更新する必要がないファイルもあります。

このディレクトリーに含まれるファイルは、以下のとおりです。

BosConfig
  このファイルには、サーバー・マシンで実行されるプロセスがリストされています。 BOS サーバーがモニターするプロセスと、プロセスが失敗したときに行うことを定義しています。また、BOS サーバーが保守の目的でプロセスを自動的に再始動する回数も定義します。

  ファイル・サーバー・マシンのインストール中に、サーバー・プロセスを作成するときに、それらのプロセスの項目は、このファイル内で自動的に定義されます。AFS インストールの手引き では、使用する bos コマンドについて、簡単に説明します。ファイルの詳細な説明と、 bos の組のコマンドでファイルを編集してプロセスの状況を制御するための指示については、 サーバー・プロセスの監視および制御 を参照してください。

NetInfo
  このオプションの ASCII ファイルは、サーバー・マシン上にある 1 つまたは複数のネットワーク・インターフェース・アドレスをリスト表示します。このファイルがファイル・サーバーの初期設定時に存在する場合は、ファイル・サーバーは、そのボリューム・ロケーション・データベース (VLDB) サーバー項目に登録するインターフェースのリストの基本としてこれを使用します。 サーバー IP アドレスおよび VLDB サーバー項目の管理を参照してください

NetRestrict
  このオプションの ASCII ファイルは、1 つまたは複数のネットワーク・インターフェース・アドレスをリスト表示します。このファイルがファイル・サーバーの初期設定時に存在する場合は、ファイル・サーバーは、その VLDB サーバー項目に登録するインターフェースのリストから指定アドレスを削除します。 サーバー IP アドレスおよび VLDB サーバー項目の管理を参照してください

NoAuth
  この長さ 0 のファイルは、マシンで実行されるすべての AFS サーバー・プロセスに、許可検査を実行しないように指示するからです。したがって、これらのサーバー・プロセスは、 anonymous にもかかわらず、どのユーザーのどのようなアクションでも実行します。この非常に危険な状態が役に立つ場合はまれで、主にマシンのインストール中だけです。

  このファイルは、 -noauth フラグをもつ初期 bosserver プロセスを開始するか、あるいは、bos setauth コマンドを発行して認証要件をオフにするときに、自動的に作成されます。bos setauth コマンドを使用して認証をオンにすると、 BOS サーバーはこのファイルを除去します。詳細については、認証と許可の要件の管理 を参照してください。

SALVAGE.fs
  この長さ 0 のファイルの存在によって、fs プロセスのファイル・サーバー・コンポーネントの破損を BOS サーバーがどのように処置するかを制御します。 BOS サーバーは、fs プロセスを開始または再始動するたびに、このファイルを作成します。ファイル・サーバーが破損したときにこのファイルが存在する場合には、 BOS サーバーは、ファイル・サーバーとボリューム・サーバーをもう一度再始動する前に、サルベージャーを実行します。ファイル・サーバーが正常に終了するときには、 BOS サーバーはそのファイルを除去して、サルベージャーが実行されないようにします。

  このファイルをユーザー自身が作成したり、または除去してはいけません。 BOS サーバーが自動的に行います。必要な場合は、bos salvage コマンドを使って、ボリュームまたはパーティションを回収することができます。ボリュームのサルベージ を参照してください。

salvage.lock
  このファイルによって、1 つのファイル・サーバー・マシンで一度に 1 つのサルベージャーしか実行されないことを保証します (単一のプロセスが、複数のサブプロセスを fork して、複数のパーティションを並列してサルベージできます)。サルベージャーの開始時 (BOS サーバー、または bos salvage コマンドの発行によって呼び出されると)、この長さ 0 のファイルを作成し、それに対して flock システム・コールを発行します。サルベージ・オペレーションが完了すると、このファイルは削除されます。サルベージャーが実行するためには、このファイルをロックする必要があるので、一度に 1 つのサルベージャーしか実行することができません。

sysid
  このファイルは、ファイル・サーバー (fileserver プロセス) がその VLDB サーバー項目に登録するネットワーク・インターフェース・アドレスを記録します。キャッシュ・マネージャーがボリューム・ロケーション情報を要求すると、ボリューム・ロケーション (VL) サーバーは、ボリュームを含む各サーバー・マシンに対して登録されているインターフェースをすべて戻します。これにより、キャッシュ・マネージャーがマルチホーム・ファイル・サーバー・マシンに保管された AFS データにアクセスする際、複数アドレスを使用することができます。詳細については、サーバー IP アドレスおよび VLDB サーバー項目の管理 を参照してください。

### /usr/afs/db ディレクトリーにある複写済みのデータベース・ファイル

ディレクトリー /usr/afs/db には、認証データベース、バックアップ・データベース、保護データベース、およびボリューム・ロケーション・データベース (VLDB) という、セル内の 4 つの複写されたデータベースに関連した以下の 2 つのタイプのファイルが含まれています。

- .DB0 拡張子が付いた、それぞれのデータベースを含むファイル。
- .DBSYS1 拡張子が付いた、それぞれのデータベースごとのファイル。データベース・サーバー・プロセスは、このファイルでそれぞれのデータベース・オペレーションをログに記録してから実行します。そのオペレーションが妨害されると、そのプロセスはこのファイルに相談してその終了方法を確認します。

それぞれのデータベース・プロセス (認証、バックアップ、保護、または VL サーバー) が、そのプロセス専用のデータベース・ファイルとログ・ファイルを保持しています。データベース・ファイルはバイナリー形式です。したがって、データベース・ファイルにアクセスする場合またはデータベース・ファイルを更新する場合は、いつでも、 kas の組 (認証データベースの場合)、 backup の組 (バックアップ・データベースの場合)、 pts の組 (保護データベースの場合)、または vos の組 (VLDB の場合) を使用しなければなりません。

セルで 複数のデータベース・サーバー・マシンを実行する場合には、それぞれのデータベース・サーバー・プロセスは、そのデータベースの独自のコピーを、マシンのハード・ディスクに保持します。ただし、所定のデータベースのすべてのコピーが同じであることが重要です。それらのコピーを同期するためには、 AFS 管理データベースの複写 で説明したように、データベース・サーバー・プロセスには、 AFS の分散データベース・テクノロジー、Ubik が必要です。

ここにリストされているファイルは、データベース・サーバー・マシンでだけこのディレクトリーに表示されます。データベース・サーバー・マシン以外のマシンのディレクトリーは、空です。

bdb.DB0
  バックアップ・データベース・ファイル

bdb.DBSYS1
  バックアップ・データベース・ログ・ファイル

kaserver.DB0
  認証データベース・ファイル

kaserver.DBSYS1
  認証データベース・ログ・ファイル

prdb.DB0
  保護データベース・ファイル

prdb.DBSYS1
  保護データベース・ログ・ファイル

vldb.DB0
  ボリューム・ロケーション・データベース・ファイル

vldb.DBSYS1
  ボリューム・ロケーション・データベース・ログ・ファイル

### /usr/afs/logs ディレクトリーのログ・ファイル

/usr/afs/logs ディレクトリーには、さまざまなサーバー・プロセスのログ・ファイルが含まれます。このファイルで通常のオペレーション中に発生する興味深いイベントについて詳しく説明します。たとえば、ボリューム・サーバーでは、ボリュームの移動を VolserLog ファイルに記録することができます。イベントは完了時に記録されます。そのため、サーバー・プロセスでは、これらのファイルを使用しないで、失敗したオペレーションを再構成します。これは /usr/afs/db ディレクトリーにあるログ・ファイルとは異なります。

ログ・ファイル内の情報は、プロセスの障害およびその他の問題を評価するのに非常に役立ちます。たとえば、ボリュームにアクセスしようとしてタイムアウト・メッセージを受け取った場合は、 FileLog ファイルを調べると、ファイル・サーバーがボリュームを付加できなかったことを示す説明が見つかる可能性があります。ログ・ファイルをリモートで調べるには、サーバー・プロセス・ログ・ファイル表示する で説明しているように、bos getlog コマンドを使用します。

このディレクトリーには、 BOS サーバーでプロセスをモニターする場合に生成される、コア・イメージ・ファイルも含まれます。BOS サーバーは、標準 core 名に拡張子を追加して、コア・ファイルを生成したプロセスを示そうとします (たとえば、保護サーバーによって生成されたコア・ファイルは、 core.ptserver という名前になります)。2 つのプロセスがほぼ同時に失敗すると、 BOS サーバーは正しい拡張子を割り当てることができない場合があります。

このディレクトリーには、以下のファイルが組み込まれます。

AuthLog
  認証サーバーのログ・ファイル。

BackupLog
  バックアップ・サーバーのログ・ファイル。

BosLog
  BOS サーバーのログ・ファイル。

FileLog
  ファイル・サーバーのログ・ファイル。

SalvageLog
  サルベージャーのログ・ファイル。

VLLog
  ボリューム・ロケーション (VL) サーバーのログ・ファイル。

VolserLog
  ボリューム・サーバーのログ・ファイル。

core.process
  存在する場合には、破損したマシンで AFS サーバー・プロセスとして作成されるコア・イメージ・ファイル (おそらく process が命名したプロセス)。

注: | ログ・ファイルが大きくなりすぎて管理不能になることを防ぐには、定期的にサーバー・プロセス (特にデータベース・サーバー・プロセス) を再始動します。プロセスの再始動を避けるには、UNIX の rm コマンドを使って、プロセスが実行されたらログ・ファイルを削除します。ログ・ファイルは自動的に再作成されます。

### サーバー・パーティションのボリューム・ヘッダー

AFS ボリュームを収容するパーティションは、マシンのルート ( / ) ディレクトリー (たとえば /usr ディレクトリーの下ではなく) のサブディレクトリーに取り付けなければなりません。ファイル・サーバー・マシンのファイル・システム登録ファイル (/etc/fstab または同等のファイル) は、ディレクトリー名とパーティションの装置名を正しくマップしなければなりません。ディレクトリーには、 /vicepindex の形式 (それぞれの index は 1 または 2 文字の小文字) の名前が付きます。規則では、マシン上の最初の AFS パーティションは /vicepa に、 2 番目のパーティションは /vicepb に、というように取り付けます。パーティションの数が 26 より多い場合は、 /vicepaa、/vicepab というように続けます。AFS Release Notes では、サポートされているサーバー・マシンあたりのパーティション数を指定しています。

非 AFS ファイルを AFS パーティションに保管しないでください。ファイル・サーバーおよびボリューム・サーバーは、パーティション上のすべてのスペースが使用可能であると予期します。

/vicep ディレクトリーには、以下の 2 つのタイプのファイルが含まれます。

Vvol_ID.vol
  このようなそれぞれのファイルが、ボリューム・ヘッダーです。vol_ID は、 vos examine、vos listvldb、および vos listvol コマンドの出力に表示されるボリューム ID 番号に対応します。

FORCESALVAGE
  この長さ 0 のファイルは、サルベージャーがパーティション全体を回収するトリガーとなります。 AFS 変更済みバージョンの fsck プログラムは、破壊を見つけると、このファイルを作成します。

注: | ほとんどのシステム・タイプにおいては、オペレーティング・システムに提供されている標準の fsck プログラムは、 AFS ファイル・サーバー・マシンでは決して実行してください。標準の fsck プログラムは、 AFS ボリューム・データの形式を認識できないため、サーバー・パーティションからすべての AFS ボリューム・データを削除します。

## ファイル・サーバー・マシンの 4 つの役割

複数のサーバー・マシンがあるセルでは、すべてのサーバー・マシンがまったく同じ機能を実行しなければならないわけではありません。実行しているサーバー・プロセスを判別して、マシンに想定できる可能な役割 が 4 つあります。すべての関連したプロセスを実行することによって、マシンには複数の役割を想定することができます。以下のリストでは 4 つの役割を要約しますが、それらについては、以降の機能グループでより完全に説明します。

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

セルにあるサーバー・マシンが 1 つだけの場合は、シンプル・ファイル・サーバーとデータベース・サーバーの役割を想定しています。 AFS インストールの手引き にある説明によっても、そのシステム・タイプに応じたシステム制御マシンとバイナリー配布マシンとして、サーバー・マシンを構成することができますが、サーバー・マシンがこれらの機能を実際に実行するのは、ユーザーが別のサーバー・マシンをインストールしてからです。

たとえ、すべてのプロセスが実行されていなくても、すべての AFS サーバー・プロセスのバイナリーを /usr/afs/bin ディレクトリーに保持するのは最もよいことです。次に、その役割を定義するプロセスを開始するかまたは停止するだけで、マシンに想定される役割を変更することができます。

### シンプル・ファイル・サーバー・マシン

シンプル・ファイル・サーバー・マシン が実行するのは、 AFS ファイルをクライアント・マシンに保管または送達し、プロセスの状態をモニターし、セルのバイナリー配布マシンとシステム制御マシンから、バイナリー・ファイルと構成ファイルをピックアップするサーバー・プロセスだけです。

一般的に、3 つより多いサーバー・マシンをもつセルだけが、シンプル・ファイル・サーバー・マシンを実行する必要があります。3 つ以下のマシンをもつセルでは、そのすべてのマシンはほとんどの場合データベース・サーバー・マシンです (管理用データベースの複写から利益を得るため)。 データベース・サーバー・マシン を参照してください。

以下のプロセスは、シンプル・ファイル・サーバー・マシンで実行されます。

- BOS サーバー (bosserver プロセス)
- fs プロセス。ファイル・サーバー、ボリューム・サーバー、およびサルベージャー・プロセスを結合し、これらがボリュームのデータに対して行うオペレーションを調整し、同じデータで複数のオペレーションを同時に行うことによって生じる矛盾を回避できるようにします。
- NTP コーディネーター (runntp プロセス)。マシンのクロックを、セル内のほかのサーバー・マシンのクロックと同期化させて保持するのに役立ちます。
- その AFS システム・タイプのバイナリー配布マシンからバイナリー・ファイルを選び出す、更新サーバーのクライアント部分 (upclientbin プロセス)
- 米国版の AFS を実行しているセル内のシステム制御マシンから共通構成ファイルを選び出す、更新サーバーのクライアント部分 (upclientetc プロセス)

### データベース・サーバー・マシン

データベース・サーバー・マシン は、 AFS の複写された管理用データベースを保守する 4 つのプロセスを実行します。この 4 つのプロセスとは、認証サーバー、バックアップ・サーバー、保護サーバー、および ボリューム・ロケーション (VL) サーバーで、認証データベース、バックアップ・データベース、保護データベース、およびボリューム・ロケーション・データベース (VLDB) をそれぞれ保守します。これらのサーバー・プロセスとそれらのデータベースの機能を見直すには、 AFS サーバー・プロセスとキャッシュ・マネージャー を参照してください。

セルに複数のサーバー・マシンがある場合には、複数のデータベース・サーバー・マシンを実行するのはよいことですが、3 つより多くが必要になることはめったにありません。データベースをこの方法で複写すると、情報の可用性と信頼性が増大するという、ボリュームを複写するのと同じ利益が生じます。1 つのデータベース・サーバー・マシンまたはプロセスが終わっても、データベース内の情報は、まだほかのデータベース・サーバー・マシンまたはプロセスから使用可能です。データベース情報に対する要求のロードが複数のマシンに分散し、いずれのマシンも過負荷になることがないようにします。

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

セルにあるあらゆるサーバー・マシンの AFS サーバー・プロセスが、どのマシンがデータベース・サーバー・マシンであるかを知っていることは重要です。特に、データベース・サーバー・プロセスでは、データベースのコピーを調整するために、対等機能との一定の接点を保守しなければなりません。ほかのサーバー・プロセスでは、データベースからの情報を必要とすることがよくあります。あらゆるサーバー・マシンでは、そのセルのデータベース・サーバー・マシンのリストを、ローカルの /usr/afs/etc/CellServDB ファイルに保持します。米国版の AFS を使用するセルでは、システム制御マシンを使用して、このファイルを配布することができます (システム制御マシン を参照)。

以下のプロセスは、定義・サーバー・マシンを定義します。

- 認証サーバー (kaserver プロセス)
- バックアップ・サーバー (buserver プロセス)
- 保護サーバー (ptserver プロセス)
- VL サーバー (vlserver プロセス)

データベース・サーバー・マシンは、シンプル・ファイル・サーバー・マシン にリストされるような、シンプル・ファイル・サーバーを定義するプロセスも実行することができます。1 つのデータベース・サーバー・マシンは、セルのシステム制御マシンとしての機能を果たし、データベース・サーバー・マシンのどれかは、そのシステム・タイプのバイナリー配布マシンとして機能を果たすことができます。 システム制御マシン および バイナリー配布マシン を参照してください。

### バイナリー配布マシン

バイナリー配布マシン では、 AFS プロセスとコマンドの組のバイナリー・ファイルを、そのシステム・タイプのほかのすべてのサーバー・マシンに保管したり配布します。それぞれのファイル・サーバー・マシンでは、 AFS サーバー・プロセス・バイナリーの独自のコピーをローカル・ディスクに、規則では、/usr/afs/bin ディレクトリーに保持します。ただし、一貫したシステム・パフォーマンスのためには、すべてのサーバー・マシンで同じバージョン (作成レベル) のプロセスを実行しなければなりません。バイナリーの作成レベルを調べるための指示については、 バイナリー・ファイルの作成レベルの表示 を参照してください。バイナリーの整合性を保持する最も簡単な方法は、それぞれのシステム・タイプのバイナリー配布マシンを使って、バイナリーをそのシステム・タイプのマシンに配布することです。

バイナリー配布マシンを定義するプロセスは、更新サーバーのサーバー部分 (upserver プロセス) です。更新サーバーのクライアント部分 (upclientbin プロセス) は、そのシステム・タイプのほかのサーバー・マシンで実行され、バイナリー配布マシンを参照します。

通常、バイナリー配布マシンは、 シンプル・ファイル・サーバー・マシン にリストされるような簡単なファイル・サーバー・マシンを定義するプロセスも実行します。 1 つのバイナリー配布マシンはセルのシステム制御マシンとしての機能を果たし、任意のバイナリー配布マシンはデータベース・サーバー・マシンとしての機能を果たします。システム制御マシンおよび データベース・サーバー・マシンを参照してください。

### システム制御マシン

米国版の AFS を実行するセルでは、 システム制御マシン では、セル内のすべてのサーバー・マシンが共有するシステム構成ファイルを保管し配布します。それぞれのファイル・サーバー・マシンでは、構成ファイルの独自のコピーをローカル・ディスクに、規則では /usr/afs/etc ディレクトリーに保持します。ただし、一貫したシステム・パフォーマンスのためには、すべてのサーバー・マシンで同じファイルを使用しなければなりません。ファイルの整合性を保持する最も簡単な方法は、システム制御マシンを使ってファイルを配布することです。本書の説明で指図されるときには、システム制御マシンに保管されるコピーだけを変更します。米国版の AFS は、米国政府の規制により決められた、米国とカナダにあるセル、およびほかの各国の選ばれた機関に使用可能です。

AFS の国際版を実行するセルでは、システム構成ファイルを配布するために、システム制御マシンを使用しません。このファイルの一部には、暗号化しないでネットワークを渡すには重要過ぎる情報が含まれ、米国政府の規制により、必要な暗号化ルーチンを更新サーバーが使用する形式でエクスポートすることは禁じられています。代わりに、それぞれのファイル・サーバー・マシンで個別に、構成ファイルを更新しなければなりません。ファイルを更新するために使用する bos コマンドは、暗号化ルーチンのエクスポート可能な形式を使用して情報を暗号化します。

/usr/afs/etc ディレクトリーに保管される構成ファイルのリストについては、 /usr/afs/etc ディレクトリーにある共通構成ファイル を参照してください。

AFS インストールの手引き では、システム制御マシンとして、セルの最初のサーバー・マシンを構成します。希望する場合には、後にユーザーがインストールする別のマシンに、その役割を再割り当てすることができますが、ほかのすべてのサーバー・マシンで実行している更新サーバーのクライアント部分を (upclientetc プロセス) を変更して、新規システム制御マシンに当てはめなければなりません。

以下のプロセスは、システム制御マシンを定義します。

- 米国版の AFS を使用しているセルでは、更新サーバー (upserver) プロセスのサーバー部分。更新サーバーのクライアント部分 (upclientetc プロセス) は、ほかのサーバー・マシンで実行され、システム制御マシンを参照します。
- セルが NTPD を使用してクロックを同期化する場合には、セル外部の時間ソースを指す NTP コーディネーター (runntp プロセス)。ほかのマシンの runntp プロセスは、その主な時間ソースとしてシステム制御マシンを参照します。

システム制御マシンでは、シンプル・ファイル・サーバー・マシン にリストされるような、シンプル・ファイル・サーバー・マシンを定義するプロセスも実行できます。また、このマシンはデータベース・サーバー・マシンとしての機能も果たすことができ、規則では、そのシステム・タイプのバイナリー配布マシンとしての機能を果たします。単一の upserver プロセスでは、構成ファイルとバイナリー・ファイルの両方を配布することができます。 データベース・サーバー・マシン および バイナリー配布マシン を参照してください。

### データベース・サーバー・マシンを特定するには

1. bos listhosts コマンドを発行する。

          % bos listhosts <machine name>

   出力にリストされるマシンは、そのセルのデータベース・サーバー・マシンです。詳細な説明と、出力サンプルについては、セルのデータベース・サーバー・マシンを表示するには を参照してください。

2. (オプション) bos status コマンドを発行して、 bos listhosts コマンドの出力にリストされたマシンが、そのマシンをデータベース・サーバー・マシンとして定義するプロセスを実際に実行していることを検証します。詳細な指示については、BosConfig ファイルのプロセス状況および情報の表示 を参照してください。

          % bos status <machine name> buserver kaserver ptserver vlserver

   指定したマシンがデータベース・サーバー・マシンである場合、 bos status コマンドの出力には以下の行が含まれます。

          Instance buserver, currently running normally.
          Instance kaserver, currently running normally.
          Instance ptserver, currently running normally.
          Instance vlserver, currently running normally.

### システム制御マシンを特定するには

1. 任意のファイル・サーバー・マシンに bos status コマンドを発行する。詳細な指示は BosConfig ファイルのプロセス状況および情報の表示 にあります。

          % bos status <machine name> upserver upclientbin upclientetc -long

   表示される出力は、ユーザーが交信したマシン、すなわち、シンプル・ファイル・サーバー・マシン、システム制御マシン、またはバイナリー配布マシンによって異なります。bos status コマンドの出力の解釈 を参照してください。

### システム・タイプに応じたバイナリー配布マシンを特定するには

1. 検査する対象のシステム・タイプのファイル・サーバー・マシンに、 bos status コマンドを発行する (マシンのシステム・タイプを判別するには、 システム・タイプ名の表示および設定 に説明するように、fs sysname または sys コマンドを発行します)。 bos status コマンドに関する詳細な指示は、BosConfig ファイルのプロセス状況および情報の表示 にあります。

          % bos status <machine name> upserver upclientbin upclientetc -long

   表示される出力は、ユーザーが交信したマシン、すなわち、シンプル・ファイル・サーバー・マシン、システム制御マシン、またはバイナリー配布マシンによって異なります。bos status コマンドの出力の解釈 を参照してください。

### bos status コマンドの出力の解釈

bos status コマンドの出力の解釈は、単純なファイル・サーバー・マシンでは最も簡単です。upserver プロセスがないため、出力には以下のメッセージが含まれます。

       bos: failed to get instance info for 'upserver' (no such entity)

単純なファイル・サーバー・マシンは upclientbin プロセスを実行するので、出力には次のようなメッセージが含まれます。これは、fs7.abc.com がこのシステム・タイプのバイナリー配布マシンであることを示しています。

       Instance upclientbin, (type is simple) currently running normally.
       Process last started at Wed Mar 10  23:37:09 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upclient fs7.abc.com -t 60 /usr/afs/bin'

米国版の AFS を実行している場合は、単純なファイル・サーバー・マシンは upclientetc プロセスも実行するので、出力には次のようなメッセージが含まれます。これは、fs1.abc.com がシステム制御マシンであることを示しています。

       Instance upclientetc, (type is simple) currently running normally.
       Process last started at Mon Mar 22  05:23:49 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upclient fs1.abc.com -t 60 /usr/afs/etc'

#### システム制御マシンの出力

米国版の AFS を実行していて、システム制御マシンに bos status コマンドを発行した場合は、出力には次のような upserver プロセスに関する項目が含まれます。

       Instance upserver, (type is simple) currently running normally.
       Process last started at Mon Mar 22 05:23:54 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upserver'

AFS インストールの手引き で推奨されているデフォルトの構成を使用している場合、システム制御マシンはそのシステム・タイプのバイナリー配布マシンでもあり、単一の upserver プロセスが両方の種類の更新を配布します。その場合には、出力には次のメッセージが含まれます。

       bos: failed to get instance info for 'upclientbin' (no such entity)
       bos: failed to get instance info for 'upclientetc' (no such entity)

システム制御マシンがバイナリー配布マシンでない場合には、出力には upclientetc プロセスに関するエラー・メッセージが含まれ、 upclientbin プロセスの完全なリストは含まれません (この場合、マシン fs5.abc.com がバイナリー配布マシンとして参照されます)。

       Instance upclientbin, (type is simple) currently running normally.
       Process last started at Mon Mar 22  05:23:49 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upclient fs5.abc.com -t 60 /usr/afs/bin'
       bos: failed to get instance info for 'upclientetc' (no such entity)

#### バイナリー配布マシンの出力

バイナリー配布マシンに bos status コマンドを発行した場合は、出力には次のような upserver プロセスに関する項目と、 upclientbin プロセスに関するエラー・メッセージが含まれます。

       Instance upserver, (type is simple) currently running normally.
       Process last started at Mon Apr 5 05:23:54 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upserver'
       bos: failed to get instance info for 'upclientbin' (no such entity)

このマシンがシステム制御マシンでもある場合以外は、次のようなメッセージでシステム制御マシン (この場合は fs3.abc.com) が参照されます。

       Instance upclientetc, (type is simple) currently running normally.
       Process last started at Mon Apr 5 05:23:49 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upclient fs3.abc.com -t 60 /usr/afs/etc'

## データベース・サーバー・マシンの管理

この機能グループでは、データベース・サーバー・マシンの管理方法を説明します。インストールの説明に関しては、 AFS インストールの手引き を参照してください。

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

AFS 管理データベースの複写 に説明されているように、AFS 管理用データベース (認証、バックアップ、保護、およびボリューム・ロケーションの各データベース) の複写には、いくつかの利点があります。セルが正しく機能するためには、各データベースのコピーが常に同一のものでなければなりません。データベースを同期化させておくために、 AFS はUbik と呼ばれるユーティリティーのライブラリーを使用します。各データベース・サーバーのプロセスは、関連した lightweight Ubik プロセスとして実行され、クライアント側のプログラムは、Ubik のクライアント側のサブルーチンを呼び出して、データベースの読み取りや変更要求を実行以来します。

Ubik は、管理者の操作を最小にとどめて機能するよう設計されていますが、 Ubik の適切なオペレーションのためのセル構成 に示すようにいくつかの構成要件があります。以下の Ubik のオペレーションの概要は、この要件を理解するための手助けとなるでしょう。詳細については、Ubik の自動オペレーション を参照してください。

Ubik は、AFS 管理データベースで行われた変更をすべてのコピーにできるだけすぐに配布することを目的としています。クライアントからの変更要求を受け入れる唯一のデータベース・コピーが 同期サイト であり、ここで実行される lightweight Ubik プロセスのことを Ubik コーディネーター といいます。最低限の可用性を保持するため、各データベースごとに別個の Ubik コーディネーターが存在し、 4 つのデータベースごとに別のマシンに同期サイトを置くことができます。データベースの同期サイトもまた、プロセス、マシン、またはネットワークの障害に応じて、マシン間を移動することができます。

データベースのその他のコピー、およびこれを保守するための Ubik プロセスは、 2 次 と名付けられます。2 次サイトは、クライアント側プログラムから直接変更を受け入れることはなく、同期サイトからのみ受け入れます。

Ubik コーディネーターは、データベースのコピーに変更を記録すると、即時に変更を 2 次サイトに送ります。短い配布期間中は、たとえ読み取り用であっても、クライアントはデータベースのコピーにアクセスできません。コーディネーターが 2 次サイトの多数に到達することができない場合には、そのコピーを打ち切り、変更の試行が失敗したことをクライアントに通知します。

配布上の障害を避けるため、Ubik プロセスはタイム・スタンプのあるメッセージを交換して、常時交信をするようにします。 2 次サイトの多数がコーディネーターのメッセージに応答する限りは、コーディネーターと同期したサイトの 定数 が存在するものとされます。プロセス、マシン、またはネットワークの障害により定数が割れる場合には、 Ubik プロセスは新しくコーディネーターを選び出し、できる限り多くのサイト間で定数を確立するようにします。 柔軟なコーディネーターによる可用性の向上 を参照してください。

#### Ubik の適切なオペレーションのためのセル構成

このセクションでは、適切な Ubik のオペレーションのためのセルの構成方法を説明します。

- 4 つのデータ・サーバー・プロセス (認証サーバー、バックアップ・サーバー、保護サーバー、および VL サーバー) のすべてを、すべてのデータベース・サーバー・マシンで実行します。

  Ubik のクライアント部分とサーバー部分のどちらも、 CellServDB ファイルにリストされるすべてのデータベース・サーバー・マシンが、すべてのデータベース・サーバー・プロセスを実行していることを求めます。あるマシンで実行されている特定のデータベース・サーバー・プロセスを示すメカニズムはありません。

- /usr/afs/etc/CellServDB のファイル情報が常時正しいものとなるよう保守します。

  Ubik は /usr/afs/etc/CellServDB ファイルを参照して、定数の確立、保守に使用するサイトを判別します。情報が正しくないと、データベースの同期がとれない、またはマシンの複数のサブグループからそれぞれコーディネーターが選ばれる結果となります。これは、各マシンの Ubik プロセスが、定数に加わるマシンの判別に一致した結果を出さないためです。

  米国版の AFS を稼働しており、更新サーバーを使用する場合は、システム制御マシン (コピーをその他すべてのサーバー・マシンに配布する) 上に /usr/afs/etc/CellServDB ファイルを置くのが最も簡単な方法です。 AFS インストールの手引き では、更新サーバーの構成方法を説明しています。インターナショナル版の AFS を稼働する場合、各マシン上でファイルを個別に更新しなくてはなりません。

  ファイルを更新するのは、データベース・サーバー・マシンの構成時または使用中止する場合です。手動でファイルを編集するのではなく、適切な bos コマンドを使用します。説明については、 サーバー CellServDB ファイルの保守 を参照してください データ ベース・サーバー・マシンのインストールまたは使用の中止に関する AFS インストールの手引き の説明のように、プロセスの停止と開始に関する サーバー・プロセスの監視および制御 の説明は、適切な環境で CellServDB ファイルを忘れずに更新するようユーザーに注意しています。

  (データベースの保守を行わないクライアント・プロセスをサーバー・プロセスもまた、適切なオペレーションを行うため CellServDB ファイルを使用しますが、この場合、Ubik のオペレーションには影響はありません。 サーバー CellServDB ファイルの保守 および データベース・サーバー・マシンの情報を保持する を参照してください。)

- セル内のすべてのマシン、特にデータベース・サーバー・マシンでは、クロックを同期させるようにしてください。

  AFS インストールの手引き に指定されている通常の構成では、 runntp プロセスを実行して、すべての AFS サーバー・マシン上のローカル Network Time Protocol Daemon (NTPD) を監視します。システム上の NTPD は、セル外の信用できるソースとマシンのクロックを同期するよう制御し、他のサーバー・マシンの NTPD に時刻を同報通信します。必要であれば、異なる時刻同期プロトコルを実行することができます。

  Ubik はデータベース・サイトのタイム・スタンプがあるメッセージを交換して常時交信をするため、クロックを同期させておくことは重要です。ネットワーク環境においては、メッセージが即時に宛先に到達すると考えるのは安全な前提ではないので、メッセージのタイム・スタンプは重要です。 Ubik は、着信メッセージと現在の時刻を比較します。差が大きすぎる場合は、障害により Ubik サイト間ので信頼性のある通信が行われず、これによりデータベースが同期されなかった可能性があります。Ubik はメッセージを無効とみなし、この場合異なるコーディネーターを選ぶよう指示が出されることがあります。

  実際に通信が中断したことによりタイム・スタンプを持つメッセージの有効期限が切れた場合、新規のコーディネーターを選ぶのは適当といえますが、送信側と受信側の時刻が異なるという理由だけでメッセージの有効期限が切れたと思われる場合には妥当ではありません。クロックの同期がとれていないことにより Ubik オペレーションが不安定となる場合の例については、 Ubik におけるタイム・スタンプ・メッセージの使用 を参照してください。

#### Ubik の自動オペレーション

以下の Ubik 機能は、保守要件を最低限にするために役に立ちます。

- Ubik のサーバーとクライアントの部分は、自動的に作動します。

  それぞれのデータベース・サーバー・プロセスは、 Ubik ライブラリーのサーバー部分を呼び出すため lightweight プロセスを実行します。この lightweight プロセスを Ubik として参照するのが一般的です。これは lightweight プロセスであるため、 Ubik プロセスは、UNIX ps コマンドなどで生成されるプロセス・リストには現れません。データベースを読み取りおよび変更する必要のあるクライアント側プログラムは、別個の lightweight プロセスを実行するのではなく、Ubik ライブラリーのクライアント部分にあるサブルーチンを直接呼び出します。このようなプログラムには、klog コマンドや、pts 組のコマンドがあります。

- Ubik は、データベース・バージョン番号をトラックします。

  コーディネーターがデータベースに変更を記録する際、データベースのバージョン番号が増分で更新されます。バージョン番号によって、サイトが最新のバージョンを入手しているかいないかを決定するのが簡単になります。バージョン番号を使用することにより、新規コーディネーターの選出後、または通信が停止後に復元された場合の通常復帰機能が高速化されます。これは、最新のデータベースを所有するサイトおよび更新の必要があるサイトの判別が容易になるためです。

- Ubik がタイム・スタンプのあるメッセージを使用することにより、データベース・コピーが通常のオペレーションにおいて常に同期化されます。

  データベースの複写によるデータ使用可能性の向上は、すべてのデータベース・コピーが同じでないと意味がありません。クライアントがアクセスするデータベースのコピーに応じて異なる情報を受け取ると、パフォーマンスに矛盾が生じます。先に説明したとおり、Ubik サイトはタイム・スタンプを持つメッセージを交換してピアの状況をトラックします。詳細については、 Ubik におけるタイム・スタンプ・メッセージの使用 を参照してください。

- コーディネーターを移動できることにより、データベースの可用性が最大限向上します。

  たとえば、3 つのデータベース・サーバー・マシンを持つセルにおいて、ネットワーク・パーティションがコーディネーターから 2 つの 2 次サイトを分離したとします。コーディネーターは、 CellServDB ファイルにリストされている多数のサイトとは交信できないため、終了します。パーティションの別サイドの 2 つのサイトは、そのサイト間で新しいコーディネーターを選出し、クライアントからのデータベースの変更を受け入れることができます。このようにしてコーディネーターを移動できないとすると、ネットワーク・パーティションが回復するまでデータベースは読み取り専用となってしまいます。 Ubik による選出方法の詳細については、 柔軟なコーディネーターによる可用性の向上 を参照してください。

##### Ubik におけるタイム・スタンプ・メッセージの使用

Ubik は、同期サイトと 2 次サイト間で常時交信を行うことにより、データベースのコピーを同期します。 Ubik コーディネーターは、各 2 次サイトに対しタイム・スタンプ付きの 保証 メッセージを頻繁に送信します。 2 次サイトはメッセージを受信すると、コーディネーターと通信状態にあるものとみなします。 2 次サイトは、時間 T (通常はコーディネーターのメッセージ送信後から 60 秒) の間は、データベースのコピーが有効であると判断します。これに対して、 2 次サイトは特定時間 X (通常はそれ以降の 120 秒) の間はコーディネーターを有効と認める、 賛否表示 メッセージを戻します。

コーディネーターは、T 秒ごとより頻繁に保証メッセージを送信します。したがって、有効期限はオーバーラップします。ネットワーク・パーティションやその他の障害によって実際に通信が停止することがなければ、満了することはありません。保証期限が切れた場合、 2 次サイトのデータベース・コピーは、現行ではなくなります。この場合でも、データベース・サーバーはクライアント要求へのサービスを継続します。セル全体が機能するためには、2 次サイトの配布する情報の期限が切れた場合でも、アクセス可能とされている方がよいものと考えられます。いずれにせよ AFS 管理データベースの大部分はそう頻繁に変更されることはなく、データベースがアクセス不能になることにより、コピーにアクセスしたクライアントに対してタイムアウトが生じることになります。

先の説明のとおり、Ubik がタイム・スタンプ付きのメッセージを使用する上では、データベース・サーバー・マシンのクロックを同期させることが重要です。どちらのクロックが先に進んでいるかにより、ずれたクロックが通常の Ubik 機能の妨げとなる場合が 2 つ考えられます。

たとえば、Ubik コーディネーターのクロックが 2 次サイトより進んでいるとします (コーディネーターのクロックが 9:35:30、2 次サイトのクロックが 9:31:30)。 2 次サイトが、コーディネーターが 9:33:30 まで有効であると認める賛否表示メッセージを送るとします。これは、2 次サイトのクロックでは 2 分先の時刻ですが、コーディネーターからは既に過去です。コーディネーターは、コーディネーターのままでいることはもう支持されていないと推断し、新規のコーディネーターを選出するよう強制します。選出には 3 分ほどかかり、その間データベースのコピーは変更を受け入れません。

これとは逆に、2 次サイトのクロック (14:50:00) が、コーディネーター (14:46:30) より進んでいる場合があります。コーディネーターが 14:47:30 までの保証メッセージを送信した場合、これは 2 次サイトでは期限切れとなります。 2 次サイトは、コーディネーターとの交信が不可能であるとみなし、コーディネーターへの賛否表示を停止し、自身をコーディネーターに選出しようとします。これは、実際にコーディネーターに障害のあった場合には適切な処置ですが、実際に障害がない場合には適切とはいえません。

新規コーディネーターとして選出されようとする単一の 2 次サイトの試みは、ほかのサイトのパフォーマンスには影響しません。2 次サイトのクロックがコーディネーターと同じである限り、他の 2 次サイトからの賛否表示要求を無視し、現行のコーディネーターへの賛否表示を継続します。ただしコーディネーターよりクロックが進んだクロックの 2 次サイトが多くなれば、たとえ現行のコーディネーターが実際に申し分のない作業を行っていても、新規コーディネーターの選出を強制することができます。

##### 柔軟なコーディネーターによる可用性の向上

Ubik は、コーディネーターの選出が必要となる際に、タイム・スタンプ付きのメッセージを使用します。これはデータベース・コピーの同期をとる場合と同様です。コーディネーターがサイトの過半数から投票メッセージを受け取ると (コーディネーターは暗黙的に自らに投票します)、データベースの変更の配布が正常に行われているとされ、コーディネーターの役割を継続することができます。過半数とは、奇数のサイトがある場合にすべてのデータベース・サイトの 50 % を上回る数のことです。偶数のサイトがある場合は、最下位の IP アドレスを持つサイトに特別な決定権があります。コーディネーターは、十分な票数を獲得できないとその役割を終了し、 Ubik サイトは新規コーディネーターを選出します。このようなことは、コーディネーターが実際に過半数の賛否表示の受信に失敗したり停止する場合を除いて、自然に発生することはありません。2 次サイトには、既存のコーディネーターに対する投票を続行するための組み込まれたバイアスがあり、不適当な選出を回避します。

新規コーディネーターは、多数決によって選出されます。Ubik サブプロセスには、最下位の IP アドレスをもつサイトに投票するためのバイアスがあり、すべてのサイトが賛否表示を自身で受けようと競合した場合よりも速く、必要な過半数を集めるのに役立ちます。選出中 (通常、3 分も続きません)、クライアントはデータベースからの情報を読み取ることはできますが、変更を加えることはできません。

Ubik の選出手続きでは、各データベース・サーバー・プロセスのコーディネーターを異なるマシンに置くことができます。たとえば、4 つすべてのプロセスの Ubik コーディネーターがマシン A で開始し、マシン A の保護サーバーに何らかの理由で障害が発生した場合は、別のサイト (たとえばマシン B) を新規の保護データベース Ubik コーディネーターとして選出しなければなりません。マシン A の保護サーバーが再び動作を開始した後も、マシン B は保護サーバーのコーディネーターのままです。保護サーバーの障害は、認証、バックアップ、および VL サーバーに影響を及ぼしません。したがって、それらのコーディネーターはマシン A に残存しています。

### 管理用データベースのバックアップと復元

AFS 管理用データベースには、セル内の AFS のオペレーションにとって重要な情報が保管されます。データベース・サーバー・マシンのハードウェア障害またはその他の問題によってデータベースが破壊された場合は、すべての情報を最初から再作成することは通常、困難で時間がかかります。データを消失から保護するには、管理用データベースを磁気テープなどの永久媒体に定期的にバックアップします。推奨される方法は、UNIX の tar コマンドのような標準のローカル・ディスク・バックアップ・ユーティリティーを使う方法です。

データベースをバックアップする頻度を決めるときは、バックアップ・コピーからデータベースを復元することが必要になった場合に、手作業で再作成してもかまわないデータの量を検討します。ほとんどのセルでは、データベースによって、変更の頻度と程度はかなり異なります。認証データベースに対する変更は、おそらく最も頻度が少なく、ほとんどがユーザー・パスワードの変更です。保護データベースおよび VLDB の変更がおそらく最も頻度が高くなります。その変更とは、ユーザーによるグループの追加または削除やグループ・メンバーシップの変更、および管理者によるボリュームの作成または移動です。変更の数と頻度は、おそらく保護データベースで最大になります。バックアップを毎日行う場合は特にそうです。

また、消失した変更の回復がどれだけ容易かも、データベースによって異なります。

- 通常のユーザーが変更の大部分をセル内の認証データベースと保護データベースに対して行っている場合は、変更を回復するには大量の検出作業とユーザーへのインタビューがおそらく必要であり、しかもユーザーがいつどのような変更を行ったかを覚えていることが前提となります。
- 消失した VLDB に対する変更の回復は、これより簡単です。 vos syncserv コマンドと vos syncvldb コマンドを使って、 VLDB とサーバー・マシンのボリュームの実際の状態を不一致を訂正することができるからです。ただし、これらのコマンドの実行には時間がかかります。
- バックアップ・データベースの構成情報 (テープ・コーディネーター・ポート・オフセット、ボリューム・セットおよび項目、ダンプ階層など) は、おそらくそれほど頻繁には変更されません。その場合、最近の少数の変更を回復するのは難しいことではありません。それと対照的に、ダンプ・オペレーションの結果である新規ダンプ・レコードが多数あることが考えられます。これらのレコードは、backup scantape コマンドで -dbadd 引き数を使って、バックアップ・テープそのものから情報を読み込むことで回復できます。ただし、セルでバックアップするデータの量やダンプを付加する方法によって、この処理は長時間を要し、テープの入れ替えが何度も必要になったりします。さらに、backup scantape コマンドにはいくつかの制約事項があります。このコマンドの最も基本的な制約事項は、データベース内の既存のダンプ・レコードが、このコマンドがスキャンしているテープ上のダンプと同じダンプ ID 番号を持っていることを検出すると、停止するということです。スキャン・オペレーションを継続したい場合は、既存のレコードをデータベースから探し出し、除去しなければなりません。詳細については、AFS Administration Reference の backup scantape コマンドの解説ページを参照してください。

データベース間のこれらの相違は、異なる頻度 (バックアップ・データベースについては数日おきから毎週、認証データベースについては 2 〜 3 週間ごとの範囲) でデータベースをバックアップすることを提示しています。一方、配備上の観点からは、特に磁気テープの消費がそれほど問題にならない場合は、すべてのデータベースを同時に (同じ頻度で) バックアップすれば、おそらくもっと単純です。また、一般にデータベースのコピーを長期間残しておく必要はないので、磁気テープは短期間で再利用できます。

### 管理用データベースをバックアップするには

1. 同期サイトではないデータベース・サーバー・マシン上のローカル・スーパーユーザー root としてログインする。通常、最も高い IP アドレスを持ったマシンが最上の選択です。その理由は、そのマシンが、選択で同期サイトになるということは、ほとんどないからです。
2. bos shutdown コマンドを発行して、ローカル・マシン上の関係のあるサーバー・プロセスを終了する。コマンドの詳細な説明は、プロセスを一時停止させる方法 を参照してください。

   -instance 引き数には、 1 つまたは複数のデータベース・サーバー・プロセスの名前を指定します (バックアップ・サーバー buserver、認証サーバー kaserver、保護サーバー ptserver、またはボリューム・ロケーション・サーバー vlserver)。ローカル・スーパーユーザー root としてログインするので -localauth フラグを付けますが、管理トークンは必ずしも必要ではありません。

          # bos shutdown <machine name> -instance <instances>+ -localauth [-wait]

3. 1 つまたは複数のデータベース・ファイルをテープに転送するには、 tar コマンドなど、ローカル・ディスク・バックアップ・ユーティリティーを使用する。ローカル・データベース・サーバー・マシンにテープ装置が付いていない場合は、リモート・コピー・コマンドを使用してファイルをテープ装置付きのマシンに転送し、その後、そこで tar コマンドを使用します。

   以下のコマンド・シーケンスは、/usr/afs/db ディレクトリーの完全なコンテンツをバックアップします。

          # cd /usr/afs/db
          # tar cvf  tape_device  .

   個々のデータベース・ファイルをバックアップするには、上に示した tar コマンドで、期間をファイルの名前に置換します。

   - バックアップ・データベースの場合は、bdb.DB0
   - 認証データベースの場合は、kaserver.DB0
   - 保護データベースの場合は、prdb.DB0
   - VLDB の場合は、vldb.DB0
4. bos start コマンドを発行して、ローカル・マシン上でサーバー・プロセスを再始動する。コマンドの詳細な説明は、状況フラグを Run に変更してプロセスを開始する方法 を参照してください。-instance 引き数には 2 のステップと同じ値を指定します。同様に -localauth フラグを指定します。

          # bos start <machine name> -instance <server process name>+ -localauth

### 管理用データベースを復元するには

1. ローカル・スーパーユーザー root として、セル内の各データベース・サーバー・マシンにログインする。
2. マシンの 1 つを使用して、bos shutdown コマンドを 1 度、各データベース・サーバー・マシンに発行し、それらのすべてのマシン上の関係のあるサーバー・プロセスを終了する。コマンドの詳細な説明は、プロセスを一時停止させる方法 を参照してください。

   -instance 引き数には、 1 つまたは複数のデータベース・サーバー・プロセスの名前を指定します (バックアップ・サーバー buserver、認証サーバー kaserver、保護サーバー ptserver、またはボリューム・ロケーション・サーバー vlserver)。ローカル・スーパーユーザー root としてログインするので -localauth フラグを付けますが、管理トークンは必ずしも必要ではありません。

          # bos shutdown <machine name> -instance <instances>+ -localauth [-wait]

3. 以下のコマンドを各マシン上で発行することによって、データベースを各データベース・サーバー・マシンから除去する。

          # cd /usr/afs/db

   バックアップ・データベースの場合、

          # rm bdb.DB0
          # rm bdb.DBSYS1

   認証データベースの場合は、

          # rm kaserver.DB0
          # rm kaserver.DBSYS1

   保護データベースの場合は、

          # rm prdb.DB0
          # rm prdb.DBSYS1

   VLDB の場合は、

          # rm vldb.DB0
          # rm vldb.DBSYS1

4. データベースをバックアップするために使用したローカル・ディスク・バックアップ・ユーティリティーを使用して、最後にバックアップしたバージョンを、 IP アドレスが最も小さいデータベース・サーバー・マシン上の適切なファイルにコピーする。同期サイトにテープ装置が付いている場合は、以下に示すのは tar コマンドの適切な例です。

          # cd /usr/afs/db
          # tar xvf tape_device  database_file

   database_file は、次のいずれかです。

   - バックアップ・データベースの場合は、bdb.DB0
   - 認証データベースの場合は、kaserver.DB0
   - 保護データベースの場合は、prdb.DB0
   - VLDB の場合は、vldb.DB0
5. マシンの 1 つを使用して、bos start コマンドを発行し、サーバー・プロセスを、各データベース・サーバー・マシン上で順番に再始動する。最も低い IP アドレスを持ったマシンから開始します。このマシンがバックアップ・データベースに対する同期サイトになります。このマシンが同期サイトとして確立するのを待った後で、このコマンドの実行を繰り返し、プロセスをほかのデータベース・サーバー・マシン上で再始動します。コマンドの詳細な説明は、状況フラグを Run に変更してプロセスを開始する方法を参照してください。-instance 引き数には 2 のステップと同じ値を指定します。同様に -localauth フラグを指定します。

          # bos start <machine name> -instance  <server process name>+  -localauth

6. データベースが、最後にバックアップした以降に変更されている場合は、示された機能グループにある説明に従って適切なコマンドを発行し、復元されたデータベース内に情報を再作成する。pts コマンドを発行する場合は、最初に管理トークンを取得しなければなりません。ローカル・スーパーユーザー root としてログインしている場合は、 backup コマンドおよび vos コマンドで -localauth フラグが受け入れられるので、管理トークンは必要ありません。認証サーバーはいつでも分離された認証を実行するので、 kas コマンドを発行する場合にのみ、-admin 引き数を組み込む必要があります。
   - バックアップ・データベースでボリューム・セットおよびボリューム項目を定義または除去するには、 ボリューム・セットおよびボリューム項目の定義および表示 を参照する。
   - ダンプ階層を編集するには、ダンプ階層の定義および表示 を参照する。
   - バックアップ・データベースでテープ・コーディネーター・ポート・オフセット項目を定義または除去するには、 テープ・コーディネーター・マシンおよびテープ装置の構成 を参照する。
   - バックアップ・データベースにダンプ・レコードを復元するには、テープ内容をスキャンするには を参照する。
   - ユーザーの認証データベース項目またはパスワードの変更を再作成するには、 ユーザー・アカウントの管理 の該当する機能グループを参照する。
   - 保護データベース項目またはグループ・メンバーシップ情報を再作成するには、 保護データベースの管理 の該当する機能グループを参照する。
   - ボリューム・ヘッダーによって VLDB を同期化するには、VLDB およびボリューム・ヘッダーの同期化 を参照する。

## サーバー・プロセス・ソフトウェアのインストール

この機能グループでは、ファイル・サーバー・マシンに新規サーバー・プロセス・バイナリーをインストールする方法、現行バージョンが適切に作動していない場合に前のバージョンに復帰する方法、および、AFS ボリュームを収容する新規のディスクをファイル・サーバー・マシンにインストールする方法について説明します。

サーバー・プロセスのバイナリーを置き換えるための最もよくある理由は、 AFS を新規のバージョンにアップグレードすることです。一般に、更新されたソフトウェアにはインストールの説明が付いていますが、この章は追加の解説書となります。

各 AFS サーバー・マシンは、規則では /usr/afs/bin と呼ばれるローカル・ディスク・ディレクトリーに、サーバー・プロセス・バイナリーを保管しなければなりません。予測可能なシステム・パフォーマンスのためには、すべてのサーバー・マシンで、同じ作成レベルまたは少なくとも同じバージョンのサーバー・ソフトウェアを実行することが最適です。AFS 作成レベルを調べるための指示については、バイナリー・ファイルの作成レベルの表示 を参照してください。

更新サーバーを使用すると、一貫したバージョンのソフトウェアをすべてのサーバー・マシンに容易に配布できます。システム・タイプごとに 1 つのサーバー・マシンをバイナリー配布マシン として指定します。そのためには、更新サーバーのサーバー部分 (upserver プロセス) をそのマシン上で実行します。そのシステム・タイプの、その他すべてのサーバー・マシンは、更新サーバーのクライアント部分 (upclientbin プロセス) を実行して、更新されたソフトウェアをバイナリー配布マシンから検索します。AFS インストールの手引き では、適切なプロセスをインストールする方法について説明しています。バイナリー配布マシンに関する詳細については、 バイナリー配布マシン を参照してください。

更新サーバーを使用する場合は、新規バイナリーをバイナリー配布マシンだけにインストールします。 upclientbin プロセスを実行しているマシンにバイナリーを直接インストールすると、プロセスがローカルの /usr/afs/bin ディレクトリーのコンテンツと、システム制御マシンのコンテンツを次回に比較したとき (デフォルトでは 5 分以内) に、バイナリーは上書きされます。

以下の指示は、bos の組の適切なコマンドを使用して、サーバー・バイナリーをインストールおよびアンインストールする方法について説明しています。

### 新規バイナリーのインストール

AFS サーバー・プロセスが /usr/afs/bin ディレクトリーにインストールされた直後に、自動的に新規プロセスのバイナリー・ファイルに切り替わることはありません。プロセスは、次に再始動されるまで、前のバージョンのバイナリー・ファイルを使用し続けます。デフォルトは、/usr/afs/local/BosConfig ファイルで指定されているように、 BOS サーバーは、新規バイナリー・ファイルが存在するプロセスを毎日午前 5 時に再始動します。このバイナリー再始動時刻 を表示または変更するには、 BOS サーバーの再始動時を設定する の説明に従って、 bos getrestart コマンドと bos setrestart コマンドを使用します。

以下の説明にあるように、bos restart コマンドを発行することによって、ファイル・サーバー・マシンに、新規サーバー・プロセス・バイナリーを使って開始するように強制することができます。

新規コマンドの組のバイナリーをインストールするときは、プロセスを再始動する必要はありません。組のコマンドを次回発行したときは、新規バイナリーが自動的に呼び出されます。

bos install コマンドを使用すると、BOS サーバーは、自動的に現行バージョンのバイナリー・ファイルの名前に .BAK 拡張子を付けて保管します。現行の .BAK バージョンがある場合、それは .OLD バージョンに名前変更されます (.OLD バージョンがまだない場合)。現行の .OLD バージョンがある場合には、現行の .BAK バージョンがそれを置き換えるためには、 .BAK バージョンは少なくとも 7 日前のものでなければなりません。

AFS バイナリーは、/usr/afs/bin ディレクトリーに保管するのが最適です。これは、BOS サーバーが新規バイナリーの有無を自動的に検査する唯一のディレクトリーだからです。ただし、bos install コマンドの -dir 引き数を使って、サーバー・マシンのローカル・ディスク上のほかのディレクトリーに非 AFS バイナリーをインストールすることができます。詳細については、 AFS Administration Reference にあるコマンドの解説ページを参照してください。

### 新規サーバー・バイナリーをインストールするには

1. ユーザーが、/usr/afs/etc/UserList ファイルにリストされているかどうかを検証する。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. バイナリーをインストールするソース・ディレクトリーで、バイナリーが使用可能であることを検証する。マシンが AFS クライアントでもある場合は、 AFS の中央ディレクトリーからバイナリーを検索することができます。そうでない場合は、 AFS 配布媒体から直接バイナリーを取得するか、前にバイナリーをインストールしたローカル・ディスク・ディレクトリーから取得するか、または、ftp コマンドなどの転送ユーティリティーを使ってリモート・マシンから、バイナリーを取得することができます。
3. バイナリー配布マシンに bos install コマンドを発行する。 (どのマシンがその役割を実行しているかを忘れた場合は、システム・タイプに応じたバイナリー配布マシンを特定するには を参照してください。)

          % bos install <machine name> <files to install>+

   ここで、

   i
     install の受け入れ可能な最も短い省略形です。

   machine name
     バイナリー配布マシンの名前。

   files to install
     ローカルの /usr/afs/bin ディレクトリーにインストールする各バイナリー・ファイルの名前を指定します。パス名の一部は、現行作業ディレクトリーとの関連で解釈されます。それぞれのパス名 (ファイル名そのもの) の最後の要素は、置き換えるファイルの名前に一致します。たとえば、サーバー・プロセスの場合は、 bosserver または volserver、コマンドの場合は、bos または vos です。

     fs プロセス以外の各 AFS サーバー・プロセスは、単一のバイナリー・ファイルを使用します。 fs プロセスは、3 つのバイナリー・ファイルを使用します。 fileserver、volserver、および salvager です。1 つのコンポーネントの新規バージョンをインストールすることは、必然的に、 3 つすべてを置き換える必要があることを意味するわけではありません。

4. それぞれのバイナリー配布マシンについて、3 のステップを繰り返す。
5. (オプション) プロセスを再始動して新規バイナリーを即時に使用する場合は、 upclientbin プログラムがバイナリー配布マシンから新規バイナリーを検索するまで待ちます。 バイナリー・バージョン日付の表示 で説明しているように、 bos getdate コマンドを使って、バイナリー・ファイルのタイム・スタンプを検証することができます。バイナリー・ファイルがそれぞれのサーバー・マシンで使用可能になったら、 bos restart コマンドを発行します。これに関する詳細な説明は、プロセスの停止および即時の再始動 にあります。

   AFS クライアント・マシンで作業している場合には、サーバー・プロセスを再始動する前に、 bos コマンドの組のバイナリーがローカル・ディスク上にあるかどうかを検証する。通例の構成では、 bos コマンドのバイナリーを収容するクライアント・マシンの /usr/afsws/bin ディレクトリーは、 AFS へのシンボリック・リンクであり、それによってローカル・ディスク・スペースが節約されます。ただし、特定のプロセス (特に、データベース・サーバー・プロセス) を再始動すると、再始動中に問題が発生した場合は特に、AFS ファイル・スペースがアクセス不能になる可能性があります。その場合も、bos バイナリーのローカル・コピーがあれば、プロセスのバイナリーをアンインストールまたは再インストールしたり、プロセスを再始動することができます。 cp コマンドを使って、 bos コマンドのバイナリーを /usr/afsws/bin ディレクトリーから /tmp などのローカル・ディレクトリーにコピーします。

   プロセスを再始動すると、サービスの停止の原因になります。可能であれば、システムの使用率が低い時間帯に実行するのが最善です。

          % bos restart <machine name> <instances>+

### 直前のバージョンのバイナリーへの復帰

まれな例では、新規バイナリーをインストールすると、直前のバージョンに復帰する必要があるほど重大な問題を引き起こすこともあります。バイナリーをインストールする場合と同様に、一貫したシステム・パフォーマンスのためには、すべてのサーバー・マシンを同じバージョンに戻さなければなりません。ここで説明する bos uninstall コマンドを、各バイナリー配布マシンで発行します。

bos uninstall コマンドを使用すると、BOS サーバーは、現行バージョンのバイナリー・ファイルを破棄し、.BAK バージョンのファイルを、拡張子を除去してプロモートします。現行の .OLD バージョンがあれば、.BAK に名前を変更します。

現行の .BAK バージョンがない場合には、 bos uninstall コマンドのオペレーションは失敗し、エラー・メッセージが生成されます。 .OLD バージョンがまだ存在している場合は、mv コマンドを発行して、名前を .BAK に変更してから、bos uninstall コマンドを発行します。

新規バイナリーをインストールしたときと同じように、サーバー・プロセスが復帰したバージョンを使って即時に開始することはありません。現行バイナリーが機能しないために復帰している場合は、以下の指示に従って関係のあるプロセスを再始動します。

### 直前のバージョンのバイナリーに復帰するには

1. ユーザーが、/usr/afs/etc/UserList ファイルにリストされているかどうかを検証する。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. 関係のある各バイナリーの .BAK バージョンが、それぞれのバイナリー配布マシンの /usr/afs/bin ディレクトリーで使用可能であることを検証する。必要な場合は、バイナリー・バージョン日付の表示 で説明しているように、bos getdate コマンドを使用することができます。必要であれば、 .OLD バージョンを .BAK に名前変更します。
3. バイナリー配布マシンに bos uninstall コマンドを発行する。 (どのマシンがその役割を実行しているかを忘れた場合は、システム・タイプに応じたバイナリー配布マシンを特定するには を参照してください。)

          % bos uninstall <machine name> <files to uninstall>+

   ここで、

   u
     uninstall の受け入れ可能な最も短い省略形です。

   machine name
     バイナリー配布マシンの名前。

   files to uninstall
     /usr/afs/bin ディレクトリーの、.BAK バージョンと置き換える各バイナリー・ファイルの名前を指定します。 /usr/afs/bin ディレクトリーが想定されているため、ファイル名だけで十分です。
4. それぞれのバイナリー配布マシンについて、3 のステップを繰り返す。
5. 各サーバー・マシンで、upclientbin プロセスが、バイナリー配布マシンから復帰されたバージョンを検索するまで待ちます。 バイナリー・バージョン日付の表示 で説明しているように、 bos getdate コマンドを使って、バイナリー・ファイルのタイム・スタンプを検証することができます。バイナリー・ファイルがそれぞれのサーバー・マシンで使用可能になったら、 bos restart コマンドを発行します。これに関する詳細な説明は、プロセスの停止および即時の再始動 にあります。

   AFS クライアント・マシンで作業している場合には、サーバー・プロセスを再始動する前に、 bos コマンドの組のバイナリーがローカル・ディスク上にあるかどうかを検証する。通例の構成では、 bos コマンドのバイナリーを収容するクライアント・マシンの /usr/afsws/bin ディレクトリーは、 AFS へのシンボリック・リンクであり、それによってローカル・ディスク・スペースが節約されます。ただし、特定のプロセス (特に、データベース・サーバー・プロセス) を再始動すると、再始動中に問題が発生した場合は特に、AFS ファイル・スペースがアクセス不能になる可能性があります。その場合も、bos バイナリーのローカル・コピーがあれば、プロセスのバイナリーをアンインストールまたは再インストールしたり、プロセスを再始動することができます。 cp コマンドを使って、 bos コマンドのバイナリーを /usr/afsws/bin ディレクトリーから /tmp などのローカル・ディレクトリーにコピーします。

          % bos restart <machine name> <instances>+

### バイナリー・バージョン日付の表示

/usr/afs/bin ディレクトリーにあるバイナリー・ファイルの 3 つのバージョン (現行、 .BAK および .OLD バージョン) すべての、コンパイル日付を検査することができます。これは、サーバー・プロセスを再始動して新規バイナリーを使用する前に、そのバイナリー配布マシンからファイル・サーバー・マシンに、新規バイナリーがコピーされたかどうかを検証する際に役立ちます。

/usr/afs/bin 以外のディレクトリーにあるバイナリーの日付を検査するには、-dir 引き数を追加します。 AFS Administration Reference を参照してください。

### バイナリー・バージョン日付を表示するには

1. bos getdate コマンドを発行する。

          % bos getdate <machine name> <files to check>+

   ここで、

   getd
     getdate の受け入れ可能な最も短い省略形です。

   machine name
     バイナリー日付を表示するファイル・サーバー・マシンの名前を指定します。

   files to check
     表示する各バイナリー・ファイルの名前を指定します。

### 使用されないバイナリー・ファイルの削除

新規バイナリーをもつプロセスが、何日も問題なく実行されている場合は、一般に .BAK および .OLD バージョンを /usr/afs/bin ディレクトリーから除去しても安全です。それによって、クラッターを削減し、ファイル・サーバー・マシンのローカル・ディスクのスペースを解放することができます。

bos prune コマンドのフラグを使用して、以下のタイプのファイルを除去することができます。

- /usr/afs/bin ディレクトリーから .BAK 拡張子を持つファイルを除去するには、 -bak フラグを使用します。
- /usr/afs/bin ディレクトリーから .OLD 拡張子を持つファイルを除去するには、 -old フラグを使用します。
- /usr/afs/logs ディレクトリーからコアと呼ばれるファイルを除去するには、 -core フラグを使用します。
- 3 つのタイプすべてのファイルを除去するには、-all フラグを使用します。

### 古くなったバイナリーを除去するには

1. ユーザーが、/usr/afs/etc/UserList ファイルにリストされているかどうかを検証する。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. 以下の 1 つまたは複数のフラグを付けて bos prune コマンドを発行する。

          % bos prune <machine name> [-bak] [-old] [-core] [-all]

   ここで、

   p
     prune の受け入れ可能な最も短い省略形です。

   machine name
     古くなったファイルを除去するファイル・サーバー・マシンの名前を指定します。

   -bak
     /usr/afs/bin ディレクトリーから、 .BAK 拡張子を持つすべてのファイルを除去します。このフラグを -all フラグと結合しないでください。

   -old
     /usr/afs/bin ディレクトリーから、 OLD 拡張子を持つすべてのファイルを除去します。このフラグを -all フラグと結合しないでください。

   -core
     /usr/afs/logs ディレクトリーからすべてのコア・ファイルを除去します。このフラグを -all フラグと結合しないでください。

   -all
     ほかの 3 つのフラグの効果を結合します。ほかの 3 つのフラグと結合しないでください。

### バイナリー・ファイルの作成レベルの表示

サーバー・マシンおよびセル全体の最も一貫したパフォーマンスのためには、すべてのサーバー・プロセスが同じ AFS 配布から検索されるのが最適です。すべての AFS バイナリーには、そのバージョンまたは作成レベル を指定する ASCII 文字列が含まれています。それを表示するには、ほとんどの UNIX 配布に含まれている strings コマンドおよび grep コマンドを使用します。

### AFS バイナリーの作成レベルを表示するには

1. バイナリー・ファイルを収容しているディレクトリーに変更する。バイナリーがある場所がわからない場合は、 which コマンドを発行します。

          % which binary_file
          /bin_dir_path/binary_file
          % cd bin_dir_path

2. strings コマンドを発行して、バイナリー・ファイルからすべての ASCII 文字列を抽出する。出力を grep コマンドにパイプ指定し、関係のある行を特定します。

          % strings ./binary_file | grep Base

   以下の形式で AFS ビルド・レベルが出力されます。

          @(#)Base configuration afsversion  build_level

   たとえば、次の文字列は、AFS 3.6 build 3.0 のバイナリーであることを示しています。

          @(#)Base configuration afs3.6 3.0

## サーバー CellServDB ファイルの保守

あらゆるサーバー・マシンでは、そのホーム・セルのデータベース・サーバー・マシンのリストを、ローカル・ディスクにあるローカル・ディスク・ファイル /usr/afs/etc/CellServDB で保守します。データベース・サーバー・プロセスおよびデータベース以外のサーバー・プロセスのどちらも、ファイルを調べます。

- データベース・サーバー・プロセス (認証サーバー、バックアップ・サーバー、保護およびボリューム・ロケーション・サーバー) は、複写済みの管理用データベースのコピーの同期化を保持するために、ピアとの一定の交信を保守します。

  AFS 管理データベースの複写 で詳細に説明したように、データベース・サーバー・プロセスは Ubik ユーティリティーを使用して、保守するデータベース内の情報を同期化します。同期化サイトの Ubik コーディネーターは、データベースの単一の読み取り / 書き込みコピーを保守し、必要に応じて、変更を 2 次サイトに配布します。同期サイトのコーディネーターは、過半数の 2 次サイトとの交信を保守し、コーディネーターのままでいなければなりません。また、CellServDB ファイルを調べて、そのピアの数と、ピアが実行されているマシンを確認しなければなりません。

  コーディネーターがそのピアの過半数との交信を失うと、全部が協力して、多数決によって新規コーディネーターを選出します。選出中は、すべての Ubik プロセスが CellServDB ファイルを調べ、賛否表示を送信する場所と、過半数を構成する数を確認します。

- データベース以外のサーバー・プロセスは、データベースから情報を検索するために、データベース・サーバー・プロセスを実行しているマシンを知っていなければなりません。たとえば、ユーザーが AFS ファイルに初めてアクセスすると、そのファイルを収容するファイル・サーバーは保護サーバーと交信して、ユーザーのグループ・メンバーシップのリストを入手します (このリストは、現行保護サブグループ、すなわち CPS と呼ばれます)。ファイル・サーバーは、ファイルを保護しているアクセス制御リスト (ACL) が、ユーザーに必要なアクセス権を許可するかどうかを決定するときに、 CPS を使用します (詳細については、保護データベースについて を参照してください)。

CellServDB ファイルの情報の欠落や、間違った情報の結果は以下のとおりです。

- このファイルがマシンをリストしないと、たとえ、データベース・サーバー・プロセスが実行されていても、それは、実際にはデータベース・サーバー・マシンではありません。Ubik コーディネーターはそのファイルにデータベース更新を送信しないか、あるいは、過半数を確立するカウントにそのファイルを組み込みます。このファイルは、Ubik 選出に参加しません。したがって、たまたまこのファイルと交信したどんなクライアント・マシンにも、データベース情報を配布することを拒否します (/usr/vice/etc/CellServDB ファイルがマシンをリストすれば、配布できる情報です)。クライアント・マシンのユーザーは、正しく機能するデータベース・サーバー・マシンを交信できるようになる前に、タイムアウトを待たなければなりません。
- ファイルが、データベース・サーバー・プロセスを実行していないマシンをリストすると、重大な結果が生じる可能性があります。Ubik コーディネーターは、そのファイルにデータベース更新を送信することができませんが、過半数を確立するカウントにそのファイルを組み込みます。有効な 2 次サイトが終了し、コーディネーターへの賛否表示の送信を停止すると、このサイトは、コーディネーターはもう必要は過半数を得ていないと、間違った表示をする可能性があります。結果として生じる新規コーディネーターの選出は、データベースからの情報が使用できなくなる間、サービスが停止する原因になります。さらに、間違ってリストされたサイトからの賛否表示が不足することによって、過半数のサイトが新規コーディネーターに投票していないとほかのサイトが考えるために、コーディネーターの選出が妨げられる可能性があります。

  重要性が小さい結果は、データベース以外のサーバー・プロセスが、そのマシンのデータベース・サーバー・プロセスと交信しようとすることです。そのプロセスは実行されていないため、データベース以外のサーバー・プロセスは、タイムアウトの遅れを経験することになります。

サーバー・マシンにある /usr/afs/etc/CellServDB ファイルは、クライアント・マシンにある /usr/vice/etc/CellServDB ファイルとは異なります。クライアント・バージョンには、ローカル・セルのほかに、外部セルの項目が組み込まれます。ただし、ユーザーのセルのデータベース・サーバー・マシンを変更するときにはいつでも、どちらのファイルのバージョンも更新することが重要です。同時にクライアントでもあるサーバー・マシンには両方のファイルが必要であり、システム管理者はそれらの両方のファイルを更新する必要があります。CellServDB ファイルのクライアント・バージョンの保守に関する詳細については、データベース・サーバー・マシンの情報を保持する を参照してください。

### サーバー CellServDB ファイルの配布

/usr/afs/etc/CellServDB ファイルにある間違った情報の負の結果を回避するには、データベース・サーバー・マシンを追加または除去するたびに、ユーザーのセルのすべてのサーバー・マシンでその情報を更新しなければなりません。AFS インストールの手引き では、データベース・サーバー・マシンのインストールまたは除去、およびそのコンテキストにある CellServDB ファイルの更新について詳しく説明します。この機能グループでは、ユーザーのサーバー・マシンにファイルを配布する方法、および、ユーザーが AFS グローバル・ネーム・スペースに参加する場合に、変更をほかのセルに知らせる方法について説明します。

米国版の AFS を使用する場合には、更新サーバーを使用して、セルのシステム制御マシンに保管されるサーバー CellServDB ファイルの中心コピーを配布します。国際版の AFS を使用する場合には、代わりに、それぞれのサーバー・マシンにあるファイルを個々に変更します。システム制御マシンに関する詳しい説明と、インターナショナル・セルが、 /usr/afs/etc ディレクトリーにあるファイルにシステム制御マシンを使用してはいけない理由については、 システム制御マシン を参照してください。米国版の AFS を使用するときの、更新サーバーの構成については、 AFS インストールの手引き を参照してください。

エラーになる可能性があるエラーのフォーマットを回避するには、ファイルを直接編集するのではなく、いつでも bos addhost コマンドと bos removehost コマンドを使用します。また、そのマシンで実行されるデータベース・サーバー・プロセスを再始動し、データベース・サーバー・マシンの新規セット間で、コーディネーターの選出を開始しなければなりません。このステップは、CellServDB ファイルにデータベース・サーバー・マシンを追加するには および CellServDB ファイルからデータベース・サーバー・マシンを除去するには の説明に組み込まれています。ファイルのコンテンツの表示については、 セルのデータベース・サーバー・マシンを表示するには を参照してください。

AFS グローバル・ネーム・スペースのパーツとして、外部ユーザーがユーザーのセルにアクセスできるようにする場合は、ユーザーのセルのデータベース・サーバー・マシンを変更するときには、ほかのセルにも通知する必要があります。AFS サポート・グループは、 AFS グローバル・ネーム・スペースに参加するすべてのセルをリストする CellServDB ファイルを保守します。詳細については、 ユーザーのセルをほかのユーザーが見ることができるようにする を参照してください。

セルのデータベース・サーバー・マシンを公示する別の方法は、 AFS ファイル・スペースの従来の場所である、 /afs/cell_name/service/etc/CellServDB.local にファイルのコピーを保守することです。詳しくは、3 番目のレベル を参照してください。

### セルのデータベース・サーバー・マシンを表示するには

1. bos listhosts コマンドを発行する。ファイルを正しく保守した場合には、その出力はあらゆるサーバー・マシンで同じになりますが、 machine name 引き数を使用すると、希望する場合には、さまざまなマシンを検査することができます。

          % bos listhosts <machine name> [<cell name>]

   ここで、

   listh
     listhosts の受け入れ可能な最も短い省略形です。

   machine name
     /usr/afs/etc/CellServDB ファイルをそこから表示する、サーバー・マシンを指定します。

   cell name
     外部セルの完全なインターネット・ドメイン名を指定します。 machine name 引き数として提供するために、セル内の少なくても 1 つのサーバー・マシンの名前をすでに知っていなければなりません。

出力には、指定されたサーバー・マシンの CellServDB ファイルに表示される順序で、マシンをリストします。出力では、以下の例のように、それぞれのマシンに 1 つの `Host` インデックス番号を割り当てます。そのインデックスとマシンの IP アドレス、名前、または Ubik コーディネーターまたは 2 次サイトとしての役割との間に、暗黙の関係はありません。

       % bos listhosts fs1.abc.com
       Cell name is abc.com
           Host 1 is fs1.abc.com
           Host 2 is fs7.abc.com
           Host 3 is fs4.abc.com

命名サービス (ドメイン名サービスまたはローカル・ホスト・テーブルなど) が適切に機能している限りは、出力は、IP アドレスではなく名前でマシンをリストします。 IP アドレスを表示するには、ローカル・スーパーユーザー rootとして、サーバー・マシンにログインし、テキスト・エディターを使用するか、あるいは、cat コマンドなどのコマンドを表示し、 /usr/afs/etc/CellServDB ファイルを見ます。

### CellServDB ファイルにデータベース・サーバー・マシンを追加するには

1. ユーザーが、/usr/afs/etc/UserList ファイルにリストされているかどうかを検証する。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. bos addhost コマンドを発行して、それぞれの新規データベース・サーバー・マシンを、 CellServDB ファイルに追加する。米国版の AFS を使用する場合には、 machine name として、システム制御マシンを指定します。 (システム制御マシンはどれかを忘れてしまった場合には、 システム制御マシンの出力 を参照してください。) 国際版の AFS を使用する場合には、順番に machine name の名前を置き換えることによって、それぞれの、またはユーザーのセルのサーバー・マシンでこのコマンドを繰り返します。

          % bos addhost  <machine name>  <host name>+

   ここで、

   addh
     addhost の受け入れ可能な最も短い省略形です。

   machine name
     米国版の AFS を使用している場合には、システム制御マシンに名前を付けます。国際版の AFS を使用している場合には、順番に、それぞれのユーザーのサーバー・マシンに名前を付けます。

   host name
     それぞれのデータベース・サーバー・マシンの完全修飾ホスト名を指定し、 CellServDB ファイルに追加します (たとえば、fs4.abc.com)。 BOS サーバーは gethostbyname( ) ルーチンを使用して、各マシンの IP アドレスを取得し、名前とアドレスをともに自動的に記録します。
3. 認証サーバー、バックアップ・サーバー、保護サーバー、および VL サーバーをあらゆるデータベース・サーバー・マシンで再始動します。その結果、マシンの新規セットが、新規 Ubik 座標の選択に関係します。説明では、プロセスの基本名を使用し、別のプロセス名を使用する場合には、適切な置換を行います。完全な構文については、プロセスの停止および即時の再始動を参照してください。

   重要 : すべてのデータベース・サーバー・マシンで即時に引き続いて、以下のコマンドを繰り返します。

          % bos restart  <machine name> buserver kaserver ptserver vlserver

4. ユーザーのセルのクライアント・マシンごとに、/usr/vice/etc/CellServDB ファイルを編集します。説明については、データベース・サーバー・マシンの情報を保持する を参照してください。
5. AFS グローバル名スペースを共有する場合には、 AFS プロダクト・サポート・グループを使って行った変更を登録する、ユーザーのセルの指定サイト接続の 1 つを入手してください。

   ユーザーのセルのサーバー CellServDB ファイルの主要なコピーを、基本位置 (/afs/cell_name/service/etc/CellServDB.local) で保持する場合には、ファイルを編集して変更を反映させます。

### CellServDB ファイルからデータベース・サーバー・マシンを除去するには

1. ユーザーが、/usr/afs/etc/UserList ファイルにリストされているかどうかを検証する。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. bos removehost コマンドを発行して、 CellServDB ファイルから、それぞれのデータベース・サーバー・マシンを除去する。米国版の AFS を使用する場合には、 machine name として、システム制御マシンを指定します。 (システム制御マシンはどれかを忘れてしまった場合には、 システム制御マシンの出力 を参照してください。) 国際版の AFS を使用する場合には、順番に machine name の名前を置き換えることによって、それぞれの、またはユーザーのセルのサーバー・マシンでこのコマンドを繰り返します。

          % bos removehost <machine name>  <host name>+

   ここで、

   removeh
     removehost の受け入れ可能な最も短い省略形です。

   machine name
     米国版の AFS を使用している場合には、システム制御マシンに名前を付けます。国際版の AFS を使用している場合には、順番に、それぞれのユーザーのサーバー・マシンに名前を付けます。

   host name
     それぞれのデータベース・サーバー・マシンの完全修飾ホスト名を指定し、 CellServDB ファイルから除去します (たとえば、fs4.abc.com)。
3. 認証サーバー、バックアップ・サーバー、保護サーバー、および VL サーバーをあらゆるデータベース・サーバー・マシンで再始動します。その結果、マシンの新規セットが、新規 Ubik 座標の選択に関係します。説明では、プロセスの基本名を使用し、別のプロセス名を使用する場合には、適切な置換を行います。完全な構文については、プロセスの停止および即時の再始動を参照してください。

   重要 : すべてのデータベース・サーバー・マシンで即時に引き続いて、以下のコマンドを繰り返します。

          % bos restart  <machine name> buserver kaserver ptserver vlserver

4. ユーザーのセルのクライアント・マシンごとに、/usr/vice/etc/CellServDB ファイルを編集します。説明については、データベース・サーバー・マシンの情報を保持する を参照してください。
5. AFS グローバル名スペースを共有する場合には、 AFS プロダクト・サポート・グループを使って行った変更を登録する、ユーザーのセルの指定サイト接続の 1 つを入手してください。

   ユーザーのセルのサーバー CellServDB ファイルの主要なコピーを、基本位置 (/afs/cell_name/service/etc/CellServDB.local) で保持する場合には、ファイルを編集して変更を反映させます。

## 認証と許可の要件の管理

この機能グループでは、許可検査を検査し、そのクライアントと相互に認証することによって、 AFS サーバー・プロセスが、適切な許可ユーザーだけが特権コマンドを確実に実行するようにする方法について説明します。ユーザーが、マシンごとまたはセルごとをベースにして要件を検査する認証を制御できる方法と、コマンドの発行時に、相互認証をバイパスする方法についても説明します。

### 認証対許可

多くの AFS コマンドには、コマンドで呼び出される AFS サーバー・プロセスが、適切な許可ユーザーに対してだけ、特権を実行するという特権が付いています。サーバー・プロセスは、以下の 2 つのテストを実行して、適切に許可されているかどうかを決定します。

- 認証 テストで、サーバー・プロセスは、ユーザーまたはアプリケーションのために機能しているコマンド・インタープリター、キャッシュ・マネージャー、またはほかのクライアント・プロセスと、相互に認証します。このテストの目的は、コマンドの発行者を決定することです。サーバー・プロセスは、自分が発行者であると主張する人が本当の発行者であることを、サーバー・チケットと発行者のトークンのほかのコンポーネントを検査して検証します。 (次に、このテストによって、クライアント・プロセスで、そのサーバー・プロセスが本物であることを検証することができます。) 発行者がトークンを持っていないか、あるいは、別の方法でテストが失敗すると、サーバー・プロセスはその発行者に、完全に許可されていないユーザーである、 anonymous の識別を割り当てます。相互認証に関する詳細な説明については、 相互認証の詳細 を参照してください。

  多くの個々のコマンドを使用すると、相互に認証しようとしなくても、anonymous の識別を想定することによって、認証テストをう回することができます。ただし、コマンドが特権で、サーバー・プロセスがまだ認証テストを実行している場合には、これは役に立たないことに注意してください。なぜなら、このような場合には、プロセスでは、特権コマンドを anonymous ユーザーに対して実行することを拒否するからです。

- 許可 テストでは、サーバー・プロセスは、特権ユーザーのリストを調べ、発行者がコマンドの使用を許可されているかどうかを決定します。このテストの目的は、発行者に許可されていることを決定することです。管理権限の管理 で説明したように、異なるサーバー・プロセスは、異なるユーザーのリストを調べます。サーバー・プロセスは、許可されていない発行者に対してどんな特権コマンドの実行も拒否します。コマンドに特権の要件がなければ、サーバー・プロセスはこのステップをスキップし、即時に実行します。

  注: | anonymous ユーザー、または system:anyuser グループを特権リストに入れないでください。許可検査が無意味になります。 bos setauth コマンドを使用して、サーバー・マシンのサーバー・プロセスで、許可を検査するかどうかを制御することができます。ほかのサーバー・マシンは影響を受けません。許可検査をオフにすることはセキュリティー上非常に危険であることに留意してください。なぜなら、そのマシンのサーバー・プロセスは、どんなユーザーのためのどんなアクションでも実行するからです。

### サーバー・マシンでの許可検査の制御

許可検査を使用不可にすることは、セキュリティー上の重大な欠陥となります。なぜなら、anonymous ユーザーであっても、ファイル・サーバー・マシンの AFS サーバー・プロセスは、任意のユーザーのどんなアクションでも実行するからです。

許可検査を使用不可にすることが一般的なのは、ユーザーが新規ファイル・サーバー・マシンをインストールしているときだけです (AFS インストールの手引き を参照してください)。これが必要となるのは、すべての必要なセキュリティー機構の構成を、通常これを使用する他のアクションを実行する前に行うことは不可能なためです。最高の安全のためには、インストールしているマシンのコンソールで作業した後すぐに、許可検査をオンにします。

通常のオペレーション中に、許可検査を使用不可にする唯一の理由は、サーバー暗号化鍵を使ってエラーが発生した場合に、サーバーがユーザーを正しく認証できないままにしておくことです。鍵関連の緊急事態の処理に関する説明については、 サーバー暗号化鍵の緊急事態の取り扱い を参照してください。

許可検査をそれぞれのファイル・サーバー・マシンで別々に制御します。 1 つのマシンで許可検査をオンにするかまたはオフにすることは、ほかのマシンには影響を及ぼしません。一般的に、クライアント・マシンはサーバー・プロセスを無作為に選択するため、すべてのマシンの要件を同じにしなければ、ある特定のコマンドに功を奏する許可検査の条件を予測することは困難です。許可検査をセル全体に対してオン / オフにするには、適切なコマンドをあらゆるファイル・サーバー・マシンで繰り返さなければなりません。

サーバー・プロセスは、そのローカル・ディスクにあるディレクトリー /usr/afs/local を定期的にモニターし、許可を検査する必要があるかどうかを決定します。NoAuth というファイルがそのディレクトリーにあれば、サーバーは許可を検査しません。このファイルがなければ (通常の場合)、サーバーは許可検査を行います。

BOS サーバーを介して、NoAuth ファイルの存在を制御します。 bos setauth コマンドを使って許可検査を使用不可にすると (または、インストール中に、BOS サーバーを開始するコマンドに -noauth フラグを書き込むと)、 BOS サーバーは長さ 0 の NoAuth ファイルを作成します。許可検査を再度使用可能にすると、BOS サーバーはそのファイルを除去します。

### サーバー・マシンの許可検査を使用不可にする

1. ユーザーが、/usr/afs/etc/UserList ファイルにリストされているかどうかを検証する。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. bos setauth コマンドを発行して、許可検査を使用不可にします。

          % bos setauth <machine name> off

   ここで、

   seta
     setauth の受け入れ可能な最も短い省略形です。

   machine name
     サーバー・プロセスが許可を検査しないファイル・サーバー・マシンを指定します。

### サーバー・マシンの許可検査を使用可能にする

1. 許可検査を再度使用可能にする (マシンは現在許可の検査をしていないため、特権は必要はありません。) 構文の詳細については、先のセクションを参照してください。

          % bos setauth <machine name> on

### 個々のコマンドの相互認証をう回する

いくつかのサーバー・プロセスを使用すると、任意のユーザーが (システム管理者だけではなく) コマンドを発行するときに、相互認証を使用できないようにすることができます。サーバー・プロセスは、発行者を認証されていないユーザー anonymous として扱います。

相互認証を妨げる機能は、緊急事態に使用するために提供されています (サーバー暗号化鍵の緊急事態の取り扱い で説明する鍵の緊急事態など)。通常の状況では、許可検査はオンにして、認証を妨げることが無益であるようにしなければなりません。サーバー・プロセスは、特権コマンドを anonymous に対して実行することを拒否します。

許可検査をオフにしているときには、認証を止めることが有効である可能性があります。鍵の緊急事態にたまたまありがちなように、サーバーが特定の暗号化鍵を理解できないと、認証の試行という実際の行為が、問題の原因となる可能性があります。

### bos、kas、pts、および vos コマンドに対する相互認証をう回するには

組の多くのコマンドで使用可能な -noauth フラグを提供します。コマンドがフラグを受け入れるかどうかを検証するには、コマンドの組に help コマンドを発行するか、あるいは、AFS Administration Reference のコマンドの参照ページを調べます (参照ページでも、それぞれのコマンドのフラグとして受け入れ可能な最も短い省略形を指定します)。組の apropos コマンドおよび help コマンドは、フラグを受け入れません。

kas interactive コマンドに -noauth フラグを組み込むことによって、対話式セッション中に発行されるすべての kas コマンドでは、相互認証をう回することができます。認証済みの識別を使って、すでに対話モードを入力した場合には、 (kas) noauthentication コマンドを発行し、 anonymous 識別を想定します。

### fs コマンドの相互認証をう回するには

これは、fs コマンドを発行する前に、 unlog コマンドを発行して、ユーザーのトークンを破棄しない限り不可能です。

## ディスクと区分の追加または除去

既存のファイル・サーバー・マシンにディスクを追加するだけで、 AFS はユーザーのセルに記憶域を簡単に追加することができます。この機能グループでは、 AFS ボリュームを保管するために使用するディスクをインストールする方法、または除去する方法について説明します。 (AFS インストールの手引き で説明したように、記憶域を追加する別の方法は、追加のサーバー・マシンをインストールすることです。)

ディスクの追加と除去のどちらも、少なくても短時間のファイル・システムの停止の原因になります。それは、サーバー区分の新規のセットを認識させるために、 fs プロセスを再始動しなければならないからです。オペレーティング・システムには、ディスクを追加または除去する前に、マシンを止める必要があるものがあります。このような場合には、まず、すべての AFS サーバー・プロセスを終了しなければなりません。ほかのすべての点では、ディスクの追加または除去の AFS が関連した局面は、複雑ではありません。したがって、停止の期間は、主として、ディスクそのものをインストールまたは除去するのに要する時間によって異なります。

新規のディスクのインストールに関する以下の説明では、そのディスクに AFS ボリュームを収容する準備が完全に済んでいます。 vos create コマンドを使用して新規ボリュームを作成するか、あるいは、vos move コマンドを使用して、ほかの区分から既存のボリュームを移動することができます。説明については、 読み取り / 書き込みボリュームの作成 および ボリュームの移動 を参照してください。ディスクの除去に関する指示は、基本的には、インストールの指示の逆ですが、データの損失を保護する特別なステップが組み込まれます。

サーバー・マシンには、256 の AFS サーバー区分を収容することができます。ディレクトリーに取り付けられたそれぞれの区分には、/vicepindex (index は 1 または 2 文字の小文字) 形式の名前が付きます。規則では、マシン上の最初の区分は /vicepa に、 2 番目の区分は /vicepbに、という具合に進み、最後の 26 番目の区分は /vicepz に取り付けられます。追加の区分は、/vicepaa から /vicepaz に、最後は /vicepiv に取り付けられます。連続した文字を使用する必要はありませんが、その方が簡単です。

それぞれの /vicep ディレクトリーは、ほかのディレクトリーのサブディレクトリーとしてではなく、ローカル・ファイル・システムのルート・ディレクトリー ( / )の下に、直接取り付けます。たとえば、/usr/vicepa は受け入れ可能な位置ではありません。また、ファイル・サーバー・マシンのファイル・システム登録ファイル (/etc/fstab または同等のファイル) にある区分の装置名に、ディレクトリーをマップしなければなりません。

これまでの指示では、マシンの AFS 初期設定ファイルには、以下のコマンドが組み込まれ、それぞれのリブート後に、BOS サーバーを再始動することを想定しています。 BOS サーバーは、ローカル /usr/afs/local/BosConfig ファイルにリストされる、ほかの AFS サーバー・プロセスを開始します。 bosserver コマンドの任意選択の引き数については、 AFS Administration Reference のこのコマンドの参照ページを参照してください。

       /usr/afs/bin/bosserver &

### 新規ディスクを追加したり取り付けて、AFS ボリュームを収容するには

1. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

          % su root
          Password: root_password

2. 新規ディスクを分割する AFS 区分の数と、その区分を取り付けるディレクトリーの名前を決めます (この機能グループの概要で、命名規則について説明しています)。既存のサーバー区分をマシンに表示するには、 vos listpart コマンドを発行します。ローカル・スーパーユーザー root としてログインするので -localauth フラグを付けますが、管理トークンは必ずしも必要ではありません。

          # vos listpart <machine name> -localauth

   ここで、

   listp
     listpart の受け入れ可能な最も短い省略形です。

   machine name
     ローカル・ファイル・サーバー・マシンに命名します。

   -localauth
     ローカルの /usr/afs/etc/KeyFile ファイルからの鍵を使用して、サーバー・チケットを構成します。相互の認証中に、bos コマンド・インタープリターが、サーバー・チケットを BOS サーバーに提示します。
3. 区分を取り付ける場所にそれぞれのディレクトリーを作成する。

          # mkdir /vicepx[x]

4. テキスト・エディターを使用して、それぞれの新規ディスク区分ごとに、マシンのファイル・システム登録ファイル (/etc/fstab または同等のファイル) に項目を作成し、直前のステップで作成したディレクトリーにその装置名をマップします。そのファイルにある既存の項目を参照して、オペレーティング・システムによって異なる、適切な形式を確認します。
5. オペレーティング・システムで、マシンをシャットオフして新規ディスクをインストールする必要がある場合には、bos shutdown コマンドを発行して、 BOS サーバー以外のすべての AFS サーバー・プロセスを終了します (マシンをシャットオフすると、BOS サーバーは安全に終了します)。ローカル・スーパーユーザー root としてログインするので -localauth フラグを付けますが、管理トークンは必ずしも必要ではありません。コマンドの詳細な説明は、プロセスを一時停止させる方法 を参照してください。

          # bos shutdown <machine name> -localauth [-wait]

6. 必要な場合には、マシンをシャットオフします。ディスクとオペレーティング・システムの取引先が提供する指示に従って、新規ディスクをインストールし形式設定します。必要な場合には、ディスクの区分表を編集し、ファイル・システム登録ファイルに加えた変更を、 4のステップで反映させます。指示については、オペレーティング・システムの資料を調べてください。
7. 6 のステップでマシンをシャットオフした場合には、そのマシンをオンにする。そうでない場合には、bos restart コマンドを発行して、 fs プロセスを再始動し、サーバー区分の新規セットを認識させます。ローカル・スーパーユーザー root としてログインするので -localauth フラグを付けますが、管理トークンは必ずしも必要ではありません。bos restart コマンドに関する詳細は、 プロセスの停止および即時の再始動 を参照してください。

          # bos restart <machine name>  fs -localauth

8. bos status コマンドを発行して、すべてのサーバー・プロセスが正しく実行されているかどうかを検証する。詳細については、BosConfig ファイルのプロセス状況および情報の表示 を参照してください。

          # bos status <machine name>

### AFS ボリュームを収容しているディスクを取り外したり、除去するには

1. ユーザーが、/usr/afs/etc/UserList ファイルにリストされているかどうかを検証する。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. ボリュームを除去するか、あるいはほかの区分に移動する準備として、 vos listvol コマンドを発行し、ユーザーが除去しようとしているそれぞれのディスクのそれぞれの区分に収容されるボリュームをリストします。詳細については、ボリューム・ヘッダーの表示 を参照してください。

          % vos listvol <machine name> [<partition name>]

3. ファイル・システムに保存したい任意のボリュームを、別の区分に移動する。読み取り / 書き込みボリュームのみ移動可能です。詳細と、読み取り専用およびバックアップ・ボリュームの移動に関する指示については、ボリュームの移動 を参照してください。

          % vos move <volume name or ID>  \
              <machine name on source>  <partition name on source>  \
              <machine name on destination>  <partition name on destination>

4. (オプション) 保持したくないボリュームがある場合には、 vos dump コマンドまたは AFS バックアップ・システムを使用して、それらのボリュームをバックアップする。 ボリュームのダンプおよび復元 または データのバックアップ をそれぞれ参照してください。
5. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

          % su root
          Password: root_password

6. umount コマンドを発行します。除去するディスクにあるそれぞれの区分ごとにこのコマンドの発行を繰り返します。

          # cd /
          # umount /dev/<partition_block_device_name>

7. テキスト・エディターを使用して、マシンのファイル・システム登録ファイル (/etc/fstab または同等のファイル) から、それぞれの区分の項目を除去するか、またはコメント化する。
8. それぞれの区分に関連した /vicep ディレクトリーを除去する。

          # rmdir /vicepxx

9. オペレーティング・システムで、マシンをシャットオフしてディスクを除去する必要がある場合には、 bos shutdown コマンドを発行して、 BOS サーバー以外のすべての AFS サーバー・プロセスを終了します (マシンをシャットオフすると、BOS サーバーは安全に終了します)。ローカル・スーパーユーザー root としてログインするので -localauth フラグを付けますが、管理トークンは必ずしも必要ではありません。コマンドの詳細な説明は、プロセスを一時停止させる方法 を参照してください。

          # bos shutdown <machine name> -localauth [-wait]

10. 必要な場合には、マシンをシャットオフします。ディスクとオペレーティング・システムの取引先が提供する指示に従って、ディスクを除去します。必要な場合には、ディスクの区分表を編集し、ファイル・システム登録ファイルに加えた変更を、 7 のステップで反映させます。指示については、オペレーティング・システムの資料を調べてください。
11. 10 のステップでマシンをシャットオフした場合には、そのマシンをオンにする。そうでない場合には、bos restart コマンドを発行して、 fs プロセスを再始動し、サーバー区分の新規セットを認識させます。ローカル・スーパーユーザー root としてログインするので -localauth フラグを付けますが、管理トークンは必ずしも必要ではありません。bos restart コマンドに関する詳細は、 プロセスの停止および即時の再始動 を参照してください。

           # bos restart <machine name>  fs -localauth

12. bos status コマンドを発行して、すべてのサーバー・プロセスが正しく実行されているかどうかを検証する。詳細については、BosConfig ファイルのプロセス状況および情報の表示 を参照してください。

           # bos status <machine name>

## サーバー IP アドレスおよび VLDB サーバー項目の管理

マルチホーム・ファイル・サーバーに対する AFS のサポートはほとんどが自動的に行われます。ファイル・サーバー・プロセスは、そのファイル・サーバー・マシンのネットワーク・インターフェースの IP アドレスをローカルの /usr/afs/local/sysid ファイルに記録し、これらをボリューム・ロケーション・データベース (VLDB) の サーバー項目 に登録します。 sysid ファイルおよびサーバー項目は、同じ固有番号により識別され、これにより両者間の関連が作成されます。

キャッシュ・マネージャーがボリューム・ロケーション情報を要求すると、ボリューム・ロケーション (VL) サーバーは、ボリュームを含む各サーバー・マシンに対して登録されているインターフェースをすべて戻します。これにより、キャッシュ・マネージャーがマルチホーム・ファイル・サーバー・マシンに保管された AFS データにアクセスする際、複数アドレスを使用することができます。

ファイル・サーバーが VLDB サーバー項目にどのインターフェースを登録するか制御するのであれば、ローカル /usr/afs/local ディレクトリーに NetInfo および NetRestrict の 2 つのファイルを作成することにより制御が可能です。ファイル・サーバーは再始動するたびに NetInfo ファイルがこれが存在する場合にこれを読み取り、ローカル・マシンのインターフェースのリストを作成します。ファイルを作成しない場合には、ファイル・サーバーはオペレーティング・システムによって構成されたネットワーク・インターフェースのリストを使用します。その上でファイル・サーバーは、NetRestrict ファイルがある場合には、そのリストのアドレスを削除します。ファイル・サーバーは、sysid ファイルに結果リストを記録し、これと同じ固有 ID を持つ VLDB サーバー項目にインターフェースを登録します。

データベース・サーバー・マシンにおいては、NetInfo および NetRestrict ファイルはまた、他のデータベース・サーバー・マシンで実行されているデータベース・サーバー・プロセスと通信する際に Ubik データベース同期ライブラリーが使用するインターフェースを決定します。

各サーバー項目には、最大数の IP アドレスが存在します (AFS Release Notesを参照)。マルチホーム・ファイル・サーバー・マシンのインターフェースがこの最大数より多ければ、 AFS は超過分を無視します。このようなマシンについては、NetInfo および NetRestrict ファイルを使用して、どのインターフェースを登録するか制御するとよいでしょう。

何らかの理由により sysid ファイルがなくなった場合には、ファイル・サーバーは新規の固有 ID の新規ファイルを作成します。ファイル・サーバーが新規ファイルの内容を登録する際、ボリューム・ロケーション (VL) サーバーは通常、新規ファイルが既存のサーバー項目に対応することを自動的に認識し、既存のサーバー項目を新規ファイル内容および ID で上書きします。ただし、sysid ファイルを削除しなくて済むのであれば、削除しない方がよいでしょう。

同様に、ファイル・サーバー・マシン間で sysid ファイルをコピーしないでください。新規のファイル・サーバー・マシンをインストールする作業の一部として、既存のマシンの /usr/afs ディレクトリーの内容を普通にコピーするのであれば、新規マシンの /usr/afs/local ディレクトリーから sysid ファイルを削除してからファイル・サーバーを開始するようにしてください。

既存のサーバー項目を新規 sysid ファイルの内容および ID で上書きしてよいか VL サーバーが判別できない場合があります。VL サーバーはこの場合、ファイル・サーバーがインターフェースを登録できないようにし、ファイル・サーバーは開始できません。これはたとえば、新規 sysid ファイルに、現在別々のサーバー項目に登録されている 2 つのインターフェースが含まれる場合に起こります。このような場合、VL サーバー・マシンの /usr/afs/log/VLLog ファイルおよびファイル・サーバー・マシンの /usr/afs/log/FileLog ファイルにあるエラー・メッセージが、vos changeaddr コマンドを使用して問題を解決する必要があることを示します。指示および支援については、AFS プロダクト・サポート・グループにご連絡ください。

このようにまれな場合を除き、vos changeaddr コマンドの適切な使用法としては、ファイル・サーバー・マシンをサービスから削除する場合に VLDB サーバー項目を完全に削除する場合があります。VLDB は、最大数のサーバー項目を含むことができます (AFS Release Notesを参照)。使用されない項目を削除することにより、新規サーバー・マシンに必要なサーバー項目を割り当てることができます。以下の説明を参照してください。

VLDB サーバー項目に登録されたインターフェースのリストを変更するのに vos changeaddr コマンドを使用しないでください。ファイル・サーバー・マシンの IP アドレスおよびサーバー項目を変更するには、以下の説明を参照してください。

### サーバーの NetInfo ファイルを作成または編集する

1. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

          % su root
          Password: root_password

2. テキスト・エディターを使用して、/usr/afs/local/NetInfo ファイルをオープンします。各行に小数点付き 10 進数の IP アドレスを配置します (たとえば、`192.12.107.33`)。項目はどのような順序でもかまいません。
3. 変更したリストを使用してすぐにファイル・サーバーを開始するには、 bos restart コマンドを使用して fs プロセスを再始動します。説明については、 プロセスの停止および即時の再始動 を参照してください

### サーバーの NetRestrict ファイルを作成または編集する

1. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

          % su root
          Password: root_password

2. テキスト・エディターを使用して、/usr/afs/local/NetRestrict ファイルをオープンします。各行に小数点付き 10 進数の IP アドレスを配置します。アドレスはどのような順序でもかまいません。そのフィールドで可能なすべてのアドレスを表すワイルドカードには、値 255 を使用します。たとえば `192.12.105.255` と入力した場合、キャッシュ・マネージャーは、192.12.105 サブネットのいずれのアドレスも登録しません。
3. 変更したリストを使用してすぐにファイル・サーバーを開始するには、 bos restart コマンドを使用して fs プロセスを再始動します。説明については、 プロセスの停止および即時の再始動 を参照してください

### VLDB のすべてのサーバー項目を表示する

1. VLDB のすべてのサーバー項目を表示するには、vos listaddrs コマンドを発行します。

          % vos listaddrs

   lista は、 listaddrs の受け入れ可能な最も短い省略形です。

   出力の各行にはすべての VLDB サーバー項目がそれぞれ表示されます。マルチホーム・ファイル・サーバーの場合には、その登録済みアドレスがすべて行に表示されます。最初のアドレスは、vos examine および vos listvldb コマンドの出力でボリュームのサイトとして報告されたアドレスです。

   VLDB サーバー項目は IP アドレスを記録し、コマンド・インタープリターは、ローカル名サービス (ドメイン・ネーム・サービスなどのプロセス、またはローカル・ホスト・テーブルのいずれか) によりアドレスをホスト名に変換してからこれを表示します。出力に IP アドレスが表示される場合は、これを変換することができないためです。

   項目が存在する場合でも、これは必ずしもマシンが活動状態のファイル・サーバー・マシンであるとは限りません。使用されないサーバー項目を削除するには、以下の説明を参照してください。

### VLDB から使用されないサーバー項目を削除する

1. ユーザーが、/usr/afs/etc/UserList ファイルにリストされているかどうかを検証する。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. VLDB からサーバー項目を削除するには、vos changeaddr コマンドを発行します。

          % vos changeaddr <original IP address> -remove

   ここで、

   ch
     changeaddr の受け入れ可能な最も短い省略形です。

   original IP address
     現在 VLDB に登録されているファイル・サーバー・マシンの IP アドレスを 1 つ指定します。マルチホーム・ファイル・サーバーは、そのいずれのアドレスでも識別ができます。

   -remove
     サーバー項目を削除します。

### サーバー・マシンの IP アドレスを変更する

1. ユーザーが、/usr/afs/etc/UserList ファイルにリストされているかどうかを検証する。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. マシンがシステム制御マシン、またはバイナリー配布マシンであり、またそのホスト名も変更しようとする場合は、他のサーバー・マシンの関連 upclient プロセスを再定義して、新規ホスト名が参照できるようにします。bos delete および bos create コマンドを使用します (プロセスの作成および除去 を参照)。
3. マシンがデータベース・サーバー・マシンであれば、セル内の各サーバー・マシンの /usr/afs/etc/CellServDB ファイルにある項目を編集し、新規 IP アドレスのうちの 1 つを表示します。 AFS 米国版を使用している場合は、システム制御マシン上のファイルを編集することができます。更新サーバーがすべてのサーバー・マシンに変更ファイルを配布する間 (デフォルトで 5 分間) 待ちます。
4. マシンがデータベース・サーバー・マシンの場合、bos shutdown コマンドを発行してすべてのサーバー・プロセスを停止します。マシンがファイル・サーバーでもある場合は、この間そのボリュームにはアクセスすることができません。コマンドの詳細な説明は、プロセスを一時停止させる方法 を参照してください。

          % bos shutdown <machine name>

5. マシンの IP アドレスを変更するには、オペレーティング・システムに提供されているユーティリティーを使用します。
6. 必要があれば、/usr/afs/local/NetInfo ファイル、または /usr/afs/local/NetRestrict ファイル (あるいはその両方) を編集して、変更したアドレスが反映されるようにします。本節のはじめにある説明に従ってください。
7. マシンがデータベース・サーバー・マシンの場合、bos restart コマンドを発行してマシンのすべてのサーバー・プロセスを再始動します。 bos restart コマンドに関する詳細は、 プロセスの停止および即時の再始動 を参照してください。

          % bos restart <machine name> -all

   同時に、セル内の他のすべてのデータベース・サーバー・マシンで bos restart コマンドを発行し、データベース・サーバー・プロセスのみ (認証、バックアップ、保護、およびボリューム・ロケーション・サーバー) を再始動します。コマンドが連続して発行できるようにし、すべてのデータベース・サーバー・プロセスが起動できるようにします。

          % bos restart <machine name> kaserver buserver ptserver vlserver

   セル内のそれぞれのデータベース・サーバー・マシンの IP アドレスを変更する場合は、セル内のそれぞれのファイル・サーバー・マシンで bos restart コマンドを発行して fs プロセスを再始動します。

8. マシンがデータベース・サーバー・マシンでなければ、bos restart コマンドを発行して fs プロセスを再始動します (マシンがデータベース・サーバー・マシンであれば、プロセスは前のステップで開始済みです)。ファイル・サーバーは自動的にインターフェースの新規リストをコンパイルし、これを /usr/afs/local/sysid ファイルに記録して、 VLDB サーバー項目に登録します。

          % bos restart <machine name> fs

9. マシンがデータベース・サーバー・マシンであれば、セル内の各クライアント・マシンの /usr/vice/etc/CellServDB ファイルにある項目を編集し、新規 IP アドレスのうちの 1 つを表示します。説明は、データベース・サーバー・マシンの情報を保持する を参照してください。
10. 保護データベースにマシンの以前の IP アドレスのマシン項目がある場合は、 pts rename コマンドを使用して新規アドレスに変更します。説明については、 保護データベース項目の名前の変更 を参照してください

## サーバー・マシンのリブート

適切なコマンドをコンソールで入力するか、または、リモート・マシンで bos exec コマンドを発行するかのいずれかによって、サーバー・マシンをリブートすることができます。ユーザーは現在の場所を離れる必要がないため、リモートのリブートが便利かもしれませんが、コンソールでできるように、リブートの進行追跡することはできません。サーバー・マシンのオペレーティング・システムが BOS サーバーを認識しているため、リモートのリブートは可能です。 BOS サーバーは、ローカル・スーパーユーザーrootとして、 bos exec コマンドを実行します。

サーバー・マシンをリブートすることは、いくつかのセルのルーチン保守の一部で、 AFS の資料の指示には、1 つのステップとして組み込まれています。リブートは、 AFS が関連した問題から回復するための標準メソッドであることを意図したものではないのは確かですが、マシンの反応が鈍いときや、ほかのすべての理にかなったオプションを試行したときの、唯一の最後の手段です。

リブートは、サービスの停止の原因になります。マシンにボリュームが保管されている場合には、リブートが完了し、ファイル・サーバーが再接続されるまで、そのすべてのボリュームにはアクセスできなくなります。そのマシンがデータベース・サーバー・マシンである場合には、それぞれのデータベース・サーバー・プロセスごとに同期化サイトを再選出している間は、そのデータベースからの情報は使用できなくなります。一般的には、VL サーバーの停止は、最大の影響を及ぼします。それは、キャッシュ・マネージャーが AFS データを取り出すためには、 VLDB にアクセスできなければならないからです。

規則では、サーバー・マシンの AFS 初期設定ファイルには、それぞれがリブートした後に、 BOS サーバーを再始動するための以下のコマンドが組み込まれています。 BOS サーバーは、ローカルの /usr/afs/local/BosConfig ファイルにリストされるほかの AFS サーバー・プロセスを開始します。これらの指示は、初期設定ファイルに以下のコマンドが組み込まれていることを想定しています。

       /usr/afs/bin/bosserver &

### コンソールからのファイル・サーバー・マシンのリブート

1. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

          % su root
          Password: root_password

2. bos shutdown コマンドを発行して、 BOS サーバー以外のすべての AFS サーバー・プロセス終了する。 BOS サーバーは、ユーザーがマシンを終了すると、安全に終了します。ローカル・スーパーユーザー root としてログインするので -localauth フラグを付けますが、管理トークンは必ずしも必要ではありません。コマンドの詳細な説明は、プロセスを一時停止させる方法 を参照してください。

          # bos shutdown <machine name> -localauth [-wait]

3. マシンをリブートする。多くのシステム・タイプでは、適切なコマンドは shutdown でが、オプションは異なる場合があります。UNIX 管理者の手引きを参照してください。

          # shutdown

### リモートでファイル・サーバー・マシンをリブートするには

1. ユーザーがリブートしているマシンの /usr/afs/etc/UserList ファイルに、ユーザーがリストされているかどうかを検証する。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. bos shutdown を発行して、BOS サーバー以外の AFS サーバー・プロセスを停止する。 BOS サーバーは、マシンをオフにすると安全に終了します。コマンドの詳細な説明は、プロセスを一時停止させる方法 を参照してください。

          % bos shutdown <machine name>  [-wait]

3. bos exec コマンドを発行して、マシンをリモートでリブートする。

          % bos exec <machine name> reboot_command

   ここで、

   machine name
     リブートするファイル・サーバー・マシンを命名します。

   reboot_command
     マシンのオペレーティング・システムのためのリブート・コマンドです。多くのシステム・タイプでは、適切なコマンドは shutdown ですが、オペレーティング・システム資料を参照してください。

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

(C) IBM Corporation 2000. All Rights Reserved