FNS の問題と対策

この節では、問題と共に、考えられる原因、診断、対策を示します。

FNS エラーについての一般的な情報については、「FNS エラーメッセージ」と付録 B 「エラーメッセージ」 を参照してください。

初期コンテキストが取得できない

「症状」

「Cannot obtain initial context」というメッセージが表示されます。

「考えられる原因」

インストール時の問題により発生します。

「診断」

/usr/lib/fn/fn_ctx_initial.so というファイルを検索し、FNS が正しくインストールされているかどうかを確認します。

「対策」

fn_ctx_initial.so ライブラリをインストールします。

初期コンテキストが空になっている

「症状」

fnlist を実行して初期コンテキストの内容を確認すると何も表示されないという状態です。

「考えられる原因」

NIS+ の設定によって起こる問題です。fn* コマンドを実行するユーザーやマシンに関連した組織に、ctx_dir ディレクトリがないことが原因です。

「診断」

nisls コマンドを使用して ctx_dir ディレクトリの有無を確認します。

「対策」

診断の結果 ctx_dir ディレクトリがなければ、fncreate -t org/nis+_domain_name/ を実行して作成します。

「no permission」というメッセージが表示される (FNS)

「症状」

「no permission」というメッセージが表示されます。

「考えられる原因」

このメッセージは、「コマンドを実行しようとしたが、アクセス権がない」ということを意味します。

「診断」

適切な NIS+ コマンドを使用してアクセス権を確認します (「FNS と NIS+ の詳細情報」を参照)。NIS+ 主体名は、nisdefaults コマンドで知ることができます。

また、使用している名前が正しいかどうかも確認する必要があります。たとえば、ルート組織のコンテキスト名は、org// を使用して決定します。ルート組織を操作する権限があるかどうか確認してください。myorgunit/ を指定する場合もあります。

「対策」

アクセス権が正しく設定されているにもかかわらずこのメッセージが表示される場合は、適切な資格が与えられていない可能性があります。

これには以下の原因が考えられます。

• keylogin が実行されていない (NIS+ 主体はデフォルトでは「未認証」になる)

• NIS+ 以外のソースに対して keylogin が実行された

  • /etc/nsswitch.conf ファイルに publickey: nisplus エントリがあるかどうか確認する

  • これはおそらく認証エラーとなる

fnlist で下位組織のリストが表示されない

「症状」

fnlist に組織名を指定して実行しても何も表示されません。

「考えられる原因」

NIS+ の設定によって発生する問題です。下位組織は NIS+ ドメインでなければなりません。NIS+ ドメインには、org_dir というサブディレクトリが必要です。

「診断」

nisls コマンドを使用して、どんなサブディレクトリが存在するかを調べます。nisls をサブディレクトリごとに実行すれば、どのサブディレクトリに org_dir があるかを確かめることができます。org_dir のあるサブディレクトリが下位組織になります。

「対策」

NIS+ ドメインに、org_dir というサブディレクトリを作成します。

ホストコンテキストまたはユーザーコンテキストが作成できない

「症状」

fncreate -t を、user (または username)、または host (または hostname) を指定して実行しても何も起こりません。

「考えられる原因」

NIS_GROUP 環境変数が設定されていません。ユーザーコンテキストあるいはホストコンテキストを作成した際、所有権が名前空間を設定した管理者ではなく、ホストまたはユーザーにあったようです。したがって、fncreate を実行するには、NIS_GROUP 変数を設定して、グループ内の管理者によってコンテキストの操作が行えるようにする必要があります。

「診断」

NIS_GROUP 環境変数をチェックします。

「対策」

NIS_GROUP 環境変数に、コンテキストの管理者のグループ名を設定します。

作成したコンテキストを削除できない

「症状」

ホストコンテキストまたはユーザーコンテキストに対して fndestroy を実行しても、コンテキストが削除されません。

「考えられる原因」

ホストコンテキストまたはユーザーコンテキストの所有権を持っていないことです。ユーザーコンテキストあるいはホストコンテキストを作成した際、所有権が名前空間を設定した管理者ではなく、ホストまたはユーザーにあったようです。

「診断」

NIS_GROUP 環境変数をチェックします。

「対策」

NIS_GROUP 環境変数に、コンテキストの管理者のグループ名を設定します。

fnunbind を実行すると「name in use」というメッセージが表示される

「症状」

バインデイングを削除しようとすると、「name in use」というメッセージが表示されます。指定する名前によってコマンドが正しく実行される場合と、そうでない場合があります。

「考えられる原因」

コンテキストの名前のバインドを解除できません。この制限は、名前のないコンテキスト (orphaned context) が残るような場合に適用されます。

「診断」

fnlist コマンドを実行し、fnunbind に指定しようとする名前がコンテキストのものかどうか確認します。

「対策」

名前がコンテキストのものであれば、fndestroy コマンドを使用してコンテキストを削除します。

fnbind/fncreate -s を実行すると「name in use」というメッセージが表示される

「症状」

-s オプションをつけて fnbind および fncreate を実行すると、指定する名前によっては「name in use」というメッセージが表示されます。

「考えられる原因」

fnbind -s、および fncreate -s を実行すると、既存のバインディングは上書きされます。ただしそれによって orphaned context ができるような場合、「name in use」というエラーメッセージが表示され、この操作は失敗します。

「診断」

fnlist コマンドを実行して、fnbind、fncreate に指定しようとする名前がコンテキストのものかどうか確認します。

「対策」

fndestroy コマンドを実行してコンテキストを削除してから、fnbind または fncreate を (先にエラーになった場合と同じ名前を指定して) 実行します。

実体のない名前を指定して fndestroy / fnunbind を実行しても「Operation Failed」が返らない

「症状」

実体のない名前を指定して fndestroy、fnunbind を実行しても、操作が失敗したことがまったく知らされない。

「考えられる原因」

fndestroy、fnunbind のセマンティクスが、「端末名がバインドされていなくても、操作が success を返す」というようになっているためだと考えられます。

「診断」

問題が発生した場合と同じ名前を指定して fnlookup コマンドを実行します。「name not found」というメッセージが表示されるはずです。

「対策」

考えられる現象を参照。