test

Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)

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

このパートでは、Solaris オペレーティング環境上で 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+ はマシンのアドレス、セキュリティ情報、メール情報、Ethernet インタフェース、ネットワークサービスなどの情報を 1 カ所に格納して、ネットワーク上のすべてのマシンからアクセスできるようにします。このように構成されたネットワーク情報を、NIS+「名前空間」と呼びます。

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

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

NIS+ では高機能のセキュリティシステムによって、名前空間の構造と保存されている情報が保護されます。このシステムは、情報にアクセスしようとしているクライアントが正当なものであるかどうかを認証と承認によって確認します。「認証」とは、情報の要求者がネットワークの正当なユーザーであるかどうかを判定することです。「承認」では、特定のユーザーが情報を所有したり修正したりできるかどうかを確認します。

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

NIS+ のメリット

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

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

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

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

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

NIS+ と NIS の違い

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

表 2–1 NIS と NIS+ の相違

NIS 

NIS+ 

フラットなドメイン - 階層なし 

階層構造 - データを名前空間内の異なるレベルに格納 

データを 2 列のマップに格納 

データを複数の列のテーブルに格納 

認証を使用しない 

DES 認証を使用 

ネットワーク情報源は 1 つ 

ネームサービススイッチ - クライアントは NIS、NIS+、DNS、またはローカル側の /etc ファイルから情報源を選択できる

バッチ伝達のため更新は遅い 

すぐに伝達される増分更新 

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 テーブルの更新は手作業で処理され、大規模な組織では、すべての複製サーバーへの伝達に 1 日以上かかることもあります。この原因の一つは、マップ内の情報が変化するたびにマップ全体を再作成して伝達しなければならなかったからです。

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

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

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

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

この図には、16 種類の NIS+ システムテーブルを示します。

各テーブルにはそれぞれ違う種類の情報が保存されます。たとえば、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+ セキュリティシステムの詳細は、第 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 互換モードの詳細については、第 26 章「NIS から NIS+ への移行」を参照してください。

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

NIS+ の管理コマンド

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

表 2–2 NIS+ の名前空間管理コマンド

コマンド名 

説明 

nisaddcred

NIS+ 主体用の資格を作成し、これらを cred テーブルに格納する

nisaddent

/etc ファイル、または、NIS マップの情報を NIS+ テーブルに追加する

nisauthconf

オプションで Diffie-Hellman キー長を設定する 

nisbackup

NIS ディレクトリのバックアップコピーを取る 

nis_cachemgr

NIS+ クライアント上で NIS+ キャッシュマネージャを起動する 

niscat

NIS+ テーブルの内容を表示する 

nis_checkpoint

ログには入力されたが、ディスクにチェックポイントが実行されていないデータについて強制的にチェックポイントを実行する 

nischgrp

NIS+ オブジェクトのグループ所有者を変更する 

nischmod

オブジェクトのアクセス権を変更する 

nischown

NIS+ オブジェクトの所有者を変更する 

nischttl

NIS+ オブジェクトの有効時間を変更する 

nisclient

NIS+ 主体を初期化する  

nisdefaults

NIS+ オブジェクトのデフォルト値 (ドメイン名、グループ名、マシン名、NIS+ 主体名、アクセス権、ディレクトリ検索パス、および生存期間) を表示する  

nisgrep

NIS+ テーブル内のエントリを検索する 

nisgrpadm

NIS+ グループの作成または削除、あるいはそのメンバーリストを表示する。また、グループにメンバーを追加または削除したり、グループメンバーかどうかのテストを行う 

nisinit

NIS+ のクライアントまたはサーバーを初期設定する 

nisln

2 つの NIS+ オブジェクト間でシンボリックリンクを作成する 

nislog

NIS+ 処理用ログの内容を表示する 

nisls

NIS+ ディレクトリの内容を表示する 

nismatch

NIS+ テーブル内のエントリを検索する 

nismkdir

NIS+ のディレクトリを作成し、そのマスターサーバーと複製サーバーを指定する  

nispasswd

NIS+ の passwd テーブルに格納されているパスワード情報を変更する (nispasswd よりは、passwd または passwd -r nisplus を使用する)

nis_ping

複製サーバーのデータをマスターサーバーのデータに強制更新する 

nispopulate

新しい NIS+ ドメインに NIS+ テーブルを生成する 

nisprefadm

クライアントが NIS+ サーバーから NIS+ 情報を検索する順序を指定する 

nisrestore

以前にバックアップを取った NIS+ ディレクトリを復元する。新しい NIS+ 複製サーバーを急速にオンラインにするときにも使用する 

nisrm

ディレクトリ以外の NIS+ オブジェクトを名前空間から削除する 

nisrmdir

名前空間から、NIS+ ディレクトリとその複製を削除する 

nisserver

新しい NIS+ サーバーを設定するときに使うシェルスクリプト 

nissetup

org_dir ディレクトリと groups_dir ディレクトリ、および NIS+ ドメイン用の完全セットの (未生成) NIS+ テーブルを作成する

nisshowcache

NIS+ キャッシュマネージャによって管理される NIS+ 共有キャッシュの内容を表示する 

nisstat

NIS+ サーバーに関する統計やその他の情報を報告する 

nistbladm

NIS+ テーブルの作成または削除と、NIS+ テーブル内のエントリの追加、修正、または削除を行う  

nistest

NIS+ 名前空間の現在の状態を報告する 

nisupdkeys

NIS+ オブジェクトに格納されている公開鍵を更新する 

passwd

NIS+ の Passwd テーブルに保管されているパスワード情報を変更するまたパスワードの経過時間やその他のパスワード関連のパラメータを管理する

NIS+ の API

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

設定および構成の前に

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

NIS と NIS+

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

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

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

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

表 2–3 NIS+ ファイルが存在する場所

ディレクトリ 

存在するマシン 

内容 

/usr/bin

すべて 

NIS+ ユーザーコマンド 

/usr/lib/nis

すべて 

NIS+ 管理者コマンド 

/usr/sbin

すべて 

NIS+ デーモン 

/usr/lib/

すべて 

NIS+ 共有ライブラリ 

/var/nis/data

NIS+ サーバー 

NIS+ サーバーの使用できるデータファイル 

/var/nis

NIS+ サーバー 

NIS+ ワーキングファイル 

/var/nis

NIS+ クライアントマシン 

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.4 以前との互換性はなくなっています。したがって、これらのファイルやディレクトリを Solaris 2.4 での名前にしてしまうと、Solaris 2.4、2.5 双方の 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 つのファイルから構成されています。

この図では、UNIX ファイルシステムと NIS+ の名前空間を比較します。

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

ディレクトリ

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

Graphic

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

この図では、ルートディレクトリの下位にある、複数のディレクトリレベルを示します。

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

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

この図では、FNS を NIS+ とともに使用した場合のディレクトリ構造を示します。

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

ドメイン

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

この図では、NIS+ ドメイン内の NIS+ グループ、NIS+ テーブルおよび org_dir ディレクトリを示します。

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

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

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

この図には、3 つの主要ディレクトリグループで構成されている NIS+ ディレクトリを示します。

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

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

この図には、3 つの NIS+ ドメインを示します。

サーバー

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

この図には、NIS+ ドメインをサポートするサーバーを示します。

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

この図には、サーバーによってサポートされる NIS+ ドメインの構成を示します。

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

Solaris オペレーティング環境ベースのマシンは、どれも NIS+ サーバーとなることができます。各 Solaris リリースには、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 つの要素が記録されます。

この図には、マスターサーバーと複製サーバーの接続の際のトランザクションログの構造を示します。

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

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

Graphic

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

NIS+ 主体とクライアント

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

主体

一般ユーザーであってもスーパーユーザー (root) であってもログインをすれば 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+ クライアントはその情報を入手できません。

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

doc.com ドメインのサーバーにアクセスするクライアントを示します。

この図には、sales.doc.com ドメインのサーバーにアクセスするクライアントを示します。

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

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

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

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

この図には、クライアントのディレクトリキャッシュを初期設定する、コールドスタートファイルを示します。

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

ドメイン名とディレクトリ名が同じ 

サポートするサーバー 

IP アドレス 

doc.com.

rootmaster 

123.45.6.77 

sales.doc.com.

salesmaster 

123.45.6.66 

manf.doc.com.

manfmaster 

123.45.6.37 

int.sales.doc.com.

Intlsalesmaster 

111.22.3.7 

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

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

この図は、コールドスタートファイルによって指定されたサーバーにアクセスするクライアントを示します。

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

サーバーが、自分のドメインのディレクトリオブジェクトのコピーをクライアントに送信することを示しています。

この図は、クライアントが該当するドメインをサポートするサーバーからディレクトリオブジェクトのコピーを取得することを示しています。

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

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

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

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

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

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

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

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

この図は、異なるドメイン内のサーバーであり、クライアントでもあるサーバーを示しています。

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

サーバー 

サポートするドメイン 

所属するドメイン 

RootMaster 

doc.com. 

doc.com. 

SalesMaster 

sales.doc.com. 

doc.com. 

IntlSalesMaster 

intl.sales.doc.com. 

sales.doc.com. 

ManfMaster 

manf.doc.com. 

doc.com. 

命名規約

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

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

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

この図は、docs.com 名前空間の例を示しています。

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

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

この図は、docs.com 名前空間の完全指定ドメイン名を示しています。

NIS+ ドメイン名

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

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

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

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

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

表 2–4 インターネットの組織ドメイン

ドメイン 

種類 

com

営利団体 

edu

教育機関 

gov

行政機関 

mil

軍事組織 

net

ネットワークサポートセンター 

org

非営利団体 

int

国際組織 

上の 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 文字までで、使用できるのは文字、数字、ダッシュ (-)、および下線 (_) です。大文字と小文字の区別はありません。また先頭は英文字とします。スペースは使用できません。

注 –

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

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

NIS+ の主体名

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

表 2–5 NIS+ の主体名

olivia.sales.doc.com.

NIS+ 主体名 

unix.olivia@sales.doc.com

Secure RPC ネット名 

また、たとえ主体の資格が 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+ は、これらのディレクトリを左から右へ検索していきます。たとえば、次のようにします。

この図は、mydir および hosts.org_dir をそれぞれに該当する完全指定ドメイン名に展開する例を示しています。

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

この図は、sales.doc.com、manf.doc.com および doc.com ディレクトリの NIS_PATH を示しています。

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

注 –

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

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

NIS ドメインが NIS 名前空間にすでに存在する場合は、そのドメインを NIS+ 名前空間に同じフラット構造で移行することができます。移行したドメインは、あとで階層構造に変更できます。NIS から NIS+ に移行するときは、計画および準備方法について、第 26 章「NIS から NIS+ への移行」を参照してください。NIS+ のスクリプトを使用すると、NIS マップのデータを利用して簡単に NIS+ を起動できます。第 4 章「スクリプトを使用した NIS+ の設定」で、NIS+ スクリプトを使用してシステムファイルや NIS マップから NIS+ 名前空間を作成する方法を説明します。

ただし、名前空間がすでに存在している場合、スクリプトをスムーズに実行するため NIS+ への移行用の設定が必要です。移行の準備の詳細については、第 26 章「NIS から NIS+ への移行」を参照してください。

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

注意 – 注意 –

Solaris 2.4 以前では、/var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルと、サブディレクトリ /var/nis/hostname がありました。またサブディレクトリ /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 通りの構成方法を紹介します。

注 –

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+ コマンドを個別に入力する必要はありません。次の表に、各スクリプトの機能を示します。

表 3–1 NIS+ スクリプト

NIS+ スクリプト 

機能 

nisserver

ルートマスターサーバー、非ルートマスターサーバー、複製サーバーをレベル 2 のセキュリティ (DES) で設定する 

nispopulate

NIS+ テーブルを、対応するシステムファイルまたは NIS マップから指定されたドメイン内に生成する 

nisclient

ホストとユーザーの NIS+ 資格を作成し、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+ スクリプトではなく 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+ コマンドより簡単に NIS+ 名前空間を設定できます。第 6 章「NIS+ クライアントの構成」、第 7 章「NIS+ サーバーの構成」、および 第 8 章「非ルートドメインの構成」を参照してください。

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

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

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

表 4–1 NIS+ の推奨構成手順の概要

作業 

説明 

スクリプトまたは NIS+ コマンド 

NIS+ 名前空間の計画を立てる 

NIS+ 名前空間の計画を立てる。計画の要件と手順の詳細は、NIS+ 名前空間の設計 - 管理モデルの目的を明らかにする を参照。(試験的なネットワークで NIS+ チュートリアルを使用している場合、この手順は不要)

 

既存の名前空間を設定する  

スクリプトを正常に実行するためには、既存の名前空間を適切に設定する必要がある。必要な準備については、 NIS+ 名前空間の設計 - 管理モデルの目的を明らかにする を参照。(試験的なネットワークで NIS+ チュートリアルを使用している場合、この手順は不要)

 

Diffie-Hellman キー長を設定する 

DES 認証を使用する場合には、デフォルトの 192 ビットよりも長い Diffie-Hellman キーの使用を考慮する。キーを長くする場合、その長さはドメイン内のすべてのマシンで同一である必要がある。各初期設定スクリプトの実行する前に、目的のキー長を指定する 

nisauthconf

ルートドメインの構成 

ルートドメインを作成する。ルートマスターサーバーの構成と初期設定を行う。ルートドメイン管理グループを作成する 

nisserver

テーブルの生成 

テキストファイルまたは NIS マップからルートドメインの NIS+ テーブルを生成 (populate) する。ルートドメインクライアントの資格 (credential) を作成する。管理者の資格を作成する 

nispopulate

nisgrpadm

nisping

ルートドメインクライアントの構成 

クライアントマシンを構成する (そのうちの何台かは続いてサーバーになる)。ユーザーを NIS+ クライアントとして初期設定する 

nisclient

サーバーを使用可能にする 

ルートドメインの一部のクライアントをサーバーとして使用可能にする。サーバーの一部は後でルート複製サーバーとなり、そのほかは下位レベルのドメインをサポートする 

rpc.nisd

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

構成したばかりのサーバーのうち、1 台または複数をルートドメインの複製として指定する 

rpc.nisd

nisserver

非ルートドメインの構成 

新しいドメインを作成する。以前の手順で使用可能にしたサーバーを、そのマスターとして指定する。その管理グループと管理資格を作成する  

rpc.nisd

nisserver

テーブルの生成 

新しいドメインのクライアントの資格を作成する。テキストファイルまたは NIS マップから、新しいドメインの NIS+ テーブルを生成する 

nispopulate

非ルートドメインのクライアントを構成する 

新しいドメインのクライアントを構成する (一部のクライアントは、後に下位レベルのドメインのサーバーとなる場合がある)。ユーザーを NIS+ クライアントとして初期設定を行う 

nisclient

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

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

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

注 –

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

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

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

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

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

表 4–2 NIS+ ドメインの構成に使うコマンド行のまとめ

作業 

対象マシン 

コマンド名 

/usr/lib/nis をルートのパスに追加する。C シェルまたは Bourne シェルを使用

ルートマスターサーバーとクライアントマシン。スーパーユーザーとして行う 

setenv PATH $PATH:/usr/lib/nis

または 

PATH=$PATH:/usr/lib/nis; export PATH

オプションで DES 認証を使用する場合には、Diffie-Hellman キー長を選択する 

サーバーとクライアントマシン。スーパーユーザーとして行う 

nisauthconf -dhkey-length-alg-type des

NIS (YP) との互換性があるか、または互換性がないルートマスターサーバーを作成する 

ルートマスターサーバー。スーパーユーザーとして行う 

nisserver -r-dnewdomain.

または 

nisserver -Y-r-d newdomain.

ファイルまたは NIS マップからルートマスターサーバーテーブルを生成する 

ルートマスターサーバー。スーパーユーザーとして行う 

nispopulate -F-p /files -d newdomain.

または 

nispopulate -Y-d newdomain. -h NISservername -a NIS_server_ipaddress -y NIS_domain

NIS+ 管理グループにユーザーを追加する 

ルートマスターサーバー。スーパーユーザーとして行う 

nisgrpadm -a admin. domain.name.domain.

NIS+ データベースのチェックポイントを実行する 

ルートマスターサーバー。スーパーユーザーとして行う 

nisping -C domain.

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

クライアントマシン。スーパーユーザーとして行う 

nisclient -i-d domain. -h master1

ユーザーを NIS+ クライアントとして初期設定する 

クライアントマシン。ユーザーとして行う 

nisclient -u

rpc.nisd デーモンを起動 - NIS (および DNS) との互換性なし、またはありでクライアントをサーバーにするために必要

クライアントマシン。スーパーユーザーとして行う 

rpc.nisd

または 

rpc.nisd -Y

または 

rpc.nisd -Y -B

サーバーをルート複製サーバーにする 

ルートマスターサーバー。スーパーユーザーとして行う 

nisserver -R -d domain. -h clientname

サーバーを非ルートマスターサーバーにする 

ルートマスターサーバー。スーパーユーザーとして行う 

nisserver -M -d newsubdomain.domain. -h clientmachine

ファイルまたは NIS マップから新しいマスターサーバーテーブルを生成する 

新しいサブドメインマスターサーバー。スーパーユーザーとして行う 

nispopulate -F -p /subdomaindirectory -d newsubdomain.domain.

または 

nispopulate -Y -d newsubdomain.domain.-h NISservername -a NIS_server_ipaddress -y NIS_domain

クライアントをマスターサーバーの複製にする 

サブドメインマスターサーバー。スーパーユーザーとして行う 

nisserver -R -d subdomain.domain. -h clientname

サブドメインの新しいクライアントを初期設定する。クライアントは、サブドメインの複製またはそのほかのサーバーにできる 

新しいサブドメインクライアントマシン。スーパーユーザーとして行う  

nisclient -i -d newsubdomain .domain. -h subdomainmaster

ユーザーを NIS+ クライアントとして初期設定する 

クライアントマシン。ユーザーとして行う 

nisclient -u

注 –

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

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

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

注 –

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

nisserver を実行するための前提条件

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

必要な情報

次の情報が必要です。

表 4–3 インターネットの組織ドメイン

ドメイン 

種類 

com

営利組織 

edu

教育機関 

gov

行政機関 

mil

軍事組織 

net

主要ネットワークサポートセンター 

org

非営利組織 

int

国際組織 

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

注 –

ドメインとホストで同じ名前を使用しないでください。たとえば、ルートドメインに doc.com. という名前を付けている場合、ドメイン内で使用するマシンには doc という名前は付けないでください。同様に、home という名前のマシンを使用する場合は、home という名前のドメインを作成しないでください。これはサブドメインの場合も同様です。たとえば、マシンに west という名前を付けている場合、sales.west.myco.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 コマンドは、各 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 認証は適正に動作できず、その結果 NIS+ で問題が発生します。

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

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

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


    127.0.0.1 localhost loghost
192.168.10.x hostA hostA-10 hostA-le0
192.168.11.y hostA hostA-11 hostA-le1
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 スクリプトをデフォルトの設定で使用して、ファイルまたは NIS マップのデータからルートマスターサーバーのテーブルを生成する方法を説明します。このスクリプトは次のものを使用します。

注 –

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

nispopulate を実行するための前提条件

スクリプト nispopulate を実行するには、次の条件が必要です。

必要な情報

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

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

注 –

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+ クライアントを初期設定する方法を説明します。次のスクリプトを使用します。

注 –

新しいクライアントマシンを初期設定する方法 で使用する -i オプションでは、DNS を使用してホスト名を解決するような NIS+ クライアントを構成しません。DNS を使用する場合には、ネームサービススイッチファイルの中でクライアント用に、DNS を明確に指定しなければなりません。DNS によるホスト名の解決については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編) 』の「ドメインネームシステム (概要)」を参照してください。

nisclient を実行するための前提条件

nisclient スクリプトを使用するには、次の条件が必要です。

必要な情報

次の情報が必要です。

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

  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 パスワード (ネットワークパスワード) が root のログインパスワードと異なる場合のみ、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 スクリプトを使用します。

nisclient を実行するための前提条件

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

必要な情報

次の情報が必要です。

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

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

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

この例では、マシン client1 がサーバーに変更されます。この手順では、NIS+ スクリプトの代わりに NIS+ コマンド rpc.nisd を使用します。

rpc.nisd を実行するための前提条件

rpc.nisd を実行するには、次の条件が必要です。

必要な情報

サーバーに変換するクライアントのスーパーユーザーパスワードが必要です。

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

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

注 –

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

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

  1. NIS と互換性のないサーバーを構成するには、次のコマンドを入力します。


    client1# rpc.nisd

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

  1. サーバーの /etc/init.d/rpc ファイルを編集して、文字列 -EMULYP=”-Y” を含む行のコメントアウトを解除して有効にします。

    コメントアウトを解除するには、行の先頭から # を削除します。

  2. スーパーユーザーとして、次のように入力します。


    client1# rpc.nisd -Y

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

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

  1. サーバーの /etc/init.d/rpc ファイルを編集します。文字列 -EMULYP=”-Y” を含む行のコメントアウトを解除 (行の先頭から # を削除) して有効にします。

    コメントアウトを解除するには、行の先頭から # を削除します。

  2. 上の行の引用符で囲まれた中に次のように -B を追加します。

    次のようになります。

    -EMULYP=”-Y -B”

  3. 次のコマンドをスーパーユーザーとして入力します。


    client1# rpc.nisd -Y -B

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

サーバーの追加作成

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

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

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

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

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

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

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

nisserver を実行するための前提条件

nisserver を実行して複製サーバーを作成するには、次の条件が必要です。

必要な情報

次の情報が必要です。

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

  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. If you want to run this replica in NIS (YP) 
compatibility mode, edit the /etc/init.d/rpc file on the replica server '
to uncomment the line which sets EMULYP to "-Y". This will ensure that 
rpc.nisd will boot in NIS-compatibility mode. Then, restart rpc.nisd with 
the “-Y” option. These actions should be taken after this script completes.
    注 –

    上記のメッセージはオプションの手順に関するものです。NIS 互換ではないルート複製サーバーを NIS 互換にする場合にだけ、/etc/init.d/rpc ファイルを変更します。つまり、NIS 互換のサーバーとして構成されていないルート複製サーバーで NIS クライアント要求を実行する場合にだけ、このファイルの変更が必要になります。NIS 互換サーバーの作成については、クライアントを NIS+ サーバーとして構成する方法を参照してください。

  4. 必要に応じて、複製サーバーを NIS (YP) 互換モードで稼動させることができるように構成します。

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

    1. rpc.nisd を終了します。

    2. サーバーの /etc/init.d/rpc ファイルをオープンして、EMULYP が -Y に設定されている行のコメントアウトを解除します。

      具体的には、EMULYP 行の先頭の # を削除します。

    3. rpc.nisd を再起動します。

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

    NIS+ データセットのロードには、2 通りの方法があります。

    • 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 認証は適正に動作できず、その結果 NIS+ で問題が発生します。

次に、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 を実行して、新しいサブドメインのマスターサーバーを作成するには、次の条件が必要です。

必要な情報

次の情報が必要です。

新しい非ルートドメインを作成する方法では、新しいサブドメインを 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 では、非ルート 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 互換性、およびセキュリティレベルの詳細は、ルートマスターサーバーを作成する方法を参照してください。

  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 スクリプトが、ルートマスターサーバー上ではなく、新しいマスターサーバー上で実行されることです。また、ドメイン名、およびファイルパス、または NIS サーバー名も変わることがあります。

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

nispopulate を実行するための前提条件

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


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:/:
注 –

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

必要な情報

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

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

注 –

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

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

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

注 –

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

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

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

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

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


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 を実行して複製サーバーを作成するには、次の条件が必要です。

必要な情報

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

    複製サーバーを作成するには、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 スクリプトを使用してユーザーを初期設定するには、次の条件が必要です。

必要な情報

次の情報が必要です。

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

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


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 スクリプトを使用してユーザーを初期設定するには、次の条件が必要です。

必要な情報

次の情報が必要です。

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 にまとめます。各コマンドの前にあるプロンプトは、そのコマンドをどのマシンで入力するかを示します。

表 4–4 NIS+ 名前空間サンプルのコマンド行のまとめ

目的 

コマンド 

/usr/lib/nis を含むように環境パスを設定 (C シェルまたは Bourne シェル)

# setenv PATH $PATH:/usr/lib/nis

または 

# PATH=$PATH:/usr/lib/nis; export PATH

オプションで Diffie-Hellman キー長を設定する 

master1# nisauthconf dh640-0 des

doc.com. ドメインのルートマスターサーバーを作成

master1# nisserver -r -d doc.com.

ルートマスターサーバーの NIS+ テーブルを、ファイルまたは NIS マップから生成 

master1# nispopulate -F -p /nis+files -d doc.com.

または 

master1# nispopulate -Y -d doc.com. -h salesmaster -a 130.48.58.111 -y sales.doc.com.

管理グループ (2) にメンバーを追加する 

master1# nisgrpadm -a admin. doc.com. topadmin.doc.com. secondadmin.doc.com.

NIS+ データベースのチェックポイントを実行 

master1# nisping -C org_dir. doc.com.

オプションで Diffie-Hellman キー長を設定する 

client1# nisauthconf dh640-0 des

doc.com. ドメイン内の NIS+ クライアントマシンを初期設定  

client1# nisclient -i -d doc.com. -h master1

ユーザーを NIS+ クライアントとして初期設定する 

client1user1prompt% nisclient -u

NIS+ クライアントを、NIS 互換性あり、またはなし、あるいは NIS と DNS ありで NIS+ サーバーに変更 

client1# rpc.nisd

または 

client1# rpc.nisd -Y

または 

client1# rpc.nisd -Y -B

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

master1# nisserver -R -d doc.com. -h client1

サーバーを sales.doc.com.ドメインの非ルートのマスターサーバーに変更

master1# nisserver -M -d sales.doc.com. -h client2

新しいマスターサーバーの NIS+ テーブルを、ファイルまたは NIS マップから生成 

client2# nispopulate -F -p /nis+files -d sales.doc.com.

または 

client2# nispopulate -Y -d sales.doc.com. -h businessmachine -a 130.48.58.242 -y business.doc.com.

マスターサーバーの複製を作成 

client2# nisserver -R -d sales.doc.com. -h client3

sales.doc.com.ドメイン内の NIS+ クライアントを初期設定

subclient1# nisclient -i -d sales.doc.com. -h client2

ユーザーを NIS+ クライアントとして初期設定する 

subclient1user2prompt% nisclient -u

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

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

注 –

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、SolarisTM 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 クライアントからの要求に応えることができます。起動方法については「ルートドメインを構成する方法」の 手順 11 で説明します。標準の NIS+ ドメインについては 手順 12 で説明します。

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

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

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

手順の要約

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

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

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

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

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

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

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

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

  8. NIS+ デーモンを -Y で起動します (NIS の互換場合)。NIS+ デーモンを起動します (NIS+ の場合)。

  9. NIS+ デーモンが実行されていることを確認します。

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

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

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

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

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

  15. NIS+ キャッシュマネージャを起動します。

  16. NIS+ デーモンをセキュリティレベル 2 で再起動します。

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

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

  19. 他のシステム管理者の資格を追加します。

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

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

表 5–1 ルートドメインを確立する

作業 

説明 

参照先 

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

domainname コマンドを使用して、ルートドメインを設定する。オプションで Diffie-Hellman キー長を長くする。ncsd デーモンの停止と起動を行う。keyserv デーモンの終了と再起動を行う。不要な NIS+ 情報を消去する

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

セキュリティについて

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

注 –

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

前提条件

作業を開始する前に、以下のことを確認します。

必要な情報

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

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

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

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

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

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

    注意 – 注意 –

    ドメインとホストで同じ名前を使用しないでください。たとえば、sales というドメインを使用している場合、sales という名前の付いたマシンは使用しないでください。同様に、home という名前のマシンを使用する場合は、home という名前のドメインを作成しないでください。これは、サブドメインの場合にもあてはまります。たとえば、マシンに west という名前を付けている場合、sales.west.myco.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+ コマンドではありません。そのため、domainname コマンドは、ドメイン名の最後にドットを付ける 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 デーモンを終了して再起動します。

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

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

  6. 次のように入力し、keyserv を強制終了して再起動します。 


    rootmaster# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
rootmaster# sh /etc/init.d/nscd stop
rootmaster# sh /etc/init.d/nscd start
rootmaster# ps -e | grep keyserv
 root 145 1 67 16:34:44 ? keyserv
 .
 .
rootmaster# kill -9 145
rootmaster# rm -f /etc/.rootkey
rootmaster# keyserv

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

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


    rootmaster# ls /var/nis 
NIS_COLD_START NIS_SHARED_CACHE
rootmaster# rm -rf /var/nis/*
rootmaster# ps -ef | grep nis_cachemgr
 root 295 260 10 15:26:58 pts/0 0:00 grep nis_cachemgr
 root 286 1 57 15:21:55 ? 0:01 /usr/sbin/nis_cachemgr
rootmaster# kill -9 286

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

  8. サーバーのデーモンを終了します。

    現在作業しているマシンが、すでに NIS+ サーバーとして使用されていた場合は、rpc.nisd または rpc.nispasswdd が実行されているかどうか確認してください。実行されている場合は、どちらのデーモンも終了してください。

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

    手順 16 までは、実際には管理グループを作成しませんが、ここで管理グループの名前を指定する必要があります。ここで管理グループの名前を指定することによって、ルートドメインの 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 ディレクトリが生成されます。

    この下には root.object. という名前のファイルがあります。 


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

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

    以降の手順では、この手順で作成されるディレクトリの下に、他のファイルが追加されます。UNIX ディレクトリを直接調べることによって、これらのファイルの存在を検証できますが、NIS+ にはもっと便利なコマンドがあります。以下の手順では、必要に応じてこれらのコマンドを実行します。

    注意 – 注意 –

    nisinit など NIS+ の構成手順によって作成された /var/nis、/var/nis/data といったディレクトリ、およびその下のファイルは、名前を変更しないでください。Solaris 2.4 以前では、/var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルとサブディレクトリ /var/nis/hostname が存在していました。またサブディレクトリ /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. NIS+ デーモンを -Y で起動します (NIS 互換の場合のみ)。

    この手順は、NIS 互換モードでルートドメインを設定している場合にだけ実行します。標準の NIS+ ドメインを設定する場合は、この代わりに 手順 12 を実行します。この手順には、NIS クライアントの DNS 転送機能をサポートするための操作手順が含まれます。

    「a」では、NIS+ デーモンを NIS 互換モードで起動します。「b」では、NIS+ デーモンはこのサーバーが再起動されたとき、確実に NIS 互換モードで再起動します。手順 b の「b」の後は、手順 14 に進んでください。

    1. rpc.nisd に -Y、-B、-S 0 オプションを使用して実行します。


      rootmaster# rpc.nisd -Y -B -S 0 options

      -Y オプションを指定すると、NIS+ 要求だけでなく NIS 要求にも応答します。-B オプションを指定すると DNS 転送をサポートします。-S 0 フラグは、サーバーのセキュリティレベルに 0 を設定します。この時点では、ブートストラップ動作のためにこの設定が必要です。cred テーブルはまだ存在しないため、NIS+ 主体は資格をもつことができません。これより高いセキュリティレベルを使用した場合、ユーザーがサーバーから締め出されてしまいます。

    2. /etc/init.d/rpc ファイルを編集します。

      /etc/init.d/rpc ファイル内で文字列 EMULYP=”Y” を検索します。その行のコメント指定を解除し、DNS 転送機能を使用できるようにするために、-B フラグを追加します。

      DNS 転送を使用する rpc ファイルの場合


      EMULYP=”-Y -B”

      DNS 転送を使用しない rpc ファイルの場合


      EMULYP=”-Y”

      DNS 転送機能を使用する必要がない場合、この行をコメント解除しますが、-B フラグは追加しません。

  12. NIS+ デーモンを起動します (標準 NIS+ の場合のみ)。

    rpc.nisd コマンドを使用しますが、必ず -S 0 フラグを追加してください。 


    rootmaster# rpc.nisd -S 0

    -S 0 フラグは、サーバーのセキュリティレベルに 0 を設定します。この時点では、ブートストラップ動作のためにこの設定が必要です。cred テーブルはまだ存在しないため、NIS+ 主体は資格をもつことができません。これより高いセキュリティレベルを使用した場合、ユーザーがサーバーから締め出されてしまいます。

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

    手順 11 または 手順 12 を実行すると、名前空間には次のものが作成されます。

    • ルートディレクトリオブジェクト (root.dir)

    • NIS+ デーモン (rootmaster) を実行するルートマスターサーバー (rpc.nisd)

    • マスターサーバー用のコールドスタートファイル (NIS_COLD_START)

    • トランザクションログファイル (trans.log)

    • テーブル辞書ファイル (data.dict)

    ルートディレクトリオブジェクトは、手順 10 で作成したディレクトリに格納されます。ls コマンドを使用して、ディレクトリの内容を確認してください。


    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 -ef | 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 テーブルへの読み取り権を未認証クラスに割り当てます。

    nisls でルートディレクトリの内容を調べたとき (手順 12)、これが空であったことを思い出してください。現在は 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 引数はルートマスターサーバー名です。この例では、rootmaster.doc.com. を 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+ キャッシュマネージャを起動します。

    キャッシュマネージャは、NIS+ クライアント (この場合、ルートマスターサーバー) に関する位置情報のローカルキャッシュを管理します。初期の情報をクライアントのコールドスタートファイル (手順 11 または 手順 12 で作成) から入手し、これを /var/nis 内の NIS_SHARED_DIRCACHE という名前のファイルに保存します。

    キャッシュマネージャを起動するには、次に示すように、nis_cachemgr コマンドを入力します。 


    rootmaster# nis_cachemgr

    キャッシュマネージャがいったん起動されたら、このプロセスを明示的に終了させた場合を除いて、再起動する必要はありません。クライアントが再起動されたときには、/var/nis 内の NIS_COLD_START ファイルがキャッシュマネージャを自動的に起動するため、キャッシュマネージャを再起動する必要はありません。

  20. NIS+ デーモンをセキュリティレベル 2 で再起動します。

    これで、ルートマスターサーバーには DES 資格があり、ルートディレクトリオブジェクトにはルートマスターの公開鍵のコピーがあるため、ルートマスターをセキュリティレベル 2 で再起動できます。まず既存のデーモンのプロセスを終了し、次にこれをセキュリティレベル 2 で再起動します。

    標準 NIS+ ドメインの場合


    rootmaster# ps -e | grep rpc.nisd
1081 ? 0:03 rpc.nisd -s 0
rootmaster# kill 1081
rootmaster# rpc.nisd

    NIS 互換のルートドメインの場合、必ず -Y フラグ (および -B フラグ) を使用してください。

    NIS 互換の NIS+ ドメインの場合


    rootmaster# ps -e | grep rpc.nisd
1081 ? 0:03 rpc.nisd -Y -B -s 0
rootmaster# kill 1081
rootmaster# rpc.nisd -Y -B

    セキュリティレベル 2 はデフォルトであるため、-S 2 フラグは不要です。

    注 –

    実際にユーザーが存在するネットワークは、常にセキュリティレベル 2 で運用してください。セキュリティレベル 0 およびレベル 1 は、設定およびテストの目的だけに使用します。本番環境ネットワークは、レベル 0 または 1 で稼動しないでください。

  21. 自分の 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+ 資格の管理」を参照してください。

  22. 自分の 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 ファイルに格納していない場合、このメッセージは表示されません。

  23. 他のシステム管理者の資格を追加します。

    そのルートドメインで作業する他のシステム管理者の LOCAL 資格と DES 資格を追加します。これには 以下の方法があります。

    • 他の管理者に一時的な資格を作成するには、NIS+ モードで実行されている Solstice AdminSuite (使用できる場合) を使用すると簡単です。

    • 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 テーブルにエントリが生成されます (パスワード列は除く)。次の nisaddent により、shadow 列が生成されます。各システム管理者は、chkey コマンドを使用することによって、自分のネットワークパスワードを後で変更できます。この手順については、第 12 章「NIS+ 資格の管理」を参照してください。

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

    この手順を実行するには、他のシステム管理者がダミーパスワードを変更するまで待つ必要はありません。-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.

  25. 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 にまとめます。このまとめは、簡単な場合を想定しています。このまとめを参考として使用する前に、作業全体の説明を十分に理解しておいてください。また、ここでは、各コマンドに対するサーバーの応答を示していません。

表 5–2 ルートドメインを設定する手順のまとめ

タスク 

コマンド 

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

rootmaster% su

Password: root パスワードを入力する

ドメイン名をチェックする 

# domainname

スイッチファイルをチェックする  

# more /etc/nsswitch.conf

NIS+ データを削除し、プロセスを終了する 

# rm -rf /var/nis*

管理 (admin) グループを指定する 

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

ルートマスターサーバーを初期設定する 

# nisinit -r

NIS 互換の場合のみ : 

デーモンを -Y -B, S 0 で起動する

EMULYP=-Y -B に変更する

# rpc.nisd -Y -B -S 0

# vi /etc/inet.d/rpc

標準 NIS+ の場合のみ : デーモンを -S 0 で起動する

# rpc.nisd -S 0

org_dir と、groups_dir テーブルを作成する

# /usr/lib/nis/nissetup [-Y]

ルートマスターサーバー用の DES 資格を作成する 

#nisaddcred des

Enter login password: ログインパスワードを入力する

管理グループを作成する

# nisgrpadm -c admin.doc.com.

ルートディレクトリに完全なグループ権を割り当てる 

# nischmod g+rmcd doc.com.

ルートマスターを管理グループに追加する 

# nisgrpadm -a admin.doc.com. rootmaster.doc.com.

ルートディレクトリの鍵を更新する。org_dir の鍵を更新する。groups_dir の鍵を更新する

# /usr/lib/nis/nisupdkeys doc.com.

# /usr/lib/nis/nisupdkeys org_dir.doc.com.

# /usr/lib/nis/nisupdkeys groups_dir.doc.com.

NIS+ キャッシュマネージャを起動する 

# nis_cachemgr

既存のデーモンを終了する 

# ps -ef | grep rpc.nisd

# kill -9 process-id

NIS+ デーモンを再起動する(NIS 互換には -Y を、DNS には -B を使用する)

# rpc.nisd [-Y] [-B]

自分の LOCAL 資格を追加する 

# nisaddcred -p 11177 -P topadmin.doc.com. local

自分の DES 資格を追加する 

# nisaddcred -p unix.11177@doc.com -P topadmin.doc.com. desEnter login password:

他のシステム管理者の資格を追加する 

他のシステム管理者を管理グループに追加する

# nisaddcred ... nisgrpadm -a admin.doc.com members

第 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+ に精通した管理者や、設定スクリプトでは提供されない標準以外の機能や構成を必要とする管理者だけが使用してください。Solstice AdminSuite がある場合には、これを使用すると NIS+ クライアントマシンの追加や設定の作業が簡単にできます。

クライアントを設定する作業のうち、手順 10 では、ブロードキャスト、ホスト名、またはコールドスタートファイルのうちのどれかを使用する方法を選択してください。それぞれ実装方法が異なるため、各作業について別々に説明します。クライアントを初期設定したあとは、手順 11 に戻ってクライアントの設定を続けてください。

この章の最後の作業では、マシンのドメイン名を変更する方法を取り上げています。

クライアントの構成

ここでは、ルートドメイン内であるかどうかとは関係なく、一般的な NIS+ クライアントの構成方法を説明します。ここでの説明は、通常の NIS+ クライアント、および後で NIS+ サーバーとなるクライアントに当てはまります。また、標準の NIS+ ドメイン内、および NIS 互換ドメイン内のクライアントにも当てはまります。

注意 – 注意 –

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

NIS+ クライアントの設定には、次の作業が必要です。

ただし、ルートドメインの設定と同様、クライアントの設定も、これら 3 つの作業を順番に実行するような単純なものではありません。構成手続を実行しやすくするため、これらの作業を個々の手順に分割し、次に示すように、これらの手順を最も効率的な順に並べてあります。

  1. ドメインのマスターサーバーにログインします。

  2. 新しいクライアントマシン用の DES 資格を作成します。

  3. マスターサーバーで使用されている Diffie-Hellman キー長を確認します。

  4. クライアントにスーパーユーザーとしてログインします。

  5. クライアントに新しいドメイン名を設定します。

  6. nscd の停止と再起動を行います。

  7. クライアントの nsswitch.conf ファイルの設定を確認します。

  8. クライアントの Diffie-Hellman キーを設定します。

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

  10. クライアントを初期設定します。

  11. 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+ のアクセス権の管理」を参照してください。

前提条件

クライアントの資格を設定するシステム管理者は、次の条件をすべて満たしている必要があります。

クライアントは次の条件をすべて満たしている必要があります。

必要な情報

クライアントの設定 — 作業マップ

表 6–1 クライアントの構成

作業 

説明 

参照先 

クライアントの設定 

クライアントの資格を作成する。クライアントマシンを準備して、NIS+ クライアントとして初期設定する 

NIS+ クライアントを設定する方法

NIS+ クライアントを設定する方法

  1. ドメインのマスターサーバーにログインします。

    スーパーユーザーとして、または自分自身のユーザー名でログインします。どちらでログインするかは、どちらの NIS+ 主体がドメインの cred テーブルに資格を追加するための適切なアクセス権を所有しているのかに依存します。

  2. 新しいクライアントマシン用の DES 資格を作成します。

    -p と -P の引数を付けた nisaddcred コマンドを実行します。 


    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# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
client1# sh /etc/init.d/nscd stop
client1# sh /etc/init.d/nscd start

    キーサーバーをこの時点で終了および再起動する必要はありません。手順 11 で 行います。

  8. 手順 3 の情報を使用して、Diffie-Hellman キー長を設定します。

    たとえば、次のようにします。


    client# nisauthconf dh640-0 des

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

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


    client1# ls /var/nis
NIS_COLD_START NIS_SHARED_CACHE
client1# rm -rf /var/nis/*
client1# ps -ef | grep nis_cachemgr
 root 295 260 10 15:26:58 pts/0 0:00 grep nis_cachemgr
 root 286 1 57 15:21:55 ? 0:01 /usr/sbin/nis_cachemgr
client1# kill -9 286

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

  10. クライアントを初期設定します。

    クライアントを初期設定するには、次の 3 つの方法があります。 3 つの方法のうち、いずれかを選択して実行します。クライアントの初期設定が終了したら、手順 11 に進みます。

  11. keyserv デーモンを終了してから再起動します。

    この手順では、非公開鍵をキーサーバー上に格納します。

    1. keyserv デーモンを終了します。

      この手順によって、キーサーバーが保持していたクライアントに関するスイッチ情報も更新されます。

    2. /etc/.rootkey ファイルを削除します。

    3. キーサーバーを再起動します。

      次の例では、手順 11 の内容を示しています。


      client1# ps -e | grep keyserv
 root 145 1 67 16:34:44 ? keyserv
client1# kill 145
client1# rm -f /etc/.rootkey
client1# keyserv

    4. keylogin -r を実行します。

      この手順では、クライアントの非公開鍵をキーサーバーに格納します。また、クライアント上のスーパーユーザーが NIS+ を使用するために keylogin を行わなくてもすむように、/etc/.rootkey にコピーを保存します。-r オプションを付けて keylogin を実行します。パスワードの入力を求められたら、クライアントのスーパーユーザーパスワードを入力します。このパスワードは、クライアントの DES 資格を作成するために与えられたパスワードと同じでなければなりません。 


      client1# keylogin -r 
Password:
Wrote secret key into /etc/.rootkey

    5. クライアントを再起動します。

DNS 転送の設定

NIS+ クライアントの DNS 転送機能を有効にするには

  1. スーパーユーザーとしてログインします。

  2. /etc/resolve.conf ファイルの hosts 行を構成します(たとえば、hosts:nisplus dns files とします)。

該当するサーバー上に /etc/resolve.conf ファイルが存在する場合は、この NIS 実装では DNS へ要求を転送するために、ypstart によって ypserv デーモンが -d オプション付きで「自動的に」起動されます。 DNS 転送を停止するには、/usr/lib/netsvc/yp/ypstart スクリプトを編集して、ypserv コマンドの -d オプションを削除します。そのあと、マシンをリブートしてください。

マシンのドメイン名を変更する

この作業では、マシンのドメイン名を変更します。マシンのドメイン名は通常インストール時に設定されるため、domainname コマンドを引数なしで実行して、マシンのドメイン名をチェックしてからこの作業を実行してください。

セキュリティについて

この作業は、ドメイン名を変更するマシン上のスーパーユーザーとして実行しなければなりません。

必要な情報

マシンのドメインの変更 - 作業マップ

表 6–2 クライアントの構成

作業 

説明 

参照先 

マシンのドメインの変更 

nisrestore を使用して、クライアントマシンのドメインを変更する

クライアントのドメイン名を変更する方法

クライアントのドメイン名を変更する方法

  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 つの種類があります。

ブロードキャストにより初期設定する

この方法では、クライアントの存在するサブネット上に IP ブロードキャストを送信して NIS+ クライアントを「初期化」します。

初期化の方法としてはこれが最も簡単ですが、最も安全性の低い方法でもあります。ブロードキャストに応答した NIS+ サーバーはクライアントが自分自身のコールドスタートファイルに格納する必要がある情報 (サーバーの公開鍵など) をすべて送信します。おそらくブローキャストに応答するのは NIS+ サーバーだけですが、クライアントからは、ブロードキャストに応答したワークステーションが確かに信用できるサーバーなのかどうか確認できません。 そのため、この方法は小規模で、セキュリティが確保されたサイトでだけ使用することをお勧めします。

セキュリティについて

この作業は、クライアント上のスーパーユーザーとして実行しなければなりません。

前提条件

クライアントと同じサブネット上に、少なくとも 1 台の NIS+ サーバーが存在しなければなりません。クライアントは、マスターサーバーで使用するのと同じ Diffie-Hellman キー長を使用する必要があります。nisauthconf(1M) を参照してください。

必要な情報

クライアントのスーパーユーザーのパスワードが必要です。

NIS+ クライアントを初期設定する — 作業マップ

表 6–3 NIS+ クライアントを初期設定する

作業 

説明 

参照先 

NIS+ クライアントを初期設定する 

nisclient コマンドを使用して NIS+ クライアントを初期設定する

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 アドレスへのメッセージを横取りし、不正なサーバーに送ることもあり得ます。

セキュリティについて

この作業は、クライアント上のスーパーユーザーとして実行しなければなりません。

前提条件

必要な情報

信頼できるサーバー名と IP アドレスが必要です。

NIS+ クライアントを初期設定する — 作業マップ

表 6–4 NIS+ クライアントを初期設定する

作業 

説明 

参照先 

ホスト名によりクライアントを初期設定する 

nisinit コマンドを使って、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+ クライアント (できれば同じドメインから) のコールドスタートファイルを使用します。NIS+ クライアントを設定する方法としてはこれが最も安全です。これにより、クライアントは、信頼できるサーバーから確実に NIS+ 情報を得ることができます。これはホスト名やブロードキャストによる初期化では保証されません。

セキュリティについて

この作業は、クライアント上のスーパーユーザーとして実行しなければなりません。

前提条件

コールドスタートファイルに指定されたサーバーは、すでに構成されており、NIS+ を実行していなければなりません。

クライアントは、マスターサーバーで使用するのと同じ Diffie-Hellman キー長を使用する必要があります。nisauthconf(1M) を参照してください。

必要な情報

コピーするコールドスタートファイルの名前と位置が必要です。

NIS+ クライアントを初期設定する — 作業マップ

表 6–5 NIS+ クライアントを初期設定する

作業 

説明 

参照先 

コールドスタートファイル経由でクライアントを初期設定する 

nisinit コマンドを使って、NIS+ クライアントをコールドスタートファイル経由で初期設定する

コールドスタートファイルを使用して NIS+ クライアントを初期設定する方法

コールドスタートファイルを使用して NIS+ クライアントを初期設定する方法

  1. 他のクライアントのコールドスタートファイルをコピーします。

    他のクライアントのコールドスタートファイルを、新しいクライアントのディレクトリにコピーします。これを行うには、クライアント上のスーパーユーザーとしてではなく、自分のユーザー名でログインしている間に行う方が簡単です。クライアントを初期設定する前に、必ずスーパーユーザーになってください。

    ただし、NIS_COLD_START ファイルを /var/nis にコピーしないでください。初期設定中にこのファイルは上書きされます。次の例では、client1 のコールドスタートファイルを、初期設定されていない client2 の /tmp ディレクトリにコピーします。 


    client2# exit
client2% rcp client1:/var/nis/NIS_COLD_START /tmp
client2% su

  2. コールドスタートファイルからクライアントを初期設定します。

    次に示すように、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 とします 。これは最も簡単なケースを想定しているため、このまとめを参考用として使用するには、その前に自分の実際の作業の詳細を理解することが必要です。簡略化のため、ここでは各コマンドに対するサーバーの応答を示していません。

表 6–6 クライアントを設定する方法のまとめ

タスク 

コマンド 

ドメインのマスターサーバーにログインする 

rootmaster%

クライアントの DES 資格を作成する 

rootmaster% nisaddcred -p unix.client1.doc.com -P client1.doc.com. des

Diffie-Hellman キー長を確認する 

rootmaster% nisauthconf

クライアントにスーパーユーザーとしてログインする 

client1% su

Password: root パスワードを入力する

クライアントのドメイン名を設定する 

client1# domainname doc.com

client1# domainname> /etc/defaultdomain

クライアントのスイッチ構成ファイルが正しく設定されていることをチェックする 

client1# more /etc/nsswitch.conf

Diffie-Hellman キー長を設定する 

client1# nisauthconf dh640-0 des

/var/nis の下のファイルを削除する

client1# rm -rf /var/nis/*

クライアントを初期設定します。 

client1# nisinit -c -H rootmaster

キーサーバーのプロセスを終了して、再起動する 

client1# ps -ef | grep keyserv

client1# kill -9 process-id

client1# keyserv

クライアント上でキーログインを実行する 

client1# keylogin -r password:

クライアントを再起動する 

client1# init 6

第 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 互換構成の手順の相違

NIS 互換の NIS+ サーバーと標準の NIS+ サーバーの設定における違いは、ルートマスターサーバーの場合と同じです ( 標準構成と NIS 互換構成の手順の相違を参照)。NIS 互換サーバー用の NIS+ デーモンは -Y オプション (DNS 転送を使用する場合は、-B オプションを追加する) を使用して起動しなければなりません。これによって、サーバーは NIS クライアントからの要求に応答できます。これについては、「NIS+ サーバーを構成する方法」の手順 2 (標準の NIS+ サーバーの場合は、手順 3) で説明します。

注 –

-Y または -B のいずれかのオプションを使用して rpc.nisd を起動した場合、必ず rpc.nisd_resolv という副デーモンが生成され、名前の解決を行います。この副デーモンは、rpc.nisd 主デーモンを終了させた場合は、必ず別個に終了させなければなりません。

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

  1. 新しい複製サーバーにスーパーユーザーとしてログインします。

  2. NIS+ デーモンを -Y で起動します (NIS 互換の場合のみ)。

  3. NIS+ デーモンを起動します (標準の NIS+ の場合のみ)。

セキュリティについて

注 –

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

この手順は、サーバー上のスーパーユーザーとして実行しなければなりません。起動したサーバーのセキュリティレベルによって、そのクライアントが備えるべき資格が決まります。たとえば、サーバーがセキュリティレベル 2 で構成された場合、サーバーがサポートするドメイン内のクライアントは、DES 資格を必要とします。このマニュアルの指示に従ってクライアントを構成した場合、そのクライアントは適切なドメインに DES 資格を持ち、セキュリティレベル 2 でサーバーを起動できます。

注 –

セキュリティレベル 0 は、管理者による構成とテストの目的だけに使用します。セキュリティレベル 1 はサポートされていません。一般のユーザーが通常の業務を行う環境では、レベル 0 またはレベル 1 を使用せず、常にセキュリティレベル 2 を使用してください。

前提条件

必要な情報

サーバーに変換するクライアントのスーパーユーザーパスワードが必要です。

NIS+ サーバーを構成する方法

1 つのマスターサーバーまたは複製サーバーから複数のドメインにサービスを提供することは可能ですが、あまりお勧めしません。

  1. 新しい複製サーバーにスーパーユーザーとしてログインします。

    以下の手順では、クライアントの構成に従って、マシンを NIS+ クライアントとして設定した後、マシンを再起動したことを前提としています。マシンを再起動すると、次の手順の推奨前提条件であるキャッシュマネージャが起動します。マシンを再起動しなかった場合、nis_cachemgr を使用して、ここでキャッシュマネージャを再起動します。

  2. NIS+ デーモンを -Y で起動します (NIS 互換の場合のみ)。

    この手順は、サーバーを NIS 互換モードで設定する場合にだけ実行します。標準の NIS+ サーバーを設定する場合は、この代わりに 手順 3 を実行します。この手順には、NIS クライアントの DNS 転送機能をサポートするための操作説明も含まれています。

    この手順は、2 つに分かれています。最初の手順では、NIS+ デーモンを NIS 互換モードで起動します。2 つめの手順では、サーバーが再起動されたときに、NIS+ デーモンが NIS 互換モードで再起動するように設定します。

    1. rpc.nisd に -Y と -B のフラグを付けて実行します。 


      compatserver# rpc.nisd -Y -B

      -Y オプションを指定すると、NIS+ 要求だけでなく NIS 要求にも応答します。-B オプションは DNS 転送をサポートします。

    2. /etc/init.d/rpc ファイルを編集します。

      /etc/init.d/rpc ファイル内で文字列 EMULYP="-Y" を検索して、この文字列を含む行のコメント指定を解除します。

      DNS 転送機能を使用するには、EMULYP="-Y" に -B フラグを追加します。DNS 転送機能が必要ない場合は、コメント指定の解除だけを実行し、-B フラグは追加しないでください。

      この手順によって、/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+ サーバーの設定は、この手順で完了です。作業の要約については サーバー構成の要覧を参照してください。

  3. NIS+ デーモンを起動します (標準の NIS+ の場合のみ)。

    rpc.nisd コマンドを実行します。


    server# rpc.nisd

    NIS+ デーモンが本当に実行されていることを確認するには、次のように ps コマンドを実行します。


    server# ps -ef | grep rpc.nisd
root 1081 1 16:43:33 ? 0:01 rpc.nisd
root 1087 1004 11 16:44:09 pts/1 0:00 grep rpc.nisd

    この手順によって、/var/nis/data という名前のディレクトリが作成されます。また、trans.log というトランザクションログファイルが作成され、/var/nis ディレクトリに格納されます。 


    compatserver# ls -F /var/nis
NIS_COLD_START data/ trans.log data.dict

    compatserver.log ファイルは、トランザクションログです。トランザクションログの内容を確認するには、nislog コマンドを使用します。使用方法については、第 18 章「NIS+ ディレクトリの管理」を参照してください。

    注意 – 注意 –

    /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) でリモートサイトに接続されている場合にだけ、複製サーバーを置くようにしてください。

複製サーバーの分散および最適な複製サーバー数については、サーバーの必要条件を決める を参照してください。既存のドメインに複製サーバーを追加するには、その複製サーバーを構成してから該当する名前空間の NIS+ データセットをロードします。

新しい複製サーバーを構成して NIS+ データセットをロードする方法には、次の 2 通りがあります。

NIS+ コマンドを使って複製サーバーを構成する

この節では、NIS+ コマンドを使って複製サーバーを既存のドメインに追加する方法について説明します。

セキュリティについて

この作業を実行する NIS+ 主体には、ドメインのディレクトリオブジェクトに対する変更権が必要です。

前提条件

必要な情報

NIS+ コマンドを使って複製サーバーを構成する— 作業マップ

表 7–1 NIS+ コマンドを使って複製サーバーを構成する

作業 

説明 

参照先 

NIS+ サーバーを設定する 

NIS+ コマンドを使って複製サーバーを設定する 

NIS+ コマンドを使って複製サーバーを構成する方法

NIS+ コマンドを使って複製サーバーを構成する方法

この例では、マスターサーバー名を master1、新しい複製サーバー名を replica2 とします。

  1. ドメインのマスターサーバーにログインします。

  2. rpc.nisd が稼働中であることを確認します。

  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+ データセットをロードします。NIS+ データセットのロードには、2 通りの方法があります。

    • 「nisping」。何もしなければ、マスターサーバーによって nisping コマンドが実行され、該当する名前空間データが新たに構成された複製サーバーにロードされます。名前空間が大きい場合は、データのロードに時間がかかることがあります。データのロード中は、ネーミング情報の要求は遅延することがあります。詳細は、nisping を使ってデータを複製サーバーにロードするを参照してください。

    • 「バックアップと復元」。nisping によるデータ転送に割り込みをかけ、NIS+ のバックアップ機能と復元機能を使って、名前空間データを新たに構成した複製サーバーにロードできます (nisrestore を使ってデータを複製サーバーにロードするを参照)。他の方法に比べて格段に早く効率的なので、こちらの方法をお勧めします。

nisrestore を使ってデータを複製サーバーにロードする

この節では、NIS+ のバックアップ機能と復元機能を使って名前空間データを新しい複製サーバーにロードする方法について説明します。この方法を使ってデータを複製サーバーにロードすることをお勧めします。

セキュリティについて

この作業を実行する NIS+ 主体には、ドメインのディレクトリオブジェクトに対する変更権が必要です。

前提条件

nisrestore を使ってデータを複製サーバーにロードする — 作業マップ

表 7–2 nisrestore を使ってデータを複製サーバーにロードする

作業 

説明 

参照先 

nisrestore を使ってデータを複製サーバーにロードする

nisrestore を使って名前空間データをロードする

名前空間データをロードする方法—nisrestore による方法

名前空間データをロードする方法—nisrestore による方法

この例では、マスターサーバー名を master1、新しい複製サーバー名を replica2 とします。

  1. 複製サーバー上の rpc.nisd を終了させます。

    マスターサーバーから複製サーバーへの名前空間データの自動ロード ( nisping による) が中断されます。

  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 が必要なデータを検証または見つけることができないという旨のエラーメッセージが出た場合は、次に示すように -f オプション付きで実行してみてください。


    replica2# nisrestore -f -a /var/master1_bakup

  4. 新しい複製サーバー上で rpc.nisd を再実行します。

    NIS+ サーバーを構成する方法 を参照してください。

nisping を使ってデータを複製サーバーにロードする

この節では、nisping コマンドを使って名前空間データを新しい複製サーバーにロードする方法について説明します。通常、このプロセスは自動的に実行されるため、nisping コマンドを実行する必要はまずありません。

nisping コマンドを使う方法の問題点は、マスターサーバーから複製サーバーへデータの再同期をとるために、NIS+ プロトコルを使ったネットワーク上のデータのやりとりが必要だということです。名前空間が大きい場合は、この処理に何時間もかかり、その間、名前管理情報の要求に対する応答が遅れることがあります。

セキュリティについて

この作業を実行する NIS+ 主体には、ドメインのディレクトリオブジェクトに対する変更権が必要です。

前提条件

nisping を使ってデータを複製サーバーにロードする — 作業マップ

表 7–3 nisping を使ってデータを複製サーバーにロードする

作業 

説明 

参照先 

nisping を使ってデータを複製サーバーにロードする

nisping を使ってデータを複製サーバーにロードする

名前空間データをロードする方法—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 つの表は、最も簡単な場合を想定しているため、参考用として使用するには、実際の自分の作業の詳細を理解している必要があります。また、ここでは、各コマンドに対するサーバーの応答を示していません。

表 7–4 複製サーバー replica2 を doc.com. に追加する

タスク 

コマンド 

ドメインマスターサーバーにスーパーユーザーとしてログインする 

master1% su

新しい複製サーバーを指定する 

# nismkdir -s replica2 doc.com.

# nismkdir -s replica2 org_dir.doc.com.

# nismkdir -s replica2 groups_dir.doc.com.

複製サーバーに対して nisping を実行する

# /usr/lib/nis/nisping doc.com.

# /usr/lib/nis/nisping org_dir.doc.com.

# /usr/lib/nis/nisping groups_dir.doc.com.

注 –

上記の例で説明したように、新しい複製サーバーにデータをロードする場合は、nisping を使用するより NIS+ のバックアップと復元機能を使用した方が簡単です。詳細については、nisrestore を使ってデータを複製サーバーにロードする を参照してください。

表 7–5 非ルートマスターサーバーを起動するには

タスク 

コマンド 

root としてサーバーにログインする 

server% su

NIS 互換モードの場合のみ: -Y -B フラグを使用してデーモンを起動する

server# rpc.nisd -Y -B

NIS 互換モードの場合のみ: EMULYP= -Y -B に変更する

server# vi /etc/inet.d/rpc

NIS+ モードの場合のみ: デーモンを起動する 

server# rpc.nisd

第 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 コマンドを使用します。

前提条件

必要な情報

非ルートドメインを設定する — 作業マップ

表 8–1 非ルートドメインを設定する

作業 

説明 

参照先 

非ルートドメインを設定する 

NIS+ コマンドを使って非ルートドメインを設定する 

非ルートドメインを設定する方法

非ルートドメインを設定する方法

  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 は必ず (複製サーバーではなく) マスターサーバー上で実行してください。複製サーバーで実行すると、マスターサーバーと複製サーバーの間で通信上の問題が発生します。

    ディレクトリオブジェクトは /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+ テーブル内の情報にアクセスできるよう、nobody クラスに読み取り権が割り当てられます。

    /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 は、サブドメインの構成に必要な手順のまとめです。これは最も簡単なケースを想定しているため、このまとめを参考用として使用するには、その前に自分の実際の作業の詳細を理解することが必要です。また、ここでは、各コマンドに対するサーバーの応答を示していません。

表 8–2 まとめ - サブドメインを設定する方法

作業 

コマンド 

ドメインマスターサーバーにスーパーユーザーとしてログインする 

smaster% su

ドメインの管理グループを指定する 

# NIS_GROUP=admin.sales.doc.com.

# export NIS_GROUP

ドメインのディレクトリを作成し、そのサーバーを指定する 

# nismkdir -m smaster -s salesreplica sales.doc.com.

org_dir 、groups_dirおよびテーブルを作成する。NIS 互換の場合、-Y を使用する

# /usr/lib/nis/nissetup sales.doc.com.

管理グループを作成する 

# nisgrpadm -c admin.sales.doc.com.

ドメインのディレクトリに対して、完全なグループ権を割り当てる 

# nischmod g+rmcd sales.doc.com.

管理グループにサーバーを追加する 

# nisgrpadm -a admin.sales.doc.com. smaster.doc.com. sreplica.doc.com.

他のシステム管理者の資格を追加する 

# nisaddcred -p 22244 -P juan.sales.doc.com. local

# nisaddcred -p unix.22244@sales.doc.com. juan.sales.doc.com. DES

ドメインの管理グループに管理者を追加する 

# nisgrpadm -a admin.sales.doc.com. juan.sales.doc.com.

第 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+ に精通した管理者や、設定スクリプトでは提供されない標準以外の機能や構成を必要とする管理者だけが使用してください。さらに、Solstice AdminSuite ツールをお持ちの場合は、NIS+ テーブルに関連する作業が簡単になります。

NIS+ テーブルを生成するには次の 4 種類の方法があります。

マップまたはファイルからテーブルを生成する場合、第 5 章「ルートドメインの設定」および第 8 章「非ルートドメインの構成」で説明する手順に従って、ルートまたはサブドメインの設定作業の中で、あらかじめテーブルを作成しておく必要があります。ドメインテーブルは、テーブルの作成後いつでも生成できますが、ドメインの設定が完了したらすぐに生成しておくことをお勧めします。テーブルを生成すると、クライアントに関する必要な情報がすでにドメインテーブル内に格納されることになるため、クライアントの追加が簡単にできます。

テーブルの生成の方法 (必要な場合)

ファイルまたは NIS マップからテーブルを生成する場合、次の 3 つの方法を使用できます。

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+ テーブルをファイルから生成する — 作業マップ

表 9–1 NIS+ テーブルをファイルから生成する

作業 

説明 

参照先 

NIS+ テーブルをファイルから生成する 

NIS+ テーブルをファイルから生成する 

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 度に 1 つずつ転送します。


    aliases
bootparams
ethers
group
hosts
ipnodes
netgroup
netmasks
networks
protocols
rpc
services

    publickey、automounter、passwd および shadow の各ファイルは、実行する手順がそれぞれ少し異なります。publickey ファイルの場合は、手順 6 に進んでください。オートマウンタファイルの場合は、手順 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_GROUP によって指定されたグループによって所有されます。

前提条件

必要な情報

NIS マップの名前と位置が必要です。

NIS+ テーブルを NIS マップから生成する — 作業マップ

表 9–2 NIS+ テーブルを NIS マップから生成する

作業 

説明 

参照先 

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

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

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

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

  1. データを転送する各 NIS マップをチェックします。

    不正なエントリがないことを確認します。正しいデータが、所定の場所に正しい書式で記録されていることを確認します。エントリのうち、古いもの、無効なもの、破損しているものは削除します。また、不完全なエントリや一部のみのエントリも削除します。不完全なエントリは、設定を完了した後に追加する方が、不完全なエントリや破損したエントリを転送するよりも簡単です。

  2. NIS+ クライアントにログインします。

    この作業はどの NIS+ クライアントからでも実行できます。ただし、そのクライアントは、情報の転送先となるテーブルと同じドメインに所属していなければなりません。ここで示す例では、ルートマスターサーバーを使用します。これらの例では、システム管理者はスーパーユーザーとしてログインしているため、この操作を実際に実行している (適切な資格とアクセス権を必要とする) NIS+ 主体は、ルートマスターサーバーです。

  3. このシェルのコマンド検索パスに /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

  4. nisaddent を使用して、次のマップを 1 度に 1 つずつ転送します。 

    aliases
bootparams
ethers
group
hosts
netgroup
netmasks
networks
passwd
protocols
rpc
services

    publickey とオートマウンタマップでは、少し手順が異なります。publickey ファイルの場合は、「NIS+ テーブルをファイルから生成する方法」の 手順 6 に、オートマウンタファイルの場合は、手順 7 に進んでください。

    デフォルトでは、nisaddent はファイル情報をテーブル情報に追加します。置換またはマージを行うには、-r または -m のオプションを使用します。

    置換する場合、次のように入力します。


    rootmaster# nisaddent -r -y nisdomain table

    追加する場合、次のように入力します。


    rootmaster# nisaddent -a -y nisdomain table

    マージする場合、次のように入力します。


    rootmaster# nisaddent -m -y nisdomain table

    初めてテーブルを生成するときに最適なオプションは、デフォルトの -a オプションです。NIS+ テーブルを NIS マップまたは /etc 内のファイルと同期させるための最適なオプションは -m (マージ) オプションです。

    -y (小文字) オプションは、テキストファイルではなく、NIS ドメインを示します。nisdomain 引数は、ユーザーが NIS+ テーブルに転送しようとしているマップを持つ NIS ドメインの名前です。実際のマップを指定する必要はありません。nisaddent ユーティリティは、table 引数に対応する NIS マップを自動的に選択します。次に例をいくつか示します。


    rootmaster# nisaddent -m -y olddoc hosts
rootmaster# nisaddent -m -y olddoc passwd
rootmaster# nisaddent -m -y olddoc groups

    最初の例では、olddoc (NIS) ドメイン内の hosts.byname マップと hosts.byaddr マップの内容を、ルートドメイン (NIS+) 内の NIS+ hosts テーブルに転送します。2 番目の例では、パスワード関連情報を格納している NIS マップを、NIS+Passwd テーブルに転送します。3 番目の例では、グループ関連情報で同じことを実行します。nisaddent コマンドの詳細については、第 19 章「NIS+ テーブルの管理」を参照してください。

  5. publickey マップを転送します。

    ドメインの cred テーブルには、すでにいくつかの資格が格納されているため、cred テーブルに転送する publickey マップの内容によって、これらの資格が上書きされないように確認する必要があります。

    1. 初めに、publickey マップをファイルにダンプします。続いて、テキストエディタでそのファイルをオープンします。 


      rootmaster# makedbm -u /var/yp/olddoc/publickey.byname /etc/publickey.xfr 
rootmaster# vi /tmp/publickey.tmp

    2. publickey マップから、ログインしているマシンの資格を削除します。

      rootmaster に対しては、次のような行は、すべて削除してください。 


      unix.rootmaster@doc.com public-key:private-key [alg-type]

    3. これにより、マップではなく「ファイル」の内容を cred テーブルに転送できます。nisaddent に -a (追加) オプションを付けて実行します。 


      rootmaster# nisaddent -a -f /etc/publickey.xfr -t cred.org_dir Publickey

      ただし、この操作は DES 資格を cred テーブルに転送するだけです。cred テーブルに対する自分の LOCAL 資格は自分で作成する必要があります。

  6. オートマウンタ情報を転送します。

    nissetup ユーティリティは auto_master テーブルと auto_home テーブルを作成しますが、これらは標準の NIS+ テーブルとはみなされません。したがって、これらのテーブルに情報を転送するには、少し異なる構文が必要となります。 


    rootmaster# nisaddent -y olddoc -Y auto.master -t auto_master.org_dir key-value
rootmaster# nisaddent -y olddoc -Y auto.home -t auto_home.org_dir key-value

    NIS ドメイン名 (この例では olddoc) と同様、-m と -y のオプションが必要です。しかし、NIS マップ名 (auto.master など) の前には -Y (大文字) を付けなければなりません。次に、オートマウンタの「テキストファイル」を転送するときに必要なように、標準の NIS+ テーブルであることを示す -t オプションを使用しなければなりません。この引数は、NIS+ ディレクトリオブジェクト (auto_master.org_dir) とテーブルの種類 (key-value) です。NIS+ テーブル名の後ろには必ず接尾辞 org_dir を追加してください。

  7. nisping を実行して更新内容を複製サーバーに送ります。

    nisping を実行すると、複製サーバーに変更が反映されます。 


    master1# nisping domain 
master1# nisping org_dir.domaincom. 
master1# nisping groups_dir.domain

  8. テーブルに対しチェックポイントを実行します。

    この手順により、ドメインをサポートしている全サーバーが、それらの .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, 1994
Master server is rootmaster.doc.com.
checkpoint succeeded.

    スワップ空間が不足している場合、サーバーはチェックポイントを正常に実行できませんが、そのことを通知しません。スワップ空間が十分あることを確認する方法として、niscat コマンドを使ってテーブルの内容をリスト表示する方法があります。スワップ空間が不足している場合、次のエラーメッセージが表示されます。 


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

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

NIS+ から NIS に情報を転送する

ここでは、NIS+ テーブルの内容を、Solaris 1.x の NIS マスターサーバー上の NIS マップに転送します。手順を次に示します。

  1. NIS+ サーバーにログインします。

  2. NIS+ テーブルを出力ファイルに転送します。

  3. 出力ファイルの内容を NIS マップに転送します。

NIS から NIS+ に情報を転送する際のセキュリティ上の留意点

この作業を実行するには、内容を転送する各テーブルへの読み取り権が必要です。

前提条件

マップを NIS サーバー上にあらかじめ作成しておかなければなりません。

NIS+ から NIS に情報を転送する — 作業マップ

表 9–3 NIS+ から NIS に情報を転送する

作業 

説明 

参照先 

NIS+ から NIS に情報を転送する 

NIS+ テーブルから Solaris 1.x の NIS のマスターサーバー上の NIS マップに情報を転送する 

NIS+ から NIS へ情報を転送する方法

NIS+ から NIS へ情報を転送する方法

  1. NIS+ サーバーにログインします。

    この例では、dualserver という名前のサーバーを使用します。

  2. NIS+ テーブルを出力ファイルに転送します。

    次に示すように、各テーブルごとに 1 回、-d オプションを付けた nisaddent コマンドを使用します。 


    dualserver% /usr/lib/nis/nisaddent -d -t table tabletype> filename

    -d オプションは、table の内容を /etc 内の標準のファイル形式に変換して filename に出力します。

  3. 出力ファイルの内容を NIS マップに転送します。

    NIS+ の出力ファイルは、NIS マップ用の入力ファイルとして使用できる ASCII ファイルです。これらを NIS マスターの /etc ディレクトリにコピーし、通常の方法で make を実行します。 


    dualserver# cd /var/yp
dualserver# make

所有者および管理者に対する Passwd 列へのアクセス制限

ここでは、passwd テーブルのパスワードに関係する列に対する読み取り権を所有者とテーブルの管理者だけに制限し、しかも passwd テーブル内の残りの列に対する認証主体 (アプリケーションを含む) の読み取り権に影響を与えない方法を説明します。

この作業では、次のアクセス権を設定します。


                         Nobody  Owner   Group  World
Table Level Rights:      ----    rmcd    rmcd   ----
Passwd Column Rights:    ----    rm--    rmcd   ----
Shadow Column Rights:    ----    rm--    rmcd   ----

Passwd 列のセキュリティ上の留意点

前提条件

必要な情報

必要なのは passwd テーブルの名前だけです。

所有者および管理者に対する Passwd 列へのアクセス制限 — 作業マップ

表 9–4 所有者および管理者に対する Passwd 列へのアクセス制限

作業 

説明 

参照先 

所有者および管理者に対する Passwd 列へのアクセス制限

NIS+ のコマンドを使って passwd.org_dir を変更し、所有者および管理者に対する passwd 列へのアクセスを制限する

Passwd 列へのアクセスを制限する方法

Passwd 列へのアクセスを制限する方法

  1. ドメインのマスターサーバーにログインします。

    この例ではルートマスターサーバー rootmaster を使用します。

  2. 現在のテーブルと列のアクセス権を確認します。

    niscat -o コマンドを実行します。


    rootmaster# niscat -o passwd.org_dir

    この作業では、次のような既存のアクセス権になっていることを前提としています。


    Access Rights    : ----rmcdrmcdr---
Columns          :       
                     [0]  Name              : name
                           Access Rights : r-----------r---
                     [1]  Name              : passwd
                           Access Rights : -----m----------
                     [2]  Name              : uid
                           Access Rights : r-----------r---
                     [3]  Name              : gid
                           Access Rights : r-----------r---
                     [4]  Name              : gcos
                           Access Rights : r----m------r---
                     [5]  Name              : home
                           Access Rights : r-----------r---
                     [6]  Name              : shell
                           Access Rights : r-----------r---
                     [7]  Name              : shadow
                           Access Rights : r-----------r---

    自分のアクセス権が異なる場合、別の構文を使用する必要があります。手順については、第 15 章「NIS+ のアクセス権の管理」を参照してください。

  3. テーブルのアクセス権を変更します。

    nischmod コマンドを実行して、テーブルのオブジェクトレベルのアクセス権を ----rmcdrmcd---- に変更します。 


    rootmaster# nischmod og=rmcd,nw= passwd.org_dir

  4. 列のアクセス権を変更します。

    nistbladm コマンドを -u オプションを付けて使用して、passwd 列 および shadow 列のアクセス権を次のように変更します。 


    passwd ---- rm-- ---- ----
shadow ---- r--- ---- ----
rootmaster# nistbladm -u passwd=o+r, shadow=o+r passwd.org_dir

  5. 新しいアクセス権を確認します。

    手順 2 の場合と同様、niscat -o コマンドを実行します。アクセス権は、手順 2 の出力と同じでなければなりません。

テーブルの生成のまとめ

NIS+ テーブルの生成に必要な手順のまとめを次に示しています。これは、最も簡単な場合を想定しています。このため、まとめを参考として使用する前に、作業の詳細を十分に理解しておいてください。また、このまとめでは各コマンドに対するサーバーの応答は示していません。

表 9–5 まとめ : NIS+ テーブルへのファイルの転送

作業 

コマンド 

NIS+ クライアントにログインする 

rootmaster%

転送するファイルの作業用コピーを作成する 

% cp /etc/hosts /etc/hosts.xfr

検索パスに /usr/lib/nis を追加する

% PATH=$PATH:/usr/lib/nis; export PATH

各ファイルを 1 つずつ転送する 

% nisaddent -m -f /etc/hosts.xfr hosts

publickey ファイルから古いサーバー資格を削除する

% vi /etc/publickey.xfer

資格テーブルに publickey ファイルを転送する

% nisaddent -a -f /etc/publickey.xfr cred

オートマウンタファイルを転送する 

% nisaddent -f auto.master.xfr -t auto_master.org_dir key-value

% nisaddent -f auto.home.xfr -t auto_home.org_dir key-value

テーブルディレクトリにチェックポイントを実行する 

% nisping -C org_dir

表 9–6 まとめ : NIS+ テーブルへのマップの転送

作業 

コマンド 

NIS+ クライアントにログインする 

rootmaster%

検索パスに /usr/lib/nis を追加する

% PATH=$PATH:/usr/lib/nis; export PATH

各マップを 1 つずつ転送する 

% nisaddent -m -y olddoc hosts

publickey マップをファイルにダンプする

% makedbm -u /var/yp/olddoc/publickey.byname> /etc/publickey.xfr

新しい資格を削除する  

% vi /etc/publickey.xfr

publickey ファイルを転送する

% nisaddent -a -f /etc/publickey.xfr -t cred.ortg_dir publickey

オートマウンタマップを転送する 

% nisaddent -y olddoc -Y auto.master -t auto_master.org_dir key-value

% nisaddent -y olddoc -Y auto.home -t auto_home.org_dir key-value

テーブルディレクトリにチェックポイントを実行する 

% nisping -C org_dir

表 9–7 まとめ : NIS+ テーブルを NIS マップに転送する

作業 

コマンド 

NIS+ サーバーにログインする 

dualserver%

NIS+ テーブルをファイルに転送する 

% /usr/lib/nis/nisaddent -d [-t table] tabletype > filename

ファイルを NIS マップに転送する 

% makedbm flags output-file NIS-dbm-file

表 9–8 まとめ : Passwd 列へのアクセス権を変更する

作業 

コマンド 

ドメインのマスターサーバーにログインする 

rootmaster#

テーブルの既存の権利をチェックする 

# niscat -o passwd.org_dir

テーブルに新しい権利を割り当てる 

# nischmod og=rmcd,nw= passwd.org_dir

列に新しい権利を割り当てる 

# nistbladm -u passwd=o+r, shadow=n+r passwd.org_dir

新しい権利を確認する 

# niscat -o passwd.org_dir