パート III NIS の設定と管理
ここでは、NIS ネームサービスの概要と、Solaris OS 内での NIS の設定、管理、そして障害の対処方法について説明します。
第 4 章 ネットワーク情報サービス (NIS) (概要)
この章では、ネットワーク情報サービス (NIS) の概要について説明します。
NIS とは分散型ネームサービスであり、ネットワーク上のオブジェクトおよびリソースを識別し、探索するメカニズムです。NIS は、ネットワーク全体の情報に関する一様な記憶領域と検索方法を、トランスポートプロトコルやメディアに依存しない形式で提供します。
この章の内容は次のとおりです。
NIS の概要
システム管理者は、NIS を実行することにより、「マップ」と呼ばれる管理データベースをさまざまなサーバー (「マスター」と「スレーブ」) に分散させることができます。さらに、これらの管理データベースを一元管理により自動的かつ確実な方法で更新できるため、どのクライアントもネットワーク全体を通して一貫した方法で同じネームサービス情報を共有できます。
NIS は DNS から独立して開発されたため、その焦点は少し異なっています。DNS は数値 IP アドレスの代わりにマシン名を使うことによって、通信を簡略化することに焦点を当てているのに対して、NIS の場合は、多様なネットワーク情報を集中管理することによりネットワーク管理機能を高めることに焦点を絞っています。NIS には、マシン名とアドレスだけでなく、ユーザー、ネットワークそのもの、ネットワークサービスについての情報も格納されます。このようなネットワーク「情報」の集まりを NIS の「名前空間」と呼びます。
注 –
「マシン」名の代わりに「ホスト」名が使われることがあります。この解説では「マシン」名が使われていますが、一部の画面メッセージまたは NIS マップ名では「ホスト」名または「マシン」名が使われています。
NIS アーキテクチャー
NIS はクライアントサーバー方式を使用します。NIS サーバーが NIS のクライアントへサービスを提供します。主サーバーは「マスター」サーバーと呼ばれ、信頼性を保証するためにバックアップつまり「スレーブ」サーバーを持っています。マスターサーバーとスレーブサーバーは、NIS の情報検索ソフトウェアを使い、NIS のマップを格納します。
NIS はドメインを使用して、マシン、ユーザー、およびネットワークをその名前空間に配置します。しかし、ドメイン階層を使用しないため、NIS の名前空間はフラットになっています。
したがって、上記のような物理ネットワークは、次のように 1 つの NIS ドメインに配置されます。
NIS だけを使っても、NIS ドメインをインターネットに直接接続することはできません。ただし、NIS を使用してインターネットへも接続したいと希望する組織では、NIS と DNS を組み合せることができます。その場合、NIS を使用してすべてのローカル情報を管理し、DNS を使用してインターネットのホストを検索できます。NIS は、NIS マップで情報が見つからない場合にホスト検索の機能を DNS へ転送する転送サービス機能を持っています。Solaris システムでは、ホスト検索要求を DNS だけに転送する、DNS で情報が見つからなければ次に NIS に転送する、あるいは NIS で情報が見つからなければ次に DNS に転送する、という切り替えも nsswitch.conf ファイルで設定できます。詳細については、第 2 章ネームサービススイッチ (概要)を参照してください。
NIS マシンのタイプ
NIS マシンには、次の 3 つのタイプがあります。
-
マスターサーバー
-
スレーブサーバー
-
NIS サーバーのクライアント
NIS クライアントにはどのマシンでもなれますが、NIS サーバー (マスターまたはスレーブ) となるのはディスクが装備されているマシンだけです。一般にサーバーは、多くの場合はそのサーバー自身のクライアントでもあります。
NIS サーバー
NIS サーバーは、FNS ファイルサーバーと同じマシンである必要はありません。
NIS サーバーには、マスターサーバーとスレーブサーバーの 2 つの種類があります。マスターサーバーとして指定されているマシンには、NIS 管理者が必要に応じて作成、更新する一群のマップが保存されます。各 NIS ドメインには、マスターサーバーが 1 つだけ存在している必要があります。マスターサーバーは、パフォーマンスの低下を最小限に抑えながら NIS の更新をスレーブサーバーに伝播できます。
ドメインに別の NIS サーバーをスレーブサーバーとして指定できます。各スレーブサーバーには、マスターサーバーの NIS マップセットの完全なコピーが存在します。マスターサーバーの NIS マップが更新されると、必ずこれらの更新がスレーブサーバーに伝播されます。スレーブサーバーは、マスターサーバーからの要求のオーバーフローに対処して、「サーバー使用不可」エラーを最小限に抑えることができます。
通常、システム管理者はすべての NIS マップに対してマスターサーバーを 1 つ指定します。ただし、各 NIS マップ内ではマスターサーバーのマシン名が符合化されているので、異なる複数のマップに対して異なる複数のサーバーを、マスターサーバーやスレーブサーバーとして動作するように指定することもできます。管理の複雑さを最小限に抑えるには、1 つのドメイン内で作成されるすべてのマップに対して、マスターサーバーを 1 つだけ指定します。この章の例では、1 つのサーバーがドメイン内のすべてのマップのマスターサーバーとなっています。
NIS クライアント
NIS クライアントでは、サーバー上のマップのデータを要求するプロセスが動作します。各 NIS サーバーに保存されている情報は同じであるはずなので、クライアントではマスターサーバーとスレーブサーバーの区別は行われません。
注 –
Solaris オペレーティングシステムは、NIS クライアントとネイティブな LDAP クライアントが同一のクライアントマシン上に共存する構成をサポートしません。
NIS の要素
NIS ネームサービスは、次の要素から構成されています。
-
ドメイン (「NIS ドメイン」を参照)
-
デーモン (「NIS デーモン」を参照)
-
ユーティリティー (「NIS ユーティリティー」を参照)
-
マップ (「NIS のマップ」を参照)
-
NIS コマンドセット (「NIS 関連コマンド」を参照)
NIS ドメイン
NIS「ドメイン」は、共通の NIS マップセットを共有しているマシンの集合です。各ドメインにはドメイン名が指定されており、共通の NIS マップセットを共有している各マシンがそのドメインに属しています。
どのマシンも指定されたドメインに属することができます。ただしこれは、そのドメインのマップに対するサーバーが同一ネットワーク上に存在する場合に限ります。NIS クライアントマシンは、ブートプロセス中にドメイン名を取得して、NIS サーバーにバインドします。
NIS デーモン
NIS サービスは、表 4–1 に示す 5 つのデーモンで提供されます。NIS サービスはサービス管理機能によって管理されます。このサービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できます。SMF の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。
表 4–1 NIS デーモン|
デーモン |
機能 |
|---|---|
|
サーバープロセス |
|
|
バインドプロセス |
|
|
高速マップ転送 |
|
|
NIS パスワード更新デーモン ** 下の注を参照 ** |
|
|
ほかのマップ (publickey など) を更新する |
注 –
rpc.yppasswdd は、r で始まるすべてのシェルを制限付きとみなします。たとえば、/bin/rksh で作業しているユーザーはそのシェルを別のシェルに変更できません。r で始まるシェルを持っているが、そのような制約を受けたくない場合は、第 7 章NIS のトラブルシューティングの対処方法を参照してください。
NIS ユーティリティー
NIS サービスは、表 4–2 に示す 9 つのユーティリティーでサポートされています。
表 4–2 NIS ユーティリティー|
ユーティリティー |
機能 |
|---|---|
|
NIS マップの dbm ファイルを作成します |
|
|
マップのデータを一覧表示します |
|
|
NIS データベースの作成、インストール、および NIS クライアントの ypservers リストの初期化を行います |
|
|
マップの特定エントリを検索します |
|
|
サーバーからマップ順序番号を取得します |
|
|
データを NIS マスターサーバーから NIS スレーブサーバーに伝播します |
|
|
特定サーバーにバインドを設定します |
|
|
NIS サーバー名およびニックネーム変換テーブルを表示します |
|
|
NIS マスターサーバーから NIS スレーブサーバーにデータを転送します |
NIS のマップ
NIS マップの情報は、ndbm フォーマットで保存されます。マップファイルのフォーマットについては、ypfiles(4) と ndbm(3C) のマニュアルページで説明しています。
NIS マップは、UNIX の /etc ファイルおよびほかの構成ファイルを置換するように設計されているので、名前およびアドレスよりはるかに多くの情報を保存できます。NIS が動作しているネットワーク上では、各 NIS ドメインの NIS マスターサーバーは、照会されるドメイン内のほかのマシンの NIS マップセットを保持します。NIS スレーブサーバーは、NIS マスターサーバーのマップのコピーを保持します。NIS クライアントマシンは、マスターサーバーまたはスレーブサーバーから名前空間情報を取得できます。
NIS マップは、本質的には 2 つの列からなるテーブルです。1 つの列は「キー」であり、もう 1 つの列はキーに関連する情報です。NIS は、キーを検索してクライアントに関する情報を見つけます。各マップでは異なるキーが使われるので、一部の情報はいくつかのマップに保存されます。たとえば、マシン名とアドレスは、 hosts.byname および hosts.byaddr という 2 つのマップに保存されます。サーバーがマシンの名前を持っており、そのマシンのアドレスを見つける必要がある場合は、サーバーは hosts.byname マップを調べます。サーバーがマシンのアドレスを持っており、そのマシンの名前を見つける必要がある場合は、サーバーは hosts.byaddr マップを調べます。
NIS Makefile は、インストール時に NIS サーバーとして指定されたマシンの /var/yp ディレクトリに保存されます。このディレクトリで make を実行すると、makedbm が入力ファイルからデフォルトの NIS マップを作成または更新します。
注 –
マップは必ずマスターサーバー上で作成してください。スレーブサーバーで作成したマップはマスターサーバーに自動的に格納されません。
デフォルトの NIS マップ
Solaris システムには、NIS マップのデフォルトセットが提供されています。システム管理者は、これらのマップをすべて使用することも一部だけを使用することもできます。また、ほかのソフトウェア製品のインストール時にシステム管理者が作成または追加したマップもすべて NIS で使用できます。
NIS ドメインのデフォルトのマップは、各サーバーの /var/yp/domainname ディレクトリに入っています。たとえば、test.com ドメインに属しているマップは、各サーバーの /var/yp/test.com ディレクトリにあります。
表 4–3 には、デフォルトの NIS マップ、これらの NIS マップに存在する情報、および NIS 動作時にソフトウェアが対応する管理ファイルを調べているか否かが示されています。
表 4–3 NIS マップに関する説明|
マップ名 |
対応する NIS 管理ファイル |
説明 |
|---|---|---|
|
audit_user |
audit_user |
ユーザー監査の事前選択データを含みます。 |
|
auth_attr |
auth_attr |
承認名と説明を含みます。 |
|
bootparams |
bootparams |
ブート時にクライアントが必要とするファイルのパス名 (ルート、スワップ、その他) を含みます。 |
|
ethers.byaddr |
ethers |
マシン名と Ethernet アドレスを含みます。Ethernet アドレスはマップ内のキーです。 |
|
ethers.byname |
ethers |
ethers.byaddr と同じです。ただしキーは、Ethernet アドレスではなくマシン名です。 |
|
exec_attr |
exec_attr |
プロファイルの実行属性を含みます。 |
|
group.bygid |
group |
グループセキュリティー情報を含みます。キーはグループ ID です。 |
|
group.byname |
group |
グループセキュリティー情報を含みます。キーはグループ名です。 |
|
hosts.byaddr |
hosts |
マシン名と IP アドレスを含みます。キーは IP アドレスです。 |
|
hosts.byname |
hosts |
マシン名と IP アドレスを含みます。キーはマシン (ホスト) 名です。 |
|
mail.aliases |
aliases |
エイリアスとメールアドレスを含みます。キーはエイリアスです。 |
|
mail.byaddr |
aliases |
メールアドレスとエイリアスを含みます。キーはメールアドレスです。 |
|
netgroup.byhost |
netgroup |
グループ名、ユーザー名、マシン名を含みます。キーはマシン名です。 |
|
netgroup.byuser |
netgroup |
netgroup.byhost と同じです。ただし、キーはユーザー名です。 |
|
netgroup |
netgroup |
netgroup.byhost と同じです。ただし、キーはグループ名です。 |
|
netid.byname |
passwd, hosts group |
UNIX スタイルの認証に使用されます。マシン名とメールアドレスを含みます (ドメイン名も含む)。netid ファイルがある場合には、ほかのファイルを使用して利用できるデータのほかにそれが参照されます。 |
|
netmasks.byaddr |
netmasks |
IP 送出時に使用するネットワークマスクを含みます。キーはアドレスです。 |
|
networks.byaddr |
networks |
システムに認識されているネットワーク名、および IP アドレスを含みます。キーは IP アドレスです。 |
|
networks.byname |
networks |
networks.byaddr と同じです。ただし、キーはネットワーク名です。 |
|
passwd.adjunct.byname |
passwd と shadow |
C2 クライアント用の監査情報と隠蔽されたパスワード情報を含みます。 |
|
passwd.byname |
passwd と shadow |
パスワード情報を含みます。キーはユーザー名です。 |
|
passwd.byuid |
passwd と shadow |
passwd.byname と同じです。ただし、キーはユーザー ID です。 |
|
prof_attr |
prof_attr |
実行プロファイルの属性を含みます。 |
|
protocols.byname |
protocols |
システムに認識されているネットワークプロトコルを含みます。 |
|
protocols.bynumber |
protocols |
protocols.byname と同じです。ただし、キーはプロトコル番号です。 |
|
rpc.bynumber |
rpc |
システムに認識されている RPC のプログラム番号と名前を含みます。キーは RPC のプログラム番号です。 |
|
services.byname |
services |
ネットワークに認識されているインターネットサービスを一覧表示します。キーはポートまたはプロトコルです。 |
|
services.byservice |
services |
ネットワークに認識されているインターネットサービスを一覧表示します。キーはサービス名です。 |
|
user_attr |
user_attr |
ユーザーと役割に関する拡張属性を含みます。 |
|
ypservers |
なし |
ネットワークに認識されている NIS サーバーを一覧表示します。 |
新しい ipnodes マップ (ipnodes.byaddr および ipnodes.byname) が、NIS に追加されました。このマップには、IPv4 アドレスと IPv6 アドレスの両方が格納されます。
注 –
Solaris 10 8/07 リリース以降、Solaris OS には 2 つの別個の hosts ファイルは存在しません。/etc/inet/hosts ファイルが唯一の hosts ファイルであり、この中に IPv4 と IPv6 の両方のエントリが含まれます。常に同期させる必要がある 2 つの hosts ファイル内の IPv4 エントリを維持管理する必要はありません。/etc/inet/ipnodes ファイルは、下位互換性のために、/etc/inet/hosts ファイルへの同名のシンボリックリンクに置き換えられています。
詳細は、hosts(4) のマニュアルページを参照してください。
NIS クライアントとサーバーは、IPv4 または IPv6 のどちらかの RPC トランスポートを使用して通信することができます。
ageing.byname マッピングには、yppasswdd によって使用される情報が含まれています。NIS から LDAP への移行時に、DIT とのパスワード有効期限情報の読み取りおよび書き込みのために使用されます。パスワードの有効期限を使用しない場合は、この情報をマッピングファイルからコメントアウトします。NIS から LDAP への移行の詳細については、第 15 章NIS から LDAP への移行 (概要と手順)を参照してください。
NIS マップの使用
NIS を使うと、/etc ファイルシステムを使った場合に比べ、ネットワークデータベースの更新がはるかに簡単になります。/etc ファイルシステムではネットワーク環境を更新するたびに各マシンの管理 /etc ファイルを変更する必要がありましたが、NIS ではこのような操作を行う必要はありません。
たとえば、NIS が動作しているネットワークに新しいマシンを追加する場合に必要なのは、マスターサーバーの入力ファイルを更新し、make を実行することだけです。これで、hosts.byname および hosts.byaddr マップが自動的に更新されます。次に、これらのマップはすべてのスレーブサーバーに転送され、ドメインのすべてのクライアントマシン、およびこれらのクライアントマシンのプログラムはこれらのマップを使用することが可能になります。クライアントマシンまたはアプリケーションがマシン名またはアドレスを要求すると、NIS サーバーは必要に応じて hosts.byname または hosts.byaddr マップを参照し、要求された情報をクライアントに送信します。
ypcat コマンドを使うと、マップの値を表示できます。ypcat の基本的な使用形式は、次のとおりです。
% ypcat mapname |
mapname は、調べたいマップ名またはその「ニックネーム」です。ypservers の場合のようにマップがキーだけで構成されている場合は、ypcat -k と入力してください。ypcat -k と入力しない場合は、空白行が出力されます。ypcat のほかのオプションについては、ypcat(1) のマニュアルページに説明されています。
ypwhich コマンドを使うと、どのサーバーが特定のマップのマスターサーバーなのかを判定できます。次のように入力します。
% ypwhich -m mapname |
mapname は、検索するマスターサーバーのマップ名またはニックネームです。mapname を入力すると、マスターサーバー名が表示されます。詳細については、ypwhich(1) のマニュアルページを参照してください。
NIS マップのニックネーム
「ニックネーム」は、マップのフルネームのエイリアスです。使用可能なマップのニックネーム (たとえば、passwd.byname の場合は passwd) を一覧表示するには、ypcat -x または ypwhich -x と入力してください。
ニックネームは、/var/yp/nicknames ファイルに保存されています。このファイルには、マップの完全指定名のあとに、マップのニックネームが空白で区切られて含まれています。ニックネームのリストは、追加または更新できます。ニックネーム数は現在、500 に制限されています。
NIS 関連コマンド
NIS サービスには、特殊なデーモン、システムプログラム、コマンドが含まれています。これらのコマンドについては次の表にまとめてあります。
表 4–4 NIS コマンドについてのまとめ|
コマンド |
説明 |
|---|---|
|
NIS クライアントが要求する NIS マップの情報を提供します。ypserv は、完全なマップセットを備えた NIS サーバー上で動作するデーモンです。NIS サービスが機能するには、少なくとも 1 つの ypserv デーモンがネットワークに存在する必要があります。 |
|
|
クライアントに NIS サーバーバインド情報を提供します。ypbind は、要求元クライアントのドメイン内のマップにサービスを提供する ypserv プロセスを見つけてバインドを行います。ypbind はすべてのサーバーとクライアント上で実行される必要があります。 |
|
|
自動的に入力ファイルから NIS サーバーのマップを作成します。ypinit はまた、クライアント上に /var/yp/binding/ domain/ypservers 初期ファイルを作成する際にも使用されます。NIS マスターサーバーおよび NIS スレーブサーバーを初めて設定する場合は、ypinit を使用します。 |
|
|
Makefile を読み込むことで NIS マップを更新します (make を /var/yp ディレクトリで実行した場合)。make を使うと、入力ファイルに基づいてすべてのマップを更新したり、個々のマップを更新したりできます。NIS の make の機能については、ypmake(1M) のマニュアルページに説明されています。 |
|
|
makedbm は入力ファイルを取得し、これを dbm.dir および dbm.pag ファイルに変換します (これらのファイルは、NIS がマップとして使用できる有効な dbm ファイル)。また、makedbm -u と入力すると、マップを分解できるため、システム管理者はマップを構成するキーと値のペアを参照できます。 |
|
|
NIS 自体を転送媒体として使い、NIS マップを遠隔サーバーから /var/yp/domain ローカルディレクトリに取り込みます。システム管理者は ypxfr を対話形式で実行したり、crontab ファイルから定期的に実行したりできます。また、ypxfr が ypserv によって呼び出されると、転送が開始されます。 |
|
|
ypxfr 要求 (一般にスレーブサーバーで発生する) に対してマップ転送サービスを提供します。ypxfr は、マスターサーバー上でだけ動作します。 |
|
|
NIS マップの新バージョンを NIS マスターサーバーからそのスレーブサーバーにコピーします。yppush の実行は、NIS マスターサーバー上で行います。 |
|
|
指定された NIS サーバーにバインドするように ypbind プロセスに要求します。ypset は、セキュリティーの関係上、通常のオペレーションで気軽に使用できるようには設計されていません。したがって、ypset はできる限り使用しないでください。ypbind プロセスの ypset および ypsetme オプションについては、ypset(1M) と ypbind(1M) のマニュアルページを参照してください。 |
|
|
yppoll |
指定されたサーバー上で NIS マップのどのバージョンが動作しているかを通知します。yppoll はまた、NIS マップのマスターサーバーを一覧表示します。 |
|
NIS マップの内容を表示します。 |
|
|
NIS マップ内の指定された 1 つ以上のキーの値を出力します。システム管理者は、NIS サーバーマップのバージョンを指定することはできません。 |
|
|
クライアントが現在どの NIS サーバーを使用して NIS サービスを取得しているかを表示します。また、-m mapname オプションを指定してこのコマンドを起動した場合は、どの NIS サーバーが各マップのマスターサーバーであるかが表示されます。-m だけを指定した場合は、使用可能なすべてのマップ名、およびこれらのマップのマスターサーバーが表示されます。 |
NIS のバインド
NIS クライアントは、バインドプロセスにより NIS サーバーから情報を取得します。バインドプロセスは、サーバーリストおよび同報通信という 2 つのモードのどちらかで動作できます。
-
サーバーリスト。サーバーリストモードでは ypbind プロセスは、/var/yp/binding/domain/ypservers リストでドメイン内のすべての NIS サーバー名を調べます。ypbindプロセスは、このファイルに存在するサーバーにだけバインドされます。このファイルは、ypinit -c を実行すると作成されます。
-
同報通信。ypbind プロセスはまた、RPC 同報通信を使ってバインドを開始できます。同報通信は、それ以上配信されない唯一のローカルサブネットイベントです。したがって、クライアントと同じサブネット上に少なくとも 1 つのサーバー (マスターまたはスレーブ) が存在しなければなりません。サーバーは、異なる複数のサブネット上に存在できます (マップはサブネット境界を超えて伝播されるため) 。サブネット環境での 1 つの一般的方法は、NIS サーバーとしてサブネットルーターを使用することです。この方法を使用すると、ドメインサーバーはどちらかのサブネットインタフェース上でクライアントにサービスを提供できます。
サーバーリストモード
サーバーリストモードでは、バインドプロセスは次のように動作します。
-
NIS マップで提供された情報を必要とする、NIS クライアントマシン上で動作しているプログラムが、ypbind にサーバー名を要求します。
-
ypbind が、/var/yp/binding/domainname/ypservers ファイルを調べてドメインの NIS サーバーリストを見つけます。
-
ypbind が、NIS サーバーリストの先頭サーバーへのバインドを開始します。先頭サーバーが応答しない場合、ypbind はサーバーが見つかるまで、あるいは NIS サーバーリストの最後に達するまで、2 番目以降のサーバーへのバインドを順に試みます。
-
ypbind が、どのサーバーにアクセスすべきかをクライアントプロセスに通知します。次に、クライアントプロセスが直接、サーバーに要求を送信します。
-
ypserv デーモンが、要求された情報をクライアントに送り返します。
同報通信モード
同報通信モードでは、バインドプロセスは次のように動作します。
-
ypbind が、RPC 同報通信を送出して NIS サーバーを探索します。
注 –このようなクライアントをサポートするには、NIS サービスを要求している各サブネット上に 1 つの NIS サーバーが存在する必要があります。
-
ypbind が、同報通信に応答する先頭サーバーへのバインドを開始します。
-
ypbind が、どのサーバーにアクセスすべきかをクライアントプロセスに通知します。次に、クライアントプロセスが直接、サーバーに要求を送信します。
-
ypserv デーモンが、要求された情報をクライアントに送り返します。
通常、いったんクライアントがサーバーにバインドされると、何らかの原因でバインドが解除されるまではクライアントはサーバーにバインドされたままになります。たとえば、サーバーがサービスを提供できなくなると、このサーバーがサービスを提供していたクライアントは、新しいサーバーにバインドされます。
どの NIS サーバーが現在、特定クライアントにサービスを提供しているかを調べる場合は、次のコマンドを入力してください。
%ypwhich machinename
machinename は、クライアント名です。マシン名が指定されていない場合は、ypwhich はデフォルトとしてローカルマシン (コマンドが実行されるマシン) を使用します。
第 5 章 NIS サービスの設定と構成
この章では、ネットワーク情報サービス (NIS) の初期設定と構成について説明します。
注 –
「マシン」名の代わりに「ホスト」名が使われることがあります。この解説では「マシン」名が使われていますが、一部の画面メッセージまたは NIS マップ名では「ホスト」名または「マシン」名が使われています。
この章の内容は次のとおりです。
NIS の構成 — 作業マップ
|
作業 |
参照先 |
|---|---|
|
変換用のソースファイルを準備します。 | |
|
ypinit を使用してマスターサーバーを設定します | |
|
マスターサーバーで NIS を起動します。 | |
|
スレーブサーバーを設定します。 | |
|
NIS クライアントを設定します。 |
NIS の構成を始める前に
NIS の名前空間を構成する前に、次の操作を行う必要があります。
-
NIS を使用する予定のすべてのマシンで、正しく構成された nsswitch.conf ファイルをインストールする。詳細については、第 2 章ネームサービススイッチ (概要)を参照してください。
-
NIS ドメインを設計する。
NIS とサービス管理機能
NIS サービスはサービス管理機能によって管理されます。SMF の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。
-
このサービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できます。NIS を開始または停止するには、コマンド行から ypstart および ypstop も使用できます。詳細については、ypstart(1M) および ypstop(1M) のマニュアルページを参照してください。
ヒント –-t オプションを使用してサービスを一時的に無効化すると、そのサービス構成に対していくらかの保護を提供できます。-t オプションを指定してサービスを無効にした場合、リブート後に元の設定が復元されます。-t オプションを指定しないでサービスを無効にした場合、リブート後もそのサービスは無効のままです。
-
NIS の障害管理リソース識別子 (FMRI) は、NIS サーバーに対しては svc:/network/nis/server:<instance>、NIS クライアントに対しては svc:/network/nis/client:<instance> です。
-
svcs コマンドを使用して NIS の状態を照会できます。
-
svcs コマンドと出力の例を、次に示します。
# svcs network/nis/server STATE STIME FMRI online Jan_10 svc:/network/nis/server:default
# svcs \*nis\* STATE STIME FMRI disabled 12:39:18 svc:/network/rpc/nisplus:default disabled 12:39:18 svc:/network/nis/server:default disabled 12:39:20 svc:/network/nis/passwd:default disabled 12:39:20 svc:/network/nis/update:default disabled 12:39:20 svc:/network/nis/xfr:default online 12:42:16 svc:/network/nis/client:default
-
svcs -l コマンドと出力の例を、次に示します。
# svcs -l /network/nis/client fmri svc:/network/nis/client:default enabled true state online next_state none restarter svc:/system/svc/restarter:default contract_id 99 dependency exclude_all/none svc:/network/nis/server (offline) dependency require_all/none svc:/system/identity:domain (online) dependency require_all/restart svc:/network/rpc/bind (online) dependency require_all/none svc:/system/filesystem/minimal (online)
-
サービスに関してより詳細な情報を得るには、svccfg ユーティリティーを使用します。svccfg(1M) のマニュアルページを参照してください。
-
デーモンの存在は ps コマンドを使用して確認できます。
# ps -e | grep rpcbind daemon 100806 1 0 Sep 01 ? 25:28 /usr/sbin/rpcbind
注 –-f オプションを ps で使用しないでください。このオプションはユーザー ID を名前に変換しようとするため、より多くのネームサービス検索が失敗する可能性があります。
-
NIS ドメインの設計
NIS サーバーまたはクライアントとしてマシンを構成する前に、NIS ドメインを設計する必要があります。
まず、NIS ドメインに入れるマシンを決めます。NIS ドメインは、ネットワークと同一である必要はありません。ネットワークには複数の NIS ドメインが存在でき、NIS ドメインに属さないマシンもネットワーク上に存在できます。
NIS ドメイン名を選択します。NIS ドメイン名には、最高 256 文字を指定できます。ドメイン名が 32 文字を超えないように制限するとよいでしょう。ドメイン名は大文字と小文字を区別します。便宜上、インターネットのドメイン名に基づいて NIS ドメイン名を指定することもできます。たとえば、インターネットのドメイン名が doc.com の場合、NIS ドメインも doc.com にすることができます。doc.com を 2 つの NIS ドメインに分けて、1 つを営業部門に、もう 1 つを製造部門に使用する場合は、一方を sales.doc.com とし、もう一方を manf.doc.com とできます。
NIS ドメイン名とマシン名を正しく設定しないと、マシンが NIS サービスを使用できるようになりません。マシン名はマシンの /etc/nodename ファイルによって設定され、マシンのドメイン名はマシンの /etc/defaultdomain ファイルによって設定されます。これらのファイルはブート時に読み取られ、その内容はそれぞれ uname -S コマンドと domainname コマンドによって使用されます。ディスクレスマシンは、そのブートサーバーからこれらのファイルを読み取ります。
NIS サーバーとクライアントを特定する
マスターサーバーになるマシンを 1 つ選択します。スレーブサーバーを作成する場合は、スレーブサーバー用のマシンを決定します。
NIS クライアントになるマシンを決定します。通常は、ドメイン内のすべてのマシンが NIS クライアントになるように設定されますが、これは必須ではありません。
マスターサーバーの準備
以降の節では、マスターサーバーのソースファイルと passwd ファイルを準備する方法を説明します。
ソースファイルディレクトリ
ソースファイルは、マスターサーバーの /etc ディレクトリか、その他のディレクトリにあります。ソースファイルを /etc に入れることは望ましくありません。マップの内容がマスターサーバー上のローカルファイルの内容と同じになるからです。これは passwd ファイルと shadow ファイルに固有の問題です。ユーザー全員がマスターサーバーのマップにアクセスし、passwd マップを通じてすべての NIS クライアントに root パスワードが渡されるためです。詳細については、「passwd ファイルと名前空間のセキュリティー」を参照してください。
ただし、ソースファイルをほかのディレクトリに入れた場合は、/var/yp 内の Makefile の DIR=/etc 行を DIR=/your-choice に変更する必要があります。your-choice はソースファイルを格納するためのディレクトリの名前です。これによって、サーバー上のローカルファイルをクライアント上のファイルのように扱うことができます。編集前の Makefile のコピーを保存しておくことをお勧めします。
また、audit_user、auth_attr、exec_attr、prof_attr がデフォルト以外のディレクトリから取り出される場合は、RBACDIR=/etc/security を RBACDIR=/your-choice に変更します。
passwd ファイルと名前空間のセキュリティー
passwd マップは特殊なケースです。この NIS 実装では、NIS パスワードマップを作成するための入力として、Solaris 1 の passwd ファイルのフォーマットに加え、/etc/passwd ファイルと /etc/shadow ファイルのフォーマットも使用できます。
セキュリティー上の理由から未承認の root アクセスを防ぐために、NIS のパスワードマップの構築に使用されるファイルには root のエントリを含めないでください。このため、パスワードマップはマスターサーバーの /etc ディレクトリに置かれたファイルから構築しないでください。パスワードマップの構築に使用されるパスワードファイルは、root エントリが削除された上、未承認のアクセスから保護されるディレクトリに置かれている必要があります。
たとえば、マスターサーバーのパスワード入力ファイルは、ファイル自体が別のファイルへのリンクではなく、ファイルの場所が Makefile に指定されている限り、/var/yp/ などのディレクトリに格納されているか、選択したディレクトリに格納されている必要があります。Makefile に指定された構成に従って、適正なディレクトリオプションが自動的に設定されます。
注意 –
PWDDIR によってディレクトリ内に指定された passwd ファイルに root のエントリが含まれないようにしてください。
ソースファイルが /etc 以外のディレクトリにある場合は、Makefile の PWDIR パスワードマクロが、passwd ファイルと shadow ファイルが入っているディレクトリを参照するように変更します。この操作を行うには、PWDIR=/etc 行を PWDIR=/your-choice に変更します。your-choice は、passwd マップソースファイルを格納するのに使用するディレクトリの名前です。
NIS マップへの変換用のソースファイルを準備する
NIS マップへの変換用のソースファイルを準備します。
変換用のソースファイルを準備する方法
-
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
マスターサーバーのソースファイルをチェックして、それらのファイルがシステムの最新の状態を反映しているかどうか確認します。
次のファイルを確認します。
-
auto.home または auto_home
-
auto.master または auto_master
-
audit_user
-
auth_attr
-
bootparams
-
ethers
-
exec_attr
-
group
-
hosts
-
ipnodes
-
netgroup
-
netmasks
-
networks
-
passwd
-
protocols
-
rpc
-
サービス
-
shadow
-
user_attr
-
-
passwd ファイルを、選択した PWDIR ディレクトリにコピーします。
-
audit_user、auth_attr、exec_attr、prof_attr を、選択した RBACDIR ディレクトリにコピーします。
-
ほかのソースファイルと異なり、/etc/mail/aliases ファイルは別のディレクトリに移動できません。このファイルは /etc/mail ディレクトリに格納されていなければなりません。詳細については、aliases(4) のマニュアルページを参照してください。
注 –/var/yp/Makefile 内の ALIASES = /etc/mail/aliases エントリを変更して別の場所を指すようにすることで、NIS 固有のメールエイリアスファイルを追加することができます。make を実行すると、ALIASES エントリによって mail.aliases マップが作成されます。/etc/nsswitch.conf ファイルで files のほかに nis が適切に指定されている場合、sendmail サービスは /etc/mail/aliases ファイルに加えてこのマップを使用します。「Makefile の更新と使用」を参照してください。
-
ソースファイルからすべてのコメントと、その他の余計な行や情報を取り除きます。
これらの操作は、sed または awk の各スクリプトで、またはテキストエディタを使用して実行できます。Makefile はソースファイルから不要なエントリをある程度自動的に削除しますが、これらのファイルを手動で検証し、クリーンアップしてから実行することをお勧めします。
-
すべてのソースファイルのデータが正しい形式になっていることを確認します。
ソースファイルのデータは、それぞれのファイルに適した形式で格納されている必要があります。該当するマニュアルページを参照して、各ファイルが正しい形式になっていることを確認します。
Makefile を準備する
ソースファイルをチェックしてソースファイルディレクトリにコピーしたら、NIS サービスが使用する ndbm 形式のマップにそのソースファイルを変換する必要があります。「ypinit によるマスターサーバーの設定」の節で説明しているように、この処理は、マスターサーバーで呼び出されると ypinit によって自動的に行われます。
ypinit スクリプトはプログラム make を呼び出します。このプログラムは、/var/yp ディレクトリに置かれた Makefile を使用します。/var/yp ディレクトリにはデフォルトの Makefile が用意されており、この中には要求された ndbm 形式のマップにソースファイルを変換するためのコマンドが入っています。
デフォルトの Makefile は、そのまま使用することも必要に応じて修正することもできます。(デフォルトの Makefile を修正するときは、将来必要な場合に備えて、必ず最初に修正前の Makefile をコピーして保存するようにしてください。)次に説明する Makefile への修正のうち、必要に応じて 1 つまたは複数を実行します。
-
「デフォルトではないマップ」
デフォルトではない自分専用のソースファイルを作成して NIS マップに変換する場合は、そのソースファイルを Makefile に追加する必要があります。
-
「
DIRの値」「ソースファイルディレクトリ」で説明しているように、/etc 以外のディレクトリに格納されたソースファイルを Makefile で使用する場合は、Makefile の
DIRの値を、使用するディレクトリに変更してください。この値を Makefile で変更するときは行をインデントしないでください。 -
「
PWDIRの値」/etc 以外のディレクトリに格納された passwd、shadow、adjunct の各ソースファイルを Makefile で使用する場合は、Makefile の
PWDIRの値を、使用するディレクトリに変更します。この値を Makefile で変更するときは行をインデントしないでください。 -
「ドメインネームリゾルバ」
現在のドメインにはないマシンに対して NIS サーバーがドメインネームリゾルバを使用するようにする場合は、Makefile の B= 行をコメントアウトし、B=-b 行のコメントを解除します (有効にする)。
Makefile の機能は、all の下にリストされるデータベースのそれぞれに対して適切な NIS マップを作成することです。データは makedbm で処理され、mapname.dir と mapname.pag の 2 つのファイルに保存されます。この両ファイルは、マスターサーバーの /var/yp/domainname ディレクトリに置かれます。
Makefile は必要に応じて、/PWDIR/passwd、/PWDIR/shadow、/PWDIR/security/passwd.adjunct の各ファイルから passwd マップを構築します。
ypinit によるマスターサーバーの設定
ypinit スクリプトは、マスターサーバー、スレーブサーバー、クライアントが NIS を使用するように設定します。また最初に make を実行して、マスターサーバー上にマップを作成します。
ypinit を使用して新規に NIS マップセットをマスターサーバーに作成する場合は、次の手順に従います。
ypinit を使用してマスターサーバーを設定する方法
-
マスターサーバーで、スーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
nsswitch.files ファイルの内容を nsswitch.conf ファイルにコピーします。
# cp /etc/nsswitch.files /etc/nsswitch.conf
-
/etc/hosts ファイルまたは /etc/inet/ipnodes ファイルを編集して、NIS サーバーのそれぞれの名前と IP アドレスを追加します。
-
新しいマップをマスターサーバーに作成します。
# /usr/sbin/ypinit -m
-
ypinit によって NIS スレーブサーバーになるほかのマシンのリストを求めるプロンプトが表示されたら、作業中のサーバー名と NIS スレーブサーバー名を入力します。
-
致命的でないエラーが発生したときにすぐに処理を終了するか、引き続き処理を継続するかを ypinit が尋ねてきたら、y と入力します。
y を選択すると、ypinit は最初の問題が発生すると終了します。問題を解決して ypinit を再起動します。ypinit を初めて実行する場合はこの手順に従うようにしてください。処理を継続する場合は、発生する問題をすべて手動で解決してから ypinit を再起動します。
注 –マップファイルの一部が存在しないと、致命的でないエラーが発生することがあります。これは NIS の機能に影響するエラーではありません。マップが自動的に作成されない場合は、必要に応じて手動で追加します。すべてのデフォルトの NIS マップの詳細については、「デフォルトの NIS マップ」を参照してください。
-
/var/yp/domainname ディレクトリ内の既存のファイルを破棄してもよいかどうか ypinit が尋ねてきます。
このメッセージは、NIS が以前に設定されている場合にだけ表示されます。
-
ypinit は、サーバーのリストを作成し終わると make を起動します。
このプログラムは、 /var/yp に置かれた Makefile (デフォルトまたは修正されたもの) に含まれている命令を使用します。make コマンドは、指定したファイルにコメント行があればその行を取り除きます。また、指定したファイルに対して makedbm を実行して適切なマップを作成し、各マップにマスターサーバー名を設定します。
マスターサーバー上で domainname コマンドを実行すると返されるドメイン以外に対するマップの転送を Makefile で行う場合は、ypinit シェルスクリプトの中で make コマンドの変数 DOM に適切なドメイン名を指定して起動すれば、マップを正しいドメインに転送することができます。次のように入力してください。
# make DOM=domainname password
このコマンドによって、マスターサーバーが属するドメインではなく目的のドメインに password マップが転送されます。
-
次のように入力してネームサービスとして NIS を有効にします。
# cp /etc/nsswitch.nis /etc/nsswitch.conf
現在のスイッチファイルが、デフォルトの NIS 用スイッチファイルに置き換えられます。このファイルは必要に応じて編集可能です。
複数の NIS ドメインをサポートするマスターサーバー
NIS マスターサーバーは通常、NIS ドメインだけをサポートします。ただし、マスターサーバーを使用して複数のドメインをサポートする場合は、「ypinit によるマスターサーバーの設定」で説明したように、追加のドメイン用にサーバーを設定するときに手順を若干修正する必要があります。
サーバー上で domainname コマンドを実行します。このコマンドによって返されるドメイン名はサーバーのデフォルトドメインです。「ypinit によるマスターサーバーの設定」で説明した手順は、そのドメインへのサービスの設定では正しく機能します。ほかのドメインへのサービスを設定する場合は、ypinit シェルスクリプトを次のように修正する必要があります。
# make DOM=correct-domain passwd |
correct-domain はサービスを設定しているほかのドメインの名前であり、passwd は make のターゲットです。このコマンドによって、マスターサーバーが属するドメインではなく目的のドメインに passwd マップが転送されます。
マスターサーバーでの NIS サービスの開始と停止
マスターサーバーのマップが作成されると、NIS デーモンをマスターサーバーで起動してサービスを開始できます。NIS サービスを有効にすると、ypserv と ypbind がサーバー上で起動されます。クライアントがサーバーの情報を要求すると、ypserv デーモンは NIS マップ内で検索してクライアントからの情報の要求に応答します。ypserv デーモンと ypbind デーモンは 1 単位として管理されます。
サーバー上で NIS サービスを開始または停止するには、次の 3 つの方法があります。
-
ブートプロセス中に /usr/lib/netsvc/yp/ypstart スクリプトを自動的に起動する
-
コマンド行からサービス管理機能の svcadm enable <fmri> コマンドおよび svcadm disable <fmri> コマンドを使用する
SMF の詳細については、svcadm(1M) を参照してください。
-
コマンド行から ypstart(1M) コマンドおよび ypstop(1M) コマンドを使用する
NIS サービスを自動的に開始する
ypinit を実行して NIS マスターサーバーを構成し終わると、マシンのブート時に ypstart が自動的に起動され、 ypserv が開始されます。「ypinit によるマスターサーバーの設定」を参照してください。
コマンド行から NIS を開始または停止する
サービス管理機能の svcadm コマンド、または ypstart/ypstop コマンドを使用して、コマンド行から NIS を開始および停止します。svcadm コマンドを使用する場合、サービスのインスタンスを複数実行しているときにのみインスタンス名が必要です。詳細については、「NIS とサービス管理機能」、または svcadm(1M)、ypstart(1M)、および ypstop(1M) のマニュアルページを参照してください。
コマンド行から NIS を開始するには、svcadm enable コマンドまたは ypstart コマンドを使用します。
# svcadm enable network/nis/server:<instance> # svcadm enable network/nis/client:<instance> or # ypstart |
注 –
起動後に ypserv が呼び出しに応答できるようになるまでに若干の遅延があるので、プログラムまたはスクリプトの内部から呼び出す場合は、svcadm の実行後に 3 - 5 秒間スリープ状態にしてください。
NIS サービスを停止するには、svcadm disable コマンドまたは ypstop コマンドを実行します。
# svcadm disable network/nis/server:<instance> # svcadm disable network/nis/client:<instance> or # ypstop |
NIS サービスを停止してすぐに再起動するには、svcadm restart コマンドを使用します。
# svcadm restart network/nis/server:<instance> # svcadm restart network/nis/client:<instance> |
NIS スレーブサーバーの設定
ネットワークは 1 つ以上のスレーブサーバーを持つことができます。スレーブサーバーを持つことで、マスターサーバーが利用できない場合にも NIS サービスを継続して利用できます。
スレーブサーバーを準備する
ypinit を実際に実行してスレーブサーバーを作成する前に、domainname コマンドを NIS スレーブサーバーごとに実行してドメイン名がマスターサーバーと一致していることを確認するようにしてください。
注 –
ドメイン名は大文字と小文字を区別します。
ネットワークが正しく機能していることを確認してから、NIS スレーブサーバーを構成してください。特に、rcp を使用して NIS マスターサーバーから NIS スレーブサーバーにファイルを送れるかどうかを確認してください。
スレーブサーバーを設定する
次の手順はスレーブサーバーの設定方法を示しています。
スレーブサーバーを設定する方法
-
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
スレーブサーバー上で /etc/hosts ファイルまたは /etc/inet/ipnodes ファイルを編集して、ほかのすべての NIS サーバー名と IP アドレスを追加します。
-
スレーブサーバー上の /var/yp にディレクトリを変更します。
注 –まず、新しいスレーブサーバーを NIS クライアントとして構成して、最初にマスターサーバーから NIS マップを入手できるようにします。詳細については、「NIS クライアントの設定」を参照してください。
-
スレーブサーバーをクライアントとして初期化します。
# /usr/sbin/ypinit -c
ypinit コマンドによって、NIS サーバーのリストを求めるプロンプトが表示されます。作業中のローカルマシン (スレーブ) の名前を最初に入力してからマスターサーバーを入力し、そのあとにドメイン内のほかの NIS スレーブサーバーをネットワーク的に近いものから遠いものの順番で入力します。
-
NIS クライアントが実行されているかどうかを確認し、必要に応じてクライアントサービスを開始します。
# svcs network/nis/client STATE STIME FMRI online 20:32:56 svc:/network/nis/client:default
svc:/network/nis/client の状態が online と表示される場合、NIS は実行されています。サービスの状態が無効となっている場合、NIS は実行されていません。
-
このマシンをスレーブサーバーとして初期設定します。
# /usr/sbin/ypinit -s master
master は、既存の NIS マスターサーバーのマシン名です。
この節で説明した手順を、NIS スレーブサーバーとして構成するマシンごとに繰り返します。
スレーブサーバーで NIS を開始する方法
次の手順は、スレーブサーバーで NIS サービスを開始する方法を示しています。
-
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
NIS クライアントの設定
ネームサービスとして NIS を使用するようにクライアントマシンを設定するには、次の 2 つの方法があります。
注 –
Solaris オペレーティングシステムは、NIS クライアントとネイティブな LDAP クライアントが同一のクライアントマシン上に共存する構成をサポートしません。
-
「ypinit」。NIS を使用するようにクライアントマシンを設定する場合は、マシンに root としてログインして ypinit -c を実行する方法をお勧めします。
# ypinit -c
NIS サーバーを指定するように求められます。クライアントは NIS サーバーからネームサービス情報を得ます。必要な数だけマスターサーバーやスレーブサーバーを指定できます。指定するサーバーはドメイン内のどこにあってもかまいません。クライアントにネットワーク的に近いサーバーから遠いサーバーの順に指定することをお勧めします。
-
「ブロードキャスト方式」。NIS を使用するようにクライアントマシンを設定する旧式の方法です。マシンに root としてログインし、domainname コマンドでドメイン名を設定してから、ypbind を実行します。
/var/yp/binding/`domainname`/ypservers ファイルが存在しない場合、ypstart は NIS クライアントをブロードキャストモードで自動的に起動します (ypbind -broadcast)。
# domainname doc.com # mv /var/yp/binding/`domainname`/ypservers /var/yp/binding/`domainname`\ /ypservers.bak # ypstart
ypbind を実行すると、NIS サーバーがローカルサブネットで検索されます。NIS サーバーが見つかると、ypbind はそのサーバーにバインドします。この検索を「ブロードキャスト」と呼びます。クライアントのローカルサブネットに NIS サーバーがない場合、ypbind によるバインドは失敗し、クライアントマシンは NIS サービスから名前空間データを入手することができません。
注 –
セキュリティーと管理の意味から、クライアントにブロードキャストを使ってサーバーを検索させるのではなく、クライアントの ypservers ファイルでクライアントのバインド先のサーバーを指定してください。ブロードキャストは、ネットワークの速度を落とし、クライアントの速度も落とします。また、異なるクライアントに対して異なるサーバーをリストするため、サーバー負荷の均衡がとれなくなります。
第 6 章 NIS の管理 (手順)
この章では、NIS の管理方法について説明します。この章の内容は次のとおりです。
注 –
NIS サービスはサービス管理機能によって管理されます。このサービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できます。NIS で SMF を使用する場合の詳細については、「NIS とサービス管理機能」を参照してください。SMF の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。
NIS サービスの開始および停止は、ypstart および ypstop コマンドを使用しても行えます。詳細については、ypstart(1M) および ypstop(1M) のマニュアルページを参照してください。
パスワードファイルと名前空間のセキュリティー
セキュリティーの関係上、次のガイドラインに従ってください。
-
マスターサーバーの NIS マップへのアクセスは制限します。
-
未許可アクセスを防止するためには、NIS パスワードマップの作成に使用されたファイルに root エントリを含めないでください。したがって、root エントリをこのパスワードファイルから削除して、このパスワードファイルをマスターサーバーの /etc ディレクトリ以外のディレクトリにおく必要があります。このディレクトリへの未許可アクセスは、防止しなければなりません。
たとえば、マスターサーバーのパスワード入力ファイルは、別のファイルへのリンクではなく Makefile に指定されている限り、/var/yp などのディレクトリに存在するか選択されたディレクトリに存在します。サービス管理機能または ypstart スクリプトを使用して NIS サービスを開始する場合、Makefile に指定された構成に従って適切なディレクトリオプションが設定されます。
注 –
この NIS 実装では、NIS パスワードマップを作成するための入力として、旧 Solaris 1 バージョンの passwd ファイルのフォーマットに加え、Solaris 2 の passwd ファイルと shadow ファイルのフォーマットも使用できます。
NIS ユーザーの管理
この節では、ユーザーパスワードの設定、NIS ドメインへの新しいユーザーの追加、ネットグループ (netgroups) へのユーザーの割り当てについて説明します。
NIS ドメインに新しい NIS ユーザーを追加する方法
-
マスター NIS サーバーで、スーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
useradd コマンドで新しいユーザーのログイン ID を作成します。
# useradd userID
userID は新しいユーザーのログイン ID です。このコマンドは、NIS マスターサーバー上の /etc/passwd ファイルと /etc/shadow ファイルにエントリを作成します。
-
新しいユーザーの初期パスワードを作成します。
新しいユーザーがログインするための初期パスワードを作成するには、passwd コマンドを実行します。
# passwd userID
userID は新しいユーザーのログイン ID です。このユーザーに割り当てるパスワードを入力するようにプロンプトが表示されます。
この手順が必要になるのは、 useradd コマンドで作成されたパスワードエントリがロックされ、新しいユーザーがログインできないからです。初期パスワードを指定することで、このパスワードエントリのロックが解除されます。
-
必要に応じて、マスターサーバーの passwd マップ入力ファイルに新しいエントリをコピーします。
マスターサーバー上のマップソースファイルは、/etc 以外のディレクトリにあります。新しい行を /etc/passwd ファイルと /etc/shadow ファイルからマスターサーバー上の passwd マップ入力ファイルにコピーします。詳細については、「パスワードファイルと名前空間のセキュリティー」を参照してください。
たとえば、新しいユーザー brown を追加する場合、/etc/passwd ファイルから passwd 入力ファイルにコピーする行は次のようになります。
brown:x:123:10:User brown:/home/brown:/bin/csh:
/etc/shadow からコピーされる brown 行は次のようになります。
brown:W12345GkHic:6445::::::
-
パスワード入力ファイルが格納されているディレクトリが Makefile で正しく指定されていることを確認します。
-
必要に応じて、/etc/passwd ファイルと /etc/shadow ファイルから新しいユーザーのエントリを削除します。
セキュリティー上の理由から、NIS マスターサーバーの /etc/passwd ファイルと /etc/shadow ファイルにユーザーエントリを保持しないようにしてください。ほかのディレクトリに存在する NIS マップソースファイルに新しいユーザーのエントリをコピーしたあと、マスターサーバー上で userdel コマンドを使用して新しいユーザーを削除します。
たとえば、マスターサーバーの /etc ファイルから新しいユーザー brown を削除するには次のように入力します。
# userdel brown
-
マスターサーバー上の passwd 入力ファイルを更新したあと、ソースファイルが存在するディレクトリで make を実行して、passwd マップを更新します。
# userdel brown # cd /var/yp # /usr/ccs/bin/make passwd
-
新しいユーザーのログイン ID に割り当てられた初期パスワードを新しいユーザーに通知します。
ログイン後、新しいユーザーはいつでも passwd を実行して別のパスワードに変更できます。
ユーザーパスワードの設定
ユーザーは passwd を実行してパスワードを変更します。
% passwd username
ユーザーがパスワードを変更する前に、NIS 管理者はマスターサーバー上で rpc.yppasswdd デーモンを起動してパスワードファイルを更新する必要があります。
rpc.yppasswdd デーモンは、マスターサーバー上で自動的に起動します。rpc.yppasswdd に -m オプションが指定された場合は、ファイルが更新されるとすぐ /var/yp の make が実行されます。passwd ファイルが更新されるたびにこの make が実行されることを回避したい場合は、ypstart スクリプトの rpc.yppasswd コマンドから -m オプションを削除して、crontab ファイルで passwd マップの転送を制御してください。
注 –
rpc.yppasswd - m コマンドのあとに引数を指定するべきではありません。別の動作のために ypstart スクリプトファイルを編集することは可能ですが、-m オプションを任意に削除すること以外の変更をこのファイルに加えることは望ましくありません。すべてのコマンドおよびデーモンは、適切なコマンド行パラメータのセットが存在するこのファイルで起動されます。このファイルを編集する場合は、rpc.yppasswdd コマンドの編集では特に注意してください。passwd.adjunct ファイルに明示的コールを追加する場合は、パスを $PWDIR/security/passwd.adjunct と正確に指定しなければなりません。正確に指定しないと、不適切な処理が行われます。
NIS ネットグループ
NIS ネットグループは、NIS 管理者が管理目的のために定義するユーザーまたはマシンのグループ (集合) です。たとえば、次のようなネットグループを作成できます。
-
特定マシンにアクセスできる一群のユーザーを定義する
-
特定のファイルシステムにアクセスできる一群の NFS クライアントマシンを定義する
-
特定の NIS ドメインのすべてのマシンに対して管理者権限を持つ一群のユーザーを定義する
各ネットグループには、1 つのネットグループ名が与えられます。ネットグループはアクセス権を直接設定しません。代わりに、ユーザー名またはマシン名が一般に使用される場所ではネットグループ名がほかの NIS マップで使用されます。たとえば、netadmins というネットワーク管理者ネットグループを作成したと仮定します。netadmins ネットグループのすべてのメンバーに特定マシンへのアクセス権を与えるには、そのマシンの /etc/passwd ファイルに netadmin エントリを追加するだけで、ネットグループ名を /etc/netgroup ファイルに追加して、NIS グループマップに追加することもできます。ネットグループの使い方の詳細については、netgroup(4) のマニュアルページを参照してください。
NIS が使用されているネットワーク上では、NIS マスターサーバー上の netgroup 入力ファイルを使用して、次の 3 つのファイルが生成されます。netgroup、netgroup.byuser、および netgroup.byhost です。netgroup マップには、netgroup 入力ファイルの基本情報が入っています。ほかの 2 つの NIS マップには、マシンまたはユーザーが指定されるとネットグループ情報の検索が迅速に行われるフォーマットで情報が入っています。
netgroup 入力ファイルのエントリのフォーマットは、 name ID です。name はネットグループ名であり、ID は、ネットグループに属しているマシンまたはユーザーを示します。ネットグループの ID (メンバー) は、コンマで区切っていくつでも指定できます。たとえば、3 つのメンバーが存在するネットグループを作成する場合、netgroup 入力ファイルエントリのフォーマットは、name ID, ID, ID となります。netgroup 入力ファイルエントリのメンバーID のフォーマットは次のようになります。
([-|machine], [-|user], [domain]) |
machine はマシン名、user はユーザー ID 、domain はマシンまたはユーザーの NIS ドメインです。「ドメイン」エレメントは任意指定ですが、ほかの NIS ドメインのマシンまたはユーザーを示す場合には必ず指定します。各エントリでは「マシン」エレメントと「ユーザー」エレメントは必須ですが、ダッシュ (-) は空であることを示すために使用されます。エントリでは、「マシン」エレメントと「ユーザー」エレメントの関係を示す必要はありません。
netgroup 入力ファイルの 2 つのサンプルエントリを次に示します。これらの各サンプルエントリでは、admins という名前のネットグループが作成されます。これらの各ネットグループは、遠隔ドメイン sales に存在するユーザー hauri と juanita、およびマシン altair と sirius で構成されます。
admins (altair, hauri), (sirius,juanita,sales) |
admins (altair,-), (sirius,-), (-,hauri), (-,juanita,sales) |
さまざまなプログラムでは、ログイン、遠隔マウント、遠隔ログイン、および遠隔シェル作成時に NIS ネットグループマップを使用してアクセス権のチェックを行います。さまざまなプログラムとは、mountd、login、rlogin、rsh などです。login コマンドは、passwd データベース内でネットグループ名を見つけた場合に、ネットグループマップでユーザー分類を調べます。mountd デーモンは、/etc/dfs/dfstab ファイル内でネットグループ名を見つけた場合に、ネットグループマップでマシン分類を調べます。rlogin と rsh (ruserok インタフェースを使用する任意のプログラム) は、/etc/hosts.equiv または .rhosts ファイル内でネットグループ名を見つけた場合に、ネットグループマップでマシン分類とユーザー分類の両方を調べます。
ネットワークに新しい NIS ユーザーまたはマシンを追加する場合は、netgroup 入力ファイルの該当ネットグループに追加してください。次に、make でネットグループマップを作成し、これを yppush コマンドですべての NIS サーバーに転送してください。ネットグループおよびネットグループ入力ファイル構文の使い方の詳細については、netgroup(4) のマニュアルページを参照してください。
NIS マップに関する作業
この節には次の情報が含まれます。
マップ情報の取得
マップ情報は、ypcat、ypwhich、ypmatch コマンドを使っていつでも取得できます。次の例では、mapname はマップの正式名とニックネーム (存在する場合) の両方を意味します。
マップのすべての値を表示するには、次のように入力します。
% ypcat mapname |
マップのキーと値 (存在する場合) の両方を表示するには、次のように入力します。
% ypcat -k mapname |
マップのすべてのニックネームを表示するには、次のいずれかのコマンドを入力します。
% ypcat -x % ypmatch -x % ypwhich -x |
使用可能なすべてのマップとそのマスターサーバーを表示するには、次のように入力します。
% ypwhich -m |
特定のマップのマスターサーバーを表示するには、次のように入力します。
% ypwhich -m mapname |
キーをマップのエントリと照合するには、次のように入力します。
% ypmatch key mapname |
検索している項目がマップのキーでない場合は、次のように入力します。
% ypcat mapname | grep item |
item は検索している情報です。ほかのドメインに関する情報を取得するには、これらのコマンドの -d domainname オプションを指定します。
デフォルト以外のドメインの情報を要求するマシンが、そのドメインに対するバインドを持っていない場合、ypbind は /var/yp/binding/domainname/ypservers ファイルを参照して、そのドメインのサーバーリストを検索します。このファイルが存在しない場合、ypbind は RPC 同報通信を送出してサーバーを検索します。この場合、検索先であるドメインのサーバーは要求元マシンと同じサブネットに存在している必要があります。
マップのマスターサーバーの変更
選択されたマップのマスターサーバーを変更するには、まず新しい NIS マスターサーバー上にマップを構築する必要があります。古いマスターサーバー名は既存のマップにキーと値のペアとして発生するので (このペアは makedbm で自動的に挿入される)、ypxfr でマップを新しいマスターサーバーにコピーしたり、コピーを新しいマスターサーバーに転送するだけでは不十分です。キーと新しいマスターサーバー名との対応づけをし直す必要があります。マップに ASCII ソースファイルが存在する場合は、このファイルを新しいマスターサーバーにコピーします。
マップのマスターサーバーを変更する方法
-
新しいマスターで、スーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
ディレクトリを変更します。
newmaster# cd /var/yp
-
作成するマップを指定する前に、Makefile にこの新しいマップのエントリが必要です。新しいマップのエントリがない場合は、最初に、sites.byname というマップを使用して Makefile を編集します。
-
マップを更新または再作成するには、次のように入力します。
newmaster# make sites.byname
-
古いマスターサーバーが NIS サーバーとして残っている場合は、古いマスターサーバーに遠隔ログイン (rlogin) してから、Makefile を編集します。sites.byname を作成した Makefile 内のセクションをコメントアウトして、このセクションで sites.byname が再び作成されないようにします。
-
sites.byname だけが ndbm ファイルとして存在している場合は、新しいマスターサーバー上に作成し直します。まず任意の NIS サーバーからコピーを分解し、次に makedbm を使ってそれを実行します。
newmaster# cd /var/yp newmaster# ypcat sites.byname | makedbm -domain-/sites.byname
新しいマスターサーバー上でマップが作成されたら、そのコピーをほかのスレーブサーバーに送信する必要があります。この場合、yppush を使用しないでください。yppush を使用すると、スレーブサーバーは新しいマスターサーバーからではなく古いマスターサーバーから新しいコピーを取得します。このような動作を回避するには、一般にマップのコピーを新しいマスターサーバーから古いマスターサーバーに送り返すという方法が使用されます。これを行うには、古いマスターサーバーでスーパーユーザーになるか、同等の役割になり、次のように入力します。
oldmaster# /usr/lib/netsvc/yp/ypxfr -h newmaster sites.byname
これで、yppush を使用できます。スレーブサーバーは古いマスターサーバーを現行のマスターサーバーとして認識しているので、マップの現行バージョンを古いマスターサーバーから取得しようとします。クライアントがこの処理を行うときは、新しいマスターサーバーが現行のマスターサーバーとして指定されている新しいマップを取得します。
この方法が失敗した場合は、各 NIS サーバーの root としてログインして上記の ypxfr コマンドを実行できます。
構成ファイルの変更
NIS は設定ファイルを正確に構文解析します。このため NIS 管理は容易になりますが、設定ファイルおよび構成ファイルにおける変更により、NIS の動作は影響を受けます。
次のファイルを変更する場合は、この節の手順を使用します。
-
/etc/resolv.conf。このファイルを追加または削除することで、DNS 転送が可能または不可になります
-
$PWDIR/security/passwd.adjunct。このファイルを追加したり削除したりすることで、C2 セキュリティーが可能または不可になります ($PWDIR は、/var/yp/Makefile で定義される)
構成ファイルを更新する方法
NIS のマップまたはマップソースファイルを更新する場合は、NIS を停止および起動する必要はありません。
次の点に注意してください。
-
NIS マスターサーバーからマップまたはソースファイルを削除しても、スレーブサーバー上の対応するマップまたはソースファイルは自動的には削除されません。スレーブサーバー上の対応するマップまたはソースファイルの削除は、NIS 管理者が手作業で行う必要があります。
-
新しいマップは、自動的には既存のスレーブサーバーに転送されません。新しいマップを既存のスレーブサーバーに転送するには、NIS 管理者がそのスレーブサーバーで ypxfr を実行してください。
-
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
NIS サーバーを停止します。
# svcadm disable network/nis/server
-
必要に応じてファイルを変更します。
-
NIS サーバーを起動します。
# svcadm enable network/nis/server
Makefile の更新と使用
/var/yp で提供されたデフォルトの Makefile を更新することにより、NIS 管理者のニーズを満たすことができます。マップを追加したり削除したり、一部のディレクトリの名前を変更できます。
ヒント –
将来の参照のために、変更していない、元の Makefile のコピーを保存しておいてください。
Makefile での作業
新しい NIS マップを追加するには、マップの ndbm ファイルのコピーをドメインに存在する各 NIS サーバーの /var/yp/domainname ディレクトリに転送する必要があります。通常これは、Makefile によって行われます。どの NIS サーバーがマップのマスターサーバーであるかを決定したら、マップを容易に作成し直せるようにマスターサーバーの Makefile を更新してください。異なるサーバーを異なるマップのマスターサーバーとして設定することも可能ですが、このようにするとたいていの場合、管理上の混乱を招きます。したがって、1 つのサーバーだけをすべてのマップのマスターサーバーとして設定するようにしてください。
一般に、人が読めるテキストファイルは、makedbm に対する入力として適したものにするために awk 、sed、grep でフィルタリングされます。デフォルトの Makefile を参照してください。make コマンドの概要については、make(1S) のマニュアルページを参照してください。
make が認識する依存性の作成方法を決定する際には、Makefile にすでに備わっているメカニズムを使用してください。make では、依存ルール内の行の始まりにタブが存在するか否かが重要であることに注意してください。ほかの設定が正しくても、タブが存在しないというだけでエントリが無効になることがあります。
Makefile にエントリを追加する場合は、次の作業を行ってください。
-
データベース名を all ルールに追加する
-
time ルールを作成する
-
データベースのルールを追加する
たとえば、Makefile をオートマウンタ入力ファイルで動作させるには、auto_direct.time および auto_home.time マップを NIS データベースに追加する必要があります。
これらのマップを NIS データベースに追加するには、Makefile を修正する必要があります。
Makefile のマクロおよび変数の変更
Makefile の先頭で定義されている変数の設定値を変更するには、等号 (=) の右側の値を変更します。たとえば、マップへの入力として /etc に存在するファイルではなく、別のディレクトリに存在するファイル (たとえば /var/etc/domainname など) を使用する場合は、DIR を DIR=/etc から DIR=/var/etc/domainname に変更します。また、PWDIR を PWDIR=/etc から PWDIR=/var/etc/domainname に変更します。
変数は次のとおりです。
-
DIR=。passwd と shadow を除くすべての NIS 入力ファイルが存在するディレクトリ。デフォルト値は /etc です。マスターサーバーの /etc ディレクトリのファイルを NIS 入力ファイルとして使用することは望ましくないので、この値は変更しなければなりません。
-
PWDIR=。NIS 入力ファイル passwd と shadow が存在するディレクトリ。マスターサーバーの /etc ディレクトリのファイルを NIS 入力ファイルとして使用することは望ましくないので、この値は変更しなければなりません。
-
DOM=。NIS ドメイン名。DOM のデフォルト値は、domainname コマンドで設定されます。ただし、大部分の NIS コマンドでは現在のマシンのドメイン (現在のマシンの /etc/defaultdomain ファイルに設定されている) が使用されます。
Makefile エントリの変更
次の手順では、Makefile にデータベースを追加したり削除したりする方法を説明します。
特定のデータベースを使用するために Makefile を変更する方法
-
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
all という語で始まる行に、追加したいデータベース名 (1 つまたは複数) を追加します。
all: passwd group hosts ethers networks rpc services protocols \ netgroup bootparams aliases netid netmasks \ audit_user auth_attr exec_attr prof_attr \ auto_direct auto_home auto_direct.time auto_home.time
エントリの順序は任意ですが、継続行の始まりの空白はスペースではなくタブにしてください。
-
Makefile の終わりに次の行を追加します。
auto_direct: auto_direct.time auto_home: auto_home.time
-
ファイル中央に auto_direct.time エントリを追加します。
auto_direct.time: $(DIR)/auto_direct @(while read L; do echo $$L; done < $(DIR)/auto_direct $(CHKPIPE)) | \ (sed -e "/^#/d" -e "s/#.*$$//" -e "/^ *$$/d" $(CHKPIPE)) | \ $(MAKEDBM) - $(YPDBDIR)/$(DOM)/auto_direct; @touch auto_direct.time; @echo "updated auto_direct"; @if [ ! $(NOPUSH) ]; then $(YPPUSH) auto_direct; fi @if [ ! $(NOPUSH) ]; then echo "pushed auto_direct"; fi
次に、各引数について説明します。
-
CHKPIPE は、次のコマンドに結果を渡す (パイピングする) 前に、パイプ (|) の左側の動作が正しく行われたことを確認します。パイプの左側の動作が正しく行われなかった場合は、「NIS make terminated」というメッセージが表示されてプロセスは終了します。
-
NOPUSH は、makefile が yppush を呼び出して新しいマップをスレーブサーバーに転送することを防止します。NOPUSH が設定されていない場合は、転送は自動的に行われます。
継続行の始まりにある while ループは、バックスラッシュで拡張された行を入力ファイルから削除するためのものです。sed スクリプトはコメント行と空行を削除します。
ほかのすべてのオートマウンタマップ (auto_home やほかのデフォルトでないマップなど) でも、同じ手順が必要となります。
-
-
make を実行します。
# make mapname
mapname は、作成するマップの名前です。
データベースを削除するために Makefile を変更する方法
Makefile で特定データベースのマップを作成しない場合は、Makefile を次のように編集してください。
-
all ルールからデータベース名を削除します。
-
削除するデータベースのデータベースルールを削除またはコメントアウトします。
-
time ルールを削除します。
たとえば、hosts データベースを削除するには、hosts: hosts.time エントリを削除します。
-
マスターサーバーとスレーブサーバーからマップを削除します。
既存のマップの更新
NIS のインストール終了後、頻繁に更新しなければならないマップとまったく更新する必要がないマップがあることに気づくかもしれません。たとえば、passwd.byname マップは、大企業のネットワークで頻繁に更新されることがありますが、auto_master マップはほとんど更新されません。
「デフォルトの NIS マップ」で説明されているように、デフォルトの NIS マップのデフォルトの位置は、/var/yp/domainname のマスターサーバー上です。domainname は NIS ドメインの名前です。マップを更新する必要がある場合は、マップがデフォルトのマップか否かによって 2 つの更新手順のどちらかを使用できます。
この節では、さまざまな更新ツールの使用方法について説明します。実際にはこれらの更新ツールはシステム起動後に、デフォルトでないマップを追加する場合または一群の NIS サーバーを変更する場合にだけ使用します。
デフォルトセットに付いているマップを更新する方法
デフォルトセットに付いているマップを更新する場合は、次の手順に従います。
-
マスターサーバー上でスーパーユーザーになります。
必ずマスターサーバー上だけで NIS マップを更新します。
-
更新するマップのソースファイルを編集します (このファイルが /etc に存在しているか、選択されたほかのディレクトリに存在しているかは問題ではありません)。
-
次のように入力します。
# cd /var/yp # make mapname
make コマンドは、対応するファイルに対して NIS 管理者が行った変更に従ってマップを更新します。make コマンドはまた、これらの変更をほかのサーバーに伝播します。
更新したマップを管理する
以降の節では、デフォルトセットで提供されているマップの更新完了後に実行する手順について説明します。
NIS マップを伝播する
マップが更新されると、Makefile は yppush を使用して新しいマップをスレーブサーバーに伝播します (ただし、NOPUSH が Makefile に設定されている場合を除く)。これは、ypserv デーモンに通知してマップ転送要求を送ることで実行されます。次に、スレーブサーバー上の ypserv デーモンが ypxfr プロセスを起動し、マスターサーバー上の ypxfrd デーモンに連絡します。いくつかの基本検査 (マップが実際に更新されているかどうかの確認など) が行われてマップが転送されます。そのあと、スレーブサーバー上の ypxfr が、転送が成功したかどうかを yppush プロセスに通知します。
注 –
上記手順は、新しく作成されたマップがスレーブサーバー上に存在しない場合は動作しません。スレーブサーバー上で ypxfr を実行して、新しいマップをスレーブサーバーに転送する必要があります。
マップの伝播は失敗することがありますが、失敗した場合は ypxfr を使って手動で新しいマップ情報を転送する必要があります。ypxfr は、2 つの方法で使用できます。 1 つは root の crontab ファイルを定期的に使用する方法であり、もう 1 つはコマンド行から対話形式で使用する方法です。これらの方法については、以降の節で説明します。
cron を使ってマップ転送を行う
マップの更新頻度はマップによってそれぞれ異なります。たとえば、デフォルトのマップである protocols.byname やデフォルトでないマップの auto_master など一部のマップは何ヶ月も更新されないことがありますが、passwd.byname など一部のマップは 1 日に数回更新されることがあります。crontab コマンドでマップ転送をスケジュールすると、個々のマップに対して特定の更新時間を設定できます。
マップに適切な頻度で ypxfr を定期的に実行するには、各スレーブサーバー上の root の crontab ファイルに、該当する ypxfr エントリを入れる必要があります。ypxfr は、マスターサーバー上のコピーがローカルのコピーより新しい場合に限り、マスターサーバーと連絡をとりマップを転送します。
注 –
デフォルトの m オプションが指定されている -rpc.yppasswdd をマスターサーバー上で実行すると、どこかで yp パスワードが変更されるたびに、 passwd デーモンが make を実行して passwd マップを作成し直します。
cron と ypxfr でシェルスクリプトを使用する
NIS 管理者は、各マップに対する crontab エントリを個々に作成するという方法ではなく、root の crontab コマンドでシェルスクリプトを実行してすべてのマップを定期的に更新するという方法を使用することもできます。マップ更新シェルスクリプトのサンプルは、/usr/lib/netsvc/yp ディレクトリに入っています。スクリプト名は、ypxfr_1perday、ypxfr_1perhour、ypxfr_2perday です。これらのシェルスクリプトを更新または置換することによって、容易にサイト要件に適合させることができます。例 6–1 は、デフォルトの ypxfr_1perday シェルスクリプトを示しています。
例 6–1 ypxfr_1perday シェルスクリプト
#! /bin/sh # # ypxfr_1perday.sh - Do daily yp map check/updates PATH=/bin:/usr/bin:/usr/lib/netsvc/yp:$PATH export PATH # set -xv ypxfr group.byname ypxfr group.bygid ypxfr protocols.byname ypxfr protocols.bynumber ypxfr networks.byname ypxfr networks.byaddr ypxfr services.byname ypxfr ypservers |
このシェルスクリプトは、root の crontab が毎日実行される場合はマップを 1 日に 1 回更新します。NIS 管理者は、1 週間に 1 回、1 ヶ月に 1 回、または 1 時間に 1 回などといった頻度でマップを更新するスクリプトを使用できますが、マップを頻繁に伝播するとパフォーマンスが低下するので注意してください。
NIS ドメインに対して構成された各スレーブサーバー上で同じシェルスクリプトを root で実行してください。各サーバー上の実行時間を変更して、マスターサーバーが動作不能にならないようにしてください。
特定のスレーブサーバーからマップを転送する場合は、シェルスクリプトの ypxfr の -h machine オプションを使用してください。シェルスクリプトに記述するコマンドの構文は、次のとおりです。
# /usr/lib/netsvc/yp/ypxfr -h machine [ -c ] mapname |
machine は転送するマップが存在するサーバー名です。mapname は要求されたマップ名です。マシンを指定することなく -h オプションを指定すると、ypxfr はマスターサーバーからマップを取得しようとします。ypxfr 実行時に ypserv がローカルに実行されていない場合は、ypxfr がローカル ypserver に現在のマップ要求の取消しを送信しないよう、-c フラグを使用してください。
-s domain オプションを使用すると、別のドメインからローカルドメインにマップを転送できます。これらのマップは、各ドメインにおいて同じでなければなりません。たとえば、2 つのドメインが同じ services.byname マップおよび services.byaddr マップを共有することがあります。また、より細かい制御を行うための rcp または rdist を使用してファイルを複数のドメインに転送することもできます。
ypxfr を直接起動する
2 番目の方法である ypxfr の起動とは、ypxfr をコマンドとして実行することです。一般に、ypxfr をコマンドとして実行するのは例外的状況においてだけです。たとえば、一時的に NIS サーバーを設定して試験環境を作成する場合や、動作不能になっていた NIS サーバーをほかのサーバーと迅速に整合させようとする場合などです。
ypxfr のアクティビティーを記録する
ypxfr が試みた転送およびその転送結果は、ログファイルに記録されます。/var/yp/ypxfr.log というファイルが存在する場合は、転送結果はこのファイルに記録されます。このログファイルのサイズには制限がありません。このログファイルのサイズが無限に大きくなることを防止するには、ときどき次のように入力してこのログファイルを空にしてください。
# cd /var/yp # cp ypxfr.log ypxfr.log.old # cat /dev/null > /var/yp/ypxfr.log |
これらのコマンドは、crontab で 1 週間に 1 回実行させることができます。記録を取らないようにするには、ログファイルを削除してください。
デフォルトでないマップの更新
デフォルトでないマップを更新する場合は、次の手順に従います。
-
対応するテキストファイルを作成または編集します。
-
新しいマップまたは更新されたマップを作成 (または再作成) します。マップ作成には 2 つの方法があります。
-
Makefile を使用する方法。デフォルトでないマップを作成するには、この方法をお勧めします。Makefile にマップのエントリが存在する場合は、make name を実行します (name は作成するマップ名)。Makefile にマップのエントリが存在しない場合は、「Makefile の更新と使用」を参照してエントリを作成してください。
-
/usr/sbin/makedbm プログラムを使用する方法。このコマンドの詳細については、makedbm(1M) のマニュアルページに説明されています。
-
デフォルトでないマップを makedbm で更新する
入力ファイルが存在しない場合は、makedbm でマップを更新する方法は 2 つあります。
-
makedbm -u の出力先を一時ファイルに変更し、一時ファイルを更新して更新済みの一時ファイルを makedbm の入力として使用します。
-
makedbm -u の出力を makedbm に渡されるパイプライン内で動作させます。分解されたマップを awk、sed、または cat で更新できる場合は、この方法をお勧めします。
テキストファイルからマップを新たに作成する
テキストファイル /var/yp/mymap.asc がマスターサーバー上のエディタまたはシェルスクリプトで作成されていると仮定します。この場合、このファイルから NIS マップを作成し、作成された NIS マップを homedomain サブディレクトリに入れるには、マスターサーバー上で次のように入力してください。
# cd /var/yp # makedbm mymap.asc homedomain/mymap |
mymap マップは現在、マスターサーバーの homedomain ディレクトリに存在しています。この新しいマップをスレーブサーバーに転送するには、ypxfr を実行してください。
ファイルをベースとしたマップにエントリを追加する
mymap へのエントリの追加は簡単です。まず、テキストファイル /var/yp/mymap.asc を更新します。対応するテキストファイルを更新しないで実際の dbm ファイルを更新した場合は、更新内容が失われます。次に、上記のように makedbm を実行してください。
標準入力からマップを作成する
オリジナルのテキストファイルが存在しない場合は、キーボードから makedbm に次のように入力して NIS マップを作成します (最後に Control + D を入力します)。
ypmaster# cd /var/yp ypmaster# makedbm -homedomain-/mymapkey1 value1 key2 value2 key3 value3 |
標準入力から作成されたマップを更新する
あとでマップを更新する必要がある場合は、makedbm でマップを分解して一時的な中間テキストファイルを作成できます。マップを分解して一時ファイルを作成するには、次のように入力します。
% cd /var/yp % makedbm -u homedomain/mymap > mymap.temp |
作成される一時ファイル mymap.temp には、1 行につき 1 つのエントリが存在します。このファイルは、任意のテキストエディタで必要に応じて編集できます。
マップを更新するには、次のように入力して更新後の一時ファイルの名前を makedbm に指定します。
% makedbm mymap.temp homedomain/mymap % rm mymap.temp |
次に root になり、次のように入力してマップをスレーブサーバーに伝播します。
# yppush mymap |
ここまでは makedbm でマップを作成する方法について説明してきましたが、実際に必要な作業はほとんど、ypinit と Makefile で行うことができます。ただし、システム起動後にデフォルトでないマップをデータベースに追加したり NIS サーバーセットを変更したりしない場合に限ります。
/var/yp の Makefile を使用してもほかの手順を使用しても、最終目的は同じです。正しく作成された dbm ファイルの新しいペアをマスターサーバー上の maps ディレクトリに配置しなければなりません。
スレーブサーバーの追加
NIS の実行後、ypinit に指定された初期リストに含まれていなかった NIS スレーブサーバーを必要に応じて作成します。
NIS スレーブサーバーを追加する場合は、次の手順に従います。
スレーブサーバーを追加する方法
-
マスターサーバーで、スーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
NIS ドメインディレクトリに移動します。
# cd /var/yp/domainname
-
# makedbm -u ypservers >/tmp/temp_file
makedbm コマンドは、ypservers を ndbm フォーマットから一時 ASCII ファイル、/tmp/temp_file に変換します。
-
テキストエディタで /tmp/temp_file ファイルを編集します。つまり、新しいスレーブサーバー名をサーバーリストに追加します。このあと、/tmp/temp_file ファイルを保存し、閉じます。
-
入力ファイルに temp_file を指定し、出力ファイルに ypservers を指定して、makedbm コマンドを実行します。
# makedbm /tmp/temp_file ypservers
makedbm は、ypservers を変換して ndbm フォーマットに戻します。
-
スレーブサーバーで次のように入力して、ypservers マップが正しいことを確認します (ypservers の ASCII ファイルは存在しないため)。
slave3# makedbm -u ypservers
makedbm コマンドは、画面に ypservers の各エントリを表示します。
注 –ypservers にマシン名が存在しない場合は、ypservers はマップファイルの更新を受信しません。これは、yppush がこのマップでスレーブサーバーリストを調べるからです。
-
新しい NIS スレーブサーバーで、スーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
新しいスレーブサーバーの NIS ドメインディレクトリを設定します。
マスターサーバーから NIS マップセットをコピーし、NIS クライアントを起動します。ypinit コマンドを実行 (起動) したら、プロンプトに従って、優先順に NIS サーバーを指定してください。
slave3# cd /var/yp slave3# ypinit -c slave3# svcadm enable network/nis/client
-
slave3# /usr/sbin/ypinit -s ypmaster
ypmaster は、既存の NIS マスターサーバーのマシン名です。
-
NIS クライアントとして実行されているマシンを停止します。
# svcadm disable network/nis/client
-
NIS スレーブサービスを開始します。
# svcadm enable network/nis/server
C2 セキュリティーが装備されている NIS の使用
$PWDIR/security/passwd.adjunct ファイルが存在する場合は、C2 セキュリティーが自動的に起動されます。$PWDIR は /var/yp/Makefile で定義されます。C2 セキュリティーモードでは、passwd.adjunct ファイルを使って passwd.adjunct NIS マップが作成されます。C2 セキュリティーモードでは、passwd.adjunct ファイルと shadow ファイルの両方を使用してセキュリティーを管理できます。passwd.adjunct ファイルは、次のように入力した場合にだけ処理されます。
# make passwd.adjunct |
make passwd コマンドは、NIS 管理者が C2 セキュリティーモードで make を手動で実行した場合に passwd マップのみを処理します。passwd.adjunct マップは処理されません。
特定の NIS サーバーへのバインド
指定した NIS サーバーにバインドするには、次の手順に従います。詳細は、ypinit(1M)、ypstart(1M)、および svcadm(1M) のマニュアルページを参照してください。
-
NIS サーバーのホスト名と IP アドレスを /etc/hosts ファイルに追加します。
-
domainname コマンドを実行して、/etc/defaultdomain ファイルを生成します。
# /usr/bin/domainname name-of-NIS-domain
-
NIS サーバーホスト名を要求します。
# /usr/sbin/ypinit -c Server name: Type the NIS server hostname
-
次のいずれかの手順を実行して、NIS サービスを再起動します。
-
リブート後を繰り返しても持続するサービスの場合は、svcadm コマンドを実行します。
# svcadm enable -r svc:/network/nis/client
-
次のリブートまでしか持続しないサービスの場合は、ypstop および ypstart コマンドを実行します。
# /usr/lib/netsvc/yp/ypstop # /usr/lib/netsvc/yp/ypstart
-
マシンの NIS ドメインの変更
マシンの NIS ドメイン名を変更する場合は、次の手順に従います。
マシンの NIS ドメイン名を変更する方法
-
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
マシンの /etc/defaultdomain ファイルを編集して、現在のドメイン名をそのマシンの新しいドメイン名に置き換えます。
たとえば、現在のドメイン名である sales.doc.com を research.doc.com に変更します。
-
domainname `cat /etc/defaultdomain' を実行します。
-
マシンを NIS クライアント、スレーブサーバー、またはマスターサーバーとして再初期化します。
詳細は、第 5 章NIS サービスの設定と構成を参照してください。
NIS を DNS と組み合わせて使用する
一般に NIS クライアントは、マシン名とアドレスの検索に NIS だけが使用されるように、nsswitch.conf ファイルで構成されます。このような検索が失敗した場合は、NIS サーバーはこれらの結果を DNS に転送します。
NIS と DNS によるマシン名とアドレスの検索を設定する方法
-
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
hosts.byname と hosts.byaddr という 2 つのマップファイルには、YP_INTERDOMAIN キーが必要です。このキーを検査するために、Makefile を編集し、次の行を変更します。
#B=-b B=
から
B=-b #B=
これで、マップの作成時に makedbm が -b フラグで起動され、YP_INTERDOMAIN キーが ndbm ファイルに挿入されます。
-
make コマンドを実行してマップを作成し直します。
# /usr/ccs/bin/make hosts
-
NIS サーバーのすべての /etc/resolv.conf ファイルが有効なネームサーバーを指していることを確認します。
注 –Solaris リリース 2 を実行していない NIS サーバーがある場合は、YP_INTERDOMAIN キーがホストマップに存在することを確認してください。
-
DNS 転送を有効にするために、各サーバーを再起動します。
# svcadm restart network/nis/server:<instance>
この NIS 実装では、ypserv が -d オプションを付けることで自動的に起動し、DNS に要求が転送されます。
混在 NIS ドメインの処理
マスターサーバーとスレーブサーバーのどちらも Solaris リリース 2 を実行していない場合は、次の表を参考にして問題が発生しないように対処してください。「4.0.3+」という表記は、「Solaris OS のリリース 4.0.3 以降」であることを意味します。makedm -b コマンドは、Makefile の「B」変数への参照です。
表 6–1 異機種システムが混在する NIS ドメインにおける NIS/DNS|
スレーブサーバー |
マスターサーバー |
||
|---|---|---|---|
|
4.0.3+ |
Solaris NIS |
||
|
4.0.3+ |
マスターサーバー: makedbm -b スレーブサーバー: ypxfr |
マスターサーバー: makedbm -b スレーブサーバー: ypxfr -b |
マスターサーバー: ypserv -d スレーブサーバー: ypxfr -b |
|
Solaris NIS |
マスターサーバー: makedbm -b スレーブサーバー: ypxfr |
マスターサーバー: makedbm -b スレーブサーバー: ypxfr |
マスターサーバー: ypserv -d スレーブサーバー: resolv.conf が存在する ypxfr または ypxfr -b |
NIS サービスをオフにする
NIS マスターサーバー上の ypserv が使用不可になっている場合は、NIS マップを更新できません。
-
クライアント上の NIS を無効にするには、次のように入力します。
# svcadm disable network/nis/client
-
特定のスレーブサーバーまたはマスターサーバー上の NIS を無効にするには、そのサーバー上で次のように入力します。
# svcadm disable network/nis/server
第 7 章 NIS のトラブルシューティング
この章では、NIS を実行しているネットワーク上で発生する問題の解決方法について説明します。NIS クライアントで発生する問題と、NIS サーバーで発生する問題を取り上げます。
NIS サーバーやクライアントで問題を解決しようとする前に、NIS 環境について説明している第 4 章ネットワーク情報サービス (NIS) (概要)を参照してください。そのあとこの節で、各問題を適切に解説している節を参照してください。
注 –
NIS サービスはサービス管理機能によって管理されます。このサービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できます。NIS で SMF を使用する場合の詳細については、「NIS とサービス管理機能」を参照してください。SMF の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。
NIS サービスの開始および停止は、ypstart および ypstop コマンドを使用しても行えます。詳細については、ypstart(1M) および ypstop(1M) のマニュアルページを参照してください。
NIS のバインドに関する問題
症状
NIS のバインドに関する一般的な問題には、次のようなものがあります。
-
クライアントのコマンドがバックグランドモードでゆっくりと処理されているか、通常よりも機能に時間がかかる
-
クライアントのコマンドがハングする。システム全体は正常で新しいコマンドを実行できる場合でも、コマンドがハングすることがあります
-
クライアントのコマンドがあいまいなメッセージとともに、またはまったくメッセージなしでクラッシュする
1 台のクライアントに影響する NIS の問題
1 台か 2 台のクライアントだけで、NIS のバインドに関する問題を示す症状が発生している場合は、そのクライアントに問題があると考えられます。複数のクライアントが正しくバインドできない場合は、1 台以上の NIS サーバーに問題があると考えられます。「複数のクライアントに影響する NIS の問題」を参照してください。
ypbind がクライアントで実行されていない
1 台のクライアントに問題があっても、同じサブネット上のほかのクライアントは正常に機能しています。問題のあるクライアント上で、ls -l をたとえば /usr のような、多くのユーザーが所有するファイル (クライアント /etc/passwd ファイルにはないものも含む) を持つディレクトリで実行します。この結果の表示に、ローカルの /etc/passwd には、名前ではなく番号として入ってないファイルの所有者が含まれる場合には、NIS サービスがクライアントで機能していないことを示します。
通常これらの症状は、クライアント ypbind プロセスが実行されていないことを示します。NIS クライアントサービスが実行されているかを確認してください。
client# svcs network/nis/client STATE STIME FMRI disabled Sep_01 svc:/network/nis/client:default |
クライアントが無効である場合、スーパーユーザーとしてログインするか、同等の役割になり、NIS クライアントサービスを開始します。
client# svcadm enable network/nis/client |
ドメイン名が指定されていないか間違っている
あるクライアントに問題があり、ほかのクライアントは正常に機能していますが、ypbind は問題のあるクライアント上で実行されています。クライアントのドメインの設定が間違っている可能性があります。
クライアント上で domainname コマンドを実行して、どのドメイン名が設定されているのかを調べます。
client7# domainname neverland.com |
NIS のマスターサーバー上の /var/yp 内の実際のドメイン名と、出力を比較します。実際の NIS ドメインは、/var/yp ディレクトリ内のサブディレクトリとして表示されます。
Client7# ls /var/yp... -rwxr-xr-x 1 root Makefile drwxr-xr-x 2 root binding drwx------ 2 root doc.com ... |
マシン上での domainname の実行によって得たドメイン名が、/var/yp 内のディレクトリとして示されたサーバードメイン名と同じではない場合には、マシンの /etc/defaultdomain ファイルで指定されたドメイン名が間違っています。スーパーユーザーとしてログインするか、同等の役割になり、マシンの /etc/defaultdomain ファイルでクライアントのドメイン名を修正します。これによって、マシンを起動するたびに、ドメイン名が正しいかどうかが確認されます。ここでマシンをリブートします。
注 –
ドメイン名では大文字と小文字を区別します。
クライアントがサーバーにバインドされない
ドメイン名が正しく設定されていて ypbind が実行中でもコマンドがまだハングする場合には、ypwhich コマンドを実行してクライアントがサーバーにバインドされていることを確認してください。ypbind を起動したばかりのときは、ypwhich を数回実行します。通常、1 回目ではドメインがバインドされていないことが通知され、2 回目は成功します。
サーバーが使用できない
ドメイン名が正しく設定されていて ypbind が実行中のときに、クライアントがサーバーと通信できないというメッセージを受け取った場合には、いくつかの問題が考えられます。
-
バインドするサーバーのリストを含む /var/yp/binding/domainname/ypservers ファイルがクライアントにあるかどうかを確認します。ない場合には、ypinit -c を実行して、設定の順番にクライアントのバインド先のサーバーを指定します。
-
クライアントに /var/yp/binding/domainname/ypservers ファイルがあり、1 つ以上のサーバーが使用できない場合には、十分な数のサーバーがあるかどうかを調べます。ない場合には、ypinit -c を実行して、リストにサーバーを追加します。
-
クライアントの ypservers ファイルにリストされたサーバーが、/etc/hosts ファイルにエントリを持っているかどうかを確認します。持っていない場合には、NIS マップホストの入力ファイルにサーバーを追加して、Working With NIS Mapsで説明しているように、-yppinit c または -ypinit 「NIS マップに関する作業」 を実行してマップを再構築します。
-
/etc/nsswitch.conf ファイルが設定されていて、NIS の他にマシンのローカルの hosts ファイルを参照できるかどうかを確認します。スイッチについての詳細は、第 2 章ネームサービススイッチ (概要)を参照してください。
-
/etc/nsswitch.conf ファイルが設定されていて、services と rpc に対して files を参照できるかどうかを確認します。スイッチについての詳細は、第 2 章ネームサービススイッチ (概要)を参照してください。
ypwhich の表示に一貫性がない
ypwhich を同じクライアントで数回使うと、NIS サーバーが変わるので結果の表示も変わります。これは正常な状態です。NIS クライアントから NIS サーバーへのバインドは、ネットワークや NIS サーバーを使用中の場合は時間の経過に伴って変化します。ネットワークは、すべてのクライアントが受け入れ可能な応答時間を NIS サーバーから得られる点で安定した状態になります。クライアントのマシンが NIS サービスを得ている限りは、サービスの供給元は問題にはなりません。たとえば、NIS サーバーマシンがそれ自体の NIS サービスを、ネットワーク上の別の NIS サーバーから受けることもあります。
サーバーのバインドが不可能な場合
ローカルなサーバーのバインドが不可能な場合には ypset コマンドを使用すると、別のネットワークまたはサブネットの別のサーバーが使用可能な場合には、そのサーバーへのバインドが一時的に可能になります。ただし、-ypset オプションを使用するためには、ypbind を -ypset または -ypsetme オプションのどちらかを指定して、実行する必要があります。詳細は、ypbind(1M) のマニュアルページを参照してください。
# /usr/lib/netsvc/yp/ypbind -ypset |
別の方法については、「特定の NIS サーバーへのバインド」を参照してください。
注 –
セキュリティーの目的のために、-ypset と -ypsetme のオプションの使用は、制御された状態でのデバッグだけに限定してください。-ypset と -ypsetme のオプションを使用すると、セキュリティーが侵害される恐れがあります。これらのデーモンの実行中はサーバーのバインドをだれでも変更できるため、ほかのユーザーの作業に問題が生じたり重要なデータへの未承認のアクセスが認められたりするためです。これらのオプションで ypbind を起動する場合には、いったん問題を修正したら ypbind を終了して、これらのオプションを指定しないで再起動してください。
ypbind を再起動するには、サービス管理機能 (SMF) を使用します。
# svcadm enable -r svc:/network/nis/client:default |
ypbind のクラッシュ
ypbind が、起動するたびにすぐにクラッシュする場合には、システムのほかの部分で問題を調べます。次のように入力して、rpcbind デーモンが存在するかどうか確認します。
% ps -e | grep rpcbind |
rpcbind が存在しない、安定しない、あるいは動作に異常がある場合には、RPC のマニュアルを参照してください。
正常に機能しているマシンから、問題のあるクライアント上の rpcbind と通信ができる場合があります。正常に機能しているマシンから、次のように入力してください。
% rpcinfo client |
問題のあるクライアント上の rpcbind に問題がない場合には、rpcinfo によって次のように出力されます。
program version netid address service owner ... 100007 2 udp 0.0.0.0.2.219 ypbind superuser 100007 1 udp 0.0.0.0.2.219 ypbind superuser 100007 1 tcp 0.0.0.0.2.220 ypbind superuser 100007 2 tcp 0.0.0.0.128.4 ypbind superuser 100007 2 ticotsord \000\000\020H ypbind superuser 100007 2 ticots \000\000\020K ypbind superuser ... |
使用中のマシンには異なる複数のアドレスがあります。それらのアドレスが表示されない場合は、ypbind によってそのサービスが登録できていません。マシンをリブートして再度 rpcinfo を実行します。ypbind プロセスがあり、NIS サービスを再起動するたびに変更される場合は、rpcbind デーモンが実行中であってもシステムをリブートしてください。
複数のクライアントに影響する NIS の問題
1 台か 2 台のクライアントだけで、NIS のバインドに関する問題を示す症状が発生している場合は、そのクライアントに問題があると考えられます。「1 台のクライアントに影響する NIS の問題」を参照してください。複数のクライアントが正しくバインドできない場合は、1 台以上の NIS サーバーに問題があると考えられます。
rpc.yppasswdd が r で始まる制限のないシェルを制限付きとみなしている
-
次のような特殊な文字列が含まれている /etc/default/yppasswdd を作成します。 "check_restricted_shell_name=1"
-
「check_restricted_shell_name=1」文字列をコメント扱いにすると、「r」のチェックは行われません。
ネットワークまたはサーバーが過負荷
ネットワークまたは NIS サーバーが過負荷状態で、クライアント ypbind プロセスに ypserv が時間以内に応答を戻せない場合には、NIS がハングする場合があります。
こういった状態では、ネットワーク上のすべてのクライアントで同じまたは類似した問題が発生します。ほとんどの場合、この状態は一時的です。NIS サーバーが再起動して ypserv を再起動するか、または NIS サーバーまたはネットワーク自体の負荷が減少すると、通常、メッセージは消えます。
サーバーの誤動作
サーバーが起動して実行中であることを確認してください。サーバーが物理的に近くにない場合には、ping コマンドを使ってください。
NIS デーモンが実行されていない
サーバーが起動されていて実行中の場合には、クライアントマシンが正常に動作していることを調べて、ypwhich コマンドを実行します。ypwhich が応答しない場合は、そのコマンドを強制終了します。次に、NIS サーバーで root としてログインし、次のように入力して NIS プロセスが実行中かどうかをチェックします。
# ps -e | grep yp |
注 –
-f オプションを ps で使用しないでください。このオプションはユーザー ID を名前に変換しようとするため、より多くのネームサービス検索が失敗する可能性があります。
NIS サーバーデーモン (ypserv) も NIS クライアントデーモン (ypbind) も実行されていない場合、次のいずれかを入力してデーモンを再起動します。
# svcadm restart network/nis/server or # /usr/lib/netsvc/yp/ypstop # /usr/lib/netsvc/yp/ypstart |
ypbind と ypserv の両プロセスが NIS サーバーで実行中の場合は、ypwhich を実行します。ypwhich が応答しない場合は、ypserv がハングしたと考えられるため再起動が必要です。サーバーに root としてログインし、次のいずれかを入力して NIS サービスを再起動します。
# svcadm restart network/nis/server or # /usr/lib/netsvc/yp/ypstop # /usr/lib/netsvc/yp/ypstart |
サーバーに別のバージョンの NIS マップが存在する
NIS はマップをサーバー間で伝播するので、ネットワーク上のさまざまな NIS サーバーに、同じマップの異なるバージョンが存在することがあります。相違点が長時間継続しない場合には、このバージョンの違いは許容可能です。
マップの不一致のもっとも一般的な原因は、マップの正常な伝播を妨げる何かが存在するためです。たとえば、NIS サーバーまたはルーターが、NIS サーバー間でダウンしている場合です。すべての NIS サーバーとそれらの間に存在するルーターが実行中の場合には、ypxfr は成功します。
サーバーとルーターが正常に機能している場合には、次のことをチェックします。
-
ypxfr 出力のログをとります (「ypxfr 出力のログ」を参照)。
-
制御ファイルをチェックします (「crontab ファイルと ypxfr シェルスクリプトをチェックする」を参照)。
-
マスターサーバー上の ypservers マップをチェックします (「ypservers マップをチェックする」を参照)。
ypxfr 出力のログ
特定のスレーブサーバーでマップの更新に問題がある場合には、そのサーバーにログインして ypxfr を対話形式で実行します。ypxfr が失敗すると ypxfr がその理由を通知するので、問題の修正が可能になります。ypxfr が成功するが時々失敗するような場合には、メッセージのログをとるためのログファイルを作成します。ログファイルを作成する場合は、スレーブサーバーで次のように入力します。
ypslave# cd /var/yp ypslave# touch ypxfr.log |
これによって、ypxfr からのすべての出力を保存する ypxfr.log ファイルが作成されます。
この出力は、ypxfr が対話形式で実行しているときに表示する出力と似ていますが、ログファイルの各行にはタイムスタンプが記録されます。タイムスタンプは通常とは異なる順番になる可能性がありますが、問題はありません。タイムスタンプは、ypxfr が実行し始めたことを示します。ypxfr のコピーが同時に実行されても作業時間が異なる場合は、起動時とは異なる順番でサマリーステータス行がログファイルに書き込まれることがあります。断続的に発生するあらゆる種類の障害がログに記録されます。
注 –
問題を解決したら、ログファイルを削除してログを停止します。削除しないと、ログは制限なく大きくなります。
crontab ファイルと ypxfr シェルスクリプトをチェックする
root の crontab ファイルを調べて、それが起動した ypxfr シェルスクリプトをチェックします。これらファイルにタイプミスがあると、伝播に関する問題が発生します。/var/spool/cron/crontabs/root ファイル内でシェルスクリプトを参照できない場合や、任意のシェルスクリプト内でマップを参照できない場合にも、エラーが発生します。
ypservers マップをチェックする
NIS スレーブサーバーが、ドメインに対するマスターサーバー上の ypservers マップにリストされていることも確認してください。リストされていない場合には、スレーブサーバーはサーバーとして正しく機能しますが、yppush はマップの変更をスレーブサーバーに伝播しません。
対策
NIS スレーブサーバーの問題が明白ではない場合には、rcp または ftp を使ってデバッグし、一貫性のないマップの最新バージョンを問題のない NIS サーバーからコピーして問題を解決できます。次に問題のあるマップを転送する方法を示します。
ypslave# rcp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain |
* の文字はコマンド行でエスケープされて、ypslave でローカルにではなく ypmaster で展開されます。
ypserv のクラッシュ
ypserv プロセスがほとんど即座にクラッシュして、何度再起動しても安定しないときは、デバッグプロセスは、「ypbind のクラッシュ」で説明する内容と実質的に同じです。rpcbind デーモンの存在を次のようにチェックしてください。
ypserver% ps -e | grep rpcbind |
デーモンが見つからない場合は、サーバーをリブートします。デーモンが見つかった場合は、デーモンが実行中であれば次のように入力して同様の出力を検索します。
% rpcinfo -p ypserver |
% program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100068 2 udp 32813 cmsd ... 100007 1 tcp 34900 ypbind 100004 2 udp 731 ypserv 100004 1 udp 731 ypserv 100004 1 tcp 732 ypserv 100004 2 tcp 32772 ypserv |
使用中のマシンには、異なる複数のポート番号があることがあります。ypserv プロセスを表す 4 つのエントリは、次のとおりです。
100004 2 udp 731 ypserv 100004 1 udp 731 ypserv 100004 1 tcp 732 ypserv 100004 2 tcp 32772 ypserv |
エントリが 1 つもなく、ypserv がそのサービスを rpcbind で登録できない場合にはマシンをリブートしてください。エントリがある場合には、rpcbind からサービスの登録を解除してから ypserv を再起動します。rpcbind からサービスの登録を解除するには、サーバーで次のように入力します。
# rpcinfo -d number 1 # rpcinfo -d number 2 |
number は、rpcinfo によって通知される ID 番号です (前述の例では、100004)。
- © 2010, Oracle Corporation and/or its affiliates