パート II NIS+ の設定と構成

このパートでは、Solaris OS 上で NIS+ ネームサービスを設定および構成する方法について説明します。

第 2 章 NIS+ の紹介

この章では、NIS+ の概要を述べます。

NIS+ は、将来のリリースではサポートされなくなる可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 リリース以降で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ について

NIS+ は NIS によく似たネットワークネームサービスですが、より多くの機能を備えています。NIS+ は、NIS の拡張機能ではなく、新しいソフトウェアプログラムです。

NIS+ ネームサービスは、ネットワークがどのような構造であっても、その周囲を取り巻くことにより、サービスを設置した組織の形態に適合するように設計されています。

NIS+ はマシンのアドレス、セキュリティ情報、メール情報、Ethernet インタフェース、ネットワークサービスなどの情報を集中的に格納して、ネットワーク上のすべてのマシンからアクセスできるようにします。このように構成されたネットワーク情報を、NIS+「名前空間」と呼びます。

NIS+ 名前空間は階層構造となっていて、UNIX® のディレクトリファイルシステムによく似ています。階層構造になっていることから、NIS+ 名前空間を企業組織の階層に合わせて構成できます。NIS+ 名前空間は、独立して管理できる複数のドメインに分割できます。クライアントは、適切なアクセス権があれば、自分のドメインだけではなく、ほかのドメインの情報にもアクセスできます。

NIS+ はクライアントサーバーモデルを使用して、NIS+ 名前空間に情報を格納し、またその情報にアクセスできます。各ドメインは複数のサーバーによってサポートされます。もっとも重要なサーバーは「マスター」サーバーと呼ばれ、バックアップサーバーは「複製」サーバーと呼ばれます。ネットワーク情報は、内部 NIS+ データベース内にある 16 個の標準 NIS+ テーブルに格納されています。マスターサーバーと複製サーバーは、両方とも NIS+ のサーバーソフトウェアを実行し、NIS+ テーブルのコピーを保持します。マスターサーバー上の NIS+ データの変更は、複製サーバーにも自動的に伝達されます。

NIS+ には、名前空間の構造とその情報を保護するために、高度なセキュリティシステムが組み込まれています。NIS+ は認証 (authentication) と承認 (authorization) を使用して、クライアントの情報要求に応えるべきかどうかを検証します。「認証」とは、情報の要求者がネットワークの正当なユーザーであるかどうかを判定することです。「承認」とは、要求された情報に関して特定のユーザーが入手または変更を許可されているかどうかを判定することです。

Solaris のクライアントは、ネームサービススイッチ (/etc/nsswitch.conf ファイル) を使用して、マシンがどこからネットワーク情報を取り出すかを決定します。この種の情報はローカル側の /etc ファイルや、NIS、DNS、NIS+ に格納されます。ネームサービススイッチでは、情報の種類ごとに異なるソースを指定できます。このスイッチの詳細は、第 1 章「ネームサービススイッチ」を参照してください。

NIS+ のメリット

NIS と比較すると、NIS+ には次のようなメリットがあります。

• 安全性の高いデータアクセス

• 階層構造を使用した分散型のネットワーク管理

• 非常に大きな名前空間の管理

• 異なるドメインにあるリソースへのアクセス

• 増分 (incremental) 更新

「NIS+ のセキュリティ」で説明したセキュリティシステムを使用すれば、特定のテーブルの個々のエントリに対する特定のユーザーのアクセスを制御できます。このようなセキュリティ方式では、システムを安全に維持でき、しかも NIS+ 名前空間全体またはテーブル全体が損傷する危険性がなく、管理業務を広く分散させることができます。

NIS+ の階層構造により、使用する名前空間に複数のドメインを置くことができます。ドメインに分割することにより、管理が容易になります。個々のドメインは完全に独立して管理できるため、システム管理者の負担が軽減され、非常に大きな名前空間の管理責任から解放されます。このように、セキュリティシステムを分散型のネットワーク管理と組み合わせることによって、管理作業の負担を分担することができます。

ドメインが個別に管理されているとしても、すべてのクライアントに名前空間内のすべてのドメインの情報を参照するアクセス権を与えることができます。クライアントは自分のドメイン内のテーブルしか見ることができないため、クライアントがほかのドメイン内のテーブルにアクセスするには、そのテーブルについて明示的にアドレスを指定しなければなりません。

増分更新とは、名前空間内での情報の高速の更新を意味します。ドメインは独立して管理されるため、マスターサーバーテーブルへの変更は、名前空間全体にではなく、その複製サーバーだけに伝達します。伝達が行われると、これらの変更はすぐに名前空間全体で有効になります。

NIS+ と NIS の違い

ネットワーク情報サービスプラス (NIS+) は、ネットワーク情報サービス (NIS) といくつかの点で異なります。NIS+ には、多くの新しい機能が追加されています。また、NIS と似た概念に対して、使用する用語が異なることがあります。わからない用語がある場合は、用語集を参照してください。次の表に、NIS と NIS+ の主な相違点を示します。

NIS+ は NIS に代わるものとして設計されました。NIS は、1980 年代に普及していたクライアントサーバーコンピューティングネットワークの管理要件に応えるものです。その当時のクライアントサーバーネットワークは、通常、クライアント数が数百を超えることはなく、多目的サーバーの数もわずかでした。これらのネットワークは数カ所のリモートサイトを結んでいるだけであり、しかもユーザーに専門知識があり信頼できたため、セキュリティを必要としませんでした。

しかしクライアントサーバーネットワークは 1980 年代半ば頃から急速な成長を遂げました。現在では、世界中のサイトに配置された 10〜100 台の専用サーバーにサポートされた 100〜10,000 台のマルチベンダークライアントが存在し、複数の公衆網に接続されています。さらに、ネットワークが格納する情報は、NIS の時代よりもはるかに急速に変化しています。このようなネットワークの規模と複雑性に対処するため、新しい管理方式が必要になりました。NIS+ はこれらの必要性に焦点をあてて設計されました。

NIS の名前空間は、フラットな状態で管理機能を集中管理しています。1990 年代に入りネットワークはスケーラビリティと管理の分散化を求めるようになったため、NIS+ の名前空間は DNS の場合のように階層ドメインをベースに設計されました。

たとえば図 2–1 は doc という名前の親ドメインと、sales と manf という 2 つのサブドメインを持つ会社の例を示しています。

図 2–1 階層型ドメインの例

これによって NIS+ は、小規模から大規模まで、広い範囲のネットワークで使用できます。また、NIS+ のサービスを組織の成長に適合させることもできます。たとえば、ある会社が 2 つの部門に分かれた場合、それに対する NIS+ の名前空間を 2 つのドメインに分割し、これらを自律的に管理できます。インターネットがドメインの管理を下のレベルに委譲するように、NIS+ のドメインも程度の差はあっても互いに独立して管理できます。

NIS+ は DNS と似たドメイン階層を使用しますが、NIS+ のドメインは DNS のドメインよりずっと多くの情報を持っています。DNS のドメインは、そのクライアントの名前とアドレスの情報を格納するだけです。一方 NIS+ のドメインには、組織の一部の中でのマシン、ユーザー、およびネットワークサービスについての「情報」が集められています。

ドメインをこのように分割することで、管理はより自律的になり、規模が拡大した場合にもうまく対処できますが、情報へのアクセスが以前より困難になることもありません。クライアントはほかのドメインの情報にも、同じドメインと同じようにアクセスできます。あるドメインを別のドメインの内部から管理することもできます。

主 NIS+ サーバーは「マスター」サーバーと呼ばれ、バックアップサーバーは「複製」サーバーと呼ばれます。マスターサーバーと複製サーバーは、両方とも NIS+ のサーバーソフトウェアを実行し、NIS+ テーブルのコピーを保持します。NIS の情報はマップに格納されますが、NIS+ の情報はテーブルに格納されます。主サーバーはオリジナルのテーブルを、バックアップサーバーはコピーを、それぞれ格納します。

しかし NIS+ は、NIS とはまったく異なる更新方式を使用します。NIS が開発された当時は、格納される情報の型はめったに変化しなかったため、NIS は安定性に重点を置いた更新方式によって開発されました。NIS テーブルの更新は手作業で処理され、大規模な組織では、すべての複製サーバーへの伝達に 1 日以上かかることもあります。この原因の一つは、マップ内の情報が変化するたびにマップ全体を再作成して伝達しなければならなかったからです。

しかし NIS+ は、複製サーバーに対する「増分 (incremental)」更新が可能です。マスターサーバー上での変更は依然として必要ですが、いったん変更すれば、複製サーバーに自動的に伝達され、すぐに名前空間全体から使用できるようになります。マップを「作成」したり、伝達を待つ必要はありません。

NIS+ の ドメイン構造、サーバー、およびクライアントの詳細については、それぞれ 「NIS+ のドメイン」、「NIS+ サーバー」、および 「NIS+ 主体 (クライアント)」を参照してください。

NIS+ のドメインは、ネームサービススイッチを使用して、その NIS+ クライアントを経由してインターネットに接続できます (例 1–1 を参照)。このクライアントが DNS のクライアントでもある場合、自分のスイッチ構成ファイルを設定して、NIS+ テーブルだけでなく、DNS ゾーンファイルまたは NIS マップ内の情報を検索できます。

NIS+ は、マップやゾーンファイルではなく、「テーブル」に情報を格納します。NIS+ は 16 種類のあらかじめ定義したテーブル (つまり「システム」テーブル) を提供します。

各テーブルにはそれぞれ異なる情報が格納されています。たとえば、hosts テーブルにはマシンアドレスについての情報が、passwd テーブルにはネットワークのユーザーについての情報が格納されています。

NIS+ のテーブルは、NIS で使用されるマップと比較して 2 つの点で大きく改良されています。第 1 に、NIS+ のテーブルは、最初の列 (キーと呼ばれることもある) だけではなく、任意の列ごとにアクセスできます。これによって、NIS で使用される hosts.byname や hosts.byaddr マップなどの二重マップが必要なくなります。第 2 に、NIS+ のテーブル内の情報は、3 つの細分化されたレベルでアクセスし、操作できます。テーブルレベル、エントリレベル、および列レベルです。NIS+ のテーブルとそこに格納されている情報については、第 10 章「NIS+ のテーブルと情報」で説明します。

NIS 管理者は、以下に示す原則および条件下で NIS を NIS+ とともに使用できます。

• 同一ドメインに NIS サーバーと NIS+ サーバーの両方が存在する。NIS 管理者は、同一ドメインで NIS サーバーと NIS+ サーバーの両方を動作させることは可能ですが、このような動作を長時間行わせることは望ましくありません。一般に、同一ドメイン内での NIS サーバーと NIS+ サーバーを両方使用するのは、NIS から NIS+ への短い移行期間だけに制限するべきです。

• サブドメイン。NIS 管理者のルートドメインのマスターサーバーで NIS+ が動作している場合は、NIS 管理者は、すべてのサーバーで NIS が動作しているサブドメインを設定できます。NIS 管理者のルートドメインのマスターサーバーで NIS が動作している場合は、NIS 管理者はサブドメインの設定はできません。

• 同一ドメインに複数のマシンが存在する。同一ドメイン内のサーバーで NIS+ が動作している場合は、NIS+、NIS、または /etc ファイルを使ってネームサービス情報を取得するように、ドメイン内の各マシンを設定できます。NIS+ サーバーが NIS クライアントのニーズを満たすには、この NIS+ サーバーが NIS 互換モードで動作している必要があります。

  同一ドメイン内のサーバーで NIS が動作している場合は、NIS または /etc ファイルを使ってネームサービス情報を取得するように、このドメイン内の各マシンを設定できます (各マシンは NIS+ を使用することはできません) 。

  さまざまなネームサービス情報を取得するためにマシンが使用するサービスは、そのマシンの nsswitch.conf ファイルで制御されます。このファイルは、「スイッチ」ファイルと呼ばれています。詳細は、第 1 章「ネームサービススイッチ」を参照してください。

NIS+ のセキュリティ

NIS+ は、「承認と認証」という相補的なプロセスによって、名前空間の構造と格納する情報を保護します。

• 「承認 (authorization)」。名前空間の各構成要素は、「だれからのどのような操作を許可するか」を規定しています。これが承認です。

• 「認証 (authentication)」。名前空間に対するアクセス要求はすべて、NIS+ によって「認証」されます。アクセス要求は、 NIS+ 主体から発行されます。NIS+ 主体には、プロセス、マシン、ルート、またはユーザーがなることができます。正当な NIS+ 主体は、NIS+「資格」を持ちます。名前空間へのアクセスが行われると、必ずその要求者 (主体) の認証が行われます。

NIS+ が要求どおりの動作をするのは、「主体が認証されていて (正当な資格を持っていて)、要求された操作が、該当する構成要素において承認されている」という場合のみです。資格がない (または完全でない)、要求された操作が承認されていないという場合、NIS+ はアクセス要求を拒否します。NIS+ セキュリティシステム全体の概要については、第 11 章「NIS+ のセキュリティの概要」を参照してください。

Solaris 1.x と NIS 互換モード

Solaris 1.x または 2.x では、NIS+ を NIS が動作しているマシンで使用できます。つまり、NIS+ ドメイン内にあるマシンはそれぞれの nsswitch.conf ファイルを nisplus ではなく nis に設定できます。NIS を実行中のマシン上で NIS+ のサービスにアクセスする場合は、NIS+ のサーバーを「NIS 互換モード」で動作させる必要があります。

NIS 互換モードを使用すれば、Solaris ソフトウェアを実行している NIS+ サーバーは、NIS+ クライアントからの要求に応答しながら、NIS クライアントからの要求にも応答できます。NIS+ は 2 つのサービスインタフェースを提供することによってこれを実現します。1 つが NIS+ クライアントの要求に応答し、もう 1 つが NIS クライアントの要求に応答します。

このモードでは、NIS クライアントに対してさらに設定や変更を行う必要はありません。実際、NIS クライアントは、応答しているサーバーが NIS サーバーではないことを意識する必要はありません。ただし、NIS 互換モードで動作している NIS+ サーバーは ypupdate と ypxfr のプロトコルをサポートしないため、複製またはマスターの NIS サーバーとしては使用できません。NIS 互換モードの詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』の「NIS+ サーバーの設定」を参照してください。

さらに 2 つの相違を指摘しておく必要があります。1 つは、NIS 互換モードでサーバーを設定する命令が標準の NIS+ サーバーの設定に使用される命令とは少し異なるということです。もう 1 つの相違としては、NIS 互換モードは、NIS+ の名前空間内のテーブルに対するセキュリティにも関係があります。NIS のクライアントソフトウェアは、NIS+ サーバーが NIS+ クライアントに与える資格 (credential) を提供する機能がないため、NIS クライアントからの要求はすべて「未認証」として分類されます。したがって、NIS クライアントが NIS+ テーブル内の情報にアクセスできるように、NIS+ の名前空間内のテーブルは未認証の要求に対してアクセス権を提供しなければなりません。これはパート II で説明するように、サーバーを NIS 互換モードで設定するために使用されるユーティリティによって自動的に処理されます。認証プロセスと NIS 互換モードについては、『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』の「NIS+ のセキュリティの概要」を参照してください。

再起動を繰り返しても NIS 互換モードが持続するように設定する場合は、「NIS+ とサービス管理機能」の説明に従って、/lib/svc/method/nisplus ファイルを変更する必要があります。

NIS+ の管理コマンド

NIS+ では、名前空間を管理するのに必要なコマンドがすべて提供されています。次の表に、これらのコマンドについてまとめます。

NIS+ サービスに関連したコマンド行管理タスクのほとんどは、サービス管理機能 (Service Management Facility、SMF) によって管理されます。SMF を NIS+ で使用する方法については、「NIS+ とサービス管理機能」を参照してください。SMF の概要については、『Solaris のシステム管理 (基本編)』の「サービスの管理 (概要)」を参照してください。詳細については、svcadm(1M) と svcs(1) の各マニュアルページも参照してください。

NIS+ の API

NIS+ の API (アプリケーションプログラミングインタフェース) とは、アプリケーションが NIS+ のオブジェクトへのアクセスと修正を行うために呼び出す関数群です。NIS+ の API には 54 個の関数があり、それらは次の 9 つのグループに分類されます。

• オブジェクト操作関数 (nis_names())

• テーブルアクセス関数 (nis_tables())

• ローカル名関数 (nis_local_names())

• グループ操作関数 (nis_groups())

• アプリケーションサブルーチン関数 (nis_subr())

• その他の関数 (nis_misc())

• データベースアクセス関数 (nis_db())

• エラーメッセージ表示関数 (nis_error())

• トランザクションログ関数 (nis_admin())

設定および構成の前に

NIS+ 名前空間を構成する前に、次の作業を行う必要があります。

• NIS+ を使用するすべてのマシンの nsswitch.conf ファイルを正しく構成します。詳細は、第 1 章「ネームサービススイッチ」を参照してください。

• NIS+ 名前空間のレイアウトを設計します。レイアウトを設計する際、次の点を考慮してください。

  • 名前空間の設計。どんなドメイン名を付けるか。サブドメインを作るか。サブドメインを作るとしたら、それらをどのように編成するか。どのマシンをどのドメインに入れるか。ドメインを上位のドメインあるいはインターネットに接続するか。

  • サーバー要件の確認。各ドメインに複製サーバーをいくつ置くか。必要なサーバーの種類、処理速度、メモリー容量はサーバーのディスク容量はどれくらい必要か。

    上記およびほかの設計上の考慮事項、および推奨ガイドラインの詳細については本書をよくお読みください。

• 名前空間がすでに存在している場合、NIS+ に移行するための準備をします。「名前空間がすでに存在する場合の設定」を参照してください。

• ルートサーバーマシンを選択します。

• ルートマスターサーバーとして使用できるシステムが少なくとも 1 つは稼働していることを確認します。ルートマスターサーバーでは、/etc/passwd などのシステム情報ファイルに少なくとも 1 人のユーザー (root) が登録されていなければなりません 。通常のマシンのシステム情報ファイルには root が存在しますので、これが問題となることはないはずです。

NIS と NIS+

NIS とNIS+ は、いくつかの同じ作業を行います。ただし NIS+ では、NIS で提供されない階層ドメイン、名前空間セキュリティなどの機能が使用できます。NIS と NIS+ の相違点の詳細は、「NIS+ と NIS の違い」を参照してください。

NIS 管理者は、以下に示す原則および条件下で NIS を NIS+ とともに使用できます。

• 同一ドメインに NIS サーバーと NIS+ サーバーの両方が存在する。NIS 管理者は、同一ドメインで NIS サーバーと NIS+ サーバーの両方を動作させることは可能ですが、このような動作を長時間行わせることは望ましくありません。一般に、同一ドメイン内での NIS サーバーと NIS+ サーバーを両方使用するのは、NIS から NIS+ への短い移行期間だけに制限するべきです。クライアントから NIS サービスの要求があった場合に、NIS 管理者は、NIS+ を NIS 互換モードで動作させることができます。詳細は、「Solaris 1.x と NIS 互換モード」を参照してください。

• サブドメイン。NIS 管理者のルートドメインのマスターサーバーで NIS+ が動作している場合は、NIS 管理者は、すべてのサーバーで NIS が動作しているサブドメインを設定できます。NIS 管理者のルートドメインのマスターサーバーで NIS が動作している場合は、NIS 管理者はサブドメインの設定はできません。この操作は、NIS 管理者が NIS から NIS+ に移行する際に便利な場合があります。たとえば、互いに独立した複数の NISドメイン (ドメインは地理的に別々のサイトに置かれていることもある) を持った会社の中で、NIS 管理者がそれらのドメインをすべてリンクさせて NIS+ の下に 1 つの階層型マルチドメイン名前空間を構築するケースを考えてみます。 この場合、NIS 管理者はまずルートドメインを NIS+ 下に設定し、次に従来の NISドメインをサブドメインとして指定できます。これらのサブドメインでは、NIS+ へ切り換える準備ができるまで NIS が継続して動作します。

• 同一ドメインに複数のマシンが存在する。

  • 同一ドメイン内のサーバーで NIS+ が動作している場合は、NIS+、NIS、または /etc ファイルを使ってネームサービス情報を取得するように、ドメイン内の各マシンを設定できます。NIS+ サーバーが NIS クライアントのニーズを満たすには、この NIS+ サーバーが NIS 互換モードで動作している必要があります。「Solaris 1.x と NIS 互換モード」を参照してください。

  • 同一ドメイン内のサーバーで NIS が動作している場合は、NIS または /etc ファイルを使ってネームサービス情報を取得するように、このドメイン内の各マシンを設定できます (各マシンは NIS+ を使用することはできません) 。

NIS+ のファイルとディレクトリ

表 2–3 は、NIS+ ファイルが格納される UNIX ディレクトリの一覧です。

nisinit など NIS+ 設定プロシージャによって作成された /var/nis、/var/nis/data といったディレクトリ、およびその下のファイルは、名前を変更しないでください。Solaris 2.4 以前では、/var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルが含まれていました。またサブディレクトリ /var/nis/hostname もありました。Solaris 2.5 を起動すると、2 つのファイル名は trans.log、data.dict となり、サブディレクトリ名は /var/nis/data となります。ファイルの「内容」も変更されており、Solaris 2.4 以前との互換性はなくなっています。したがって、これらのファイルやディレクトリを Solaris 2.4 での名前にしてしまうと、Solaris 2.4 と現行バージョンのどちらの rpc.nisd でも機能しなくなるので名前の変更をしないようにしてください。ディレクトリ名もファイル名も変更しないでください。

Solaris プラットフォームでは、NIS+ データディレクトリ (/var/nis/data.dict) はマシンに依存しません。そのため、NIS+ 名を簡単に変えることができます。また、NIS+ のバックアップコピーを使用したり機能を復元したりして、NIS+ のデータをひとつのサーバーから別のサーバーに転送もできます。第 21 章「NIS+ のバックアップと復元」を参照してください。

NIS+ 名前空間の構造

NIS+ の名前空間は、NIS+ によって格納された情報を配置したものです。この名前空間は、組織のニーズに合わせていろいろな方法で配置することができます。たとえば、3 つの部門を持つ組織の場合、その NIS+ の名前空間も各部門ごとに 1 つずつで 3 つの部分に分割されます。分割した各部分は、その部門のユーザー、マシン、およびネットワークサービスについての情報を格納しますが、互いに通信することも簡単です。このような配置により、ユーザーによる情報へのアクセスや、管理者による情報の管理が更に容易に行えます。

NIS+ の名前空間の配置はサイトごとに異なりますが、ディレクトリ、テーブル、グループという構成はすべてのサイトが使用します。 これらの構成は NIS+「オブジェクト」と呼ばれます。NIS+ オブジェクトは、UNIX のファイルシステムに似た階層形式に配置できます。たとえば、次の図を参照してください。左側の名前空間は、3 つのディレクトリオブジェクト、3 つのグループオブジェクト、および 3 つのテーブルオブジェクトから構成されています。右側の UNIX ファイルシステムは、3 つのディレクトリと 3 つのファイルから構成されています。

NIS+ の名前空間は UNIX ファイルシステムに似ていますが、重要な違いが 5 つあります。

• 両方ともディレクトリを使用するが、NIS+ の名前空間でのオブジェクトはテーブルとグループであり、ファイルではない

• NIS+ の名前空間は、NIS+ の管理コマンド、または管理用に設計された Solaris 管理コンソール^TM ツールなどのグラフィカルユーザーインタフェース (GUI) だけで管理され、UNIX 標準のファイルシステムコマンドや GUI では管理できない

• UNIX ファイルシステム構成要素の名前はスラッシュで区切られる (/usr/bin) が、NIS+ の名前空間オブジェクト名はドットで区切られる (doc.com. )

• UNIX ファイルシステムの「ルート」へは、ディレクトリを右から左にたどっていけば到達する (/usr/src/file1) が、NIS+ の名前空間のルートは左から右にたどって到達する (sales.doc.com.)

• NIS+ オブジェクト名は、左から右に構成されているので、完全指定名は常にドットで終わる。また最後に「.」がないものは完全な名前とはみなされず、相対的な名前 (まだ上の階層があるという意味) であるとみなされる

NIS+ 名前空間のディレクトリ

ディレクトリオブジェクトは、名前空間の骨格を形成します。ツリー構造に配置した場合、名前空間を別々に分けます。ディレクトリ階層を理解するには、木の根を一番上に置き、逆さまの木として見るとよく分かります。名前空間の一番上のディレクトリが「ルート」ディレクトリです。名前空間が 1 つの層だけの場合、ディレクトリは 1 つしかありませんが、そのディレクトリはルートディレクトリです。ルートディレクトリの下にあるディレクトリオブジェクトは、単に「ディレクトリ」と呼ばれます。

1 つの名前空間には、複数の階層のディレクトリを割り当てることができます。

ディレクトリ間の関係を識別する場合には、下位ディレクトリは「子」ディレクトリと呼ばれ、上位ディレクトリは「親」ディレクトリと呼ばれます。

UNIX のディレクトリは UNIX のファイルを格納するように設計されていますが、NIS+ のディレクトリは NIS+ オブジェクト (ほかのディレクトリ、テーブル、およびグループ) を格納するように設計されています。 各 NIS+ のドメインレベルのディレクトリには、以下のサブディレクトリが含まれています。

• NIS+ グループ情報を格納する

• org_dir. -NIS+ システムテーブルを格納する

技術的には、ユーザーはディレクトリ、テーブル、およびグループをどんな構造にでも配置することができます。しかし、名前空間内の NIS+ のディレクトリ、テーブル、およびグループは、「ドメイン」と呼ばれる構成に配置されるのが普通です。ドメインは、名前空間の別々の部分をサポートするよう設計されています。たとえば、あるドメインが会社の営業部門 (Sales Division) をサポートし、別のドメインが製造部門 (Manufacturing Division) をサポートできます。

NIS+ のドメイン

1 つの NIS+ のドメインは、ディレクトリオブジェクト、その org_dir ディレクトリ、その groups_dir ディレクトリ、および NIS+ テーブルのセットから構成されます。

NIS+ のドメインは、実際に存在する名前空間の構成要素ではありません。これらは単に、現実の組織をサポートするために使用される名前空間の「一部分」を示すための便利な方法にすぎません。

たとえば、DOC 社に営業部門と製造部門があるとします。これらの部門をサポートするため、DOC 社の NIS+ 名前空間は、以下の図のような構造によって、3 つの主要ディレクトリグループに配置されることになります。

図 2–2 NIS+ ディレクトリ構造の例

このような構造を、3 つのディレクトリ、6 つのサブディレクトリ、およびいくつかの追加オブジェクトと表現するよりも、3 つの NIS+ ドメインと表現する方が便利です。

図 2–3 NIS+ ドメインの例

NIS+ サーバー

すべての NIS+ ドメインは複数の NIS+「サーバー」によってサポートされます。サーバーは、ドメインのディレクトリ、グループ、およびテーブルを格納し、ユーザー、管理者、およびアプリケーションからのアクセス要求に応答します。各ドメインは、1 組の複数のサーバーだけによってサポートされます。ただし、この 1 組のサーバーは複数のドメインをサポートできます。

ドメインはオブジェクトではなく、オブジェクトの集合を意味するものであることを忘れないでください。したがって、ドメインをサポートするサーバーは、実際にはドメインにではなく、ドメインのメインディレクトリに関連付けられています。

サーバーとディレクトリオブジェクトとのこうした接続は、ドメインを設定するときに行われます。ここで、重要なことを 1 つ指摘しておく必要があります。それは、この接続が確立されたときに、ディレクトリオブジェクトはそのサーバー名と IP アドレスを格納するということです。後述しますが、クライアントはこの情報を使用してサービス要求を送信します。

Solaris プラットフォームベースのマシンは、どれも NIS+ サーバーとなることができます。このリリースには、NIS+ のサーバー用とクライアント用の両方のソフトウェアが入っています。したがって、Solaris 2.x がインストールされているマシンであれば、サーバーにもクライアントにも、あるいはその両方にもなることができます。クライアントとサーバーを区別するのは、その果たす役割です。マシンが NIS+ サービスを提供している場合、それは NIS+ サーバーとして機能しています。同じマシンが NIS+ サービスを要求している場合、これは NIS+ クライアントとして機能しています。

多数のクライアント要求にサービスを提供する必要があるため、NIS+ サーバーとして機能するマシンは、平均的なクライアントよりも高いコンピューティング能力と多くのメモリーを装備して構成されます。そして、NIS+ データを格納する必要があるため、より大型のディスクも装備することになります。しかし、性能を高めるためのハードウェアを除いては、サーバーと NIS+ クライアントとの本質的な違いはありません。

NIS+ ドメインをサポートするのは、マスターとその複製の 2 種類のサーバーです。

ルートドメインのマスターサーバーを「ルートマスター」サーバーと呼びます。1 つの名前空間には 1 つのルートマスターサーバーしか存在しません。ほかのドメインのマスターサーバーは、単にマスターサーバーと呼びます。同様に、ルート複製サーバーと単なる複製サーバーがあります。

マスターサーバーと複製サーバーは、両方とも NIS+ テーブルを格納し、クライアント要求に応答します。ただし、マスターサーバーはドメインのテーブルのマスターコピーを格納します。複製サーバーは複製だけを格納します。管理者は、情報をマスターサーバー内のテーブルにロードし、マスターサーバーはそれを複製サーバーに伝達します。

この配置には 2 つのメリットがあります。第 1 に、マスターテーブルが 1 組しか存在しないことから、テーブル間の不一致を避けることができます。複製サーバーに格納されたテーブルは、マスターのコピーにすぎません。第 2 に、これによって NIS+ サービスの「信頼性」が大幅に向上します。マスターまたはスレーブのどちらかがダウンした場合、ほかのサーバーがバックアップとして機能し、サービス要求に応えることができます。

サーバーが変更を伝達する方法

NIS+ のマスターサーバーは、そのオブジェクトをすぐに更新します。しかし、更新 内容を複製サーバーに伝達する前に、複数の更新をまとめ (バッチ) ようと試みます。マスターサーバーが、ディレクトリ、グループ、リンク、またはテーブルといったオブジェクトへの更新を受信した場合、約 2 分間ほかの更新が到着しないかどうかを待機して確認します。待機時間が終了すると、これらの更新をディスクと「トランザクションログ」の 2 カ所に格納します (メモリーにはすでに更新を格納)。

マスターサーバーはトランザクションログを使用して、名前空間への変更内容が複製に伝達されるまで、これを格納します。トランザクションログには、更新とタイムスタンプという 2 つの要素が記録されます。

更新とは、変更されたオブジェクトの実際のコピーです。たとえば、ディレクトリが変更された場合、更新はそのディレクトリオブジェクトの完全なコピーです。テーブルエントリが変更された場合、更新は実際のテーブルエントリのコピーです。タイムスタンプは、マスターサーバーによって更新が行われた時間を示します。

その変更内容をトランザクションログに記録したのち、マスターは自分の複製にメッセージを送信し、送信すべき更新があることを知らせます。各複製は、マスターから受信した最後の更新のタイムスタンプでこれに応答します。するとマスターは、各複製のタイムスタンプ以降にログに記録した更新を複製に送信します。

マスターサーバーがその複製サーバーをすべて更新すると、トランザクションログをクリアします。ドメインに新しい複製が追加された場合などには、マスターは、トランザクションログに記録されているもっとも早い時間のタイムスタンプよりもさらに前のタイムスタンプを複製から受け取ることがあります。この場合、マスターサーバーは全面的な「再同期」、つまり「resync」を行います。resync では、マスターに格納されているすべてのオブジェクトと情報を該当複製にダウンロードします。resync 実行中には、マスターと複製の両方がビジー状態となります。複製は要求に応答できません。マスターは、読み取り要求には応答できますが、更新要求を受け付けることはできません。両方とも「Server Busy - Try Again」というメッセージで応答します。

NIS+ 主体 (クライアント)

NIS+ 主体とは、NIS+ サービスに要求をするエンティティ (クライアント) のことです。

NIS+ 主体

一般ユーザーであってもスーパーユーザー (root) であってもログインをすれば NIS+ 主体になります。実際の要求は、前者の場合はクライアントユーザーから、後者の場合はクライアントマシンから送られます。つまり NIS+ 主体は、クライアントユーザーである場合と、クライアントマシンである場合とがあります。

また NIS+ サーバーから NIS+ サービスを提供するエンティティも、NIS+ 主体になることができます。すべての NIS+ サーバーは NIS+ クライアントにもなるので、サーバーが NIS+ の主体となる場合もあります。

NIS+ クライアント

NIS+ クライアントとは、NIS+ サービスを要求するように設定されたマシンです。NIS+ クライアントの設定では、セキュリティ資格 (credential) を設定し、クライアントを適切な NIS+ グループのメンバーとし、そのホームドメインを確認し、スイッチ構成ファイルを確認し、最後に NIS+ 初期設定スクリプトを実行します (詳細は、パート II「NIS+ の紹介と概要」を参照)。

NIS+ クライアントは、セキュリティ上の制約に従って、名前空間のどの部分にもアクセスできます。つまり、認証されており、しかも適切なアクセス権が与えられている場合、名前空間内のどのドメインの情報やオブジェクトにもアクセスできます。

クライアントは名前空間全域にアクセスできますが、1 つのクライアントが所属するドメインは 1 つだけであり、これをその「ホーム」ドメインと呼びます。クライアントのホームドメインは、インストール時に指定されるのが普通ですが、インストール後でも変更または指定できます。クライアントの IP アドレスや資格など、クライアントについてのすべての情報は、そのホームドメインの NIS+ テーブルに格納されています。

NIS+ クライアントであることと、NIS+ テーブルに登録されていることは、微妙な違いがあります。あるマシンについての情報を NIS+ テーブルに入力しても、そのマシンが自動的に NIS+ クライアントになるわけではありません。これは単に、すべての NIS+ クライアントがそのマシンの情報を使用できるようにするだけです。実際に NIS+ クライアントとして設定しない限り、そのマシンから NIS+ サービスを要求することはできません。

逆に、あるマシンを NIS+ クライアントにしても、そのマシンについての情報は NIS+ テーブルに入力されません。これは単に、そのマシンで NIS+ サービスを受信できるようにするだけです。管理者がそのマシンについての情報を明確に NIS+ テーブルに入力しないと、ほかの NIS+ クライアントはその情報を入手できません。

クライアントが名前空間へのアクセスを要求した場合、実際には、クライアントは名前空間内の特定ドメインへのアクセスを要求していることになります。したがって、クライアントは、アクセスしようとしているドメインをサポートするサーバーに自分の要求を送信します。簡単に表現すると次のようになります。

クライアントはこのサーバーを、試行錯誤によって認識します。 クライアントは、自分のホームサーバーから始めて、正しいサーバーが見つかるまでサーバーを 1 台ずつ試していきます。サーバーがクライアントの要求に応じられない場合、サーバーは適切なサーバーの検索に役立つ情報をクライアントに送信します。やがて、クライアントは自分の情報キャッシュを構築し、適切なサーバーをより効率的に検索できるようになります。このプロセスの詳細を次に示します。

コールドスタートファイルとディレクトリキャッシュ

クライアントが初期設定されるとき、クライアントには「コールドスタートファイル」が与えられます。コールドスタートファイルの目的は、名前空間内のサーバーと連絡をとるための起点として使用できるディレクトリオブジェクトのコピーをクライアントに提供することです。ディレクトリオブジェクトには、アドレス、公開鍵、およびそのディレクトリをサポートするマスターサーバーと複製サーバーについての情報が収められています。通常、コールドスタートファイルには、クライアントのホームドメインのディレクトリオブジェクトが収められています。

コールドスタートファイルは、クライアントのローカルの「ディレクトリキャッシュ」を初期設定するためにだけ使用されます。ディレクトリキャッシュは、「キャッシュマネージャ」と呼ばれる NIS+ 機能によって管理されます。キャッシュマネージャには、クライアントが自身の要求を適切なサーバーに送信できるようにするためのディレクトリオブジェクトが格納されます。クライアントのコールドスタートファイルから取得された情報は、/var/nis 内の NIS_SHARED_DIRCACHE というファイルにダウンロードされます。

名前空間のディレクトリオブジェクトのコピーを自分のディレクトリキャッシュに格納することによって、クライアントは、どのサーバーがどのドメインをサポートするかを知ることができます。クライアントのキャッシュの内容を表示するには、nisshowcache コマンドを使用してください (「nisshowcache コマンド」を参照)。簡単な例を次に示します。

これらのコピーを最新の状態に保つため、各ディレクトリオブジェクトには「生存期間」フィールドがあります。このデフォルト値は 12 時間です。クライアントがディレクトリオブジェクトを求めてディレクトリキャッシュを調べ、最近の 12 時間以内にこれが更新されていないことを発見した場合、キャッシュマネージャはオブジェクトの新しいコピーを獲得します。「nischttl コマンド」で説明するように、ディレクトリオブジェクトの生存期間の値は、nischttl コマンドで変更できます。ただし、生存期間を長くするほどオブジェクトのコピーが古くなる可能性が高くなり、生存期間を短くするほどネットワークトラフィックとサーバーのロードが増加することに注意してください。

ディレクトリキャッシュは、これらのディレクトリオブジェクトをどうやって蓄積するのでしょうか。前に説明したように、コールドスタートファイルはキャッシュ内の最初のエントリを提供します。したがって、クライアントが最初の要求を送信するとき、コールドスタートファイルによって指定されたサーバーに要求を送信します。その要求がそのサーバーによってサポートされるドメインへのアクセスである場合、そのサーバーは要求に応答します。

その要求が別のドメイン (たとえば、sales.doc.com.) へのアクセスである場合、サーバーは、クライアントが適切なサーバーを探すのを助けようとします。サーバーが、自分のディレクトリキャッシュ内に該当するドメイン用のエントリを保有している場合、そのドメインのディレクトリオブジェクトのコピーをクライアントに送信します。クライアントは、その情報を今後の参照用として自分のディレクトリキャッシュにロードし、そのサーバーに要求を送信します。

ほとんどありえないことですが、クライアントがアクセスしようとしているディレクトリオブジェクトのコピーを、サーバーが保有していない場合、そのサーバーは、自分のホームドメインのディレクトリオブジェクトのコピーをクライアントに送信します。ここには、そのサーバーの親のアドレスが登録されています。クライアントは、親サーバーを使ってこのプロセスを繰り返し、適切なサーバーを見つけるか、または名前空間内の全サーバーを試し終わるまで、これを繰り返します。クライアントがドメイン内の全サーバーを試し終わった後でどうするかは、そのネームサービススイッチ構成ファイルの指示によって決まります。

やがてクライアントは、名前空間内のすべてのディレクトリオブジェクトのコピーをキャッシュ内に蓄積します。したがって、これらディレクトリオブジェクトをサポートするサーバーの IP アドレスも蓄積することになります。クライアントがほかのドメインへのアクセス要求を送信する必要があるとき、通常は、自分のディレクトリキャッシュの中から自分のサーバー名を見つけ、そのサーバーにアクセス要求を直接送信できます。

NIS+ サーバーはクライアントでもある

NIS+ サーバーは NIS+ クライアントでもあります。サーバーとして設定するマシンは、まずクライアントとして初期化する必要があります。唯一の例外はルートマスターサーバーであり、このサーバーには独自の設定を行う必要があります。

つまり、サーバーはドメインをサポートするだけではなく、ドメインにも「所属する」のです。つまり、クライアントになることによって、サーバーにはホームドメインがあるということです。サーバーのホスト情報は自分のホームドメインの hosts テーブルに格納され、その DES 資格は自分のホームドメインの cred テーブルに格納されます。ほかのクライアントと同様、サーバーは、自分のディレクトリキャッシュに記録されているサーバーに対して、サービス要求を送信します。

忘れてはならない重要な点は、ルートドメインを除いて、サーバーのホームドメインは、そのサーバーがサポートするドメインの「親」ドメインであるということです。

つまり、サーバーは 1 つのドメイン内のクライアントをサポートしますが、別のドメインの「クライアント」になるのです。ルートドメインを除いて、サーバーは自分のサポートするドメインのクライアントにはなれません。ルートドメインをサポートするサーバーには親ドメインがないため、これらはルートドメイン自体に所属します。

たとえば、次のような名前空間を考えてみます。

各サーバーがどのドメインをサポートし、どのドメインに所属するかを次に示します。

命名規則

NIS+ 名前空間内のオブジェクトは、「部分指定」および「完全指定」の 2 種類の名前によって識別できます。 部分指定名は、「単純」名とも呼ばれ、オブジェクト名だけまたは完全指定名の一部です。管理操作中にオブジェクトまたは主体の部分指定名を入力すると、NIS+ によってその名前は完全指定名に展開されます。詳細については、「命名規則」を参照してください。

完全指定名とは、名前空間内でオブジェクトを探すために必要なすべての情報を含んだオブジェクトの完全な名前です。必要なすべての情報とはオブジェクトの親ディレクトリ (もしあれば)、最後のドットも含んだ完全なドメイン名などです。

これはオブジェクトの種類によって異なるため、各タイプと NIS+ の主体ごとの規則を別個に説明します。次の名前空間を例として使用します。

NIS+ の主体を含む、この名前空間内の全オブジェクトの完全指定名を次の図に要約します。

図 2–4 名前空間の構成要素の完全指定名

NIS+ ドメイン名

完全指定ドメイン名は左から右に作成され、ローカルドメインで始まってルートドメインで終わります。

doc.com. (ルートドメイン)

sales.doc.com. (サブドメイン)

intl.sales.doc.com. (第 3 レベルのサブドメイン)

最初の行はルートドメインの名前を示します。ルートドメインは、少なくとも 2 つのラベルを持ち、ドットで終わらなければなりません。最後 (右端) のラベルは自由につけられますが、インターネット上の互換性を維持するためには、以下に示すインターネットの組織名、または 2、3 文字の地域識別子 (日本であれば .jp) をつける必要があります。

上の 2 行目と 3 行目は下位レベルドメインの名前です。

ディレクトリオブジェクト名

ディレクトリの単純名は、単にディレクトリオブジェクトの名前です。この完全指定名は、単純名にそのドメインの完全指定名を加えたものです (常に最後のドットを含む)。

groups_dir (単純名)

groups_dir.manf.doc.com. (完全指定名)

複数のディレクトリ層が 1 つのドメインを形成しないような変則的な階層を設定する場合、中間ディレクトリ名を含めるようにしてください。たとえば、以下のようになります。

lowest_dir.lower_dir.low_dir.mydomain.com.

通常単純名は、同じドメイン内から使用され、完全指定名は、リモートドメインから使用されます。ただし、ドメインの NIS_PATH 環境変数に検索パスを指定することによって、リモートドメインから単純名を使用できます (「環境変数 NIS_PATH」を参照)。

テーブルおよびグループ名

完全指定されたテーブル名とグループ名は、オブジェクト名から始まり、ディレクトリ名をつけ、その後に完全指定されたドメイン名が続いて作られます。すべてのシステムテーブルオブジェクトは org_dir ディレクトリに格納されて、すべてのグループオブジェクトは groups_dir ディレクトリに格納されていることを忘れないでください。独自の NIS+ テーブルを作成した場合は、どこでも好きなところに格納できます。グループ名とテーブル名の例を次に示します。

admin.groups_dir.doc.com.	
admin.groups_dir.doc.com. 
admin.groups_dir.sales.doc.com. 
admin.groups_dir.sales.doc.com. 
hosts.org_dir.doc.com.	
hosts.org_dir.doc.com. 
hosts.org_dir.sales.doc.com.	
hosts.org_dir.sales.doc.com.

テーブルエントリ名

NIS+ テーブル内のエントリを識別するには、その中にあるエントリとテーブルオブジェクトを識別する必要があります。このような名前を「インデックス付き」名と呼びます。この構文を次に示します。

[column=value,column=value,...],tablename

Column はテーブル列の名前です。Value はその列の実際の値です。Tablename は、テーブルオブジェクトの完全指定名です。hosts テーブルのエントリ例を次に示します。

[addr=129.44.2.1,name=pine],hosts.org_dir.sales.doc.com. 
[addr=129.44.2.2,name=elm],hosts.org_dir.sales.doc.com. 
[addr=129.44.2.3,name=oak],hosts.org_dir.sales.doc.com.

括弧の中には、テーブルエントリを一意に識別するために必要な最小限の列の値のペアを使用できます。

一部の NIS+ 管理コマンドは、この構文のバリエーションを利用できます。詳細は、パート II「NIS+ の紹介と概要」の nistbladm、nismatch、nisgrep の各コマンドの説明を参照してください。

ホスト名

ホスト名の長さは 24 文字までで、使用できるのは文字、数字、ダッシュ (-)、および下線 (_) です。大文字と小文字の区別はありません。また先頭は英文字とします。スペースは使用できません。

ドット (.) はホスト名には使用できません。たとえば、ホスト名には doc.2 などは使用できません。また、引用符で囲んだドットも、ホスト名には使用できません。たとえば、`doc.2' は使用できません。ドメイン構成要素を識別するために、完全指定ホスト名の一部として使用する場合にのみ、ドットを使用します。たとえば、doc-2.sales.doc.com. は、正しい完全指定のホスト名です。

またドメイン名とホスト名が同じにならないようにします。たとえば、sales ドメインがある場合は、ホスト名に sales を使用することはできません。同様に、home というホスト名がある場合には、ドメイン名に home を使用できません。これは、サブドメインについても同様です。たとえば、すでにホスト名として west がある場合には、sales.west.doc.com というサブドメインを作成することはできません。

NIS+ の主体名

NIS+ の主体名は、Secure RPC のネット名とよく混同することがあります。念のためここで 1 つだけ違いを指摘しておきます。NIS+ の主体名は必ずドットで終わりますが、Secure RPC のネット名はドットで終わることは決してありません。以下に、例を示します。

NIS+ の主体名

olivia.sales.doc.com.

Secure RPC netname

unix.olivia@sales.doc.com

また、たとえ主体の資格が cred テーブルに格納されていても、cred テーブル名も org_dir ディレクトリ名も主体名には含まれません。

使用できる記号

名前空間名は、ISO ラテン 1 セットの印刷可能文字を自由に使用して作成できます。ただし、名前の先頭には次に示す文字は使用できません。@ < > + [ ] - / = . , : ;

文字列を使用するには、二重引用符で囲みます。名前の中に引用符を使用するには、その記号も引用符で囲みます (たとえば、o'henry を使用するには o”'”henry と入力します)。John Smith などのように空白スペースを組み込むには、次のように一重引用符の中で二重引用符を使用します。

`”John Smith”`

ホスト名に適用される制限については、「ホスト名」を参照してください。

NIS+ の名前展開

NIS+ のコマンドで完全指定名を入力することは面倒です。この作業を簡単にするため、NIS+ は名前展開機能を提供します。部分指定名が入力されると、NIS+ は別のディレクトリのもとでこのオブジェクトを見つけようと試みます。最初は、デフォルトドメインから探します。これは、このコマンドを入力したクライアントのホームドメインです。デフォルトドメインでオブジェクトが見つからなかった場合、このオブジェクトが見つかるまで、NIS+ はデフォルトドメインの親ディレクトリを下から上へ探していきます。2 つのラベルしかない名前に到達すると、検索を停止します。次にその例を示します。この例では、software.big.sales.doc.com. ドメインに所属するクライアントにログインしたと仮定します。

環境変数 NIS_PATH

環境変数 NIS_PATH の値を変更することによって、NIS+ が検索するディレクトリのリストを変更または拡張できます。NIS_PATH には、コロンで区切って複数のディレクトリ名を設定できます。次に例を示します。

setenv NIS_PATH directory1: directory2: directory3 ...

または

NIS_PATH=directory1:  directory2: directory3 ...;export NIS_PATH

NIS+ は、これらのディレクトリを左から右へ検索していきます。たとえば、以下のようになります。

$PATH や $MANPATH のように、変数 NIS_PATH には特殊記号 $ を使用できます。$ 記号は、ディレクトリ名に追加するか、または単独で追加できます。ディレクトリ名に追加した場合、NIS+ はその名前にデフォルトディレクトリを追加します。たとえば、以下のようになります。

$ 記号を単独で使用する (たとえば、org_dir.$:$) 場合、NIS+ は前述のような標準の名前展開を実行します。つまり、デフォルトディレクトリの検索から始め、親ディレクトリへと進めていきます。NIS_PATH のデフォルト値は $ です。

NIS_PATH に追加や変更を加えると、NIS+ がより多くの検索を行わなければならないので、性能が低下するという点に注意してください。

名前空間がすでに存在する場合の設定

NIS ドメインが NIS 名前空間にすでに存在する場合は、そのドメインを NIS+ 名前空間に同じフラット構造で移行できます。移行したドメインは、あとで階層構造に変更できます。 NIS から NIS+ への移行を始める前に、計画および準備に関する重要な情報について、『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』の「スクリプトを使用した NIS+ の設定」を参照してください。NIS+ のスクリプトを使用すると、NIS マップのデータを利用して簡単に NIS+ を起動できます。第 4 章「スクリプトを使用した NIS+ の設定」で、NIS+ スクリプトを使用してシステムファイルや NIS マップから NIS+ 名前空間を作成する方法を説明します。

ただし、名前空間がすでに存在している場合、スクリプトをスムーズに実行するため NIS+ への移行用の設定が必要です。

準備に関する主な注意事項は次のとおりです。

• 「ドメイン名とホスト名」。ドメイン名とホスト名は、同じにならないようにする必要があります。たとえば、sales ドメインがある場合は、ホスト名に sales を使用することはできません。同様に、home というホスト名がある場合には、ドメイン名に home を使用できません。これはサブドメインの場合も同様です。たとえば、マシンに west という名前を付けている場合、sales.west.doc.com というサブディレクトリを作成しないでください。

• 「ホスト名にはドットを使用しない」。NIS+ では、マシン名とドメイン名の間や、親とサブドメインの間の区切りにドット (ピリオド) を使用します。このため、マシン名の中ではドットを使用できません。使用している場合は、NIS+ に移行する前に (スクリプトを実行する前に) 必ず変更してください。ホスト名中のドットは、ハイフンに置き換えます。たとえば、sales.alpha というマシン名を付けることはできません。この名前は、sales-alpha に置き換えることができます (使用可能なホスト名の詳細については、 hosts のマニュアルページを参照してください)。

• 「ルートサーバーが動作していることを確認する」。ルートサーバーになるマシンが起動されていることを確認します。また、スーパーユーザーとしてアクセスできることも確認します。

• データのロード元のローカル /etc ファイル、または NIS マップのエントリを確認する。不正なエントリがないことを確認します。正しいデータが、所定の場所に正しい書式で記録されていることを確認します。エントリのうち、古いもの、無効なもの、破損しているものは削除します。また、不完全なエントリや一部のみのエントリも削除します。構成完了後は、いつでもエントリを追加できます。必要なエントリをあとから追加する方が、不完全なエントリや破損しているエントリを読み込もうとするよりも簡単です。

Solaris 2.4 以前では、 /var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルが含まれていました。また、/var/nis/hostname というサブディレクトリも含まれていました。Solaris 2.5 で NIS+ をインストールした場合、2 つのファイル名は trans.log、data.dict、サブディレクトリ名は /var/nis/data となります。Solaris 2.5 ではこれらのファイルの内容も変更されており、Solaris 2.4 以前との互換性はなくなっています。したがって、これらのファイルやディレクトリを Solaris 2.4 での名前にしてしまうと、Solaris 2.4、2.5 双方の rpc.nisd で機能しなくなります。ディレクトリ名もファイル名も変更しないでください。

2 通りの構成方法

ここでは、NIS+ 名前空間の 2 通りの構成方法を紹介します。

• 「設定 (構成) 用のスクリプトを使う方法」。nisserver、 nispopulate、および nisclient という 3 つの NIS+ スクリプトを使用して NIS+ を構成する方法については、この章と第 4 章「スクリプトを使用した NIS+ の設定」で説明しています。 簡単に済ませることができるため、こちらの方法をお勧めします。

• 「NIS+ コマンドを使う方法」。NIS+ コマンドを使用して NIS+ を構成する方法については、第 6 章「NIS+ クライアントの構成」、第 7 章「NIS+ サーバーの構成」、および第 8 章「ルート以外のドメインの構成」で説明します。NIS+ コマンドを使用すれば、NIS+ スクリプトより柔軟に構成できますが、複雑になります。NIS+ コマンドは、NIS+ スクリプトによって生成される名前空間と特性が大きく異なる名前空間を構成する必要があるときに、経験豊富な NIS+ 管理者だけが使用してください。

NIS+ コマンドセットを使用する場合は、ネームサービスに NIS+ を使用する各マシンの /etc ディレクトリに正しい nsswitch.conf ファイルが存在することも確認してください (第 1 章「ネームサービススイッチ」を参照)。この作業は、NIS+ 構成スクリプトを使った場合は自動的に行われます。

NIS+ ディレクトリまたはドメイン、NIS+ サーバー、あるいは NIS+ 名前空間の削除方法については第 22 章「NIS+ の削除」を参照してください。

第 3 章 NIS+ 設定スクリプト

この章では、NIS+ スクリプトとその機能について説明します。

NIS+ は、将来のリリースではサポートされなくなる可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 リリース以降で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ スクリプトについて

必ず「NIS+ 設定の概要」の手順を実行してから、NIS+ スクリプトを実行してください。

3 つの NIS+ スクリプト nisserver、nispopulate、nisclient を使用すれば、NIS+ 名前空間を設定できます。NIS+ スクリプトは NIS+ コマンド群を実行する Bourne シェルスクリプトであり、NIS+ コマンドを個別に入力する必要はありません。次の表に、各スクリプトの機能を示します。

NIS+ スクリプトで実行すること

NIS+ スクリプトといくつかの NIS+ コマンドと組み合わせることで、NIS+ 名前空間の設定に必要な作業を実行できます。NIS+ スクリプトとそのオプションについての詳しい説明は、nisserver(1M)、nispopulate(1M)、nisclient(1M) のマニュアルページを参照してください。第 4 章「スクリプトを使用した NIS+ の設定」では、NIS+ スクリプトを使用した NIS+ 名前空間の設定方法について説明しています。

-x オプションを使用して、コマンドを実際に実行せずに各スクリプトを実行できます。このオプションを使用すると、スクリプトが呼び出すコマンドとおおよその結果をシステムを変更せずに確認できます。-x オプションを使用してスクリプトを実行することで、予想外の結果を最小限にできます。

NIS+ スクリプトでは実行しないこと

NIS+ スクリプトを使用すれば NIS+ 名前空間の作成に必要な作業が軽減されるとはいえ、スクリプトですべての NIS+ コマンドを代行できるわけではありません。スクリプトは、NIS+ の一部の機能を提供するだけです。NIS+ にまだ慣れていない場合、NIS+ 名前空間のサンプルを作成してからこの節を読むこともできます。

nisserver スクリプトは、標準のテーブルとアクセス権 (承認) で NIS+ サーバーを設定するだけです。このスクリプトでは次のことは実行しません。

• テーブルとディレクトリに特別なアクセス権を設定する

• NIS+ 管理グループへ NIS+ 主体を追加する

  NIS+ スクリプトではなく nisgrpadm コマンドを使用して、NIS+ 管理グループに特別な NIS+ 主体を追加する方法については、第 4 章「スクリプトを使用した NIS+ の設定」を参照してください。

• 独自のテーブルを作成する

• レベル 2 以外の任意のセキュリティレベルで NIS+ サーバーを実行する

• リモートサーバーで rpc.nisd デーモンを起動する。この作業は、サーバーのインストールを完了するために必要

NIS+ スクリプトではなく rpc.nisd コマンドを使用して、NIS+ クライアントマシンをルート以外のサーバーに変更する方法については、第 4 章「スクリプトを使用した NIS+ の設定」を参照してください。

nisclient スクリプトは、DNS を使用してホスト名を検索するように NIS+ クライアントを設定することはありません。この設定を必要とするクライアントの場合、DNS を明確に設定しなければなりません。

第 4 章 スクリプトを使用した NIS+ の設定

この章では、nisserver、nispopulate、nisclient の各スクリプトと NIS+ コマンドを組み合わせて、基本的な NIS+ 名前空間を構成する方法について説明します。

NIS+ は、将来のリリースではサポートされなくなる可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 リリース以降で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ 設定の概要

NIS+ 名前空間の設定と構成には、スクリプトを使用する方法をお勧めします。これらのスクリプトを使用すると、NIS+ コマンドセットを使用する場合よりも簡単に NIS+ 名前空間を設定できます。第 6 章「NIS+ クライアントの構成」、第 7 章「NIS+ サーバーの構成」、および第 8 章「ルート以外のドメインの構成」を参照してください。

スクリプトの詳細は、nisserver(1M)、nispopulate(1M)、nisclient(1M) の各マニュアルページを参照してください。用語や略語の定義については、用語集を参照してください。

このチュートリアルで説明するサンプルの小さな NIS+ 名前空間を土台にして実際の NIS+ 名前空間を作ることはしないでください。名前空間についてひととおり理解できたら、サンプルの名前空間は削除してください。サンプルの名前空間に実際の名前空間を追加しないでください。あらためて、初めから NIS+ 階層の計画を注意深く立ててから、実際の名前空間を作成してください。

一般に推奨される設定手順を表 4–1 に要約します。左端の列には、ルートドメインの構成やクライアントの作成などの主な設定作業を示します。中央の列は、作業の説明です。3 番目の列は、各手順に必要なスクリプトまたはコマンドです。

NIS+ スクリプトを使用することによって、上の作業で示される個々の手順の大部分を省略できます。

NIS+ とサービス管理機能

NIS+ サービスに関連したコマンド行管理タスクのほとんどは、サービス管理機能 (SMF) によって管理されます。SMF の概要については、『Solaris のシステム管理 (基本編)』の「サービスの管理 (概要)」を参照してください。詳細については、svcadm(1M) と svcs(1) の各マニュアルページも参照してください。

• NIS+ サービスに対する有効化、無効化、再起動などの管理操作を実行するには、svcadm コマンドを使用します。サービスを起動または停止すると、依存するプロセスもすべて起動または停止します。

  ---

  ヒント –

  -t オプションを使ってサービスを一時的に無効にすると、サービス構成の一部を保護できます。-t オプションを使ってサービスを無効にした場合は、再起動後にサービスの元の設定が復元されます。-t オプションを使わずにサービスを無効にした場合は、再起動後もサービスは引き続き無効になります。

  ---

• SMF では、/var/nis/NIS_COLD_START ファイルが検出されると、NIS+ サービスを有効にしたときに nis_cachemgr が自動的に起動されます。

• NIS+ の FMRI (Fault Managed Resource Identifier) は svc:/network/rpc/nisplus:<instance> です。

• keyserv の FMRI は svc:/network/rpc/keyserv:<instance> です。

• NIS+ の状態を問い合わせるには、svcs コマンドを使用します。

  • svcs コマンドと出力の例を次に示します。

    # svcs \*nisplus\* STATE STIME FMRI disabled Sep_01 svc:/network/rpc/nisplus:default

  • svcs -l コマンドと出力の例を次に示します。

    # svcs -l network/rpc/nisplus fmri svc:/network/rpc/nisplus:default enabled false state disabled next_state none restarter svc:/system/svc/restarter:default dependency require_all/none svc:/network/rpc/keyserv (online)

    また、svccfg ユーティリティを使用すれば、サービスに関する詳細な情報を取得できます。svccfg(1M) のマニュアルページを参照してください。

• デーモンが存在するかどうかを確認するには、ps コマンドを使用します。

  # ps -e | grep rpc.nisd

  ---

  注 –

  -f オプションは ps とともに使わないでください。このオプションはユーザー ID を名前に変換しようとするため、より多くのネームサービスの検索が失敗する可能性があります。

  ---

svcadm を rpc.nisd -x とともに使用する

一般に、/usr/sbin/rpc.nisd デーモンは svcadm コマンドを使って管理します。ただし、rpc.nisd が -x nisplusLDAPinitialUpdateOnly=yes を使って呼び出された場合、rpc.nisd は指定された操作を実行して、終了します。つまり、rpc.nisd はデーモンとして動作しません。SMF は -x nisplusLDAPinitialUpdateOnly=yes とともに使用しません。SMF は、それ以外で rpc.nisd デーモンを起動、停止、または再起動する場合にいつでも使用できます。

rpc.nisd を -x nisplusLDAPinitialUpdateOnly=yes で使用する例を次に示します。

# /usr/sbin/rpc.nisd -m mappingfile \
-x nisplusLDAPinitialUpdateAction=from_ldap \
-x nisplusLDAPinitialUpdateOnly=yes

/lib/svc/method/nisplus ファイルの変更

SMF を使って rpc.nisd デーモンを呼び出すときに特定のオプションを指定する場合は、そのオプションを /lib/svc/method/nisplus ファイルに追加します。次に、よく使われるオプションをいくつか示します。

/lib/svc/method/nisplus ファイルの変更方法

1. スーパーユーザーになるか、同等の役割になります。

   役割には、承認と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「役割に基づくアクセス制御の使用 (作業)」を参照してください。

2. NIS+ サービスを停止します。

   # svcadm disable network/rpc/nisplus:default

3. /lib/svc/method/nisplus ファイルを開きます。

   適切なテキストエディタを使用します。

4. ファイルを編集して必要なオプションを追加します。

   例 —

   変更前:

   /usr/sbin/rpc.nisd $nisd_flags || exit $?

   変更後:

   /usr/sbin/rpc.nisd $nisd_flags -Y -B || exit $?

   この例では、-Y および -B オプションが rpc.nisd に追加され、起動時に自動的に実装されます。

5. 保存して終了します。

6. NIS+ サービスを開始します。

   # svcadm enable network/rpc/nisplus:default

NIS+ 名前空間サンプルの作成

この章では、サンプルの NIS+ 名前空間を作成する方法を説明します。NIS+ 名前空間のサンプルは、/etc 内のファイルと NIS マップから作成されます。このサンプルでは、サイトで NIS を実行している場合と実行していない場合の両方について、スクリプトの使用方法を説明します。サーバーが NIS クライアントにサービスを提供する場合、サーバーを NIS 互換モードに設定できます。NIS 互換モードの詳細については、「Solaris 1.x と NIS 互換モード」を参照してください。

サイトの実際の NIS+ 名前空間とそのドメイン階層は、名前空間サンプルのものとはおそらく異なり、サーバー、クライアント、およびドメインの数も異なります。最終的なドメイン構成と階層は、このサンプルと異なるものと考えてください。この名前空間サンプルは、NIS+ スクリプトの使用法を説明するためだけのものです。この名前空間サンプルを作成すると、自分のサイトでのドメイン、サーバー、およびクライアントの作成方法も理解できるはずです。

名前空間サンプルには次の構成要素があります。

• ルートマスターサーバー 1 台 (名称 master、doc.com. ドメイン用)

• ルートドメイン (doc.com.) のクライアント 4 台

  • client1 は、ルート複製サーバーとなる (doc.com. ドメイン用)

  • client2 は、新しいサブドメインのマスターサーバーとなる (sub.doc.com. ドメイン用)

  • client3 は、新しいサブドメインのルート以外の複製サーバーとなる (sub.doc.com. ドメイン用)

  • client4 は、ルートドメインのクライアントとして残る (doc.com. ドメイン用)

• サブドメインの 2 台のクライアント (名称 subclient1 および subclient2、sub.doc.com. ドメイン用)

ここでは、/etc/hosts などのシステム情報ファイルと NIS マップの両方を使用してネットワークサービス情報を格納するサイトで、NIS+ の設定に使用されるスクリプトを説明します。NIS+ 名前空間サンプルでこのような混合型のサイトを使用するのは、単にサンプルとして示すことが目的です。

NIS+ スクリプトのコマンド行の要約

表 4–2 に、NIS+ ドメインのサンプルを作成するときの、NIS+ スクリプトとコマンドの汎用的な手順を示します。このあとの節ではこれらのコマンド行について詳しく説明します。NIS+ のドメイン、サーバー、およびクライアントの作成に必要な作業に習熟した後、表 4–2 はコマンド行のクイックリファレンスガイドとして使用してください。表 4–2 は、NIS+ 名前空間サンプルを作成するために実際に入力するコマンドと変数をまとめたものです。

実際にコマンドを実行させないで、しかも NIS+ スクリプトがどんなコマンドを呼び出すかを表示するには、-x オプションを使います。-x オプションによって、あたかも実際にスクリプトを実行しているかのように、それらのコマンド名とそれぞれのおおよその出力を画面に表示できます。最初に -x を指定してスクリプトを実行すれば、結果を先に見ることができます。詳細は各スクリプトのマニュアルページを参照してください。

NIS+ ルートサーバーの設定

NIS+ ドメインを設定するための最初の作業が、ルートマスターサーバーの設定です。この節では、nisserver スクリプトを使用してデフォルト設定でルートマスターサーバーを構成する方法を説明します。ルートマスターサーバーは、次のデフォルトを使用します。

• セキュリティレベル 2 (DES) - NIS+ セキュリティの最高レベル

• NIS 互換を OFF に設定 (NIS 互換に設定する方法も記述)

• ネームサービス情報の情報源としてシステム情報ファイル (/etc) または NIS マップ

• NIS+ グループとして admin. domainname

nisserver スクリプトは、ルートマスターサーバーを設定するときに、ネームサービススイッチファイルを NIS+ 用に変更します。/etc/nsswitch.conf ファイルは後で変更できます。ネームサービススイッチについては、第 1 章「ネームサービススイッチ」を参照してください。

nisserver を実行してルートサーバーを設定するための前提条件

ルートマスターサーバーにしたいマシンの /etc/passwd ファイルに root のエントリがあるかどうかを確認します。

nisserver を実行する前に、次の情報が必要になります。

• マシン (ルートマスターサーバーにする) のスーパーユーザーのパスワード

• 新しいルートドメイン名。ルートドメイン名は少なくとも 2 つの要素 (ラベル) で構成され、その末尾にドット (ピリオド) が打たれていなければならない (例: something.com)。最後 (右端) のラベルは自由につけられますが、インターネット上の互換性を維持するためには、表 4–3 に示されるようなインターネットの組織名、または 2、3 文字の地域識別子 (日本であれば .jp) をつける必要があります。

次の例では、ルートマスターサーバーに指定するマシンは master1 で、doc.com. が新しいルートドメインになります。

またドメイン名とホスト名が同じにならないようにします。たとえば、ルートドメインに doc.com. という名前を付けている場合、ドメイン内で使用するマシンには doc という名前は付けないでください。同様に、home というホスト名がある場合には、ドメイン名に home を使用できません。これは、サブドメインについても同様です。たとえば、すでにホスト名として west がある場合には、sales.west.doc.com というサブドメインを作成することはできません。

ルートマスターサーバーを作成する方法

1. スーパーユーザーの PATH 変数に /usr/lib/nis を追加します。

   このパスを root の .cshrc または .profile ファイルに追加するか、または変数を直接設定します。

2. DES 認証を使用する場合には、オプションで、Diffie-Hellman キー長を指定します。

   640 ビットの Diffie-Hellman キーとデフォルトの 192 ビットのキーを使用するには、以下を入力します。

   nisauthconf dh640-0 des

   640 ビットのキーだけを許可し、192 ビットのキーを拒否するには、以下を入力します。

   nisauthconf dh640-0

3. 次のコマンドをスーパーユーザー (root) として入力し、ルートマスターサーバーを構成します。

   -r オプションはルートマスターサーバーを構成することを示します。-d オプションは NIS+ ドメイン名を指定します。

   master1# nisserver -r -d doc.com. This script sets up this machine “master1” as a NIS+ root master server for domain doc.com. Domain name : doc.com. NIS+ group : admin.doc.com. NIS (YP) compatibility : OFF Security level : 2=DES Is this information correct? (type 'y' to accept, 'n' to change)

   「NIS+ グループ」は、doc.com. ドメイン (ドメイン名は常にピリオドで終了する) の情報を変更する権限を持つユーザーのグループです。 NIS+ グループは、ドメインを削除することもできます。NIS+ グループのデフォルト名は、admin.domainname です。この名前の変更方法については、「誤った情報を変更する方法」を参照してください。

   「NIS 互換」とは、NIS+ サーバーが NIS クライアントからの情報要求を受け付けるかどうかを意味します。デフォルト設定の OFF に設定されている場合、NIS+ サーバーは NIS クライアントからの要求を処理しません。ON に設定されている場合、NIS+ サーバーはこの要求を処理します。このスクリプトでは、NIS 互換設定を変更できます。「誤った情報を変更する方法」を参照してください。

   ---

   注 –

   このスクリプトは、マシンを NIS+ セキュリティの最高レベルであるセキュリティレベル 2 で設定します。このスクリプトを使用する場合、セキュリティレベルを変更できません。スクリプトが終了した後、適切な NIS+ コマンドでセキュリティレベルを変更できます。セキュリティレベルの変更の詳細については、rpc.nisd のマニュアルページを参照してください。

   ---

4. y を入力します (画面の情報が正しい場合)。

   n を入力すると、スクリプトは正しい情報の入力を要求します。n を入力した場合の操作については、「誤った情報を変更する方法」を参照してください。

   Is this information correct? (type 'y' to accept, 'n'' to change) y This script will set up your machine as a root master server for domain doc.com. without NIS compatibility at security level 2. Use "nisclient -r" to restore your current network service environment. Do you want to continue? (type `y' to continue, `n' to exit the script)

5. y を入力して、NIS+ の構成を続けます。

   n を入力するとスクリプトは問題なく終了します。y を選んだ後でスクリプトの実行中にスクリプトを中断した場合、スクリプトは動作を停止し、それまでに作成された構成内容はそのまま残されます。スクリプトは自動回復や後始末は行いません。このスクリプトはいつでも再実行できます。

   Do you want to continue? (type 'y' to continue, 'n' to exit the script y setting up domain information “doc.com.” ... setting up switch information ... running nisinit ... This machine is in the doc.com. NIS+ domain. Setting up root server ... All done. starting root server at security level 0 to create credentials... running nissetup ... (creating standard directories & tables) org_dir.doc.com. created Enter login password:

   nissetup(1M) コマンドは、各 NIS+ テーブルのディレクトリを作成します。

6. プロンプトに対してマシンの root パスワードを入力し、Return キーを押します。

   この例の場合、ユーザーは master1 マシンの root パスワードを入力しています。

   Wrote secret key into /etc/.rootkey setting NIS+ group to admin.doc.com. ... restarting root server at security level 2 ... This system is now configured as a root server for domain doc.com. You can now populate the standard NIS+ tables by using the nispopulate or /usr/lib/nis/nisaddent commands.

   これでルートマスターサーバーが構成され、NIS+ の標準テーブルを生成する用意が整いました。続けてテーブルを生成する場合は、「NIS+ テーブルの生成 (populate)」に進みます。

誤った情報を変更する方法

上記の手順 4 で返された情報の一部あるいは全部が誤っていたために n を入力した場合、次のように表示されます。

Is this information correct? (type 'y' to accept, 'n' to change)
 n
Domain name: [doc.com.]

1. ドメイン名が正しい場合は Return キーを押します。誤っている場合は、正しいドメイン名を入力して Return キーを押します。

   この例では、Return キーを押して、目的のドメイン名が doc.com. であることを確定しました。次に、このスクリプトは NIS+ グループ名の確認を要求します。

   Is this information correct? (type 'y' to accept, 'n' to change) n Domain name: [doc.com.] NIS+ group: [admin.doc.com.]

2. NIS+ グループが正しければ Return キーを押します。間違っている場合、正しい NIS+ グループ名を入力して Return キーを押します。

   この例では、名前を変更しました。次に、スクリプトは NIS 互換性の入力を要求します。

   NIS+ group: [admin.doc.com.] netadmin.doc.com. NIS (YP) compatibility (0=off, 1=on): [0]

3. NIS 互換性を必要としない場合は Return キーを押します。互換性が必要な場合は 1 を入力して Return キーを押します。

   この例では、Return キーを押して、NIS 互換の状態が正しいことを確認しました。スクリプトは、情報が正しいかどうかを再度尋ねてきます。

   ---

   注 –

   このサーバーを NIS 互換に選択した場合、この選択を有効にするには、ファイルを編集して、rpc.nisd デーモンを再起動する必要があります。詳細については、「クライアントを NIS+ サーバーとして構成する方法」を参照してください。

   ---

   NIS (YP) compatibility (0=off, 1=on): [0] Domain name : doc.com. NIS+ group : netadmin.doc.com. NIS (YP) compatibility : OFF Security level : 2=DES Is this information correct? (type 'y' to accept, 'n' to change)

   情報が正しい場合、「ルートマスターサーバーを作成する方法」の手順 3 に移ります。正しい情報となるまで、n を繰り返し選択できます。

Multihomed NIS+ ルートマスターサーバーの設定方法

Multihomed NIS+ サーバーを設定する手順は、単一インタフェースサーバーの設定手順と同じです。唯一の相違点は、ローカルの /etc/hosts ファイル、/etc/inet/ipnodesファイルと NIS+ の hosts テーブルおよび ipnodes テーブル内に定義する必要があるインタフェースが、単一インタフェースサーバーよりも多いという点です。ホスト情報を定義したら、nisclient と nisserver スクリプトを使用して Multihomed NIS+ サーバーを設定します。Multihomed 複製サーバーの設定の詳細は、「Multihomed NIS+ 複製サーバーの設定方法」を参照してください。

Multihomed NIS+ サーバーを設定する場合は、サーバーの主体名はシステムのノード名と同じにする必要があります。これは、Secured RPC と nisclient を同時に使用する際の必要条件です。

• Secured RPC は、ノード名を使用して認証に必要なネット名を作成する

• nisclient は、主体名を使用してクライアントの資格を作成する

次に、NIS+ ルートマスターサーバーの設定手順を示します。

1. ルートマスター上で、サーバーのホスト情報を /etc/hosts ファイルまたは /etc/inet/ipnodes ファイル内に追加します。

   たとえば、3 つの Ethernet インタフェースを装備した hostA システムの場合、/etc/hosts ファイルには次のように入力します。

   127.0.0.1 localhost loghost 192.168.10.x hostA hostA-10 hostA-eri0 192.168.11.y hostA hostA-11 hostA-eri1 192.168.12.z hostA hostA-12

2. nisserver を使用して、サーバーを multihomed NIS+ ルートサーバーとして設定します。

   hostA# nisserver -r -d sun.com

   上記の例では、sun.com はルートドメイン名を表しています。ルートドメイン名を指定して nisserver コマンドを実行してください。

   multihomed NIS+ ルートサーバーの設定が完了したら、このあとの設定手順は、単一インタフェースサーバーの設定手順とまったく同じです。

NIS+ テーブルの生成 (populate)

ルートマスターサーバーの構成が終了すると、ほかのネットワークサービスの情報から標準の NIS+ テーブルを生成できます。この節では、nispopulate(1M) スクリプトをデフォルトの設定で使用して、ファイルまたは NIS マップのデータからルートマスターサーバーのテーブルを生成する方法を説明します。このスクリプトは次のものを使用します。

• 前の例で作成されたドメイン (doc.com. )

• ネットワークサービスのソースとしてシステム情報ファイルまたは NIS マップ

• 標準の NIS+ テーブル: auto_master、auto_home、ethers、group、 hosts、networks、passwd、protocols、services、rpc、netmasks、 bootparams、netgroup および aliases

テーブルの情報源がファイルである場合、shadow ファイルの内容が passwd ファイルの内容とマージされて passwd テーブルが作成されます。shadow テーブルは作成されません。

nispopulate を実行してルートサーバーテーブルを生成するための前提条件

nispopulate スクリプトを実行するには、次の条件を満たしている必要があります。

• データを読み込むローカルの /etc 内の各ファイルまたは NIS マップを表示します。不正なエントリがないことを確認します。正しいデータが、所定の場所に正しい書式で記録されていることを確認します。エントリのうち、古いもの、無効なもの、破損しているものは削除します。また、不完全なエントリや一部のみのエントリも削除します。構成完了後は、いつでもエントリを追加できます。必要なエントリをあとから追加する方が、不完全なエントリや破損しているエントリを読み込もうとするよりも簡単です。

• ファイル内の情報は、ロード先のテーブルに合った書式で書かれていなければなりません。対応する NIS+ テーブルに変換するときに使用するテキストファイルの書式については、第 9 章「NIS+ テーブルの設定」を参照してください。

• ドメイン名とホスト名が同一でないことを確認します。ドメインとホストで同じ名前は使用しないでください。たとえば、sales ドメインがある場合は、ホスト名に sales を使用することはできません。同様に、home というホスト名がある場合には、ドメイン名に home を使用できません。これは、サブドメインについても同様です。たとえば、マシンに west という名前を付けている場合、sales.west.doc.com というサブドメインを作成しないでください。

• ホスト名のドットと下線はすべて削除します。NIS+ では、ドット (ピリオド) をマシン名とドメインの間、および親ドメインとサブドメインの間の区切りに使用するため、ドットをマシン名に使うことはできません。DNS ではホスト名に下線を使うことを認めていませんので、ホスト名に下線を使うことはできません。nispopulate スクリプトを実行する前に、ホスト名で使用されているドットを必ず削除してください。ドットをハイフンに置き換えるのも 1 つの手です。たとえば、sales.alpha というマシン名を付けることはできません。この名前は、sales-alpha に置き換えることができます (使用可能なホスト名の詳細については、 hosts のマニュアルページを参照してください)。

• ネットワークをはじめて設定する場合、多くのネットワーク情報をすでにどこかに格納しているということはおそらくないでしょう。このような場合、まずネットワーク情報を集め、「入力ファイル」に手入力する必要があります。 このファイルは、基本的に /etc 内のファイルに対応するものです。

• 安全のため、/etc 内のファイルのコピーを作成します。実際のファイルは使用せずに、作成したコピーを使用してテーブルを生成してください。たとえば、この例では /nisplusfiles というディレクトリ内のファイルを使用します。

• コピーした NIS テーブルファイルのうち、passwd、shadow、aliases、hosts の各ファイルには、名前空間全体に分散させるとセキュリティ上問題がある項目があるので、それらを編集します。たとえば、次に示す行をローカル側の passwd ファイルのコピーから削除して、名前空間からはそれらの情報にアクセスできないようにします。

  root:x:0:1:0000-Admin(0000):/:/sbin/sh daemon:x:1:3:0000-Admin(0000):/: bin:x:3:5:0000-Admin(0000):/usr/bin: sys:x:3:3:0000-Admin(0000):/: adm:x:4:4:0000-Admin(0000):/var/adm: lp:x:78:9:0000-lp(0000):/usr/spool/lp: smtp:x:0:0:mail daemon user:/: uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp: nuucp:x:7:8:0000-uucp (0000):/var/spool/uucppublic:/usr/lib/uucp/uucico listen:x:22:6:Network Admin:/usr/net/nls nobody:x:60000:60000:uid no body:/: noaccess:x:60002:60002:uid no access:/:

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのサーバーには、新しいテーブル情報を収容できるだけの十分なディスク空き領域が必要です。

• NIS+ 主体 (適切な資格を持つクライアント) としてログインし、指定されたドメイン内の NIS+ テーブルに対する書き込み権を保持する必要があります。この例では、マシン master1 上の root ユーザーでなければなりません。

必要な情報

ファイルから生成する場合、次の情報が必要です。

• 新しい NIS+ ドメイン名

• データが転送される、適切に編集されたテキストファイルのパス

• ルートパスワード

NIS マップから生成する場合、次の情報が必要です。

• 新しい NIS+ ドメイン名

• NIS ドメイン名

• NIS サーバー名

• NIS サーバーの IP アドレス

• ルートパスワード

NIS ドメインの名前は大文字と小文字を区別しますが、NIS+ ドメインの名前は区別しません。

ルートマスターサーバーのテーブルを生成する方法

1. 「a」または「b」を実行してルートマスターサーバーテーブルを生成し、手順 2 に進みます。

   「a」では、ファイルからテーブルを生成する方法を示します。「b」では、NIS マップからテーブルを生成する方法を示します。これらのコマンドはスクロールできるウィンドウ内で実行します。そうしないと、スクリプトの出力がスクロールされず読めないことがあります。

   ---

   注 –

   システム上の /tmp 領域が不足する場合、nispopulate スクリプトは異常終了することがあります。これを防止するには、環境変数 TMPDIR に別のディレクトリを設定します。TMPDIR に有効なディレクトリが設定されていない場合、スクリプトは /tmp ディレクトリを使用します。

   ---

   1. 次のように入力して、ファイルからテーブルを生成します。

      master1# nispopulate -F -p /nis+files -d doc.com. NIS+ domain name : doc.com. Directory Path : /nis+files Is this information correct? (type 'y' to accept, 'n' to change)

      -F オプションは、テーブルがデータをファイルから取り出すことを示します。-p オプションには、ソースファイルのディレクトリ検索パスを指定します (この例では、/nis+files を指定します)。-d オプションは NIS+ ドメイン名を指定します (この例では、doc.com.を指定します)。

      NIS+ 主体のユーザーは root です。この例では、はじめてルートマスターサーバーのテーブルを生成することになるため、この作業はスーパーユーザーとして実行しなければなりません。nispopulate スクリプトは、NIS+ 管理グループのすべてのメンバーの資格を追加します。

   2. 次のように入力して、NIS マップからテーブルを生成します。

      master1# nispopulate -Y -d doc.com. -h salesmaster -a 130.48.58.111 -y sales.doc.com. NIS+ domain name : doc.com. NIS (YP) domain : sales.doc.com. NIS (YP) server hostname : salesmaster Is this information correct? (type 'y' to accept, 'n' to change)

      -Y オプションは、テーブルがデータを NIS マップから取り出すことを示します。-d オプションは NIS+ ドメイン名を指定します。-h オプションは、NIS サーバーのマシン名を指定します。salesmaster は NIS サーバーの名前の例です。サンプルドメインを作成する際は、salesmaster の代わりに、サイトでの実際の NIS サーバー名を指定してください。-a オプションは、NIS サーバーの IP アドレスを指定します。130.48.58.111 はアドレスの例です。サンプルドメインを作成する際は、サイトでの実際の NIS サーバーの IP アドレスを指定してください。-y オプションは、NIS ドメイン名を指定します。この例では、ドメイン名は sales.doc.com.です。サンプルドメインを作成する際は、sales.doc.com. の代わりに、サイトでの実際の NIS ドメインの NIS ドメイン名を指定してください。

      NIS+ 主体のユーザーは root です。この例では、はじめてルートマスターサーバーのテーブルを生成することになるため、この作業はスーパーユーザーとして実行しなければなりません。nispopulate(1M) スクリプトは、NIS+ 管理グループのすべてのメンバーの資格を追加します。

2. y を入力します (画面に表示された情報が正しい場合)。

   n を入力すると、スクリプトは正しい情報の入力を要求します。情報が誤っている場合の操作は、「誤った情報を変更する方法」を参照してください。

   • 手順 1 の「a」を実行すると、次のように表示されます。

     Is this information correct? (type 'y' to accept, 'n' to change) y This script will populate the following NIS+ tables for domain doc.com. from the files in /nis+files: auto_master auto_home ethers group hosts networks passwd protocols services rpc netmasks bootparams netgroup aliases shadow **WARNING: Interrupting this script after choosing to continue may leave the tables only partially populated. This script does not do any automatic recovery or cleanup. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

   • 手順 1 の「b」を実行すると、次のように表示されます。

     Is this information correct? (type 'y' to accept, 'n' to change) y This script will populate the following NIS+ tables for domain doc.com. from the NIS (YP) maps in domain sales: auto_master auto_home ethers group hosts networks passwd protocols services rpc netmasks bootparams netgroup aliases **WARNING: Interrupting this script after choosing to continue may leave the tables only partially populated. This script does not do any automatic recovery or cleanup. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. y を入力して、テーブルの生成を続けます。

   n を入力するとスクリプトは問題なく終了します。y を選択した後で、スクリプトの実行中にスクリプトを中断した場合、スクリプトは動作を停止し、テーブルは一部だけが生成された状態になることがあります。 スクリプトは自動回復や後始末は行いません。このスクリプトは安全に再実行できますが、テーブルは最新の情報で上書きされます。

   • ファイルからテーブルを生成する場合、スクリプトが hosts 情報と passwd 情報に基づいてホストとユーザーの資格を作成することを示す、次のようなメッセージが表示されます。

     Do you want to continue? (type 'y' to continue, 'n' to exit this script) y populating auto_master table from file /nis+files/auto_master ... auto_master table done. populating auto_home table from file /nis+files/auto_home ... auto_home table done. Credentials have been added for the entries in the hosts and passwd table(s). Each entry was given a default network password (also known as a Secure- RPC password). This password is: nisplus Use this password when the nisclient script requests the network password. Done!

     Secure RPC パスワード (上の例では nisplus) は必ず控えておき、忘れないようにしてください。ネットワークパスワードまたは Secure RPC パスワードを求められたら、ここで控えておいたパスワードを入力します。

     スクリプトは、必要なすべてのファイルを検索し、使用できるファイルからすべてのテーブルを生成します。

   • NIS マップからテーブルを生成する場合、スクリプトが hosts と passwd の情報に基づいてホストとユーザーの資格を作成する際に、次の内容が表示されます。

     Do you want to continue? (type 'y' to continue, 'n' to exit this script) y populating auto_master table from sales.doc.com. NIS(YP) domain... auto_master table done. populating auto_home table from file sales.doc.com. NIS(YP) domain... auto_home table done. .... Credentials have been added for the entries in the hosts and passwd table(s). Each entry was given a default network password (also known as a Secure-RPC password). This password is: nisplus Use this password when the nisclient script requests the network password. Done!

     Secure RPC パスワード (上の例では nisplus) は必ず控えておき、忘れないようにしてください。ネットワークパスワードまたは Secure RPC パスワードを求められたら、ここで控えておいたパスワードを入力します。

     これですべてのテーブルが生成されました。parse error という警告が表示されるかもしれませんが無視してかまいません。これらのエラーは、NIS+ が特定の NIS マップのフィールドで空の値または予期せぬ値を見つけたことを示します。必要に応じて、スクリプト終了後、データを検証してください。

4. ルートドメインの管理グループに自分自身とほかの管理者を追加します (必要に応じて) 。

   たとえば、自分自身のログイン ID が topadm で、ほかの管理者の ID が secondadmin の場合、次のように入力します。

   master1# nisgrpadm -a admin.doc.com. topadm.doc.com. secondadm.doc.com. Added “topadm.doc.com.” to group “admin.doc.com.”. Added “secondadm.doc.com.” to group “admin.doc.com.”.

   上記の nisgrpadm -a コマンドの引数 admin.doc.com. は、グループ名を表し、最初に記述しなければなりません。残りの 2 つの引数は管理者名です。

   ---

   注 –

   この時点で管理グループにユーザーを追加したい場合にだけ、この手順が必要です。ルートサーバーに管理者を追加するには、この時点で行います。NIS+ を構成した後でも、管理グループにユーザーを追加できます。

   ---

   この手順を実行するには、ほかの管理者がデフォルトパスワードを変更するまで待つ必要はありません。ただし、管理グループにほかの管理者を追加する場合は、事前に passwd テーブルに管理者が登録されている必要があります。管理グループのメンバーは、ドメインに自分自身を追加しなければ、NIS+ 主体として行動できません。ユーザーの初期設定については、「NIS+ ユーザーを初期設定する方法」を参照してください。また、新規にメンバーが登録されても、管理グループに対する古いキャッシュが破棄された後でなければ有効になりません。

5. 次のコマンドを入力して、ドメインのチェックポイントを実行します。

   master1# nisping -C doc.com. Checkpointing replicas serving directory doc.com. Master server is master1.doc.com. Last update occurred at date Master server is master1.doc.com. checkpoint scheduled on master1.doc.com.

   この手順によって、そのドメインをサポートする全サーバーは、初期設定 (.log) ファイルから新しい情報をテーブルのディスク上のコピーに転送します。ルートドメインの設定が終了したばかりであるため、このルートドメインにはまだ複製が存在せず、この手順はルートマスターサーバーにだけ影響を与えます。

スワップ領域またはディスク領域が不足している場合、サーバーは適切にチェックポイントを実行できませんが、その旨の通知は行われません。スワップ領域またはディスク領域が不足していないか確認するには、niscat コマンドでテーブルの内容を表示します。たとえば、rpc テーブルの内容をチェックするには、次のように入力します。

master1# niscat rpc.org_dir
rpcbind rpcbind 100000
rpcbind portmap 100000
rpcbind sunrpc 100000

スワップ領域が不足していると「チェックポイントを実行できない」という旨のメッセージではなく、次のエラーメッセージが表示されます。

can't list table: Server busy, Try Again.

このメッセージには明示されていませんが、これはスワップ領域の不足を示します。スワップ空間を増やし、このドメインに再びチェックポイントを実行します。

NIS+ クライアントマシンの設定

ルートマスターサーバーのテーブルがファイルまたは NIS マップから生成されると、NIS+ クライアントマシンを初期設定できます。ルートマスターサーバーは自分のドメインの NIS+ クライアントであるため、ルートマスターサーバーをこれ以上初期設定する必要はありません。この節では、デフォルト設定の nisclient スクリプトを使用して、NIS+ クライアントを初期設定する方法を説明します。次のスクリプトを使用します。

• 前の例で使用したドメイン doc.com.

• 前の例で、nispopulate スクリプトによって作成された Secure RPC パスワード (ネットワークパスワードとも呼ばれる。デフォルトは nisplus)

「新しいクライアントマシンを初期設定する方法」で使用する -i オプションでは、DNS を使用してホスト名を検索するような NIS+ クライアントを構成しません。DNS を使用する場合には、ネームサービススイッチファイルの中でクライアント用に、DNS を明確に指定しなければなりません。

nisclient を実行してクライアントマシンを設定するための前提条件

nisclient スクリプトを実行するには、次の条件を満たしている必要があります。

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのマスターサーバーのテーブルが生成されている (少なくとも、hosts テーブルまたは ipnodes テーブルには新しいクライアントマシンのエントリが必要)

• NIS+ クライアントとなるマシンにスーパーユーザーとしてログインしている。この例では、新しいクライアントマシン名は client1

必要な情報

nisclient を実行するには、次の情報が必要です。

• ドメイン名

• デフォルトの Secure RPC パスワード (nisplus)

• クライアントとなるマシンの root パスワード

• クライアントのホームドメインにある NIS+ サーバーの IP アドレス

• DES 認証を使用する場合には、マスターサーバー上で、Diffie-Hellman キー長が使用される。nisauthconf を使用して、マスターサーバー上で Diffie-Hellman キー長を確認する

新しいクライアントマシンを初期設定する方法

1. DES 認証を使用する場合には、オプションで、Diffie-Hellman キー長を指定します。

   マスターサーバー上で以下を入力します。

   nisauthconf

   クライアントマシン上で nisauthconf コマンドを実行するときは、上記コマンドの出力を引数として使用します。たとえば、マスターサーバー上で nisauthconf を実行すると

   dh640dh-0 des

   と出力される場合には、クライアントマシン上で次のコマンドを入力します。

   nisauthconf dh640dh-0 des

2. 次のコマンドを入力して、新しいクライアントマシン上で新しいクライアントを初期設定します。

   -i オプションはクライアントを初期設定します。-d オプションは新しい NIS+ ドメイン名を指定します。ドメイン名が指定されていない場合、デフォルトは現在のドメイン名です。-h オプションは NIS+ サーバーのホスト名を指定します。

   client1# nisclient -i -d doc.com. -h master1 Initializing client client1 for domain “doc.com.”. Once initialization is done, you will need to reboot your machine. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. y を入力します。

   n を入力するとスクリプトが終了します。クライアントの /etc/hosts ファイルまたは /etc/inet/ipnodes ファイルにルートサーバーのエントリがない場合、スクリプトはルートサーバーの IP アドレスの入力を指示します。

   Do you want to continue? (type 'y' to continue, 'n' to exit this script) y Type server master1's IP address:

4. 正しい IP アドレスを入力して、Return キーを押します。

   この例では、アドレス 123.123.123.123 を使用します。

   Type server master1's IP address: 123.123.123.123 setting up the domain information... setting up the name service switch information... At the prompt below, type the network password (also known as the Secure-RPC password) that you obtained either from your administrator or from running the nispopulate script. Please enter the Secure-RPC password for root:

5. Secure RPC パスワード (ネットワークパスワード) がルートのログインパスワードと異なる場合のみ、Secure RPC パスワードを入力します。

   この例では、デフォルトの nisplus を使用します。

   パスワードは画面に表示されません。入力を誤った場合、正しいパスワードを入力するよう要求されます。2 回目も入力を誤った場合、スクリプトが終了し、前回のネットワークサービスが復元されます。この場合、スクリプトを再度実行してください。

   Please enter the login password for root:

6. このクライアントマシンの root パスワードを入力します。

   パスワードは画面に表示されません。ネットワークパスワードと root のログインパスワードが同じ場合、root のログインパスワードの入力要求はありません。

   root パスワードを入力すると、このマシンの資格が変更されます。ここで、このマシンでは RPC パスワードと root パスワードが同じになります。

   Please enter the login password for root: Wrote secret key into /etc/.rootkey Your network password has been changed to your login one. Your network and login passwords are now the same. Client initialization completed!! Please reboot your machine for changes to take effect.

7. クライアントマシンを再起動します。

   ここで行なった変更は、マシンを再起動すると有効になります。

   以上の手順により、この NIS+ クライアントマシンのユーザーを NIS+ ドメインに追加できるようになりました。

クライアントマシンの追加作成

これまでに説明したクライアントの初期設定手順を、必要な各マシンで繰り返します。ほかのドメインのクライアントを初期設定するには、ドメイン名とマスターサーバー名を適宜変更して、上記の手順を繰り返します。

この章で説明する NIS+ ドメインのサンプルでは、ドメイン doc.com. 内の 4 台のクライアントを初期設定すると想定しています。そして、このうち 2 台のクライアントをルート以外の NIS+ サーバーとして構成し、3 番目のクライアントを doc.com. ドメインのルートマスターサーバーのルート複製サーバーとして構成します。

システムをサーバーにするには、システムをどの種類のサーバーにするにしても、事前にシステムを親ドメインのクライアントにしておく必要があります。

NIS+ クライアントユーザーの初期設定

マシンが NIS+ クライアントになったら、そのマシンのユーザーは自分自身を NIS+ ドメインに追加しなければなりません。ユーザーをドメインに追加するということは、Secure RPC パスワードをそのユーザーのログインパスワードに変更することを意味します。実際には、ユーザーのパスワードと Secure RPC パスワードが同じになります。この手順では nisclient(1M) スクリプトを使用します。

nisclient を実行してクライアントユーザーを初期設定するための前提条件

nisclient スクリプトを使用してユーザーを初期設定するには、次の条件を満たしている必要があります。

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのマスターサーバーのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• ドメイン内のクライアントマシンが初期設定されている

• クライアントマシンに「ユーザー」としてログインしている (この例では、ユーザー名は user1)

• DES 認証を使用する場合には、クライアントマシンでマスターサーバーと同じ Diffie-Hellman キー設定を使用している

必要な情報

nisclient を実行するには、次の情報が必要です。

• ユーザーのログイン名 (この例では user1)

• デフォルトの Secure RPC パスワード (この例では nisplus)

• NIS+ クライアントになるユーザーのログインパスワード

NIS+ ユーザーを初期設定する方法

1. NIS+ クライアントになるユーザーとしてログインして、次のように nisclient コマンドを入力します。

   user1prompt% nisclient -u At the prompt below, type the network password (also known as the Secure-RPC password) that you obtained either from your administrator or from running the nispopulate script. Please enter the Secure-RPC password for user1:

2. Secure RPC パスワード (この例では nisplus) を入力します。

   パスワードは画面に表示されません。

   Please enter the login password for user1:

3. ユーザーのログインパスワードを入力し、Return キーを押します。

   パスワードは画面に表示されません。

   Your network password has been changed to your login one. Your network and login passwords are now the same

   これで、このユーザーは NIS+ クライアントになりました。全ユーザーを NIS+ クライアントにする必要があります。

NIS+ サーバーの設定

初期設定が終了したら、どのクライアントマシンも次の NIS+ サーバーに変更できます。

• ルート複製サーバー (ルートマスターサーバー上にある NIS+ テーブルのコピーを格納する)

• ルートドメインのサブドメインのマスターサーバー

• ルートドメインのサブドメインのマスターサーバーの複製サーバー

NIS+ マスタールートサーバーは 1 つしか持てません。ルート NIS+ サーバーは特殊な NIS+ サーバーです。この節ではルートマスターサーバーの構成方法は説明しません。詳細は、「NIS+ ルートサーバーの設定」 を参照してください。

サーバーを構成する場合、次の 3 つの設定があります。

• NIS と互換性なし

• NIS と互換性あり

• NIS との互換性と DNS 転送あり - NIS+ 名前空間に Sun OS 4.x クライアントを配置する場合は、DNS 転送を設定する必要があります。

サーバーとその複製は、NIS 互換についての設定が同じでなければなりません。設定が異なる場合、ネットワーク情報を受信するために NIS 互換の設定を必要とするクライアントは、必要なサーバーまたは複製サーバーを使用できなければ、この情報を受信できません。

NIS+ サーバーを設定するための前提条件

svcadm を使用してコマンド行から NIS+ サービスを起動するには、次の条件が満たされていることを確認してください。

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのマスターサーバーのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• ドメイン内のクライアントマシンが初期設定されている

• クライアントマシンにスーパーユーザーとしてログインしている (この例では、クライアントマシン名は client1)

• DES 認証を使用する場合には、クライアントマシンでマスターサーバーと同じ Diffie-Hellman キー設定を使用している

必要な情報

svcadm コマンドを使用して NIS+ サービスを起動するには、サーバーに変換するクライアントのスーパーユーザーパスワードが必要です。

クライアントを NIS+ サーバーとして構成する方法

クライアントをサーバーとして構成するには、次の手順のどれかを実行します。この手順では、サーバーと同じ名前のディレクトリを作成し、サーバーの初期設定ファイルを作成します。これらは /var/nis に置かれます。

同じドメイン内のすべてのサーバーは、NIS 互換の設定が同じでなければなりません。たとえば、マスターサーバーが NIS 互換である場合、その複製も NIS 互換でなければなりません。

NIS と互換性のないサーバーを構成する方法

この手順を実行するには、スーパーユーザーになるか、同等の役割になる必要があります。

1. /lib/svc/method/nisplus ファイルを表示して、-Y オプションが含まれていないことを確認します。

   詳細については、「NIS+ とサービス管理機能」を参照してください。

2. NIS+ サービスを開始します。

   この手順を実行するには、スーパーユーザーになるか、同等の役割になる必要があります。

   client1# svcadm enable /network/rpc/nisplus:default

これで、このサーバーはドメインのマスターまたは複製として指定できます。

NIS と互換性のあるサーバーを構成する方法

この手順を実行するには、スーパーユーザーになるか、同等の役割になる必要があります。

1. サーバー上で /lib/svc/method/nisplus ファイルを編集して -Y オプションを追加します。

   詳細については、「NIS+ とサービス管理機能」を参照してください。

2. NIS+ サービスを開始します。

   この手順を実行するには、スーパーユーザーになるか、同等の役割になる必要があります。

   client1# svcadm enable /network/rpc/nisplus

これで、このサーバーはドメインのマスターまたは複製として指定できます。

DNS 転送機能と NIS との互換性を備えたサーバーを構成する方法

次の手順を実行して、DNS 転送と NIS との互換性の両方の機能を備えた NIS+ サーバーを構成します。SunOS 4.x クライアントをサポートするには、両方の機能が必要です。

この手順を実行するには、スーパーユーザーになるか、同等の役割になる必要があります。

1. サーバー上で /lib/svc/method/nisplus ファイルを編集して -Y オプションと -B オプションを追加します。

   詳細については、「NIS+ とサービス管理機能」を参照してください。

2. NIS+ サービスを開始します。

   この手順を実行するには、スーパーユーザーになるか、同等の役割になる必要があります。

   client1# svcadm enable /network/rpc/nisplus:default

これで、このサーバーはドメインのマスターまたは複製として指定できます。

サーバーの追加作成

これまでのクライアントをサーバーに変更する手順を、必要なクライアントマシンごとに繰り返します。

この章で説明する NIS+ サンプルドメインは、3 台のクライアントをサーバーに変更すると想定しています。そして、サーバーの 1 台をルート複製サーバーに、もう 1 台を新しいサブドメインのマスターに、そして 3 台目を新しいサブドメインのマスターの複製に構成します。

ルート複製サーバーの作成

NIS+ サービスを常に利用可能な状態にしておくため、ルート複製サーバーを少なくとも 1 つは作成しておくことをお勧めします。複製サーバーを作成すると複数のサーバーが存在することになり、要求の処理を分散させることができるため、ネットワーク要求の処理も高速化されます。

パフォーマンス上の理由から、1 つのドメインに多くの複製サーバーを置くことはお勧めできません。ネットワークが複数のサブネットで構成されている場合、あるいは広域ネットワーク (WAN) でリモートサイトに接続されている場合には、複製サーバーを追加すると良い場合があります。

• 「サブネット」。複数のサブネットで構成されているドメインの場合、各サブネットに複製サーバーを少なくとも 1 つは作成することをお勧めします。そうしておけば、ネットワーク間の通信が一時的に途絶しても、接続が回復するまでの間、サブネットレベルの機能は維持されます。

• 「リモートサイト」。WAN によりリモートサイトに接続されているドメインの場合、WAN 接続の両側に複製サーバーを少なくとも 1 つは作成することをお勧めします。組織論的な見地からしても、同一の NIS+ ドメインに物理的に離れた 2 つのサイトがあるのは意味のあることです。たとえば、ドメイン内のマスターサーバーとその複製サーバーがすべて一方のサイトに置かれている場合、そのサイトともう一方のサイトとの間の NIS+ ネットワークトラフィックが増大するのは目に見えています。もう一方のサイトにも複製サーバーを置いておけば、ネットワークトラフィックが減るはずです。

最適な複製サーバー数の決定方法については、「ルート複製サーバーの作成」を参照してください。

「ルート複製サーバーを作成する方法」では、マシン client1 を doc.com. ドメインのルート複製サーバーとして構成します。この手順では、NIS+ スクリプトの nisserver を使用します。「NIS+ コマンドを使って複製サーバーを構成する」で説明しているように、NIS+ コマンドを使用して複製サーバーを構成することもできます。

nisserver を実行してルート複製サーバーを作成するための前提条件

nisserver を実行して複製サーバーを作成するには、次の条件を満たしている必要があります。

• ドメインがすでに構成され、マスターサーバーが稼働している

• マスターサーバーのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• 新たに作成したサーバーをそのドメインのクライアントマシンとして初期設定している (具体的な手順については、「NIS+ クライアントマシンの設定」を参照)

• 新たに作成した複製サーバー上で NIS+ サービス (rpc.nisd) を起動している (具体的な手順については、「NIS+ サーバーの設定」を参照)

• ルートマスターサーバーにスーパーユーザーとしてログインしている。この例では、ルートマスターマシン名は master1

必要な情報

nisserver を実行するには、次の情報が必要です。

• ドメイン名

• クライアントマシン名 (この例では、client1)

• ルートマスターサーバーのスーパーユーザーのパスワード

ルート複製サーバーを作成する方法

1. NIS+ ドメインのルートマスターサーバー上でスーパーユーザー (root) として次のように入力して、ルート複製サーバーを作成します。

   master1# nisserver -R -d doc.com. -h client1 This script sets up a NIS+ replica server for domain doc.com. Domain name: :doc.com. NIS+ server : :client1 Is this information correct? (type 'y' to accept, 'n' to change)

   -R オプションは、複製サーバーを構成することを示します。-d オプションは NIS+ ドメイン名 (このサンプルでは doc.com.) を指定します。-h オプションはルート複製サーバーとなるクライアントマシン (この例では client1) を指定します。

2. y を入力して操作を続けます。

   n を入力すると、スクリプトは正しい情報の入力を要求します。n を入力した場合の操作については、「誤った情報を変更する方法」を参照してください。

   Is this information correct? (type 'y' to accept, 'n' to change) y This script will set up machine “client1” as an NIS+ replica server for domain doc.com. without NIS compatibility. The NIS+ server daemon, rpc.nisd, must be running on client1 with the proper options to serve this domain. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. y を入力して操作を続けます。

   n を入力するとスクリプトは問題なく終了します。クライアントマシン上で rpc.nisd が動作していない場合、スクリプトは自動的に終了します。

   Is this information correct? (type 'y' to continue, 'n' to exit this script) y The system client1 is now configured as a replica server for domain doc.com.. The NIS+ server daemon, rpc.nisd, must be running on client1 with the proper options to serve this domain. ...

   ---

   注 –

   この複製サーバーを NIS (YP) 互換モードで実行する場合は、/lib/svc/method/nisplus ファイルに -Y オプションを追加します。このファイルの変更が必要となるのは、ルート複製サーバーで NIS クライアント要求を実行する場合で、このサーバーが NIS 互換サーバーとして構成されていない場合に限られます。NIS 互換サーバーの作成方法については、「クライアントを NIS+ サーバーとして構成する方法」を参照してください。NIS+ でのサービス管理機能コマンドの使用方法については、「NIS+ とサービス管理機能」を参照してください。

   ---

4. (省略可能) 複製サーバーを NIS (YP) 互換モードで稼働させることができるように構成します。

   複製サーバーを NIS 互換モードで稼働させるには、次の手順に従います。

   1. NIS+ サービスを停止します。

      # svcadm disable /network/rpc/nisplus:<instance>

   2. サーバーの /lib/svc/method/nisplus ファイルを編集して -Y オプションを追加します。

   3. NIS+ サービスを再起動します。

      # svcadm enable /network/rpc/nisplus:<instance>

5. 新たに作成した複製サーバーに名前空間データをロードします。

   これには、次の 2 つの方法があります。

   • NIS+ の保存と復元の機能を使用して、マスターサーバーのデータを保存し、作成した複製サーバーに復元します (こちらの方法をお勧めします)。具体的な手順については、「名前空間データをロードする方法—nisrestore による方法」を参照してください。

   • nisping を実行します。nisping を実行すると、マスターサーバーのすべての NIS+ データを複製サーバーに完全に再同期させることができます。しかし、大きな名前空間の場合、処理に長時間かかることがあります。その間、マスターサーバーはビジーになって応答が遅く、また作成した複製サーバーはまだ NIS+ 要求に応答できない状態になることがあります。具体的な手順については、「名前空間データをロードする方法—nisping による方法」を参照してください。

   名前空間データのロードが終了すれば、マシン client1 は NIS+ ルート複製サーバーとなります。この新しいルート複製サーバーは、ルートドメインのクライアントからの要求を処理できます。これでドメインで使用可能なサーバーが 2 台となるため、要求を速く処理できます。

   これらの手順に従って、複製サーバーを必要なだけ作ることができます。同じ手順を使ってサブドメインに複製サーバーを作ることもできます。

Multihomed NIS+ 複製サーバーの設定方法

Multihomed NIS+ サーバーを設定する手順は、単一インタフェースサーバーの設定手順と同じです。唯一の相違点は、ローカルの /etc/hosts ファイル、/etc/inet/ipnodes ファイルと NIS+ の hosts テーブルおよび ipnodes テーブル内に定義する必要があるインタフェースが、単一インタフェースサーバーよりも多いという点です。ホスト情報を定義したら、nisclient と nisserver スクリプトを使用して Multihomed NIS+ サーバーを設定します。

Multihomed NIS+ サーバーを設定する場合は、サーバーの主体名はシステムのノード名と同じにする必要があります。これは、Secured RPC と nisclient を同時に使用する際の必要条件です。

• Secured RPC は、ノード名を使用して認証に必要なネット名を作成する

• nisclient は、主体名を使用してクライアントの資格を作成する

次に、NIS+ ルートマスター以外のサーバーの設定手順を示します。以下の例では、ルートドメインの複製を作成しています。muitihomed ルートサーバーの設定方法については、「Multihomed NIS+ ルートマスターサーバーの設定方法」を参照してください。

1. サーバーのホスト情報を hosts ファイルまたは ipnodes ファイル内に追加します。

   たとえば、3 つのインタフェースを装備した hostB システムの場合は、次のように入力します。

   192.168.11.y hostB hostB-11 192.168.12.x hostB hostB-12 192.168.14.z hostB hostB-14

2. ルートマスターサーバー上で、nispopulate または nisaddent のどちらかを使用して、新しいホスト情報を hosts テーブルまたは ipnodes テーブル内にロードします。

   たとえば、以下のようになります。

   hostA# nispopulate -F -d sun.com hosts

   この例では、sun.com は NIS+ ルートドメイン名を表しています。自分の NIS+ ルートドメイン名を指定して nispopulate コマンドを実行してください。

3. ルートマスターサーバー上で、nisclient スクリプトを使用して新しいクライアントの資格を作成します。

   たとえば、以下のようになります。

   hostA# nisclient -c -d sun.com hostB

   この例では、sun.com は ルートドメイン名を表しています。自分のルートドメイン名を指定して nisclient コマンドを実行してください。

4. ルート以外のマスターサーバー上で、新しいサーバーがまだ稼働していない場合は、nisclient を使用して新しいサーバーを起動し、このマシンを NIS+ クライアントとして初期化します。

   たとえば、以下のようになります。

   hostB# nisclient -i -d sun.com

   この例では、sun.com は ルートドメイン名を表しています。自分のルートドメイン名を指定して nisclient コマンドを実行してください。

5. ルートマスター上で、nisserver を使用してルートマスター以外のサーバーを設定します。

   たとえば、以下のようになります。

   hostA# nisserver -M -d eng.sun.com -h hostB.sun.com.

   この例では、eng.sun.com は NIS+ ドメイン名を表し、hostB.sun.com は NIS+ サーバーの完全指定ホスト名を表しています。nisserver コマンドは、自分の NIS+ ドメイン名と NIS+ サーバーの完全指定ホスト名を指定して実行してください。

6. ルートマスターサーバー上で、nisserver を使用して複製サーバーを設定します。

   たとえば、以下のようになります。

   hostA# nisserver -R -d sun.com -h hostB.sun.com.

   この例では、sun.com は 複製サーバーを表し、hostB.sun.com は NIS+ サーバーの完全指定ホスト名を表しています。nisserver コマンドは、自分の複製サーバー名と NIS+ サーバーの完全指定ホスト名を指定して実行してください。

multihomed NIS+ 複製サーバーの設定が完了したら、このあとの設定手順は、単一インタフェースのサーバーの設定手順とまったく同じです。

サブドメインの作成

この節では、ルート以外の新しいドメイン (サブドメイン) のマスターサーバーの作成方法を説明します。この新しいドメインは doc.com. ドメインのサブドメインとなります。NIS+ の階層構造によって、組織構造に合わせたドメイン構造を作成できます。

この例では、マシン client2 が新しい sub.doc.com. ドメインのマスターサーバーに変更されます。ここでは NIS+ スクリプトの nisserver を使用します。

nisserver を実行してサブドメインを作成するための前提条件

nisserver を実行して、新しいサブドメインのマスターサーバーを作成するには、次の条件を満たしている必要があります。

• 親ドメインがすでに構成され、そのマスターサーバーが実行されている

• 親ドメインのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• 親ドメイン内の新しいクライアントマシンが初期設定されている

• クライアント上で NIS+ サービス (rpc.nisd) が起動されている

• 新しいドメインを追加するための適切なアクセス権がある。この例では、親マスターサーバーにスーパーユーザーとしてログインする。この例では、親マスターマシン名は master1

必要な情報

nisserver を実行してサブドメイン用のマスターサーバーを作成するには、次の情報が必要です。

• クライアントマシン名 (この例では、client2)

• 親マスターサーバーのスーパーユーザーパスワード

• 新しいサブドメインの名前 - 親ドメインの名前を含んだ新しいドメイン名。書式は、「newdomain.rootdomain」という構文に従うこと

  「新しいルート以外のドメインを作成する方法」では、新しいサブドメインを sub.doc.com. とします。

Solaris リリース 2.6 およびこれ以前のリリースでは、どんな NIS+ クライアントでも、そのサービスの提供先となるドメインの上位ドメインに置かれている限り、NIS+ マスターサーバーに変更できます。たとえば、ドメイン sales.doc.com. の NIS+ クライアントは、west.sales.doc.com. や alameda.west.sales.doc.com. などの下位ドメインにサービスを提供することができます。ただし、このクライアントは、ドメイン doc.com. にサービスを提供することはできません。これは、doc.com. が sales.doc.com. の上位ドメインであるためです。ただし、ルート複製サーバーはこのルールの唯一の例外であり、サービス提供先のドメインのクライアントです。

Solaris リリース 7 およびリリース 8 では、ドメインの NIS+ サーバーを、それがサービスしている同じドメイン内に置くことができます。ルート以外のサーバーは、設定されたドメイン内でサーバーとして動作します。つまり、ルート以外のサーバー上のアプリケーションを構成して、上位ドメインから渡される情報を使用することができます。

ただし、ルート以外のサーバーの資格は、上位ドメインになければなりません。ルート以外のサーバーの構成方法については、「新しいルート以外のドメインを作成する方法」を参照してください。サーバーを正しく構成したあとで、ドメイン名をサーバーとして機能するドメインの名前に変更できます。nisinit の -k オプションおよび nisserver の -d オプションを参照してください。

新しいルート以外のドメインを作成する方法

1. NIS+ ドメインのルートマスターサーバー上のスーパーユーザー (root) として次のように入力し、新しいルート以外のドメインマスターサーバーを作成します。

   -M オプションは、新しいルート以外のドメインのマスターサーバーを作成することを示します。-d オプションは、ドメイン名 (この例では、sales.doc.com.) を指定します。-h オプションは、新しいドメインのマスターサーバーになるクライアントマシン (この例では、client2) を指定します。

   master1# nisserver -M -d sales.doc.com. -h client2 This script sets up a non-root NIS+ master server for domain sales.doc.com. Domain name : sales.doc.com. NIS+ server : client2 NIS+ group : admin.sales.doc.com. NIS (YP) compatibility : OFF Security level : 2=DES Is this information correct? (type 'y' to accept, 'n' to change)

   新しいルート以外のドメインのマスターサーバーは、ルートサーバーと同じデフォルト値によって作成されます。NIS+ グループ、NIS (YP) 互換性、およびセキュリティレベルの詳細は、「ルートマスターサーバーを作成する方法」を参照してください。

2. y を入力して操作を続けます。

   n を入力すると、スクリプトは正しい情報の入力を要求します。n を入力した場合の操作については、「誤った情報を変更する方法」を参照してください。

   Is this information correct? (type 'y' to accept, 'n' to change) y This script sets up machine “client2” as an NIS+ non-root master server for domain sales.doc.com. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. y を入力して操作を続けます。

   n を入力すると、スクリプトは安全に終了します。クライアントマシン上で rpc.nisd が動作していない場合、スクリプトは自動的に終了します。

   Do you want to continue? (type 'y' to continue, 'n' to exit this script) y running nissetup ... org_dir.sales.doc.com. created groups_dir.sales.doc.com. created ... ... setting NIS+ group admin.sales.doc.com. ... The system client2 is now configured as a non-root server for domain sales.doc.com. You can now populate the standard NIS+ tables by using the nispopulate or /usr/lib/nis/nisaddent commands.

   これで、マシン client2 は sales.doc.com. ドメインのマスターサーバーになりました。sales.doc.com. ドメインは、doc.com. ドメインのサブドメインです。マシン client2 は、依然としてルートドメイン doc.com. のクライアントであり、しかも sales.doc.com. ドメインのマスターサーバーでもあります。

   これで、sales.doc.com. ドメインの新しいマスターサーバーに標準の NIS+ テーブルを生成できます。

ドメインの追加作成

サーバーを新しいルート以外のドメインのマスターサーバーに変更する前述の手順を、必要な各サーバーマシンに対して繰り返します。新しいマスターサーバーはすべて新しいドメインです。ドメイン構造の計画を立ててから、NIS+ 名前空間の作成を開始します。NIS+ 階層の計画については、「NIS+ 名前空間の構造」を参照してください。

新しいサブドメインのテーブルの生成

新しいドメインを作成したら、そのマスターサーバーの標準の NIS+ テーブルを生成しなければなりません。新しいマスターサーバーのテーブルを生成するには、ルートマスターサーバーのテーブルを生成するときと同じ手順を使用します。大きな違いは、nispopulate(1M) スクリプトが、ルートマスターサーバー上ではなく、新しいマスターサーバー上で実行されることです。また、ドメイン名、およびファイルパス、または NIS サーバー名も変わることがあります。

この例では、新しいドメイン (sales.doc.com.) のテーブルを生成します。

nispopulate を実行してサブドメインのテーブルを生成するための前提条件

nispopulate スクリプトを実行して新しいマスターサーバーのテーブルを生成するには、次の条件を満たしている必要があります。

• ファイル内の情報は、ロード先のテーブルに合った書式で書かれていなければなりません。

  • スクリプトを実行する前に、データを読み込むローカルの /etc 内の各ファイルまたは NIS マップを調べます。不正なエントリがないことを確認します。正しいデータが、所定の場所に正しい書式で記録されていることを確認します。エントリのうち、古いもの、無効なもの、破損しているものは削除します。また、不完全なエントリや一部のみのエントリも削除します。構成完了後は、いつでもエントリを追加できます。必要なエントリをあとから追加する方が、不完全なエントリや破損しているエントリを読み込もうとするよりも簡単です。

  • ネットワークをはじめて設定する場合、多くのネットワーク情報をすでにどこかに格納しているということはおそらくないでしょう。このような場合、まずネットワーク情報を集め、「入力ファイル」に手入力する必要があります。このファイルは、基本的に /etc 内のファイルに対応するものです。

  • 安全のため、/etc 内のファイルのコピーを作成します。実際のファイルは使用せずに、作成したコピーを使用してテーブルを生成してください。たとえば、この例では /nis+files というディレクトリ内のファイルを使用します。

• コピーした NIS テーブルファイルのうち、passwd、shadow、aliases、hosts の各ファイルには、名前空間全体に分散させるとセキュリティ上問題がある項目があるので、それらを編集します。たとえば、次に示す行をローカル側の passwd ファイルのコピーから削除して、名前空間で配布されないようにします。

  root:x:0:1:0000-Admin(0000):/:/sbin/sh daemon:x:1:3:0000-Admin(0000):/: bin:x:3:5:0000-Admin(0000):/usr/bin: sys:x:3:3:0000-Admin(0000):/: adm:x:4:4:0000-Admin(0000):/var/adm: lp:x:78:9:0000-lp(0000):/usr/spool/lp: smtp:x:0:0:mail daemon user:/: uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp: nuucp:x:7:8:0000- uucp (0000):/var/spool/uucppublic:/usr/lib/uucp/uucico listen:x:22:6:Network Admin:/usr/net/nls: nobody:x:60000:60000:uid no body:/: noaccess:x:60002:60002:uid no access:/:

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのサーバーには、新しいテーブル情報を収容できるだけの十分なディスク空き領域が必要です。

• NIS+ 主体としてログインしていて、しかも指定されたドメイン内の NIS+ テーブルに対する書き込み権が必要です。この例では、マシン client2 上の root でなければなりません。

システム上の /tmp 領域が不足する場合、nispopulate スクリプトは異常終了することがあります。これを防止するには、環境変数 TMPDIR に別のディレクトリを設定します。TMPDIR に有効なディレクトリが設定されていない場合、スクリプトは代わりに /tmp ディレクトリを使用します。

必要な情報

ファイルから生成するか、NIS マップから生成するかによって収集する情報が異なります。

ファイルから生成する場合、次の情報が必要です。

• 新しい NIS+ ドメイン名

• データが転送される、適切に編集されたテキストファイルのパス

• NIS+ マスターサーバーの root パスワード

NIS マップから生成する場合、次の情報が必要です。

• 新しい NIS+ ドメイン名

• NIS ドメイン名

• NIS サーバー名

• NIS サーバーの IP アドレス

• NIS+ マスターサーバーの root パスワード

NIS ドメインの名前は大文字と小文字を区別しますが、NIS+ ドメインの名前は区別しません。

マスターサーバーテーブルを生成する方法

この手順は、「ルートマスターサーバーのテーブルを生成する方法」の手順と実質的に同じなので、この例では新しい sales.doc.com. ドメインのテーブルを生成するための入力についてのみ説明します。この手順の詳細は、「ルートマスターサーバーのテーブルを生成する方法」を参照してください。

このスクリプトは、ルートマスターサーバーではなく、新しいドメインのマスターサーバー上で実行しなければなりません。

次のいずれかの方法で、新しいマスターサーバー上にマスターサーバーテーブルを生成します。

• ファイルからマスターサーバーテーブルを生成する

• NIS マップからマスターサーバーテーブルを生成する

実行結果が一度に表示しきれないことがあるので、どちらの方法で行うにしてもスクロール可能なウィンドウを使用してください。

テーブルをファイルから生成する方法

ファイルからマスターサーバーテーブルを生成するには、次のコマンドを入力します。

client2# nispopulate -F -p /nis+files -d sales.doc.com.
NIS+ domain name : sales.doc.com.
Directory Path : /nis+files
Is this information correct? (type 'y' to accept, 'n' to change

テーブルを NIS マップから生成する方法

NIS マップからマスターサーバーテーブルを生成するには、次のコマンドを入力します。

client2# nispopulate -Y -d sales.doc.com. -h businessmachine -a 
IP_addr_of_NIS_server -y business.doc.com.
NIS+ Domain name : sales.doc.com.
NIS (YP) domain : business.doc.com.
NIS (YP) server hostname : businessmachine
Is this information correct? (type 'y' to accept, 'n' to change)

詳細は、「ルートマスターサーバーのテーブルを生成する方法」を参照してください。

サブドメイン複製サーバーの作成

ルートドメイン複製サーバーに対して適用される規則は、サブドメイン複製サーバーに対しても適用されます (「ルート複製サーバーの作成」を参照)。

サブドメインの複製サーバーの作成には、ルート複製サーバーの作成と同じ手順を使用します。このルート複製サーバーの作成とサブドメイン複製サーバーの作成との大きな違いは、サブドメイン複製サーバーに変更しようとしているマシンが、複製サーバーとしてサービスを提供することになるドメインより上位のドメインのクライアントのままであることです。この例では、新しいドメインの複製サーバーを作成するための入力だけを示します。スクリプトの残りの出力については、「ルート複製サーバーを作成する方法」を参照してください。

nisserver を実行してサブドメイン複製サーバーを作成するための前提条件

nisserver を実行して複製サーバーを作成するには、次の条件を満たしている必要があります。

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• 親ドメイン内のクライアントマシンが初期設定されている

• クライアント上で NIS+ サービス (rpc.nisd) が起動されている

• マスターサーバーにスーパーユーザーとしてログインしている (この例では、マスターマシン名は client2)

必要な情報

nisserver を実行するには、次の情報が必要です。

• ドメイン名

• クライアントマシン名 (この例では、client3)

• ルートマスターサーバーのスーパーユーザーのパスワード

複製サーバーを作成する方法

複製サーバーを作成するには、NIS+ ドメインのマスターサーバー上でスーパーユーザー (root) として、nisserver -R コマンドを実行します。

client2# nisserver -R -d sales.doc.com. -h client3
This script sets up a NIS+ replica server for domain sales.doc.com.
Domain name 	::sales.doc.com.
NIS+ server :client
Is this information correct? (type 'y' to accept, 'n' to change)

この例では、client2 がマスターサーバーです。-R オプションは、複製サーバーを構成することを示します。-d オプションは NIS+ ドメイン名 (ここでは、sales.doc.com.) を指定します。-h オプションは複製サーバーとなるクライアントマシン (ここでは client3) を指定します。なお、このマシンは依然として doc.com. ドメインのクライアントであり、sales.doc.com. ドメインのクライアントではありません。

このスクリプトの残りの出力については、「ルート複製サーバーを作成する方法」を参照してください。

サブドメインの NIS+ クライアントマシンの初期設定

マスターサーバーのテーブルをファイルまたは NIS マップから生成すれば、NIS+ クライアントマシンを初期設定できます。この節では、デフォルト設定の nisclient スクリプトを使用して、新しいドメイン内の NIS+ クライアントを初期設定する方法を説明します。NIS+ クライアントマシンは、NIS+ マスターサーバーとは別のマシンです。

「新しいサブドメインクライアントマシンを初期設定する方法」で使用される -i オプションは、NIS+ クライアントを DNS を必要とするホスト名の解決ができるようには構成しません。DNS を使用する場合には、ネームサービススイッチファイルの中でクライアント用に、DNS を明確に指定しなければなりません。

新しいドメイン内のクライアントを初期設定するには、ルートドメイン内のクライアントの初期設定と同じ手順を使用します。この例では、新しいドメインのクライアントを初期設定するための入力だけを示します。スクリプトの残りの出力については、「新しいクライアントマシンを初期設定する方法」を参照してください。

nisclient を実行してクライアントマシンを初期設定するための前提条件

nisclient スクリプトを使用してクライアントマシンを初期設定するには、次の条件を満たしている必要があります。

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのマスターサーバーのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• ドメイン内のクライアントマシンが初期設定されている

• クライアントマシンに「ユーザー」としてログインしている (この例では、ユーザー名は user1)

必要な情報

nisclient を実行するには、次の情報が必要です。

• ドメイン名 (この例では、sales.doc.com.)

• デフォルトのネットワークパスワード (この例では、nisplus)

• クライアントとなるマシンの root のパスワード

• クライアントのホームドメイン内の NIS+ サーバーの IP アドレス (この例では、マスターサーバー client2 のアドレス)

新しいサブドメインクライアントマシンを初期設定する方法

新しいクライアントマシン上で新しいクライアントを初期設定するには、スーパーユーザーとして次のコマンドを入力します。

subclient1# nisclient -i -d sales.doc.com. -h client2
Initializing client subclient1 for domain “sales.doc.com.”.
Once initialization is done, you will need to reboot your machine.
Do you want to continue? (type 'Y' to continue, 'N' to exit this script)

-i オプションはクライアントを初期設定します。-d オプションは新しい NIS+ ドメイン名を指定します。ドメイン名が指定されない場合、デフォルトは現在のドメイン名になります。-h オプションは NIS+ サーバーのホスト名を指定します。

このスクリプトの残りの出力については、「新しいクライアントマシンを初期設定する方法」を参照してください。

サブドメインの NIS+ クライアントユーザーの初期設定

新しいドメイン内のユーザーを初期設定するには、ルートドメイン内のユーザーを初期設定する場合と同じ手順 (nisclient) を使用します。全ユーザーが NIS+ クライアントにならなければなりません。この例では、新しいドメインのユーザーを初期設定するための入力だけを示します。スクリプトの残りの出力については、「NIS+ ユーザーを初期設定する方法」を参照してください。

nisclient を実行してサブドメインのクライアントユーザーを初期設定するための前提条件

nisclient スクリプトを使用してユーザーを初期設定するには、次の条件を満たしている必要があります。

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのマスターサーバーのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• ドメイン内のクライアントマシンが初期設定されている

• クライアントマシンに「ユーザー」としてログインしている (この例では、ユーザー名は user2)

必要な情報

nisclient を実行するには、次の情報が必要です。

• ユーザーのログイン名 (この例では、user2)

• デフォルトのネットワークパスワード (この例では、nisplus)

• NIS+ クライアントになるユーザーのログインパスワード

NIS+ サブドメインユーザーを初期設定する方法

NIS+ クライアントとなるには、ユーザーとしてログインして、次のコマンドを実行します。

user2prompt% nisclient -u
At the prompt below, type the network password (also known as the 
Secure-RPC password) that you obtained either from your administrator 
or from running the nispopulate script.
Please enter the Secure-RPC password for user2:

このスクリプトの残りの出力については、「NIS+ ユーザーを初期設定する方法」を参照してください。

NIS+ 名前空間サンプルで使用したコマンドのまとめ

名前空間サンプルの作成で使用したコマンドを表 4–4 にまとめます。各コマンドの前にあるプロンプトは、そのコマンドをどのマシンで入力するかを示します。

第 5 章 ルートドメインの設定

この章では、NIS+ コマンド群によるルートドメインと DES 認証の設定の手順を説明します。

NIS+ は、将来のリリースではサポートされなくなる可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 リリース以降で使用できます (『Solaris のシステム管理(ネーミングとディレクトリサービス: DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

ルートドメインの設定方法の概要

ここでは、ルートマスターサーバーをセキュリティレベル 2 で稼働させるルートドメインの構成方法について説明します。

ルートドメインの構成は、この章で説明する NIS+ コマンドより、NIS+ スクリプトを使用する方が簡単です。この章で説明する方法は、NIS+ に精通した管理者や、設定スクリプトでは提供されない標準以外の機能や構成を必要とする管理者だけが使用してください。

ルートドメインの設定には、次の 3 つの主な作業があります。

• ルートマスターサーバーの準備

• ルートドメインの作成

• ルートドメインの資格の作成

ただし、ルートドメインの設定はこれらの 3 つの作業を単にこの順序で行うといった簡単なものではありません。3 つの作業はそれぞれ関連し合っています。たとえば、ルートディレクトリを作成する前にセキュリティパラメータの一部を指定しなければなりません。ほかのパラメータはその後で指定します。ルートドメインの構成を容易にするために、この節ではこれらの作業を個別の手順に分けて、一番効率の良い順番に並べています。

標準構成と NIS 互換構成の手順の相違

この章で説明する手順は、標準の NIS+ ルートドメインと NIS 互換のルートドメインの両方に適用できます。ただし、いくつかの重要な相違があります。NIS 互換ドメイン用の NIS+ デーモンは -Y オプションを使用して起動する必要があります。これによりルートマスターサーバーは、NIS クライアントからの要求に応えることができます。詳細については、「NIS+ とサービス管理機能」を参照してください。

また、NIS 互換ドメインでは、passwd テーブルは、未認証クラスに対する読み取り権が必要です。これにより NIS クライアントはテーブルのパスワード列にある情報にアクセスすることができます。これは手順 14 で nissetup コマンドに -Y オプションを使用して行います。標準の NIS+ ドメインは同じコマンドを使用しますが、-Y オプションは付けません。

NIS+ サービスは、サービス管理機能 (SMF) によって管理されます。このサービスに対する有効化、無効化、再起動などの管理操作を実行するには、svcadm コマンドを使用します。SMF を NIS+ で使用する方法については、「NIS+ とサービス管理機能」を参照してください。SMF の概要については、『Solaris のシステム管理 (基本編)』の「サービスの管理 (概要)」を参照してください。詳細については、svcadm(1M) と svcs(1) の各マニュアルページも参照してください。

ルートドメインを確立する

各手順では詳細を説明し、また関連する情報についても説明します。詳細な説明が必要でない場合は、「ルートドメイン構成の要覧」に必要なコマンドをまとめたリストがありますので参照してください。

手順の要約

設定作業の手順を次にまとめます。

1. ルートマスターサーバーにスーパーユーザーとしてログインします。

2. ルートマスターサーバーのドメイン名をチェックします。

3. ルートマスターサーバーのスイッチ構成ファイルをチェックします。

4. オプションで Diffie-Hellman キー長を設定します。

5. nsswitch.conf ファイルに少しでも変更を加えた場合は、ネームサービスキャッシュ (nscd) を再起動します。

6. /etc/.rootkey を削除し、keyserv を再起動します。

7. NIS+ サービスを停止します。

8. NIS+ のファイルを削除しプロセスを終了します。

9. ルートドメインの管理グループを指定します。

10. ルートディレクトリを作成し、ルートマスターサーバーを初期設定します。

11. (省略可能) /lib/svc/method/nisplus ファイルを編集して必要なオプションを追加します。

12. NIS+ デーモンを起動します。

13. ルートオブジェクトが作成されているかどうか確認します。

14. ルートドメインのサブディレクトリとテーブルを作成します。

15. ルートマスターサーバーの DES 資格を作成します。

16. ルートドメインの管理グループを作成します。

17. ルートドメインの管理 (admin) グループにルートマスターを追加します。

18. ルートドメインの公開鍵を更新します。

19. NIS+ サービスを起動します (これにより、キャッシュマネージャと NIS+ デーモンがセキュリティレベル 2 で起動します)。

20. 自分の LOCAL 資格をルートドメインに追加します。

21. 自分の DES 資格をルートドメインに追加します。

22. ほかの管理者の資格を追加します。

23. ルートドメインの管理グループに自分とほかのシステム管理者を追加します。

24. 十分なスワップ空間を割り当てます。

ルートドメインを確立する — 作業マップ

セキュリティについて

NIS+ はルートドメインに対しデフォルトのセキュリティを提供します。デフォルトのセキュリティレベルは、レベル 2 です。実際にユーザーが使用する本稼働のネットワークは、常にセキュリティレベル 2 で運用してください。セキュリティレベル 0 およびレベル 1 は、構成およびテスト目的だけに使用します。本番環境のネットワークは、レベル 0 または 1 で稼働しないでください。

NIS+ のセキュリティシステムは複雑です。NIS+ セキュリティを使い慣れていない場合は、第 11 章「NIS+ のセキュリティの概要」を参照してから NIS+ 環境を構成することをお勧めします。

ルートドメインを確立するための前提条件

作業を開始する前に、以下の条件を満たしていることを確認します。

• ルートマスターサーバー上の /etc/passwd ファイルには、この構成作業でルートドメインに資格を追加するシステム管理者である自分と、ほかのすべてのシステム管理者のエントリが含まれなければなりません。

• サーバーが NIS 互換モードで動作し、Solaris 1.x のクライアントで DNS 転送を使用する場合は、/etc/resolv.conf ファイルを正しく構成しておく必要があります。

• サーバーには、必ずほかのユーザー ID と異なる、固有のマシン名を付けてください。

• サーバーに付けるマシン名には、ドットを使用しないでください。たとえば、マシン名に sales.alpha を使用できません。sales-alpha というマシン名は、使用できます。

必要な情報

ルートドメインを作成するには、次の内容について調べておく必要があります。

• マシン (ルートマスターサーバーにする) のスーパーユーザーのパスワード

• ルートドメイン名

• ルートドメインの管理グループ名

• 自分のユーザー ID とパスワード

• ルートドメインに資格を追加する予定のほかのシステム管理者のユーザー ID

ルートドメインを構成する方法

1. ルートマスターサーバーとするマシン上にスーパーユーザーとしてログインします。

   次の例では、rootmaster をルートマスターサーバーとして、doc.com. をルートドメインとして、それぞれ使用します。

2. ルートマスターサーバーのドメイン名をチェックします。

   domainname コマンドを使用して、ルートマスターサーバーが正しいドメイン名を使用していることを確認します。domainname コマンドは、マシンの現在のドメイン名を返します。

   ---

   注意 –

   またドメイン名とホスト名が同じにならないようにします。たとえば、sales ドメインがある場合は、ホスト名に sales を使用することはできません。同様に、home という名前のマシンを使用する場合は、home という名前のドメインを作成しないでください。これは、サブドメインについても同様です。たとえば、すでにホスト名として west がある場合には、sales.west.doc.com というサブディレクトリを作成することはできません。

   ---

   ドメイン名が正しくない場合は、変更してください。

   rootmaster# domainname strange.domain rootmaster# domainname doc.com rootmaster# domainname rootmaster# doc.com rootmaster# rm -f /etc/defaultdomain rootmaster# domainname > /etc/defaultdomain

   domainname コマンドの最後にドットを付けないでください。domainname コマンドは、NIS+ コマンドではないため、ドメイン名の最後にドットを付ける NIS+ の表記規則には従いません。

   上記の例では、ルートマスターサーバーのドメイン名を strange.domain から doc.com に変更しています。ドメイン名を変更したり設定したりする場合は、doc ではなく doc.com のように、少なくとも 2 つのラベルを付けてください。末尾の要素はインターネットの組織コード (.com など) または地域識別子 (.jp、.uk など) にしてください。

3. ルートマスターサーバーのスイッチ構成ファイルをチェックします。

   ルートマスターサーバーが、NIS 互換モードで動作する場合であっても、NIS+ 用の nsswitch.conf ファイルを使用していることを確認してください。この手順で、ルートマスター用の情報の主情報源が確実に NIS+ テーブルとなります。

   rootmaster# more /etc/nsswitch.conf

   上のコマンドを実行すると、現在の nsswitch.conf ファイルの内容が表示されます。このファイルによって参照される主ネームサービスは nisplus です。ルートマスターサーバーの構成ファイルが主ネームサービスとして nisplus を使用していない場合は、「構成ファイルの変更」を参照して、nisplus を使用する構成ファイルに置き換えてください。

4. オプションで Diffie-Hellman キー長を設定します。

   DES 認証を使用する場合には、Diffie-Hellman キー長をデフォルトの 192 ビットより長くすることができます。たとえば、640 ビットと 192 ビットの両方を許可する場合には、以下を入力します。

   rootmaster# nisauthconf dh640-0 des

5. nsswitch.conf ファイルに少しでも変更を加えた場合は、ネームサービスキャッシュ (nscd) デーモンを再起動します。

   rootmaster# svcs \*name\* online Jan_12 svc:/system/name-service-cache:default rootmaster# svcadm restart system/name-service-cache

   nscd が nsswitch.conf ファイルの内容をキャッシュに格納しているため、ファイルの内容を変更したあとは、nscd を再起動する必要があります。

   詳細な手順については、第 1 章「ネームサービススイッチ」を参照してください。

6. /etc/.rootkey ファイルを削除し、keyserv を再起動します。

   rootmaster# cp /etc/nsswitch.nisplus /etc/nsswitch.conf rootmaster# svcs \*keyserv\* online Jan_12 svc:/network/rpc/keyserv:default rootmaster# svcadm disable network/rpc/keyserv rootmaster# rm -f /etc/.rootkey rootmaster# svcadm enable network/rpc/keyserv

7. NIS+ サービスを停止します。

   rootmaster# svcs \*nisplus\* online Jan_12 svc:/network/rpc/nisplus:default rootmaster# svcadm disable network/rpc/nisplus:default rootmaster# svcs \*nisplus\* disabled Jan_12 svc:/network/rpc/nisplus:default

8. NIS+ のファイルを削除しプロセスを終了します。

   現在作業しているマシンが、以前は NIS+ のサーバーまたはクライアントとして使用したものである場合、/var/nis 内にファイルがあればすべて削除します。この例では、/var/nis 内にはコールドスタートファイルとディレクトリキャッシュファイルがまだ存在します。

   rootmaster# ls /var/nis NIS_COLD_START NIS_SHARED_CACHE rootmaster# rm -rf /var/nis/*

   この手順によって、/var/nis 内に残されたファイル、またはキャッシュマネージャによって格納されたディレクトリオブジェクトは完全に消去されるため、これらがこの設定作業で生成される新しい情報と重複することはありません。/var/nis 内に管理スクリプトを格納していた場合、ルートドメインの設定が終わるまでは、これらを一時的にほかのどこかに格納しておくことができます。

9. ルートドメインの管理グループを指定します。

   手順 16 までは、実際には管理グループを作成しませんが、ここで管理グループの名前を指定する必要があります。手順 13 で管理グループの名前を指定することによって、ルートドメインの org_dir ディレクトリオブジェクト、groups_dir ディレクトリオブジェクト、およびその全テーブルオブジェクトが手順 14 で作成されたときに、適切なデフォルトグループが割り当てられます。

   管理グループを指定するには、環境変数 NIS_GROUP の値に、ルートドメインの管理グループの名前を設定します。次に、csh ユーザー用と、sh/ksh ユーザー用の 2 つの例を示します。どちらも、NIS_GROUP を admin.doc.com. に設定します。

   C シェルの場合

   rootmaster# setenv NIS_GROUP admin.doc.com.

   Bourne シェルまたは Korn シェルの場合

   rootmaster# NIS_GROUP=admin.doc.com. rootmaster# export NIS_GROUP

10. ルートディレクトリを作成し、ルートマスターサーバーを初期設定します。

    この手順では、名前空間内の最初のオブジェクトであるルートディレクトリを作成し、マシンをルートマスターサーバーに変換します。次に示すように、nisinit -r コマンドを使用します。この場合に限り、ドメインのディレクトリオブジェクトの作成と、そのマスターサーバーの初期設定が 1 回の操作で行われます。実際には nisinit -r が nismkdir を実行し、自動的にルートディレクトリを作成します。いずれにしても、ルートマスターの場合を除くと、これら 2 つのプロセスは別々の作業として実行されます。

    rootmaster# nisinit -r This machine is in the doc.com. NIS+ domain Setting up root server ... All done.

    /var/nis/data という名前の UNIX ディレクトリが生成されます。

    /var/nis ディレクトリ内には、root.object というファイルがあります。

    rootmaster# ls -l /var/nis/data -rw-rw-rw- 1 root other 384 date root.object

    これはルートディレクトリオブジェクトではありません。実際には、NIS+ が内部目的で名前空間のルートを記述するために使用するファイルです。NIS+ のルートディレクトリオブジェクトはあとで作成します。

    以降の手順では、この手順で作成されるディレクトリの下に、ほかのファイルが追加されます。UNIX ディレクトリを直接調べることによって、これらのファイルの存在を検証できますが、NIS+ にはもっと便利なコマンドがあります。以下の手順では、必要に応じてこれらのコマンドを実行します。

    ---

    注意 –

    nisinit など NIS+ の構成手順によって作成された /var/nis、/var/nis/data といったディレクトリ、およびその下のファイルは、名前を変更しないでください。Solaris 2.4 以前では、/var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルが存在していました。またサブディレクトリ /var/nis/hostname もありました。Solaris 2.5 では、これらの 2 つのファイル名は trans.log、data.dict とし、サブディレクトリ名は /var/nis/data となります。Solaris リリース 2.5 ではこれらのファイルの内容も変更されており、Solaris リリース 2.4 以前との互換性はなくなっています。したがって、これらのファイルやディレクトリを Solaris 2.4 での名前にしてしまうと、Solaris 2.4、2.5 双方の rpc.nisd で機能しなくなるので名前の変更をしないようにしてください。ディレクトリ名もファイル名も変更しないでください。

    ---

11. (省略可能) /lib/svc/method/nisplus ファイルを編集して必要なオプションを追加します。

    -S 0 オプションを追加する必要があります。適切なテキストエディタを使用します。

    /lib/svc/method/nisplus ファイルの編集方法については、「NIS+ とサービス管理機能」を参照してください。

    -S 0	サーバーのセキュリティレベルを 0 に設定します。現時点ではブートストラップに必要です。  cred テーブルがまだ存在しないので、NIS+ 主体は資格を持つことができません。このため、高いセキュリティレベルを使用すると、サーバーからロックアウトされます。
    -B	DNS 転送をサポートします。
    -Y	NIS 互換モードで NIS+ デーモンを起動します。

12. NIS+ サービスデーモンを起動します。

    rootmaster# svcadm enable network/rpc/nisplus:default

13. ルートオブジェクトが正しく作成されているかどうか確認します。

    名前空間には次のものが作成される必要があります。

    • ルートディレクトリオブジェクト (root.dir)

    • NIS+ サービスを実行するルートマスターサーバー (rootmaster)

    • マスターサーバー用のコールドスタートファイル (NIS_COLD_START)

    • トランザクションログファイル (trans.log)

    • テーブル辞書ファイル (data.dict)

    ルートディレクトリオブジェクトは、手順 10 で作成したディレクトリに格納されます。ディレクトリの内容を確認してください。

    rootmaster# ls -l /var/nis/data -rw-rw-rw- 1 root other 384 date root.object -rw-rw-rw- 1 root other 124 date root.dir

    この時点で、ルートディレクトリは空です。つまり、サブディレクトリはありません。このことを確認するには、nisls コマンドを使用します。

    rootmaster# nisls -l doc.com. doc.com.:

    ただし、いくつかの「オブジェクト」属性は存在し、niscat -o を使用すればこれを調べることができます。

    rootmaster# niscat -o doc.com. Object Name : doc Owner : rootmaster.doc.com. Group : admin.doc.com. Domain : Com. Access Rights : r---rmcdrmcdr---

    なお、ルートディレクトリオブジェクトは、「所有者」と「グループ」の両方には完全な (読み取り、変更、作成、削除) 権利を与え、「その他」と「未認証」には読み取り権だけを与えます。ディレクトリオブジェクトがこれらの権利を提供しない場合、nischmod コマンドを使用して変更できます。

    NIS+ デーモンが動作していることを確認するには、ps コマンドを使用します。

    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

    ルートマスターサーバーのインターネットアドレスが (最終的には公開鍵も) 収められているルートドメインの NIS_COLD_START ファイルは、/var/nis 内に置かれます。この内容を調べるための NIS+ コマンドはありませんが、この内容はサーバーのディレクトリキャッシュ (NIS_SHARED_DIRCACHE) に保存されます。これらの内容は、/usr/lib/nis/nisshowcache コマンドで調べることができます。

    また、トランザクションログファイル (trans.log) と辞書ファイル (data.dict) も作成されます。マスターサーバーのトランザクションログは、前回の更新以降マスターサーバーとそのすべての複製サーバーによって実行されたすべてのトランザクションを格納しています。この内容を調べるには、nislog コマンドを使用します。辞書ファイルは、NIS+ が内部目的に使用するものであり、システム管理者には関係ありません。

14. ルートドメインのサブディレクトリとテーブルを作成します。

    この手順では、ルートディレクトリオブジェクトの下に、org_dir ディレクトリと groups_dir ディレクトリ、および NIS+ テーブルを追加します。nissetup ユーティリティを使用してください。NIS 互換ドメインの場合、必ず -Y フラグを付けてください。両方の場合の例を次に示します。

    標準 NIS+ のみの場合

    rootmaster# /usr/lib/nis/nissetup

    NIS 互換のみの場合

    rootmaster# /usr/lib/nis/nissetup -Y

    このユーティリティによって追加されたオブジェクトを表示すると、次のようになります。

    rootmaster# /usr/lib/nis/nissetup org_dir.doc.com. created groups_dir.doc.com. created auto_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

    -Y オプションは、標準の NIS+ ドメインと同じテーブルとサブディレクトリを作成します。しかし、NIS クライアントからの未認証要求が passwd テーブルに含まれる暗号化されたパスワードにアクセスできるようにするため、passwd テーブルへの読み取り権を未認証クラスに割り当てます。

    現在、ルートディレクトリには 2 つのサブディレクトリがあります。

    rootmaster# nisls doc.com. doc.com.: org_dir groups_dir

    サブディレクトリとテーブルのオブジェクト属性を調べるには、niscat -o コマンドを使用してください。また、フラグなしで niscat オプションを使用して、このテーブル内の情報を調べることもできますが、この時点では空です。

15. ルートマスターサーバーの DES 資格を作成します。

    ルートマスターサーバーは、自分の要求が認証されるために、DES 資格を必要とします。これらの資格を作成するには、次に示すように nisaddcred コマンドを使用します。プロンプトに対して、サーバーの root パスワードを入力します。

    rootmaster# nisaddcred des DES principal name: unix.rootmaster@doc.com Adding key pair for unix.rootmaster@doc.com (rootmaster.doc.com.). Enter login password: Wrote secret key into /etc/.rootkey

    サーバーの root パスワードと異なるパスワードを入力した場合、警告メッセージとパスワードを再入力するプロンプトが表示されます。

    Enter login password: nisaddcred: WARNING: password differs from login password. Retype password:

    それでも同じパスワードを再び入力すると、NIS+ は資格を作成します。この新しいパスワードは /etc/.rootkey に格納され、キーサーバーが起動時に使用します。キーサーバーに新しいパスワードをすぐに登録するには、keylogin -r を実行します。第 12 章「NIS+ 資格の管理」を参照してください。

    最終的に自分のログインパスワードを使用する場合は、Control-C を押して、この手順をやり直します。Control-C を押さずにメッセージに従って自分のログインパスワードを入力すると、別の目的のエラーメッセージが表示され、混乱を招くことがあります。

    nisaddcred: WARNING: password differs from login password. Retype password: nisaddcred: password incorrect. nisaddcred: unable to create credential.

    この手順の結果として、ルートサーバーの非公開鍵と公開鍵がルートドメインの cred テーブル (cred.org_dir.doc.com.) に格納され、その非公開鍵は /etc/.rootkey. に格納されます。cred テーブル内の資格を確認するには、niscat コマンドを使用します。デフォルトのドメイン名は doc.com. であるため、cred テーブルの完全指定名を入力する必要はありません。接尾辞の org_dir で十分です。ルートマスターの資格を探すためには、その Secure RPC ネット名を探してください。

16. ルートドメインの管理グループを作成します。

    この手順では、手順 9 で指定された管理グループを作成します。nisgrpadm コマンドに -c オプションを付けて実行してください。次の例では admin.doc.com. グループを作成します。

    rootmaster# nisgrpadm -c admin.doc.com. Group admin.doc.com. created.

    この手順ではグループを作成するだけであり、そのメンバー名の指定は行いません。これについては、手順 17 で行います。グループのオブジェクト属性を見るには、niscat -o を使用します。しかし、グループ名では必ず groups_dir を使用します。 たとえば、次のようになります。

    doc.com. Object Name : admin Directory : groups_dir.doc.com Owner : rootmaster.doc.com. Group : admin.doc.com. Domain : groups_dir.doc.com. Access Rights : ----rmcdr---r--- Time to Live : 1:0:0 Object Type : GROUP Group Flags : Group Members :

17. ルートドメインの管理 (admin) グループにルートマスターを追加します。

    この時点では、このルートマスターサーバーは DES 資格をもつ唯一の NIS+ 主体であるため、管理グループに追加すべき唯一のメンバーです。今度は、nisgrpadm コマンドに -a オプションを付けて実行します。第 1 引数はグループ名、第 2 引数はルートマスターサーバー名です。この例では doc.com ドメインに rootmaster.doc.com. を追加します。

    rootmaster# nisgrpadm -a admin.doc.com. rootmaster.doc.com. Added rootmaster.doc.com. to group admin.doc.com.

    ルートマスターがこの管理グループに属していることを確認するには、nisgrpadm コマンドを、-l オプションを指定して実行します。第 17 章「NIS+ グループの管理」を参照してください。

    ---

    注 –

    nisgrpadm などのグループ関連コマンドでは、名前に groups_dir サブディレトリを含める必要はありません。niscat などのコマンドの場合、NIS+ オブジェクト一般に対して動作するように設計されているため、このディレクトリを含む必要があります。グループ関連コマンドは、groups_dir サブディレクトリを対象としています。

    ---

    rootmaster# nisgrpadm -l admin.doc.com. Group entry for admin.doc.com. group: Explicit members: rootmaster.doc.com. No implicit members No recursive members No explicit nonmembers No implicit nonmembers No recursive nonmembers

18. ルートドメインの公開鍵を更新します。

    ディレクトリオブジェクトは、すでに DES 資格をもつ NIS+ 主体によって作成されるのが普通です。しかしこの場合、cred テーブルを作成するまでは、自分の資格を格納する親ドメインがないため、ルートマスターサーバーは DES 資格を獲得できません。その結果、root、org_dir、および groups_dir という 3 つのディレクトリオブジェクトには、ルートマスターサーバーの公開鍵のコピーがありません。これについては、niscat -o コマンドにどれかのディレクトリオブジェクトを指定して実行することによって確認できます。「Public Key:」フィールドを探してください。手順については、第 18 章「NIS+ ディレクトリの管理」を参照してください。

    ルートマスターサーバーの公開鍵を、ルートドメインの cred テーブルからこれら 3 つのディレクトリオブジェクトに伝達するには、次に示すように、各ディレクトリオブジェクトに対して /usr/lib/nis/nisupdkeys ユーティリティを使用します。

    rootmaster# /usr/lib/nis/nisupdkeys doc.com. rootmaster# /usr/lib/nis/nisupdkeys org_dir.doc.com. rootmaster# /usr/lib/nis/nisupdkeys groups_dir.doc.com.

    コマンドを実行するたびに、次のような確認メッセージが表示されます。

    Fetch Public key for server rootmaster.doc.com. netname = 'unix.rootmaster@doc.com.' Updating rootmaster.doc.com.'s public key. Public key:

    これらのディレクトリを (niscat -o を使用して) 表示すると、「Public key:」フィールドに 1 つまたは複数のエントリが見つかります。

    Public key: Diffie-Hellman (192 bits)

19. NIS+ サービスを再起動します。

    これで、ルートマスターサーバーには DES 資格があり、ルートディレクトリオブジェクトにはルートマスターの公開鍵のコピーがあるため、ルートマスターを再起動すると、自動的にセキュリティレベル 2 で起動されます。

    サービス管理機能では、/var/nis/NIS_COLD_START ファイルが検出されると、NIS+ サービスを有効にしたときに nis_cachemgr を自動的に起動します。

    NIS と互換性のあるルートドメインの場合は、必ず /lib/svc/method/nisplus ファイルを編集して -Y フラグを追加してください。詳細については、「NIS+ とサービス管理機能」を参照してください。

    rootmaster# svcs \*nisplus\* online Jan_12 svc:/network/rpc/nisplus:default rootmaster# svcadm restart network/rpc/nisplus:default

    セキュリティレベル 2 はデフォルトであるため、-S 2 フラグは不要です。

    ---

    注 –

    実際にユーザーが存在するネットワークは、常にセキュリティレベル 2 で運用してください。セキュリティレベル 0 およびレベル 1 は、設定およびテスト目的だけに使用します。本番環境のネットワークは、レベル 0 または 1 で稼働しないでください。

    ---

20. 自分の LOCAL 資格をルートドメインに追加します。

    ユーザーはルートドメインの cred テーブルに対するアクセス権がないため、この動作はスーパーユーザーとして実行しなければなりません。さらに、「前提条件」で説明したように、ルートマスターの /etc/passwd ファイルには自分用のエントリが必要です。nisaddcred コマンドに -p と -P フラグを付けて使用します。その構文と例を次に示します。

    nisaddcred -p uid -P principal-name local

    principal-name はシステム管理者のログイン名とドメイン名で構成されます。この例では、UID が 11177 で NIS+ 主体名が topadmin.doc.com.のシステム管理者用の LOCAL 資格を追加します。

    rootmaster# nisaddcred -p 11177 -P topadmin.doc.com. local

    nisaddcred コマンドの詳細については、第 12 章「NIS+ 資格の管理」を参照してください。

21. 自分の DES 資格をルートドメインに追加します。

    ここでも nisaddcred コマンドを使用しますが、次のような構文となります。

    nisaddcred -p secure-RPC-netname -P principal-name des

    secure-RPC-netname は、接頭辞 unix に自分のユーザー ID、@ 記号、およびドメイン名を付けて構成しますが、最後にドットは付けません。principal-name は LOCAL 資格の場合と同じで、ログイン名にドメイン名を付け、さらに最後にドットを付けます。

    rootmaster# nisaddcred -p unix.11177@doc.com -P topadmin.doc.com. des Adding key pair for unix.11177@doc.com (topadmin.doc.com.). Enter login password:

    ログインパスワードの入力後に「password that differs from the login password」という警告が表示され、入力したパスワードが正しいログインパスワードである場合は、このエラーメッセージを無視してください。NIS+ がパスワードの格納されている、保護された /etc/shadow ファイルを期待どおりに読み込めないため、このメッセージが表示されます。ユーザーパスワード情報を /etc/passwd ファイルに格納していない場合、このメッセージは表示されません。

22. ほかのシステム管理者の資格を追加します。

    そのルートドメインで作業するほかのシステム管理者の LOCAL 資格と DES 資格を追加します。これには 以下の方法があります。

    • ほかの管理者に一時的な資格を作成する場合は、NIS+ モードで実行されている Solaris 管理コンソール (使用できる場合) を使用すると簡単です。

    • 2 つめは、ほかの管理者にその管理者自身の資格を追加するよう要求する方法です。この方法は、スーパーユーザーとして実行する必要があります。ユーザー ID が 33355 で主体名が miyoko.doc.com. の管理者の資格を追加する例を次に示します。

      rootmaster# nisaddcred -p 33355 -P miyoko.doc.com. local rootmaster# nisaddcred -p unix.33355@doc.com -P miyoko.doc.com. des Adding key pair for unix.33355@doc.com (miyoko.doc.com.). Enter login password:

    • 3 つめは、ダミーのパスワードを使用して、ほかの管理者に一時的な資格を作成する方法です。ほかの管理者、この例では miyoko は、NIS+ passwd テーブルにエントリがなければなりません。エントリがない場合は、まず nistbladm を使用して、必ずエントリを作成してください。次の例に、その手順を示します。

      rootmaster# nistbladm -D owner=miyoko.doc.com. name=miyoko uid=33355 gcos=miyoko home=/home/miyoko shell=/bin/tcsh passwd.org_dir rootmaster# nisaddent -a -f /etc/passwd.xfr passwd rootmaster# nisaddent -a -f /etc/shadow.xfr shadow rootmaster# nisaddcred -p 33355 -P miyoko.doc.com. local rootmaster# nisaddcred -p unix.33355@doc.com -P miyoko.doc.com. des Adding key pair for unix.33355@doc.com (miyoko.doc.com.). Enter miyoko's login password: nisaddcred: WARNING: password differs from login passwd. Retype password: rootmaster# nischown miyoko.doc.com. '[name=miyoko],passwd.org_dir'

      この場合、最初の nisaddent で passwd テーブルにエントリが生成されます (shadow 列は除く)。次の nisaddent により、shadow 列が生成されます。各システム管理者は、chkey コマンドを使用することによって、自分のネットワークパスワードを後で変更できます。この手順については、第 12 章「NIS+ 資格の管理」を参照してください。

23. ルートドメインの管理グループに自分とほかのシステム管理者を追加します。

    この手順を実行するには、ほかのシステム管理者がダミーパスワードを変更するまで待つ必要はありません。-a オプションを付けて nisgrpadm コマンドを実行します。最初の引数はグループ名であり、残りの引数はシステム管理者の名前です。この例では、topadmin と miyoko の 2 人のシステム管理者を admin.doc.com. グループに追加します。

    rootmaster# nisgrpadm -a admin.doc.com. topadmin.doc.com. miyoko.doc.com. Added topadmin.doc.com. to group admin.doc.com. Added miyoko.doc.com. to group admin.doc.com.

24. NIS+ テーブルを格納するための、十分なスワップ空間を割り当てます。

    スワップ空間は、rpc.nisd の最大サイズの 2 倍にする必要があります。rpc.nisd が使用するメモリー量を調べるには、次のコマンドを実行してください。

    rootmaster# /usr/lib/nis/nisstat

    rpc.nisd は、特定の条件のもとでは、自らのコピーを作成してフォークします。メモリーが不足すると、rpc.nisd は正しく動作しません。

    また、NIS+ テーブルに必要なメモリーとスワップ空間のサイズも計算できます。たとえば、NIS+ テーブル内に、180,000 人のユーザーと 180,000 台のホストがある場合、これらの 2 つのテーブルが占有するメモリーは、約 190M バイトです。180,000 人のユーザーと 180,000 台のホストに資格を追加する場合、cred テーブルには、540,000 のエントリ (ユーザーごとにローカルの資格と DES の資格、合わせて 2 つの資格、ホストごとに 1 つの資格) が入ります。そのため、cred テーブルが占有するメモリーは、約 285M バイトになります。この例では、rpc.nisd に必要なメモリー容量は、少なくとも、190M バイト + 285M バイト = 475M バイトになります。この結果、少なくとも 1G バイトのスワップ空間が必要になります。また、rpc.nisd 全体をすべてメモリー内に保持するには、少なくとも 500M バイトが必要です。

ルートドメイン構成の要覧

ルートドメインの構成に必要な手順を表 5–2 にまとめます。このまとめは、簡単な場合を想定しています。このまとめを参考として使用する前に、作業全体の説明を十分に理解しておいてください。また、ここでは、各コマンドに対するサーバーの応答を示していません。

第 6 章 NIS+ クライアントの構成

この章では、NIS+ コマンド群を使用した 3 通りの初期設定方法で NIS+ クライアントを設定する手順を説明します。この章の内容は、NIS+ モード、NIS+ 互換モードを問わず、ルートドメイン、サブドメインに共通するものです。

NIS+ は、将来のリリースではサポートされなくなる可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 リリース以降で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ クライアントの設定の概要

この章では、標準の NIS+ ドメインと NIS 互換ドメイン内のクライアントを構成する方法を説明します。各手順では詳細を説明し、また関連する情報についても説明します。詳しい手順の説明が必要ない場合は、表 6–6 で必要なコマンドの一覧を参照してください。

NIS+ クライアントを設定する作業は、この章で説明する NIS+ のコマンドセットを使用する方法よりも、パート I で説明した NIS+ 設定スクリプトを使用する方が簡単です。この章で説明する方法は、NIS+ に精通した管理者や、設定スクリプトでは提供されない標準以外の機能や構成を必要とする管理者だけが使用してください。可能な場合は Solaris 管理コンソール を使用すると、NIS+ クライアントマシンの追加や設定の作業が簡単にできます。

クライアントを設定する作業のうち、手順 11 では、ブロードキャスト、ホスト名、コールドスタートファイルのどれを使用するかを選択してください。 それぞれ実装方法が異なるため、各作業について別々に説明します。クライアントを初期設定したあとは、手順 12 に戻ってクライアントの設定を続けてください。

この章の最後の作業では、マシンのドメイン名を変更する方法を取り上げています。

クライアントの設定

ここでは、ルートドメイン内であるかどうかとは関係なく、一般的な NIS+ クライアントの構成方法を説明します。ここでの説明は、通常の NIS+ クライアント、および後で NIS+ サーバーとなるクライアントに当てはまります。また、標準の NIS+ ドメイン内、および NIS 互換ドメイン内のクライアントにも当てはまります。

またドメイン名とホスト名が同じにならないようにします。たとえば、sales ドメインがある場合は、ホスト名に sales を使用することはできません。同様に、home というホスト名がある場合には、ドメイン名に home を使用できません。これは、サブドメインについても同様です。たとえば、すでにホスト名として west がある場合には、sales.west.doc.com というサブドメインを作成することはできません。

NIS+ クライアントの設定には、次の作業が必要です。

• クライアントの資格の作成

• マシンの準備

• マシンを NIS+ クライアントとして初期設定

ただし、ルートドメインの設定と同様、クライアントの設定も、これら 3 つの作業を順番に実行するような単純なものではありません。構成手続を実行しやすくするため、これらの作業を個々の手順に分割し、次に示すように、これらの手順をもっとも効率的な順に並べてあります。

1. ドメインのマスターサーバーにログインします。

2. 新しいクライアントマシン用の DES 資格を作成します。

3. マスターサーバーで使用されている Diffie-Hellman キー長を確認します。

4. クライアントにスーパーユーザーとしてログインします。

5. クライアントに新しいドメイン名を設定します。

6. nscd の停止と再起動を行います。

7. クライアントの nsswitch.conf ファイルの設定を確認します。

8. クライアントの Diffie-Hellman キーを設定します。

9. NIS+ のファイルを削除し、プロセスを終了します。

10. クライアントを初期設定します。

11. /etc/.rootkey ファイルを削除し、keyserv デーモンを再起動します。

12. keylogin を実行します。

13. クライアントを再起動します。

クライアント構成時のセキュリティについて

クライアントの設定には、セキュリティ上の主な必要要件が 2 つあります。つまり、システム管理者とクライアントの両方が、適切な資格とアクセス権を持つことです。そうでない場合、クライアントがセキュリティレベル 2 で実行しているドメインの資格を入手する唯一の方法は、クライアントのホームドメイン内での有効な DES 資格と cred テーブルに対する変更権とを持つシステム管理者が資格を作成することです。システム管理者は DES 資格を、クライアントのホームドメイン内、または自分のホームドメイン内に所持できます。

システム管理者がクライアントの資格を作成すると、そのクライアントは構成プロセスを終了できます。しかしクライアントは、ホームドメインのディレクトリオブジェクトに対する読み取り権を必要とします。第 5 章「ルートドメインの設定」または第 8 章「ルート以外のドメインの構成」の手順に従ってクライアントのホームドメインを構成した場合、ディレクトリオブジェクトの作成に使用した NIS+ コマンド (nisinit と nismkdir) によって、読み取り権がその他のクラスに提供されています。

ディレクトリオブジェクトのアクセス権をチェックするには、niscat-o コマンドを使用します。このコマンドは、アクセス権などのディレクトリ属性を表示します。次にその例を示します。

rootmaster# niscat -o doc.com.
ObjectName : Doc
Owner : rootmaster.doc.com.
Group : admin.doc.com.
Domain : Com.
Access Rights : r---rmcdr---r---

ディレクトリオブジェクトのアクセス権は、オブジェクトに対する変更権を持っている場合は、nischmod コマンドを使用して変更できます。詳細については、第 15 章「NIS+ のアクセス権の管理」を参照してください。

クライアントの資格を構成するための前提条件

クライアントの資格を設定するシステム管理者は、次の条件をすべて満たしている必要があります。

• 有効な DES 資格を持っていること

• クライアントのホームドメインにある cred テーブルを修正する権利を持っていること

クライアントは次の条件をすべて満たしている必要があります。

• ホームドメインのディレクトリオブジェクトに対する読み取り権を持っていること

• クライアントのホームドメインがあらかじめ構成されており、NIS+ を実行していること

• マスターサーバーの /etc/hosts ファイル、または /etc/inet/ipnodes ファイル、あるいはドメインの hosts テーブルまたは ipnodes テーブルの中にエントリが存在すること

• マシン名が、どのユーザーの ID とも重複しておらず、固有であること

• マシン名にドットが含まれていないこと。たとえば、sales.alpha というマシン名は使用できませが、sales-alpha なら使用できます。

必要な情報

• クライアントのホームドメイン名

• クライアントとなるマシンのスーパーユーザーのパスワード

• クライアントのホームドメイン内にある NIS+ サーバーの IP アドレス

クライアントの設定 — 作業マップ

NIS+ サービスは、サービス管理機能 (SMF) によって管理されます。このサービスに対する有効化、無効化、再起動などの管理操作を実行するには、svcadm コマンドを使用します。SMF を NIS+ で使用する方法については、「NIS+ とサービス管理機能」を参照してください。SMF の概要については、『Solaris のシステム管理 (基本編)』の「サービスの管理 (概要)」を参照してください。詳細については、svcadm(1M) と svcs(1) の各マニュアルページも参照してください。

NIS+ クライアントを設定する方法

1. ドメインのマスターサーバーにログインする

   スーパーユーザーとして、または自分自身のユーザー名でログインします。どちらでログインするかは、どちらの NIS+ 主体がドメインの cred テーブルに資格を追加するための適切なアクセス権を所有しているのかに依存します。

2. 新しいクライアントマシン用の DES 資格を作成します。

   nisaddcred コマンドを引数 -p と -P を付けて実行します。構文は、次のとおりです。

   nisaddcred -p secure-RPC-netname principal-name des [domain]

   secure-RPC-netname は、接頭辞 unix に、クライアントのホスト名、@ 記号、およびクライアントのドメイン名を付けて構成しますが、最後にドットは付けません。principal-name は、クライアントのホスト名とドメイン名によって構成され、最後にドットを付けます。このクライアントの所属するドメインが、コマンドを入力したサーバーとは異なる場合、2 番目の引数の後にクライアントのドメイン名を追加します。

   この例では、doc.com. ドメイン内の client1 という名前のクライアントマシンに対する DES 資格を追加します。

   rootmaster% nisaddcred -p unix.client1@doc.com -P client1.doc.com. des Adding key pair for unix.client1@doc.com (client1.doc.com.). Enter client1.doc.com.'s root login passwd: Retype password:

   nisaddcred コマンドの詳細については、第 12 章「NIS+ 資格の管理」を参照してください。

3. マスターサーバーで使用される Diffie-Hellman キー長を確認します。

   たとえば、以下のようになります。

   rootmaster% nisauthconf dh640-0 des

4. クライアントにスーパーユーザーとしてログインします。

   これでクライアントマシンに資格ができたため、ユーザーはマスターサーバーからログアウトし、クライアント自体から作業を開始できます。この作業はローカルでもリモートでも可能です。

5. クライアントに新しいドメイン名を設定します。

   クライアントのドメイン名を設定する (変更する) 方法については、「マシンのドメイン名を変更する」を参照し、次の手順 6 に戻ります。

6. クライアントの nsswitch.conf ファイルをチェックします。

   クライアントが NIS+ バージョンの nsswitch.conf ファイルを使用していることを確認します。これによって、クライアント情報の 1 次ソースが NIS+ テーブルということが確認できます。NIS+ スイッチファイルの詳細については、例 1–1 を参照してください。

7. nsswitch.conf ファイルに少しでも変更を加えた場合 (または新規にファイルにコピーした場合)、ここで nscd を再起動する必要があります。

   client1# svcadm restart /system/name-service-cache

   キーサーバーをこの時点で停止および再起動する必要はありません。手順 12 で行います。

8. 手順 3 の情報を使用して、Diffie-Hellman キー長を設定します。

   たとえば、次のようにします。

   client# nisauthconf dh640-0 des

9. NIS+ サービスを停止します。

   client1# svcadm disable network/rpc/nisplus:default client1# svcs \*nisplus\* disabled Jan_12 svc:/network/rpc/nisplus:default

10. NIS+ のファイルを削除しプロセスを終了します。

    現在作業しているマシンが、以前は NIS+ のサーバーまたはクライアントとして使用したものである場合、/var/nis 内にファイルがあればすべて削除します。この例では、/var/nis 内にコールドスタートファイルとディレクトリキャッシュファイルがまだ存在します。

    client1# ls /var/nis NIS_COLD_START NIS_SHARED_CACHE client1# rm -rf /var/nis/*

    /var/nis 内に残されたファイル、またはキャッシュマネージャによって保存されたディレクトリオブジェクトは、この手順によって完全に消去されます。したがって、この構成プロセスで生成された新しい情報と重複することはありません。/var/nis 内に管理スクリプトを 1 つでも格納していた場合、ルートドメインの設定が終わるまでは、それらを一時的にほかのどこかに格納しておくことをお勧めします。

11. クライアントを初期設定します。

    クライアントを初期設定するには、次の 3 つの方法があります。ホスト名、コールドスタートファイル、ブロードキャストによる方法です。3 つの方法のうち、いずれかを選択して実行します。クライアントの初期設定が終了したら、手順 12 に進みます。

12. /etc/.rootkey ファイルを削除し、keyserv デーモンを再起動します。

    この手順では、非公開鍵をキーサーバー上に格納します。

    client1# cp /etc/nsswitch.nisplus /etc/nsswitch.conf client1# svcs \*keyserv\* online Jan_12 svc:/network/rpc/keyserv:default client1# svcadm disable network/rpc/keyserv client1# rm -f /etc/.rootkey client1# svcadm enable network/rpc/keyserv

DNS 転送の設定

NIS+ クライアントの DNS 転送機能を有効にするには

1. スーパーユーザーとしてログインします。

2. /etc/resolve.conf ファイルの hosts 行を構成します。たとえば、hosts:nisplus dns files とします。

該当するサーバー上に /etc/resolve.conf ファイルが存在する場合、この NIS 実装では DNS へ要求を転送するために、ypstart によって ypserv デーモンが -d オプション付きで「自動的に」起動されます。

マシンのドメイン名を変更する

この作業では、マシンのドメイン名を変更します。マシンのドメイン名は通常インストール時に設定されるため、domainname コマンドを引数なしで実行して、マシンのドメイン名をチェックしてからこの作業を実行してください。

マシンのドメイン名変更時のセキュリティについて

この作業は、ドメイン名を変更するマシン上のスーパーユーザーとして実行しなければなりません。

必要な情報

• マシンのスーパーユーザーのパスワード

• 新しいドメイン名

マシンのドメインの変更 - 作業マップ

クライアントのドメイン名を変更する方法

1. マシンにログインして、スーパーユーザーになります。

   この例では、マシンに client1 を、新しいドメイン名に doc.com. を使用します。

   client1% su Password:

2. マシンのドメイン名を変更します。

   domainname コマンドを使用して新しい名前を入力します。名前の最後にドットを入力しないでください。たとえば、マシンのドメインを doc.com に変更する場合、次のように入力します。

   client1# domainname doc.com

   マシンが NIS クライアントの場合は、NIS サービスを受けることはできません。

3. 結果を確認します。

   今度は、引数を付けずに domainname コマンドを実行し、サーバーの現在のドメインを表示させます。

   client1# domainname doc.com

4. 新しいドメイン名を保存します。

   domainname コマンドの出力を /etc/defaultdomain ファイルに書き込みます。

   client1# domainname > /etc/defaultdomain

5. 適当な時に、マシンを再起動します。

   /etc/defaultdomain ファイルに新しいドメイン名を入力した後でも、一部のプロセスは依然として古いドメイン名で動作している可能性があります。すべてのプロセスに新しいドメイン名を確実に使用させるため、マシンを再起動します。

   この作業は、ほかのいくつかの作業の流れの中で行うものです。再起動は、マシンでのすべての作業が完了したことを確認してから行なってください。確認を怠ると、何度も再起動が必要になる可能性があります。

   mountd などのデーモンを個別に再起動すれば、NFS の問題が解決されることがあります。ただし、構成の変更をデーモン間で同期化するために、マシンを再起動することを強くお勧めします。マシンを再起動することによって、構成の変更の非同期が原因で発生するアプリケーションの失敗を最小限に抑えることができます。

NIS+ クライアントを初期設定する

NIS+ クライアントを初期設定する方法には、以下の 3 つの種類があります。

• ブロードキャストを使用する方法 (「ブロードキャストにより初期設定する」を参照)

• ホスト名を使用する方法 (「ホスト名により NIS+ クライアントを初期設定する」を参照)

• コールドスタートファイルを使用する方法 (「コールドスタートファイルを使用してクライアントを初期設定する」を参照)

ブロードキャストにより初期設定する

この方法では、クライアントの存在するサブネット上に IP ブロードキャストを送信して NIS+ クライアントを「初期化」します。

初期化の方法としてはこれがもっとも簡単ですが、もっとも安全性の低い方法でもあります。ブロードキャストに応答した NIS+ サーバーはクライアントが自分自身のコールドスタートファイルに格納する必要がある情報 (サーバーの公開鍵など) をすべて送信します。おそらくブローキャストに応答するのは NIS+ サーバーだけですが、クライアントからは、ブロードキャストに応答したマシンが確かに信用できるサーバーなのかどうか確認できません。 そのため、この方法は小規模で、セキュリティが確保されたサイトでだけ使用することをお勧めします。

クライアント初期設定時のセキュリティについて

この作業は、クライアント上のスーパーユーザーとして実行しなければなりません。

クライアントを初期設定するための前提条件

クライアントと同じサブネット上に、少なくとも 1 台の NIS+ サーバーが存在しなければなりません。クライアントは、マスターサーバーで使用するのと同じ Diffie-Hellman キー長を使用する必要があります。nisauthconf(1M) を参照してください。

必要な情報

クライアントのスーパーユーザーのパスワードが必要です。

NIS+ クライアントを初期設定する — 作業マップ

ブロードキャストによりクライアントを初期設定する方法

クライアントを初期設定します。

この手順では、クライアントを初期設定し、その /var/nis ディレクトリ内に NIS_COLD_START ファイルを作成します。nisinit コマンドに -c と -B のオプションを付けて実行します。

client1# nisinit -c -B
This machine is in the doc.com. NIS+ domain.
Setting up NIS+ client ...
All done.

同じサブネット上の NIS+ サーバーがブロードキャストに応答し、その位置情報をクライアントのコールドスタートファイルに追加します。

ホスト名により NIS+ クライアントを初期設定する

クライアントをホスト名によって初期化する場合、信頼できるサーバーの IP アドレスを明確に指摘します。そしてこのサーバー名、位置情報、公開鍵がクライアントのコールドスタートファイルに格納されます。

この方法は、クライアントがサーバーの IP アドレスを指定するので、自分で自分を識別してくるサーバーに応答するブロードキャストよりも安全です。しかし、クライアントと信頼できるサーバーの間にルーターが介在している場合、正しい IP アドレスへのメッセージを横取りし、不正なサーバーに送ることもあり得ます。

ホスト名によりクライアントを初期設定する場合のセキュリティについて

この作業は、クライアント上のスーパーユーザーとして実行しなければなりません。

ホスト名によりクライアントを初期設定するための前提条件

• NIS+ サービスはクライアントのドメインで実行されていなければなりません。

• クライアントは、/etc/hosts ファイル内に信頼できるサーバーのエントリを持っていなければなりません。

• クライアントは、マスターサーバーで使用するのと同じ Diffie-Hellman キー長を使用する必要があります。nisauthconf(1M) を参照してください。

必要な情報

信頼できるサーバー名と IP アドレスが必要です。

ホスト名により NIS+ クライアントを初期設定する — 作業マップ

ホスト名によりクライアントを初期設定する方法

1. クライアントの /etc/hosts ファイルまたは /etc/inet/ipnodes ファイルを確認します。

   クライアントが、信頼できるサーバーのエントリを持っていることを確認します。

2. クライアントを初期設定します。

   この手順では、クライアントを初期設定し、その /var/nis ディレクトリ内に NIS_COLD_START ファイルを作成します。nisinit コマンドに -c と -H のオプションを付けて実行します。次の例では、信頼できるサーバーとして rootmaster を使用します。

   Client1# nisinit -c -H rootmaster This machine is in the doc.com. NIS+ domain. Setting up NIS+ client ... All done.

   nisinit ユーティリティは、クライアントの /etc/hosts ファイルまたは /etc/inet/ipnodes ファイル内でサーバーのアドレスを探します。したがって、サーバーにドメイン名を付加しないでください。ドメイン名を付加した場合、このユーティリティはサーバーのアドレスを見つけることができません。

コールドスタートファイルを使用してクライアントを初期設定する

ここでは、NIS+ クライアントを初期設定するために、別の NIS+ クライアント (できれば同じドメインから) の COLD_START を使用します。NIS+ クライアントを設定する方法としてはこれがもっとも安全です。これにより、クライアントは、信頼できるサーバーから確実に NIS+ 情報を得ることができます。これはホスト名やブロードキャストによる初期化では保証されません。

コールドスタートファイルを使用してクライアントを初期設定する場合のセキュリティについて

この作業は、クライアント上のスーパーユーザーとして実行しなければなりません。

コールドスタートファイルを使用してクライアントを初期設定するための前提条件

COLD_START ファイルに指定されたサーバーは、すでに構成されており、NIS+ を実行していなければなりません。

クライアントは、マスターサーバーで使用するのと同じ Diffie-Hellman キー長を使用する必要があります。nisauthconf(1M) を参照してください。

必要な情報

コピーする COLD_START ファイルの名前と位置が必要です。

コールドスタートファイルを使用して NIS+ クライアントを初期設定する —作業マップ

COLD_START 経由で NIS+ クライアントを初期設定する方法

1. ほかのクライアントの COLD_START ファイルをコピーします。

   ほかのクライアントの COLD_START ファイルを、新しいクライアントのディレクトリにコピーします。これを行うには、クライアント上のスーパーユーザーとしてではなく、自分のユーザー名でログインしている間に行う方が簡単です。クライアントを初期設定する前に、必ずスーパーユーザーになってください。

   ただし、NIS_COLD_START ファイルを /var/nis にコピーしないでください。初期設定中にこのファイルは上書きされます。次の例では、client1 のコールドスタートファイルを、初期設定されていない client2 の /tmp ディレクトリにコピーします。

   client2# exit client2% rcp client1:/var/nis/NIS_COLD_START /tmp client2% su

2. COLD_START ファイルからクライアントを初期設定します。

   次に示すように、nisinit コマンドに -c と -C のオプションを付けて実行します。

   client2# nisinit -c -C /tmp/NIS_COLD_START This machine is in the doc.com. NIS+ domain. Setting up NIS+ client ... All done.

NIS+ クライアント構成の要覧

クライアントの構成に必要な手順を表 6–6 にまとめます。クライアントは doc.com ドメインにある client1 とします 。これはもっとも簡単なケースを想定しているため、このまとめを参考用として使用するには、その前に自分の実際の作業の詳細を理解することが必要です。簡略化のため、ここでは各コマンドに対するサーバーの応答を示していません。

第 7 章 NIS+ サーバーの構成

この章では、NIS+ コマンドセットを使って NIS+ サーバーを設定する手順と、既存の NIS+ ドメインに複製サーバーを追加する手順を説明します。

NIS+ は、将来のリリースではサポートされなくなる可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 リリース以降で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ サーバーを設定する

NIS+ サーバーの初期設定は、この章で説明する NIS+ コマンドよりも、NIS+ スクリプトを使用した方が簡単に行うことができます。この章で説明する方法は、NIS+ に精通した管理者や、設定スクリプトでは提供されない標準以外の機能や構成を必要とする管理者だけが使用してください。

NIS+ サービスは、サービス管理機能 (SMF) によって管理されます。このサービスに対する有効化、無効化、再起動などの管理操作を実行するには、svcadm コマンドを使用します。SMF を NIS+ で使用する方法については、「NIS+ とサービス管理機能」を参照してください。SMF の概要については、『Solaris のシステム管理 (基本編)』の「サービスの管理 (概要)」を参照してください。詳細については、svcadm(1M) と svcs(1) の各マニュアルページも参照してください。

標準構成と NIS 互換構成の相違 (NIS+ サーバー)

NIS 互換の NIS+ サーバーと標準の NIS+ サーバーの設定における違いは、ルートマスターサーバーの場合と同じです (「標準構成と NIS 互換構成の手順の相違」を参照)。サーバーには、正しく構成された /etc/resolv.conf ファイルが必要です。また、NIS 互換サーバー用の NIS+ デーモンは -Y オプション (DNS 転送を使用する場合は、-B オプションも必要) を使用して起動しなければなりません。これによって、サーバーは NIS クライアントからの要求に応答できます。-Y オプションと -B オプションの実装方法については、「NIS+ とサービス管理機能」を参照してください。

-Y または -B のいずれかのオプションを使用して rpc.nisd を起動した場合、必ず rpc.nisd_resolv という副デーモンが生成され、名前の解決を行います。

設定作業の手順を次にまとめます。

1. 新しくサーバーにするワークステーションにスーパーユーザーとしてログインします。

2. NIS+ デーモンを -Y で起動します (NIS 互換のみの場合)。

3. NIS+ デーモンを起動します (標準の NIS+ のみの場合)。

NIS+ サーバー構成時のセキュリティについて

NIS+ のセキュリティシステムは複雑です。NIS+ セキュリティを使い慣れていない場合は、第 11 章「NIS+ のセキュリティの概要」を参照してから NIS+ 環境を構成することをお勧めします。

この手順は、サーバー上のスーパーユーザーとして実行しなければなりません。起動したサーバーのセキュリティレベルによって、そのクライアントが備えるべき資格が決ります。たとえば、サーバーがセキュリティレベル 2 で構成された場合、サーバーがサポートするドメイン内のクライアントは、DES 資格を必要とします。このマニュアルの指示に従ってクライアントを構成した場合、そのクライアントは適切なドメインに DES 資格を持ち、セキュリティレベル 2 でサーバーを起動できます。

セキュリティレベル 0 は、管理者による構成とテストの目的だけに使用します。セキュリティレベル 1 はサポートされていません。一般のユーザーが通常の業務を行う環境では、レベル 0 またはレベル 1 を使用せず、常にセキュリティレベル 2 を使用してください。

NIS+ サーバーを構成するための前提条件

• ルートドメインがあらかじめ構成されている (第 5 章「ルートドメインの設定」を参照)

• サーバーにするには、NIS+ クライアントとして初期設定しておく (第 6 章「NIS+ クライアントの構成」を参照)

• サーバーを構成するには、そのマシンにスーパーユーザーとしてログインする必要がある

• サーバーを NIS 互換モードで実行し、DNS 転送をサポートするためには、正しく構成された /etc/resolv.conf ファイルが必要である

必要な情報

サーバーに変換するクライアントのスーパーユーザーパスワードが必要です。

NIS+ サーバーを構成する方法

1 台のマスターサーバーまたは複製サーバーから複数のドメインにサービスを提供することは可能ですが、お勧めしません。

1. 新しくサーバーにするワークステーションにスーパーユーザーとしてログインします。

   以下の手順では、「クライアントの設定」に従って、マシンを NIS+ クライアントとして設定した後、マシンを再起動したことを前提としています。マシンを再起動すると、次の手順の推奨前提条件であるキャッシュマネージャが起動します。マシンを再起動しなかった場合は、ここで svcadm を使用して NIS+ サービスを再起動します。

2. (省略可能) /lib/svc/method/nisplus ファイルを編集して必要なオプションを追加します。

   適切なテキストエディタを使用します。

   /lib/svc/method/nisplus ファイルの編集方法については、「NIS+ とサービス管理機能」を参照してください。

   -B	DNS 転送をサポートします。
   -Y	NIS 互換モードで NIS+ デーモンを起動します。

3. NIS+ デーモンを起動します。

   server# svcadm enable network/rpc/nisplus:default

   NIS+ サービスが実行されていることを確認するには、svcs コマンドを実行します。

   server# svcs \*nisplus\* STATE STIME FMRI online Jan_12 svc:/network/rpc/nisplus:default

   この手順によって、/var/nis/data という名前のディレクトリが作成されます。また、trans.log というトランザクションログファイルが作成され、/var/nis というディレクトリに格納されます。

   compatserver# ls -F /var/nis NIS_COLD_START data/ trans.log data.dict

   trans.log ファイルは、トランザクションログです。トランザクションログの内容を確認するには、nislog コマンドを使用します。使用方法については、「nislog コマンド」を参照してください。

   ---

   注意 –

   /var/nis ディレクトリと /var/nis/data ディレクトリは、移動または名前の変更をしないでください。また、/var/nis/trans.log ファイルと /var/nis/data.dict ファイルについても、移動または名前の変更をしないでください。Solaris 2.4 以前からアップグレードする場合、それまで使っていた /hostname サブディレクトリは自動的に /var/nis/data に変換され、関連するファイルも必要に応じて変換されます。この自動変換がなされた後で、新しい名前に変更することは 絶対にしないで ください。

   ---

   これでこのサーバーは、第 8 章「ルート以外のドメインの構成」の説明に従って、ドメインのマスターまたは複製に指定できます。NIS+ サーバーの設定は、この手順で完了です。作業の要約については 「サーバー構成の要覧」を参照してください。

複製サーバーを既存のドメインに追加する

NIS+ サービスを常に利用できる状態にしておきたいのであれば、ルート複製サーバーを少なくとも 1 つは作成しておくことをお勧めします。複製サーバーを作成すると複数のサーバーが存在することになり、要求の処理を分散させることができるため、ネットワーク要求の処理も高速化されます。

パフォーマンス上の理由から、1 つのドメインに多くの複製サーバーを置くことはお勧めできません。ネットワークが複数のサブネットで構成されている場合、あるいは広域ネットワーク (WAN) でリモートサイトに接続されている場合にだけ、複製サーバーを置くようにしてください。

• 「サブネット」。複数のサブネットで構成されているドメインの場合、各サブネットに複製サーバーを少なくとも 1 つは作成することをお勧めします。そうしておけば、ネットワーク間の通信が一時的に途絶していても、接続が回復するまでの間、サブネットレベルの機能は維持されるからです。

• 「リモートサイト」。WAN によりリモートサイトに接続されているドメインの場合、WAN 接続の両側に複製サーバーを少なくとも 1 つは作成することをお勧めします。組織論的な見地からしても、同一の NIS+ ドメインに物理的に離れた 2 つのサイトがあるのは意味のあることです。たとえば、ドメイン内のマスターサーバーとその複製サーバーがすべて一方のサイトに置かれている場合、そのサイトともう一方のサイトとの間の NIS+ ネットワークトラフィックが増大するのは目に見えています。もう一方のサイトにも複製サーバーを置いておけば、ネットワークトラフィックが減るはずです。

複製サーバーの分散および最適な複製サーバー数の決定方法については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』の「ルート複製サーバーの作成」を参照してください。既存のドメインに複製サーバーを追加するには、その複製サーバーを構成してから該当する名前空間の NIS+ データセットをロードします。

新しい複製サーバーを構成して NIS+ データセットをロードする方法には、次の 2 通りがあります。

• 「スクリプト」。nisserver スクリプトを実行するには、「ルート複製サーバーの作成」の説明に従ってください。この方法では、NIS+ データセットが新しい複製サーバーにロードされて自動的に再同期がとられます。格段に簡単なので、こちらの方法をお勧めしますが、「NIS+ コマンドセット」と「バックアップと復元」を利用する方法に比べると、時間が長くかかることがあります。

• 「NIS+ コマンドセット」。NIS+ コマンドを使うには、「NIS+ コマンドを使って複製サーバーを構成する」の説明に従ってください。nisserver スクリプトを実行する方法に比べると、NIS+ に対する深い知識が必要です。この NIS+ コマンドを使う方法には、きめの細かい設定と監視が可能であるという利点があります。そして、もう 1 つ、ドメインディレクトリを手作業で作成して複製サーバーを生成し、nisbackup と nisrestore を使って NIS+ データをロードできるという利点もあります。NIS+ のバックアップおよび復元機能を使うと、nisserver を使うより短時間でデータをロードできます。

  新たに構成した複製サーバーに NIS+ データセットをロードする方法には、次の 2 通りがあります。

  • 「nisping」。nisserver スクリプトか NIS+ コマンドのどちらかを使って新しい複製サーバーを構成する場合、マスターサーバーは nisping を使用してネットワーク経由で該当する名前空間のデータセットを新しい複製サーバーに自動的にロードします。このとき、大きな名前空間では処理に長時間かかり、その間、名前管理情報の要求が遅れることがあります。詳細は、「nisping を使ってデータを複製サーバーにロードする」を参照してください。

  • 「バックアップと復元」。nisping によるデータ転送に割り込みをかけ、NIS+ のバックアップ機能と復元機能を使って、名前空間データを新たに構成した複製サーバーにロードできます (「nisrestore を使ってデータを複製サーバーにロードする」を参照)。複製サーバーから複製サーバーにデータセットがロードされることになり、マスターサーバーから複製サーバーにネットワーク経由でデータセットをロードする場合に比べて格段に早く終わるので、こちらの方法をお勧めします。

NIS+ コマンドを使って複製サーバーを構成する

この節では、NIS+ コマンドを使って複製サーバーを既存のドメインに追加する方法について説明します。

複製サーバー構成時のセキュリティについて

この作業を実行する NIS+ 主体には、ドメインのディレクトリオブジェクトに対する変更権が必要です。

複製サーバーを構成するための前提条件

• ドメインをあらかじめ構成し、マスターサーバーを稼働させておく

• 新しい複製サーバーが NIS+ サーバーとして構成されている (「NIS+ サーバーを設定する」を参照)

必要な情報

• サーバー名

• ドメイン名

NIS+ コマンドを使って複製サーバーを構成する— 作業マップ

NIS+ コマンドを使って複製サーバーを構成する方法

この例では、マスターサーバー名を master1、新しい複製サーバー名を replica2 とします。

1. ドメインのマスターサーバーにログインします。

2. NIS+ サービスが実行されていることを確認します。

   master1# svcs -l network/rpc/nisplus:default

3. ドメインに複製サーバーを追加します。

   nismkdir コマンドに -s オプションを付けて実行します。次の例では、doc.com. ドメインに replica2 という名前の複製サーバーマシンを追加します。

   master1# nismkdir -s replica2 doc.com. master1# nismkdir -s replica2 org_dir.doc.com. master1# nismkdir -s replica2 groups_dir.doc.com.

   すでに存在するディレクトリオブジェクトに nismkdir コマンドを実行すると、ディレクトリは再作成されずに、与えられたフラグに基づいてディレクトリが変更されます。この場合、-s フラグはドメインに追加する複製サーバーを割り当てます。複製サーバーが追加されたことを確認するには、niscat -o コマンドを実行して、ディレクトリオブジェクトの定義を調べます。

   ---

   注意 –

   複製サーバー上で nismkdir を実行しないでください。複製サーバーで nismkdir を実行すると、マスターサーバーと複製サーバーの間で通信上の問題が発生します。

   ---

   これで新しい複製サーバーの構成は完了です。次は、構成した複製サーバーに NIS+ データセットをロードします。これには、次の 2 つの方法があります。

   • 「nisping」。何もしなければ、マスターサーバーによって nisping コマンドが実行され、該当する名前空間データが新たに構成された複製サーバーにロードされます。名前空間が大きい場合は、データのロードに時間がかかることがあります。データのロード中は、ネーミング情報の要求は遅延することがあります。詳細は、「nisping を使ってデータを複製サーバーにロードする」を参照してください。

   • 「バックアップと復元」。nisping によるデータ転送に割り込みをかけ、NIS+ のバックアップ機能と復元機能を使って、名前空間データを新たに構成した複製サーバーにロードできます (「nisrestore を使ってデータを複製サーバーにロードする」を参照)。ほかの方法に比べて格段に早く効率的なので、こちらの方法をお勧めします。

nisrestore を使ってデータを複製サーバーにロードする

この節では、NIS+ のバックアップ機能と復元機能を使って名前空間データを新しい複製サーバーにロードする方法について説明します。この方法を使ってデータを複製サーバーにロードすることをお勧めします。

nisrestore を使って複製サーバーにデータをロードする場合のセキュリティについて

この作業を実行する NIS+ 主体には、ドメインのディレクトリオブジェクトに対する変更権が必要です。

nisrestore を使ってデータをロードするための前提条件

• ドメインをあらかじめ構成し、マスターサーバーを稼働させておく

• 新しい複製サーバーが NIS+ サーバーとして構成されている (「NIS+ サーバーを設定する」を参照)

• 新しい複製サーバーが複製サーバーとして構成されている (「NIS+ コマンドを使って複製サーバーを構成する」を参照)

nisrestore を使ってデータを複製サーバーにロードする — 作業マップ

名前空間データをロードする方法—nisrestore による方法

この例では、マスターサーバー名を master1、新しい複製サーバー名を replica2 とします。

1. 新しい複製サーバー上の NIS+ サービスを停止します。

   この処理は、nisping コマンドを使用した、マスターから複製への名前空間データの自動転送に割り込んで実行されます。

   replica2# svcadm disable /network/rpc/nisplus:default

2. マスターサーバー上で NIS+ バックアップ機能を実行します。

   この手順の詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。以下の例では、nisbackup コマンドを使って master1 サーバーを /var/master1_bakup ディレクトリにバックアップします。

   master1# nisbackup -a /var/master1_bakup

   nisrestore を使って新しい複製サーバーを構成するもっとも簡単な方法は、マスターサーバーのデータを NFS にマウントされた (複製サーバーからアクセス可能な) ディレクトリにバックアップするというものです。この例では、マスターサーバーと新しい複製サーバーの両方に、/var/master1_bakup ディレクトリへのアクセス権が与えられているものと想定します。

   このほかに、tar コマンドを使って /var/master1_bakup ディレクトリからテープカートリッジなどの可搬記憶メディアにデータをコピーし、次に、その可搬記憶メディアから新しい複製サーバーにマウントされているディレクトリにデータをコピーし、そのディレクトリを nisrestore コマンドの情報源として使うという方法 (手順 3 参照) もあります。

3. nisrestore コマンドを使って、NIS+ データセットを新しい複製サーバーにロードします。

   この手順の詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。以下の例では、nisrestore コマンドを使って NIS+ データを/var/master1_bakup ディレクトリから client2 にダウンロードします。

   replica2# nisrestore -a /var/master1_bakup

   作成している複製サーバーがルートドメイン用の場合、あるいは nisrestore が必要なデータを検証または検索できないというエラーメッセージが表示される場合は、nisrestore に -f オプションを付けて実行してください。たとえば、以下のようになります。

   replica2# nisrestore -f -a /var/master1_bakup

4. 新しい複製サーバー上で NIS+ サービスを起動します。

   詳細は、「NIS+ サーバーを構成する方法」を参照してください。

nisping を使ってデータを複製サーバーにロードする

この節では、nisping コマンドを使って名前空間データを新しい複製サーバーにロードする方法について説明します。通常、このプロセスは自動的に実行されるため、nisping コマンドを実行する必要はまずありません。

nisping コマンドを使う方法の問題点は、マスターサーバーから複製サーバーへデータの再同期をとるために、NIS+ プロトコルを使ったネットワーク上のデータのやりとりが必要だということです。名前空間が大きい場合は、この処理に何時間もかかり、その間、名前管理情報の要求に対する応答が遅れることがあります。

nisping を使ってデータをロードする場合のセキュリティについて

この作業を実行する NIS+ 主体には、ドメインのディレクトリオブジェクトに対する変更権が必要です。

nisping を使ってデータをロードするための前提条件

• ドメインをあらかじめ構成し、マスターサーバーを稼働させておく

• 新しい複製サーバーが NIS+ サーバーとして構成されている (「NIS+ サーバーを設定する」を参照)

• 新しい複製サーバーが複製サーバーとして構成されている (「NIS+ コマンドを使って複製サーバーを構成する」を参照)

nisping を使ってデータを複製サーバーにロードする — 作業マップ

名前空間データをロードする方法—nisping による方法

通常、名前空間データのロードは、マスターサーバーによって自動的に開始されます。マスターサーバーによるロードが行われなかった場合は、次の説明に従って nisping コマンドを実行してください。

ディレクトリに対して nisping を実行します。

この手順では、新しい複製サーバーにメッセージ「ping」を送信して、マスターサーバーに対して更新を要求するように通知します。複製サーバーがルートドメインに所属していない場合、必ずドメイン名を指定してください。次の例では、ドメイン名は完全を期すためにだけ記述してあります。この作業で使用する例は、ルートドメインに複製サーバーを追加しているため、次の例にあるドメイン名 doc.com. は必要ありません。

master1# nisping doc.com. 
master1# nisping org_dir.doc.com. 
master1# nisping groups_dir.doc.com.

この結果は以下のようになります。

master1# nisping doc.com. 
Pinging replicas serving directory doc.com. :
Master server is master1.doc.com.
 No last update time
Replica server is replica1.doc.com.
 Last update seen was Wed Nov 18 11:24:32 1992
 Pinging ... replica2.doc.com.

大きな名前空間の場合、この処理に何時間もかかる場合があります。nisping の詳細については、第 18 章「NIS+ ディレクトリの管理」を参照してください。

サーバー構成の要覧

表 7–4、表 7–5 では、この章で説明した作業のまとめを示しています。この 2 つの表は、もっとも簡単な場合を想定しているため、参考用として使用するには、実際の自分の作業の詳細を理解している必要があります。また、ここでは、各コマンドに対するサーバーの応答を示していません。

上記の例で説明したように、新しい複製サーバーにデータをロードする場合は、nisping を使用するより NIS+ のバックアップと復元機能を使用した方が簡単です。詳細については、「nisrestore を使ってデータを複製サーバーにロードする」を参照してください。

第 8 章 ルート以外のドメインの構成

この章では、NIS+ コマンドセットを使ってサブドメイン (ルート以外のドメイン) を構成する方法 (マスターサーバーと複製サーバーを設定する方法を含む) を、手順を追って説明します。

NIS+ は、将来のリリースではサポートされなくなる可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 リリース以降で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

ルート以外のドメインを設定する

NIS+ クライアントを設定する作業は、この章で説明する NIS+ のコマンドセットを使用する方法よりも、パート I で説明した NIS+ 設定スクリプトを使用する方が簡単です。この章で説明する方法は、NIS+ に精通した管理者や、設定スクリプトでは提供されない標準以外の機能や構成を必要とする管理者だけが使用してください。

最初にルート以外のドメインのサーバーを構成してから、ルート以外のドメインを構成してください。

ルート以外のドメインを設定するには、次の作業を行います。

• ドメインのセキュリティの設定

• ドメインのディレクトリの作成

• ドメインのテーブルの作成

• ドメインのサーバーの指定

ルートドメインの構成と同様に、これらの作業は連続して実行できません。構成プロセスを簡単にするため、これらを個々の手順に分割して、もっとも効率的な順序に並べています。

標準構成と NIS 互換構成の相違 (ルート以外のドメイン)

サブドメインにおける NIS 互換の NIS+ サーバーと標準の NIS+ サーバーとの違いは、ルートドメインの場合と同じです (「標準構成と NIS 互換構成の手順の相違」参照)。

NIS 互換ドメインの各サーバーの NIS+ デーモンは、第 7 章「NIS+ サーバーの構成」の説明に従って、-Y オプションを使用して起動する必要があります。また、NIS 互換ドメインでは、ドメインのテーブルによって未認証クラスに読み取り権を提供する必要があります。これにより、NIS クライアントはテーブルに格納されている情報にアクセスできます。手順 4 で説明するとおり、nissetup コマンドに -Y オプションを追加すると、テーブル内の情報にアクセスできます。標準の NIS+ ドメインでも同じコマンドを使用しますが、-Y オプションは使用しません。これについても手順 4 で説明します。

設定作業の手順を次にまとめます。

1. ドメインのマスターサーバーにログインします。

2. ドメインの管理グループを指定します。

3. ドメインのディレクトリを作成し、そのサーバーを指定する

4. ドメインのサブディレクトリとテーブルを作成します。

5. ドメインの管理グループを作成します。

6. ディレクトリオブジェクトに完全なグループアクセス権を割り当てます。

7. ドメインの管理グループにサーバーを追加します。

8. ほかの管理者の資格を追加します。

9. ドメインの管理グループに管理者を追加します。

ルート以外のドメイン設定時のセキュリティについて

NIS+ のセキュリティシステムは複雑です。NIS+ セキュリティを使い慣れていない場合は、第 17 章「NIS+ グループの管理」を参照してから NIS+ 環境を構成することをお勧めします。

多くのサイトでは、親ドメインのセキュリティを確保するために、その下にドメインを作成できるのは、親ドメインのマスターサーバー、または親ドメインの管理グループに所属するシステム管理者に限定しています。これは、管理方針であり NIS+ の必要条件ではありませんが、この章の操作説明ではこの作業を行う管理者がこの方針に従っているものと仮定します。もちろん、親ドメインの管理グループには、親ディレクトリオブジェクトに対する作成権が必要です。これを確認するには、niscat -o コマンドを実行します。

rootmaster# niscat -o doc.com.
Object Name : Doc
Owner : rootmaster
Group : admin.doc.com.
Domain : Com.
Access Rights : r---rmcdrmcdr---
:

安全性よりも便宜性を重視する場合、新しいドメインのマスターサーバーをその親ドメインの管理グループのメンバーとし、そのサーバーからすべて手順を実行できます。この場合、第 17 章「NIS+ グループの管理」で説明する nisgrpadm コマンドを使用します。

ルート以外のドメインを設定するための前提条件

• 親ドメインを構成し、実行していなければなりません。

• このドメインのマスターとして指定されるサーバーは、すでに初期設定され、NIS+ を実行していなければなりません。

• 複製サーバーを指定する場合、マスターサーバーは、その /etc/hosts ファイル、/etc/inet/ipnodes ファイルまたはその NIS+ hosts テーブルを通じて、複製サーバーの IP アドレスを入手できなければなりません。

必要な情報

• 新しいドメインの名前 (手順 3)

• 新しいドメインのマスターサーバーと複製サーバー名

• 新しいドメインの管理グループ名 (手順 2)

• 新しいドメインの管理グループに所属する管理者のユーザー ID (UID) (手順 8)

ルート以外のドメインを設定する — 作業マップ

ルート以外のドメインの設定方法

1. ドメインのマスターサーバーにログインします。

   新しいドメインのマスターにする予定のサーバーにログインします。この作業の手順では smaster という名前のサーバーを使用します。 このサーバーは doc.com. ドメインに所属し、sales.doc.com. サブドメインのマスターサーバーになります。この作業を実行する管理者は、admin.doc.com. グループのメンバーである nisboss.doc.com. です。このグループには、doc.com. ディレクトリオブジェクトに対する完全なアクセス権が割り当てられています。

2. ドメインの管理グループを指定します。

   実際に管理グループを作成するのは、手順 5 の時点でですが、ここで管理グループを指定する必要があります。これによって、次の手順で使用される nismkdir コマンドは、このグループに対する適切なアクセス権をもつディレクトリオブジェクトを作成できます。またこれは、手順 4 で使用する nissetup ユーティリティに対しても同じことを行います。

   環境変数 NIS_GROUP に、ドメインの管理グループ名を設定します。ここでは、C シェルユーザーの場合と Bourne シェルまたは Korn シェルユーザーの場合の 2 つの例を示します。どちらの場合も NIS_GROUP を admin.sales.doc.com. に設定します。

   C シェルの場合

   smaster# setenv NIS_GROUP admin.sales.doc.com.

   Bourne シェルまたは Korn シェルの場合

   smaster# NIS_GROUP=admin.sales.doc.com. smaster# export NIS_GROUP

3. ドメインのディレクトリを作成し、そのサーバーを指定する

   nismkdir コマンドは、新しいドメインのディレクトリ作成と、そのサポートサーバーの指定を 1 つの手順で行います。この構文を次に示します。

   nismkdir -m master -s replica domain

   -m フラグはマスターサーバーを指定し、-s フラグは複製サーバーを指定します。この例を次に示します。

   smaster# nismkdir -m smaster -s salesreplica sales.doc.com.

   ---

   注意 –

   nismkdir は必ず (複製サーバーではなく) マスターサーバー上で実行してください。複製サーバー上で nismkdir を実行しないでください。複製サーバーで実行すると、マスターサーバーと複製サーバーの間で通信上の問題が発生します。

   ---

   ディレクトリオブジェクトは /var/nis にロードされます。内容を表示するには、niscat -o コマンドを実行します 。cat または more は使用しないでください。

   smaster# niscat -o sales.doc.com. Object Name : Sales Owner : nisboss.doc.com. Group : admin.sales.doc.com. Domain : doc.com. Access Rights : ----rmcdr---r--- .

   ルートディレクトリとは異なり、このディレクトリオブジェクトには適切なグループが割り当てられています。したがって、nischgrp を実行する必要はありません。

4. ドメインのサブディレクトリとテーブルを作成します。

   この手順では、org_dir ディレクトリと groups_dir ディレクトリ、および NIS+ テーブルを新しいディレクトリオブジェクトの下に追加します。nissetup ユーティリティを使用しますが、新しいドメイン名の追加を忘れないでください。NIS 互換ドメインの場合、-Y フラグを指定します。

   「NIS 互換の場合」

   smaster# /usr/lib/nis/nissetup -Y sales.doc.com.

   「標準 NIS+ の場合」

   smaster# /usr/lib/nis/nissetup sales.doc.com.

   このユーティリティによって追加されたオブジェクトを表示すると、次のようになります。

   smaster# /usr/lib/nis/nissetup org_dir.sales.doc.com. created groups_dir.sales.doc.com. created auto_master.org_dir.sales.doc.com. created auto_home.org.dir.sales.doc.com. created bootparams.org_dir.sales.doc.com. created cred.org_dir.sales.doc.com. created ethers.org_dir.sales.doc.com. created group.org_dir.sales.doc.com. created hosts.org_dir.sales.doc.com. created mail_aliases.org_dir.sales.doc.com. created sendmailvars.org_dir.sales.doc.com. created netmasks.org_dir.sales.doc.com. created netgroup.org_dir.sales.doc.com. created networks.org_dir.sales.doc.com. created passwd.org_dir.sales.doc.com. created protocols.org_dir.sales.doc.com. created rpc.org_dir.sales.doc.com. created services.org_dir.sales.doc.com. created timezone.org_dir.sales.doc.com. created

   -Y オプションによって、標準の NIS+ ドメインの場合と同じテーブルとサブディレクトリが作成されますが、NIS クライアントからの要求が NIS+ テーブル内の情報にアクセスできるよう、未認証クラスに読み取り権が割り当てられます。

   /var/nis/salesmaster に相当する自分のマスターを調べることによって、org_dir ディレクトリと groups_dir ディレクトリが存在することを確認できます。これらのディレクトリは、ルートオブジェクトおよびその他の NIS+ ファイルとともに登録されています。テーブルは org_dir ディレクトリに存在します。任意のテーブルの内容を調べるには、第 9 章「NIS+ テーブルの設定」で説明する niscat コマンドを実行します 。ただしこの時点ではテーブルは空です。

5. ドメインの管理グループを作成します。

   この手順では、手順 2 で指定した管理グループを作成します。nisgrpadm コマンドに -c オプションを付けて実行してください。次の例では admin.sales.doc.com. グループを作成します。

   smaster# nisgrpadm -c admin.sales.doc.com. Group admin.sales.doc.com. created.

   この手順ではグループを作成するだけであり、そのメンバー名の指定は行いません。指定は手順 9 で行います。

6. ディレクトリオブジェクトに完全なグループアクセス権を割り当てます。

   デフォルトでは、ディレクトリオブジェクトはそのグループに読み取り権を与えるだけであり、これではその他のカテゴリと同様、グループも使うことができません。クライアントとサブドメインの構成を簡単にするため、ディレクトリオブジェクトがそのグループに与えるアクセス権を、読み取り権のみから読み取り権、変更権、作成権、削除権に変更します。次に示すように、nischmod コマンドを実行します。

   smaster# nischmod g+rmcd sales.doc.com.

   nischmod コマンドの使用方法の詳細については、第 15 章「NIS+ のアクセス権の管理」を参照してください。

7. ドメインの管理グループにサーバーを追加します。

   この時点で、このドメインのグループにはメンバーがありません。-a オプションを付けて nisgrpadm コマンドを実行し、マスターサーバーと複製サーバーを追加します。最初の引数はグループ名であり、残りの引数は新しいメンバーの名前です。この例では、smaster.doc.com. と salesreplica.doc.com. を admin.sales.doc.com. グループに追加します。

   smaster# nisgrpadm -a admin.sales.doc.com. smaster.doc.com. salesreplica.doc.com. Added smaster.doc.com. to group admin.sales.doc.com. Added salesreplica.doc.com. to group admin.sales.doc.com.

   このサーバーが管理グループに属していることを確認するには、nisgrpadm コマンドを -l オプションで実行します。手順については、第 17 章「NIS+ グループの管理」を参照してください。

   smaster# nisgrpadm -l admin.sales.doc.com. Group entry for admin.sales.doc.com. group: Explicit members: smaster.doc.com. salesreplica.doc.com. No implicit members No recursive members No explicit nonmembers No implicit nonmembers No recursive nonmembers

8. ほかの管理者の資格を追加します。

   そのドメインで仕事をするほかの管理者の資格を追加します。

   すでにもう 1 つのドメインで DES 資格をもつ管理者の場合、単に LOCAL 資格を追加します。このとき、-p フラグと -P フラグ付きの nisaddcred コマンドを実行します。たとえば、次のようになります。

   smaster# nisaddcred -p 33355 -P nisboss.doc.com. local

   まだ資格をもたない管理者の場合、2 つの方法があります。

   • 管理者に対して、自分の資格を追加するよう要求するのが 1 つの方法です。この方法は、スーパーユーザーとして実行する必要があります。ユーザー ID が 22244 で、主体名が juan.sales.doc.com. の管理者が、sales.doc.com. ドメインに自分の資格を追加する例を次に示します。

     smaster# nisaddcred -p 22244 -P juan.sales.doc.com. local smaster# nisaddcred -p unix.22244@sales.doc.com -P \ juan.sales.doc.com. des Adding key pair for unix.22244@sales.doc.com. Enter login password:

   • もう 1 つの方法では、ダミーパスワードを使用して、ほかの管理者用の一時的な資格を作成します 。各管理者には NIS+ passwd テーブル内にエントリが必要です。

     smaster# nisaddcred -p 22244 -P juan.sales.doc.com. local smaster# nisaddcred -p unix.22244@sales.doc.com -P \ juan.sales.doc.com. des Adding key pair for unix.22244@sales.doc.com. Enter juan's login password: nisaddcred: WARNING: password differs from login passwd. Retype password:

   各管理者は、後で chkey コマンドを実行して、自分のネットワークパスワードを変更できます。パスワードの変更方法については、第 12 章「NIS+ 資格の管理」と第 13 章「NIS+ 鍵の管理」を参照してください。

   ---

   注 –

   上記の手順 8 の 2 つの例で、小文字の -p フラグに続くドメイン名の終わりにドットを付けないでください。また、大文字の -P フラグに続くドメイン名の終わりにはドットを必ず付けてください。

   ---

9. ドメインの管理グループに管理者を追加します。

   この手順を実行するには、ほかのシステム管理者がダミーパスワードを変更するまで待つ必要はありません。-a オプションを付けて nisgrpadm コマンドを実行します。最初の引数はグループ名、残りの引数は管理者名です。この例では、管理者 juan を admin.sales.doc.com. グループに追加します。

   smaster# nisgrpadm -a admin.sales.doc.com. juan.sales.doc.com. Added juan.sales.doc.com. to group admin.sales.doc.com.

10. NIS+ テーブルを格納するための、十分なスワップ空間を割り当てます。

    スワップ空間は、rpc.nisd の最大サイズの 2 倍にする必要があります。rpc.nisd が使用するメモリー量を調べるには、次のコマンドを実行してください。

    rootmaster# /usr/lib/nis/nisstat

    rpc.nisd は、特定の条件のもとでは、自らのコピーを作成してフォークします。メモリーが不足すると、rpc.nisd は正しく動作しません。

    また、NIS+ テーブルに必要なメモリーとスワップ空間のサイズも計算できます。たとえば、NIS+ テーブル内に、180,000 人のユーザーと 180,000 台のホストがある場合、これらの 2 つのテーブルが占有するメモリーは、約 190M バイトです。180,000 人のユーザーと 180,000 台のホストに資格を追加する場合、cred テーブルには、540,000 のエントリ (ユーザーごとにローカルの資格と DES の資格、合わせて 2 つの資格、ホストごとに 1 つの資格) が入ります。そのため、cred テーブルが占有するメモリーは、約 285M バイトになります。この例では、rpc.nisd に必要なメモリー容量は、少なくとも、190M バイト + 285M バイト = 475M バイトになります。この結果、少なくとも 1G バイトのスワップ空間が必要になります。また、rpc.nisd 全体をすべてメモリー内に保持するには、少なくとも 500M バイトが必要です。

サブドメイン構成の要覧

表 8–2 は、サブドメインの構成に必要な手順のまとめです。これはもっとも簡単なケースを想定しているため、このまとめを参考用として使用するには、その前に自分の実際の作業の詳細を理解することが必要です。また、ここでは、各コマンドに対するサーバーの応答を示していません。

第 9 章 NIS+ テーブルの設定

この章では、NIS+ コマンドセットを使用して、/etc ディレクトリ内のファイルや NIS マップからマスターサーバー上に NIS+ テーブルを作成する方法について説明します。また、この章では NIS+ テーブルから NIS マップへ情報を戻す方法と、passwd テーブルのパスワード列へのアクセスを制限する方法を説明します。

NIS+ は、将来のリリースではサポートされなくなる可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 リリース以降で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

テーブルの設定

NIS+ テーブルを生成する作業は、この章で説明する NIS+ コマンドセットを使用する方法よりも、パート I で説明した NIS+ 設定スクリプトを使用した場合の方が簡単です。この章で説明する方法は、NIS+ に精通した管理者や、設定スクリプトでは提供されない標準以外の機能や構成を必要とする管理者だけが使用してください。さらに、Solaris 管理コンソール ツールをお持ちの場合は、NIS+ テーブルに関連する作業が簡単になります。

NIS+ テーブルを生成するには次の 4 種類の方法があります。

• ファイルから作成する (「NIS+ テーブルをファイルから生成する」参照)

• NIS マップから作成する (「NIS+ テーブルを NIS マップから生成する」参照)

• nispopulate スクリプトを使用して作成する (「NIS+ テーブルの生成 (populate)」および 「新しいサブドメインのテーブルの生成」参照)

• 可能な場合、Solaris 管理コンソール ツールを使用する

マップまたはファイルからテーブルを生成する場合、第 5 章「ルートドメインの設定」および第 8 章「ルート以外のドメインの構成」で説明する手順に従って、ルートまたはサブドメインの設定作業の中で、あらかじめテーブルを作成しておく必要があります。ドメインテーブルは、テーブルの作成後いつでも生成できますが、ドメインの設定が完了したらすぐに生成しておくことをお勧めします。テーブルを生成すると、クライアントに関する必要な情報がすでにドメインテーブル内に格納されることになるため、クライアントの追加が簡単にできます。

テーブルの生成の方法

ファイルまたは NIS マップからテーブルを生成する場合、次の 3 つの方法を使用できます。

• 「置換」- この方法を使用すると、NIS+ は、初めにテーブル内の既存のエントリをすべて削除してから、情報源からのエントリを追加します。サイズの大きいテーブルの場合は、マスターサーバーの /var/nis/trans.log ファイルにエントリの大きなセット (既存のエントリを削除するためのセットと新しいエントリを追加するためのセット) が追加されます。/var/nis 内のディスク空間を大幅に使用するため、複製サーバーへの転送時間はさらに長くなります。

• 「追加」- この方法は、NIS+ テーブルに情報源からのエントリを追加します。既存のエントリが影響されることはありません。

• 「マージ」- この方法は、置換オプションと結果は同じですが、内部的な処理が異なります。既存のエントリを削除後、置換するのではなく、更新します。このオプションでは、NIS+ は次の 3 種類のエントリを異なる方法で処理します。

  • ソース内にだけ存在するエントリは、テーブルに追加する

  • ソースとテーブルの両方に存在するエントリは、テーブル内で更新する

  • NIS+ テーブルにだけ存在するエントリは、テーブルから削除する

  大きなテーブルを更新する場合で、内容の変更があまりないときは、マージオプションを使用するとサーバーは多くの動作を節約できます。ソース内で重複していないエントリだけを削除する (置換オプションは全エントリを無差別に削除する) ため、重複エントリごとに 1 回の削除と 1 回の追加動作を省略できます。このため、この方法をお勧めします。

NIS+ テーブルをファイルから生成する

これは /etc/hosts などの ASCII ファイルの内容を NIS+ テーブルに転送する作業です。

手順を次に示します。

1. データを転送する各ファイルの内容を確認します。

2. 各ファイルのコピーを作成します。作成したコピーを実際の転送に使用します。このマニュアルでは、hosts.xfr のように、転送されるファイルのコピーの最後に .xfr を付けます。

3. NIS+ クライアントにログインするテーブルを更新するための資格とアクセス権が必要です。以下の 「ファイルからテーブルを生成する場合のセキュリティについて」を参照してください。

4. このシェルのコマンド検索パスに /usr/lib/nis を追加します。

5. nisaddent を使用して、次の必要なファイルを 1 つずつ転送します。aliases, bootparams, ethers, group, hosts, netgroup, netmasks, networks, passwd, protocols, rpc, services, shadow、および ipnodes。

   ---

   注 –

   新しい /etc/inet/ipnodes ファイルには、IPv4 および IPv6 のアドレスが含まれています。nisaddent を実行して、 /etc/inet/ipnodes ファイルを ipnodes.org_dir テーブルに変換してください。

   ---

6. publickey ファイルを転送する

7. オートマウンタ情報を転送します。

8. 複製サーバーに対して nisping を実行します。

9. テーブルに対しチェックポイントを実行します。

ファイルからテーブルを生成する場合のセキュリティについて

NIS+ テーブルは、NIS+ クライアントまたは NIS+ ルートマスターサーバーから生成できます。NIS+ テーブルを生成するには、スーパーユーザー (root) としてログインする必要はありませんが、一定の資格とアクセス権は必要です。テーブル内のエントリをテキストファイルのエントリによって置換またはマージする場合、そのテーブルへの作成権と削除権が必要です。新しいエントリを追加する場合、作成権だけが必要です。

NIS+ のセキュリティシステムは複雑です。NIS+ セキュリティを使い慣れていない場合は、第 11 章「NIS+ のセキュリティの概要」を参照してから NIS+ 環境を構成することをお勧めします。

この処理が完了した後、テーブルエントリは、動作を実行した NIS+ 主体と、環境変数 NIS_GROUP によって指定されたグループによって所有されます。

ファイルからテーブルを生成するための前提条件

• ドメインをあらかじめ設定していて、そのマスターサーバーを実行している

• ドメインのサーバーには、新しいテーブル情報を収容できるだけの十分なスワップ領域が必要

• ファイル内の情報は、ロード先のテーブルに合った書式で書かれていなければならない。対応する NIS+ テーブルに転送するテキストファイルで要求される書式については、「nispopulate を実行してルートサーバーテーブルを生成するための前提条件」を参照してください。ローカルの /etc 内のファイルは、正しい書式で書かれているのが普通ですが、いくつかのコメントを削除しなければならないこともあります。

• マシン名とユーザー名は重複していない。ユーザーとマシンは、すべて固有の名前を付ける必要があります。また、ユーザーと同じ名前の付いたマシンは使用できません。

• マシン名にはドット (ピリオド) および下線は使用できない。たとえば、マシン名に sales.alpha を使用できません。ドットや下線の代わりにハイフンを使うことはできます。たとえば、sales-alpha というマシン名は有効です。

必要な情報

転送されるテキストファイルの名前と位置が必要です。

NIS+ テーブルをファイルから生成する — 作業マップ

NIS+ テーブルをファイルから生成する方法

1. データを転送する各ファイルをチェックします。

   不正なエントリがないことを確認します。正しいデータが、所定の場所に正しい書式で記録されていることを確認します。エントリのうち、古いもの、無効なもの、破損しているものは削除します。また、不完全なエントリや一部のみのエントリも削除します。不完全なエントリは、設定を完了した後に追加する方が、不完全なエントリや破損したエントリを転送するよりも簡単です。

2. 転送する各ファイルの作業用コピーを作成します。

   このセクションで説明する実際のファイル転送の手順では、作成した作業用コピーを使用します。各作業用コピーには、同じファイル名拡張子を付けます (たとえば、.xfr)。

   rootmaster% cp /etc/hosts /etc/hosts.xfr

   万が一に備えて、使用する予定のすべてのファイルを /etc 以外のディレクトリにコピーしておくのもよいでしょう。nisaddent コマンドと nispopulate コマンドでは、ファイルソースディレクトリを指定できます。

3. NIS+ クライアントにログインする

   この作業はどの NIS+ クライアントからでも実行できます。ただし、そのクライアントは、情報の転送先となるテーブルと同じドメインに所属していなければなりません。ここで示す例では、ルートマスターサーバーを使用します。これらの例では、システム管理者はスーパーユーザーとしてログインしているため、この操作を実際に実行している (適切な資格とアクセス権を必要とする) NIS+ 主体は、ルートマスターサーバーです。

   しかし、NIS+ テーブルを更新するだけであれば、あえてルートマスターサーバーにスーパーユーザー (root) としてログインする必要はありません。スーパーユーザーであれ、一般ユーザーであれ、一定の資格、権限、許可さえあれば、どのマシンからでも NIS+ テーブルを更新できます。

4. このシェルのコマンド検索パスに /usr/lib/nis を追加します。

   テーブルごとに /usr/lib/nis/nisaddent コマンドを使用するため、検索パスに /usr/lib/nis を追加しておくと、毎回これを入力する必要がありません。ここでは、C シェルユーザーの場合の例と Bourne シェルまたは Korn シェルのユーザーの場合の例を示します。

   C シェルの場合

   rootmaster# setenv PATH $PATH:/usr/lib/nis

   Bourne シェルまたは Korn シェルの場合

   rootmaster# PATH=$PATH:/usr/lib/nis rootmaster# export PATH

5. nisaddent を使用して、次のファイルを 1 つずつ転送します。

   aliases bootparams ethers group hosts ipnodes netgroup netmasks networks protocols rpc, services

   publickey、automounter、passwd、および shadow の各ファイルは、実行する手順がそれぞれ少し異なります。publickey ファイルの場合は、手順 6 に進んでください。automounter ファイルの場合は、手順 7 に進んでください。passwd および shadow ファイルの場合は、手順 8 に進んでください。

   デフォルトでは、nisaddent はファイル情報をテーブル情報に追加します。置換またはマージを行うには、-r または -m オプションを使用します。

   置換する場合、次のように入力します。

   rootmaster# nisaddent -r -f filename table[domain]

   追加する場合、次のように入力します。

   rootmaster# nisaddent -a -f filename table [domain]

   マージする場合、次のように入力します。

   rootmaster# nisaddent -m -f filename table [domain]

   はじめてテーブルを生成する場合は、デフォルトの -a オプションが最適です。NIS+ テーブルを NIS マップまたは /etc 内のファイルと同期させるための最適なオプションは -m (マージ) オプションです。

   • filename はファイル名です。通常は、nisaddent によって作成されたことを示す .xfr をファイル名の最後につけます。

   • table は NIS+ テーブル名です。domain 引数は省略可能で、テーブルを別のドメインに生成するときに使用します。ルートドメインのマスターサーバーから入力されたいくつかの例を次に示します。これらのファイルは、/etc 内のファイルを編集したものです。

     rootmaster# nisaddent -m -f /etc/hosts.xfr hosts rootmaster# nisaddent -m -f /etc/groups.xfr groups

   この作業をルート以外のサーバーから実行する場合、ルート以外のサーバーは、サポートするドメインの上のドメインに所属することに注意してください。つまり、ルート以外のサーバーはもう 1 つのドメインのクライアントです。たとえば、sales.doc.com. マスターサーバーは doc.com. ドメインに所属します。そのマスターサーバーからテーブルを sales.doc.com. ドメインに生成するには、nisaddent 文に sales.doc.com. ドメイン名を追加する必要があります。

   salesmaster# nisaddent -f /etc/hosts.xfr hosts Sales.doc.com.

   この作業を sales.doc.com. ドメインのクライアントとして実行した場合、このコマンドにドメイン名を指定する必要はありません。

   エントリが NIS+ テーブルに転送されたことを確認するには、niscat コマンドを使用します。詳細については、第 19 章「NIS+ テーブルの管理」を参照してください。

   rootmaster# niscat groups.org_dir root::0:root other::1:: bin::2:root,bin,daemon .

   障害追跡のヒント: niscat を実行しても表示された内容が反映されていない場合、変更がマスターサーバーから複製サーバーに送られていないためかもしれません。そのような場合は、5 〜 10 分後にもう一度 niscat の実行を試みるか、niscat に -M オプションを付けて実行してください。-M オプションを付けると、マスターサーバーのデータが取得されます。

6. publickey ファイルを転送します。

   ドメインの cred テーブルには、すでにいくつかの資格が格納されているため、この cred テーブルに転送する publickey テキストファイルの内容によって、これらの資格が上書きされないよう確認する必要があります。これを避けるには、publickey テキストファイルからこれらの資格を取り除きます。rootmaster で次のような行がある場合は、すべて削除してください。

   unix.rootmaster@doc.com public-key:private-key [alg-type]

   こうすれば、publickey ファイルの内容を cred テーブルに転送できます。nisaddent に -a (追加) オプションを付けて実行します。

   rootmaster# nisaddent -a -f /etc/publickey.xfr -t cred.org_dir publickey [domain]

   ただし、この操作は DES 資格を cred テーブルに転送するだけです。主体は、cred テーブルに対する自分の LOCAL 資格を作成する必要があります。

7. オートマウンタ情報を転送します。

   nissetup ユーティリティは auto_master テーブルと auto_home テーブルを作成しますが、これらは標準の NIS+ テーブルとはみなされません。したがって、これらのテーブルに情報を転送するには、少し異なる構文が必要となります。特に、-t フラグを使用し、そのテーブルが key-value 形式であることを指定しなければなりません。

   rootmaster# nisaddent -f auto.master.xfr -t auto_master.org_dir key-value rootmaster# nisaddent -f auto.home.xfr -t auto_home.org_dir key-value

8. NIS+ passwd テーブルを作成します。

   NIS+ の passwd テーブルは、/etc/passwd および /etc/shadow の両方のディレクトリのファイルから引き出されるデータで構成されます。このため、nisaddent を 2 回実行して passwd テーブルを作成しなければなりません。passwd テーブルを対象として /etc/passwd ファイルからデータを引き出す場合と、shadow テーブルを対象として /etc/shadow ファイルからデータを引き出す場合の 2 回実行します。shadow ファイルに対して nisaddent を実行する場合、shadow テーブルが存在しなくても、ターゲットテーブルに shadow を指定すること、そしてデータが実際に passwd テーブルの shadow 列に配置されることに注意してください。

   rootmaster# nisaddent -m -f /etc/passwd.xfr passwd rootmaster# nisaddent -m -f /etc/shadow.xfr shadow

9. nisping を実行して更新内容を複製サーバーに送ります。

   nisping を実行すると、複製サーバーに変更が反映されます。

   master1# nisping domain master1# nisping org_dir.domaincom. master1# nisping groups_dir.domain

10. テーブルに対しチェックポイントを実行します。

    ここまでの手順で、マスターサーバーと複製サーバーの NIS+ データセットがメモリー内で更新されました。今度はそれをディスク上のテーブルファイルに書き込みます。この作業を「チェックポイント」といいます。チェックポイントは必ずしもここで実行しなければならないわけではありません。定期的に実行していれば、問題ありません。ただし、重要な変更を加えた場合には、できるだけ早めにディスクに書き込むことをお勧めします。

    この手順により、ドメインをサポートしている全サーバーが、それらの .log ファイルからディスク上のテーブルのコピーに新しい情報を転送します。ルートドメインを設定したばかりの場合、そのルートドメインにはまだ複製サーバーがないため、この手順はルートマスターサーバーだけが対象となります。チェックポイントを実行するには nisping コマンドに -C (大文字) オプションを付けて実行します。

    rootmaster# nisping -C org_dir Checkpointing replicas serving directory org_dir.doc.com. : Master server is rootmaster.doc.com. Last update occurred at July 14, 1997 Master server is rootmaster.doc.com. checkpoint succeeded.

    スワップ空間が不足している場合、サーバーはチェックポイントを正常に実行できませんが、そのことを通知してくれません。スワップ空間が十分あることを確認する方法として、niscat コマンドを使ってテーブルの内容をリスト表示する方法があります。スワップ空間が不足している場合、次のエラーメッセージが表示されます。

    can't list table: Server busy, Try Again.

    このメッセージ内容からはわかりませんが、これはスワップ空間の不足を示しています。スワップ空間を増やし、このドメインに再びチェックポイントを実行します。

NIS+ テーブルを NIS マップから生成する

ここでは、NIS マップの内容を NIS+ テーブルに転送します。手順を次に示します。

1. データを転送する各 NIS マップの内容を確認します。

2. NIS+ クライアントにログインする

3. このシェルのコマンド検索パスに /usr/lib/nis を追加します。

4. nisaddent を使用して、次のマップを 1 度に 1 つずつ転送します。aliases, bootparams, ethers, group, hosts, netgroup, netmasks, networks, passwd, protocols, rpc, services。

5. publickey マップを転送します。

6. オートマウンタ情報を転送します。

7. nisping を実行して変更内容を複製サーバーに反映させます。

8. テーブルに対しチェックポイントを実行します。

NIS マップからテーブルを生成する際のセキュリティについて

この作業を行うシステム管理者 (またはクライアント上のスーパーユーザー) に適切な資格とアクセス権がある限り、この作業は、どの NIS+ クライアントからでも実行できます。テーブル内のエントリを NIS マップのエントリで置換またはマージする場合、そのテーブルへの作成権と削除権が必要です。新しいエントリを追加する場合、作成権だけが必要です。

この作業が完了した後、テーブルエントリは、作業を実行した NIS+ 主体 (システム管理者である自分、またはスーパーユーザーとしてログインした場合はそのクライアント) と、環境変数 NIS_GROUP によって指定されたグループによって所有されます。

NIS マップからテーブルを生成するための前提条件

• ドメインをあらかじめ設定していて、そのマスターサーバーを実行している

• NIS+ テーブルにロードしようとしている NIS マップ用の dbm ファイル (.pag および .dir ファイル) は、/var/yp のサブディレクトリ内にある

• マシン名とユーザー名は重複していない。ユーザーとマシンは、すべて固有の名前を付ける必要があります。また、ユーザーと同じ名前の付いたマシンは使用できません。

• マシン名にはドット (ピリオド) を使用できない。たとえば、マシン名に sales.alpha を使用できません。sales-alpha というマシン名は、使用できます。