22.9. NIS/YP

原作: Swingle Bill [FAMILY Given].
追記: Ogren Eric [FAMILY Given]Erdelhoff Udo [FAMILY Given].

22.9.1. NIS/YP とは?

NIS とは Network Information Services の略で Sun Microsystems によって UNIX® の (もともとは SunOS™ の) 集中管理のために開発されました。現在では事実上の業界標準になっており、 主要な UNIX® ライクシステム (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD、等々) はすべてこれをサポートしています。

NIS は元々、イエローページといっていましたが、 商標問題から Sun はその名前を変えました。 古い用語 (および yp) はまだよく見られ、使用されています。

NIS は RPC を使ったクライアント/サーバシステムです。 これを使うと NIS ドメイン内のマシン間で、 共通の設定ファイルを共有することができます。 また NIS を使うことでシステム管理者は最小限の設定データで NIS クライアントを立ち上げることができ、 1 ヶ所から設定データの追加、削除、変更が可能です。

NIS は Windows NT® のドメインシステムに似ています。 内部の実装は似ても似つかないものですが、 基本的な機能を対比することはできます。

22.9.2. 知っておくべき用語 / プロセス

NIS サーバの立ち上げや NIS クライアントの設定など、 NIS を FreeBSD に導入するにあたって、 目にするであろう用語や重要なユーザプロセスがいくつかあります。

用語説明
NIS ドメイン名NIS マスタサーバとそのクライアントすべて (スレーブサーバを含む) には NIS ドメイン名がついています。 Windows NT® ドメイン名と同様に、NIS ドメイン名は DNS とは何の関係もありません。
portmapRPC (Remote Procedure Call, NIS で使用されるネットワークプロトコル) を利用するために実行しておかなければなりません。 portmap が動作していなければ、 NIS サーバを起動することも、 NIS クライアントとして動作させることもできません。
ypbindNIS クライアントを NIS サーバに 結びつけ ます。 これは NIS ドメイン名をシステムから取得し RPC を用いてサーバに接続します。ypbind は NIS 環境におけるクライアントとサーバ間の通信の中枢です。 クライアントマシンの ypbind が停止した場合は、NIS サーバへアクセスすることができなくなります。
ypservは NIS サーバでのみ実行されるべきもので、 NIS サーバプロセスそのものです。ypserv(8) が停止した場合、サーバはもはや NIS リクエストに応答することができなくなるでしょう (できれば、後を引き継ぐスレーブサーバがあるとよいでしょう)。 今まで使っていたサーバが機能を停止したとき、 別のサーバに再接続しに行かない NIS の実装もいくつかあります (FreeBSD のものは違います)。 そのような場合に復帰するための唯一の方法は、 サーバプロセス (あるいはサーバ全体)、もしくはクライアントの ypbind プロセスを再スタートすることです。
rpc.yppasswddNIS マスターサーバで動かすべき、 もう一つのプロセスです。これは NIS クライアントが NIS パスワードを変更することを可能にするデーモンです。 このデーモンが動作していないときは、 ユーザは NIS マスタサーバにログインし、 そこでパスワードを変更しなければなりません。

22.9.3. 動作のしくみ

NIS 環境にあるホストは、 マスターサーバ、スレーブサーバ、クライアントの 3 種類に分類されます。 サーバは、ホストの設定情報の中心的な情報格納庫の役割をします。 マスターサーバは元となる信頼できる情報を保持し、 スレーブサーバは冗長性を確保するためこの情報をミラーします。 そしてクライアントは、サーバから情報の提供を受けて動作します。

この方法を用いることで、数多くのファイルにある情報が共有できます。 よく NIS で共有されるのは、 master.passwdgroup, hosts といったファイルです。 クライアント上のプロセスが、 通常ならローカルのファイルにある情報を必要とするときは、 クライアントは代わりに接続している NIS サーバに問い合わせを行います。

22.9.3.1. マシンの分類

  • NIS マスターサーバ。 このサーバは Windows NT® で言うところのプライマリドメインコントローラにあたります。 すべての NIS クライアントで利用されるファイルを保守します。 passwdgroup、 その他 NIS クライアントが参照するファイルは、 マスターサーバにあります。

    注記:

    一つのマシンが一つ以上の NIS ドメインのマスターサーバになることは可能です。 しかし、ここでは比較的小規模の NIS 環境を対象としているため、 そのような場合については扱いません。

  • NIS スレーブサーバWindows NT® のバックアップドメインコントローラに似たもので、 NIS スレーブサーバは NIS マスターサーバのデータファイルのコピーを保持します。 NIS スレーブサーバは重要な環境で必要とされる冗長性を提供し、 マスターサーバの負荷のバランスをとります。 NIS クライアントは常に最初にレスポンスを返したサーバを NIS サーバとして接続しますが、 これにはスレーブサーバも含まれます。

  • NIS クライアント。 NIS クライアントは大部分の Windows NT® ワークステーションのように、ログオンに際して NIS サーバ (Windows NT® ワークステーションの場合は Windows NT® ドメインコントローラ) に接続して認証します。

22.9.4. NIS/YP を使う

この節では NIS 環境の立ち上げ例を取り上げます。

注記:

この節ではあなたが FreeBSD 3.3 以降を使っているものとします。 ここで与えられる指示は おそらく FreeBSD の 3.0 以降のどのバージョンでも機能するでしょうが、 それを保証するものではありません。

22.9.4.1. 計画を立てる

あなたが大学の小さな研究室の管理人であるとしましょう。 この研究室は 15 台の FreeBSD マシンからなっていて、 現在はまだ集中管理されていません。 すなわち、各マシンは /etc/passwd/etc/master.passwd を各々が持っています。 これらのファイルは手動でお互いに同期させています。 つまり現時点では、新しいユーザをあなたが追加するとき、 adduser を 15 ヶ所すべてで実行しなければなりません。 これは明らかに変える必要があるため、 あなたはこのうち 2 台をサーバにして NIS を導入することを決めました。

その結果、研究室の設定はこのようなものになります。

マシンの名前IP アドレス役割
ellington10.0.0.2NIS マスタ
coltrane10.0.0.3NIS スレーブ
basie10.0.0.4教員用のワークステーション
bird10.0.0.5クライアントマシン
cli[1-11]10.0.0.[6-17]その他のクライアントマシン

もし NIS によるシステム管理の設定を行なうのが初めてなら、 どのようにしたいのか、 ひととおり最後まで考えてみることをお勧めします。 ネットワークの規模によらず、 いくつか決めるべきことがあるからです。

22.9.4.1.1. NIS ドメイン名を決める

ここでいうドメイン名は、今まであなたが使っていた、 いわゆる ドメイン名 と呼んでいたものとは違います。 正確には NIS ドメイン名 と呼ばれます。 クライアントがサーバに情報を要求するとき、 その要求には自分が属する NIS ドメインの名前が含まれています。 これは 1 つのネットワークに複数のサーバがある場合に、 どのサーバが要求を処理すれば良いかを決めるために使われます。 NIS ドメイン名とは、 関連のあるホストをグループ化するための名前である、 と考えると良いでしょう。

組織によってはインターネットのドメイン名を NIS ドメイン名に使っているところがあります。 これはネットワークのトラブルをデバッグするときに混乱の原因となるため、 お勧めできません。 NIS ドメイン名はネットワーク内で一意なければいけません。そして、 ドメイン名がドメインに含まれるマシンを表すようなものであれば分かり易いです。 たとえば Acme 社のアート (Art) 部門であれば NIS ドメイン名を acme-art とすれば良いでしょう。この例では NIS ドメイン名として test-domain を使用します。

しかしながらオペレーティングシステムによっては (特に SunOS™)、 NIS ドメイン名をネットワークドメイン名として使うものもあります。 あなたのネットワークにそのような制限のあるマシンが 1 台でもあるときは、NIS のドメイン名としてインターネットのネットワークドメイン名を使わなければ いけません

22.9.4.1.2. サーバマシンの物理的必要条件

NIS サーバとして使うマシンを選ぶ際には、 いくつか注意すべき点があります。 NIS に関する困ったことの一つに、 クライアントのサーバへの依存度があります。 クライアントが自分の NIS ドメインのサーバに接続できないと、 マシンが使用不能になることがあまりに多いのです。 もし、ユーザやグループに関する情報が得られなければ、 ほとんどのシステムは一時的に停止してしまいます。 こういったことを念頭に置いて、頻繁にリブートされるマシンや、 開発に使われそうなマシンを選ばないようにしなければなりません。 理想的には NIS サーバはスタンドアロンで NIS サーバ専用のマシンにするべきです。 ネットワークの負荷が重くなければ、 他のサービスを走らせているマシンを NIS サーバにしてもかまいません。 ただし NIS サーバが使えなくなると、 すべての クライアントに影響をおよぼす、 という点には注意しなければなりません。

22.9.4.2. NIS サーバ

元となるすべての NIS 情報は、 NIS マスターサーバと呼ばれる 1 台のマシンに格納されます。 この情報が格納されるデータベースを NIS マップと呼びます。 FreeBSD では、このマップは /var/yp/[domainname] に置かれます。 [domainname] は、 サーバがサービスする NIS ドメインです。 1 台の NIS サーバが複数のドメインをサポートすることも可能です。 つまり、このディレクトリを各々のドメインごとに作ることができます。 それぞれのドメインは、 独立したマップの集合を持つことになります。

NIS のマスターサーバとスレーブサーバ上では、 ypserv デーモンがすべての NIS 要求を処理します。 ypserv は NIS クライアントからの要求を受け付け、 ドメイン名とマップ名を対応するデータベースファイルへのパスに変換し、 データをクライアントに返送します。

22.9.4.2.1. NIS マスターサーバの設定

やりたいことにもよりますが NIS マスターサーバの設定は比較的単純です。 FreeBSD は初期状態で NIS に対応しています。 必要なのは以下の行を /etc/rc.conf に追加することだけで、 あとは FreeBSD がやってくれます。

  1. nisdomainname="test-domain"

    この行はネットワークの設定後に (たとえば再起動後に) NIS のドメイン名を test-domain に設定します。

  2. nis_server_enable="YES"

    これは FreeBSD に次にネットワークが立ち上がったとき NIS のサーバプロセスを起動させます。

  3. nis_yppasswdd_enable="YES"

    これは rpc.yppasswdd デーモンを有効にします。上述したようにこれはユーザが NIS のパスワードをクライアントのマシンから変更することを可能にします。

注記:

NIS の設定によっては、 さらに他のエントリを付け加える必要があるかもしれません。 詳細については、下記の NIS クライアントとしても動作している NIS サーバ 節を参照してください。

さて、あとはスーパユーザ権限で /etc/netstart コマンドを実行するだけです。 これにより /etc/rc.conf で定義された値を使ってすべての設定が行なわれます。

22.9.4.2.2. NIS マップの初期化

NIS マップ とは /var/yp ディレクトリにあるデータベースファイルです。 これらは NIS マスタの /etc ディレクトリの設定ファイルから作られます。 唯一の例外は /etc/master.passwd ファイルです。これは root や他の管理用アカウントのパスワードまでその NIS ドメインのすべてのサーバに伝えたくないという、 もっともな理由によるものです。このため NIS マップの初期化の前に以下を行う必要があります。

# cp /etc/master.passwd /var/yp/master.passwd
# cd /var/yp
# vi master.passwd

システムに関するアカウント (bin, tty, kmem, games など) や、NIS クライアントに伝えたくないアカウント (たとえば root や他の UID が 0 (スーパユーザ) のアカウント) をすべて NIS マップから取り除かなければなりません。

注記:

/var/yp/master.passwd が グループまたは誰もが読めるようになっていないようにしてください (モード 600)! 必要なら chmod コマンドを使ってください。

すべてが終わったら NIS マップを初期化します! FreeBSD には、これを行うために ypinit という名のスクリプトが含まれています (詳細はそのマニュアルページをご覧ください)。 このスクリプトはほとんどの UNIX® OS に存在しますが、 すべてとは限らないことを覚えておいてください。 Digital Unix/Compaq Tru64 UNIX では ypsetup と呼ばれています。NIS マスタのためのマップを作るためには -m オプションを ypinit に与えます。上述のステップを完了しているなら、以下を実行して NIS マップを生成します。

ellington# ypinit -m test-domain
Server Type: MASTER Domain: test-domain
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n] n
Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
At this point, we have to construct a list of this domains YP servers.
rod.darktech.org is already known as master server.
Please continue to add any slave servers, one per line. When you are
done with the list, type a <control D>.
master server   :  ellington
next host to add:  coltrane
next host to add:  ^D
The current list of NIS servers looks like this:
ellington
coltrane
Is this correct?  [y/n: y] y

[..output from map generation..]

NIS Map update completed.
ellington has been setup as an YP master server without any errors.

ypinit/var/yp/Makefile/var/yp/Makefile.dist から作成します。 作成された時点では、そのファイルはあなたが FreeBSD マシンだけからなるサーバが 1 台だけの NIS 環境を扱っていると仮定しています。 test-domain はスレーブサーバを一つ持っていますので /var/yp/Makefile を編集しなければなりません。

ellington# vi /var/yp/Makefile

以下の行を (もし既にコメントアウトされていないならば) コメントアウトしなければなりません。

NOPUSH = "True"
22.9.4.2.3. NIS スレーブサーバの設定

NIS スレーブサーバの設定はマスターサーバの設定以上に簡単です。 スレーブサーバにログオンし /etc/rc.conf ファイルを前回と同様に編集します。唯一の違うところは ypinit の実行に -s オプションを使わなければいけないことです。 -s オプションは NIS マスターサーバの名前を要求し、 コマンドラインは以下のようになります。

coltrane# ypinit -s ellington test-domain

Server Type: SLAVE Domain: test-domain Master: ellington

Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.

Do you want this procedure to quit on non-fatal errors? [y/n: n]  n

Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
There will be no further questions. The remainder of the procedure
should take a few minutes, to copy the databases from ellington.
Transferring netgroup...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byuser...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byhost...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring group.bygid...
ypxfr: Exiting: Map successfully transferred
Transferring group.byname...
ypxfr: Exiting: Map successfully transferred
Transferring services.byname...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.byname...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.byname...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring netid.byname...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring ypservers...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byname...
ypxfr: Exiting: Map successfully transferred

coltrane has been setup as an YP slave server without any errors.
Don't forget to update map ypservers on ellington.

この例の場合 /var/yp/test-domain というディレクトリが必要になります。 NIS マスターサーバのマップファイルのコピーは、 このディレクトリに置いてください。 これらを確実に最新のものに維持する必要があります。 次のエントリをスレーブサーバの /etc/crontab に追加することで、最新のものに保つことができます。

20      *       *       *       *       root   /usr/libexec/ypxfr passwd.byname
21      *       *       *       *       root   /usr/libexec/ypxfr passwd.byuid

この二行はスレーブサーバにあるマップファイルを、 マスターサーバのマップファイルと同期させるものです。 このエントリは必須というわけではありませんが、マスターサーバは NIS マップに対する変更をスレーブサーバに伝えようとしますし、 サーバが管理するシステムにとってパスワード情報はとても重要なので、 強制的に更新してしまうことはよい考えです。特に、 マップファイルの更新がきちんと行なわれるかどうかわからないくらい混雑するネットワークでは、 重要になります。

スレーブサーバ上でも /etc/netstart コマンドを実行して、NIS サーバを再起動してください。

22.9.4.3. NIS クライアント

NIS クライアントは ypbind デーモンを使って、特定の NIS サーバとの間に結合 (binding) と呼ばれる関係を成立させます。 ypbind はシステムのデフォルトのドメイン (domainname コマンドで設定されます) を確認し、RPC 要求をローカルネットワークにブロードキャストします。 この RPC 要求により ypbind が結合を成立させようとしているドメイン名が指定されます。 要求されているドメイン名に対してサービスするよう設定されたサーバが ブロードキャストを受信すると、 サーバは ypbind に応答しypbind は応答のあったサーバのアドレスを記録します。複数のサーバ (たとえば一つのマスターサーバと、複数のスレーブサーバ) が利用可能な場合、ypbind は、 最初に応答したサーバのアドレスを使用します。 これ以降、クライアントのシステムは、 すべての NIS の要求をそのサーバに向けて送信します。 ypbind は、 サーバが順調に動作していることを確認するため、 時々 ping をサーバに送ります。 反応が戻ってくるべき時間内に ping に対する応答が来なければ、 ypbind は、そのドメインを結合不能 (unbound) として記録し、別のサーバを見つけるべく、 再びブロードキャストパケットの送信を行います。

22.9.4.3.1. NIS クライアントの設定

FreeBSD マシンを NIS クライアントにする設定は非常に単純です。

  1. ネットワークの起動時に NIS ドメイン名を設定して ypbind を起動させるために /etc/rc.conf ファイルを編集して以下の行を追加します。

    nisdomainname="test-domain"
    nis_client_enable="YES"
  2. NIS サーバから、 利用可能なパスワードエントリをすべて取り込むため、 /etc/master.passwd からすべてのユーザアカウントを取り除いて、 vipw コマンドで以下の行を /etc/master.passwd の最後に追加します。

    +:::::::::

    注記:

    この行によって NIS サーバのパスワードマップにアカウントがある人全員にアカウントが与えられます。 この行を変更すると、 さまざまな NIS クライアントの設定を行なうことが可能です。 詳細は ネットグループ を、さらに詳しい情報については、O'Reilly の Managing NFS and NIS を参照してください。

    注記:

    /etc/master.passwd 内に少なくとも一つのローカルアカウント (つまり NIS 経由でインポートされていないアカウント) を置くべきです。 また、このアカウントは wheel グループのメンバーであるべきです。 NIS がどこか調子悪いときには、 リモートからこのアカウントでログインし、 root になって修復するのに利用できます。

  3. NIS サーバにあるすべてのグループエントリを取り込むため、 以下の行を /etc/group に追加します。

    +:*::

上記の手順がすべて完了すれば、 ypcat passwd によって NIS サーバの passwd マップが参照できるようになっているはずです。

22.9.5. NIS セキュリティ

一般にドメイン名さえ知っていれば、 どこにいるリモートユーザでも ypserv(8) に RPC を発行して NIS マップの内容を引き出すことができます。 こういった不正なやりとりを防ぐため、 ypserv(8) には securenets と呼ばれる機能があります。これは、 アクセスを決められたホストだけに制限するのに使える機能です。 ypserv(8) は起動時に /var/yp/securenets ファイルから securenets に関する情報を読み込みます。

注記:

上記のパス名は -p オプションで指定されたパス名によって変わります。このファイルは、 空白で区切られたネットワーク指定とネットマスクのエントリからなっていて、 # で始まる行はコメントとみなされます。 簡単な securenets ファイルの例を以下に示します。

# allow connections from local host -- mandatory
127.0.0.1     255.255.255.255
# allow connections from any host
# on the 192.168.128.0 network
192.168.128.0 255.255.255.0
# allow connections from any host
# between 10.0.0.0 to 10.0.15.255
10.0.0.0      255.255.240.0

ypserv(8) が上記のルールの一つと合致するアドレスからの要求を受け取った場合、 処理は正常に行なわれます。 もしアドレスがルールに合致しなければ、 その要求は無視されて警告メッセージがログに記録されます。 また /var/yp/securenets が存在しない場合、 ypserv はすべてのホストからの接続を受け入れます。

ypserv は Wietse Venema 氏による tcpwrapper パッケージもサポートしています。 そのため /var/yp/securenets の代わりに tcpwrapper の設定ファイルを使ってアクセス制御を行なうことも可能です。

注記:

これらのアクセス制御機能は一定のセキュリティを提供しますが、 どちらも特権ポートのテストのような IP spoofing 攻撃に対して脆弱です。すべての NIS 関連のトラフィックはファイアウォールでブロックされるべきです。

/var/yp/securenets を使っているサーバは、古い TCP/IP 実装を持つ正当なクライアントへのサービスに失敗することがあります。 これらの実装の中にはブロードキャストのホストビットをすべて 0 でセットしてしまったり、 ブロードキャストアドレスの計算でサブネットマスクを見落としてしまったりするものがあります。 これらの問題にはクライアントの設定を正しく行なえば解決できるものもありますが、 問題となっているクライアントシステムを引退させるか、 /var/yp/securenets を使わないようにしなければならないものもあります。

このような古風な TCP/IP の実装を持つサーバで /var/yp/securenets を使うことは実に悪い考えであり、 あなたのネットワークの大部分において NIS の機能喪失を招きます。

tcpwrapper パッケージを使うとあなたの NIS サーバのレイテンシ (遅延) が増加します。特に混雑したネットワークや遅い NIS サーバでは、遅延の増加によって、 クライアントプログラムのタイムアウトが起こるかもしれません。 一つ以上のクライアントシステムがこれらの兆候を示したなら、 あなたは問題となっているクライアントシステムを NIS スレーブサーバにして自分自身に結び付くように強制すべきです。

22.9.6. 何人かのユーザのログオンを遮断する

わたしたちの研究室には basie という、 教員専用のマシンがあります。わたしたちはこのマシンを NIS ドメインの外に出したくないのですが、 マスタ NIS サーバの passwd ファイルには教員と学生の両方が載っています。 どうしたらいいでしょう?

当該人物が NIS のデータベースに載っていても、 そのユーザがマシンにログオンできないようにする方法があります。 そうするには -username をクライアントマシンの /etc/master.passwd ファイルの末尾に付け足します。 username はあなたがログインさせたくないと思っているユーザのユーザ名です。 これは vipw で行うべきです。 vipw/etc/master.passwd への変更をチェックし、編集終了後パスワードデータベースを再構築します。 たとえば、ユーザ billbasie にログオンするのを防ぎたいなら、以下のようにします。

basie# vipw
[add -bill to the end, exit]
vipw: rebuilding the database...
vipw: done

basie# cat /etc/master.passwd

root:[password]:0:0::0:0:The super-user:/root:/bin/csh
toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
operator:*:2:5::0:0:System &:/:/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
+:::::::::
-bill

basie#

22.9.7. ネットグループの利用

寄稿: Erdelhoff Udo [FAMILY Given].

前節までに見てきた手法は、 極めて少ないユーザ/マシン向けに個別のルールを必要としている場合にはうまく機能します。 しかし大きなネットワークでは、 ユーザに触られたくないマシンへログオンを防ぐのを 忘れるでしょう し、 そうでなくとも各マシンを個別に設定して回らなければならず、 集中管理という NIS の恩恵を失ってしまいます。

NIS の開発者はこの問題を ネットグループ と呼ばれる方法で解決しました。 その目的と意味合いは UNIX® のファイルシステムで使われている一般的なグループと比較できます。 主たる相違は数値 ID が存在しないことと、 ユーザアカウントと別のネットグループを含めたネットグループを定義できることです。

ネットグループは百人/台以上のユーザとマシンを含む、 大きく複雑なネットワークを扱うために開発されました。 あなたがこのような状況を扱わなければならないなら便利なものなのですが、 一方で、この複雑さは単純な例でネットグループの説明をすることをほとんど不可能にしています。 この節の残りで使われている例は、この問題を実演しています。

あなたの行なった、 研究室への NIS の導入の成功が上司の目に止ったとしましょう。 あなたの次の仕事は、あなたの NIS ドメインをキャンパスの他のいくつものマシンを覆うものへ拡張することです。 二つの表は新しいユーザと新しいマシンの名前とその説明を含んでいます。

ユーザの名前説明
alpha, betaIT 学科の通常の職員
charlie, deltaIT 学科の新しい見習い
echo, foxtrott, golf, ...一般の職員
able, baker, ...まだインターン
マシンの名前説明
war, death, famine, pollution最も重要なサーバ。IT 職員だけがログオンを許されます。
pride, greed, envy, wrath, lust, slothあまり重要でないサーバ。 IT 学科の全員がログオンを許されます。
one, two, three, four, ...通常のワークステーション。 本当の 職員だけがログオンを許されます。
trashcan重要なデータの入っていないひどく古いマシン。 インターンでもこのマシンの使用を許されます。

もしあなたがこの手の制限を各ユーザを個別にブロックする形で実装するなら、 あなたはそのシステムにログオンすることが許されていない各ユーザについて -user という 1 行を、各システムの passwd に追加しなければならなくなるでしょう。 もしあなたが 1 エントリでも忘れればトラブルに巻き込まれてしまいます。 最初のセットアップの時にこれを正しく行えるのはありえることかも知れませんが、 遂には連日の業務の間に例の行を追加し忘れてしまうでしょう。 結局マーフィーは楽観主義者だったのです。

この状況をネットグループで扱うといくつかの有利な点があります。 各ユーザを別個に扱う必要はなく、 ユーザを一つ以上のネットグループに割り当て、 ネットグループの全メンバのログインを許可したり禁止したりすることができます。 新しいマシンを追加するときはネットグループへログインの制限を定義するだけ、 新しいユーザを追加するときはそのユーザを一つ以上のネットグループへ追加するだけで、 それぞれ行なうことができます。 これらの変更は互いに独立なので、 ユーザとマシンの組合わせをどうするか は存在しなくなります。 あなたの NIS のセットアップが注意深く計画されていれば、 マシンへのアクセスを認めるにも拒否するにも中心の設定をたった一カ所変更するだけです。

最初のステップは NIS マップネットグループの初期化です。 FreeBSD の ypinit(8) はこのマップをデフォルトで作りませんが、 その NIS の実装はそれが作られさえすればそれをサポートするものです。 空のマップを作るには、単に

ellington# vi /var/yp/netgroup

とタイプして内容を追加していきます。 わたしたちの例では、すくなくとも IT 職員、IT 見習い、一般職員、 インターンの 4 つのネットグループが必要です。

IT_EMP  (,alpha,test-domain)    (,beta,test-domain)
IT_APP  (,charlie,test-domain)  (,delta,test-domain)
USERS   (,echo,test-domain)     (,foxtrott,test-domain) \
	(,golf,test-domain)
INTERNS (,able,test-domain)     (,baker,test-domain)

IT_EMP, IT_APP 等はネットグループの名前です。 それぞれの括弧で囲まれたグループが一人以上のユーザアカウントをそれに登録しています。 グループの 3 つのフィールドは

  1. その記述が有効なホスト (群) の名称。 ホスト名を特記しなければそのエントリはすべてのホストで有効です。 もしあなたがホスト名を特記するなら、 あなたは闇と恐怖と全き混乱の領域に入り込んでしまうでしょう。

  2. このネットグループに所属するアカウントの名称。

  3. そのアカウントの NIS ドメイン。 もしあなたが一つ以上の NIS ドメインの不幸な仲間なら、 あなたは他の NIS ドメインからあなたのネットグループにアカウントを導入できます。

各フィールドには、ワイルドカードが使えます。 詳細は netgroup(5) をご覧ください。

注記:

8 文字以上のネットグループ名は、特にあなたの NIS ドメインで他のオペレーティングシステムを走らせているときは使うべきではありません。 名前には大文字小文字の区別があります。 そのためネットグループ名に大文字を使う事は、 ユーザやマシン名とネットグループ名を区別する簡単な方法です。

(FreeBSD 以外の) NIS クライアントの中には 多数のエントリを扱えないものもあります。 たとえば SunOS™ の古い版では 15 以上の エントリ を含むネットグループはトラブルを起こします。 この制限は 15 ユーザ以下のサブネットグループをいくつも作り、 本当のネットグループはこのサブネットグループからなるようにすることで回避できます。

BIGGRP1  (,joe1,domain)  (,joe2,domain)  (,joe3,domain) [...]
BIGGRP2  (,joe16,domain)  (,joe17,domain) [...]
BIGGRP3  (,joe31,domain)  (,joe32,domain)
BIGGROUP  BIGGRP1 BIGGRP2 BIGGRP3

単一のネットグループに 225 人以上のユーザをいれたいときは、 このやり方を繰り返すことができます。

新しい NIS マップの有効化と配布は簡単です。

ellington# cd /var/yp
ellington# make

これで新しい 3 つの NIS マップ netgroup, netgroup.byhost, netgroup.byuser ができるはずです。 新しい NIS マップが利用できるか確かめるには ypcat(1) を使います。

ellington% ypcat -k netgroup
ellington% ypcat -k netgroup.byhost
ellington% ypcat -k netgroup.byuser

最初のコマンドの出力は /var/yp/netgroup の内容に似ているはずです。 2 番目のコマンドはホスト別のネットグループを作っていなければ出力されません。 3 番目のコマンドはユーザに対するネットグループのリストを得るのに使えます。

クライアント側の設定は非常に簡単です。 サーバ war を設定するには、 vipw(8) を実行して以下の行

+:::::::::

+@IT_EMP:::::::::

に入れ替えるだけです。

今、ネットグループ IT_EMP で定義されたユーザのデータだけが war のパスワードデータベースに読み込まれ、 そのユーザだけがログインを許されています。

残念ながらこの制限はシェルの ~ の機能や、 ユーザ名や数値の ユーザ ID の変換ルーチンにも影響します。 つまり、 cd ~user はうまく動かず、 ls -l はユーザ名のかわりに数値の ID を表示し find . -user joe -printNo such user で失敗します。 これを避けるためには、すべてのユーザのエントリを サーバにログインすることを許さずに 読み込まなければなりません。

これはもう一行を /etc/master.passwd に追加することで実現できます。その行は以下の

+:::::::::/sbin/nologin を含んでおり、 これは すべてのエントリを読み込むが、読み込まれたエントリのシェルは /sbin/nologin で置き換えられる ということを意味します。passwd エントリの他のフィールドを /etc/master.passwd の既定値から置き換えることも可能です。

警告:

+:::::::::/sbin/nologin の行が +@IT_EMP::::::::: の行より後ろに位置することに注意してください。 さもないと NIS から読み込まれた全ユーザが /sbin/nologin をログインシェルとして持つことになります。

この変更の後では、新しい職員が IT 学科に参加しても NIS マップを一つ書き換えるだけで済みます。 同様にして、あまり重要でないサーバのローカルの /etc/master.passwd のかつての +::::::::: 行を以下のように置き換えます。

+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/sbin/nologin

この行は、一般のワークステーションでは以下のようになります。

+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/sbin/nologin

これでしばらく順調に運用していましたが、 数週間後、ポリシに変更がありました。 IT 学科はインターンを雇い始め、IT インターンは一般のワークステーションと余り重要ではないサーバを使うことが許され、 IT 見習いはメインサーバへのログインが許されました。 あなたは新たなネットグループ IT_INTERN を追加して新しい IT インターンたちをそのグループに登録し、 すべてのマシンの設定を変えて回ることにしました。 古い諺にこうあります。 集中管理における過ちは、大規模な混乱を導く

いくつかのネットグループから新たなネットグループを作るという NIS の機能は、このような状況に対処するために利用できます。 その方法の一つは、役割別のネットグループを作ることです。 たとえば、重要なサーバへのログイン制限を定義するために BIGSRV というネットグループを作り あまり重要ではないサーバへは SMALLSRV というネットグループを、そして一般のワークステーション用に USERBOX という第 3 のネットグループを 作ることができます。これらのネットグループの各々は、 各マシンにログインすることを許されたネットグループを含みます。 あなたの NIS マップネットグループの新しいエントリは、 以下のようになるはずです。

BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP  ITINTERN
USERBOX   IT_EMP  ITINTERN USERS

このログイン制限の定義法は、 同一の制限を持つマシンのグループを定義できるときには便利なものです。 残念ながらこのようなケースは例外的なものです。 ほとんどの場合、 各マシンに基づくログイン制限の定義機能が必要となるでしょう。

マシンごとのネットグループの定義は、 上述したようなポリシの変更を扱うことができるもうひとつの方法です。 このシナリオでは、各マシンの /etc/master.passwd+ で始まる 2 つの行からなります。 最初のものはそのマシンへのログインを許されたアカウントを追加するもので、 2 番目はその他のアカウントを /sbin/nologin をシェルとして追加するものです。 マシン名をすべて大文字で記述したものをネットグループの名前として使うのは良い考えです。 言い換えれば、件の行は次のようになるはずです。

+@BOXNAME:::::::::
+:::::::::/sbin/nologin

一度、各マシンに対してこの作業を済ませてしまえば、 二度とローカルの /etc/master.passwd を編集する必要がなくなります。 以降のすべての変更は NIS マップの編集で扱うことができます。 以下はこのシナリオに対応するネットグループマップに、 いくつかの便利な定義を追加した例です。

# Define groups of users first
IT_EMP    (,alpha,test-domain)    (,beta,test-domain)
IT_APP    (,charlie,test-domain)  (,delta,test-domain)
DEPT1     (,echo,test-domain)     (,foxtrott,test-domain)
DEPT2     (,golf,test-domain)     (,hotel,test-domain)
DEPT3     (,india,test-domain)    (,juliet,test-domain)
ITINTERN  (,kilo,test-domain)     (,lima,test-domain)
D_INTERNS (,able,test-domain)     (,baker,test-domain)
#
# Now, define some groups based on roles
USERS     DEPT1   DEPT2     DEPT3
BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP    ITINTERN
USERBOX   IT_EMP  ITINTERN  USERS
#
# And a groups for a special tasks
# Allow echo and golf to access our anti-virus-machine
SECURITY  IT_EMP  (,echo,test-domain)  (,golf,test-domain)
#
# machine-based netgroups
# Our main servers
WAR       BIGSRV
FAMINE    BIGSRV
# User india needs access to this server
POLLUTION  BIGSRV  (,india,test-domain)
#
# This one is really important and needs more access restrictions
DEATH     IT_EMP
#
# The anti-virus-machine mentioned above
ONE       SECURITY
#
# Restrict a machine to a single user
TWO       (,hotel,test-domain)
# [...more groups to follow]

もしユーザアカウントを管理するのにデータベースの類を使っているなら、 データベースのレポートツールからマップの最初の部分を作れるようにするべきです。 そうすれば、新しいユーザは自動的にマシンにアクセスできるでしょう。

最後に使用上の注意を: マシン別のネットグループを使うことが常に賢明というわけではありません。 あなたが数ダースから数百の同一の環境のマシンを学生の研究室に配置しているのならば、 NIS マップのサイズを手頃な範囲に押さえるために、 マシン別のネットグループのかわりに役割別のネットグループを使うべきです。

22.9.8. 忘れてはいけないこと

NIS 環境にある今、 今までとは違ったやり方が必要なことがいくつかあります。

  • 研究室にユーザを追加するときは、それをマスター NIS サーバに だけ 追加しなければならず、さらに NIS マップを再構築することを忘れてはいけません。 これを忘れると新しいユーザは NIS マスタ以外のどこにもログインできなくなります。 たとえば、新しくユーザ jsmith をラボに登録したいときは以下のようにします。

    # pw useradd jsmith
    # cd /var/yp
    # make test-domain

    pw useradd jsmith のかわりに adduser jsmith を使うこともできます。

  • 管理用アカウントを NIS マップから削除してください。 管理用アカウントやパスワードを、 それらのアカウントへアクセスさせてはいけないユーザが居るかも知れないマシンにまで伝えて回りたいとは思わないでしょう。

  • NIS のマスタとスレーブをセキュアに、 そして機能停止時間を最短に保ってください。 もし誰かがこれらのマシンをクラックしたり、 あるいは単に電源を落としたりすると、 彼らは実質的に多くの人を研究室へログインできなくしてしまえます。

    これはどの集中管理システムにとってももっとも大きな弱点でしょう。 あなたの NIS サーバを守らなければ怒れるユーザと対面することになるでしょう!

22.9.9. NIS v1 との互換性

FreeBSD の ypserv は、 NIS v1 クライアントを部分的にサポートしています。 FreeBSD の NIS 実装は NIS v2 プロトコルのみを使用していますが、 ほかの実装では、古いシステムとの下位互換性を持たせるため v1 プロトコルをサポートしているものもあります。 そのようなシステムに付いている ypbind デーモンは、 必要がないにもかかわらず NIS v1 のサーバとの結合を成立させようとします (しかも v2 サーバからの応答を受信した後でも、 ブロードキャストをし続けるかも知れません)。 FreeBSD の ypserv は、 クライアントからの通常のリクエストはサポートしていますが、 v1 のマップ転送リクエストはサポートしていないことに注意してください。 つまり FreeBSD の ypserv を、 v1 だけをサポートするような古い NIS サーバと組み合わせて マスターやスレーブサーバとして使うことはできません。 幸いなことに、現在、そのようなサーバが使われていることは ほとんどないでしょう。

22.9.10. NIS クライアントとしても動作している NIS サーバ

複数のサーバが存在し、サーバ自身が NIS クライアントでもあるようなドメインで ypserv が実行される場合には注意が必要です。 一般的に良いとされているのは、 他のサーバと結合をつくるようにブロードキャストさせるのではなく、 サーバをそれ自身に結合させることです。 もし、サーバ同士が依存関係を持っていて、一つのサーバが停止すると、 奇妙なサービス不能状態に陥ることがあります。 その結果、すべてのクライアントはタイムアウトを起こして 他のサーバに結合しようと試みますが、 これにかかる時間はかなり大きく、 サーバ同士がまた互いに結合してしまったりすると、 サービス不能状態はさらに継続することになります。

ypbind-S オプションフラグを指定して実行することで、 ホストを特定のサーバに結合することが可能です。 NIS サーバを再起動するたびに、これを手動で行いたくないなら、 次の行を /etc/rc.conf に追加すればよいでしょう。

nis_client_enable="YES"	# run client stuff as well
nis_client_flags="-S NIS domain,server"

詳細については ypbind(8) を参照してください。

22.9.11. パスワード形式

NIS を実装しようする人の誰もがぶつかる問題の一つに、 パスワード形式の互換性があります。 NIS サーバが DES 暗号化パスワード使っている場合には、 同様に DES を使用しているクライアントしか対応できません。 たとえば Solaris™; の NIS クライアントがネットワーク内にある場合、 ほぼ確実に DES 暗号化パスワードを使用しなければならないでしょう。

サーバとクライアントがどのライブラリを使用しているかは、 /etc/login.conf を確認してください。 ホストが DES 暗号パスワードを使用するように設定されている場合、 default クラスには以下のようなエントリが含まれます。

default:\
    :passwd_format=des:\
    :copyright=/etc/COPYRIGHT:\
    [Further entries elided]

passwd_format 特性について他に利用可能な値は blf および md5 (それぞれ Blowfish および MD5 暗号化パスワード) です。

/etc/login.conf を変更したときは、 ログイン特性データベースも再構築しなければなりません。 これは root 権限で下記のようにコマンドを実行すればできます。

# cap_mkdb /etc/login.conf

注記:

すでに /etc/master.passwd 内に記録されているパスワード形式は、 ログイン特性データベースが再構築された、 ユーザが彼らのパスワードをはじめて変更するまで変更されないでしょう。

次に、 パスワードが選択した形式で暗号化されることを確実にするために、 さらに /etc/auth.conf 内の crypt_default において、 選択したパスワード形式に高い優先順位がついていることも確認してください。 そうするためには、選択した形式をリストの先頭に置いてください。 たとえば DES 暗号化されたパスワードを使用するときは、 エントリは次のようになります。

crypt_default	=	des blf md5

FreeBSD 上の各 NIS サーバおよびクライアントにおいて上記の手順に従えば、 ネットワーク内でどのパスワード形式が使用されるかが それらのマシン間で整合されているということを確信できます。 NIS クライアント上で問題があれば、 ここから問題となりそうな部分を探すと良いでしょう。 覚えておいてください: 異種混在ネットワークに NIS サーバを配置したいときには、 DES が最大公約数的な標準となるでしょうから、 すべてのシステムで DES を使用しなければならないかもしれません。

本文書、および他の文書は ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ からダウンロードできます。

FreeBSD に関する質問がある場合には、 ドキュメント を読んだ上で <questions@FreeBSD.org> まで (英語で) 連絡してください。

本文書に関する質問については、 <doc@FreeBSD.org> まで電子メールを (英語で) 送ってください。