パート III では NIS+ の名前空間の管理方法を説明します。
この章では、NIS+ 資格とその管理方法について説明します。
NIS+ セキュリティタスクの中には、可能であれば Solstice AdminSuite ツールを使用した方が簡単に実行できるものがあります。
NIS+ 資格は、NIS+ のユーザーを識別するために使用します。この章では、NIS+ セキュリティシステム全体と、特にシステムで資格が果たす役割について、十分理解しているユーザーを想定しています。
これらタスクを実行するのに使われるコマンドの構文、オプションなどの詳細は、NIS+ のマニュアルを参照してください。
この章の DES 資格の説明は、192 ビット Diffie - Hellmaun DES 資格に適用することができます。これらは似てはいますが、その他の鍵の長さを使用した認証は細部では異なっています。コマンド行インタフェースを使用して鍵を操作するときは、その違いはユーザーにもシステム管理者にも意識されることはありません。指定した鍵の長さの表示や設定は nisauthconf(1M) を使って行います。
この章では、NIS+ のコマンド一式を使用してクライアント情報を作成する方法について説明します。
資格および認証システムは、誰かが本人以外のユーザーになりすますのを防ぐシステムです。あるマシンの root 権限で su コマンドを使って、ログインしていないもしくは別のマシンにログインしている第 2 のユーザーになりすまし、第 2 のユーザーの NIS+ アクセス権を使用して NIS+ オブジェクトにアクセスすることを防ぎます。
NIS+ には、他人のユーザーログインパスワードを知っている者が、そのユーザーになりすましてユーザー ID と NIS+ アクセス権を使用することを妨げることはできません。また root 権限を持つユーザーが同一マシンからログインしている別のユーザーになりすますのを防ぐこともできません。
NIS+ 名前空間のセキュリティ保全のために、NIS+ 資格および認証機能がどのように承認およびアクセス権を使用するかについては、第 6 章「セキュリティの概要」を参照してください。
DES 資格をどのように作成しそれがどのように機能するのかを理解するには、実際の資格と資格を作成しチェックするのに使われる情報とを区別する必要があります。
「資格情報」
DES 資格を作成するのに使われるデータであり、サーバーが当該資格をチェックするのに使われる
「DES 資格」
主体を認証するために、主体からサーバーへ渡される一連の数字。主体が NIS+ 要求を行うたびに作成されチェックされる。実際の DES 資格については、「DES 資格の詳細」を参照
資格および認証プロセスを機能させるには、次の要素が必要です。
「主体の DES 資格情報」
この情報は各主体に NIS+ 管理者が最初に作成します。この情報は主体のホームドメインの cred テーブルに格納されます。主体の DES 資格情報は次のもので構成されます。
「主体名」
ユーザーの完全ログイン ID もしくはマシンの完全ホスト名
「主体の Secure RPC ネット名」
各主体はユニークな Secure RPC ネット名を持っています (Secure RPCネット名の詳細は、「DES 資格の Secure RPC ネット名」を参照)
「主体の公開鍵」
「主体の非公開暗号鍵」
「主体の LOCAL 資格」
「サーバーの公開鍵」
各ディレクトリオブジェクトには、当該ドメインのすべてのサーバーの公開鍵の複製が格納されています。cred テーブルには各サーバーの DES 資格も格納されていることに注意してください。
「主体の公開鍵のキーサーバーの複製」
キーサーバーは、その時点でログインしている主体 (ユーザーまたはマシン) の公開鍵の複製を持っています。
承認プロセスには 3 つのフェーズがあります。
「準備フェーズ」
NIS+ 管理機能がユーザーのログインに先立って行う設定動作。たとえば、ユーザーのための資格情報を作成
「ログインフェーズ」
ユーザーがログインした時にシステムが行う動作
「要求フェーズ」
NIS+ 主体が、NIS+ サービスもしくは NIS+ オブジェクトに要求を発する時にソフトウェアが行う動作
これら 3 つのフェーズの詳細は、次の項目を参照してください。
NIS+ 管理者がユーザーに資格情報を作成する最も容易な方法は、『Solaris ネーミングの設定と構成』に述べられている、nisclient スクリプトを使う方法です。この節では、NIS+ のコマンド一式を使用してクライアント情報を作成する方法について説明します。
NIS+ 主体がログインする前に、NIS+ 管理者は当該主体 (ユーザーまたはマシン) のための資格情報を作成する必要があります。管理者は次のようにする必要があります。
各主体の公開鍵と非公開暗号鍵を作成します。これらの鍵は主体のホームドメインの cred テーブルに格納されます。これは nisaddcred コマンドを使って行われます (「NIS+ 主体の資格情報を作成する方法」を参照)。
サーバーの公開鍵を作成します (「公開鍵の更新」を参照)。
主体がシステムにログインする時、次のステップが自動的に実行されます。
主体のために keylogin プログラムが起動します。keylogin プログラムは cred テーブルから主体の非公開暗号鍵を取得し、主体のログインパスワードを使って復号化します。
主体のログインパスワードが Secure RPC パスワードと異なる場合、keylogin コマンドはパスワードを復号化できず、「cannot decrypt」などのエラーとなるか、メッセージなしでコマンドが失敗します。この問題の解説は、「Secure RPC パスワードとログインパスワードの問題」を参照してください。
復号化された主体の非公開暗号鍵は、要求フェーズでの利用に備えてキーサーバーに渡され格納されます。
復号化された非公開暗号鍵はユーザーが keylogout コマンドを実行するまでキーサーバーに格納されます。ユーザーが keylogout を実行せずにログアウトした (またはログアウトせずに帰宅してしまった) 場合には、復号化された非公開鍵がサーバーに格納されたままになっています。もしユーザーマシンの root 権限を持った誰かがユーザーログイン ID に su コマンドを使った場合、その人間はユーザーの復号化された非公開鍵を使用でき、ユーザーのアクセス承認を使って NIS+ オブジェクトにアクセスできることになります。このような事態を避けるため、ユーザーが業務を終了する時は確実に keylogout コマンドを使ってログアウトするように注意する必要があります。同様にもしユーザーがログオフする場合は、業務に戻る時はログバックするだけで良いのです。もしユーザーが確実にログオフしなかった場合、業務に戻る時に確実に keylogin を実行する必要があります。
NIS+ 主体の要求が NIS+ オブジェクトにアクセスするつど、その主体を認証するために NIS+ ソフトウェアは複数段階のプロセスを実行します。
NIS+ はオブジェクトドメインの cred テーブルをチェックします。
もし主体が LOCAL 資格情報を持っていた場合、LOCAL 資格にあるドメイン情報を使い、主体のホームドメイン cred テーブルを見つけます。ここでは必要な情報を獲得します。
もし主体が資格情報を持っていなかった場合、残りのプロセスは実行されず、主体の承認アクセスクラスには未認証クラスが与えられます。
ユーザーのホームドメインの cred テーブルから、NIS+ がユーザーの DES 資格を取得します。ユーザーパスワードを使って非公開暗号鍵が復号化され、キーサーバーに格納されます。
キーサーバーが、主体の復号化された非公開鍵とオブジェクトのサーバー (オブジェクトが格納されているサーバー) の公開鍵を使って、「共通鍵」を作成します。
共通鍵を使って暗号化された「DES 鍵」が作成されます。これは、Secure RPC が乱数を発生させ、これを共通鍵を使って暗号化することで行われます。このため、DES 鍵は「乱数鍵」もしくは「乱数 DES 鍵」として参照される場合があります。
NIS+ が 15 秒のタイムウィンドウ (DES 鍵を使って暗号化される) を作成します。この「ウィンドウ」はタイムスタンプとサーバーの内部クロックとの間で許容される最長時間になります。
NIS+ が主体の DES 資格を作成します。これは次のもので構成されます。
主体の cred テーブルに基づく Secure RPC ネット名
(unix.identifier@domain)
キーサーバーから得た暗号化された主体の DES 鍵
暗号化されたタイムスタンプ
暗号化されたタイムウィンドウ
NIS+ が NIS+ オブジェクトの格納されているサーバーに次の情報を渡します。
アクセス要求
主体の DES 資格
ウィンドウ判定子 (暗号化済)。ウィンドウ判定子は暗号化されたウィンドウに 1 を加えたもの
オブジェクトのサーバーがこの情報を受信します。
オブジェクトのサーバーが、資格の中の Secure RPC ネット名の一部を使って、主体のホームドメインにある cred テーブル内にある主体の公開鍵をチェックします
サーバーが主体の公開鍵とサーバーの非公開鍵を使ってもう一度共通鍵を作成します。この共通鍵は主体の非公開鍵とサーバーの公開鍵を使って作成されている共通鍵と一致する必要があります。
共通鍵を使って、主体の資格の一部として受信している DES 鍵を暗号化します。
サーバーが、新しく復号化した DES 鍵を使って主体のタイムスタンプを復号化し、ウィンドウ判定子を使ってそれをチェックします。
サーバーが、復号化しチェックしたタイムスタンプと自分の内部時計とを比較し、次のプロセスを実行します。
サーバーとの時間差がウィンドウ許容値を越えていた場合、要求は拒否され、プロセスが中止されて、エラーメッセージが表示されます。たとえば、タイムスタンプが 9:00 am であり、ウィンドウが 1 分であったとします。もしその要求をサーバーが受信して復号化したのが 9:01 am であれば、その要求は拒否されます。
タイムスタンプがウィンドウ許容値内である場合、サーバーは主体から前に受信した要求のタイムスタンプよりも大きいかチェックします。これによって、NIS+ 要求を正しい順序で処理しているか確認できます。
順序誤りの要求はエラーメッセージとともに拒否されます。たとえば、タイムスタンプが 9:00 am でありその主体から最後に受信した要求のタイムスタンプが 9:02 am だった場合、その要求は拒否されます。
最後に受信した要求と同じタイムスタンプであった場合もエラーメッセージが表示されて拒否されます。これによって、要求を 2 度処理することはなくなります。たとえば、タイムスタンプが 9:00 am であり最後にその主体から受信した要求のタイムスタンプも 9:00 am だった場合、この要求は拒否されます。
タイムスタンプがウィンドウ許容値内であり、その主体からの最後の要求よりも大きかった場合に、サーバーはその要求を受け入れます。
サーバーが、要求をコンパイルし、タイムスタンプをその主体から受信した最後のものとして格納し、要求に基づいて動作します。
要求に対する応答としてサーバーから受信した情報が信頼できるサーバーからのものであるかを主体が確認できるようにするため、サーバーは主体の DES 鍵を使ってタイムスタンプを暗号化し、データとともに主体に送り返します。
主体側では、主体の DES 鍵を使って送り返されたタイムスタンプを復号化します。
復号化が成功した場合は、サーバーからの情報を要求者へ戻します。
何らかの理由で復号化に失敗した場合は、エラーメッセージが表示されます。
DES 資格は次の内容で構成されます。
主体の「Secure RPC ネット名」
「確認 (verification)」フィールド
「Secure RPC ネット名」
資格のこの部分は NIS+ の主体を特定するのに使用します。Secure RPC ネット名はすべて次の 3 つの要素で構成されます。
「接頭辞」
接頭辞は常に unix になります。
「識別子」
主体がクライアントユーザーの場合、ID フィールドはユーザーの UID です。主体がクライアントワークステーションの場合、ID フィールドはワークステーションのホスト名になります。
「ドメイン名」
主体の DES 資格を含んでいるドメイン名がドメイン名になります (主体のホームドメイン)。
NIS+ 主体名は常にドット (.) で終わりますが、Secure RPC ネット名はドット (.) で終わらないことに注意してください。
主体 |
接頭辞 |
識別子 |
ドメイン |
例 |
---|---|---|---|---|
ユーザー |
unix |
UID |
ユーザーのパスワードエントリと DES 資格そのもののあるドメイン |
unix.24601@sales.doc.com |
ワークステーション |
unix |
ホスト名 |
ドメイン名はワークステーションが domainname コマンドを実行すると返される |
unix.machine7@sales.doc.com |
確認フィールドは資格を確かめるために使用するフィールドです。cred テーブルに格納された資格情報に基づいて作成されます。
確認フィールドの構成は次のとおりです。
主体の非公開鍵と NIS+ サーバーの公開鍵に基づく、暗号化された主体の DES 鍵 (「要求フェーズ - 詳細説明」参照)
暗号化されたタイムスタンプ
タイムウィンドウ
図 7-2 を参照してください。DES 資格を作成するには、keylogin コマンドを実行する必要がありますが、これは主体が資格を作成する前に実行します。keylogin コマンド (単に「keylogin」とする場合が多い) は、NIS+ 主体がログインする時に自動的に実行されます。
主体のログインパスワードが Secure RPC パスワードと異なる場合は、keylogin コマンドは成功しないことに注意してください。詳しくは、「Secure RPC パスワードとログインパスワードの問題」を参照してください。
keylogin コマンドの目的は、主体が自身の非公開鍵にアクセスできるようにすることにあります。keylogin コマンドを実行すると、cred テーブルから主体の非公開鍵を取り込み (fetch)、主体の Secure RPC パスワード (非公開鍵は主体の「Secure RPC パスワード」を使って最初に暗号化される) を使ってそれを復号化し、将来の NIS+ 要求に備えてキーサーバーに格納します。
主体が DES 資格を作成するには、主体が要求を送る相手サーバーの公開鍵が必要です。この情報は主体のディレクトリオブジェクトに格納されています。主体がこの情報を獲得すれば資格の確認フィールドを作成できます。
まず、主体が種々の資格情報を暗号化するためにランダム DES 鍵を作成します。主体は自分の非公開鍵 (キーサーバーに格納されている) とサーバーの公開鍵を使って、ランダム DES 鍵を作成し暗号化するための共通鍵を作成します。次に DES 鍵で暗号化したタイムスタンプを作成し、それを確認フィールドで他の資格関連情報の中に入れます。
主体のログインパスワードがユーザーの Secure RPC パスワードと異なる場合、keylogin コマンドは主体のログインパスワードを使って復号化し、主体の Secure RPC パスワードを使って非公開鍵を暗号化するのがデフォルト動作なので、ログインした時に主体のログインパスワードを復号化できません。
この場合でも主体がシステムにログインすることは可能ですが、キーサーバーがそのユーザーのための復号化された非公開鍵を持っていませんから、未認証クラスが与えられることになります。ほとんどの NIS+ 環境において、未認証クラスにはほとんどの NIS+ オブジェクトに対する作成権、削除権、変更権を与えないように設定されますから、結果としてユーザーが NIS+ オブジェクトにアクセスしても「アクセス権拒否」などのエラーになります。
「ネットワークパスワード」を「Secure RPC パスワード」の同意語として使用する場合があります。ネットワークパスワードの入力プロンプトが表示された場合は、Secure RPC パスワードを入力してください。
別の承認クラスを得るには、この場合 keylogin プログラムを実行し、パスワード入力のプロンプトに主体の Secure RPC パスワードを入力する必要があります (「キーログイン」の項を参照)。
しかし、keylogin コマンドを実行するのは一時的な解決であり、有効なのはそのセッション限りです。こうしてキーサーバーはユーザーの復号化された非公開鍵を入手しますが、ユーザーの cred テーブルにある非公開鍵は、ログインパスワードではなく Secure RPC パスワードを使って暗号化されています。次にログインした時には同じ問題が発生します。この問題を永久的に解決するには、ユーザーの Secure RPC パスワードではなくユーザーログイン ID を使って、cred テーブルにある非公開鍵を再度暗号化する必要があります。このためにはユーザーが chkey -p コマンドを実行します (「NIS+ 主体の鍵の変更」の項を参照)。
Secure RPC パスワードがログインパスワードと異なる問題を永久的に解決するには、ユーザー (もしくはユーザーに対応している管理者) が次の手順を実行してください。
ログインパスワードを使ってログインします。
キーサーバーにある復号化された非公開鍵を一時的に獲得するために、keylogin プログラムを実行し、NIS+ アクセス権を得ます。
chkey -p を実行し、cred テーブル内の暗号化された非公開鍵を、ユーザーログインパスワードに基づいたものに永久的に変更します。
logout コマンドを使って、システムからログオフします。
正しい資格を作成し、正しいアクセス権を与えられたのに、主体の要求が拒否される場合があります。この原因のほとんどは、サーバーの公開鍵が古いバージョンだった時に作られた、古いオブジェクトが残っていることにあります。この問題は通常次の方法で解決します。
アクセスしようとしているドメインで、nisupdkeys を実行します (この種の問題解決の情報については、「nisupdkeys コマンド」と 「資格に関する情報が古くなっている」の項を参照)。
マシンの nis_cachemgr を終了します。次に /var/nis/NIS_SHARED_DIRCACHE を削除してから、nis_cachemgr を再起動します。
この節では、NIS+ 名前空間のどこに資格関連情報が格納されるのかを説明します。
公開鍵などの資格に関連する情報は、名前空間内のあちこちに格納されています。NIS+ は、情報を格納しているオブジェクトの生存期間に応じてこの情報を定期的に更新しますが、場合によっては、更新の間に同期が失われ、正常に動作しなくなることがあります。資格関連の情報を格納するすべてのオブジェクト、テーブル、ファイル、および再設定方法を、表 7-2 に示します。
表 7-2 資格に関連する情報が格納されている場所
項目 |
格納している情報 |
リセットまたは変更の方法 |
---|---|---|
cred テーブル |
NIS+ 主体の秘密非公開鍵と公開鍵。これらの鍵のマスターコピーとなっている |
nisaddcred を使用して、新しい資格を作成する。既存の資格を更新する。chkey も使用可 |
ディレクトリオブジェクト |
サポートする各サーバーの公開鍵のコピー |
ディレクトリオブジェクトに対して /usr/lib/nis/nisupdkeys コマンドを実行する |
キーサーバー |
現在ログインしている NIS+ 主体の秘密鍵 |
クライアントユーザーの場合は keylogin を、クライアントワークステーションの場合は keylogin -r を実行する |
NIS+ デーモン |
ディレクトリオブジェクトのコピー。これはサーバーの公開鍵のコピーを持つ |
rpc.nisd デーモンとキャッシュマネージャを終了し、/var/nis から NIS_SHARED_DIRCACHE を削除する。その後両方を再起動する |
ディレクトリキャッシュ |
ディレクトリオブジェクトのコピー。これはサーバーの公開鍵のコピーを持つ |
NIS+ キャッシュマネージャのプロセスを終了し、nis_cachemgr -i コマンドで再起動する。-i オプションは、コールドスタートファイルからディレクトリキャッシュを再設定し、キャッシュマネージャを再起動する |
コールドスタートファイル |
ディレクトリオブジェクトのコピー。これは、サーバーの公開鍵のコピーを持つ |
ルートマスターでは、NIS+ デーモンのプロセスを終了してから再起動する。デーモンは、既存の NIS_COLD_START ファイルに新しい情報を再ロードする。クライアントでは、まず/var/nis から NIS_COLD_START と NIS_SHARED_DIRCACHE ファイル削除し、次にキャッシュマネージャのプロセスを終了する。その後、nisinit -c でクライアントを再び初期設定する。クライアントの信頼できるサーバーは、クライアントワークステーションの NIS_COLD_START ファイルに新しい情報を再ロードする |
passwd テーブル |
ユーザーのパスワード |
passwd -r nisplus コマンドを使用する。このコマンドは、NIS+ passwd テーブル内のパスワードを変更し、cred テーブル内のパスワードを更新する |
passwd ファイル |
ユーザーのパスワード、またはワークステーションのスーパーユーザーパスワード |
passwd -r nisplus コマンドを使用する。スーパーユーザーとしてログインしていても、自分のユーザー名でログインしていてもよい |
passwd マップ (NIS) |
ユーザーのパスワード |
passwd -r nisplus コマンドを使用する |
主体の資格情報は「cred テーブル」に格納されています。cred テーブルは NIS+ が標準で持つ 16 のテーブルの 1 つです。各ドメインに cred テーブルが 1 つあり、そのドメインに属しているクライアントワークステーションとログインを許されたクライアントユーザー (そのドメインの主体) の資格情報が格納されています。cred テーブルはそれらドメインの org_dir サブディレクトリにあります。
cred テーブルをリンクしないでください。各 org_dir ディレクトリはそれ自身の cred テーブルを持つ必要があります。他の org_dir の cred テーブルとのリンクも使用しません。
ドメイン内のすべてのマシンにログインできるユーザーすべての LOCAL 資格情報が cred テーブルに格納されています。cred テーブルにはまた、ホームドメインとしてとしてドメインを持っているユーザーの DES 資格情報も格納されています。
cred テーブルの内容は niscat コマンドを使って見ることができます。第 14 章「NIS+ テーブルの管理」を参照してください。
表 7-3 に示すように、cred テーブルには 5 つの列があります。
表 7-3 cred テーブルの資格情報
NIS+主体名 |
認証の種類 |
認証名 |
公開データ |
非公開データ |
|
---|---|---|---|---|---|
列名 |
cname |
auth_type |
auth_name |
public_data |
private_data |
ユーザー |
完全主体名 |
LOCAL |
UID |
GID list |
|
マシン |
完全主体名 |
DES |
Secure RPCネット名 |
公開鍵 |
暗号化された非公開鍵 |
「LOCAL」
認証種類が LOCAL の場合、他の列は主体のユーザー名、UID、および GID となり、最後の列は空白になります。
「DES」
認証種類が DES の場合、他の列は主体の Secure RPC ネット名、公開鍵、および暗号化された非公開鍵となります。これらの鍵は、他の情報と共に DES 資格を暗号化したり、復号化するのに使われます。
資格情報を作成したり管理したりするには次の方法があります。
Solstice AdminSuite ツールを使用します。このツールを使用すると容易に資格を管理できます。個々の資格を管理する場合はこのツールの使用を推奨します。
nisclient スクリプトを使用します。1 つの主体の資格を容易に作成し変更できます。便利な方法なので、個々の資格を管理する方法として推奨します。『Solaris ネーミングの設定と構成』のパート I「ネーミングの紹介」に nisclient スクリプトを使用して資格情報を作成する方法を示しています。
nispopulate スクリプトを使用します。これはすでに NIS+ マップもしくは /etc ファイルに資格情報を格納してある1つ以上の主体の資格を作成変更する便利な方法です。これは、NIS+ 主体グループの資格を管理する方法として推奨します。『Solaris ネーミングの設定と構成』のパート I「ネーミングの紹介」に nispopulate スクリプトを使用して資格情報を作成する方法を示しています。
nisaddcred コマンドを使用します。次の節では、nisaddcred コマンドを使って資格と資格情報を作成する方法を説明します。
nisaddcred コマンドは資格情報を作成するコマンドです。
nispopulate と nisclient スクリプトを使って資格情報を作成できます。これらスクリプトは nisaddcred コマンドよりも容易に使えて効果的なものです。ネットワークが特別な機能を必要とするのでなければ、スクリプトを使用してください。
nisaddcred コマンドは、LOCAL 資格と DES 資格情報の作成、更新、および削除を行います。資格情報を作成するには、適切なドメインの cred テーブルに対する作成権が必要です。資格を更新するには、cred テーブル、または少なくとも cred テーブルの特定エントリに対する変更権が必要です。資格を削除するには、cred テーブル、または cred テーブルのエントリに対する削除権が必要です。
LOCAL 資格
nisaddcred -p uid -P principal-name local |
DES 資格
nisaddcred -p rpc-netname -P principal-name des |
自分の資格を更新する場合
LOCAL 資格
nisaddcred -local |
DES 資格
nisaddcred des |
この章で説明する nisaddcred コマンドに加えて、資格に関して有用な情報を提供するコマンドが 2 つ用意されています。
表 7-4 その他の資格関連コマンド
コマンド |
説明 |
参照ページ |
---|---|---|
niscat -o |
ディレクトリの属性を一覧表示する。ディレクトリのサーバーの非公開鍵フィールドをチェックすることで、ディレクトリオブジェクトに非公開鍵が格納されているかわかる | |
nismatch- |
cred テーブル上で実行すると主体の資格情報を表示する |
LOCAL 資格情報を作成するために nisaddcred コマンドを使用すると、nisaddcred コマンドは主体のログインレコードから主体ユーザーの UID (および GID) を抽出し、ドメインの cred テーブルに置きます。
DES 資格情報を作成するのに使用した場合、nisaddcred は 2 つのプロセスを実行します。
主体の Secure RPC ネット名を作成します。Secure RPC ネット名は、パスワードレコードから取得した主体のユーザー ID 番号とドメイン名 (たとえば、unix.1050@doc.com) を結合して作成されます。
主体の非公開鍵と公開鍵を生成します。
nisaddcred が非公開鍵を暗号化するには、Secure RPC パスワードが必要です。nisaddcred コマンドを引数 -des で呼び出すと、主体の Secure RPC パスワードの入力を要求されます。通常このパスワードは主体のログインパスワードと同じです。(異なる場合は、「Secure RPC パスワードとログインパスワードの問題」に示す手順に従ってさらに操作が必要となります。)
nisaddcred コマンドは 1 対の乱数 (Difie-Hellman 方式を使った 192 ビットの認証鍵) を作成します。この鍵は Difie-Hellman の鍵ペア (key-pair) または省略して単に「鍵ペア」と呼びます。
この鍵ペアの一方が「非公開鍵」であり、もう一方が「公開鍵」になります。公開鍵は cred テーブルの公開データフィールドに置かれます。非公開鍵は主体の Secure RPC パスワードで暗号化された後に非公開データに置かれます。
デフォルトでは、cred テーブルをすべての NIS+ 主体 (未認証主体さえも) が読み取れるので、セキュリティ上の予防措置として、主体の非公開鍵を暗号化しています。
資格情報を作成する際、何度も主体の「RPC ネット名 (rpc-netname)」と「主体名 (principal-name)」を入力しなければなりません。どちらも独自の構文が必要です。
「Secure RPC ネット名」
Secure RPC ネット名は Secure RPC プロトコルで判定されますから、NIS+ のネーミング規則には従いません。
ユーザーの場合:unix.uid@domain
マシンの場合:unix.hostname@domain
Secure RPC ネット名がユーザーを識別する場合、ユーザーの UID が必要です。ワークステーションを識別する場合は、ワークステーションのホスト名が必要です (nisaddcred コマンドとともに使用する場合は、常に -p (小文字) フラグで始まります)。
Secure RPC ネット名は常に unix (すべて小文字) で始まりドメイン名で終わります。Secure RPC プロトコルに従いますから、ドメイン名にはドットを付けません。
「主体名」
NIS+ 主体名は通常の NIS+ ネーミング規則に従いますが、常に完全指定名でなければなりません。構文は、principal.domain になります。
識別する対象がクライアントユーザーであっても、クライアントワークステーションであっても、主体名で始まり、その後にドットと完全なドメイン名が続き、最後はドットで終わります。資格の作成に使用する場合、常に先頭は -P (大文字) フラグで始まります。資格の削除に使用する場合、-P フラグは使用しません。
名前空間を最初に設定する場合、ドメインをサポートする管理者の資格情報を最初に作成します。一度管理者の資格情報を作成すると、他の管理者、クライアントワークステーション、およびクライアントユーザーの資格情報を作成できます。
自分の資格情報を作成しようとすると、堂々めぐりに陥ります。つまり、ドメインの cred テーブルに対する作成権がなければ自分の資格情報を作成できず、もし NIS+ 環境が適切に設定されていれば、資格を持つまではそのような権限を持つこともできません。この循環から抜け出さなくてはなりません。これには、次の 2 つの方法があります。
ドメインのマスターサーバーにスーパーユーザーとしてログインしているうちに、資格情報を作成する
ダミーパスワードを使用して、他の管理者に自分の資格を作成してもらってから chkey コマンドを使用してパスワードを変更する
いずれの場合も、別の NIS+ 主体に資格情報を作成してもらうことになります。自分の資格情報を作成するには、「NIS+ 主体の資格情報を作成する方法」の項を参照してください。
NIS+ の資格情報はドメインの設定後いつでも作成できます。すなわち、cred テーブルがあれば作成できます。
NIS+ 主体の資格情報を作成する
主体のホームドメインの cred テーブルに対する作成権が必要
サーバーは、主体の存在を認識している必要がある。この場合「サーバーが認識している」とは以下のことを意味する
主体がユーザーの場合、ドメインの NIS+ passwd テーブルかサーバーの /etc/passwd ファイルのどちらかにエントリが必要
主体がワークステーションン場合、ドメインの NIS+ host テーブルかサーバーの /etc/hosts ファイルのどちらかにエントリが必要
これらの条件を満たせば、-p と -P の両方のオプション付きで nisaddcred コマンドを実行できます。
LOCAL 資格
nisaddcred -p uid -P principal-name local |
DES 資格
nisaddcred -p rpc.netname -P principal-name des |
次の原則を銘記してください。
主体ユーザーの場合、LOCAL 資格と DES 資格の両方の情報を作成できます。
主体ワークステーションの場合、DES 資格情報しか作成できません。
主体のホームドメイン (ユーザーまたはマシン) でだけ DES 資格情報を作成できます。
ユーザーの LOCAL 資格情報はユーザーのホームドメインでも他のドメインでも作成できます。
UID が 11177 の morena という名前の NIS+ ユーザーの LOCAL および DES 資格情報を作成する例を次に示します。彼女の所属するドメインは doc.com. で、この例ではドメインの主体マシンから彼女の資格情報を入力します。
client# nisaddcred -p 11177 -P morena.doc.com. local client# nisaddcred -p unix.11177@sales.doc.com ¥ -P morena.doc.com. des Adding key pair for unix.11177@sales.doc.com (morena.doc.com.). Enter login password: |
Enter login password: プロンプトに対する正しい応答は morena のログインパスワードです。彼女のログインパスワードを知らない場合は、ダミーパスワードを使用します。ダミーパスワードは、次の例のように、後で chkey コマンドを使って変更できます。
ユーザーのログインパスワードを知らない場合、次に説明するようにダミーパスワードを使うことができます。
表 7-5 は、ダミーパスワードを使って資格情報を作成した管理者が、chkey コマンドを使ってパスワードを変更する方法を示します。この例では、UID が 119 の eiji という名前の管理者の資格情報を作成します。eiji はルートドメインに属しているので、rootmaster という名前のルートマスターサーバーから彼の資格情報を入力します。
表 7-5 管理者の資格情報を作成する作業
作業 |
コマンド |
---|---|
eiji の LOCAL 資格情報を作成する |
rootmaster# nisaddcred -p 119 -P eiji.doc.com. local |
eiji の DES 資格情報を作成する |
rootmaster#nisaddcred -p unix.119@doc.com -P eiji.doc.com. des Adding key pair for unix.119@doc.com (eiji.doc.com.). |
eiji のダミーパスワードを入力する |
Enter eiji's login password: nisaddcred: WARNING: password differs from login passwd |
ダミーパスワードを再度入力する |
Retype password: |
使用したダミーパスワードを eiji に伝える | |
eiji がルートマスターにログイン |
rootmaster% login: eiji |
eiji が本当のログインパスワードを入力 |
Password: |
eiji はエラーメッセージを受けたが、ログインは許可される |
Password does not decrypt secret key for unix.119@doc.com. |
eiji がログインを実行 |
rootmaster% keylogin |
eiji がダミーパスワードを入力 |
Password: dummy-password |
eiji が chkey を実行 |
rootmaster%chkey -p Updating nisplus publickey database Generating new key for'unix.119@doc.com'. |
eiji が本当のログインパスワードを入力 |
Enter login password: |
eiji が本当のログインパスワードを再入力 |
Retype password: Done. |
まず、通常の方法で eiji の資格情報を作成しますが、ダミーのログインパスワードを使用します。NIS+ は警告を発して、再入力を要求します。再入力を行うと、この操作は完了します。ドメインの cred テーブルには、ダミーパスワードに基づく eiji の資格情報が入っています。しかし、ドメインの passwd テーブル (あるいは /etc/passwd ファイル) には、まだ彼のパスワードエントリが残っているので、彼はシステムにログオンできます。
次に、eiji は本当のログインパスワードを入力して、ドメインのマスターサーバーにログインします (ログイン手順では、passwd テーブルまたは /etc/passwd ファイルのパスワードをチェックするため)。そこから eiji は、まずダミーパスワードを使用して keylogin を実行し (cred テーブルをチェックするため)、chkey -p コマンドを使用して cred エントリを本当のパスワードに変更します。
これらの 2 つの例では、主体ユーザーのホームドメインのマスターサーバーにログインしている間に、主体ユーザーの資格情報を作成しました。しかし、適切なアクセス権がある場合、別のドメインに資格を作成できます。次の構文でドメイン名を付加するだけです。
LOCAL 資格情報
nisaddcred -p uid -P principal-name local domain-name |
DES 資格情報
nisaddcred -p rpc-netname -P principal-name des domain-name |
次の例では、まず chou という名前のシステム管理者の LOCAL および DES 資格情報を、そのシステム管理者のホームドメイン (これは、たまたまルートドメイン) に作成し、次にその LOCAL 資格を doc.com ドメインに追加します。chou の UID は 11155 です。このコマンドは、ルートマスターサーバーから入力します。簡単にするため、chou の正しいログインパスワードを入力しているものとします。
rootmaster# nisaddcred -p 11155 -P chou.doc.com. local rootmaster# nisaddcred -p unix.11155@doc.com -P chou.doc.com. des Adding key pair for unix.11155@doc.com (chou.doc.com.). Enter login password: rootmaster# nisaddcred -p 11155 -P chou.doc.com. local doc.com. |
LOCAL 資格情報は、UID を NIS+ 主体名にマップします。クライアントユーザーである NIS+ 主体は、さまざまなドメインにさまざまな UID を持てますが、NIS+ 主体名は 1 つしか持てません。したがって、chou などの NIS+ 主体が自分のホームドメイン以外のドメインからログインする場合、そのドメインにパスワードエントリを持つだけではなく、そのドメインの cred テーブルに LOCAL 資格も持っていなければなりません。
主体「ワークステーション」の資格情報を作成する例を次に示します。このホスト名は starshine1 で、ルートドメインに所属しています。したがって、この資格はルートマスターサーバーから作成されます。この例では、ルートマスターにルートとしてログインしている間に資格情報を作成します。しかし、有効な資格情報と適切なアクセス権をすでに持っている場合、自分のユーザー名でログインしているときに、資格を作成できます。
rootmaster# nisaddcred -p unix.starshine1@doc.com -P ¥ starshine1.doc.com. des Adding key pair for unix.starshine1@doc.com (starshine1.doc.com.). Enter starshine1.doc.com.'s root login password: Retype password: |
パスワードプロンプトに対しては、クライアントワークステーションのスーパーユーザーパスワードを入力してください。もちろん、ダミーパスワードを使用することもできます。このダミーパスワードは、その主体ワークステーションにスーパーユーザーとしてログインすれば、後で変更できます。
以下のいくつかのセクションでは、nisaddcred コマンドで資格情報を管理する方法について説明します。nisaddcred で資格情報を管理するには、cred テーブルに対する作成権、変更権、読み取り権、削除権が必要です。
自分の資格情報を更新することは、資格を作成することよりはるかに簡単です。自分のユーザー名でログインしているときに、次のような nisaddcred コマンドを入力するだけです。
# nisaddcred des # nisaddcred local |
別のユーザーの資格情報を更新する場合は、そのユーザーの資格情報を作成するのと同じ操作を行います。
nisaddcred コマンドは、主体の資格情報を削除しますが、コマンドを実行しているローカルドメインだけから削除できます。
システム全体から完全に主体を削除するには、主体のホームドメインおよび LOCAL 資格情報のあるすべてのドメインから主体の資格情報を明示的に削除しなければなりません。
資格情報を削除するには、ローカルドメインの cred テーブルへの変更権が必要です。-r オプションを使い、完全 NIS+ 主体名で主体を指定します。
# nisaddcred -r principal-name |
次の 2 つの例では、システム管理者 morena.doc.com. の LOCAL と DES の資格情報を削除します。最初の例では、システム管理者のホームドメイン (doc.com.) から両方の資格情報を削除し、2 番目の例では、sales.doc.com. ドメインから LOCAL 資格情報を削除します。該当するドメインのマスターサーバーから、それぞれがどう入力されるかに注意してください。
rootmaster# nisaddcred -r morena.doc.com. salesmaster# nisaddcred -r morena.doc.com. |
資格が本当に削除されたことを確かめるには、次に示すように、cred テーブルに対して nismatch を実行します。nismatch の詳細は、第 14 章「NIS+ テーブルの管理」を参照してください。
rootmaster# nismatch morena.doc.com. cred.org_dir salesmaster# nismatch morena.doc.com. cred.org_dir |
この章では、NIS+ の鍵と、鍵を管理する方法について説明します。
Solstice AdminSuite ツールを利用した方が容易に NIS+ セキュリティタスクを実行できます。
NIS+ 鍵は NIS+ の関連情報を暗号化するために使用します。
この章では、NIS+ セキュリティシステム全体と、特にシステムで鍵が果たす役割について、十分理解しているユーザーを想定しています。(詳しくは、第 6 章「セキュリティの概要」を参照してください。)
NIS+ 鍵に関するコマンドとその構文やオプションについての詳しい説明は、nis+(1) のマニュアルページを参照してください。また、nisaddcred コマンドも鍵に関連のある働きをします。詳細は、「nisaddcred コマンド」を参照してください。
主体がログインする時、パスワードの入力を求めるプロンプトが現れます。このパスワードはユーザーがセキュリティゲートをパスし、ネットワークにアクセスするために必要なものです。ログインプロセスは、ユーザーのホームドメインの cred テーブルにあるユーザーの非公開鍵を復号化しキーサーバーへ渡します。キーサーバーはその復号化された非公開鍵を使って、ユーザーが NIS+ オブジェクトにアクセスするつど、ユーザーの認証を行います。
通常は、この場合だけ主体にパスワードが要求されます。しかし、cred テーブルにある主体の非公開鍵がユーザーのログインパスワードと異なるパスワードを使用して暗号化されていると、ログインプロセスはそれを login の際にログインパスワードを使って復号化できないので、キーサーバーに復号化した非公開鍵を提供できません。(これは cred テーブル内にあるユーザーの非公開鍵が、ログインパスワードと異なる Secure-RPC パスワードを使用して暗号化された場合に多く起こります。)
「ネットワークパスワード」と「Secure-RPC パスワード」を同意語として使用する場合があります。
この問題を一時的に解決するには、ログインの後には必ず主体が keylogin コマンドを使用して、キーログインを実行する必要があります。-r フラグを使って、スーパーユーザー主体にログインし、ホストの /etc/.rootkey にスーパーユーザーの鍵を格納します。
主体ユーザーの場合
keylogin |
主体マシンの場合 (一度だけ)
keylogin -r |
しかしながら、オリジナルのパスワードを使用して確実にキーログインを実行しても、そのログインセッションにおいて一時的に問題が解決するだけです。cred テーブルの非公開鍵はユーザーのログインパスワードと異なるパスワードを用いて暗号化されたままであり、次にユーザーがログインした時に同じ問題が起こります。この問題を永久的に解決するには、chkey コマンドを使用して、非公開鍵の暗号化に使ったパスワードをユーザーのログインパスワードに変更します (「NIS+ 主体の鍵の変更」を参照)。
chkey コマンドは cred テーブルに格納されている NIS+ 主体の公開および非公開鍵を変更します。このコマンドは passwd テーブル内もしくは /etc/passwd ファイル内のいずれのエントリにも影響を与えません。
新規に鍵を作成し、パスワードを用いて非公開鍵を暗号化します。-p オプションをつけて実行した場合、chkey コマンドは既存の非公開鍵を新規のパスワードで再暗号化します。
新規に Diffie-Hellman の鍵ペアを作成し、提供されたパスワードを使用して非公開鍵を暗号化します (各主体に複数の Diffie-Hellman の鍵のペアが存在することは可能) 。しかし、ほとんどの場合ユーザーは新規の鍵ペアを求めず、既存の非公開鍵を新規のパスワードを使って再暗号化しようとします。これを行うには、-p オプション付きで chkey を実行します。
これらのテーマの詳細は、マニュアルを参照してください。
NIS+ 環境においては、どんな管理ツールまたは passwd (もしくは nispasswd) コマンドを用いてログインパスワードを変更しても、cred テーブル内の非公開鍵は新規のパスワードを使用して自動的に再暗号化されます。従って、ログインパスワードの変更後に chkey コマンドを実行する必要はありません。
chkey コマンドはキーサーバー、cred テーブル、および passwd テーブルとの関連で動作します。chkey を実行するには次のようにします。
ホームドメインの passwd テーブルにエントリが必要です。この条件を満たさなければ、エラーメッセージが返ります。
cred テーブルの変更権を持っていなければなりません。この権限がない場合は「permission denied」などのエラーメッセージが返ります。
cred テーブル内の非公開鍵の暗号化に使われた、オリジナルのパスワードを知らなくてはなりません (ほとんどの場合、これは Secure-RPC パスワード)。
ログインパスワードを使って非公開鍵を再暗号化するために chkey コマンドを使用するには、最初にオリジナルのパスワードを用いて keylogin を実行し、次に chkey -p を実行します。表 8-1 では、主体ユーザーの keylogin と chkey の実行方法を示します。
表 8-1 非公開鍵の暗号化:コマンドの説明
作業 |
コマンド |
---|---|
ログインする |
Sirius% login Login-name |
ログインパスワードを入力する |
Password: |
ログインパスワードと Secure RPC パスワードが異なっている場合、keylogin を実行する |
Sirius% keylogin |
非公開鍵の暗号化に使用したオリジナルパスワードを入力する |
Password: Secure RPC password |
chkey を実行する |
Sirius% chkey -p Updating nisplus publickey database Updating new key for 'unix.1199@Doc.com.' |
ログインパスワードを入力する |
Enter login password: login-password |
ログインパスワードを再入力する |
Retype password: |
次の節では、NIS+ 主体の鍵の変更方法を説明します。
サーバーの鍵を変更するときは、常にドメイン内の全クライアントの鍵情報も更新する必要があります。その方法は、「クライアントの鍵情報を更新する」で説明します。
ルートマスター (root として) からルートマスターサーバーの鍵を変更するには、表 8-2 の手順を実行します。
表 8-2 ルートマスターからルートマスター鍵を変更する
作業 |
コマンド |
---|---|
新規 DES 資格を作成 |
rootmaster# nisaddcred des |
rpc.nisd のプロセス ID を発見 |
rootmaster# ps -e | grep rpc.nisd |
NIS+ デーモンを終了 |
rootmaster# kill pid |
セキュリティなしで NIS+ デーモンを再起動 |
rootmaster# rpc.nisd -S0 |
keylogout を実行 (以前の keylogin はタイムアウト) |
rootmaster# keylogout -f |
マスターがディレクトリに保管していた鍵を更新 |
rootmaster# nisupdkeys dirs |
rpc.nisd のプロセス ID を発見 |
rootmaster# ps -e | grep rpc.nisd |
NIS+ デーモンを終了 |
rootmaster# kill pid |
デフォルトセキュリティで NIS+ デーモンを再起動 |
rootmaster# rpc.nisd |
keylogin を実行 |
rootmaster# keylogin |
pid は ps -e | grep rpc.nisd コマンドで通知されるプロセス ID 番号
dirs は更新するディレクトリオブジェクト (rootmaster によって保管されたディレクトリオブジェクト)
表 8-2 に示すプロセスの最初の手順では、nisaddcred がルートマスターの cred テーブルを更新し、/etc/.rootkey を更新し、ルートマスターのキーログインを実行します。この時点では、マスターに保管されたディレクトリオブジェクトが更新されておらず、その資格情報とルートマスターとは同期がとれていません。表 8-2 のその後の手順は、すべてのオブジェクトを更新するのに必要です。
サーバーの鍵を変更するときは、常にドメイン内の全クライアントの鍵情報も更新する必要があります。その方法は、「クライアントの鍵情報を更新する」で説明します。
別のマシンからルートマスターの鍵を変更する場合、それに必要な NIS+ 資格とそれを行う承認を得ていなくてはなりません。
表 8-3 異なるマシンによるルートマスターの鍵の変更 - コマンド一覧
作業 |
コマンド |
---|---|
新規の DES 資格を作成 |
othermachine% nisaddcred -p principal -P nisprincipal des |
ディレクトリオブジェクトを更新 |
othermachine% nisupdkeys dirs |
/etc.roootkey を更新 |
othermachine% keylogin -r |
クライアントとして再度初期化 |
othermachine% nisinit -cH |
principal はルートマシンの Secure RPC ネット名。たとえば、unix.rootmaster@doc.com (ドットで終わらない)
nis-principal はルートマシンの NIS+ 主体名。たとえば、rootmaster.doc.com. (ドットで終わる)
dirs は更新するディレクトリオブジェクト (rootmaster で保管されたディレクトリオブジェクト)
nisupdkeys を実行する場合、関連したディレクトリオブジェクトすべてを同時に更新するように注意します。すなわち、すべてを 1 つのコマンドで行います。分割して更新すると、認証エラーになります。
サーバーの鍵を変更するときは、常にドメイン内の全クライアントの鍵情報も更新する必要があります。その方法は 「クライアントの鍵情報を更新する」で説明します。
複製からルート複製の鍵を変更する手順を次に示します。
replica# nisaddcred des replica# nisupdkeys dirs |
dirs は更新するディレクトリオブジェクト (replica で保管されたディレクトリオブジェクト)
nisupdkeys を実行する場合、関連したディレクトリオブジェクトのすべてを同時に更新するように注意します。すなわち、すべてを 1 つのコマンドで行います。分割して更新すると、認証エラーになります。
サーバーの鍵を変更するときは、常にドメイン内の全クライアントの鍵情報も更新する必要があります。その方法は、「クライアントの鍵情報を更新する」で説明します。
サーバーからルート以外のサーバー (マスターまたは複製) の鍵を変更する手順を以下に示します。
subreplica# nisaddcred des subreplica# nisupdkeys parentdir dirs |
parentdir はルート以外のサーバーの親ディレクトリ (subreplica の NIS+ サーバーを持つディレクトリ)
dirs は更新しようとするディレクトリオブジェクト (subreplica で保管されたディレクトリオブジェクト)
nisupdkeys を実行する場合、関連したディレクトリオブジェクトのすべてを同時に更新するように注意します。すなわち、すべてを 1 つのコマンドで行います。分割して更新すると、認証エラーになります。
サーバーの鍵を変更するときは、常にドメイン内の全クライアントの鍵情報も更新する必要があります。その方法は、「クライアントの鍵情報を更新する」で説明します。
NIS+ サーバーの公開鍵は名前空間のあちこちに格納されています。サーバーに新規の資格情報を作成する場合、新規の鍵ペアが作成され cred テーブルに格納されます。しかし、名前空間ディレクトリオブジェクトには、まだサーバーの古い公開鍵のコピーが残っています。nisupdkeys コマンドを使用して、これらのディレクトリオブジェクトのコピーを更新します。
古い鍵ペアの保全が危うくなったり、非公開鍵の暗号化に使ったパスワードを忘れてしまったりして新規の鍵ペアを作成する場合、nisupdkeys を使用してディレクトリオブジェクト内の古い公開鍵を更新できます。
1 台の特定サーバーの鍵を更新する
NIS+ ディレクトリオブジェクトをサポートしているサーバーすべての鍵を更新する
サーバーの公開鍵をディレクトリオブジェクトから削除する
サーバーの IP アドレスが変更された場合にそれを更新する
しかしながら、nisupdkeys は主体ワークステーション上の NIS_COLD_START ファイルを更新できません。サーバーの鍵のコピーを更新するには、NIS+ クライアントが nisclient コマンドを実行しなければなりません。もしくは、NIS+ キャッシュマネージャを実行中でかつコールドスタートファイル内で1つ以上のサーバーを利用できる場合、主体はディレクトリオブジェクト上で生存期間がタイムアウトするまで待つことができます。タイムアウトが発生すると、キャッシュマネージャはコールドスタートファイルを自動的に更新します。生存期間のデフォルトは 12 時間です。
nisupdkeys を使うには、NIS+ ディレクトリオブジェクトへの変更権が必要です。
nisupdkeys コマンドは /usr/lib/nis にあります。nisupdkeys コマンドは次の引数を使います。nisupdkeys コマンドの詳細と引数すべてのリストは、nisupdkeys(1M) のマニュアルページを参照してください。
表 8-4 nisupdkeys の引数
引数 |
Effect |
---|---|
(引数なし) |
カレントドメインのサーバーの鍵をすべて更新する |
ディレクトリ名 |
ディレクトリ名で指定したディレクトリオブジェクトの鍵を更新する |
-H サーバー名 |
カレントドメインディレクトリオブジェクト内のサーバー名で指定したサーバーの鍵を更新する。他のドメインにあるサーバーの鍵を更新する場合は、完全ホスト名を使用する |
-s -H サーバー名 |
サーバー名で指定したサーバーで保管されたディレクトリオブジェクトすべての鍵を更新する |
-C |
鍵をクリアする |
表 8-5 で公開鍵の更新手順の例を示します。
表 8-5 公開鍵の更新: コマンド例
タスク |
コマンド |
---|---|
カレントドメイン (doc.com) のすべてのサーバーのすべての鍵を更新 |
rootmaster# /usr/lib/nis/nisupdkeys Fetch Public key for server rootmaster.doc.com. netname='unix.rootmaster@doc.com' Updating rootmaster.doc.com.'s public key. Public key: public-key |
sales.doc.com ドメインのディレクトリオブジェクトをサポートしているすべてのサーバーの鍵を更新 |
salesmaster# nisupdkeys sales.doc.com (画面上には何も表示されません。) |
すべてのディレクトリ内のサーバー名が master7 であるサーバーの鍵を更新 |
rootmaster# nisupdkeys -H master7 |
sales.doc.com ディレクトリオブジェクトで保管された鍵をクリア |
rootmaster# nisupdkeys -C sales.doc.com |
カレントドメインのディレクトリオブジェクトのサーバー名が master7 であるサーバーの鍵をクリア |
rootmaster# nisupdkeys -C -H master7 |
サーバーの IP アドレスを変更するか、またはアドレスを追加する場合、NIS+ アドレス情報を更新するために nisupdkeys を実行する必要があります。
1 つ以上のサーバーの IP アドレスを更新するには、-a オプション付きで nisupdkeys を使用します。
rootmaster# nisupdkeys -a domain |
特定サーバーの IP アドレスを更新。
rootmaster# nisupdkeys -a -H server |
サーバーの鍵を変更するときは、常に全クライアントの鍵情報も更新する必要があります。NIS+ のサーバーは NIS+ のクライアントでもあります。そのため、あるサーバーの鍵を更新した場合は、それが NIS+ のサーバーであるか通常のクライアントであるかにかかわらず、ドメイン内にあるほかのすべてのマシンの鍵情報を更新する必要があります。
クライアントの鍵情報を更新するには、以下の 3 通りの方法があります。
最も簡単に個々のクライアントの鍵情報を更新するには、クライアント側で nisclient スクリプトを実行します。『Solaris ネーミングの設定と構成』を参照してください。
別の方法で個々のクライアントの鍵情報を更新するには、クライアント側で nisinit コマンドを実行します。「クライアントを初期設定する」を参照してください。
ドメイン内にある全てのマシンのクライアントの鍵情報を一括で更新するには、ドメインのディレクトリオブジェクトの生存期間の値を短くします。「クライアントの鍵情報を一括で更新する」を参照してください。
サーバーの鍵を変更したあとで、ドメイン内にあるすべてのマシンのクライアントの鍵情報を一括更新できます。
nischttl コマンドを使用して、ドメインのディレクトリオブジェクトの生存期間 (TTL) を、すぐに満了するような小さな値にしてください。
たとえば、sales.doc.com. ドメイン内のサーバーの鍵を変更した場合、ディレクトリの TTL 値を 1 分にするには、以下のように入力します。
client% nischttl 60 sales.doc.com. |
ディレクトリの TTL 値が満了すると、キャッシュマネージャはエントリを終了し、クライアントのために新しく更新された情報を入手します。
ディレクトリオブジェクトの TTL 値が満了したあとで、ディレクトリオブジェクトの TTL 値をデフォルト値に戻します。
たとえば、sales.doc.com. ドメインのディレクトリオブジェクトの TTL 値を 12 時間に戻すには、以下のように入力します。
client% nischttl 12h sales.doc.com. |
TTL 値の使用の詳細は、「nischttl コマンド」を参照してください。
NIS+ は、RPCSEC_GSS RPC(3N) セキュリティフレイバーを使用して、192 ビット Diffie-Hellman [RPC(3N) セキュリティフレイバー AUTH_DES] を超える RPC(3N) 層におけるより厳格なセキュリティを提供します。システム上で使用可能なセキュリティメカニズムのリストについては、nisauthconf(1M) コマンドを参照してください。また、これらのセキュリティメカニズムは、より厳格な暗号と各 NIS+ トランザクションの完全性を提供します。すなわち、各 NIS+ トランザクションのデータが変更されていないことが検証されます。
システム管理者は、後述のガイドラインに従って、NIS+ サーバー環境を構築する前または後に nisauthconf(1M) を実行することによって、より厳格なセキュリティメカニズムの利点を活用することができます。
Diffie-Hellman 640 ビット (dh640-0) のような公開鍵暗号ファミリーのより厳格なセキュリティメカニズムを使用するには、既存の cred テーブルに各主体の新しい資格を追加することが必要です。後述の手順は、現在 Diffie-Hellman 192 ビット (RPC セキュリティフレイバー AUTH_DES) セキュリティを実行しているシステムを、Diffie-Hellman 640 ビット (RPC セキュリティフレイバー RPCSEC_GSS) セキュリティを実行するように変換する場合のものです。この移行手順は、最もよくある場合を説明したものですが、公開鍵暗号ファミリーのどれか 1 つのセキュリティメカニズムタイプから、公開鍵暗号ファミリーの別のセキュリティメカニズムに変換する場合、原理は同じです。
以下の例では、$PATH に /usr/lib/nis があることを前提にしています。
NIS+ セキュリティの構成は、nisauthconf(1M) コマンドを使用して行います。nisauthconf はセキュリティメカニズムのリストを設定した順に取ります。セキュリティメカニズムは、secure_rpc(3N) で指定された 1 つまたは複数の認証フレイバーを使用することができます。des が唯一の指定されたメカニズムである場合には、NIS+ は他の NIS+ クライアントおよびサーバーの認証に AUTH_DES だけを使用します。NIS+ は、nisaddcred(1M) の場合を除いて、des より後のメカニズムは無視します。
nisauthconf [-v] [mechanism, ...] |
この場合の mechanism は、システム上で使用可能な RPC セキュリティメカニズムです。使用可能なメカニズムのリストについては、nisauthconf(1M) を参照してください。メカニズムを指定しないと、現在構成されているメカニズムのリストが出力されます。
NIS+ ユーザーおよびホスト主体ごとに、新しいメカニズムの資格情報を作成する必要があります。これを行うには、システムが現在のメカニズムによる認証を継続している間に、NIS+ を実行しているマシンの 1 つで nisauthconf(1M) コマンドを実行して新しい資格を作成しなければなりません。資格作成の基本の詳細は、「NIS+ 主体の資格情報を作成する方法」も参照してください。
des から dh640-0 へ変換します。nisauthconf がスーパーユーザーとして実行されており、nisaddcred が、ホームディレクトリの中で作成権を持っているどれかの主体として実行されていることが必要です。サーバー名は server1、ユーザーの主体名は morena です。ユーザー morena の UID は 11177 です。
client# nisauthconf des dh640-0 client% nisaddcred -P server1.doc.com. -p unix.server1@doc.com dh640-0 (画面上には何も表示されない) client% nisaddcred -P morena.doc.com. -p unix.11177@doc.com -ldummy-password dh640-0 (画面上には何も表示されない) |
すべてのサーバーの新しい資格が生成されたら、nisupdkeys(1M) を実行して、これらのサーバーが提供するすべてのディレクトリオブジェクトに新しい公開鍵を追加します。nisupdkeys(1M) コマンドを使用するには、その NIS+ ディレクトリオブジェクトに対する変更権を持っていなければなりません。詳細は、「公開鍵の更新」を参照してください。
これらの NIS+ ディレクトリを提供するすべてのサーバー、およびこれらのディレクトリにアクセスするすべてのクライアントは、Solaris 7 以降を実行していなければなりません。
この例では、新しい公開鍵を使用してサーバーが提供しているディレクトリは、doc.com、org_dir.doc.com.、および groups_dir.doc.com. です。更新は、マスターサーバー主体として行われます。新しいメカニズムを実行する前に、nisauthconf(1M) を使用して nisupdkeys を構成することが必要です。この例では、現在の認証メカニズムは des で、新しいメカニズムは dh640-0 です。
masterserver# nisauthconf dh640-0 des masterserver# nisupdkeys doc.com. (画面上には何も表示されない) masterserver# nisupdkeys org_dir.doc.com. (画面上には何も表示されない) masterserver# nisupdkeys groups_dir.doc.com. (画面上には何も表示されない) |
各サーバー上で NIS+ 認証を構成して、新旧両方の資格を受け入れるようにします。そのためには、nisauthconf(1M) および keylogin(1) を実行し、keyserv(1M) を再起動することが必要です。keylogin(1) コマンドは、各メカニズムの鍵を /etc/.rootkey に格納します。keylogin の基本の詳細は、「キーログイン」を参照してください。
この例では、現在の認証メカニズムは des で、新しいメカニズムは dh640-0 です。ここでは順序が重要です。クライアントおよびサーバーの NIS+ 認証では des より後のエントリは無視されます。
server# nisauthconf dh640-0 des server# keylogin -r (画面上には何も表示されない) server# /etc/reboot |
新しい資格を受け入れられるようになったので、ワークステーションを新しい資格によって認証するように変換することができます。そのためには、nisauthconf(1M) および keylogin(1) をスーパーユーザーとして実行し、リブートします。
この例では、新しいメカニズムは dh640-0 ですが、システムは、dh640-0 資格が使用可能でないか、あるいは dh640-0 による認証に成功しなかった場合には、des 資格による認証も試みます。
workstation# nisauthconf dh640-0 des workstation# keylogin -r (画面上には何も表示されない) workstation# /etc/reboot |
次の例では、新しいメカニズムは dh640-0 で、このメカニズムによる認証だけが行われます。システムを新しいメカニズムだけで認証するように構成する前に、キャッシュに書き込まれているディレクトリオブジェクトが新しいメカニズムの鍵を含むように、リフレッシュされることが必要です。これは、nisshowcache(1M) によって検証することができます。キャッシュに書き込まれているディレクトリオブジェクトがタイムアウトしてリフレッシュされるのを待つ代わりとして、次の方法があります。nis_cachemgr(1M) を終了し、続いて nisinit(1M) を使用して新しい NIS_COLD_START を構築し、続いて niscachemgr(1M) を再起動します。
ディレクトリオブジェクトを手動でリフレッシュするには、次のようにします。
# pkill -u 0 nis_cachemgr # nisinit -cH masterserver # niscachemgr -i |
ワークステーション主体およびこのワークステーションのすべてのユーザーが cred テーブルの中に dh640-0 資格を持っていなければ、dh640-0 だけで認証を行うようにシステムを構成することはできません。
workstation# nisauthconf dh640-0 workstation# keylogin -r (画面上には何も表示されない) workstation# /etc/reboot |
ダミーパスワードを持った新しい資格を与えられた各ユーザーは、chkey(1) を実行してログインパスワードに変換することが必要です。詳細については、「NIS+ 主体の鍵の変更」を参照してください。
chkey(1) を実行してログインパスワードに変換します。
# chkey -p (画面上には何も表示されない) |
低グレードのセキュリティメカニズムから高グレードのものに変換する場合には、新しい高グレードのセキュリティメカニズムタイプの資格だけを受け入れるように NIS+ サーバーを構成することによって、最大限のセキュリティが達成されます。新旧両方のメカニズムによって認証を行うようにサーバーを構成した後で、変換します。
新しいメカニズムだけを使用して認証を行うようにシステムを構成する前に、キャッシュに書き込まれているディレクトリオブジェクトをリフレッシュして、新しいメカニズムの鍵を含むようにし、nisshowcache(1M) を使用してこれを検証します。
各 NIS+ サーバー上で nisauthconf(1M) を実行し、リブートします。この例では、NIS+ サーバーは dh640-0 資格の認証だけを受け入れるように構成されます。
server# nisauthconf dh640-0 server# /etc/reboot |
この段階で、オプションで、ディレクトリオブジェクトを更新して、古い公開鍵を削除できます。これはマスターサーバーから行う必要があり、新しいセキュリティメカニズムだけを使用して認証を行うサーバーが管理するディレクトリごとに一度、nisupdkeys(1M) を実行しなければなりません。この例では、更新されるディレクトリは、doc.com、org_dir.doc.com.、および groups_dir.doc.com. です。
masterserver# nisupdkeys doc.com. (画面上には何も表示されない) masterserver# nisupdkeys org_dir.doc.com. (画面上には何も表示されない) masterserver# nisupdkeys groups_dir.doc.com. |
必要に応じて、cred テーブルから古いセキュリティメカニズムの資格を削除できます。そのためには、ローカルドメインの cred テーブルに対する変更権が必要です。詳細は、「資格情報の削除」の項を参照してください。
この例では、主体 morena.doc.com が自分の des 資格を cred テーブルから削除します。
master# nisaddcred -r morena.doc.com. dh192-0 |
この章では、NIS+ アクセス権とその管理方法について説明します。
NIS+ セキュリティタスクには、Solstice AdminSuite ツールがあればより簡単に実行できるものがあります。
NIS+ アクセス権とは、どの NIS+ ユーザーがどの操作を行うことができるか、どの情報にアクセスすることができるかを決めたものです。ここでの説明は、読者が NIS+ セキュリティシステム全般に関する知識を有し、NIS+ セキュリティシステムにおけるアクセス権の役割を理解していることを前提としています (詳細は第 6 章「セキュリティの概要」を参照)。
NIS+ アクセス関連のコマンドとその構文、オプションについては、nis+(1) のマニュアルページを参照してください。
承認とアクセス権が NIS+ 資格および認証とどのように関連して NIS+ 名前空間のセキュリティを維持しているかについては、「NIS+ の承認とアクセス - 紹介」および第 6 章「セキュリティの概要」を参照してください。
「承認クラス」に説明のあるように、NIS+ のアクセス権は各クラスに与えられるものです。4 つの NIS+ クラスが用意されています。
「所有者」
所有者クラスは 1 つの NIS+ 主体です。デフォルトではオブジェクトの所有者は、オブジェクトを作成した主体になります。しかし、オブジェクトの所有者は所有権を別の主体に譲ることで所有者を変更できます。
「グループ」
グループクラスは 1 つ以上の NIS+ 主体の集まりです。1 つの NIS+ オブジェクトは 1 つだけの NIS+ グループを持つことができます。
「その他」
その他クラスには、NIS+ に認証された NIS+ 主体のすべて (すべての所有者クラスとグループクラス、および有効な DES 資格を提示したものすべて) が含まれます。
「未認証」
未認証クラスは、すべての適切な認証を受けられなかったもので構成されます。すなわち、有効な DES 資格を提示できなかったすべてのものです。
「NIS+ のアクセス権について」で詳述したように、NIS+ には 4 種類のアクセス権があります。
「読み取り」
オブジェクトに対する読み取り権を持った主体がオブジェクトの内容を読み取れます。
「変更」
「削除」
「作成」
上位レベルのオブジェクトに対する作成権を持った主体が、そのレベルの下位に新規のオブジェクトを作成できます。つまり、NIS+ ディレクトリオブジェクトに対して作成権を持っていれば、そのディレクトリ内に新規のテーブルを作成できます。NIS+ テーブルに対する作成権があれば、そのテーブル内に新規の列とエントリを作成できます。
これらの権限は論理的には、ディレクトリ、テーブル、列とエントリのように下位に展開するものであることを銘記してください。たとえば、新規にテーブルを作成するには、そのテーブルを格納する NIS+ ディレクトリオブジェクトに対する作成権が必要です。そのテーブルを作成した場合、そのデフォルト所有者になります。所有者として、自分自身にそのテーブルに対する作成権を与え、テーブルに新規のエントリを作成できます。テーブル内に新規のエントリを作成した場合、それらのエントリの所有者になります。テーブルの所有者として、テーブルレベルの作成権を他の人に与えることもできます。たとえば、自身のテーブルのグループクラスのテーブルレベルの作成権を与えることができます。その場合、テーブルのグループのすべてのメンバーがテーブル内に新規のエントリを作成できます。新規のテーブルエントリを作成した、グループの個々のメンバーはそのエントリのデフォルト所有者になります。
承認クラスは連鎖の関係にあります。つまり、上位クラスは通常下位クラスにも属しており、自動的に下位クラスの権限を得ることになります。次のように機能します。
「所有者クラス」
オブジェクトの所有者はそのオブジェクトのグループに所属していても、いなくてもかまいません。所有者があるグループに属していると、そのグループに与えられている権限をすべて得ることになります。オブジェクトの所有者が自動的に、その他と未認証のクラスにも属することになり、自動的にこれら 2 つのクラスに与えられている権限を獲得することになります。
「グループクラス」
オブジェクトのグループメンバーは自動的にその他と未認証クラスに所属します。したがって、グループメンバーは自動的にその他クラスと未認証クラスのメンバーがそのオブジェクトに持っている権限を獲得します。
「その他クラス」
「未認証クラス」
この基本原則は、下位クラスのアクセス権は自動的に上位クラスに与えられるということです。つまり、上位クラスは下位クラスよりも多くの権限を持つことができ、権限が少なくなることはないということです (この原則の例外は、もし所有者がグループのメンバーでなければ、所有者の持っていない権限をグループクラスに与えることが可能になる場合)。
NIS+ オブジェクトを作成した時、NIS+ はそのオブジェクトに所有者クラスとグループクラスのアクセス権のデフォルトセットを与えます。デフォルトでは、所有者はそのオブジェクトを作成した NIS+ 主体です。デフォルトのグループは NIS_GROUP
の環境変数で指定されたグループになります (詳細は、「デフォルトのアクセス権」を参照)。
NIS+ は NIS+ オブジェクトが作成された時に自動的に付与されたデフォルト権限を変更する 2 つの異なった方法を提供しています。
NIS_DEFAULTS
環境変数。NIS_DEFAULTS
はセキュリティに関するデフォルト値を保管し、その 1 つはアクセス権です。このデフォルトアクセス権は、オブジェクトが作成された時にオブジェクトに自動的に付与されるものです。(詳細は、「NIS+ デフォルトの表示 - nisdefaults コマンド」を参照してください。)
NIS_DEFAULTS
環境変数の値を変更すると、変更後に作成されたオブジェクトに新規の値が与えられます。しかし、以前に作成されたオブジェクトは影響を受けません。
-D オプションはいくつかの NIS+ コマンドに用いられます。NIS+ オブジェクトを作成するコマンドに -D オプションを使用すると、NIS_DEFAULTS
環境変数が指定したデフォルト権限を上書きします。(詳細は、「デフォルトを無効にする」を参照してください。
NIS+ オブジェクトを作成する場合、既存のデフォルトアクセス権 (NIS_DEFAULTS
環境変数か -D オプションの指定かのいずれかによる) に対処する必要があります。デフォルト権限を変更するコマンドは次のとおりです。
NIS+ テーブルに対するアクセス権を指定する方法には、次の 3 通りあります。
「テーブル」全体を対象にアクセス権を指定する
「エントリ」(行) 単位でアクセス権を指定する
「列」単位でアクセス権を指定する
列とエントリ (行) が交差する部分をフィールドといいます。データ値はすべてこの交差領域、つまりフィールドに入力します。
列とエントリレベルのアクセス権を持っていると、テーブルレベルのアクセス権の制限があっても個々の行と列にアクセスできますが、テーブル全体へのアクセス権以上に列とエントリレベルの権限を制限することはできません。
「テーブル」
テーブルレベルは基本的なレベルです。テーブルレベルに付与されたアクセス権は、列ごとまたはエントリごとに特に変更された場合を除き、テーブル内のすべての部分に適用されます。テーブルレベルの権限は最も厳格であるべきです。
承認クラスは連結しているということに注意してください。上位クラスは、下位クラスに割り当てられた権利を取得していることになります。「アクセス権の連鎖」を参照してください。
「列」
列レベルの権限を持っていると、列ごとに追加アクセス権を持つことになります。たとえば、その他クラスと未認証クラスにテーブルレベルの権限が何も付与されていなかったとします。この場合、この 2 つのクラスはテーブル内のデータに対して、読み取り権、変更権、作成権、削除権を持ちません。列レベルの権限を持てば、テーブルレベルの権限の制限を超えて、その他クラスのメンバーであっても特定の列のデータを読み取ることができます。
一方、所有者クラスとグループクラスにテーブル全体の読み取り権が付与されている場合、列レベルの権限を使ってグループクラスの列の読み取り権を妨げることはできません。
列のグループはテーブルのグループやエントリのグループと同じにはなりません。これらはまったく異なるグループです。
「エントリ (行)」
エントリレベルの権限があれば、行ごとに追加アクセス権を持つことになります。たとえば、個々のユーザーに指定したエントリに限って変更する権限を与えることができるのです。
エントリのグループはテーブルのグループとは同じである必要はなく、別のグループにできます。そうすることによって、特定のグループのメンバーに、他のグループに属するエントリに影響を与えないで、あるエントリのセットにアクセスする権限を付与できます。
列またはエントリレベルのアクセス権は、追加アクセスを次の 2 つの方法で提供できます。1 つは権限を持つ主体を増やす方法で、もう 1 つは同じ主体に権限を追加する方法です。もちろん、これらを組み合わせることも可能です。以下にその例を示します。
テーブルオブジェクトが、そのテーブルの所有者に対して読み取り権を与えたとします。
表 10-1 テーブル、列、エントリの例 1
|
未認証 |
所有者 |
グループ |
その他 |
---|---|---|---|---|
テーブルのアクセス権 |
---- |
r--- |
---- |
---- |
このことは、テーブルの所有者だけがテーブル全体の内容を読み取れることを意味します。所有者でない主体は、アクセスできません。テーブルのエントリ 2 にグループクラスに対して読み取り権を与えることができます。
表 10-2 テーブル、列、エントリの例 2
|
未認証 |
所有者 |
グループ |
その他 |
---|---|---|---|---|
テーブルのアクセス権 |
---- |
r--- |
---- |
---- |
エントリ 2 のアクセス権 |
---- |
---- |
r--- |
---- |
テーブルの内容をすべて読み取れるのは所有者だけですが、このテーブルのグループのメンバーであれば、この特定エントリの内容を読み取ることができます。次に、特定の列がその他クラスに読み取り権を与えたとします。
表 10-3 テーブル、列、エントリの例 3
|
未認証 |
所有者 |
グループ |
その他 |
---|---|---|---|---|
テーブルのアクセス権 |
---- |
r--- |
---- |
---- |
エントリ 2 のアクセス権 |
---- |
---- |
r--- |
---- |
列 1 のアクセス権 |
---- |
---- |
---- |
r--- |
その他のクラスのメンバーは列 1 のすべてのエントリを読み取ることができます (表 10-4 の薄い影の部分)。グループクラスのメンバーは (その他クラスにも属しているので) 列 1 のすべてとエントリ 2 の全列を読み取ることができます (表 10-4 の濃い影の部分)。*NP* になっている列は、「グループ」、「その他」いずれのクラスも読み取りができません (どちらにもアクセス権がない)。
表 10-4 テーブル、列、エントリの例 4
|
列 1 |
列 2 |
列 2 |
---|---|---|---|
エントリ 1 |
読み取り |
*NP* |
*NP* |
エントリ 2 |
読み取り |
読み取り |
読み取り |
エントリ 3 |
読み取り |
*NP* |
*NP* |
エントリ 4 |
読み取り |
*NP* |
*NP* |
エントリ 5 |
読み取り |
*NP* |
*NP* |
この節では 4 つの権限 (読み取り、作成、変更、削除) が 4 つのアクセスレベル (ディレクトリ、テーブル、列、エントリ) とどのようにかかわるのかを説明します。
種々の権限とレベルに関係した機能を次の表 10-5 にまとめます。
表 10-5 アクセス権、アクセスレベル、およびその機能
|
ディレクトリ |
テーブル |
列 |
エントリ |
---|---|---|---|---|
読み取り |
ディレクトリ内容のリスト |
テーブル内容の読み取り |
列内容の読み取り |
エントリ (行) 内容の読み取り |
作成 |
新規ディレクトリまたはテーブルオブジェクトの作成 |
新規エントリ (行) の追加 |
列に新規のデータを入力 |
エントリ (行) に新規のデータを入力 |
変更 |
オブジェクトの移動とオブジェクト名の変更 |
テーブル内の任意のデータを変更 |
列内のデータを変更 |
エントリ (行) 内のデータを変更 |
削除 |
テーブル等のディレクトリオブジェクトの削除 |
エントリ (行) の削除 |
列内のデータの削除 |
エントリ (行) 内のデータの削除 |
「ディレクトリ」
ディレクトリの読み取り権があれば、ディレクトリの内容を表示できます。
「テーブル」
テーブルの読み取り権があれば、テーブル内のすべてのデータを読み取れます。
「列」
列の読み取り権があれば、その列のすべてのデータを読み取れます。
「エントリ」
エントリの読み取り権があれば、そのエントリのすべてのデータを読み取れます。
「ディレクトリ」
ディレクトリレベルの作成権があれば、テーブル等の新規オブジェクトをディレクトリ内に作成できます。
「テーブル」
テーブルレベルの作成権があれば、テーブル内に新規のエントリを作成できますが、列は作成できません。テーブルレベルの作成権だけでは、テーブルに新規のエントリを追加できますが、新規の列を追加することはできません。
「列」
列の作成権があれば、列内のフィールドに新規のデータを入力できます。新規の列を作成できません。
「エントリ」
エントリの作成権があれば、その行のフィールドに新規のデータを入力できます。(エントリレベルの作成権では新規の行を作成することはできません。)
「ディレクトリ」
ディレクトリレベルの変更権があれば、ディレクトリオブジェクトの移動と名前の変更ができます。
「テーブル」
テーブルレベルの変更権があれば、テーブル内のデータをすべて変更できます。新規の行を作成 (追加) できますが、新規の列は作成できません。空白フィールドにデータを入力することも可能です。
「列」
列の変更権があれば、その列の任意のフィールドのデータを変更できます。
「エントリ」
エントリの変更権があれば、その行の任意のフィールドのデータを変更できます。
「ディレクトリ」
ディレクトリレベルの削除権があれば、テーブル等のディレクトリ内の既存オブジェクトを削除できます。
「テーブル」
テーブルレベルの削除権があれば、テーブル内の既存のエントリ (行) を削除できますが、列は削除できません。削除できるのは既存のエントリだけで、既存の列は削除できません。
「列」
列の削除権があれば、その列の任意のフィールドのデータを削除できます。
「エントリ」
エントリの削除権があれば、その行の任意のフィールドのデータを削除できます。
オブジェクトのアクセス権は、そのオブジェクトの定義の一部として指定され、格納されます。この情報は NIS+ テーブルには格納されません。
アクセス権を読み取るには niscat コマンドを使用します。
niscat -o objectname |
アクセス権を読み取るオブジェクト名を指定します。
このコマンドは、NIS+ オブジェクトに関する次の情報を返します。
「所有者」
所有権を持っている NIS+ 主体。通常はオブジェクトを作成した人ですが、元の所有者が所有権を渡した場合もある
「グループ」
オブジェクトの NIS+ 主体
「未認証クラスのアクセス権」
認証された (有効な DES 資格を提示した) か否かにかかわらず、全員が持つ権限
「所有者クラスのアクセス権」
オブジェクトの所有者に付与されたアクセス権
「グループクラスのアクセス権」
「その他クラスのアクセス権」
認証された NIS+ 主体全てに付与されたアクセス権
4 つの承認クラスのアクセス権は、次のように 16 文字の文字列で表示されます。
r---rmcdr---r--- |
各文字がアクセス権の種類を表します。
r は読み取り権
m は変更権
d は削除権
c は作成権
- はアクセス権のないことを表す
先頭の 4 文字は未認証に、次の 4 文字は所有者に、その次の 4 文字はグループに、そして最後の 4 文字はその他に、それぞれ与えられたアクセス権を表します。
UNIX ファイルシステムとは異なり、先頭のアクセス権は未認証用であり、所有者用ではありません。
オブジェクトを作成すると、NIS+ はそのオブジェクトにデフォルトの所有者、グループ、および アクセス権を割り当てます。デフォルトの所有者は、そのオブジェクトを作成する NIS+ 主体です。デフォルトのグループは、環境変数 NIS_GROUP
の中で名前をつけられたグループです。デフォルトのアクセス権は次のようになります。
未認証 |
所有者 |
グループ |
その他 |
---|---|---|---|
- |
読み取り |
読み取り |
読み取り |
- |
変更 |
- |
- |
- |
作成 |
- |
- |
- |
削除 |
- |
- |
環境変数 NIS_DEFAULTS
のセットがある場合、NIS_DEFAULTS
内の値が新規のオブジェクトに適用されるデフォルト値を決定します。コマンド行でオブジェクトを作成した場合は、-D フラグを使ってデフォルト値以外を設定できます。
この節では、読み取り、変更、削除、作成の操作が行われる際、テーブルオブジェクト、エントリ、列に対するアクセス権をサーバーが各クラスにどのように割り当てるかということについて説明します。
セキュリティレベル 0 では、サーバーはアクセス権を実行しないため、すべてのクライアントがテーブルオブジェクトに対する完全なアクセス権を付与されます。セキュリティレベル 0 は管理者だけがテストの目的で使用します。通常の業務にはレベル 0 を使用しないでください。
サーバーがアクセスを許可するか否かを決定する 4 つの要素があります。
主体が要求する処理の種類
主体がアクセスしようとしているテーブル、エントリ、または列
その特定のオブジェクトに対して、主体が所属する承認クラス
テーブル、エントリ、または列がその主体の承認クラスに割り当てたアクセス権
認証後に主体は、主体が有効な DES 資格を所持しているかを確認することで要求を行い、NIS+ サーバーは処理の種類と要求のオブジェクトを決定します。
「ディレクトリ」
オブジェクトがディレクトリかグループの場合、サーバーは 4 つのクラスに付与されている権限を知るためにオブジェクトの定義をチェックし、どのクラスに主体が所属しているか判定し、主体のクラスとそのクラスに付与された権限に基づいて、その要求を受け入れるかまたは拒否します。
「テーブル」
オブジェクトがテーブルの場合、サーバーは 4 つのクラスに付与されているテーブルレベルの権限を知るためにテーブルの定義をチェックし、どのクラスに主体が所属しているか判定します。所属しているクラスが要求処理を行うテーブルレベルの権限を持っていない場合は、サーバーは次にどの行または列にかかわる処理かを判定し、要求処理に必要な該当する行または列レベルのアクセス権があるかを決定します。
ここでの説明では、NIS+ 環境のセキュリティレベルが 2 (デフォルト) であるものと想定しています。
この節では、この章で説明するコマンドを使用するときにアクセス権や所有者、グループ所有者、オブジェクトを指定する方法を説明します。
この節では、承認とアクセス権に関係する NIS+ コマンドに使われるアクセス権の構文について説明します。
アクセス権は、環境変数で指定する場合もコマンドで指定する場合も、「クラス (class)」、「演算子 (operator)」、「権利 (right)」という 3 種類の引数で区別されます。
「クラス」
クラスは、「権利」が適用される NIS+ 主体のカテゴリを意味します。
クラス |
説明 |
---|---|
n |
未認証: すべての未認証要求 |
o |
オブジェクトまたはテーブルエントリの所有者 |
g |
オブジェクトまたはテーブルエントリのグループ所有者 |
w |
その他: すべての認証済み主体 |
a |
すべて: 所有者、グループ、およびその他の省略形。これはデフォルト |
「演算子」
演算子は、「権限」について行われる操作を示します。
演算子 |
説明 |
---|---|
+ |
「権利」によって指定されたアクセス権を追加する |
- |
「権利」によって指定されたアクセス権を取り消す |
= |
この演算子権利によって指定されたアクセス権に変更する。つまり、既存の「権利」をすべて取り消し、新しいアクセス権に置き換える |
「権限」
アクセス権そのものです。使用可能な値は次のとおりです。
権利 |
説明 |
---|---|
r |
オブジェクト定義またはテーブルエントリを読み取る |
m |
オブジェクト定義またはテーブルエントリを変更する |
c |
テーブルエントリまたは列を作成する |
d |
テーブルエントリまたは列を削除する |
コンマ (,) で区切ることで、複数のコマンドを 1 つのコマンド行にまとめることができます。
表 10-10 クラス、演算子、権限の構文 - 例
操作 |
構文 |
---|---|
読み取りアクセス権を「所有者」クラスに追加する |
o+r |
変更アクセス権を所有者、グループ、およびその他のクラスに追加する |
a=m |
読み取りと変更の権限をその他と未認証クラスに追加する |
wn+m |
グループ、その他、および未認証クラスから 4 つの権限をすべて削除する |
gwn-rmcd |
所有者クラスに作成と削除の権限を追加し、その他と未認証クラスに読み取り権と変更権を追加する |
o+cd,wn+rm |
「所有者」
NIS+ グループを指定するには、NIS+ グループ名にドメイン名を付けて使います。
「グループ」
NIS+ グループを指定するには、NIS+ グループ名にドメイン名を付けて使います。
主体名は完全指定されていることに注意してください。
( principalname.domainname )
所有者
principalname |
グループ
groupname.domainname |
オブジェクトとテーブルエントリは異なる構文を使います。
オブジェクトは単純なオブジェクト名を使います。
テーブルエントリはインデックス付きの名前を使います。
オブジェクト
objectname |
テーブルエントリ
[columnname=value],tablename |
この場合、角括弧 ( [ ] ) は構文の一部であり、オプション記号ではありません。
インデックス付きの名前では、列と値のペアを複数指定できます。その場合、操作はすべての列と値のペアに一致するエントリにだけ適用されます。列と値のペアが増えると、検索条件が厳しくなります。
以下に例を示します。
表 10-11 オブジェクトとエントリの構文
型 |
例 |
---|---|
オブジェクト |
hosts.org_dir.sales.doc.com. |
テーブルエントリ |
`[uid=33555],passwd.org_dir.Eng.doc.com.' |
2 つの値のテーブルエントリ |
`[name=sales,gid=2],group.org_dir.doc.com.' |
列はインデックス付きの名前の特殊な形式になっています。列の操作は nistbladm コマンドでだけ可能なため、詳細は、「nistbladm コマンド」を参照してください。
nisdefaults コマンドは、名前空間内で現在有効な 7 つのデフォルトを表示します。これらのデフォルトは次のいずれかです。
オブジェクトを作成する時に -D オプション付きのコマンドを使って上書きしなければ、このマシン上でオブジェクトを作成すると自動的にデフォルト値を獲得することになります。
表 10-12 7 つの NIS+ デフォルト値と nisdefaults オプション
デフォルト |
オプション |
元データ |
説明 |
---|---|---|---|
ドメイン |
-d |
/etc/defaultdomain |
コマンドを入力したワークステーションのホームドメインを表示する |
グループ |
-g |
環境変数 |
このシェルが作成する次のオブジェクトに付与されるグループを表示する |
ホスト |
-h |
uname -n |
ワークステーションのホスト名を表示する |
主体 |
-p |
gethostbyname() |
nisdefaults コマンドを入力した NIS+ 主体の完全指定ユーザー 名またはホスト名を表示する |
アクセス権 |
-r |
|
このシェルが作成する次のオブジェクトまたはエントリに付与されるアクセス権を表示する。 フォーマット:----rmcdr---r--- |
検索パス |
-s |
環境変数 |
検索パスの構文を表示する。これは NIS+ が情報を検索する時のドメインを示す。もし設定してあれば、環境変数 |
生存期間 |
-t |
環境変数 |
このシェルが作成する次のオブジェクトに付与される生存期間を表示する。デフォルトは 12 時間 |
全部 (簡潔) |
-a |
|
7 つのデフォルトすべてを簡潔フォーマットで表示する |
冗長 |
-v |
|
指定した値を冗長モードで表示する |
これらのオプションを使用して、すべてのデフォルト値もしくはそのサブセットを表示できます。
master% nisdefaults Principal Name : topadmin.doc.com. Domain Name : doc.com. Host Name : rootmaster.doc.com. Group Name : salesboss Access Rights : ----rmcdr---r--- Time to live : 12:00:00:00:00 Search Path : doc.com. |
すべての値を簡潔フォーマットで表示するには、-a オプションを付けます。
値のサブセットを表示するには、適切なオプションを使用します。その値は簡潔モードで表示されます。権限と検索パスのデフォルトを簡潔モードで表示する例を次に示します。
rootmaster% nisdefaults -rs ----rmcdr---r--- doc.com. |
値のサブセットを冗長モードで表示するには、-v フラグを使用します。
この節では、nisdefaults コマンド、環境変数 NIS_DEFAULTS
、および -D オプションに関連したタスクを実行する方法を説明します。環境変数 NIS_DEFAULTS
は次のデフォルト値を指定します。
所有者
グループ
アクセス権
生存期間
環境変数 NIS_DEFAULTS
に設定した値はデフォルトとなり、そのシェルを使用して作成したすべての NIS+ オブジェクトに適用されます (-D オプション付きでコマンドを実行してデフォルト値に上書きした場合を除く)。
環境変数 NIS_DEFAULTS
を指定することで、デフォルト値 (所有者、グループ、アクセス権、および生存期間) を指定できます。一度 NIS_DEFAULTS の値を設定するとそのシェルから作成したすべてのオブジェクトは、-D オプション付きでコマンドを実行して上書きした場合を除きそのデフォルトに設定されます。
echo コマンドを使って、環境変数の値をチェックできます。以下にその例を示します。
client% echo $NIS_DEFAULTS owner=butler:group=gamblers:access=o+rmcd |
nisdefaults コマンドを使用して、名前空間でアクティブな NIS+ デフォルトの一般的リストを表示することも可能です。「NIS+ デフォルトの表示 - nisdefaults コマンド」を参照してください。
環境変数 NIS_DEFAULTS
の値を変更することで、アクセス権、所有者、およびグループのデフォルトを変更できます。ユーザーのシェルに適切な環境コマンド (csh には setenv、sh と ksh には $NIS_DEFAULTS=, export) を次の引数を付けて使用します。
access=アクセス権 (「コマンドによるアクセス権の指定」で説明されたフォーマットを使って)
owner=所有者名
group=グループ名
複数の引数をまとめる場合は、コロン (:) で区切ります。
owner= 主体名 :group= グループ名
表 10-13 に例をいくつか示します。
表 10-13 デフォルトの変更例
作業 |
例 |
---|---|
所有者のデフォルトアクセス権に読み取り権を設定 |
client% setenv NIS_DEFAULTS access=o+r |
デフォルトの所有者をホームドメインが doc.com. である abe に設定 |
client% setenv NIS_DEFAULTS owner=abe.doc.com. |
2 つのコード行をまとめる |
client% setenv NIS_DEFAULTS access=o+r:owner=abe.doc.com. |
デフォルトを変更したシェルから作成されるすべてのオブジェクトとエントリは、指定した新規の値になります。テーブルの列またはエントリに対してはデフォルトを指定できません。列とエントリはデフォルトをそのまま継承します。
変数 NIS_DEFAULTS
をオリジナルの値に再設定するには、ユーザーのシェルに適したフォーマットを使って、引数なしで変数の名前を入力します。
C シェルの場合
client# unsetenv NIS_DEFAULTS |
Bourne シェルまたは Korn シェルの場合
client$ NIS_DEFAULTS=; export NIS_DEFAULTS |
次の NIS+ コマンドのどれかを使えば、NIS+ オブジェクトまたはテーブルエントリを作成する時に、いつでもデフォルトのアクセス権、所有者、およびグループを無効にできます。
デフォルト値を無効にするには、「コマンドによるアクセス権の指定」の説明のように、コマンドの構文に -D オプションを挿入します。
デフォルトを設定する時と同様、複数の引数を 1 行のコマンド行で指定できます。なお、列とエントリの所有者とグループは常に同じであるため、これらを無効にすることはできません。
nismkdir コマンドを使用して、sales.doc.com ディレクトリを作成し、デフォルトアクセス権を無効にして所有者にだけ読み取り権を付与するには、次のように入力します。
client% nismkdir -D access=o+r sales.doc.com |
nischmod コマンドは、NIS+ オブジェクトまたはテーブルエントリのアクセス権を変更します。テーブル列のアクセス権は操作しません。列の場合、nistbladm コマンドに -D オプションを付けて実行してください。nischmod コマンドを使用するには、そのオブジェクトかエントリに対する変更権が必要です。
オブジェクトまたはエントリに権限を追加する例を次に示します。
オブジェクト
nischmod class+right object-name |
テーブルエントリ
nischmod class+right [column-name=value],table-name |
sales.doc.com. ディレクトリオブジェクトのグループに読み取り権と変更権を追加する場合は、次のように入力します。
client% nischmod g+rm sales.doc.com. |
hosts.org_dir.doc.com. テーブル内の name=abe エントリのグループに読み取り権と変更権を追加する場合は、次のように入力します。
client% nischmod g+rm '[name=abe],hosts.org_dir.doc.com.' |
オブジェクトまたはエントリの権限を削除するには、次のように入力します。
オブジェクト
nischmod class-right object-name |
エントリ
nischmod class-right [column-name=value], table-name |
sales.doc.com. ディレクトリオブジェクトのグループから作成権と削除権を削除するには次のように入力します。
client% nischmod g-cd sales.doc.com. |
たとえば、hosts.org_dir.doc.com. テーブル内の name=abe エントリのグループから削除権を削除する場合は、次のようにします。
client% nischmod g-d '[name=abe],hosts.org_dir.doc.com.' |
nistbladm コマンドは NIS+ テーブルに種々の操作を行うことができます。これについては 「nistbladm コマンド」にほとんどの説明があります。このコマンドは -c と -u の 2 つのオプションを使用してセキュリティ関連のタスクを実行できます。
-c オプション。nistbladm コマンドを使用して テーブルを作成する際に、-c オプションを使用すると最初の列アクセス権を指定できます。
-u オプション。-u オプションを nistbladm コマンドとともに使用すると、列アクセス権を変更できます。
テーブルが作成された時、列にはテーブルオブジェクトと同じ権限が付与されます。このテーブルレベルの権限は環境変数 NIS_DEFAULTS
で指定されるか、またはテーブルを作成したコマンドの一部で指定されます。nistbladm コマンドでテーブルを作成する際に -c オプションを使用すれば、最初の列アクセス権を指定できます。このオプションを使用するには、テーブルを作成しようとするディレクトリの作成権が必要です。テーブル作成時に列権限を指定するには、次のように入力します。
nistbladm -c type ` columname=[flags] [, access]... tablename' |
type はテーブルの種類を示す文字列です。テーブルの type は何にでもできます。
columnname は列名です。
flags には、列の種類を指定します。使用できるフラグには次のものがあります。
S (検索可能)
I (大文字と小文字を区別しない)
C (暗号化)
B (2 進データ)
X (XDR 符号化データ)
access は、「コマンドによるアクセス権の指定」で説明した構文を使用したこの列のアクセス権です。
... はそれぞれの型と権限のセットを持った複数の列を指定できることを示しています。
tablename は完全指定名で表した作成しようとするテーブル名です。
テーブルを作成する際、その列にはテーブルオブジェクトと同じ権限が付与されます。列に独自の権限を付与するには、列の型とコンマの後の各列の等号記号にアクセス権を追加し、列をスペースで区切ります。
column=type, rights column= type, rights column = type, rights |
以下の例では、div 特性で depts という名前のテーブルが doc.com ディレクトリに作成されます。列は Name、Site および Manager の 3 つです。第 2、第 3 列のグループには、変更権が追加されます。
rootmaster% nistbladm -c div Name=S Site=S,g+m Manager=S,g+m depts.doc.com. |
nistbladm -c オプションの詳細は、第 14 章「NIS+ テーブルの管理」を参照してください。
既存の NIS+ テーブルの列にアクセス権を追加するには、nistbladm -u オプション付きの nistbladm コマンドを使用します。このオプションを使用する場合、テーブル列の変更権が必要です。入力例を次に示します。
nistbladm -u [column= access,...],tablename |
column は列名です。
access は、「コマンドによるアクセス権の指定」で説明した構文を使用したこの列のアクセス権です。
... はそれぞれの type と権限のセットを持った複数の列を指定できることを示しています。
tablename は完全指定名で表した作成しようとするテーブル名です。
権限を更新する列ごとに column=access のペアを使用します。複数の列を更新するにはコンマ (,) で区切り全体を角括弧 ( [] ) で囲みます。
[column=access, column=access, column=access] |
(このオプションの完全な構文については、「nistbladm コマンド」を参照してください。)
次の例は、hosts.org_dir.doc.com. テーブルの name および addr 列のグループに、作成権と変更権を追加するものです。
client% nistbladm -u `[name=g+rm,addr=g+rm],hosts.org_dir..doc.com.' |
NIS+ テーブル列のアクセス権を削除するには、上記 「既存のテーブル列に権限を追加する」で説明したように -u オプションを使用します。ただし + 記号を使って権限を追加するのではなく、− 記号を使って権限を削除します。
次の例は、hosts.org_dir.doc.com. テーブルの hostname 列のグループの読み取り権と変更権を削除するものです。
client% nistbladm -u 'name=g-rm,hosts.org_dir.doc.com.' |
nischown コマンドは、1 つ以上のオブジェクトまたはエントリの所有者を変更します。このコマンドを使用するには、オブジェクトまたはエントリに対する変更権が必要です。テーブルの列の所有者はテーブルの所有者であるため、nischown コマンドでは列の所有者を変更できません。列の所有者を変更するには、テーブルの所有者を変更する必要があります。
オブジェクトの所有者を変更するには、次のように入力します。
nischown new-owner object |
new-owner はそのオブジェクトの新規の所有者のユーザー ID で完全指定します。
object はそのオブジェクトの完全指定名です。
オブジェクト名と新規所有者名にドメイン名を必ず追加します。
次の例は、doc.com. ドメイン内の hosts テーブルの所有者を、ホームドメインが doc.com. でユーザー名 lincoln であるユーザーに変更するものです。
client% nischown lincoln.doc.com. hosts.org_dir.doc.com. |
テーブルエントリの所有者を変更する構文は、エントリを特定するのにインデックス付きエントリを使います。次に例を示します。この構文の詳細は、「オブジェクトとテーブルエントリの構文」を参照してください。
nischown new-owner [ column=value,...], tablename |
new-owner はそのオブジェクトの新規の所有者のユーザー ID で完全指定します。
column は、所有者を変更するエントリ (行) を特定する値を持った列名です。
value は、所有者を変更するエントリ (行) を特定するデータ値です。
... は所有者を変更する複数のエントリを示します。
tablename は、所有者を変更するエントリを含むテーブルの完全指定名です。
所有者名とテーブル名にドメイン名を必ず追加します。
次の例は、doc.com. ドメインのホストテーブル内のエントリの所有者を、ホームドメインが doc.com. であるユーザー takeda に変更するものです。そのエントリの name 列の値は virginia です。
client% nischown takeda.doc.com. '[name=virginia],hosts.org_dir.doc.com.' |
nischgrp コマンドは、1 つ以上のオブジェクトまたはテーブルエントリのグループ所有者を変更します。このコマンドを使用するには、オブジェクトまたはエントリに対する変更権が必要です。テーブルの列に割り当てられたグループは、テーブルに割り当てられたグループと同じであるため、nischgrp コマンドは、列のグループを変更できません。列のグループ所有者を変更するには、テーブル所有者を変更する必要があります。
オブジェクトのグループを変更するには、次の構文を使用します。
nischgrp group object |
ここで、
group はオブジェクトの新規のグループの完全指定名です
object はオブジェクトの完全指定名です
オブジェクト名と新規のグループ名にはドメイン名を必ず追加します。
次の例は、doc.com. ドメイン内の hosts テーブルのグループを admins.doc.com. に変更するものです。
client% nischgrp admins.doc.com. hosts.org_dir.doc.com. |
テーブルエントリのグループを変更する構文は、エントリを識別するためにインデックス付きのエントリを使用します。(この構文については、「オブジェクトとテーブルエントリの構文」に詳細説明があります。) 以下に構文を示します。
nischgrp new-group [ column=value,...], tablename |
new-group はオブジェクトの新規グループの完全指定名です。
column は変更される特定のエントリ (行) を識別する値を持った列名です。
value は変更されるグループの特定の エントリ (行) を識別するデータ値です。
tablename は変更ことになるグループのエントリを含むテーブルの完全指定名です。
... は複数のエントリで変更するグループを指定できることを示します。
新規グループ名とテーブル名にはドメイン名を必ず追加します。
次の例は、doc.com. ドメインのホストテーブル内のエントリのグループを sales.doc.com. に変更するものです。そのエントリの name 列の値は virginia です。
client% nischgrp sales.doc.com. '[name=virginia],hosts.org_dir.doc.com.' |
この章では、一般ユーザー (NIS+ 主体) の観点から見た passwd コマンドの使用方法と、NIS+ 管理者によるパスワードシステムの管理方法を説明します。
NIS+ セキュリティタスクには、Solstice AdminSuite ツールが利用可能であればもっと簡単に実行できるものがあります。
マシンへのログインの際には、ユーザー名 (「ログイン ID」とも呼ばれる)、およびパスワードを入力する必要があります。ログイン ID は公開の情報ですが、パスワードを知っているのは所有者だけです。
システムへのログインは以下の手順で行います。
Login: プロンプトで、ログイン ID を入力します。
Password: プロンプトで、パスワードを入力します。
(秘密を守るため、入力してもパスワードは画面に表示されません)
ログインに成功すると、本日のメッセージ (ない場合もある)、続いてコマンド行プロンプト、ウィンドウシステム、通常のアプリケーションなどが表示されます。
「Login incorrect」というメッセージは以下のことを意味します。
「誤ったログイン ID あるいはパスワードを入力した」
最も一般的な理由です。スペルを確認してもう一度やり直します。誤入力の回数は、ほとんどのシステムで「5」に制限されているので注意してください。
誤入力の回数が制限を超えると、「Too many failures - try later」というメッセージが表示され、一定の時間が経過するまで再試行ができなくなります。
指定された時間内にログインが成功しないと、「Too many tries; try again later」というメッセージが表示され、一定の時間が経過するまで再試行できなくなります。
「管理者がパスワードをロックしている」
ログイン ID、パスワードともに正しく入力しているにもかかわらず「Login incorrect」メッセージが表示される場合は、システム管理者に問い合わせてください。
「パスワード使用権がシステム管理者によって取り消された」
ログイン ID、パスワードともに正しく入力しているにもかかわらず「Login incorrect」メッセージが表示される場合は、システム管理者に問い合わせてください。
このメッセージは、「パスワードが有効期限を過ぎている」ということを意味します。つまり、パスワードを作成してから時間が経ちすぎているので、すぐに作成し直す必要があるということです (新しいパスワードを作成する場合の必要条件については、「パスワードの選択」を参照してください)。
この場合、新しいパスワードの作成は以下の手順で行います。
Enter login password (多少異なる場合がある) プロンプトで、従来のパスワードを入力します。
キー入力の内容は画面には表示されません。
Enter new password プロンプトで、新しいパスワードを入力します。
キー入力の内容は画面には表示されません。
Re-enter new password プロンプトで、新しいパスワードをもう一度入力します。
キー入力の内容は画面には表示されません。
このメッセージ (あるいは「Your password will expire within 24 hours」というメッセージ) は、「パスワードが、N 日あるいは 24 時間以内に有効期限に達する」ということを意味します。
このメッセージが表示されたら、パスワードをすぐに変更する必要があります (「パスワードの変更」を参照)。
ログイン ID およびパスワードを入力したあと、このメッセージが表示されて login: プロンプトに戻った場合は、「管理者によってパスワードがロックされた、アカウントが取り消された、パスワード使用権の有効期限が過ぎたなどの理由で、ログインが正しく行われなかった」ということを意味します。このような場合、管理者がパスワードロックを解除するか、アカウントを復旧するまではログインができません。システム管理者に問い合わせてください。
セキュリティを確保するため、パスワードは定期的に変更してください (新しいパスワードを作成する場合の必要条件、および基準については、「パスワードの選択」を参照)。
現在の passwd コマンドでは、以前 nispasswd で行なっていた操作がすべて行えます。NIS+ の名前空間に特有な操作を行うには、passwd -r nisplus を使用します。
パスワードの変更は以下の手順で行います。
システムプロンプトから passwd コマンドを実行します。
Enter login password (多少異なる場合がある) プロンプトで、従来のパスワードを入力します。キー入力の内容は画面には表示されません。
Enter new password プロンプトで、新しいパスワードを入力します
キー入力の内容は画面には表示されません。
この時点で、新しいパスワードが必要条件を満たしているかどうかがシステムによって確認されます。
満たしている場合は再入力を求められます。
満たしていない場合は、その旨を知らせるメッセージが表示されます。このときは、必要条件を満たす別のパスワードを入力する必要があります。
パスワードの必要条件については、「パスワードの必要条件」を参照してください。
Re-enter new password プロンプトで、新しいパスワードを再入力します。
キー入力の内容は画面には表示されません。
1 回目と 2 回目で入力したパスワードが異なっていた場合は、手順 1 から繰り返すようにプロンプトが表示されます。
root のパスワードを変更した場合は、その直後に必ず chkey -p を実行する必要があります(詳細は、「ルートからルート鍵を変更する」、および、「別のマシンからルート鍵を変更する手順」を参照してください)。root のパスワードを変更したあと chkey -p を実行しないと、root で正常にログインできなくなります。
システムの中には、パスワード変更の試行回数、所要時間に制限を設けているものもあります (他の人が試行錯誤によって勝手にパスワードを変更してしまうのを防ぐため)。
パスワード変更、ログインの試行回数、または所要時間が指定の範囲を超えた場合は、「Too many failures - try later」、または「Too many tries: try again later」といったメッセージが表示されます。この種のメッセージが表示されると、一定の時間 (システム管理者が指定) が経過するまでログイン、パスワードの変更は行えなくなります。
コンピュータのセキュリティの侵害の例としては、「他のユーザーのパスワードを推測によって盗む」というものが多くみられます。passwd コマンドには、パスワードを推測しにくいものにするための基準がいくつか設けられていますが、ユーザーに関していくつかの情報を得るだけでパスワードがわかってしまう人もいるのです。したがって、「自分にとって覚えやすく他人にとって推測しにくい」というのが良いパスワードです。逆に悪いパスワードとは、「自分にとって覚えにくく (メモしないと覚えられない)、自分を知る他人にとっては推測しやすい」というものです。
パスワードの必要条件は以下のとおりです。
「長さ」は 6 文字以上にします (デフォルト)。また意味を持つのは最初の 8 文字だけです (つまり、「8 文字より長いパスワードを作成することはできるが、システムは最初の 8 文字のみをチェックする」ということです)。パスワードの長さの最小値 (文字数) はシステム管理者によって変更される可能性があり、システムによっては 6 文字ではない場合があります。
「英文字」2 つ以上 (大文字、小文字どちらでも良い) と数字または記号 (@、#、% など) 1 つ以上で構成します。つまり、dog#food、dog2food といったパスワードは使用できますが、dogfood というパスワードは使用できません。
「ログイン ID と同じにならないようにします」。またログイン ID の文字を並べ替えたものも使用できません (この場合、大文字と小文字は同じものとして考える)。ログイン ID が Claire2 の場合、たとえば e2clair をパスワードとして使用できません。
「古いパスワードと同じにならないようにします」。古いパスワードを、少なくとも 3 文字以上入れ替える必要があります (この場合、大文字と小文字は同じものとして考える)。古いパスワードが Dog#fooD なら、新しいパスワードにたとえば dog#Meat は使用できますが、daT#Food は使用できません。
悪いパスワードの例としては以下のようなものが考えられます。
自分の名前をもとにしたもの
家族やペットの名前
運転免許証の番号
電話番号
社会保険の番号
従業員番号
趣味に関係のある名前
季節に関係のある名前 (たとえば 12 月に Santa を使うなど)
普通の辞書に載っている単語
普通に使われる言葉をそのままパスワードに使用しないようにします。辞書に載っていたら使えないものと思ってください。
良いパスワードの例としては以下のようなものが考えられます。
フレーズに数字や記号を加えたもの (例:beam#meup)
フレーズを構成する単語の頭文字に番号や記号を加えた意味のない言葉 (例:SomeWhere Over The RainBow の頭文字に 7 を加えた swotrb7)
単語の一部を数字や記号に置き換えたもの (例:snoopy ではなく、sn00py にする)
ここでは、NIS+ 名前空間の中でパスワードを管理する方法について説明します。この説明は、読者が NIS+ セキュリティシステム全般に関する知識を有し、NIS+ セキュリティシステムにおけるログインパスワードの役割を理解していることを前提としています (詳細は、第 6 章「セキュリティの概要」を参照)。
現在の passwd コマンドでは、以前 nispasswd で行なっていた操作がすべて行えます。NIS+ の名前空間に特有な操作を行うには、passwd -r nisplus を使用します。
passwd コマンドの使用や、パスワードの使用期間に関する設定を正しく行うには、nsswitch.conf ファイル中の passwd エントリがすべてのマシンにおいて正しくなければなりません。passwd コマンドが「パスワード情報をどこに要求するか」および「パスワード情報をどこで更新するか」は、このエントリによって決定されます。
passwd エントリの設定として考えられるのは、以下の 5 種類だけです。
passwd: files
passwd: files nis
passwd: files nisplus
passwd: compat
passwd: compat
passwd_compat: nisplus
ネットワーク上のすべてのワークステーションの nsswitch.conf ファイルで、上記の passwd エントリの設定のうちいずれかを使用する必要があります。上記の 5 つ以外の設定をすると、ログインができなくなります。
現在の passwd コマンドでは、以前 nispasswd で行なっていた操作がすべて行えます。コマンド行で実行するときは、nispasswd ではなく passwd を使用します。
旧バージョンとの互換性を確保するため、nispasswd も完全な形で残っている点に注意してください。
現在の passwd コマンドでは、以前 yppasswd で行なっていた操作がすべて行えます。コマンド行で実行するときは、yppasswd ではなく passwd を使用します。
旧バージョンとの互換性を確保するため、yppasswd も完全な形で残っている点に注意してください。
passwd コマンドでは、パスワードに関する様々な操作が行えます。現在の passwd コマンドは、nispasswd コマンドの代わりとして使用できます。従来 nispasswd で行なっていた操作にも、passwd コマンドを使用するようにしてください。passwd コマンドのフラグ、オプション、引数の詳細は、マニュアルページを参照してください。
一般ユーザーが passwd コマンドで行える操作には以下のものがあります。
自らのパスワードの変更
自らのパスワード情報の表示
管理者が passwd コマンドで行える操作には以下のものがあります。
他のユーザーにログイン時のパスワード変更を強制する
他のユーザーのパスワードをロック (使用不可能に) する
「パスワード作成後、どのくらいの期間変更禁止にするか」を指定する
「パスワードが間もなく無効になる」という警告を出すタイミングを指定する
パスワードの有効期間を指定する
passwd などのコマンドがパスワード情報をどこから得て、どこに保存するのかということは、nsswitch.conf ファイルで設定します。nsswitch.conf ファイルの passwd エントリの設定に使用する文字列はそれぞれ以下のことを意味します。
nisplus
nis
パスワード情報の獲得、変更、保存は、passwd マップで行う
files
パスワード情報の獲得、変更、保存は、/etc/passwd ファイルおよび /etc/shadow ファイルで行う
passwd コマンドの -r nisplus、-r nis、-r files といった引数は、nsswitch.conf ファイルの設定よりも優先されます。これらの引数をつけて passwd コマンドを実行すると、「nsswitch.conf ファイルより優先される」ということを知らせる警告メッセージが表示されます。警告メッセージ表示後も操作を続行すると、nsswitch.conf ファイルのシーケンスは無視され、-r によって指定された場所でパスワード情報の更新が行われます。
たとえば、nsswitch.conf ファイルにおいて passwd エントリが以下のように指定されている場合を考えてみましょう。
passwd: files nisplus |
この場合、passwd コマンドを -r を使用しないで実行すると、パスワード情報のソース (情報の獲得、変更、保存が行われる場所) は /etc/passwd ファイルになります。しかし -r nisplus オプションを使用して passwd コマンドを実行すると、パスワード情報のソースは /etc/passwd ファイルから NIS+ の passwd テーブルに変更されます。
-r オプションは、「検索シーケンスが誤っていて nsswitch.conf ファイルが使用できない」という場合にのみ使用するようにします。たとえば、2 カ所に格納されているパスワード情報を更新する必要がある場合、1 つ目については nsswitch.conf ファイルで指定されているソースを使用できますが、2 つ目については別のソースを使用する必要があります。
Your specified repository is not defined in the nsswitch file! |
このメッセージは、「パスワード情報の更新は、-r オプションで指定された場所において行われるが、nsswitch.conf ファイルでその場所がソースとして指定されるまでは更新の影響がまったく現れない」ということを意味します。たとえば、nsswitch.conf ファイルにおいて passwd: files nis という指定が行われているときに、-r nisplus オプションでパスワード使用期間の設定を行なったとします (つまり設定は NIS+ の passwd テーブルにおいて行われることになる)。パスワード情報のソースが nsswitch.conf ファイルにおいて NIS+ passwd テーブル以外の場所に指定されているため、この設定による影響はまったく現れません。
この章で「NIS+ 環境とは」、「nsswitch.confファイルでパスワード情報のソースが nisplus に設定されている」、「passwd コマンドが -r nisplus という引数をつけて実行されている」という状況を指します。
passwd コマンドは NIS+ 環境 (前節参照) で実行された場合、ユーザーに資格があってもなくても機能するよう設計されています。ただし資格のないユーザーが passwd コマンドで行えるのは、自らのパスワードの変更だけです。他のパスワード操作は、資格のある (認証された)、必要なアクセス権を持った (承認された) ユーザーだけが行えます。
承認およびアクセス権については、ユーザーがすべて適切な資格を持っているという前提で説明をします。
通常の NIS+ 環境では、passwd テーブルの所有者はいつでも制約なしにパスワード情報の変更ができます (デフォルトの場合)。つまり passwd テーブルの所有者は、読み取り、作成、変更、削除に関して完全に承認されている (アクセス権を与えられている) ということになります。また所有者は以下のことも行えます。
テーブルのグループ、その他、未認証といったクラスに、読み取り権、作成権、変更権、削除権などを与える (この種の権利をその他クラス、未認証クラスに与えると NIS+ のセキュリティが弱くなる)
任意のクラスに与えられたアクセス権を、nisdefaults、nischmod、nistbladm などのコマンドを使用して変更する
与えられているアクセス権には関わりなく、その他クラス、未認証クラスのユーザーはすべてパスワードの使用期間の制約に従います。つまり、自分のパスワードであろうと他のユーザーのパスワードであろうと、作成されてから一定の時間が経過するまでは変更ができないということです。また有効期間の過ぎたパスワードを変更しなければならないという点も、グループ、その他、未認証といったクラスのメンバーすべてに共通です。しかしパスワード使用期間に関する上記のような制約は、passwd テーブルの所有者には適用されません。
NIS+ 環境で passwd コマンドを使用する場合、行おうとする操作に関する承認 (アクセス権) が必要です。
表 11-1 passwd コマンドに関するアクセス権
操作の種類 |
必要な権利 |
アクセス対象となるオブジェクト |
---|---|---|
情報を表示する |
読み取り権 |
passwd テーブルのエントリ |
情報を更新する |
変更権 |
passwd テーブルのエントリ |
情報を追加する |
変更権 |
passwd テーブル |
NIS+ 環境で passwd コマンドを使用して主体のパスワードを変更しようとすると、主体の非公開鍵が cred テーブル中で更新されます。
cred テーブルの DES エントリに対してユーザーが変更権を持っていて、ログインパスワードと Secure RPC パスワードが同じであれば、passwd コマンドによって cred テーブルの非公開鍵が更新されます。
cred テーブルの DES エントリに対する変更権がユーザーになく、ログインパスワードと Secure RPC パスワードが異なっている場合は、passwd コマンドによってパスワードだけが変更され、非公開鍵は変更されません。
つまり cred テーブルの非公開鍵が、passwd テーブルに格納されているものとは異なったパスワードで作られることになります。この場合は、chkey コマンドを実行する、ログイン後に毎回 keylogin を実行するといった方法で、鍵を変更する必要があります。
他のドメインの passwd テーブルに対して操作をするには、passwd コマンドを以下のように使用します。
passwd [options] -D domainname |
nistbladm は、passwd テーブルをはじめとする NIS+ テーブルに関する情報を作成、変更、表示するのに使用するコマンドです。
nistbladm コマンドを使用してパスワード操作をするには、nistbladm を passwd テーブルのシャドウ列に適用する必要があります。nistbladm をシャドウ列に適用するのは複雑で微妙な作業になります。passwd コマンド、admintool、または Solstice AdminSuite ツールで容易に行える操作には、nistbladm コマンドを使用しない方が良いでしょう。
つまり以下のような操作には、nistbladm ではなく passwd コマンドや Solstice AdminSuite ツールを使用してください。
パスワードの変更
パスワードの使用期間の設定
パスワード作成後から変更が可能になるまでの時間の設定
「パスワードが間もなく無効になる」という警告が表示されるタイミングの設定
パスワードの使用期間に関する設定の解除
nistbladm コマンドには以下の機能があります。
新しい passwd テーブルエントリの作成
既存のエントリの削除
passwd テーブル中の UID フィールド、GID フィールドの更新
passwd テーブルの、アクセス権などセキュリティに関する属性の更新
ユーザーアカウントに関して「どれだけの期間使用できるか」、「どれだけの期間使用されなければ無効になるか」を設定する (「パスワード使用権の有効期限」、「ログインの間隔の最大値の指定」を参照)
nistbladm コマンドでは、シャドウ列の様々なフィールドの値を指定することによってパスワードパラメータの設定を行います。シャドウ列のフィールドの値は、以下のような形式で設定します。
個々のフィールドの内容は以下のとおりです。
「n1 最終変更日」は、パスワードが最後に変更されたときの日付です。1970 年 1 月 1 日からの日数で表されます。このフィールドの値は、パスワードが変更されると自動的に更新されます (日数に関する詳細な情報は、「nistbladm と日数」に示されています)。このフィールドが空白であったり、指定されている値が 0 の場合は、過去に一度もパスワードの変更が行われていないことを意味します。
このフィールドの値は、残りのフィールドの設定の基礎となることに注意してください。このフィールドの値が不当に変更されると、残りのフィールドの設定も不当なものになります。
「n2 最小値」は、パスワードが変更されてから、次の変更が可能になるまでの期間です。たとえば、パスワード作成時の最終変更日フィールドの値が 9201 (1970 年 1 月 1 日から 9201 日経過したことを示す) で、最小値フィールドの値が 8 だとすると、9209 日目まではパスワードの変更ができません (詳細は、「パスワードの変更禁止期間の設定」を参照)。
この値としては以下の 3 とおりが考えられます。
「0」は、変更禁止期間がないことを意味します。
「0 より大きい数字」はこの数字がパスワードの変更禁止期間 (単位:日) になります。
「最大値 (n3) より大きい値」はこのフィールド値が最大フィールドの値より大きい場合、パスワードを変更できません。変更しようとすると、You may not change this password というメッセージが表示されます。
「n3 最大値」は、パスワードが作成されてから、使用できなくなるまでの日数を示します。この日数を過ぎると、ログインの際新しいパスワードの設定が強制されます。たとえば、パスワード作成時の最終変更日の値が 9201 の最大値が 30 である場合、9231 (9201+30) 日目が経過した後は、ログイン時に新しいパスワードの設定が強制されます (詳細は、「パスワードの有効期間の設定」を参照)。
この値としては以下の 3 とおりが考えられます。
「0」は「次回のログイン時にパスワードの変更を強制し、その後は有効期間を設定する機能を停止する」ということを意味します。
「0 より大きい値」は、この数字がパスワードの有効期間 (単位:日) になります。
「-1」は、有効期間を設定する機能を停止するということを意味します。つまり passwd -x -1 username というコマンドを実行すると、以前に行われたパスワードの有効期間の設定が解除されることになります。このフィールドを空白にしておくと、-1 として扱われます。
「n4 警告」は、「パスワードが間もなく無効になる」という警告メッセージが表示されるタイミングを示します。パスワードが作成されてからの日数で指定します。たとえば、最終変更日が 9201、最大値が 30、警告が 5 である場合、9226 (9201+30-5) 日が経過した後は、ログインの度に「パスワードが間もなく無効になる」という警告メッセージが表示されます (詳細は、「警告期間の設定」を参照)。
この値としては以下の 2 とおりが考えられます。
「0」は、警告メッセージが表示される期間がないことを示します。
「0 より大きい値」は、この数字が、パスワードが作成されてから警告メッセージが表示されるまでの期間 (日数) になります。
「n5 間隔」は、ログインとログインの間隔 (日数) の最大値です。ここで指定された日数を超える期間ログインを行わないと、ログインができなくなります。たとえば、間隔に 6 を指定した場合、6 日間ログインを行わないと 7 日目にはログインができなくなります (詳細は、「ログインの間隔の最大値の指定」を参照)。
この値としては以下の 2 とおりが考えられます。
「-1」は、デフォルト設定です。機能を停止します。この場合、ログインとログインとの間隔が何日開いてもログイン特権が失われることはありません。
「0 より大きい値」は、この数字が、ログインとログインの間隔 (日数) の最大値になります。
「n6 期限」は、パスワードの有効期限を示します。1970 年 1 月 1 日からの日数で表されます。この日を過ぎると、ログインができなくなります。たとえば、期限が 9739 (1995 年 9 月 1 日) に設定されている場合、1995 年 9 月 2 日 (GMT) になるとログインができなくなります。このときログインを試行すると 「Login incorrect」というメッセージが表示されます (詳細は、「パスワード使用権の有効期限」を参照)。
この値としては以下の 2 とおりが考えられます。
「-1」は、機能を停止します。パスワードが有効期限を過ぎている場合でも、-1 を設定すると再び使えるようになります。有効期限を設定したくないときは、-1 を指定するようにしてください。
「0 より大きい値」は、この数字が有効期限の日付になります (1970 年 1 月 1 日から数えたもの)。現在以前の日付を設定すると、パスワードはすぐに無効になります。
Login はユーザのログイン ID
nistbladm を使用して passwd テーブルのシャドウ列を設定する場合、すべてのフィールドに適切な値を指定する必要があります。空白のまま残したり、0 を入力したりしても「変更なし」という意味にはなりません。
ユーザー amy が、パスワードの最終変更日が 1995 年 5 月 1 日 (1970 年 1 月 1 日から数えて 9246 日目)、パスワード作成後の変更禁止期間が 7 日、パスワードの有効期間が 30 日、「パスワードが間もなく無効になる」という警告が表示されるのがパスワード作成から 26 日目以降、ログインとログインの間隔の最大値が 15 日、アカウントの有効期限が (1970 年 1 月 1 日から) 9255 日目という設定にするには、以下のように入力します。
master# nistbladm -m shadow=9246:7:30:5:15:9255:0 [name=amy], passwd.ord_dir |
パスワードの使用期間に関するパラメータは、日数で表されるものがほとんどです。日数を指定する際には以下の規則を守る必要があります。
1970 年 1 月 1 日を 0 とします。つまり 1970 年 1 月 2 日は 1 になります。
NIS+ では、日付の計算、カウントに GMT (Greenwich Mean Time) が使用されます。つまり日付が変更されるのは、GMT の午前 0 時です。
日数の指定には整数を使用します。分数は使用できません。
パスワードのロックなどの動作は、指定された日付に行われます。たとえば、パスワード使用権の有効期限を1995 年 1 月 2 日 (1970 年 1 月 1 日から 9125日目) に設定した場合、この日は「ユーザーがパスワードを使用できる最後の日」となります。パスワードが使用できなくなるのは、次の日からです。
最終変更日、期限のどちらのフィールドも、入力するのは 1970 年 1 月 1 日から数えた日数です。この日数と実際の日付との関係を以下の表に示します。
表 11-2 1970 年 1 月 1 日からの日数
日付 |
日数 |
---|---|
1970 年 1 月 1 日 |
0 |
1970 年 1 月 2 日 |
1 |
1971 年 1 月 2 日 |
365 |
1997 年 1 月 1 日 |
9863 |
passwd および nistbladm コマンドと類似の機能を持つコマンドは他にもあります。それぞれについて表 11-3 にまとめてあります。
表 11-3 関連コマンド
コマンド |
説明 |
---|---|
yppasswd |
現在は passwd コマンドにリンク。yppasswd を起動すると passwd コマンドが起動される |
nispasswd |
現在は passwd コマンドにリンク。nispasswd を起動すると passwd コマンドが起動される |
niscat |
テーブルの内容を表示するのに使用 |
ドメイン中のユーザーのパスワード情報を表示するには、passwd コマンドを使用します。情報は、全ユーザーについて同時に表示することも、ユーザーごとに表示することもできます。
自分のパスワード情報
passwd -s |
ドメインの全ユーザーの情報
passwd -s -a |
他のユーザーの情報
passwd -s username |
表示できるのは、エントリおよび列のうち読み取り権を持っているものだけです。エントリの表示形式は以下のとおりです。
使用期間に関する情報が省略されたもの:username status
使用期間に関する情報が付加されたもの: username status mm/dd/yy min max warn expire inactive
フィールド |
説明 |
参照箇所 |
---|---|---|
username |
ユーザーのログイン名 |
|
status |
パスワードの状態。PS (アカウントにパスワードが存在する)、LK (パスワードがロックされている)、NP (アカウントにパスワードが存在しない) の 3 種類がある | |
mm/dd/yy |
パスワードが最後に変更された日付 (GMT で表す) |
|
min |
パスワード作成後の変更禁止期間 (日数) | |
max |
パスワードの有効期間 (日数) | |
warn |
「パスワードが間もなく無効になる」という警告が表示されるまでの日数 | |
expire |
パスワードの有効期限 (日付) | |
inactive |
ログインとログインの間隔の最大値 (日数)。ログインとログインの間隔がここで指定した日数を超えると、ログインができなくなる |
別のドメインの passwd テーブルのエントリを表示するには、-D オプションを使用します。
ドメイン中の全ユーザー
passwd -s -a -D domainname |
個々のユーザー
passwd -s -D domainname username |
新しいパスワードを作成するときは、「パスワードの必要条件」に示された必要条件を満たすようにします。
自分のパスワードを変更するには、以下のように入力します。
station1% passwd |
「古いパスワードの入力」、「新しいパスワードの入力」、「新しいパスワードの再入力 (確認のため)」という順にプロンプトが表示されるので、それに従って作業します。
他人のパスワードを変更するには、以下のように入力します。
同じドメイン内の他のユーザー
passwd username |
他のドメインのユーザー
passwd -D domainname username |
NIS+ 環境 (「passwd コマンドと NIS+ 環境」参照) で passwd コマンドを使用して他人のパスワードを変更する場合、passwd テーブルにおける該当ユーザーエントリへの変更権が必要になります。つまり、該当する passwd テーブルに対して変更権を持つグループのメンバーになる必要があります。このとき、該当ユーザーの古いパスワードや自分のパスワードを入力する必要はありません。確認のため新しいパスワードの入力を求めるプロンプトが 2 回表示されます。一致しない場合は、さらに 2 回入力する必要があります。
passwd コマンドで root のパスワードを変更した場合は、その直後に chkey -p を実行する必要があります。chkey -p を実行しないと、root で正しくログインできなくなります。
root のパスワードの変更手順は以下のとおりです。
root でログインします。
passwd コマンドで root のパスワードを変更します。nispasswd は使用しないでください。
chkey -p を実行します。
必ず -p オプションを使用します。
NIS+ 環境 (「passwd コマンドと NIS+ 環境」を参照) で passwd コマンドを使用してパスワードのロックができるのは、該当ユーザーの passwd テーブル中のエントリに対する変更権を持っている管理者 (グループのメンバー) です。パスワードがロックされると、そのアカウントは使用できなくなります。また、パスワードがロックされているユーザー名を使ってログインをしようとすると、「Login incorrect」というメッセージが表示されます。
該当ユーザーがすでにログインしている場合、パスワードをロックすることによる影響は現れないという点に注意してください。ただ、パスワードの入力が必要になる login、rlogin、ftp、telnet などの機能は使用できなくなります。
すでにログインしているユーザーのパスワードをロックしても、そのユーザーが passwd コマンドでパスワードを変更するとロックは解除されます。
以下のようなことが有効です。
セキュリティ上の問題が発生している可能性があれば、すぐに一部のユーザーのパスワードをロックする
解雇になったユーザーのパスワードをすぐにロックする。ユーザーのアカウントを削除するより速く容易に行える上、そのアカウントに格納されているデータをそのまま容易に保管できる
UNIX プロセスにパスワードを設定している場合には、この種のパスワードもロックできる。パスワードがロックされてもプロセスの実行はできるが、プロセスを使用してログインすることは (たとえパスワードを知っていても) できなくなる。多くの場合、プロセスは NIS+ 主体の形では設定されない。しかしプロセスのパスワード情報は、/etc ディレクトリのファイルに保存される。このとき /etc に格納されたパスワードをロックするにはファイルモードで passwd コマンドを実行する必要がある。
パスワードのロックは以下のように行います。
passwd -l username |
パスワードのロックは、パスワードを変更すれば解除されます。この場合、「変更」とは必ずしもパスワードを新しいものに変えるという意味ではなく、パスワード変更の手順を踏むということです (元とまったく同じパスワードに「変更する」ということもある)。
たとえば、jody というユーザーのパスワードのロックを解除するには、以下のように入力します。
station1% passwd jody |
設定により、パスワードの定期的な変更をユーザーに強制できます。
たとえば、以下のような設定が可能です。
次回のログインの際に強制的にパスワードを変更させる (詳細は、「パスワードの強制的な変更」を参照)
パスワードの有効期間 (日数) を設定する (詳細は、「パスワードの有効期間の設定」を参照)
パスワード作成後の変更禁止期間を設定する (詳細は、「パスワードの変更禁止期間の設定」を参照)
パスワードの有効期間が終わる前に「パスワードが間もなく無効になる」という警告メッセージが (ログイン時に) 表示されるタイミングを設定する (詳細は、「警告期間の設定」を参照)
ログインとログインの間隔の最大値 (日数) を指定する。指定された日数を超えてログインが行われないと、パスワードがロックされる (詳細は、「ログインの間隔の最大値の指定」を参照)
パスワードの有効期限 (日付) を設定する。この日を過ぎると、該当ユーザはシステムにログインできなくなる (詳細は、「パスワード使用権の有効期限」を参照)
上記の警告期間や有効期間などに達したのがログインの行われた後であった場合、影響は現れません。そのまま普通に動作し続けます。
影響が現れるのは、次回のログイン時か、ログインを必要とする機能 (以下に例を示す) を使用した時です。
login
rlogin
telnet
ftp
パスワードの使用期間に関する設定は、ユーザーごとに行います。パスワードの使用期間に関する必要条件はユーザーによって違っている可能性があります。ユーザー一般にデフォルト設定を適用することもできます。詳細は、「/etc/defaults/passwd ファイル」を参照してください。
次回ログイン時のパスワード変更をユーザーに強制するには、以下の 2 種類の方法があります。
使用期間に関する設定を引き続き有効にする場合
passwd -f username |
使用期間に関する設定を解除する場合
passwd -x 0 username |
パスワードの有効期間を設定するには、passwd コマンドの引数 max を使用します。有効期間は日数で指定します。有効期間が終了した後は、新しいパスワードをユーザーが、作成しなければなりません。有効期間終了後に同じパスワードでログインしようとしても、「Your password has been expired for too long」というメッセージが表示され、新しいパスワードを作成しない限りログインを完了できません。
引数 max は以下の形式で使用します。
passwd -x max username |
引数の意味はそれぞれ以下のとおりです。
username は、ユーザーのログイン ID
max は、以下のうちいずれかになります。
「0 より大きい値」は、パスワードの有効期間の日数
「0」は、次回ログイン時のパスワード変更を強制する。使用期間に関する設定は解除される
「-1」は、パスワードの使用期間に関する設定を解除します。つまり passwd -x -1 username と入力すると、使用期間に関して該当ユーザーに行われていた設定はすべて解除されます。
たとえば、schweik というユーザーに 45 日ごとのパスワード変更を強制するには、以下のように入力します。
station1% passwd -x 45 schweik |
パスワード作成後の変更禁止期間を設定するには、引数 min を使用します。変更禁止期間が終了しないうちにパスワードを変更しようとすると、「Sorry less than N days since the last change」というメッセージが表示されます。
引数 min は以下の形式で使用します。
passwd -x max -n min username |
引数の意味はそれぞれ以下のとおりです。
username は、ユーザーのログイン ID
max は、パスワードの有効期間 (前のセクションを参照)
min は、パスワード作成後の変更禁止期間
たとえば、ユーザー eponine のパスワードの、有効期間を 45 日間、変更禁止期間を 7 日間に設定する場合は、以下のように入力します。
station1% passwd -x 45 -n 7 eponine |
min 引数には以下の規則があります。
min 引数は必ずしも使用しなくて良い (つまり、パスワード変更禁止期間は必ずしも指定しなくて良い)
min 引数は、必ず -max 引数と組み合わせて使用する。つまり、変更禁止期間を設定するには、有効期間も設定する必要がある
min に max より大きい値を設定すると (例: passwd -x 7 -n 8)、ユーザーはパスワードを変更できなくなる。変更しようとすると、「You may not change this password」というメッセージが表示される。min に max より大きな値を設定すると、次の 2 つの効果が得られる
ユーザーによるパスワードの変更を禁止する。つまり、管理特権を有する一部の人物以外は、パスワードを変更できなくなる。たとえば、複数のユーザーに共通のグループパスワードを割り当て、そのパスワードに対して min 値より大きな max 値を設定すると、グループ内のユーザーは誰一人としてパスワードを変更できなくなる
パスワードは max 値で設定される期限内のみ有効となる。しかも、min 値が max 値より大きいため、ユーザーはパスワードを変更できない。つまり、max 値の示す有効期限が満了する前にパスワードの期限延長を図る手だては、ユーザーには一切与えられない。実際、有効期限が満了した後は、管理者の介在なしにユーザーはログインできなくなる
パスワードの有効期限以前の一定期間、ログイン時に「Your password will expire in N days」(N は日数) というメッセージが表示されるようにするには、引数 warn を使用します。
たとえば、パスワードの有効期限が 30 日間 (引数 -max で指定する) で、warn が 7 に設定されている場合、パスワード作成後 24 日目のログイン時に「Your password will expire in 7 days」という警告メッセージが表示されます。また翌日 (パスワード作成後 25 日目) には、警告メッセージは「Your password will expire in 6 days」となります。
警告メッセージは、電子メールで送信されるものでも、ユーザーのコンソールウィンドウに表示されるものでもないという点に注意してください。表示されるのは、ユーザーのログイン時のみです。つまり指定の期間ユーザーがログインしなければ警告メッセージは表示されません。
warn の値は、max の値との「関連によって機能する」ものであるという点に注意してください。つまり、「max によって設定される有効期限から逆算されるもの」ということです。warn の値が 14 であれば、「Your password will expire in N days」というメッセージの表示が開始されるのは、有効期限の 2 週間前です。
warn の値は max の値との関連によって機能するため、max の指定がない場合は意味がなくなります。
引数 warn は以下の形式で使用します。
passwd -x max -w warn username |
引数の意味はそれぞれ以下のとおりです。
username は、ユーザーのログイン ID
max は、パスワードの有効期限 (日数) (「パスワードの有効期間の設定」を参照)
warn は、「有効期限の何日前から警告メッセージの表示を開始するか」を指定する
たとえば、nilovna というユーザーの、パスワードの有効期間を 45 日間とし、警告メッセージの表示を有効期限の 5 日前から開始する場合、以下のように入力します。
station1% passwd -x 45 -w 5 nilovna |
warn 引数には以下の規則があります。
warn 引数は必ずしも使用しなくて良い。warn の値を設定しなければ、警告メッセージは表示されない
warn 引数は、必ず max 引数と組み合わせて使用する。つまり、警告メッセージの表示期間を指定するには、有効期間の指定が必要になる
Solstice AdminSuite を使用して、warm 値をユーザーのパスワード用に設定することもできます。
ユーザーのパスワードの有効期間を解除するには、以下の 2 つの方法があります。
有効期間を取り消す。パスワードはそのまま使用できる
passwd -x -1 username |
次回ログイン時にパスワードを強制的に変更させた後、有効期間を取り消す
passwd -x 0 username |
上記の方法では、max の値を 0 か -1 に設定する (詳細は、「パスワードの有効期間の設定」を参照)
たとえば、ユーザー mendez のパスワードを次回ログイン時に強制的に変更させ、その後パスワードの有効期間を解除するには、以下のように入力します。
station% passwd -x 0 mendez |
Solstice AdminSuite を使用して、このパラメータをユーザーのパスワード用に設定できます。
この値を設定するには、nistbladm コマンドを使用できます。たとえば、ユーザー otsu のパスワードの有効期間を取り消し、変更の必要がないようにするには、以下のように入力します。
station1% nistbladm -m `shadow=0:0:-1:0:0:0:0' [name=otsu],passwd.org_dir |
nistbladm コマンドの使用方法の詳細は、「nistbladm コマンド」を参照してください。
引数 expire には「ユーザーのパスワード使用権がいつ無効になるか」を日付で指定します。該当ユーザーのログインをこの日以降禁止し、システムから締め出します。
たとえば、ユーザー pete の有効期限を 1997 年 12 月 31 日に設定すると、どんなパスワードを使用しても 1998 年 1 月 1 日以降 pete という ID ではログインができなくなります。ログインをしようとしても、「Login incorrect」というメッセージが表示されます。
パスワード使用権の有効期限は、パスワードの有効期間とは異なっています。
「パスワードの有効期間」
厳密に区別をする必要のない場合には、有効期間が終了した後も変更されないパスワードのことを「有効期限の過ぎたパスワード」と呼ぶことがあります。しかしこのパスワードは、もう一度だけログインに使用できます。ただしその際に変更を強制されます。
「パスワード使用権の有効期限」
パスワード使用権が「有効期限」を過ぎたユーザーは、どんなパスワードを使用してもログインできません。ネットワークへのログインアクセス権が無効になったということです。
パスワード使用権が無効になっても、その影響が現れるのは、該当ユーザーがログインをしようとするときだけです。該当ユーザーがすでにログインしていた場合には、パスワード使用権が無効になったことによる影響は現れません。ただし、rlogin、telnet などログインを必要とする機能は使用できなくなり、いったんログアウトするとログインできなくなります。以上のことから、パスワード使用権に有効期限を設ける場合、毎日のワークセッション終了時には必ずログアウトするようユーザー全員に指示してください。
Solstice AdminSuite ツールを使用して有効期限の設定ができるときは、nistbladm を使用しないでください。Solstice AdminSuite ツールの方が使いやすく、設定を誤る可能性が低くなります。
nistbladm コマンドでパスワード使用権の有効期限を指定するには、以下のように入力します。
nistbladm -m `shadow=n:n:n:n:n:n6:n' [name=login],passwd.org_dir |
引数の意味はそれぞれ以下のようになります。
login は、ユーザーのログイン ID です。
n は、シャドウ列の (n6 を除くフィールドの) 値です。
n6 は、ユーザーのパスワード使用権の有効期限 (日付) を設定します。「1970 年 1 月 1 日から数えて何日目か」で表します (表 11-2 を参照)。このフィールドに指定する値には、以下の 2 種類があります。
「-1」は、有効期限の設定を解除します。ユーザーのパスワードがすでに有効期限を過ぎていても、-1 を設定することによって再び使用できるようになります。有効期限を設定したくないときは、初めから -1 を指定しておきます。
「0 より大きい値」は、有効期限の日付 (「1970 年 1 月 1 日から数えて何日目か」) です。現在以前の日付を指定すると、ユーザーのパスワードはすぐに無効になります。
たとえば、ユーザー pete の有効期限を 1995 年 12 月 31 日に設定する場合は、以下のように入力します。
station1% nistbladm -m `shadow =n:n:n:n:n:9493:n' [name=pete],passwd.org_dir |
空白のフィールドや、値の正しくないフィールドがあると機能しません。
有効期限を過ぎたパスワード使用権を再び使用できる状態にするには、nistbladm コマンドを使用して該当フィールド (n6) に -1 を指定します。例を以下に示します。
station1% nistbladm -m `shadow= n:n:n:n:n:-1:n' [name=huck],passwd.org_dir |
また、nistbladm で「n6」フィールドを将来の日付に設定し直すという方法も使用できます。
引数 inactive には、「ログインからログインまでの間隔を最大何日あけることができるか」を指定します。この引数に指定された日数を超えてログインが行われなかった場合、該当ユーザーはマシンにログインできなくなります。ログインしようとすると、「Login incorrect」というメッセージが表示されます。
この設定はネットワーク全体ではなく、個々のマシンに対して行われます。したがって、NIS+ 環境においてログイン間隔の最大値を設定するには、該当ユーザーのエントリをホームドメインの passwd テーブルに指定します。この設定はネットワーク上のすべてのマシンで該当ユーザーに対して適用されます。しかし、最後にログインをした日付はマシンごとに異なるため、個別に (各マシンの /var/adm/utmp ファイルに) 記録されます。
たとえば、ユーザー sam の最大ログイン間隔を 10 日間に設定した場合を考えてみましょう。sam は 1 月 1 日にマシン A とマシン B にログインをした後、ログアウトしました。続いて 3 日後の 1 月 4 日、sam はマシン B にログインした後ログアウトしました。さらに 9 日後の 1 月13日になると、sam はマシン B にはログインできますがマシン A にはログインできません。マシン B においては最終ログインから 9 日間しか経過していませんが、マシン A においては 13 日間が経過しているからです。
最大ログイン間隔の設定は、まだ一度もログインをしていないマシンには適用されないという点に注意してください。一度もログインをしていないマシンには、引数 inactive の設定および他のマシンへのログイン実績がどのようになっていようとログインが可能です。
「毎日の作業終了時には必ずログアウトをせよ」という指示がユーザーに対して行われていない場合、最大ログイン間隔の設定はしないでください。この設定はログインにだけ関係しており、他の形でシステムを使用する場合のことは考慮されていません。仮にユーザーが作業終了後もログインしたままの状態でシステムを放置しておくと、ログインが発生しないため指定のログイン間隔をすぐ超えてしまいます。指定のログイン間隔を超えた状態でリブートやログアウトをすると、再びログインできなくなります。
Solstice AdminSuite ツールを使用して最大ログイン間隔の設定ができるときは、nistbladm を使用しないでください。Solstice AdminSuite ツールの方が使いやすく、設定を誤る可能性が低くなります。
最大ログイン間隔の設定を nistbladm コマンドで行う場合は、以下の形式を使用します。
nistbladm -m `shadow= n:n:n:n:n5:n:n' [name=login], passwd.org_dir |
引数の意味はそれぞれ以下のとおりです。
login は、ユーザーのログイン ID です。
n は、シャドウ列の (n5 以外の) フィールドの値です。
n5 は、最大ログイン間隔 (日数) です。指定される値には、以下の 2 種類があります。
「-1」は、デフォルト設定です。最大ログイン間隔の設定を解除します。この設定の場合、ログインされない期間が何日続いてもパスワード使用権が失われることはありません。
「0 より大きい値」は、最大ログイン間隔 (日数) を指定します。
たとえば、ユーザー sam の最大ログイン間隔を 7 日間に指定する場合は、以下のように入力します。
station1% nistbladm -m `shadow= n:n:n:n:n:7:n:n' [name=sam],passwd.org_dir |
最大ログイン間隔の設定を解除する (ログインできなくなったユーザーを再びログインできるようにする) には、nistbladm で inactive を -1 に指定します。
パスワードの使用規則に関する設定およびそのデフォルトについて説明します。
パスワード情報の獲得先が nsswitch.conf ファイルで files に指定されているすべてのユーザーのパスワードについて、4 つのデフォルト設定を行うためのファイルです。/etc/defaults/passwd ファイルで行われたデフォルト設定は、/etc ディレクトリのファイルからパスワード情報を獲得しているユーザーにだけ適用されます。パスワード情報の獲得先が NIS マップあるいは NIS+ テーブルであるようなユーザーには適用されません。NIS+ サーバー上の /etc/defaults/passwd ファイルは、パスワード情報をローカルファイルから獲得しているローカルユーザーにだけ影響を与えます。NIS+ 環境または、nsswitch.conf ファイルでパスワード情報の獲得先が nis、nisplus に設定されているユーザーには影響を与えません。
/etc/defaults/passwd ファイルで行われる「パスワードに関する 4 つのデフォルト設定」とは、具体的には以下のものを指します。
有効期間 (週単位)
変更禁止期間 (週単位)
「パスワードが間もなく無効になる」という警告メッセージの表示される期間 (週単位)
最低文字数
/etc/defaults/passwd ファイルのデフォルト設定には、以下の規則があります。
パスワード情報をローカルの /etc ファイルから得ているユーザーの場合、passwd コマンド、Solstice AdminSuite、admintool で個々に行われた設定の方が、/etc/defaults/passwd のデフォルト設定よりも優先します。つまり /etc/defaults/passwd ファイルのデフォルト設定は、passwd テーブル中のエントリで (/etc/defaults/passwd の設定に対応した) 個別の設定が行われていないユーザーにだけ適用されるということです。
パスワードの長さを除き、すべての設定は週単位で行われます (個々のパスワードの使用期間についての設定は、日単位で行われていた点に注意)
MAXWEEKS
、MINWEEKS
、WARNWEEKS
は、パスワードの最終変更日を起点として設定します (nistbladm などでは warn の起点を max としていた点に注意)。
/etc/defaults/passwd ファイルには、デフォルトでは以下のエントリがすでに含まれています。
MAXWEEKS= MINWEEKS= PASSLENGTH= |
設定に必要な作業は、= の後に適切な数字を入力することだけです。= の後に数字が入っていないエントリは無効です。たとえば、MAXWEEKS
に 4 を指定するには、以下のように入力します。
MAXWEEKS=4 MINWEEKS= PASSLENGTH= |
ユーザーのパスワードの有効期間を週単位で指定するためのエントリです。以下に示すとおり、"=" の後に適切な数字を入力するだけで指定ができます。
MAXWEEKS=N |
N は週の数です。たとえば、MAXWEEKS=9 というようにします。
パスワードの変更禁止期間を週単位で指定するためのエントリです。以下に示すとおり、"=" の後に適切な数字を入力するだけで指定ができます。
MINWEEKS=N |
N は週の数です。たとえば、MINWEEKS=2 というようにします。
同時に MAXWEEKS
のデフォルトを設定していない限り、WARNWEEKS
のデフォルトを設定しても問題はありません。
パスワードが無効になる前に、「パスワードが間もなく無効になる」という警告メッセージの表示が開始されるタイミングを指定するエントリです。たとえば、MAXWEEKS
の値を 9 に指定していて、パスワードが無効になる 2 週間前に警告メッセージの表示を開始したいときは、WARNWEEKS
を 7 に設定します。
WARNWEEKS
は、MAXWEEKS
に指定された有効期限ではなく、パスワードの最終変更日を起点と考えて設定することに注意してください。したがって WARNWEEKS
に、MAXWEEKS
以上の値を設定することはできません。
WARNWEEKS
のデフォルトは、MAXWEEKS
のデフォルトも一緒に設定されていない限り無効です。
WARNWEEKS は、以下に示すとおり "=" の後に適切な数字を入力するだけで指定ができます。
WARNWEEKS=N |
N は週の数です。たとえば、WARNWEEKS=1 というようにします。
passwd コマンドには、デフォルトで「パスワードの長さは6文字以上にする」という規則があります。しかし、/etc/defaults/passwd ファイルの PASSLENGTH
を使用することによってこの規則を変更することが可能です。
パスワードの最低文字数を 6 以外の値にするには、以下に示すとおり PASSLENGTH= の後に適切な値を入力します。
PASSLENGTH=N |
N は文字数です。たとえば、PASSLENGTH=7 というようにします。
パスワード変更の際の入力試行回数と所要時間には、制限を設定できます。設定は rpc.nispasswdd デーモン起動時の引数で行います。
入力試行回数を制限したり、タイムウィンドウを設定したりすることにより、「権利のない人が、パスワードを試行錯誤で知ることのできるものに変えてしまう」という危険をある程度 (完璧ではない) 回避できます。
パスワード変更時の誤入力試行回数を制限するには、rpc.nispasswdd に -a number という引数 (number は試行回数) を指定します。rpc.nispasswdd を起動するには、NIS+ マスターサーバー上にスーパーユーザー特権が必要です。
誤入力試行回数を 4 に制限する (デフォルトは 3) 場合、以下のように入力します。
station1# rpc.nispasswdd -a 4 |
この場合、4 回目のパスワード入力が失敗すると、「Too many failures - try later」というメッセージが表示され、一定の時間が経過するまで該当ユーザーのパスワード変更はできなくなります。
パスワード変更時の所要時間 (ログインの所要時間) を制限するには、rpc.nispasswdd に -c minutes という引数 (minutes には時間を分単位で指定する) を指定します。rpc.nispasswdd を起動するには、NIS+ マスターサーバー上にスーパーユーザー特権が必要です。
たとえば、ユーザーが 2 分以内にログインしなければならないように設定するには、以下のように入力します。
station1# rpc.nispasswdd -c 2 |
この場合、2 分以内にパスワードの変更に成功しないとエラーメッセージが表示され、一定の時間が経過するまで該当ユーザーのパスワード変更はできなくなります。
この章では、NIS+ グループとその管理方法について説明します。
NIS+ セキュリティグループのタスクには、Solstice AdminSuite ツールを利用するともっと簡単に実行できるものもあります。
Solaris/NIS+ 環境には、UNIX グループ、ネットグループ、NIS+ グループの 3 種類のグループがあります。
「UNIX グループ」
UNIX グループとは、特別な UNIX アクセス権を与えられたユーザーの集まりのことです。NIS+ 名前空間では、UNIX グループに関する情報は org_dir ディレクトリオブジェクト (group.org_dir) 内のグループテーブルに格納されます。UNIXグループメンバーの追加、修正、削除の方法については、第 14 章「NIS+ テーブルの管理」を、グループテーブルの詳細は、「group テーブル 」をそれぞれ参照してください。
「ネットグループ」
ネットグループとは、ワークステーションとユーザー (他のワークステーション上でリモート操作を実行する権限を与えられている) の集まりのことです。NIS+ 名前空間では、ネットグループに関する情報は org_dir ディレクトリオブジェクト (netgroup.org_dir) 内のグループテーブルに格納されます。ネットグループメンバーの追加、修正、削除の方法については第 14 章「NIS+ テーブルの管理」を、ネットグループテーブルの詳細は、「netgroup テーブル」をそれぞれ参照してください。
「NIS+ グループ」
NIS+ グループとは、NIS+ オブジェクトに対する特別なアクセス権 (ネームスペースの管理を許されることが多い) を与えられている NIS+ ユーザーの集まりのことをいいます。NIS+ グループに関する情報は groups_dir ディレクトリオブジェクト内のテーブルに格納されます。
NIS+ グループは、NIS+ オブジェクトに対するアクセス権を NIS+ の主体に割り当てるために考えられた概念です。(これらのアクセス権については、第 6 章「セキュリティの概要」を参照してください。) NIS+ グループに関する情報は、NIS+ groups_dir ディレクトリオブジェクト内のテーブルに格納されます。各グループは個別のテーブルを持ち、グループ名とテーブル名はそれぞれ対応します。たとえば、admin グループに関する情報は admin.groups_dir テーブルに格納されます。
NIS+ グループを作成したら、どれか 1 つには admin という名前を付けることをお勧めします。そして、この admin グループには、NIS+ アクセス権を持たせるユーザーを割り当ててください。必ずしも admin という名前にしなければならないわけでもないのですが、NIS+ マニュアルでは、NIS+ 管理権限を持たせるユーザーのグループを admin と呼んでいます。異なるユーザーと異なる権限を組み合わせて複数の NIS+ グループを作成することもできます。
NIS+ グループのメンバー (ユーザー) の管理には、nisgrpadm コマンドを使います。グループテーブルの管理には、nisls コマンドと nischgrp コマンドを使います。グループテーブルに対して nistbladm コマンドを使うことはできないので注意してください。
NIS+ グループ関連のコマンドとその構文、オプションの詳細は、nis+(1) のマニュアルページを参照してください。
nisgrpadm コマンドを使ってほとんどのグループ管理作業を実行できますが、グループ管理に関連するコマンドには次のものがあります。
表 12-1 グループに関連するコマンド
コマンド |
説明 |
参照する項目 |
---|---|---|
nissetup |
ドメインのグループが格納されるディレクトリである groups_dir を作成する | |
nisls |
groups_dir ディレクトリの内容、つまり、ドメイン内の全グループを表示する。各グループは groups_dir に個別のテーブルを持ち、グループ名とテーブル名はそれぞれ対応する | |
nischgrp |
グループを任意の NIS+ オブジェクトに割り当てる | |
niscat |
NIS+ グループのオブジェクト属性とメンバーを表示する | |
nisdefaults |
新しい NIS+ オブジェクトに割り当てられるグループを表示する |
以上のコマンドの詳細 (構文、オプションなど) は、nis+(1) のマニュアルページを参照してください。
NIS+ グループテーブルに対して nistbladm コマンドを使うことはできません。
NIS+ グループには明示的 (explicit)、暗黙的 (implicit)、および再帰的 (recursive) という 3 タイプのメンバーがあります。またメンバー以外の主体にも、同様の 3 つのタイプがあります。メンバーのタイプは、メンバーを追加、削除する際に使用されます (「nisgrpadm コマンド」を参照)。
「明示的なもの」
個々の NIS+ 主体です。これらは、すべてのグループ管理コマンドで、主体名によって識別されます。主体名は、デフォルトドメインから入力される場合、完全指定名を使用する必要はありません。
「暗黙的なもの」
NIS+ ドメインに所属するすべての NIS+ 主体です。これらは、* 記号とドットで始まるドメイン名によって識別されます。選択した処理は、グループ内のすべてのメンバーに適用されます。
「再帰的なもの」
他の NIS+ グループのメンバーの、すべての NIS+ 主体です。これらは、@ 記号で始まる NIS+ グループ名によって識別されます。選択した処理は、グループ内のすべてのメンバーに適用されます。
NIS+ グループは、明示的、暗黙的、および再帰的の 3 つすべてのカテゴリでのメンバー以外も受け付けます。メンバー以外の主体とは、「メンバーになることができるが、指定によってグループから排除されているもの」を指します。
メンバー以外の主体はマイナス記号で始まり、メンバー主体と区別されます。
同じ主体について「グループに含まれる」という指定と「グループに含まれない」という指定があった場合、指定の順序に関係なく「含まれない」という指定が優先されます。たとえば、同じ主体について「グループに含まれる暗黙的なドメインのメンバーである」という指定と「グループに含まれない再帰的なグループのメンバーである」という指定の両方がある場合、後者の方が優先されます。
nisgrpadm コマンドを使用する場合、主体のタイプは表 12-2 のように指定します。
表 12-2 主体のタイプの指定方法
主体のタイプ |
構文 |
---|---|
明示的なメンバー |
username.domain |
暗黙的なメンバー |
*.domain |
再帰的なメンバー |
@groupname.domain |
メンバー以外 (明示的なもの) |
-username.domain |
メンバー以外 (暗黙的なもの) |
-*.domain |
メンバー以外 (再帰的なもの) |
@groupname.domain |
niscat -o コマンドを使用して、NIS+ グループのオブジェクト属性を表示できます。
グループのオブジェクト属性を表示するには、そのグループが格納されている groups_dir ディレクトリへの読み取り権が必要です。ここでは、niscat -o とグループの完全指定名を使用します。この完全指定名には、次に示すようにその groups_dir サブディレクトリを含んでいなければなりません。
niscat -o group-name .groups_dir.domain-name |
次に例を示します。
rootmaster# niscat -o sales.groups_dir.doc.com. Object Name : sales Owner : rootmaster.doc.com. Group : sales.doc.com. Domain : groups_dir.doc.com. Access Rights : ----rmcdr---r--- Time to Live : 1:0:0 Object Type : GROUP Group Flags : Group Members : rootmaster.doc.com. topadmin.doc.com. @.admin.doc.com. *.sales.doc.com. |
nisgrpadm -1 コマンドを使うと、メンバーリストはさらに整理されて表示されます。
グループ属性のいくつかは、環境変数 NIS_DEFAULTS
から継承されます。ただし、このグループの作成時に環境変数が無効になっている場合を除きます。Group Flags フィールドは、現在使用されていません。グループメンバーのリストでは、* 記号はメンバーのドメインを、@ 記号はメンバーのグループをそれぞれ示します。
nisgrpadm コマンドは、NIS+ グループを作成したり、削除したり、さまざまな管理作業を実行します。nisgrpadm を使用するには、処理に適したアクセス権が必要です。
表 12-3 nisgrpadm に必要なアクセス権
処理 |
必要なアクセス権 |
処理の対象 |
---|---|---|
グループの作成 |
作成権 |
groups_dir ディレクトリ |
グループの削除 |
削除権 |
groups_dir ディレクトリ |
メンバーの表示 |
読み取り権 |
グループオブジェクト |
メンバーの追加 |
変更権 |
グループオブジェクト |
メンバーの削除 |
変更権 |
グループオブジェクト |
nisgrpadm には、グループ作業用とグループメンバー作業用に 2 つの形式があります。
nisgrpadm -c group-name.domain-name nisgrpadm -d group-name nisgrpadm -l group-name |
メンバーの追加または削除、あるいはメンバーがグループに所属するかどうかの判定 (member... には、表 12-2 に示した、6 種類のメンバーのどのような組み合わせでも指定できます)。
nisgrpadm -a group-name member... nisgrpadm -r group-name member... nisgrpadm -t group-name member... |
作成 (-c) 以外のすべての処理には、部分指定名 group-name を使用できます。ただし、-c オプションの場合でも、nisgrpadm では group-name 引数に groups_dir を使用する必要はありません。実際これは受け付けられません。
NIS+ グループを作成するには、グループのドメインの groups_dir ディレクトリに対する作成権が必要です。-c オプションと完全指定グループ名を使用します。
nisgrpadm -c group-name.domainname |
グループを作成すると、指定した名前の NIS+ グループテーブルが groups_dir に作成されます。nisls コマンドを使うと、対応するテーブルが groups_dir に作成されているかどうかを確認できます。また、niscat コマンドを使うと、そのテーブル中のグループメンバーを一覧表示できます。
新しく作成したグループにはメンバーがありません。どのメンバーをどのグループに追加するかについては、「NIS+ グループにメンバーを追加する」を参照してください。
次の例では、admin という名前の 3 つのグループを作成します。最初のグループは doc.com. ドメインに、次のグループは sales.doc.com. に、3 番目のグループは manf.doc.com. に作成されます。これらはすべて、それぞれのドメインのマスターサーバーから作成されます。
rootmaster# nisgrpadm -c admin.doc.com. Group admin.doc.com. created. salesmaster# nisgrpadm -c admin.sales.doc.com. Group admin.sales.doc.com. created. manfmaster# nisgrpadm -c admin.manf.doc.com. Group admin.manf.doc.com. created. |
作成されるグループは、変数 NIS_DEFAULTS
で指定されたオブジェクト属性をすべて継承します。つまり、その所有者、所有グループ、アクセス権、生存期間、および検索パスです。これらのデフォルトを表示するには、nisdefaults コマンドを使用します (第 10 章「NIS+ のアクセス権の管理」を参照)。オプションなしで使用すると、次のように出力されます。
rootmaster# nisdefaults Principal Name : rootmaster.doc.com. Domain Name : doc.com. Host Name : rootmaster.doc.com. Group Name : Access Rights : ----rmcdr---r--- Time to live : 12:0:0 Search Path : doc.com. |
所有者は Principal Name: フィールドに表示されます。所有者グループは、環境変数 NIS_GROUP
を設定した場合にだけ表示されます。たとえば、C シェルを想定して NIS_GROUP
を fns_admins.doc.com に設定する場合は、次のように入力します。
rootmaster# setenv NIS_GROUP fns_admins.doc.com |
もちろん、グループの作成時に -D オプションを使用することによって、これらのデフォルトはどれでも変更できます。
salesmaster# nisgrpadm -D group=special.sales.doc.com.-c admin.sales.doc.com. Group admin.sales.doc.com. created. |
NIS+ グループを削除するには、グループのドメイン内の groups_dir ディレクトリに対する削除権が必要です。-d オプションを使用します。
nisgrpadm -d group-name |
デフォルトドメインが正しく設定されている場合、完全指定グループ名を使用する必要はありません。ただし、別のドメイン内のグループを誤って削除しないように、まず (nisdefaults を使用して) チェックしなければなりません。次の例では test.sales.doc.com. グループを削除します。
salesmaster% nisgrpadm -d test.sales.doc.com. Group test.sales.doc.com. destroyed. |
NIS+ グループにメンバーを追加するには、グループオブジェクトに対する変更権が必要です。-a オプションを使用します。
nisgrpadm -a group-name members. . . |
「NIS+ グループメンバーのタイプ」の記述どおり、主体 (明示的なメンバー)、ドメイン (暗黙的なメンバー)、およびグループ (再帰的なメンバー) を追加できます。デフォルトドメインに所属するメンバー名またはグループ名は、完全指定する必要がありません。次の例では、デフォルトドメイン sales.doc.com. からの NIS+ 主体 panza と valjean、および manf.doc.com. ドメインからの主体 makeba を、グループ Ateam.sales.doc.com. に追加します。
client% nisgrpadm -a Ateam panza valjean makeba.manf.doc.com. Added panza.sales.doc.com to group Ateam.sales.doc.com Added valjean.sales.doc.com to group Ateam.sales.doc.com Added makeba.manf.doc.com to group Ateam.sales.doc.com |
この動作を確認するには、nisgrpadm -l オプションを使用します。「明示的なメンバー」のカテゴリにあるメンバーを探してください。
次の例では、doc.com. ドメイン内のすべての NIS+ 主体を staff.doc.com. グループに追加します。これは doc.com. ドメイン内のクライアントから入力します。ドメイン名の前にある * 記号とドットに注意してください。
client% nisgrpadm -a Staff *.doc.com. Added *.doc.com. to group Staff.manf.doc.com. |
次の例では、NIS+ グループ admin.doc.com. を admin.manf.doc.com. グループに追加します。これは manf.doc.com. ドメインのクライアントから入力します。グループ名の前にある @ 記号に注意してください。
client% nisgrpadm -a admin @admin.doc.com. Added @admin.doc.com. to group admin.manf.doc.com. |
NIS+ グループのメンバーを表示するには、グループオブジェクトに対する読み取り権が必要です。-l オプションを使用します。
nisgrpadm -l group-name |
次の例では、admin.manf.doc.com. グループのメンバーを表示します。これは manf.doc.com. グループ内のクライアントから入力します。
client% nisgrpadm -l admin Group entry for admin.manf.doc.com. group: No explicit members No implicit members: Recursive members: @admin.doc.com. No explicit nonmembers No implicit nonmembers No recursive nonmembers |
NIS+ グループからメンバーを削除するには、グループオブジェクトに対する変更権が必要です。-r オプションを使用します。
nisgrpadm -r group-name members. . . |
次の例では、Ateam.sales.doc.com グループから NIS+ 主体 allende と hugo.manf.doc.com. を削除します。これは sales.doc.com.domain ドメイン内のクライアントから入力します。
client% nisgrpadm -r Ateam allende hugo.manf.doc.com. Removed allende.sales.doc.com. from group Ateam.sales.doc.com. Removed hugo.manf.doc.com. from group Ateam.sales.doc.com. |
次の例では、admin.manf.doc.com. グループから admin.doc.com. グループを削除します。これは manf.doc.com. ドメイン内のクライアントから入力します。
client% nisgrpadm -r admin @admin.doc.com. Removed @admin.doc.com. from group admin.manf.doc.com. |
ある NIS+ 主体が特定の NIS+ グループのメンバーであるどうかを調べるには、そのグループオブジェクトに対する読み取り権が必要です。-t オプションを使用します。
nisgrpadm -t group-name members. . . |
次の例では、NIS+ 主体 topadmin が admin.doc.com. グループに所属するかどうかを調べます。これは doc.com. ドメイン内のクライアントから入力します。
client% nisgrpadm -t admin topadmin topadmin.doc.com. is a member of group admin.doc.com. |
次の例では、sales.doc.com. ドメインの NIS+ 主体 jo が admin.sales.doc.com. グループに所属するかどうかを調べます。これは doc.com. ドメイン内のクライアントから入力します。
client% nisgrpadm -t admin.sales.doc.com. jo.sales.doc.com. jo.sales.doc.com. is a member of group admin.sales.doc.com. |
この章では、NIS+ ディレクトリのオブジェクトとその管理方法を説明します。
NIS+ ディレクトリオブジェクトは、NIS+ ドメインに関する情報を格納するために使われます。NIS+ ドメインごとに個別の NIS+ ディレクトリ構造があります。NIS+ ディレクトリの詳細は、第 4 章「NIS+ の名前空間」を参照してください。
NIS+ ディレクトリ関連のコマンドとその構文、オプションについては、nis+(1) のマニュアルページを参照してください。
niscat -o コマンドを使えば、NIS+ ディレクトリのオブジェクト属性を表示できます。このコマンドを使うには、ディレクトリオブジェクトの読み取り権が必要です。
ディレクトリのオブジェクト属性を表示するには、niscat -o とディレクトリ名を使います。
niscat -o directory-name |
次に例を示します。
rootmaster# niscat -o doc.com. Object Name : doc Owner : rootmaster.doc.com. Group : Domain : Com. Access Rights : r---rmcdr---r--- Time to Live : 24:0:0 Object Type : DIRECTORY . . |
nisls コマンドは、NIS+ ディレクトリの内容を表示します。このコマンドを使うには、ディレクトリオブジェクトに対する読み取り権が必要です。
簡潔形式での表示
nisls [-dgLmMR] directory-name |
詳細形式での表示
nisls -l [-gm] [-dLMR] directory-name |
オプション |
目的 |
---|---|
-d |
ディレクトリオブジェクト。ディレクトリの内容を表示するのではなく、別のオブジェクトのように扱う |
-L |
リンク。ディレクトリ名が実際にはリンクである場合、コマンドはリンクをたどり、リンクされたディレクトリの情報を表示する |
-M |
マスター。マスターサーバーだけから情報を取得する。これによって最新の情報が得られるが、マスターサーバーが使用中の場合は長時間を要することがある |
-R |
再帰的 (recursive)。ディレクトリを再帰的に表示する。つまり、ディレクトリ中に他のディレクトリがある場合、それらの内容も表示する |
-l |
長形式。情報を長形式で表示する。長形式では、オブジェクトのタイプ、作成時間、所有者、およびアクセス権を表示する |
-g |
グループ。情報を長形式で表示するとき、ディレクトリ所有者ではなく、そのグループ所有者を表示する |
-m |
変更時間。情報を長形式で表示するとき、ディレクトリ作成時間ではなく、その変更時間を表示する |
ディレクトリ内容をデフォルトの短形式で表示するには、次に示すオプションの内の 1 つまたは複数と、ディレクトリ名を使います。ディレクトリ名を指定しない場合、NIS+ はデフォルトのディレクトリを使います。
nisls [-dLMR] directory-name |
または
nisls [-dLMR] |
たとえば、次の nisls の場合は、ルートドメイン doc.com. のルートマスターサーバーから入力します。
rootmaster% nisls doc.com.: org_dir groups_dir |
次に、ルートマスターサーバーから入力した例をもう 1 つ示します。
rootmaster% nisls -R sales.doc.com. sales.doc.com.: org_dir groups_dir groups_dir.sales.doc.com.: admin org_dir.sales.doc.com.: auto_master auto_home bootparams cred . |
ディレクトリの内容を詳細形式で表示するには -l オプション、および次に示すオプションのうちの 1 つまたは複数を使います -g と -m のオプションは、表示される属性を変更します。ディレクトリ名を指定しない場合、NIS+ はデフォルトのディレクトリを使います。
nisls -l [-gm] [-dLMR] directory-name |
または
nisls -l [-gm] [-dLMR] |
次に示すのは、ルートドメイン doc.com. のマスターサーバーから入力した例です。
rootmaster% nisls -l doc.com. D r---rmcdr---r--- rootmaster.doc.com. date org_dir D r---rmcdr---r--- rootmaster.doc.com. date groups_dir |
この節では、nismkdir コマンドを使用して既存のドメインに非ルートサーバーを追加する方法を説明します。nisserver スクリプトを使うともっと簡単に非ルートサーバーを追加できますが、その方法については『Solaris ネーミングの設定と構成』で説明します。
nismkdir コマンドは、ルート以外の NIS+ ディレクトリを作成し、これをマスターサーバーに関連付けます。ルートディレクトリを作成するには、「nisinit コマンド」で説明する nisinit -r コマンドを使います。nismkdir コマンドを使って、複製サーバーを既存のディレクトリに追加できます。
NIS+ ディレクトリを作成するには、いくつかの関連作業のほかに、いくつかの前提条件があります。詳細は、『Solaris ネーミングの設定と構成』を参照してください。
ディレクトリを作成するには、以下のように入力します。
nismkdir [-m master-server] directory-name |
複製を既存のディレクトリに追加するには、以下のように入力します。
nismkdir -s replica-server directory-name nismkdir -s replica-server org_dir.directory-name nismkdir -s replica-server groups_dir.directory-name |
ディレクトリを作成するには、(ドメインのマスターサーバー上の) 親ディレクトリに対する作成権が必要です。まず -m オプションを使ってマスターサーバーを定義し、次に -s オプションを使って複製を定義します。
nismkdir -m master directory nismkdir -s replica directory |
nismkdir は必ず (複製サーバーではなく) マスターサーバー上で実行してください。複製サーバーで実行すると、マスターサーバーと複製サーバーの間で通信上の問題が発生します。
次の例では、sales.doc.com. ディレクトリを作成し、そのマスターサーバーである smaster.doc.com. とその複製サーバーである rep1.doc.com を指定します。これはルートマスターサーバーから入力します。
rootmaster% nismkdir -m smaster.doc.com. sales.doc.com. rootmaster% nismkdir -m smaster.doc.com. org_dir.sales.doc.com. rootmaster% nismkdir -m smaster.doc.com. groups_dir.sales.doc.com. rootmaster% nismkdir -s rep1.doc.com. sales.doc.com. rootmaster% nismkdir -s rep1.doc.com. org_dir.sales.doc.com. rootmaster% nismkdir -s rep1.doc.com. groups_dir.sales.doc.com. |
小規模またはテスト用の名前空間でないかぎりは推奨しませんが、nismkdir コマンドを使えば、独自のディレクトリを指定する代わりに、新しいディレクトリとして親ディレクトリのサーバーを使えます。次に 2 つの例を示します。
最初の例では、sales.doc.com. ディレクトリを作成し、これをその親ディレクトリのマスターと複製サーバーに関連付けます。
rootmaster% nismkdir sales.doc.com |
2 番目の例では、sales.doc.com. ディレクトリを作成し、独自のマスターサーバーである smaster.doc.com. を指定します。
rootmaster% nismkdir -m smaster.doc.com. sales.doc.com. |
複製サーバーは指定されないため、nismkdir を再び使用して複製を割り当てるまでは、新しいディレクトリにはマスターサーバーしかありません。sales.doc.com. ドメインがすでに存在する場合、上記の nismkdir コマンドは、salesmaster.doc.com. をその新しいマスターサーバーとし、その古いマスターサーバーを複製サーバーに格下げします。
この章では nismkdir コマンドを使用して複製サーバーを既存のシステムに追加する方法を説明します。簡単な方法としては、『Solaris ネーミングの設定と構成』で説明している nisserver スクリプトを使う方法があります。
以下の点に注意してください。
サブドメインサーバーは、サブドメインの 1 つ上の階層の親ドメイン (またはその一部) に置く。たとえば、名前空間に prime という名前のルートドメインと sub1 という名前のサブドメインがある場合は、次のようになる
prime ドメインにサービスを提供するマスターサーバーと複製サーバーは、prime がルートドメインであるため、prime ドメインの一部になる
sub1 サブドメインにサービスを提供するマスターサーバーと複製サーバーも、prime が sub1 の親ドメインであるため、prime ドメインの一部になる
マスターサーバーまたは複製サーバーから複数のドメインにサービスを提供することもできるが、そのような措置は避けた方がよい
新しい複製サーバーを既存のディレクトリに割り当てるには、-s オプションと、既存のディレクトリ名を使います。
nismkdir -s replica-server existing-directory-name nismkdir -s replica-server org_dir.existing-directory-name nismkdir -s replica-server groups_dir.existing-directory-name |
nismkdir コマンドは、ディレクトリがすでに存在することを知っているため、再び作成しません。単に、追加の複製サーバーを割り当てるだけです。たとえば、新しい複製サーバーマシン名が rep1 である場合は、以下のように入力します。
rootmaster% nismkdir -s rep1.doc.com. doc.com. rootmaster% nismkdir -s rep1.doc.com. org_dir.doc.com. rootmaster% nismkdir -s rep1.doc.com. groups_dir.doc.com. |
nismkdir は必ず (複製サーバーではなく) マスターサーバー上で実行してください。複製サーバーで実行すると、マスターサーバーと複製サーバーの間で通信上の問題が発生します。
先述のように nismkdir を 3 回繰り返して実行した後は、以下の 3 つのディレクトリでマスターサーバーから nisping を実行する必要があります。
rootmaster# nisping doc.com. rootmaster# nisping org_dir.doc.com. rootmaster# nisping group_dir.doc.com. |
この結果は以下のようになります。
rootmaster# nisping doc.com. Pinging replicas serving directory doc.com. : Master server is rootmaster.doc.com. Last update occurred at Wed Nov 18 19:54:38 1995 Replica server is rep1.doc.com. Last update seen was Wed Nov 18 11:24:32 1995 Pinging ... rep1.doc.com |
マスターサーバーの cron ファイルに、nisping コマンドが少なくとも 24 時間に一度 (この 3 つのディレクトリに対して) 実行されるよう設定しておくことをお勧めします。
nisrmdir コマンドでは、ディレクトリを削除したり、ディレクトリと複製サーバーを切り離すことができます。ディレクトリを削除、またはディレクトリと複製サーバーを切り離すと、その NIS+ ドメインに対しては、マシンは NIS+ 複製サーバーとしては機能しなくなります。
ディレクトリの削除では、まずマスターサーバーと複製サーバーをディレクトリから切り離し、次にそのディレクトリを削除します。
ディレクトリを削除するには、その親ディレクトリに対する削除権が必要です。
ディレクトリから複製サーバーを切り離すには、そのディレクトリに対する変更権が必要です。
nisrmdir コマンドの実行で問題が生じる場合は、「複製の失敗からの NIS+ ディレクトリの削除または分離」を参照してください。
ディレクトリ全体を削除し、そのマスターサーバーと複製サーバーを切り離すには、nisrmdir コマンドをオプションなしで実行します。
nisrmdir directory-name nisping domain |
次の例では、doc.com. ディレクトリの下の manf.doc.com. ディレクトリを削除します。
rootmaster% nisrmdir manf.doc.com. rootmaster% nisping doc.com. |
複製サーバーをディレクトリから切り離すには、まず、ディレクトリの org_dir と groups_dir サブディレクトリを削除します。その時は、nisrmdir コマンドに -s オプションを付けて実行します。サブディレクトリが削除されたら、親ドメインに戻って nisping を実行してください。
nisrmdir -s replicaname org_dir domain nisrmdir -s replicaname groups_dir .domain nisrmdir -s replicaname domain nisping domain |
次の例では、manfreplica1 サーバーを manf.doc.com. ディレクトリから切り離します。
rootmaster% nisrmdir -s manfreplica1 org_dir.manf.doc.com. rootmaster% nisrmdir -s manfreplica1 groups_dir.manf.doc.com. rootmaster% nisrmdir -s manfreplica1 manf.doc.com. rootmaster% nisping manf.doc.com. |
nisrmdir -s コマンドを実行したが、切り離し対象の複製サーバーがダウンしていた、または通信が途絶していたという場合、「Cannot remove replica name: attempt to remove a non-empty table」というエラーメッセージが出されます。このような場合は、マスターサーバー上で nisrmdir -f -s replicaname コマンドを実行すれば、強制的に切り離すことができます。ただし、nisrmdir -f -s コマンドでダウン状態の複製サーバーを切り離した場合、その複製サーバーがオンラインに復帰したらただちに nisrmdir -f -s コマンドを再実行して複製サーバーの /var/nis ファイルシステムの中を整理する必要があります。この nisrmdir -f -s replicaname コマンドの再実行を怠ると、複製サーバーに古い情報が残り、問題が生じる原因にもなりかねません。
nisrm コマンドは、標準の rm システムコマンドと似ています。このコマンドは、ディレクトリと空でないテーブルを除いて、名前空間からすべての NIS+ オブジェクトを削除します。nisrm コマンドを使うには、オブジェクトに対する削除権が必要です。しかし、この権利がない場合、-f オプションを使うことができます。このオプションは、アクセス権がなくても動作を強行しようと試みます。
nisgrpadm -d コマンド (「NIS+ グループを削除する」を参照) を使えばグループオブジェクトを削除でき、nistbladm -r または nistbladm -R (「テーブルを削除する」を参照) を使えばテーブルを空にできます。
nisrm [-if] object-name |
オプション |
目的 |
---|---|
-i |
照会。オブジェクトを削除する前に確認を要求する。指定されたオブジェクト名が完全指定されていない場合、このオプションが自動的に使われる |
-f |
強制。たとえ適切なアクセス権がない場合でも、削除の強行を試みる。nischmod コマンドを使ってアクセス権の変更を試み、再度オブジェクトの削除を試みる |
ディレクトリ以外のオブジェクトを削除するには、nisrm コマンドを使い、オブジェクト名を指定します。
nisrm object-name... |
次の例では、名前空間からグループとテーブルを削除します。
rootmaster% nisrm -i admins.doc.com. groups.org_dir.doc.com. Remove admins.doc.com.? y Remove groups.org_dir.doc.com.? y |
rpc.nisd コマンドは、NIS+ デーモンを起動します。このデーモンは NIS 互換モードで実行でき、NIS クライアントからの要求にも応答できます。NIS+ デーモンを起動するにはアクセス権は不要ですが、そのすべての前提条件と関連作業を知っておく必要があります。これらについては、『Solaris ネーミングの設定と構成』を参照してください。
デフォルトでは、NIS+ デーモンはセキュリティレベル 2 で起動します。
デーモンを起動するには、以下のように入力します。
rpc.nisd |
デーモンを NIS 互換モードで起動するには、以下のように入力します。
rpc.nisd -Y [-B] |
DNS 転送機能によって NIS 互換デーモンを起動するには、以下のように入力します。
rpc.nisd -Y -B |
オプション |
目的 |
---|---|
-S security-level |
セキュリティレベルを指定する。0 は「NIS+ セキュリティを使用しない」、2 は「最高レベルの NIS+ セキュリティを使用する」という意味 |
-F |
デーモンによって提供されるディレクトリのチェックポイント設定を強行する。この動作は、ディレクトリのトランザクションログを空にして、ディスク空間を解放することになる |
DNS 転送機能によって NIS+ 互換デーモンを起動する
rpc.nisd |
ルートマスター以外の任意のサーバーで NIS+ デーモンを起動するには、このコマンドをオプションなしで実行します。
デーモンは、デフォルトであるセキュリティレベル 2 で起動します。セキュリティレベル 0 でデーモンを起動するには、-S フラグを使います。
rpc.nisd -S 0 |
ルートマスターを含む任意のサーバーで、NIS+ デーモンを NIS 互換モードで起動できます。-Y (大文字) オプションを使います。
rpc.nisd -Y |
サーバーが再起動された場合にデーモンを NIS 互換モードで再起動させるには、サーバーの /etc/init.d/rpc ファイル内で EMULYP=Y を含む行をコメント解除しなければなりません。
NIS 互換モードで実行している NIS+ デーモンに DNS 転送機能を追加するには、rpc.nisd に -B オプションを追加します。
rpc.nisd -Y -B |
サーバーが再起動された場合に、デーモンを DNS 転送 NIS 互換モードで再起動させるには、サーバーの /etc/init.d/rpc ファイル内の EMULYP=-Y を含む行をコメント解除し、次のように変更しなければなりません。
EMULYP -Y -B |
NIS+ デーモンを停止するには、その実行モードが通常であろうと NIS 互換であろうと、他のデーモンと同じようにプロセスを終了させます。最初にそのプロセス ID を見つけ、次にプロセスを終了させます。次に例を示します。
rootmaster# ps -e | grep rpc.nisd root 1081 1 61 16:43:33 ? 0:01 rpc.nisd -S 0 root 1087 1004 11 16:44:09 pts/1 0:00 grep rpc.nisd rootmaster# kill 1081 |
この節では、nisinit コマンドを使用してワークステーションクライアントを初期設定する方法について説明します。クライアントの初期設定は、nisclient スクリプトを使用するとさらに容易に行えます (『Solaris ネーミングの設定と構成』を参照)。
nisinit コマンドは、NIS+ クライアントとなるワークステーションを初期設定します。rpc.nisd コマンドと同様、nisinit コマンドを使うにはアクセス権は不要ですが、その前提条件と関連作業を知っておく必要があります。これらについては、『Solaris ネーミングの設定と構成』を参照してください。
クライアントを初期設定するには、次の 3 つの方法があります。
ホスト名による方法
ブロードキャストによる方法
コールドスタートファイルによる方法
前提条件と関連作業は、方法によってそれぞれ異なります。たとえば、ホスト名によってクライアントを初期設定するには、その前にクライアントの /etc/hosts ファイルまたは /etc/inet/ipnodesファイルに、使用するホスト名を登録しなければなりません。また nsswitch.conf ファイルの hosts の最初の選択肢として、files を指定する必要があります。IPv6 アドレスには、hosts の最初の選択肢としてipnodes を指定してください。 前提条件や関連作業を含め、各方法の詳細は、『Solaris ネーミングの設定と構成』を参照してください。nisinit コマンドを使う手順を次にまとめてみます。
ホスト名によってクライアントを初期設定するには、-c と -H のオプションを使い、クライアントがそのコールドスタートファイルを取得するサーバー名を指定します。
nisinit -c -H hostname |
コールドスタートファイルによってクライアントを初期設定するには、-c と -C のオプションを使い、コールドスタートファイル名を指定します。
nisinit -c -C filename |
ブロードキャストによってクライアントを初期設定するには、-c と -B のオプションを使います。
nisinit -c -B |
ルートマスターサーバーを初期設定するには、nisinit -r コマンドを使います。
nisinit -r |
ここで次の情報が必要になります。
ワークステーション (ルートマスターサーバーにする) のスーパーユーザーのパスワード
新しいルートドメイン名。ルートドメイン名は少なくとも 2 つの要素 (ラベル) で構成され、その末尾にドット (ピリオド) が打たれていなければならない (例: something.com)。最後の要素はインターネットの組織ドメイン (表 13-4 を参照) か、2〜3 文字の地域識別子 (日本であれば .jp) のどちらかにするように決められている
ドメイン |
種類 |
---|---|
com |
営利団体 |
edu |
教育機関 |
gov |
行政機関 |
mil |
軍事組織 |
net |
ネットワークサポートセンター |
org |
非営利団体 |
int |
国際組織 |
nis_cachemgr コマンドは、NIS+ キャッシュマネージャプログラムを起動します。このプログラムは、すべての NIS+ クライアント上で動作します。キャッシュマネージャは、名前空間で最もよく使われるディレクトリをサポートする NIS+ サーバーの位置情報キャッシュを管理します。位置情報はトランスポートアドレス、認証情報、生存期間値などです。
キャッシュマネージャが起動すると、クライアントのコールドスタートファイルから初期情報を取得し、それを /var/nis/NIS_SHARED_DIRCACHE ファイルにダウンロードします。
キャッシュマネージャは、クライアントワークステーションとして要求を行います。クライアントワークステーションには必ず適切な資格を持たせてください。そうしないと、性能が向上するどころか、キャッシュマネージャが性能を低下させます。
キャッシュマネージャを起動するには、nis_cachemgr コマンドを入力します。
client% nis_cachemgr client% nis_cachemgr -i |
-i オプションがない場合、キャッシュマネージャは再起動されますが、情報を /var/nis/NIS_SHARED_DIRCACHE ファイルに入れておきます。コールドスタートファイル内の情報は、このファイル内の既存情報に追加されます。-i オプションは、キャッシュファイルをクリアし、クライアントのコールドスタートファイルの内容からこれを再び初期設定します。
キャッシュマネージャを停止させるには、他のプロセスと同様にプロセスを終了します。
nisshowcache コマンドは、クライアントのディレクトリキャッシュの内容を表示します。
nisshowcache コマンドは、/usr/lib/nis 内にあります。このコマンドはキャッシュヘッダーとディレクトリ名だけを表示します。ルートマスターサーバーから入力した例を次に示します。
rootmaster# /usr/lib/nis/nisshowcache -v Cold Start directory: Name : doc.com. Type : NIS Master Server : Name : rootmaster.doc.com. Public Key : Diffie-Hellman (192 bits) Universal addresses (3) . . Replicate: Name : rootreplica1.doc.com. Public Key : Diffie-Hellman (192 bits) Universal addresses (3) . . . Time to live : 12:0:0 Default Access Rights : |
NIS+ データセットに変更を加えると、その変更は、当該 NIS+ ドメイン (またはサブドメイン) のマスターサーバーのメモリに格納されます。変更の記録はマスターサーバーのトランザクションログ (/var/nis/data/trans.log) にも残されます。
通常、NIS+ データセットに変更が加えられると、その 120 秒 (2 分) 後に、マスターサーバーから当該ドメインの複製サーバーにその変更の内容が転送されます。この転送プロセスのことを「ping」といいます。マスターサーバーから複製サーバーへの ping が実行されると、通知された変更内容に従って複製サーバーのデータセットが更新されます。これにより、変更された NIS+ データがマスターサーバーと複製サーバーの両方のメモリに格納されることになります。
自動 ping プロセスが不調で複製サーバーのデータセットが更新されないこともあります。その場合は、「ping を強制的に実行する」の説明に従って ping を強制的に実行する必要があります。複製サーバーが最新の NIS+ データどおりに正しく更新されているかどうか不安な場合は、「最新更新時間を表示する」の説明に従って複製サーバーが最後に更新されたのはいつであるかを確認してください。
NIS+ データセットに対する変更は、サーバーのメモリーに格納され、トランザクションログに記録されたのち、ディスク上の NIS+ テーブルに書き込まれなければなりません。この NIS+ テーブルを更新することを「チェックポイントを実行する」といいます。
チェックポイントの実行は自動的には行われません。「ディレクトリにチェックポイントを実行する」の説明に従ってチェックポイントコマンドを実行する必要があります。
複製サーバーが最後に ping されたのはいつであるかを表示する (詳細は、「最新更新時間を表示する」を参照)
自動 ping サイクルが不調に終わった場合、マスターサーバーから複製サーバーへの ping を強制的に実行する (詳細は、「ping を強制的に実行する」を参照)
サーバーにチェックポイントを実行する (詳細は、「ディレクトリにチェックポイントを実行する」を参照)
-u オプションを指定して nisping コマンドを実行すると、ローカルドメインのマスターサーバーと複製サーバーが更新された時間が表示されます。
/usr/lib/nis/nisping -u [domain] |
他のドメインで最後に更新が行われた時間を表示するには、コマンド行にそのドメイン名を指定します (-u オプションを指定して nisping コマンドを実行した場合、複製サーバーに対する ping は一切実行されない点に注意)。
たとえば、ローカルドメイン doc.com. で複製サーバーが最後に更新された時間を表示するには、次のように入力します。
rootmaster# /usr/lib/nisping -u Last updates for directory doc.com.: Master server is rootmaster.doc.com. Last update occurred at Wed Nov 25 10:53:37 1992 Replica server is rootreplica1.doc.com. Last update seen was Wed Nov 25 10:53:37 1992 |
-u オプションを指定して nisping コマンドを実行した結果、複製サーバーが正しく更新されていないことがわかったとします。そのような場合は、nisping コマンドを実行することにより、マスターサーバーからドメイン内のすべての複製サーバーに対して、または特定の複製サーバーに対して、ping を強制的に実行できます。
すべての複製サーバーを ping の対象とする場合、次に示すように、nisping コマンドをオプションなしで実行します。
/usr/lib/nis/nisping |
これにより、マスターサーバーからドメイン内のすべての複製サーバーへの ping が強制的に実行されます。ローカルドメイン doc.com. のすべての複製サーバーに対する ping を強制的に実行するには、次のように入力します。
rootmaster# /usr/lib/nis/nisping Pinging replicas serving directory doc.com.: Master server is rootmaster.doc.com. Last update occurred at Wed Nov 25 10:53:37 1992 Replica server is rootreplica1.doc.com. Last update seen was Wed Nov 18 11:24:32 1992 Pinging ... rootreplica1.doc.com. |
ローカルドメインでないドメイン内のすべての複製サーバーに対し ping を実行するには、ドメイン名を指定します。
/usr/lib/nis/nisping domainname |
特定の 1 台のホスト上のすべてのディレクトリにあるすべてのテーブルに対し ping を実行することもできます。この場合、-a オプションを使用します。
/usr/lib/nis/nisping -a hostname |
スワップの頻度やディスク領域との関連でトランザクションログが大きくなりすぎる場合、各ドメインおよびサブドメインに対しては、少なくとも 24 時間に 1 回はチェックポイントを実行する必要があります。
大きなドメイン、または大きなトランザクションログを持つドメインに対してチェックポイントを実行すると、終了するまでにかなりの時間がかかり、その間 NIS+ サーバーが拘束され、NIS+ サービスの速度が低下します。サーバーは、チェックポイントを実行している間もサービス要求に応答しますが、更新できません。できるだけ、システムが混んでいない時間帯を選んでチェックポイントを実行することをお勧めします。チェックポイントの実行スケジュールは cron ファイルで調整できます。
チェックポイントを実行するには、当該ドメインのマスターサーバー上で nisping -C コマンドを実行します。先にすべての複製サーバーに対して ping を実行してから、チェックポイントを実行することをお勧めします。その場合には、複製サーバーに対して常に最新のデータでチェックポイントを実行できます。
特定のディレクトリに対してチェックポイントを実行するには、次に示すように、-C オプションを指定して nisping コマンドを実行します。
rootmaster# /usr/lib/nis/nisping rootmaster# /usr/lib/nis/nisping -C org_dir |
ローカルドメイン内のすべてのディレクトリに対してチェックポイントを実行するには、次に示すように、-C -a オプションを指定して nisping コマンドを実行します。
rootmaster# /usr/lib/nis/nisping rootmaster# /usr/lib/nis/nisping -C -a |
サーバーによってそのトランザクションログの情報が NIS+ テーブルに転送されると、ログファイル内のトランザクションは、ディスク領域の節約のため消去されます。
doc.com. ドメイン内のすべてのディレクトリに対してチェックポイントを実行するには、次のように入力します。
rootmaster# /usr/lib/nis/nisping -C -a Checkpointing replicas serving directory doc.com. : Master server is rootmaster.doc.com. Last update occurred at Wed May 25 10:53:37 1995 Master server is rootmaster.doc.com. checkpoint has been scheduled with rootmaster.doc.com. Replica server is rootreplica1.doc.com. Last update seen was Wed May 25 10:53:37 1995 Replica server is rootreplica1.doc.com. checkpoint has been scheduled with rootmaster.doc.com. |
nislog コマンドは、トランザクションログの内容を表示します。
/usr/sbin/nislog /usr/sbin/nislog -h [number] /usr/sbin/nislog -t [number ] |
オプション |
機能 |
---|---|
-h [num] |
ログの先頭からトランザクションを表示する。数字を指定しなければ、最初のトランザクションから表示が開始される。0 を指定すると、ログヘッダーだけが表示される |
-t [num] |
ログの末尾からトランザクションを表示する。数字を指定しなければ、最後のトランザクションから表示が開始される。0 を指定すると、ログヘッダーだけが表示される |
-v |
冗長モード |
各トランザクションは、トランザクションの明細部とオブジェクト定義のコピー部の 2 つの部分から構成されます。
doc.com. ディレクトリが最初に作成されたときに作られたトランザクションログエントリを次の例に示します。「XID」はトランザクション ID を意味します。
rootmaster# /usr/sbin/nislog -h 1 NIS Log printing facility. NIS Log dump: Log state : STABLE Number of updates : 48 Current XID : 39 Size of log in bytes : 18432 ***UPDATES*** @@@@@@@@@@@@@@TRANSACTION@@@@@@@@@@@@@@ #00000, XID : 1 Time : Wed Nov 25 10:50:59 1992 Directory : doc.com. Entry type : ADD Name Entry timestamp : Wed Nov 25 10:50:59 1992 Principal : rootmaster.doc.com. Object name : org_dir.doc.com. ...................Object...................... Object Name : org_dir Owner : rootmaster.doc.com. Group : admin.doc.com. Domain : doc.com. Access Rights : r---rmcdr---r--- Time to Live : 24:0:0 Object Type : DIRECTORY Name : `org_dir.doc.com.' Type: NIS Master Server : rootmaster.doc.com. . . ................................................ @@@@@@@@@@@@@@TRANSACTION@@@@@@@@@@@@@@ #00000, XID : 2 |
nischttl コマンドは、名前空間内のオブジェクトまたはエントリの生存期間値を変更します。キャッシュマネージャは、この生存期間値を使って、キャッシュエントリをいつ期限切れにするかを決めます。生存期間を指定するには、合計秒数か、日、時間、分、秒の組み合わせのいずれかを使います。
オブジェクトまたはエントリに割り当てる生存期間値は、オブジェクトの安定性に左右されます。よく変化するオブジェクトの場合、生存期間値を低くします。安定したオブジェクトの場合、高い値を指定します。高い生存期間値であれば、1 週間などを指定し、低い値であれば 1 分未満を指定します。パスワードエントリの生存期間値は約 12 時間とし、1 日に 1 回パスワード変更ができるようにする必要があります。RPC テーブル内のエントリなど、あまり変化しないテーブルのエントリには、数週間の値を設定できます。
オブジェクトの生存期間を変更するには、そのオブジェクトに対する変更権が必要です。テーブルエントリの生存期間を変更するには、テーブルに対する変更権が必要であり、テーブルがなければエントリに対して、エントリもなければ変更したい列に対して変更権が必要です。
オブジェクトまたはテーブルエントリの現在の生存期間値を表示するには、第 10 章「NIS+ のアクセス権の管理」で説明する nisdefaults -t コマンドを使います。
オブジェクトの生存期間値を変更するには、以下のいずれかのように入力します。
nischttl time-to-live object-name |
nischttl [-L] time-to-live object-name |
エントリの生存期間値を変更するには、以下のいずれかのように入力します。
nischttl time-to-live ¥ [column=value,...], ¥ table-name |
nischttl [-ALP] time-to-live ¥ [column=value,...], ¥ table-name |
「秒」
数字だけで文字を指定しなければ、単位が秒であると解釈される (例 : 1234 は 1234 秒)。数字の後に s をつけると、単位が秒であると解釈される (例 : 987s は 987 秒)。日、時間、分などとともに指定する場合は、秒であることを明らかにするため s をつける
「分」
数字の後に m を指定すると、単位が分であると解釈される (例: 90m は 90 分)
「時間」
数字の後に h をつけると、単位が時間であると解釈される (例: 9h は 9 時間)
「日」
数字の後に d をつけると、単位が日であると解釈される (例:7d は 7 日)
以上の値は組み合わせて使うことができます。たとえば「 4d3h2m1s 」は、4 日 3 時間 2 分 1 秒を意味します。
表 13-6 nischttl 構文のオプション
オプション |
目的 |
---|---|
-A |
すべて。[column=value] 指定に合致する全エントリに変更を適用する |
-L |
リンク。リンクをたどり、リンク自体ではなく、リンクされたオブジェクトまたはエントリを変更する |
-P |
パス。条件を満足するエントリが 1 つ見つかるまで、パスをたどる |
オブジェクトの生存期間を変更するには、生存期間の値とオブジェクト名を指定して nischttl コマンドを入力します。-L コマンドを追加すれば、リンクされたオブジェクトにまで変更を拡張できます。
nischttl -L time-to-live object-name |
生存期間は秒か、日、時間、分、秒の組み合わせかで指定できます。前者の場合、秒数だけを指定します。後者の場合、日数、時間数、分数と秒数に「 s、m、h、d」をつけてください。同じ動作をする 2 つの例を次に示します。
client% nischttl 86400 sales.doc.com. client% nischttl 24h sales.doc.com. client% nischttl 2d1h1m1s sales.doc.com. |
最初の 2 つでは、sales.doc.com. ディレクトリの生存期間が 86,400 秒、つまり 24 時間に変更されます。3 つ目では、hosts テーブル内の全エントリの生存期間が 176,461 秒、つまり 2 日と 1 時間 1 分 1 秒に変更されます。
エントリの生存期間を変更するには、インデックス付きのエントリフォーマットを使います。-A、-L、または -P のどのオプションでも使えます。
nischttl [-ALP] time-to-live ¥ [column=value,...], ¥ table-name |
Cシェル を使用している場合、[ ] がメタキャラクタとして解釈されないように引用符で囲みます。
次に示す例は上記の例と似ていますが、オブジェクトではなく、テーブルエントリの値を変更します。
client% nischttl 86400 '[uid=99],passwd.org_dir.doc.com.' client% nischttl 24h `[uid=99],passwd.org_dir.doc.com.' client% nischttl 2d1h1m1s `[name=fred],hosts.org_dir.doc.com' |
この章では、NIS+ テーブルとその管理方法について説明します。(デフォルトの NIS+ テーブルの詳細は、付録 C 「NIS+ テーブルの情報」 を参照してください。)
NIS+ で使われる情報は NIS+ テーブルに格納されます。Solaris 8 リリースに付属のデフォルトの NIS+ システムテーブルについては、付録 C 「NIS+ テーブルの情報」 を参照してください。
これらのコマンドの構文やオプションなどの詳細は、nis+(1) のマニュアルページを参照してください。
NIS+ テーブルに関連した作業のうちいくつかは、 Solstice AdminSuiteTMツールを使用すると容易に行えます。
nistbladm コマンドは NIS+ テーブル管理コマンドの中でも最も重要なコマンドであり、NIS+ ディレクトリオブジェクトに格納されている NIS+ テーブル上で使います。nistbladm コマンドを使うと、NIS+ テーブルまたはそのエントリを作成、修正、削除できます。ただし、ディレクトリのないところにテーブルを作成はできません。同様に、テーブルと列が定義されていないところにエントリを追加できません。
テーブルを作成するには、そのテーブルが所属するディレクトリに対する作成権が必要です。テーブルを削除するには、そのディレクトリに対する削除権が必要です。テーブルの内容を変更 (エントリの追加、変更、または削除) するには、そのテーブルまたはエントリの変更権が必要です。
nistbladm コマンドの一般的な構文は次のとおりです。
nistbladm -a column=" value" ¥ column=" value" ¥ column=" value" ¥ ... tablename nistbladm -a indexedname |
nistbladm options ¥ [columspec | columnvalue] ¥ [tablename | indexedname ] |
columnspec には、テーブル内に作成する列を指定する (具体的な指定方法については、「テーブルの列を指定する」 を参照)
columnvalue には、tablename によって表されるテーブルの中の特定のセルを指定する (具体的な指定方法については、「nistbladm と列の値」を参照)
tablename には、テーブル名 (hosts.org_dir.doc.com. など) を指定する
indexedname には、特定のテーブルの中の特定のセル値を指定する (具体的な指定方法については、「nistbladm と列の値」を参照) 。indexedname は本質的に、columnvalue と tablename の役割を兼ね備えている
オプション |
説明 |
---|---|
-a | -A |
既存の NIS+ テーブルにエントリを追加する。-a を指定した場合、nistbladm コマンドを実行すると既存のエントリが上書きされる場合には、エラーが返される。-A を指定した場合、nistbladm コマンドが既存エントリを上書きする場合でも強制的に実行される (「エントリをテーブルに追加する」を参照) |
-D defaults |
別のデフォルト特性を使ってオブジェクトを作成する (詳細は、デフォルトの nistbladm(1) のマニュアルページを参照) |
-d |
テーブルを破棄する (「テーブルを削除する」を参照) |
-c |
テーブルを作成する ( 「テーブルを作成する」を参照) |
-r | -R |
既存の NIS+ テーブルからエントリ (1 つまたは複数) を削除する。-r を指定した場合、複数のエントリの削除につながる nistbladm コマンドは実行されず、エラーが返される。-R を指定した場合、複数のエントリの削除につながる nistbladm コマンドであっても強制的に実行される (「テーブルからエントリを削除する」を参照) |
-m |
テーブルエントリを修正するためのオプション。旧リリースとの互換性を維持するためにだけ残されている。エントリを修正するのであれば、-e オプションまたは -E オプションを使うほうが望ましい |
-e | -E |
既存の NIS+ テーブルのエントリを修正する。-e を指定した場合、複数のエントリの変更につながる nistbladm コマンドは実行されず、エラーが返される。-E を指定した場合、複数のエントリの変更につながる nistbladm コマンドであっても強制的に実行される (「エントリを修正する」を参照) |
列の値は、テーブル内の個々のエントリを識別するために使われます。列の値の書式は次のとおりです。
columname="value", ¥ columnname="value ", ... |
columname はテーブルの列名を示す
value は列内の特定のセルの内容 (値) を示す。この値により、テーブルの行を識別することができる (column=value を指定してテーブルデータを作成または修正する場合は、必ず value を引用符で囲むこと)
たとえば、マシン名と IP アドレスを登録した hosts という名前のテーブルがあるとします。
表 14-2 サンプルテーブル hosts
IP アドレス |
名前 |
別名 |
---|---|---|
129.146.168.4 |
altair | |
129.146.168.119 |
deneb |
|
129.146.168.120 |
regulus |
dnsmaster |
129.146.168.121 |
regulus |
dnsmaster |
129.146.168.11 |
sirius |
このサンプルテーブルの altair エントリ (行) を識別するには、次の 3 通りの column=value の指定方法が考えられます。
name=altair
address=129.146.168.4
name=altair,address=129.146.168.4.
上記のテーブルで注目すべき点としては、regulus という名前のマルチホームマシンに 2 つの IP アドレスが割り当てられていることです。この場合、ホストマシン regulus の column=value は 2 つの行を示します。そこで、最初の regulus 行だけを識別したいという場合は次のいずれかを入力します。
address=129.146.168.120
address=129.146.168.120.,name=regulus,dnsmaster
nistbladm コマンドの一部のオプションには、テーブル内のすべての列に column=value を指定しなければならないものがあります。
NIS+ テーブルを作成する際は、S フラグまたは I フラグを指定し、1 つまたは複数の列が検索可能になるようにします (「テーブルの列を指定する」を参照)。なお、niscat -o tablename と入力すれば、テーブルの列とその特性を一覧表示できます。
テーブル内で行の「識別」に使われるのが検索可能列です。検索可能列の値 (値の組み合わせ) はすべて一意でなければなりません。したがって、検索可能列が 1 つしかないテーブルの場合、各行の検索可能列の値はすべて一意でなければならず、重複は一切許されません。
ここで、city という名前の検索可能列と country という名前の検索不可列からなるテーブルを作成する場合を想定します。次に示すのは、正しい (City 列に重複がない) テーブルの例です。
City |
Country |
---|---|
San Francisco |
United States |
Santa Fe |
United States |
Santiago |
Chile |
次は正しくない (City 列に重複がある) テーブルの例です。
City |
Country |
---|---|
London |
Canada |
London |
England |
1 つのテーブルに検索可能列が複数ある場合は、検索可能列どうしの値の組み合わせが一意であればかまいません。ここでは、Lastname および Firstname という 2 つの検索可能列と、city という検索不可列からなるテーブルを作成する場合を想定します。次に示すのは、正しい (検索可能列の値の組み合わせに重複がない) テーブルの例です。
Lastname |
Firstname |
City |
---|---|---|
Kuznetsov |
Sergei |
Odessa |
Kuznetsov |
Rima |
Odessa |
Sergei |
Alex |
Odessa |
次は正しくない (検索可能列の値の組み合わせに重複がある) テーブルの例です。
Lastname |
Firstname |
City |
---|---|---|
Kuznetsov |
Rima |
Odessa |
Kuznetsov |
Rima |
Chelm |
NIS+ のコマンドはいずれも、検索可能列の値に基づいて特定の行を識別します。
NIS+ には、テーブル名と列の値の検索基準の組み合わせ (これを「インデックス名」という) によって特定のテーブルの特定のエントリを識別する、というテーブル管理の方法もあります。インデックス名の書式は次のとおりです。
[search_criteria], tablename.directory |
search_criteria には検索基準を指定しますが、このとき角カッコ ([]) で囲むのを忘れないでください。書式は次のとおりです。
columname=value, ¥ columname=value ,... |
columname=value にはテーブルの検索可能列の値を指定します (「nistbladm と列の値」を参照)。
たとえば、表 14-2 の altair エントリを識別するには、次のようにインデックス名を指定します。
[addr=129.146.168.4,cname=altair],hosts.org_dir.doc.com. |
nistbladm -R コマンドを使用すると、間になにも入れない角カッコ [ ]をすべてのテーブル列を指定するワイルドカードとして使用し、テーブル中のすべてのエントリを一度に削除できます。
Solaris の NIS+ 環境には 3 種類のグループがあります。
UNIXグループ - UNIX グループに関する情報は groups.org_dir テーブルに格納される。UNIX グループ情報の管理には nistbladm コマンドを使う
ネットグループ - ネットグループに関する情報は netgroups.org_dir テーブルに格納される。ネットグループ情報の管理には nistbladm コマンドを使う
NIS+ グループ - NIS+ グループに関する情報は groups_dir ディレクトリオブジェクトのテーブル (1 つまたは複数) に格納される。NIS+ グループ情報の管理には nisgrpadm コマンドを使う
NIS+ グループの管理に nistbladm を使うことはできません。
その他のグループの詳細は、「Solaris グループ」を参照してください。
NIS+ テーブルには、少なくとも 1 つの列が必要で、その列のうち少なくとも 1 つが検索可能でなければなりません。NIS+ テーブルを作成するには、nistbladm コマンドに -c オプションを付けて使います。
nistbladm -c tabletype columnspec ¥ ... tablename |
tabletype は、単にテーブルをあるテーブルクラスに所属するものとして識別する文字列です。
columnspec 引数には、各列の名前と特性を指定します。1 つの columnspec には、新規テーブルに含める、それぞれの列を入力してください。
nistbladm -c tabletype columnspec columnspec ¥ columnspec tablename |
columnspec の書式については、「テーブルの列を指定する」を参照してください。
各 columnspec エントリは、以下の形式のように、2 つから 4 つの要素から成っています。
name=type,rights: |
構成要素 |
説明 |
---|---|
name |
列の名前 |
= |
等号記号 (必須) |
type |
(オプション) S、I、または C で列の種類を指定する。表 14-4 参照。type を指定しないと、その列はデフォルトとなる |
rights |
(オプション) アクセス権を指定する。ここに指定したアクセス権は、テーブル全体や特定エントリに付与したアクセス権より優先される。access を指定しないと、その列のアクセス権は、テーブル全体や特定エントリに付与したアクセス権になる。アクセス権の構文については、「コマンドによるアクセス権の指定」を参照 |
列には、次に挙げる種類のうち 1 つを指定できます。
表 14-4 列の種類
種類 |
説明 |
---|---|
|
等号 (=) のみ。列の種類は指定しない。その列は検索可能にもならなければ、暗号化されることもない |
S |
検索可能 |
I |
大文字と小文字の区別をしない。NIS+ コマンドで列を検索する場合、大文字と小文字を区別しない |
C |
暗号化する |
NIS+ の各コマンドは、列全体を調べ、検索可能列の値に基づいて個々の行を識別します。検索可能列は S フラグまたは I フラグで指定します (データベースの分野では、検索可能列のことをキー列といいます)。テーブルの最初の列は必ず検索可能にします。その他の列は検索可能にする必要はありません。検索可能列はそのテーブル内の行の識別に使われるため、検索可能列を複数にする場合は、最初の列とその隣の列を検索可能にします。検索可能列の間に通常の列を置くことはできません。したがって、常に先頭の列を検索可能とし、検索可能列の数を 1 つ増やすたびにその隣の列を検索可能にしていきます (検索可能列の詳細は、「nistbladm、検索可能列、キー、列の値」を参照)。
アクセス権だけを指定する場合、コンマを使用する必要はありません。-S、-I、-C フラグの 1 つか複数を指定する場合は、アクセス権の前にコンマを追加します。
以下の例では、上と同じテーブルが作成されますが、最初の 2 列にはその列に固有なアクセス権が付与されます。
master% nistbladm -c depts Name=I,w+m Site=w+m Name=C ¥ divs.mydir.doc.com. |
テーブル作成時の列のアクセス権の指定については、「テーブル作成時の列権限設定」を参照してください。
NIS+ では、すべての列エントリが NULL で終了するものと仮定しています。NIS+ テーブルに情報を書き込むアプリケーションやルーチンは、列エントリをすべて NULL で終了するように構成しなければなりません。
自動マウントテーブルには 2 つの列しか作ることができません。1 番目の列には key という名前を付け、2 番目の列には value という名前を付けます。たとえば、auto1 という名前の自動マウントテーブルを作成するには、次のように入力します。
master% nistbladm -c key-value key=S value= auto1.org_dir.doc.com. |
テーブルを削除するには、-d オプションを使ってテーブル名を入力します。
nistbladm -d tablename |
テーブルを削除するには、その前にテーブルが空になっていなければなりません (「テーブルからエントリを削除する」を参照)。次の例では、doc.com. ディレクトリから divs テーブルを削除します。
rootmaster% nistbladm -d divs.doc.com. |
エントリ (行) をテーブルに追加するには、nistbladm コマンドに -a オプションまたは -A オプションを指定し、続けて column=value のペア (1 つまたは複数)、テーブル名の順に指定します。あるいは、nistbladm コマンドに -a オプションまたは -A オプションを指定し、続けてインデックス名を指定します (「nistbladm とインデックス名」を参照)。
nistbladm [-a | -A] indexedname nistbladm [-a | -A] column="value" ¥ column="value" ¥ ... tablename |
-a オプションまたは -A オプションを指定して既存のテーブルに新しいエントリ (行) を追加する場合は、次の点に注意してください。
value は必ず引用符で囲む。たとえば、新たに追加するエントリの cname 列の値を deneb にする場合は、column=value ペアを cname="deneb" と指定する
テーブル内のすべての列の値を指定する
追加するエントリ (行) の列を空白にする場合は、column=" " と指定する。つまり、value には、引用符で囲んだ半角スペースを指定する
NIS+ はネームサービスであり、設計上、そのテーブルにはオブジェクト本体ではなく、オブジェクトのリファレンスが格納されます。NIS+ は、最適化された状態では 10,000 におよぶオブジェクトをサポートし、すべてのテーブルのサイズを合計しても 10M バイトを超えることはありません。NIS+ では、1 つの列のフィールドサイズの合計が 7k を超えるようなテーブルはサポートされません。テーブルが大きすぎると、rpc.nisd は失敗します。
nistbladm コマンドに -a オプションを指定しておくと、追加するエントリと同じエントリがすでに存在する場合は、エントリの上書きは行われずにエラーが返されます。あるエントリの検索可能列の値が、追加するエントリの検索可能列の値とまったく同じである場合、そのエントリは「すでに存在しているもの」と判断されます。(このとき、検索不可列の値は一切考慮されません。)
-a オプションを指定する場合、次のように、テーブル内のすべての列の値を指定する必要があります。
nistbladm -a column=" value" ¥ column=" value" ¥ ... tablename nistbladm -a indexedname |
(テーブルのすべての列名とその特性を表示する場合は、niscat -o tablename コマンドを実行します。)
たとえば、depts テーブルに新しい行を追加する場合は、次に示すように、列の数だけ column=value ペアを指定します。
rootmaster% nistbladm -a Name='R&D' Site='SanFran' ¥ Name='vattel' depts.doc.com. |
なお、これと同じエントリをインデックス名を指定して追加する場合は、次のように入力します。
rootmaster% nistbladm -a [Name='R&D',Site='SanFran' ¥ Name='vattel'],depts.doc.com. |
いずれの場合も、次のようなテーブルとなります。
Dept |
Site |
Name |
---|---|---|
R&D |
SanFran |
vattel |
C シェルを使っている場合は、角カッコを含む数式を引用符でオフセットすることもできます。
nistbladm コマンドでは 1 回につき 1 つのエントリしか追加できません。つまり、追加する行の数だけ nistbladm コマンドを実行する必要があります。
追加するエントリ (行) の各列と同じ値を持つ行がすでに存在する場合、nistbladm -a はエラーを返します。1 つのテーブルの中に同じ行が存在することはできません。検索可能列の値が同一である場合、それらの行は同一であるとみなされます。このとき、検索不可列の値は考慮されません。
たとえば、Dept 列と Site 列が検索可能であって、Name 列は検索可能ではないテーブルに対して nistbladm を実行すると、次の 2 つの行は同一であるとみなされます。
Dept (検索可能) |
Site (検索可能) |
Name (検索不可) |
---|---|---|
Sales |
Vancouver |
Hosteen |
Sales |
Vancouver |
Lincoln |
この場合、nistbladm -a を実行して Sales Vancouver Lincoln という行を作成できません。
しかし、複数の検索可能列のどちらか一方の値が重複するだけであれば、nistbladm -a を実行して新しい行を作成できます。たとえば、以下の 2 つのコマンドを実行すると、一部の値が異なるだけの 2 つの列を作成できます。
rootmaster% nistbladm -a Dept='Sales' ¥ Site='Vancouver' Name='hosteen' staff.doc.com. rootmaster% nistbladm -a Dept='Sales' ¥ Site='SanFran' Name='lincoln' staff.doc.com. |
これらのコマンドを実行すると、検索可能列の一部が同じで、すべてが同じではない 2 つの行が作成されます。
Dept |
Site |
Name |
---|---|---|
Sales |
Vancouver |
hosteen |
Sales |
SanFran |
lincoln |
-A オプションは、nistbladm コマンドで既存のエントリを上書きするアプリケーションに使用します。-a と同様に、-A もテーブルにエントリを追加するためのオプションです。しかし、追加するエントリがすでに存在する場合、エラーを返して終了するのではなく、既存のエントリを上書きします。
-A オプションを指定する場合、エントリ内のすべての列の値を指定する必要があります。
ここで、Dept 列と Site 列が検索可能である次のテーブルを想定します。
Dept (検索可能) |
Site (検索可能) |
Name |
---|---|---|
Sales |
SanFran |
Lincoln |
このテーブルに対して、次のコマンドを実行します。
rootmaster% nistbladm -A Name=Sales Site=SanFran ¥ Name=Tsosulu depts.doc.com. |
Name=Sales Site=SanFran はすでに存在するので、オプションが -a であれば、上記のコマンドはエラーを返します。しかし、上記のコマンドでは -A が指定されているので、既存の行が上書きされます。
Dept |
Site |
Name |
---|---|---|
Sales |
SanFran |
Tsosulu |
既存のエントリを修正 (編集) する場合は、-e オプションまたは -E オプションを指定します。Solaris 8 リリースでは、旧リリースとの互換性を維持するため、-m オプションも残されています。新しいアプリケーションまたはコマンド行での操作には、-e オプションまたは -E オプションを使うことをお勧めします。
テーブル内の既存のエントリ (行) を編集するには、nistbladm コマンドに -e オプションまたは -E オプションを指定し、それに続けて、値を変更した column=value のペア (1 つまたは複数) とテーブル内の特定の行を示すインデックス名を指定します (「nistbladm とインデックス名」を参照)。
nistbladm [-e | -E] column=" value" ¥ column=" value" ¥ ... indexedname |
-e オプションまたは -E オプションを指定して既存エントリ (行) を修正する場合は、次の点に注意してください。
value は必ず引用符で囲む。たとえば、cname 列の値を deneb に変更する場合は、column=value ペアを cname="deneb" と指定する
検索可能列の値は、1 行 (エントリ) 単位でしか変更できない
エントリ (行) の列を空白にする場合は、column=" " と指定する。つまり、value には、引用符で囲んだ半角スペースを指定する
-e オプションを指定した場合、複数のエントリの検索可能列値を変更することになる nistbladm コマンドは実行されず、エラーが返されます。このとき、検索不可列の値は考慮されません。
nistbladm column=" value" ¥ column=" value" ¥ ... indexedname |
-e オプションを指定した場合、変更する列の値を指定するだけです。
ここで次のテーブルについて考えます。
Dept |
Site |
Name |
---|---|---|
Sales |
SanFran |
Tsosulu |
Name 列の値を Chandar に変更するには、次のように入力します。
master% nistbladm -e Name="Chandar" [Dept='Sales',Site='SanFran'], ¥ depts.doc.com. |
修正後のテーブルは次のようになります。
Dept |
Site |
Name |
---|---|---|
Sales |
SanFran |
Chandar |
(上記の例では、インデックス名に Name 列が含まれていません。これは、Name 列が検索可能ではないためです。)
C シェルを使っている場合は、角カッコを含む数式を引用符でオフセットすることもできます。
-e オプションを指定して検索可能列の値を編集するには、新たに指定した値が (インデックス名によって識別される) 1 行にだけ適用されることが条件になります。したがって、Dept 列の値を Manf に変更するには、次のように入力します。
master% nistbladm -e Dept="Manf" [Dept='Sales',Site='SanFran'], ¥ depts.doc.com. |
Dept (検索可能) |
Site (検索可能) |
Name |
---|---|---|
Manf |
SanFran |
Chandar |
しかし、検索可能列に Manf と SanFran という値を持つエントリが既に存在する場合は、nistbladm -e はエラーを返します。
同一のエントリが対象である場合は、複数の列の変更を指定できます。たとえば、Dept 列と Name 列の値を変更するには、次のように入力します。
master% nistbladm -e Dept="Manf" Name="Thi" ¥ [Dept='Sales',Site='SanFran'],depts.doc.com. |
Dept (検索可能) |
Site (検索可能) |
Name |
---|---|---|
Manf |
SanFran |
Thi |
-E オプションは、nistbladm コマンドで既存のエントリを上書きする場合のアプリケーションに使用します。
ここで次のテーブルを想定します。
Dept (検索可能) |
Site (検索可能) |
Name |
---|---|---|
Sales |
SanFran |
Chandar |
Sales |
Alameda |
Achmed |
このテーブルに対して次のコマンドを実行します。
master% nistbladm -E Site="Alameda" Mgr="Chu" ¥ [Div='Sales',Site='SanFran'],depts.doc.com. |
すると、Sales SanFran Chandar 行が Sales Alameda Chu に変わります。しかも、キーの値 Sales Alameda によって識別される Sales Alameda Achmed 行までもが変更の対象になります。その結果、コマンド実行前には 2 つあったはずの行が 1 つになります。
Dept (検索可能) |
Site (検索可能) |
Name |
---|---|---|
Sales |
Alameda |
Chu |
これは複数の行を編集することになるので、オプションが -e であれば、上記のコマンドはエラーを返します。しかし、実際には -E が指定されているので、複数のエントリ (行) が編集されます。
テーブルから 1 つのエントリを削除する場合は、-r オプションを指定します (「1 つのエントリを削除する」を参照)。
テーブルから複数のエントリを削除する場合は、-R オプションを指定します (「複数のエントリを削除する」を参照)。
テーブルから 1 つのエントリを削除するには、次に示すように -r オプションを指定します。
nistbladm -r indexed-name |
次に示すコマンドでは、depts テーブルから Manf-1 エントリを削除します。
rootmaster% nistbladm -r [Dept=Manf-1,Site=Emeryville,Name=hosteen], ¥ depts.doc.com. |
指定する列の値の数は最小限に減らすことができます。NIS+ では、列の値の重複が見つかると、行は 1 つも削除されることなく、エラーが返されます。次のテーブルから Manf-1 エントリを削除するには、次に示すように Site 列の値を指定するだけで済みます。
rootmaster% nistbladm -r [Site=Emeryville],depts.doc.com. |
しかし、R&D エントリも Sales エントリと同じ値を持っているため、Site 列の値 (SanFran) を指定するだけでは Sales エントリを削除できません。
Dept |
Site |
Name |
---|---|---|
R&D |
SanFran |
kuznetsov |
Sales |
SanFran |
jhill |
Manf-1 |
Emeryville |
hosteen |
Manf-2 |
Sausalito |
lincoln |
テーブルから複数のエントリを削除するには、次に示すように -R オプションを指定します。
nistbladm -R indexedname |
オプションが -r であれば、最小限必要な列値を指定するだけで済みます。しかし、上記のコマンドでは -R が指定されているので、NIS+ が重複を見つけると、それに該当するすべてのエントリが削除されます。テーブル内の列の名前を確認したい場合は、niscat -o コマンドを実行します。次のコマンドを実行すると、Site 列の値が SanFran であるすべてのエントリが削除されます。
rootmaster% nistbladm -R [Site=SanFran],depts.doc.com. |
Dept |
Site |
Name |
---|---|---|
Manf-1 |
Emeryville |
hosteen |
Manf-2 |
Sausalito |
lincoln |
-R オプションを指定すると、次に示すように、列の値を指定しなければテーブル内のすべてのエントリを削除できます。
rootmaster% nistbladm -R [],depts.doc.com. |
nistbladm -R コマンドと共に使用すると、一対の空の角カッコはすべてのテーブル列を指定するワイルドカードとして解釈されます。
niscat コマンドは NIS+ テーブルの内容を表示します。このコマンドを使って、テーブルのオブジェクト属性を表示できます。表示するテーブル、エントリ、または列に対する読み取り権が必要です。
テーブルの内容を表示するには、以下のように入力します。
niscat [-hM] tablename |
テーブルのオブジェクト属性を表示するには、以下のように入力します。
niscat -o tablename niscat -o entry |
オプション |
目的 |
---|---|
-h |
ヘッダー。テーブルエントリの上にあるヘッダー行を表示し、各列の名前を表示する |
-M |
マスター。マスターサーバーに収められているテーブルのエントリだけを表示する。これによって最新情報を取得できる。デバッグにだけ使用する |
-o |
オブジェクト。列名、属性、サーバーなどの、テーブルについてのオブジェクト情報を表示する |
テーブルの内容を表示するには、niscat にテーブル名を付けて実行します。
niscat tablename |
次の例では、depts というテーブルの内容を表示します。
rootmaster% niscat -h depts.doc.com. # Name:Site:Name R&D:SanFran:kuznetsov Sales:SanFran:jhill Manf-1:Emeryville:hosteen Manf-2:Sausalito:lincoln |
*NP* は、ユーザーにそのエントリを表示するためのアクセス権がないことを示します。アクセス権は、テーブル、列、エントリ (行) ごとに与えられます。アクセス権の詳細は、第 10 章「NIS+ のアクセス権の管理」を参照してください。
テーブルのオブジェクト属性を表示するには、niscat -o にテーブル名を付けて実行します。
niscat -o tablename.org_dir |
テーブルエントリのオブジェクト属性を表示するには、niscat -o を使い、インデックス付きの名前でエントリを指定します。
entry ::=column=value ... tablename | ¥ [column=valu ,...], tablename |
次に、テーブルの例とテーブルエントリの例を示します。
「テーブル」
rootmaster# niscat -o hosts.org_dir.doc.com. Object Name : hosts Owner : rootmaster.doc.com. Group : admin.doc.com. Domain : org_dir.doc.com. Access Rights : ----rmcdr---r--- Time to Live : 12:0:0 Object Type : TABLE Table Type : hosts_tbl Number of Columns : 4 Character Separator : Search Path : Columns : [0] Name : cname Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INS Access Rights: ---------------- [1] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INS Access Rights: ---------------- [2] Name : addr Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INS Access Rights: ---------------- [3] Name : comment Attributes : (TEXTUAL DATA) Access Rights: ---------------- |
「テーブルエントリ」
rootmaster# niscat -o [name=rootmaster],hosts.org_dir.doc.com. Object Name : hosts Owner : rootmaster.doc.com. Group : admin.doc.com. Domain : org_dir.doc.com. Access Rights : ----rmcdr---r--- Time to Live : 12:0:0 Object Type : ENTRY Entry data of type hosts_tbl Entry has 4 columns. . # |
nismatch コマンドと nisgrep コマンドは、NIS+ テーブルを検索して、それぞれ特定の文字列または正規表現に一致するエントリを探します。これらのコマンドは、エントリ自体、またはエントリの検索できた回数のどちらかを表示します。nismatch コマンドと nisgrep コマンドの相違を表 14-6 に示します。
表 14-6 nismatch と nisgrep の 比較
機能 |
nismatch |
nisgrep |
---|---|---|
検索指定 |
テキストのみ指定可能 |
正規表現が指定可能 |
速度 |
高速 |
低速 |
検索対象 |
検索可能列のみ |
すべての列 (検索可能かどうかとは無関係) |
検索構文 |
column=string ... tablename[ column= string,...], tablename |
column=exp ... tablename |
この節の例では、両方のコマンドの構文を説明します。
どちらのコマンドを使用する場合にも、検索するテーブルに対する読み取りアクセス権が必要です。
この節の例は、次に示す depts.doc.com. というテーブルの値をベースにしています。最初の 2 つの列だけが検索可能です。
Name (S) |
Site (S) |
Name |
---|---|---|
R&D |
SanFran |
kuznetsov |
Sales |
SanFran |
jhill |
Manf-1 |
Emeryville |
hosteen |
Manf-2 |
Sausalito |
lincoln |
Shipping-1 |
Emeryville |
tsosulu |
Shipping-2 |
Sausalito |
katabami |
Service |
Sparks |
franklin |
正規表現により、テキストと記号を組み合わせて使用し、特定の構成の列の値を検索できます。たとえば、正規表現 `Hello' は、Hello で始まる値を検索します。正規表現をコマンド行で使用するときは、必ず引用符で囲んでください。その理由は、正規表現記号の多くが Bourne シェルと C シェルでは特殊な意味をもつからです。たとえば、次のように入力します。
rootmaster% nisgrep -h greeting='Hello' phrases.doc.com. |
正規表現の記号を表 14-7 にまとめます。
表 14-7 正規表現記号
記号 |
意味 |
---|---|
^string |
string で始まる値を見つける |
string $ |
string で終わる値を見つける |
. |
ピリオドの数と等しい数の文字をもつ値を見つける |
[chars] |
角かっこ内の文字のどれかを含む値を見つける |
*expr |
expr についてゼロ回以上一致する値を見つける |
+ |
1 回以上現われるものを見つける |
? |
任意の値を見つける |
¥'s-char' |
? や $ などの特殊文字を見つける |
x | y |
x または y の値を見つける |
最初の列を検索するには、以下のように入力します。
nismatch string tablename nisgrep reg-exp tablename |
特定の列を検索するには、以下のように入力します。
nismatch column=string tablename nisgrep column= reg-exp tablename |
複数の列を検索するには、以下のように入力します。
nismatch column=string tablename ...¥ nismatch [column=string,...], tablename nisgrep column= reg-exp ... ¥ tablename |
オプション |
目的 |
---|---|
-c |
カウント。エントリ自体ではなく、検索指定に一致したエントリのカウントを表示する |
-h |
ヘッダー。エントリの上のヘッダー行を表示し、各列名を表示する |
-M |
マスター。マスターサーバーに収められているテーブルのエントリだけを表示する。これによって、最新情報を取得できる。デバッグにだけ使うようにする |
テーブルの最初の列で特定の値を検索するには、最初の列の値と「tablename」を入力します。nismatch では、この値は文字列でなければなりません。nisgrep では、この値は正規表現でなければなりません。
nismatch [-h] string tablename nisgrep [-h] reg-expression tablename |
次の例では、depts テーブルを検索して、最初の列の値が R&D となっているすべてのエントリを探します。
rootmaster% nismatch -h `R&D' depts.doc.com. rootmaster% nisgrep -h `R&D' depts.doc.com. |
& がシェルによってメタキャラクタとして解釈されないように、R&D が引用符で囲まれています。
最初の列以外の特定の列を検索するには、次の構文を使います。
nismatch column=string tablename nisgrep column=reg- expression tablename |
次の例では、depts テーブルを検索して、第 2 列の値が SanFran となっているすべてのエントリを探します。
rootmaster% nismatch -h Site=SanFran depts.doc.com. rootmaster% nisgrep -h Site=SanFran depts.doc.com. |
2 つ以上の列で一致するエントリを検索するには、次の構文を使います。
nismatch [-h] [column= string, ... ¥ column= string,...], tablename nisgrep [-h] column=reg-exp ... ¥ tablename |
以下の例では、第 2 列の値が SanFran で、第 3 列の値が jhill のエントリを検索します。
rootmaster% nismatch -h [Site=SanFran,Name=jhill], depts.doc.com. rootmaster% nisgrep -h Site=SanFran Name=jhill depts.doc.com. |
nisln コマンドは、NIS+ オブジェクトとテーブルエントリの間でシンボリックリンクを作成します。すべての NIS+ 管理コマンドで、NIS+ オブジェクト間のリンクをたどるように指示する -L フラグを使用できます。
あるテーブルから他のテーブルへのリンクはできますが、あるテーブルのエントリから他のテーブルのエントリへのリンクはできません。
他のオブジェクトまたはエントリへのリンクを作成するには、ソースオブジェクトまたはエントリ、つまり他のオブジェクトまたはエントリを指すものに対する変更権が必要です。
cred テーブルをリンクしないでください。org_dir ディレクトリには、それぞれ専用の cred テーブルが必要です。org_dir cred テーブルもリンクしないでください。
リンクを作成するには次のように入力します。
nisln source target |
オプション |
目的 |
---|---|
-L |
リンクをたどる。ソース (source) 自体がリンクである場合、新しいリンクはこれにはリンクされず、そのリンク元のソースにリンクされる |
-D |
デフォルト。リンクされたオブジェクトに対して別のデフォルトセットを指定する。デフォルトについては、「デフォルトを無効にする」を参照 |
オブジェクト間のリンク (テーブルとディレクトリの間のリンクなど) を作成するには、最初に「ソース (source)」、次に「リンク先 (target)」の順で、両方のオブジェクト名を指定します。
nisln source-object target-object |
nissetup コマンドは、org_dir ディレクトリと groups_dir ディレクトリ、それにフルセットの NIS+ テーブルを作成することによって、既存の NIS+ ディレクトリオブジェクトをドメインに展開します。しかし、データでテーブルを生成することはありません。これを行うには、「nisaddent コマンド」で説明する nisaddent コマンドが必要です。ドメインにディレクトリを展開することは、ドメインの設定作業の一部です。前提条件および必要な動作の詳細は、パート II「NIS+ の紹介と概要」を参照してください。
新しい NIS+ ドメインを設定するのであれば、nissetup コマンドを使うより、nisserver スクリプトを使った方が簡単です。nisserver スクリプトの具体的な使い方については、『Solaris ネーミングの設定と構成』を参照してください。
nissetup コマンドは、NIS クライアントをサポートするドメインにもディレクトリを展開できます。
nissetup を使用するには、テーブルを格納するディレクトリに対する変更権が必要です。
nissetup コマンドは、ディレクトリ名を付けても付けなくても使えます。ディレクトリ名を付けない場合、このコマンドはデフォルトのディレクトリを使います。追加される各オブジェクトは、出力に表示されます。
rootmaster# /usr/lib/nis/nissetup doc.com. org_dir.doc.com. created groups_dir.doc.com. created a uto_master.org_dir.doc.com. created auto_home.org_dir.doc.com. created bootparams.org_dir.doc.com. created cred.org_dir.doc.com. created ethers.org_dir.doc.com. created group.org_dir.doc.com. created hosts.org_dir.doc.com. created mail_aliases.org_dir.doc.com. created sendmailvars.org_dir.doc.com. created netmasks.org_dir.doc.com. created netgroup.org_dir.doc.com. created networks.org_dir.doc.com. created passwd.org_dir.doc.com. created protocols.org_dir.doc.com. created rpc.org_dir.doc.com. created services.org_dir.doc.com. created timezone.org_dir.doc.com. created |
NIS+ と NIS のクライアント要求をサポートするドメインにディレクトリを展開するには、-Y フラグを使います。作成するテーブルは、NIS のクライアント要求がアクセスできるように、未認証カテゴリに対する読み取り権が与えられます。
rootmaster# /usr/lib/nis/nissetup -Y Test.doc.com. |
nisaddent コマンドは、テキストファイルまたは NIS マップからの情報を NIS+ テーブルにロードします。また、NIS+ テーブルの内容をテキストファイルに逆にダンプできます。NIS+ テーブルを初めて生成 (populate) する場合、『Solaris ネーミングの設定と構成』を参照してください。すべての前提条件と関連作業が説明してあります。
nisaddent を使用して、情報をある NIS+ テーブルから別のテーブルに (たとえば、別のドメインの同じ種類のテーブルに) 転送できますが、直接には転送できません。まず、テーブルの内容をファイルにダンプし、次にそのファイルを他のテーブルにロードする必要があります。ただし、ファイル内の情報は正しくフォーマットされていなければなりません。各テーブルに必要なフォーマットを付録 C 「NIS+ テーブルの情報」 で説明します。
情報をテーブルにロードするとき、置換 (replace)、追加 (append)、またはマージ (merge) の 3 つのオプションを自由に使用できます。追加オプションは、ソースエントリを NIS+ テーブルに単純に追加します。置換オプションの場合、NIS+ は、まずテーブル内のすべての既存エントリを削除し、次にソースからエントリを追加します。大規模なテーブルでは、これによって多くのエントリセット (1 セットは既存エントリの削除用、他のセットは新エントリの追加用) がテーブルの .log ファイルに追加され、/var/nis 内の領域を占有し、複製への伝達に長時間を要することになります。
マージオプションでは、置換オプションと同じ結果が得られますが、異なるプロセスを使っており、複製に送信する動作数が大幅に減少します。マージオプションの場合、NIS+ は 3 種類のエントリを別に処理します。
ソース内にだけ存在するエントリは、テーブルに「追加」される
ソースとテーブルの両方に存在するエントリは、テーブル内で「更新」される
NIS+ テーブルにだけ存在するエントリは、テーブルから「削除」される
大きなテーブルを更新する場合で、内容の変更があまりないときは、マージオプションを使用するとサーバーは多くの動作を節約できます。ソース内で重複していないエントリだけを削除する (置換オプションは全エントリを無差別に削除する) ため、重複エントリごとに 1 回の削除と 1 回の追加動作を省略できます。
初めてテーブルに情報をロードする場合、テーブルオブジェクトに対する作成権が必要です。テーブル内の既存情報を上書きする場合、テーブルに対する変更権が必要です。
テキストファイルから情報をロードするには、以下のように入力します。
/usr/lib/nis/nisaddent -f filename table-type [domain] /usr/lib/nis/nisaddent -f filename -t tablename table-type [domain] |
NIS マップから情報をロードするには、以下のように入力します。
/usr/lib/nis/nisaddent -y NISdomain table-type [domain] /usr/lib/nis/nisaddent -y NISdomain -t tablename table-type [domain] /usr/lib/nis/nisaddent -Y map table-type [domain] /usr/lib/nis/nisaddent -Y map -t tablename table-type [domain] |
NIS+ テーブルから情報をファイルにダンプするには、以下のように入力します。
/usr/lib/nis/nisaddent -d [-t tablename tabletype ] > filename |
ファイルの内容を NIS+ テーブルに転送するには、いくつかの方法があります。
-f を単独で指定すると、table-type の内容が filename の内容に置き換えられます。
nisaddent -f filename table-type |
-f と -a を同時に指定すると、filename の内容が table-type に「追加」されます。
nisaddent -a -f filename table-type |
-f と -m を同時に指定すると、filename の内容が table-type の内容に「マージ」されます。
nisaddent -m -f filename table-type |
次に示す 2 つの例では、テキストファイル /etc/passwd.xfr の内容が NIS+ passwd テーブルにロードされます。最初の例ではローカルドメインに、2 番目の例では別のドメインのテーブルにロードされます。
rootmaster# /usr/lib/nis/nisaddent -f /etc/passwd.xfr passwd rootmaster# /usr/lib/nis/nisaddent -f /etc/shadow.xfr shadow rootmaster# /usr/lib/nis/nisaddent -f /etc/passwd.xfr passwd sales.doc.com. rootmaster# /usr/lib/nis/nisaddent -f /etc/shadow.xfr shadow sales.doc.com. |
/etc ディレクトリのファイルから NIS+ passwd テーブルを作成する場合は、nisaddent を 2 回 (/etc/passwd ファイルと /etc/shadow ファイルに対して 1 回ずつ) 実行する必要があります。
もう 1 つの方法では、stdin をソースとして使います。しかし、stdin では -m オプションを使えません。次に例を示します。リダイレクト (>) やパイプ (|) を使用することは可能です。ただし、別のドメインに出力が行われるような形でパイプを使用することはできません。
作業 |
コマンド |
---|---|
リダイレクト |
cat filename > nisaddent table-type |
リダイレクト処理後、追加する |
cat filename > nisaddent -a table-type |
リダイレクト処理後、別のドメインに追加する |
cat filename > nisaddent -a table-type NIS+ domain |
パイプ |
cat filename | nisaddent table-type |
パイプ処理後、追加する |
cat filename | nisaddent -a table-type |
NIS+ テーブルが、オートマウンタテーブルの 1 つであるか標準以外のテーブルである場合、-t オプションと NIS+ テーブルの完全な名前を追加します。
master# nisaddent -f /etc/auto_home.xfr ¥ -t auto_home.org_dir.doc.com.key-value master# nisaddent -f /etc/auto_home.xfr ¥ -t auto_home.org_dir.doc.com. key-value sales.doc.com. |
NIS マップから情報を転送する方法は 2 つあり、NIS ドメインを指定するか、または実際の NIS マップを指定します。ドメインを指定した場合、NIS+ は、table-type に基づいて、/var/yp/nisdomain 内のどのマップファイルをソースとして使うかを判断します。/var/yp/nisdomain は「ローカル」ファイルでなければなりません。
NIS+ テーブル形式 |
NIS マップ名 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NIS ドメインの指定によって転送するには、-y (小文字) オプションを使い、NIS+ テーブル形式に加えて NIS ドメインを指定します。
「テーブルの置換」
nisaddent -y nisdomain table-type |
「テーブルの追加」
nisaddent -a -y nisdomain table-type |
「テーブルのマージ」
nisaddent -m -y nisdomain table-type |
デフォルトでは、nisaddent は NIS+ テーブルの内容を NIS マップの内容に置き換えます。追加またはマージを行うには、-a または -m のオプションを使います。次の例では、対応する NIS マップ (passwd.byname
) からの NIS+ passwd テーブルを old-doc ドメインにロードします。
rootmaster# /usr/lib/nis/nisaddent -y old-doc passwd |
2 番目の例でも同じことを行いますが、ローカルドメイン doc.com. の代わりに、sales.doc.com. ドメインに対して行います。
rootmaster# /usr/lib/nis/nisaddent -y old-doc passwd sales.doc.com. |
NIS+ テーブルが、オートマウンタテーブルの 1 つであるか非標準テーブルである場合、そのソースがファイルであるかのように、-t オプションと NIS テーブルの完全な名前を追加します。
rootmaster# nisaddent -y old-doc ¥ -t auto_home.org_dir.doc.com. key-value rootmaster# nisaddent -y old-doc ¥ -t auto_home.org_dir.doc.com. key-value sales.doc.com. |
マップファイルをドメイン用に使うのではなく、特定の NIS マップを指定したい場合、-Y (大文字) オプションを使い、マップ名を指定します。オプションを見つけやすいように、次の例では太字にしています。
rootmaster# nisaddent -Y hosts.byname hosts rootmaster# nisaddent -Y hosts.byname hosts sales.doc.com. |
NIS マップがオートマウンタマップの 1 つであるか非標準マップである場合、-Y オプションと -t オプションを組み合わせます。
rootmaster# nisaddent -Y auto_home ¥ -t auto_home.org_dir.doc.com. key-value rootmaster# nisaddent -Y auto_home ¥ -t auto_home.org_dir.doc.com. key-value sales.doc.com. |
NIS+ テーブルの内容をファイルにダンプするには、-d と -t のオプションを使います。-d オプションは、ダンプするようコマンドに指示します。-t オプションは、NIS+ テーブルを指定します。
rootmaster# nisaddent -Y auto_home¥ -t auto_home.org_dir.doc.com. key-value rootmaster# nisaddent -Y auto_home ¥ -t auto_home.org_dir.doc.com. key-value sales.doc.com. |
この章では、NIS+ クライアントが使用するサーバーのカスタマイズおよび制御方法について説明します。
クライアントマシン、ユーザー、アプリケーション、あるいはプロセスは、アクティブな NIS+ サーバー (マスターまたは複製) を検索して、そこから必要な情報を取り込みます。巨大なネットワーク、サブネットを多く持ったネットワーク、あるいは広域リンクにまたがったネットワークでは、サーバーの使用法をカスタマイズすることにより NIS+ の性能を強化できます。
カスタマイズ前の状態で、nisprefadm コマンドによるサーバーの優先順位設定がなにも設定されていなければ、クライアントは、まず自分自身のローカルサブネット上の NIS+ サーバーから情報を入手しようとします。そのサブネットにアクティブなサーバーが見つかれば、応答のあった最初のローカルサーバーから必要な情報を入手します。ローカルサブネットにサーバーがない場合、次にクライアントは、ローカルサブネットの外部を検索し、応答のあった最初の遠隔サーバーから必要な NIS+ 情報を入手します。
ネットワークが大規模で、混雑している場合、上記のデフォルトの検索動作では NIS+ の性能を十分に発揮させることができないことがあります。それは次のような理由によります。
サブネット上の複数のサーバーが多数のクライアントに情報の配布を行なっている場合、クライアントのデフォルト検索パターンがランダムなために、他にあまり使われていないサーバーがあるのに、いくつかのサーバーの負荷が高くなりすぎる可能性があります。
ローカルサブネットの外で NIS+ サーバーを検索する際、クライアントは、オーバーワークしているサーバーであっても、低速な広域ネットワーク接続方式 (たとえば、モデム) や、すでにトラフィック多い専用回線によってリンクされているサーバーであっても、最初に応答したものから情報を入手します。
Solaris 8 リリースには、新規機能 (サーバーの使用のカスタマイズ) が搭載されています。この機能を使用すると、クライアントが NIS+ サーバーを検索する順序をコントロールできます。この新規機能では、次のような方法でサーバーの使用の度合いをバランスよくカスタマイズできます。
クライアントが特定のサーバーを優先的に選択する (検索する) ように指定します。
使用できるローカルサーバーがない場合、クライアントが遠隔サーバーを使用してもよいかどうかを指定します。
指定した検索基準は、ドメイン内のすべてのクライアント、サブネット上のすべてのクライアント、またはマシンごとに独立したクライアントに適用できます。
サーバー使用の優先順位を特定のマシンに設定すると、この優先順位は、そのマシンで実行中のユーザー、アプリケーション、処理、または他のクライアントすべてに適用されます。同じマシン上の別のクライアントに、異なるサーバー使用のパターンを設定できません。
使用サーバーのカスタマイズは、多数のサブネットを持つ大規模ネットワークや、モデムまたは専用回線で接続された複数の地理的サイトにまたがるネットワークで使用すると特に効果があります。ネットワークの性能を最大にするには、サブネット間やより低速な接続によってリンクされたサイト間のトラフィックを最小限にする必要があります。これは、クライアントが使用できる NIS+ サーバーとその優先順位を指定することによって実現できます。このようにして、可能な限り NIS+ ネットワークトラフィックがローカルサブネットから出ないようにします。
この節では、サーバー使用のカスタマイズの概要について説明します。
使用サーバーをカスタマイズするには、クライアントで nis_cachemgr を実行している必要があります。クライアントマシンが nis_cachemgr を実行していない場合は、使用サーバーのカスタマイズ機能は利用できません。クライアントマシン上で、nis_cachemgr を実行していない場合は、そのクライアントは、「デフォルトでのクライアントの検索動作」で説明した方法で識別された最初のサーバーを使用します。
nisprefadm コマンドは、次のように、その使用方法により、ローカルの client_info ファイルまたはドメインの client_info テーブルのどちらかを作成します。
「ファイル」
nisprefadm を使用して、マシンの /var/nis ディレクトリに格納される、ローカルなマシン固有の client_info を作成できます。ローカルファイルは、サーバーの優先順位をそのマシンだけに指定するためのものです。マシンに、ローカルの /var/nis/client_info ファイルがある場合、そのマシンは、ドメインの client_info.org_dir テーブルに入っているサーバーの優先順位は無視します。ローカル client_info ファイルを作成するには、-L オプションを指定した nisprefadm を実行してください。
「テーブル」
nisprefadm を使用して、各ドメインの NIS+ ディレクトリオブジェクト org_dir 内に格納される NIS+ client_info テーブルを作成できます。このテーブルは、次のものに対してサーバーの優先順位を指定できます。
個別のマシン
マシンにローカルの /var/nis/client_info ファイルがある場合、ドメインの client_info テーブルによって、そのマシンに対して指定された優先順位はすべて無視されます。
1 つの特定のサブネット上にあるすべてのマシン
サブネット上のマシンにローカルの /var/nis/client_info ファイルがあるか、またはテーブル内にそのマシン固有の優先順位が設定されている場合、そのマシンは、サブネットに指定された優先順位を無視します。
1 つのサブネット上のすべてのマシンに適用されるグローバル client_info テーブルを作成するには、-G および -C オプションを指定して nisprefadm を実行してください。これについては、「グローバルサーバー優先順位を指定する」で説明しています。
マシンに、以下で説明するような、固有のローカル client_info ファイルがある場合、そのマシンに対してグローバル client_info テーブル内に設定されたサーバーの優先順位はすべて無視されるので注意してください。マシンに、ローカル client_info ファイルがあるか、またはグローバル client_info テーブルにそのマシン固有のエントリがある場合は、そのサブネットに設定された優先順位は無視されます。
client_info ファイルと client_info テーブルを変更する場合は、nistbladm コマンドだけを使用してください。nistbladm などの、他の NIS+ コマンドは絶対に使用しないでください。
client_info テーブルまたは client_info ファイルを処理する場合は、-G または -L オプションを使用して、グローバルテーブル (-G) またはコマンドを実行中のマシンのローカルファイル (-L) のどちらにそのコマンドを適用させるかを指定する必要があります。
サーバーの優先順位は、各サーバーに「優先順位を表す番号」を指定することによって制御されます。クライアントは、数値で指定された優先順位にしたがって NIS+ サーバーを検索します。検索の順序は、まず、優先順位格付け番号が小さいサーバーを先に検索し、次に大きい数値の付いたサーバーを検索します。
つまり、クライアントは、まず初めにゼロの優先順位の付いた NIS+ サーバーから名前空間情報を入手しようとします。使用できる優先順位=0 のサーバーがない場合、クライアントは、次に優先順位=1 のサーバーに問い合わせを行います。1 のサーバーが使用できない場合は、2 のサーバーを検出しようと、次に 3 というように、この検索は必要な情報が入手できるか、または検索するサーバーがなくなるまで続きます。
優先順位格付け番号は、nisprefadm コマンドを使用してサーバーに割り当てます。これについては、「グローバルサーバー優先順位を指定する」で説明しています。
サーバーの優先順位番号は、client_info テーブルと client_info ファイル内に格納されます。マシンに、固有の /var/nis/client_info ファイルがある場合は、このファイル内に格納された優先順位番号が使用されます。マシンに、固有の client_info ファイルがない場合は、ドメインの client_info.org_dir テーブル内に格納された優先順位番号が使用されます。このような client_info テーブルと client_info ファイルを、「優先サーバーのリスト」、または単に「サーバーリスト」と呼びます。
各クライアントのサーバーの優先順位を制御することで、サーバーの使用法をカスタマイズします。たとえば、ドメインに mailer という名前のクライアントマシンがあり、このマシンは名前空間情報を頻繁に利用していて、さらにこのドメインには、マスターサーバー (nismaster) と複製サーバー (replica1) の両方があるとします。ここで、mailer マシン用に nismaster に優先順位番号 1 を割り当て、replica1 に優先順位番号 0 を割り当てると、mailer マシンは、名前空間情報を、必ず最初に replica1 から入手しようとし、その後で nismaster に移ります。次に、このサブネット上にある他のすべてのマシンに対して、優先順位番号を nismaster サーバーにはゼロを、replica1 には 1 を割り当てます。この結果、他のマシンは、必ず最初に nismaster に問い合わせを行います。
同じ優先順位番号を、ドメイン内の複数のサーバーに割り当てることができます。たとえば、nismaster1 と replica2 の両方に優先順位番号 0 を割り当て、replica3、replica4、replica5 に優先順位番号 1 を割り当てることができます。
client_info ファイルまたはテーブルがない場合は、キャッシュ管理プログラムが自動的に、ローカルサブネット上のすべてのサーバーにデフォルトの優先順位番号ゼロ (0) を割り当て、ローカルサブネットの外部のすべてのサーバーに無限大の優先順位を割り当てます。nisprefadm は、このデフォルトの優先順位番号を自由に変更するためのものです。
クライアントは、すべてのサーバーを指定された優先順位番号を使用して昇順に検索しなければなりません。クライアントが指定された優先順位番号をもつすべてのサーバーを検索するには、5 秒以上必要です。つまり、ドメイン内に 1 つのマスターサーバーと 4 つの複製サーバーがあり、それぞれのサーバーに 0 から 4 の異なる優先順位番号を指定した場合、クライアントがこれらの優先レベルをすべて実行するには、25 秒以上かかるということです。
性能を最大にするために、サーバーの優先レベルを 2 つまたは 3 つ以上使用しないでください。たとえば、上記のような場合は、5 つのサーバーのうちの 1 つに優先順位= 0 を割り当て、他すべてのサーバーには優先順位 1 を割り当てるか、または 5 つのサーバーのうち 2 つに優先順位 1 を、残りの 3 つのサーバーに 2 を割り当てるといった方法をとってください。
サーバーリストには、クライアントが優先サーバーを検出できなかった場合の処置も指定できます。「優先サーバー」とは、優先順位にゼロが指定されたサーバー、または nisprefadm を使用して優先順位番号を割り当てたサーバーです。
デフォルトでは、クライアントは優先サーバーに到達できないと、検索モードを使用して、ネットワーク上のあらゆる場所を検索し、検出できるあらゆるサーバーを検索します。これについては、「デフォルトでのクライアントの検索動作」で説明しています。このデフォルト機能を、nisprefadm -o オプションを使用して変更し、クライアントが優先サーバーだけを使用し、使用できるサーバーがない場合でも、優先サーバー以外のサーバーには問い合わせしないように指定できます。詳細は、「優先サーバー限定指定」を参照してください。
マシンのドメインに優先サーバーが全くない場合、このオプションは無視されます。
現在特定のクライアントマシンに対して有効なサーバーの優先順位を表示するには、-l オプションを指定した nisprefadm を実行してください。これについては、「現行のサーバー優先順位の表示」で説明しています。
サーバーまたはクライアントマシンを指定する場合、次の点に注意してください。
サーバー名とクライアント名は、同じ NIS+ ドメイン内にあり、オブジェクトを個別に特定できれば、完全指定名である必要はありません。マシン名を単独で使用できます。
サーバーまたはサブネットが別の NIS+ ドメインにある場合は、そのマシンを個別に特定できるだけのドメイン名を含める必要があります。たとえば、sales.doc.com ドメイン内にいて、manf.doc.com ドメイン内の nismaster2 マシンを指定する必要がある場合、nismaster2.manf と入力します。
以下のマシンにサーバーの優先順位を指定する方法は、それぞれ次のとおりです。
「個別のクライアントマシン」にサーバーの優先順位を指定するには、-L オプションを使用すると、nisprefadm を実行中のマシンにローカル client_info ファイルを作成します。-G -C マシンオプションを使用すると、グローバル client_info テーブル内にマシン固有の優先順位を作成します。
「サブネット上のすべてのマシン」にサーバーの優先順位を指定するには、-G -C サブネット番号オプションを使用してください。
マシン固有のまたはサブネット固有の優先順位を持たない、現在のドメイン内にあるすべてのマシンにサーバーの優先順位を指定するには、-G オプションを使用してください。
マシンまたはサブネットのサーバー優先順位の変更内容は、通常、指定したマシンがその nis_cachemgr データを更新するまでは有効になりません。マシンの nis_cachemgr がそのサーバー使用情報を更新するタイミングは、マシンがサーバーの優先順位をグローバル client_info テーブルまたはローカル /var/nis/client_info ファイルのどちらから入手するかによって決まります (「グローバルテーブルまたはローカルファイル」を参照してください)。
「グローバルテーブル」から入手する場合
サーバーの優先順位をグローバルテーブルから入手するマシンのキャッシュ管理プログラムは、マシンがブートされた時、または client_info テーブルの存続時間 (TTL) の値が満了した時に、マシン用のサーバーの優先順位を更新します。デフォルトでは、この TTL 値は 12 時間ですが、変更可能です。「オブジェクトの生存期間を変更する」を参照してください。
「ローカルファイル」
ローカルファイルからサーバーの優先順位を入手するマシンのキャッシュ管理プログラムは、サーバーの優先順位を 12 時間ごとに更新するか、または nisprefadm を実行してサーバーの優先順位を変更した時に必ず更新します。マシンをリブートしても、キャッシュ管理プログラムのサーバーの優先順位情報は更新されません。
ただし、nisprefadm に -F オプションを指定して実行すると、サーバーの優先順位の変更内容を強制的にただちに有効にできます。-F オプションを使用すると、nis_cachemgr で、ただちにその情報が更新されます。詳細は、「優先順位の変更内容をただちに実現する方法」を参照してください。
ここからの節では、nisprefadm コマンドを使用して、サーバーの優先順位を設定、変更、削除する方法について説明します。
nisprefadm コマンドは、クライアントが優先的に選択するサーバーを指定するために使用します。
nisprefadm -a|-m|-r|-u|-x|-l -L|-G [-o type] ¥ [-d domain] ¥ [-C machine] ¥ servers nisprefadm -F |
オプション |
説明 |
---|---|
-G |
ドメインの org_dir ディレクトリ内に格納されるグローバル client_info テーブルを作成する。つまり、グローバルな優先されるサーバーリストを作成する。このオプションは、指定したサブネット上のすべてのマシンに対して優先順位を指定する場合は -C subnet、個別のマシンに優先順位を指定する場合は -C machine のどちらかと同時に使用しなければならない |
-L |
ローカルマシンの /var/nis ディレクトリに格納されるローカル client_info ファイルを作成する。つまり、コマンドを実行中のマシンにだけ適用される優先サーバーのリストを作成する |
-o type |
オプションを指定する。有効なオプションには、クライアントが接続できる優先サーバーがない場合、優先サーバー以外のサーバーを使用できるように指定する pref_type=all と、指定した優先サーバーだけをクライアントが使用するように指定する pref_type=pref_only がある |
-d domain |
指定したドメインまたはサブドメインに、グローバルな優先サーバーの client_info テーブルを作成する |
-C subnet |
優先順位を適用するサブネットの番号 |
-C machine |
クライアントマシン名 |
servers |
1 つまたは複数の NIS+ サーバー。ここで指定されたサーバーは優先的に選択される |
-a |
サーバーリストに指定サーバーを追加する |
-m |
サーバーリストを変更する。たとえば、-m オプションを使用すると、1 つまたは複数のサーバーに指定された優先順位番号を変更できる |
-r |
サーバーリストから指定したサーバーを削除する |
-u |
サーバーリストを消去してから、指定したサーバーを追加する (つまり、現行のサーバーリストを優先サーバーの新規リストに置換する) |
-x |
サーバーリストを完全に削除する |
-l |
現行の優先サーバー情報を一覧表示 (表示) する |
-F |
優先サーバーのリストを強制的にただちに変更する |
-C machine オプションは、-L (ローカル) フラグとともに使用しても無効となるので、使用しないでください。たとえば、nisprefadm を altair マシン上で実行しているとします。ここで、-L フラグを使用して、指定した優先順位が altair のローカル client_info ファイルに書き込まれるように指定し、さらに、-C vega オプションを使用して、作成した優先順位が vega マシンに適用されるように指定します。すると、nisprefadm コマンドは、vega 用の優先順位を altair のファイルに書き込みますが、vega は、サーバーの優先順位を必ず自分のローカル client_info ファイルまたはドメインのグローバル client_info テーブルから入手するため、これらの情報を参照することはありません。そのため、-C オプションは、nisprefadm に -G (グローバル) フラグを指定して実行する場合にだけ意味をもちます。
現行のサーバー優先順位を表示するには、nisprefadm に -l
オプションを指定して実行してください。
そのマシン上で、nisprefadm に -L と -l を指定して実行します。
sirius# nisprefadm -L -l |
このようにすると、マシンのローカル /var/nis/client_info ファイル内に定義されたサーバーの優先順位がすべて表示されます。ローカルファイルがない場合は、情報は表示されず、シェルプロンプトに戻ります。
nisprefadm に、-l、-G、-C machinename オプションを指定して実行します。
sirius# nisprefadm -G -l -C machinename |
machinename には、マシンの IP アドレス (番号) が入ります。
このようにすると、このマシン用にドメインのグローバル client_info テーブル内に設定された優先順位が表示されます。
nisprefadm に、-l、-G、-C subnet オプションを指定して実行します。
sirius# nisprefadm -G -l -C subnet |
subnet には、サブネットの IP アドレス (番号) が入ります。
このようにすると、このサブネット用にドメインのグローバル client_info テーブル内に設定された優先順位が表示されます。
デフォルトでは、-a オプションの後ろにリストしたサーバーには、すべて優先順位番号ゼロが指定されます。別の優先順位番号を指定する場合は、次のように、サーバー名の直後に指定する番号をカッコで囲んで入れてください (-a name(n)) 。name にはサーバー名が、n には優先順位番号が入ります。
たとえば、replica2 サーバーに優先順位番号 3 を割り当てる場合は、次のように入力します。
# nisprefadm -G -a replica2(3) |
シェルの中には、次のように要素を 2 重引用符で囲まなければならないものがあります。"name(n)"
サーバーの優先順位格付け番号の基礎知識については、「優先順位の番号の指定」を参照してください。
ローカルまたは遠隔ドメインに、グローバルサーバー優先順位を設定できます。優先順位は、個別のマシンと 1 つのサブネット上のすべてのマシンに設定できます。
この節では、NIS+ ドメインのマスターサーバーに存在するグローバル client_info テーブル内にサーバーの優先順位を設定する方法を説明します。マスターサーバー上にテーブルがある場合、NIS+ は、そのテーブルをドメインの既存の複製サーバー上に複写します。
個別のマシンにローカル client_info ファイルを作成する方法については、「ローカルサーバー優先順位を指定する」 を参照してください。
グローバル client_info テーブルとローカル client_info ファイルの違いについては、「グローバルテーブルまたはローカルファイル」を参照してください。
サーバーの優先順位番号を割り当てるには、次のどちらかを指定した nisprefadm を実行してください。
新規または別の優先サーバーを追加する場合は、-a オプションを指定します。
既存のサーバー優先順位を削除して、新規の優先順位を作成する場合は、-u オプションを指定します。
1 つのサブネット上のすべてのマシンのグローバルテーブルにサーバーの優先順位を割り当てるには、次のようにします。
nisprefadm に -G および -C subnet オプションを指定して実行します。
# nisprefadm -G -a -C subnet servers (preferences) |
-C subnet には、優先順位を適用するサブネットの IP 番号を指定します。使用するシェルによっては、マシンを引用符で囲む必要があります。
servers (preferences) には、1 つまたは複数のサーバーが入ります。それらには優先順位格付け番号を指定できます。
たとえば、サブネット 123.123.123.123 が、nismaster および replica3 サーバーにはデフォルトの優先順位番号ゼロを付け、manf.replica6 サーバーには優先順位番号 1 を付けて使用するように指定する場合は、次のように入力してください。
polaris# nisprefadm -a -G -C 123.123.123.123 nismaster1 ¥ replica3 "manf.replica6(1)" |
# nisprefadm -G -a -C machine servers (preferences) |
-C マシンには、優先順位を適用するマシンを指定します。使用するシェルによっては、machine を引用符で囲む必要があります。
servers (preferences) には、1 つまたは複数のサーバーが入ります。それらには優先順位格付け番号を指定できます。
たとえば、マシン cygnus に指定された現行の優先順位を、replica7 と replica9 の両方にデフォルトの優先順位番号ゼロを指定したものに置き換える場合は、次のように入力します。
polaris# nisprefadm -u -G -C cygnus replica7 replica9 |
遠隔ドメイン内の個別のマシン、または遠隔ドメイン内の 1 つのサブネット上にあるすべてのマシンにサーバーの優先順位を割り当てるには、次のようにします。
nisprefadm に -C、-G、-d オプションを指定して実行します。
# nisprefadm -a -G -C name ¥ -d domain servers (preferences) |
name には、サブネットの IP 番号またはマシン名が入ります。このコマンドを使用して行なった変更は、ここに入力したサブネットまたはマシンに適用されます。
domainname には、遠隔ドメイン名が入ります。
servers (preferences) には、1 つまたは複数のサーバーが入ります。それらには優先順位格付け番号を指定できます。
たとえば、デフォルトの優先順位番号ゼロを指定した nismaster2 サーバーを、遠隔ドメイン sales.doc.com 内のサブネット 111.11.111.11 の優先サーバーのリストに追加する場合は、次のように入力します。
polaris# nisprefadm -a -G -C 111.11.111.11 -d sales.doc.com. nismaster2 |
ここでは、ローカル client_info ファイルの作成および変更方法について説明します。ローカル client_info ファイルは、このファイルが存在するマシンにサーバーの優先順位を指定するためのものです。
マシンに /var/nis/client_info ファイルがある場合、このマシンは、NIS+ サーバー上のグローバル client_info テーブルではなく、そのマシンのローカルファイルからサーバーの優先順位を入手します。つまり、ローカルファイルはグローバルテーブルよりも優先されます。
NIS+ サーバーのグローバル client_info テーブルを作成する方法については、「グローバルサーバー優先順位を指定する」を参照してください。
グローバル client_info テーブルとローカル client_info ファイルの相違点については、「グローバルテーブルまたはローカルファイル」を参照してください。
サーバーの優先順位を割り当てるには、次のどちらかを指定した nisprefadm を実行してください。
新規または別の優先サーバーを追加する場合は、-a オプションを指定します。
既存のサーバー優先順位を削除して、新規の優先順位を作成する場合は、-u オプションを指定します。
nisprefadm コマンドを実行中のローカルマシンにサーバーの優先順位を割り当てるには、次のようにします。
nisprefadm に -L オプションと -a または -u オプションを指定して実行します。
#nisprefadm -a -L servers (preferences) |
ここで、servers (preferences) には、1 つまたは複数のサーバーが入ります。それらには優先順位格付け番号を指定できます。
たとえば、deneb マシンが NIS+ 情報を、まず初めにデフォルトの優先順位番号ゼロが指定された replica3 から検索し、次に manf.doc.com ドメイン内の (優先順位番号 1 が指定された) サーバー replica6 を検索するように指定する場合は、次のように入力します。
deneb# nisprefadm -a -L replica3 replica6.manf(1) |
サーバーの優先順位番号は、変更することができ、また別のサーバーに優先順位番号の割り当てを移すこともできます
優先サーバーまたはサーバーに割り当てた優先順位番号を変更するには、nisprefadm に -m oldserver-=newserver(n) オプションを指定して実行してください。
nisprefadm に -m server=server(new) オプションを指定して実行します。
#nisprefadm -L|-G -C name -m oldserver= newserver(n) |
L|G には、ローカルファイルとグローバルテーブルのどちらを修正するかを指定します。
-C name には、サブネットの IP 番号またはマシン名が入ります。このオプションは、-G オプションを使用している場合にだけ使用します。このコマンドを使用して行なった変更は、ここに指定したサブネットまたはマシンに適用されます。
-m は、サーバーリストを変更するオプションです。
old server には、その優先順位番号を変更したいサーバー名が入ります。
new server(n) には、サーバー名とその新しい優先順位番号が入ります。
たとえば、deneb マシン上で、deneb のローカル client_info ファイルの replica6.manf サーバーに指定された番号を 2 に変更する場合は、次にように入力します。
deneb# nisprefadm -L -m replica6.manf=replica6.manf(2) |
優先順位リスト内で、1 つのサーバーを別のサーバーに変更するには、次のようにします。
nisprefadm に -m oldserver=newserver オプションを指定して実行します。
# nisprefadm -L|-G -C name -m oldserver=newserver ( prefnumber) |
-L|-G には、ローカルまたはドメイン全体のどちらのサーバーリストを変更するのかを指定します。
-C name には、サブネットの IP 番号またはマシン名が入ります。このオプションは、-G オプションを使用している場合にだけ使用します。このコマンドを使用して行なった変更は、ここに指定したサブネットまたはマシンに適用されます。
-m は、サーバーリストを変更するオプションです。
oldserver には、置換する対象となる旧サーバーが入ります。
newserver (prefnumber) には、優先サーバーリスト内の旧サーバーの位置に入る新規サーバー (優先順位格付け番号を指定できる) を入力します。
-G オプションを使用して、グローバル client_info テーブル内のサーバーを置換する場合には、その置換内容は -C オプションで特定したサブネットまたはマシンにだけ適用されるので注意してください。それ以外にリストされている置換対象 (旧) サーバーは影響を受けません。
たとえば、3 つのサブネットを持つドメインを所有していて、この中の 2 つのサブネット用に replica1 サーバーが優先サーバーのリストに入っている場合を考えます。これ以上 replica1 を使用しないので、使用サーバーから除外する場合は、nisprefadm -m を実行して、最初のサブネットの replica1 を新規サーバーに置換します。この時、2 番目のサブネットに対しても同様の処理を行うまでは、replica1 はそのサブネットの優先サーバーのリストに入っています。個別のマシンの優先サーバーでも同様です。
たとえば、ドメインのグローバル client_info テーブル内で、サブネット 123.12.123.12 用に指定された replica3 サーバーを replica6 サーバーに置換し、replica6 に優先順位番号 1 を割り当てる場合は、次のように入力します。
nismaster# nisprefadm -G -C 123.12.123.12 -m replica3 replica6(1) |
優先順位リストから 1 つまたは複数のサーバーを削除するには、次のようにします。
nisprefadm に -r オプションを指定して実行します。
# nisprefadm -L|-G -C name -r servers |
-L|-G には、ローカルまたはドメイン全体のサーバーリストのどちらを変更するのかを指定します。
-C name には、サブネットの IP 番号またはマシン名が入ります。このオプションは、-G オプションを使用している場合にだけ使用します。このコマンドを使用した優先サーバーの削除は、ここに名前を指定したサブネットまたはマシンに適用されます。
-r は、servers に名前を指定したサーバーをリストから削除するオプションです。
たとえば、ドメインのグローバル client_info テーブル内から、マシン polaris に指定された replica3 および replica6.manf サーバーを削除する場合は、次のように入力します。
polaris# nisprefadm -G -C polaris -r replica3 replica6.manf |
グローバル client_info テーブルまたはマシンのローカル client_info ファイルどちらかの中にある、サブネットまたはマシンに指定された優先サーバーのリスト全体を置換するには、nisprefadm に -u オプションを指定して実行してください。
-u オプションは、マシンまたはサブネットに指定されたサーバーの優先順位を、まず初めにすべて削除してから指定した新規の優先順位を追加しますが、これ以外は、-a オプションと同じ処理を行います。既存の優先順位がある場合、-a オプションでは旧リストに新しい優先順位を追加します。
-u オプションの使用例については、「個別のマシンにグローバル優先順位を設定する方法」を参照してください。
優先サーバーが使用できない場合に、クライアントがとる動作を指定できます。
デフォルトでは、クライアントは、優先サーバーに到達できない場合、検出できたサーバーであればどれでも使用してしまいます。優先サーバー限定オプションを設定すると、クライアントが優先サーバーだけを使用するように指定できます。優先サーバー限定オプションと全サーバーオプションの基礎知識については、優先サーバー限定とすべてのサーバーを参照してください。
優先サーバーが使用できない場合のクライアントの動作を指定するには、nisprefadm に -o value オプションを指定して実行してください。
サーバーリストを使用するクライアントが、リスト内に記述されたサーバーだけから NIS+ 情報を入手するように指定するには、次のようにします。
nisprefadm に -o pref_only オプションを指定して実行してください。
# nisprefadm -L|-G -o pref_only |
-L|-G には、ローカルまたはドメイン全体のサーバーリストのどちらを変更するかを指定します。
-o pref_only により、クライアントがリスト内に記述されたサーバーだけから NIS+ 情報を入手するように指定されます。
このオプションは、優先サーバーが全くないドメインでは無視されます。
たとえば、altair のローカル client_info ファイル内に、altair が必ず優先サーバーを使用し、altair の優先サーバーリストにないサーバーは使用しないように指定するには、次のように入力します。
altair# nisprefadm -L -o pref_only |
サーバーリストを使用するクライアントが、優先サーバーが使用できない場合に、リストに記載されていないサーバーから NIS+ 情報を入手するように指定するには、次のようにします。
# nisprefadm -L|-G -o all |
-L|-G には、ローカルまたはドメイン全体のサーバーリストのどちらを変更するかを指定します。
-o all は、クライアントが、優先サーバーが使用できない場合に、リストに記載されていないサーバーから NIS+ 情報を入手するように指定するオプションです。
これは、デフォルトの動作です。そのため、-o all オプションは、以前に -o pref_only オプションを使用して優先サーバーだけを指定していた場合に限り使用する必要があります。
たとえば、altair が優先サーバーを使用できない場合には、altair のローカル client_info ファイル内に、優先サーバー以外のサーバーを使用できるように指定し直すには、次のように入力してください。
altair# nisprefadm -L -o all |
使用サーバーのカスタマイズ機能の使用を終了し、「デフォルトでのクライアントの検索動作」で説明した NIS+ 情報の入手方法に戻すことができます。
サーバーの優先順位の使用を終了するには、nisprefadm に -x オプションを指定して実行してください。
サーバーの優先順位の使用を終了する場合、クライアントは、「サーバーの優先順位が有効になるタイミング」で説明していることがらが通常どおり進行するまではサーバーの優先順位の使用を終了しません。また、サーバーの優先順位の使用を強制的にただちに終了させることもできます。これについては、「サーバーの優先順位の有効化」で説明しています。
nisprefadm に -G および -x オプションを指定して実行してください。
# nisprefadm -G -x |
これにより、グローバルサーバーの優先順位が削除されます。
ローカルサーバーの優先順位が指定されていないクライアントマシンは、「デフォルトでのクライアントの検索動作」で説明したように NIS+ 情報を入手します。
ローカル /var/nis/client_info ファイルで設定されたサーバーの優先順位があるクライアントマシンは、引き続きそのファイルに指定されたサーバーを使用します。
ローカル優先順位を終了するということは、次の異なる 3 つの事項のいずれか 1 つを意味すると考えられます。
特定のマシンで、サーバーの優先順位にローカル client_info ファイルの使用を終了し、かわってドメインのグローバル client_info テーブル内にそのサブネット用に設定された優先順位を使用したい場合
このマシンで、サーバーの優先順位にローカル client_info ファイルの使用を終了し、かわってドメインのグローバル client_info テーブル内にそのマシン固有に設定された優先順位を使用したい場合
特定のマシンで、サーバーの優先順位をまったく使用したくない場合。マシンがサーバーの優先順位を使用しない場合、そのマシンは、「デフォルトでのクライアントの検索動作」に説明した方法で NIS+ 情報を入手する
マシンの /var/nis/client_info ファイルを削除します。
# rm /var/nis/client_info |
この結果、マシンはドメインのグローバル client_info テーブル内でマシンのサブネットに指定された優先順位を使用するようになります。
マシンの /var/nis/client_info ファイルを削除します。
# rm /var/nis/client_info |
-G と -C オプションを使用して、グローバルテーブル内にそのマシン用の優先順位を指定します。
詳細は、「個別のマシンにグローバル優先順位を設定する方法」を参照してください。
マシンの /var/nis/client_info ファイルを削除します。
# rm /var/nis/client_info |
マシンのドメインにグローバル client_info テーブルがない場合、必要な処理はこの手順だけです。ドメインに client_info テーブルがある場合は、手順 2 に進んでください。
空の /var/nis/client_info ファイルを作成します。
# touch /var/nis/client_info |
マシンに固有の /var/nis/client_info ファイルがある場合、そのマシンは client_info テーブルのグローバル優先順位は使用しません。マシンに空の /var/nis/client_info ファイルがある場合、そのマシンはどの優先順位も使用せず、「デフォルトでのクライアントの検索動作」で説明した方法で NIS+ 情報を入手します。
使用サーバーの変更内容は、通常、クライアントマシンをリブートするか、またはマシンのキャッシュ管理プログラムを更新した時に有効になります。
ローカル client_infoファイル (-L オプション) を使用するローカルマシン上で、nisprefadm を使用してサーバーの優先順位の設定または変更した場合は、その変更内容はただちに有効になります。
グローバル client_info テーブル (-G オプション) からサーバーの優先順位を入手しているマシンの場合、nisprefadm に -F オプションを指定して実行すると、サーバーの優先順位に加えた変更を強制的にただちに有効にできます。
# nisprefadm -F |
-F オプションとは、マシンのキャッシュ管理プログラムに、そのサーバーの優先順位情報をドメインのグローバル client_info テーブルを使って強制的にただちに更新させるオプションです。nisprefadm -F を実行するマシンが、/var/nis 内にそのマシン固有のローカル client_info ファイルを持つ場合、そのマシン上で nisprefadm -F を実行しても無効になります。
-F オプションは、他の nisprefadm オプションと同時に使用できません。nisprefadm -F コマンドは、必ず、このコマンドを適用するマシン上で、単独で使用してください。-G オプションを使用して、ドメイン内にあるすべてのマシンのキャッシュ管理プログラムを更新できません。nisprefadm -F コマンドは、各マシン上でそれぞれ実行する必要があります。
新しく作成、または変更したサーバーリストを、指定したマシン上で強制的にただちに有効にするためには、次のようにします。
# nisprefadm -F |
たとえば、vega の優先サーバーリストへの変更内容を、強制的にただちに実現させるには (ローカルまたはグローバルのどちらの場合でも)、次のように入力してください。
vega# nisprefadm -F |
この章では、NIS+ 名前空間のバックアップ方法と復元方法について説明します。
NIS+ のバックアップ機能と復元機能を使用すると、NIS+ 名前空間の保存と復元を素早く簡単に行うことができます。また、これらの機能を使用すると、新しい複製サーバーを簡単に作成でき、さらにそのサーバーをオンラインにするためにかかる時間を削減できます。これらのタスクは、次の 2 種類のコマンドを使用して実行します。
nisbackup - NIS+ ディレクトリオブジェクトをバックアップする
nisrestore - NIS+ ディレクトリオブジェクトを復元する
nisbackup コマンドは、1 つまたは複数の NIS+ ディレクトリオブジェクト、または 1 つの名前空間全体を、指定した UNIX ファイルシステムのディレクトリにバックアップします。
nisbackup コマンドは、必ずマスターサーバー上で実行してください。複製サーバー上では絶対に実行しないでください。
nisbackup コマンドは、バックアップコマンドが動作するように設定された時点の NIS+ 名前空間をコピーします。この記録には、現行のすべての NIS+ データと、認証されたネットワーク管理者が NIS+ 名前空間に入力した変更が含まれます。ただし、まだ NIS+ テーブルにチェックポイントされていない ( NIS+ テーブルに記入されていない) ものは除きます。このバックアップ処理は、NIS+ データのチェックや訂正は行いません。テーブル内のデータが破壊されると、破壊されたデータは、有効なデータと見分けがつかない状態にバックアップされます。
nisbackup コマンドは、マシンがそのマスターサーバーであるディレクトリオブジェクトだけをバックアップします。つまり、nisbackup は、マスターサーバー上でだけ使用でき、複製サーバー上では使用できません。
マシンが、ドメインとサブドメイン両方の NIS+ ディレクトリオブジェクトのマスターサーバーである場合、nisbackup をこのマシン上で実行するとドメインとサブドメイン両方のディレクトリオブジェクトをバックアップできます。
ただし、マシンが、1 つのディレクトリオブジェクトのマスターサーバーで、さらに別のディレクトリオブジェクトの複製サーバーである場合、nisbackup を実行してそのマシンがマスターサーバーであるディレクトリオブジェクトをバックアップできますが、複製サーバーのオブジェクトはバックアップされません。
バックアップ処理が、他の処理に割り込まれたり、またはその処理を正常に終了できない場合は、処理を停止し、転送先ディレクトリ内に格納された以前のバックアップファイルをすべて復元します。
nisbackup コマンドで使用する構文は、次のとおりです。
nisbackup [-v][-a] backupdir objects |
backupdir には、バックアップファイルを格納する転送先ディレクトリが入ります。たとえば、/var/master1_bakup です。
objects には、バックアップする NIS+ ディレクトリオブジェクトが入ります。たとえば、org_dir.doc.com です。ここには、複数の NIS+ ディレクトリオブジェクトをスペースで区切って入力できます。
nisbackup コマンドには、次のようなオプションを指定できます。
表 16-1 nisbackup コマンドのオプション
オプション |
目的 |
---|---|
-v |
冗長モード。このモードは追加情報を出力する |
-a |
すべて。サーバーがマスターである NIS+ ディレクトリオブジェクトをすべてバックアップする。これには、このサーバーがマスターであるサブドメインのディレクトリオブジェクトも含まれる。ただし、他のマスターサーバーを持つサブドメインのディレクトリオブジェクトはバックアップされない |
nisbackup コマンドは、バックアップする NIS+ ディレクトリオブジェクトのマスターサーバー上で実行する必要があります。
バックアップする NIS+ ディレクトリオブジェクトを指定する場合、そのディレクトリ名には完全指定名、または部分指定名を使用できます。
マルチレベルディレクトリをバックアップする場合、下位ディレクトリのバックアップファイルは、自動的にバックアップ転送先ディレクトリのサブディレクトリ内に配置されます。
nisbackup を使用する場合、nisbackup はサーバー固有のコマンドであることに注意してください。-a オプションを使用するかどうかに関係なく、nisbackup は、このコマンドを実行中のサーバーがマスターサーバーであるディレクトリだけをバックアップします。他にマスターサーバーを持つ NIS+ ディレクトリオブジェクトは、バックアップされません。
たとえば、submaster1 は、sales.doc.com. ディレクトリオブジェクトのマスターサーバーで、さらに west.sales.doc.com. ディレクトリオブジェクトの複製サーバーでもあるとします。この場合、submaster1 上で nisbackup を実行すると、sales.doc.com. ディレクトリオブジェクトだけがバックアップされます。
このサーバー固有の原則には次のものがあります。
「全 NIS+ 名前空間」
複数のドメインのすべての名前空間に、NIS+ バックアップを実行する場合で、ルートマスターサーバーが全サブドメインのマスターサーバーでもある場合は、ルートマスター上で nisbackup に -a オプションを指定して実行します。ただし、スーパーユーザーのマスターサーバーが、すべてのサブドメインのマスターサーバーでない場合は、すべての名前空間のバックアップを完全に実施するために、nisbackup を他のマスターサーバー上でも実行する必要があります。
「サブドメイン」
1 つまたは複数のサブドメインの NIS+ バックアップを実行する場合、サブドメインのマスターサーバー上で nisbackup を実行する必要があります。ルートマスターなどの 1 つのマシンが、1 つまたは複数のサブドメインのマスターでもある場合、そのマシン上で nisbackup に -a オプションを指定して実行します。
「FNS ctx_dir」
FNS を実行している場合は、nisbackup を ctx_dir のマスターサーバー上で実行し、ctx_dir をバックアップするように指定するか、または -a オプションを使用すると、ctx_dir ディレクトリだけがバックアップされます。通常は、ctx_dir と NIS+ ディレクトリオブジェクトが別々のマスターサーバーから提供されていますが、この場合は、すべてのディレクトリをバックアップするには、nisbackup を両方のマシン上で実行する必要があります。
バックアップ転送先ディレクトリは、バックアップ対象のサーバーが使用できるものでなければなりませんが、サーバー上に物理的にマウントしていない転送先ディレクトリを使用するのも良い方法です。この場合、サーバーがダメージを受けても、バックアップディレクトリは使用可能です。
独立した転送先ディレクトリは、バックアップ対象となるマスターサーバーごとに使用する必要があります。混乱を避けるために、マスターサーバーのマシン名を転送先ディレクトリ内に組み込むと良いでしょう。たとえば、master1 マシン上で実行した nisbackup の転送先ディレクトリは、/var/master1_bakup という名前にします。
指定した 1 つの転送先ディレクトリに対して、複数のサーバーをバックアップしないでください。異なるマスターサーバーには、必ず、異なる転送先ディレクトリを使用してください。それは、指定した転送先ディレクトリに、1 つまたは複数の NIS+ ディレクトリオブジェクトをバックアップするたびに、このディレクト内のこれらの NIS+ ディレクトリオブジェクト用のそれ以前のバックアップファイルが上書きされるからです。
バックアップファイルを日付順に保存するには、少なくとも次の 2 つの方法があります。
「別々の転送先ディレクトリとして保存」
異なる転送先ディレクトリは、バックアップした日付ごとに保持できます。たとえば、/var/master1_bakup/July14、/var/master1_bakup/July15、など。この方法は簡単ですが、ディスク領域がかなり必要です。
「ファイルシステムのバックアップ」
NIS+ バックアップを日付順に保存する最も一般的な方法は、使用する通常ファイルシステムのバックアップメソッドに、バックアップ転送先ディレクトリを単に組み込むだけの方法です。これを簡単に行うには、nisbackup コマンドを crontab ファイルから実行するか、または Solstice バックアップルーチン内から実行します。nisbackup のようなコマンドを、システムのバックアッププロシージャとして自動的に実行するように指定する方法については、Solstice の説明書を参照してください。
特定の NIS+ ディレクトリオブジェクトをバックアップするには、これらのディレクトリをバックアップ転送先ディレクトリの後ろに入力します。
たとえば、ルート、sales ドメイン、manf ドメインの 3 つの org_dir ディレクトリオブジェクトを /master1_backup ディレクトリにバックアップするには、nisbackup を master1 マシン上で次のように実行します。
master1# nisbackup /var/master1_bakup org_dir org_dir.sales org_dir.manf |
すべての NIS+ 名前空間をバックアップする場合は、ルートマスターサーバー上で、nisbackup コマンドに -a オプションを指定して実行します。
-a オプションを使用する場合は、バックアップする NIS+ ディレクトリオブジェクトは指定しません。サーバー上とそのサーバーの下にあるサブドメインのすべての NIS+ ディレクトリオブジェクトは、自動的にバックアップされます。
たとえば、doc.com. 名前空間を /master1_bakup ディレクトリにバックアップするには、ルートマスター上で、nisbackup を次のように実行してください。
rootmaster# nisbackup -a /var/master1_bakup |
ドメイン上でバックアップを実行すると、バックアップ転送先ディレクトリ内に、NIS+ ディレクトリオブジェクトごとにサブディレクトリが作成されます。これらのサブディレクトリ名は、完全指定の NIS+ ディレクトリオブジェクト名の末尾にピリオドが付いたものになります。
-a オプションを使用して、すべての NIS+ オブジェクトを完全にバックアップすると、3 つの関連ディレクトリオブジェクト (ドメイン、org_dir.domein、groups_dir.domein) すべてがバックアップされ、転送先サブディレクトリが 3 つ作成されます。複数のオブジェクトをバックアップすると、サブディレクトリはバックアップしたそれぞれのオブジェクトごとに作成されます。
複数の NIS+ ディレクトリオブジェクトのバックアップサブディレクトリは、それがサブドメインであるかどうかに関係なく、親バックアップ転送先ディレクトリのサブディレクトリになるので注意してください。つまり、nisbackup は、親バックアップ転送先ディレクトリの下にドメインの階層を複製しません。その代わりに、バックアップサブディレクトリはすべて、転送先ディレクトリの単純なサブディレクトリになります。
たとえば、ルート、sales、manf のそれぞれからディレクトリオブジェクト doc.com. を /var/master1_bakup ディレクトリにバックアップする場合、図 16-1 に示すように、/var/master1_bakup ディレクトリ内には 9 個のサブディレクトリが作成されます。
バックアップ転送先ディレクトリには、この転送先ディレクトリにバックアップされた最新の NIS+ ディレクトリオブジェクトを表示する backup_list ファイルが入っています。
各サブディレクトリには、ファイルが 2 つと /data サブディレクトリが 1 つ組み込まれます。この 3 つのファイルを次に示します。
data.dict
このディレクトリにバックアップされた NIS+ ディレクトリオブジェクトの NIS+ データ辞書の入った XDR コード化ファイル
last.upd
このディレクトリにバックアップされた NIS+ ディレクトリオブジェクトに関する時刻スタンプ情報が入ったバイナリファイル
各 /data サブディレクトリには、1 つまたは複数の以下のファイルが入っています。
root.object
NIS+ ルートディレクトリオブジェクトの説明の入った XDR コード化ファイル。たとえば、/master1_bakup/doc.com/data/root.object
root_dir
これらのオブジェクトのルートディレクトリとサーバー情報内に組み込まれた NIS+ オブジェクトの説明が入った XDR コード化ファイル。たとえば、/master1_bakup/doc.com/data/root_dir
table.directory (テーブルディレクトリ)
バックアップの実行時に、NIS+ テーブル内に表示されていたデータと関連するすべての NIS+ ログファイル内に含まれるデータがすべて入った XDR コード化ファイル。バックアップされた NIS+ ディレクトリオブジェクト内に NIS+ テーブルがある場合、対応する table.directory バックアップファイルが、そのディレクトリオブジェクトの /data サブディレクトリ内に作成される。
たとえば、それぞれの NIS+ org_dir ディレクトリには、hosts テーブルが含まれるため、各 target/org_dir.domain/data サブディレクトリには、hosts.org_dir がある。たとえば、/master1_bakup/org_dir.doc.com./data/hosts.org_dir です。
指定したディレクトリオブジェクト内に表示されたユーザー作成の NIS+ テーブルは、標準 NIS+ テーブルとして同じ方法でバックアップされます。
groups_dir
NIS+ グループ情報の入った XDR コード化ファイル。このファイルは、対応する NIS+ groups_dir 転送先ディレクトリに格納されます。
nisrestore コマンドによって、nisbackup を使用して作成したバックアップファイル内に格納されたデータと一致する NIS+ ディレクトリオブジェクトが再現されます。このコマンドを使用すると、NIS+ サーバーの復元、壊れたディレクトリオブジェクトの置換、または新しい NIS+ サーバーに NIS+ データを読み込めます。
nisrestore を使用するためには、nisrestore から NIS+ データの受け取り先マシンが、NIS+ サーバーとして設定されている必要があります ( NIS+ サーバーの設定の詳細は、『Solaris ネーミングの設定と構成』を参照)。つまり、次のような状態にしておく必要があります。
マシンを、NIS+ クライアントとして初期化しておく必要があります。
マシンを NIS 互換モードで実行し、ドメイン名システム (DNS) 転送をサポートする場合は、そのマシンには、適切に構成された /etc/resolv.conf ファイルが必要です。
名前空間内で他のサーバーが実行中の時、あるサーバーで nisrestore を使用する場合は、nisrestore は、他のサーバーを検証して、このサーバーがサーバーに復元するバックアップ NIS+ オブジェクトを配布するように構成されているかどうかを確認します。実行中のサーバーが他にない場合は、nisrestore に -f オプションを指定して実行する必要があります。つまり、nisrestore がチェックする他のサーバーがある場合は、-f オプションを使用する必要はありません。また、使用できるサーバーが他にない場合、たとえば、1 台のマスターサーバーを復元するときに、機能複製サーバーが他にない場合は、-f オプションを使用する必要があります。
上記の 3 つの前提条件への追加条件として、マシン上で rpc.nisd デーモンを実行しないでください。rpc.nisd デーモンを実行する場合は、rpc.nisd を消去してから nisrestore を実行してください。
nisrestore コマンドでは、次の構文を使用します。
nisrestore [-fv][-a][-t] backupdir [directory_objects] |
backupdir には、NIS+ オブジェクトの復元に使用するバックアップファイルの入ったディレクトリを入力します (/var/master1_bakup)。
directory_objects には、復元する NIS+ ディレクトリオブジェクトを入力します (org_dir.doc.com)。複数の NIS+ ディレクトリオブジェクトを、スペースで区切って入れることができます。nisrestore に -a オプションを指定して実行する場合は、特定のディレクトリオブジェクトは指定しません。
nisrestore コマンドには、以下のオプションを指定できます。
表 16-2 nisrestore コマンドのオプション
オプション |
目的 |
---|---|
-a |
すべて。バックアップディレクトリ内に入っている NIS+ ディレクトリオブジェクトをすべて復元する |
-f |
サーバーが、ディレクトリオブジェクトのサーバーリストに記載されているかどうかを検査せずに、強制的に復元を行う。このオプションは、ルートマスターサーバーを復元する時、または " オブジェクトを検出できません " といった種類のエラーを受け取った場合に使用する必要がある |
-v |
冗長モード。このモードは、追加情報を出力する |
-t |
このオプションを使用すると、バックアップディレクトリ内に格納された NIS+ ディレクトリオブジェクトがすべて表示される。オブジェクトの復元は行われない |
NIS+ バックアップファイルから NIS+ データを復元するには、nisrestore コマンドを使用します。
たとえば、org_dir.doc.com. ディレクトリオブジェクトを replica1 サーバーに復元する場合は、スーパーユーザーになって replica1 にログインします。「nisrestore を実行するための前提条件」 で説明した前提条件が満たされていることを確認してから、以下のように nisrestore を実行します。
replica1# nisrestore /var/master1_bakup org_dir.doc.com. |
nisrestore には、以下の項目が適用されます。
「損傷した名前空間」
損傷した、または破壊された NIS+ 名前空間を復元するには、復元する NIS+ ディレクトリオブジェクトのすべてのサーバー上で nisrestore コマンドを実行する必要があります。
「検出エラー」
nisrestore が必要なデータを確認できないか、または検出できないというエラーメッセージを受け取った場合は、-f オプションを使用する必要があります。
たとえば、master1 という名前のルートマスターサーバー上に NIS+ データをロードし直す場合は、次のように入力します。
master1# nisrestore -f -a /var/master1_bakup |
NIS+ バックアップおよび復元機能を使用すると、NIS+ データを新しい複製サーバーに速く読み込むことができます。名前空間が広い場合は、この方法の方が、nisping を使用するよりもマスターサーバーからのデータを非常に速く入手できます。
新しい複製サーバーの設定に nisbackup と nisrestore を使用する方法の詳細は、『Solaris ネーミングの設定と構成』で説明しています。手順の簡単な説明を次に示します。
この処理は、nisping コマンドを使用した名前空間データのマスターから複製への自動転送に割り込んで実行されます。
マスターサーバー上で、nisbackup を実行します。
新しい複製サーバー上で nisrestore を実行し、NIS+ データを読み込みます。
nisbackup と nisrestore を使用すると、サーバーとして使用中のマシンと別のマシンをすぐに置換できます。たとえば、旧サーバーを新しい高速のサーバーと交換すると、ネットワークのパフォーマンスを向上させることができます。
NIS+ サーバーとして使用中のマシンを他のマシンに置き換える場合には、次の条件が必要です。
新しいマシンには、置換する旧マシンと同じ IP アドレスを割り当てます。
新しいマシンには、置換する旧マシンと同じマシン名を割り当てます。
新しいマシンは、置換する旧マシンと同じサブネットに接続します。
サーバーマシンを置換する場合は、次の手順に従ってください。
旧サーバーが管理するドメインのマスターサーバー上で nisbackup を実行します。
詳細は、「すべての NIS+ 名前空間をバックアップする」を参照してください。置換する旧サーバーがマスターサーバーである場合もあるので注意してください。この場合は、この旧マスターサーバー上で nisbackup を実行します。
旧サーバーをネットワークから切り離します。
新しいサーバーをネットワークに接続します。
新しいサーバーに旧サーバーと同じ IP アドレス (番号) を割り当てます。
新しいサーバーに旧サーバーと同じマシン名を割り当てます。
必要な場合は、新しいサーバー上で rpc.nisd を消去します。
新しいサーバー上で nisrestore を実行し、NIS+ データを読み込みます。
詳細は、「nisrestore を使用して NIS+ 名前空間を復元する」を参照してください。
.rootkey ファイルを、バックアップディレクトリから新しいサーバーの /etc にコピーします。
NIS_COLD_START ファイルを、バックアップディレクトリから新しいサーバーの /var/nis にコピーします。
新しいサーバーを再起動します。
この章では、NIS+ ディレクトリ管理コマンドを使用して、クライアントまたはサーバーから NIS+ を削除する方法と、NIS+ 名前空間全体を削除する方法について説明します。
NIS+ 複製サーバーを、ディレクトリから分離し、そのドメインの複製サーバーとして機能しないようにする場合は、「nisrmdir コマンド」を参照してください。
この節では、クライアントマシンから NIS+ を削除する方法について説明します。ただし、クライアントマシンから NIS+ を削除しても、ネットワークから NIS+ ネームサービスを削除したことにはならないので注意してください。ネットワークから NIS+ ネームサービスを削除して、NIS または /etc ディレクトリのファイルをネームサービスとして使用する状態に戻す場合は、「NIS+ 名前空間を削除する」を参照してください。
『Solaris ネーミングの設定と構成』で説明されているように、nisclient -i スクリプトを使用して NIS+ クライアントとして設定したクライアントマシンから NIS+ を削除するには、以下のように -r オプションを指定して nisclient を実行します。
client# nisclient -r |
nisclient -r では、nisclient -i 1 回分の処理が取り消されます。つまり、nisclient -i 実行以前にクライアントによって使用されていたネーミングシステム (NIS、あるいは /etc ディレクトリのファイルなど) が再び使用されるようになります。
nisaddcred、domainname、nisinit といったコマンドによって NIS+ クライアントとして設定したクライアントマシン (『Solaris ネーミングの設定と構成』を参照) から NIS+ を削除する手順は以下のとおりです。
client# rm -f /etc/.rootkey |
keyserv、nis_cachemgr、nscd のプロセス ID を確認して、終了します。
client# ps -ef | grep keyserv root 714 1 67 16:34:44 ? keyserv client# kill -9 714 client# ps -ef | grep nis_cachemgr root 123 1 67 16:34:44 ? nis_cachemgr client# kill -9 123 client# ps -ef | grep nscd root 707 1 67 16:34:44 ? nscd client# kill -9 707 |
/var/nis ディレクトリとその下のファイルを削除します。
clientmachine# rm -rf /var/nis/* |
この節では、NIS+ サーバーから NIS+ を削除する方法を示します。
ただし、サーバーから NIS+ を削除しても、ネットワークから NIS+ ネームサービスを削除したことにはならないので注意してください。ネットワークから NIS+ ネームサービスを削除して、NIS または /etc ディレクトリのファイルをネームサービスとして使用する状態に戻す場合は、「NIS+ 名前空間を削除する」を参照してください。ルートマスターサーバーから NIS+ を削除します。
NIS+ サーバーとして使用しているマシンを、別のマシンに置換できます。「サーバーマシンを置換する」を参照してください。
サーバーから NIS+ を削除する手順は以下のとおりです。
クライアントから NIS+ を削除する作業を行います。
NIS+ サーバーも NIS+ クライアントの一種なので、まずクライアントに関連する部分を削除する必要があります。このためには nisclient -r (「nisclient を使用してインストールした NIS+ を削除する」を参照) か、NIS+ コマンド (「NIS+ コマンドでインストールした NIS+ を削除する」を参照) を使用します。
サーバーの groups_dir ディレクトリと org_dir ディレクトリを削除する。
server# nisrmdir -f groups_dir. domainname server# nisrmdir -f org_dir. domainname |
keyserv、rpc.nisd、nis_cachemgr、nscd のプロセス ID を確認し、終了します。
server# ps -ef | grep rpc.nisd root 137 1 67 16:34:44 ? rpc.nisd server# kill -9 137 server# ps -ef | grep keyserv root 714 1 67 16:34:44 ? keyserv server# kill -9 714 server# ps -ef | grep nis_cachemgr root 123 1 67 16:34:44 ? nis_cachemgr server# kill -9 123 server# ps -ef | grep nscd root 707 1 67 16:34:44 ? nscd server# kill -9 707 |
/var/nis ディレクトリとその下のファイルを削除します。
rootmaster# rm -rf /var/nis/* |
NIS+ 名前空間を削除し、NIS または /etc ディレクトリのファイルをネームサービスとして使用する状態に戻す手順は以下のとおりです。
ルートマスターから .rootkey ファイルを削除します。
rootmaster# rm -f /etc/.rootkey |
ルートマスターのルートドメインから groups_dir サブディレクトリと org_dir サブディレクトリを削除します。
rootmaster# nisrmdir -f groups_dir. domainname rootmaster# nisrmdir -f org_dir.domainname |
domainname には、ルートドメイン名 (doc.com など) が入ります。
ルートドメインを削除します。
rootmaster# nisrmdir -f domainname |
domainname には、ルートドメイン名 (doc.com など) が入ります。
keyserv、rpc.nisd、nis_cachemgr、nscd のプロセス ID を確認し、終了します。
rootmaster# ps -ef | grep rpc.nisd root 137 1 67 16:34:44 ? rpc.nisd rootmaster# kill -9 137 rootmaster# ps -ef | grep keyserv root 714 1 67 16:34:44 ? keyserv rootmaster# kill -9 714 rootmaster# ps -ef | grep nis_cachemgr root 123 1 67 16:34:44 ? nis_cachemgr rootmaster# kill -9 123 rootmaster# ps -ef | grep nscd root 707 1 67 16:34:44 ? nscd rootmaster# kill -9 707 |
新しいドメインを作成します
rootmaster# domainname name |
name には、新しいドメイン名 (NIS+ インストール前のドメイン名など) が入ります。
既存の /etc/defaultdomain ファイルを削除します。
rootmaster# rm /etc/defaultdomain |
/etc/defaultdomain ファイルを、新しいドメイン名を使用して作成し直します。
rootmaster# domainname > /etc/defaultdomain |
nsswitch.conf ファイルを元のファイルに戻します。
サーバーを nisserver -r を使用して設定した場合は、以下のコマンドを使用します。
rootmaster# cp /etc/nsswitch.conf.no_nisplus /etc/nsswitch.conf |
また、デフォルトスイッチテンプレートファイルの 1 つをコピーする方法もあります。NIS スイッチのデフォルトファイルテンプレートを使用する場合は、以下のコマンドを入力します。
rootmaster# cp /etc/nsswitch.nis etc/nsswitch.conf |
/etc ファイルのデフォルトスイッチファイルテンプレートを使用する場合は、以下のコマンドを入力します。
rootmaster# cp /etc/nsswitch.files etc/nsswitch.conf |
rootmaster# keyserv |
/var/nis ディレクトリとその下のファイルを削除します。
rootmaster# rm -rf /var/nis/* |
この状態で、別のネームサービス (NIS または /etc ファイル) を再起動できます。