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® のドメインシステムに似ています。 内部の実装は似ても似つかないものですが、 基本的な機能を対比することはできます。
NIS サーバの立ち上げや NIS クライアントの設定など、 NIS を FreeBSD に導入するにあたって、 目にするであろう用語や重要なユーザプロセスがいくつかあります。
| 用語 | 説明 |
|---|---|
| NIS ドメイン名 | NIS マスタサーバとそのクライアントすべて (スレーブサーバを含む) には NIS ドメイン名がついています。 Windows�NT ドメイン名と同様に、NIS ドメイン名は DNS とは何の関係もありません。 |
| portmap | RPC (Remote Procedure Call, NIS で使用されるネットワークプロトコル) を利用するために実行しておかなければなりません。 portmap が動作していなければ、 NIS サーバを起動することも、 NIS クライアントとして動作させることもできません。 |
| ypbind | NIS クライアントを NIS サーバに “結びつけ” ます。 これは NIS ドメイン名をシステムから取得し RPC を用いてサーバに接続します。ypbind は NIS 環境におけるクライアントとサーバ間の通信の中枢です。 クライアントマシンの ypbind が停止した場合は、NIS サーバへアクセスすることができなくなります。 |
| ypserv | は NIS サーバでのみ実行されるべきもので、 NIS サーバプロセスそのものです。ypserv(8) が停止した場合、サーバはもはや NIS リクエストに応答することができなくなるでしょう (できれば、後を引き継ぐスレーブサーバがあるとよいでしょう)。 今まで使っていたサーバが機能を停止したとき、 別のサーバに再接続しに行かない NIS の実装もいくつかあります (FreeBSD のものは違います)。 そのような場合に復帰するための唯一の方法は、 サーバプロセス (あるいはサーバ全体)、もしくはクライアントの ypbind プロセスを再スタートすることです。 |
| rpc.yppasswdd | NIS マスターサーバで動かすべき、 もう一つのプロセスです。これは NIS クライアントが NIS パスワードを変更することを可能にするデーモンです。 このデーモンが動作していないときは、 ユーザは NIS マスタサーバにログインし、 そこでパスワードを変更しなければなりません。 |
NIS 環境にあるホストは、 マスターサーバ、スレーブサーバ、クライアントの 3 種類に分類されます。 サーバは、ホストの設定情報の中心的な情報格納庫の役割をします。 マスターサーバは元となる信頼できる情報を保持し、 スレーブサーバは冗長性を確保するためこの情報をミラーします。 そしてクライアントは、サーバから情報の提供を受けて動作します。
この方法を用いることで、数多くのファイルにある情報が共有できます。 よく NIS で共有されるのは、 master.passwd や group, hosts といったファイルです。 クライアント上のプロセスが、 通常ならローカルのファイルにある情報を必要とするときは、 クライアントは代わりに接続している NIS サーバに問い合わせを行います。
NIS マスターサーバ。 このサーバは Windows�NT で言うところのプライマリドメインコントローラにあたります。 すべての NIS クライアントで利用されるファイルを保守します。 passwd や group、 その他 NIS クライアントが参照するファイルは、 マスターサーバにあります。
注意: 一つのマシンが一つ以上の NIS ドメインのマスターサーバになることは可能です。 しかし、ここでは比較的小規模の NIS 環境を対象としているため、 そのような場合については扱いません。
NIS スレーブサーバ。 Windows�NT のバックアップドメインコントローラに似たもので、 NIS スレーブサーバは NIS マスターサーバのデータファイルのコピーを保持します。 NIS スレーブサーバは重要な環境で必要とされる冗長性を提供し、 マスターサーバの負荷のバランスをとります。 NIS クライアントは常に最初にレスポンスを返したサーバを NIS サーバとして接続しますが、 これにはスレーブサーバも含まれます。
NIS クライアント。 NIS クライアントは大部分の Windows�NT ワークステーションのように、ログオンに際して NIS サーバ (Windows�NT ワークステーションの場合は Windows�NT ドメインコントローラ) に接続して認証します。
この節では NIS 環境の立ち上げ例を取り上げます。
注意: この節ではあなたが FreeBSD�3.3 以降を使っているものとします。 ここで与えられる指示は おそらく FreeBSD の 3.0 以降のどのバージョンでも機能するでしょうが、 それを保証するものではありません。
あなたが大学の小さな研究室の管理人であるとしましょう。 この研究室は 15 台の FreeBSD マシンからなっていて、 現在はまだ集中管理されていません。 すなわち、各マシンは /etc/passwd と /etc/master.passwd を各々が持っています。 これらのファイルは手動でお互いに同期させています。 つまり現時点では、新しいユーザをあなたが追加するとき、 adduser を 15 ヶ所すべてで実行しなければなりません。 これは明らかに変える必要があるため、 あなたはこのうち 2 台をサーバにして NIS を導入することを決めました。
その結果、研究室の設定はこのようなものになります。
| マシンの名前 | IP アドレス | 役割 |
|---|---|---|
| ellington | 10.0.0.2 | NIS マスタ |
| coltrane | 10.0.0.3 | NIS スレーブ |
| basie | 10.0.0.4 | 教員用のワークステーション |
| bird | 10.0.0.5 | クライアントマシン |
| cli[1-11] | 10.0.0.[6-17] | その他のクライアントマシン |
もし NIS によるシステム管理の設定を行なうのが初めてなら、 どのようにしたいのか、 ひととおり最後まで考えてみることをお勧めします。 ネットワークの規模によらず、 いくつか決めるべきことがあるからです。
ここでいうドメイン名は、今まであなたが使っていた、 いわゆる “ドメイン名” と呼んでいたものとは違います。 正確には “NIS ドメイン名” と呼ばれます。 クライアントがサーバに情報を要求するとき、 その要求には自分が属する NIS ドメインの名前が含まれています。 これは 1 つのネットワークに複数のサーバがある場合に、 どのサーバが要求を処理すれば良いかを決めるために使われます。 NIS ドメイン名とは、 関連のあるホストをグループ化するための名前である、 と考えると良いでしょう。
組織によってはインターネットのドメイン名を NIS ドメイン名に使っているところがあります。 これはネットワークのトラブルをデバッグするときに混乱の原因となるため、 お勧めできません。 NIS ドメイン名はネットワーク内で一意なければいけません。そして、 ドメイン名がドメインに含まれるマシンを表すようなものであれば分かり易いです。 たとえば Acme 社のアート (Art) 部門であれば NIS ドメイン名を “acme-art” とすれば良いでしょう。この例では NIS ドメイン名として test-domain を使用します。
しかしながらオペレーティングシステムによっては (特に SunOS)、 NIS ドメイン名をネットワークドメイン名として使うものもあります。 あなたのネットワークにそのような制限のあるマシンが 1 台でもあるときは、NIS のドメイン名としてインターネットのネットワークドメイン名を使わなければ いけません。
NIS サーバとして使うマシンを選ぶ際には、 いくつか注意すべき点があります。 NIS に関する困ったことの一つに、 クライアントのサーバへの依存度があります。 クライアントが自分の NIS ドメインのサーバに接続できないと、 マシンが使用不能になることがあまりに多いのです。 もし、ユーザやグループに関する情報が得られなければ、 ほとんどのシステムは一時的に停止してしまいます。 こういったことを念頭に置いて、頻繁にリブートされるマシンや、 開発に使われそうなマシンを選ばないようにしなければなりません。 理想的には NIS サーバはスタンドアロンで NIS サーバ専用のマシンにするべきです。 ネットワークの負荷が重くなければ、 他のサービスを走らせているマシンを NIS サーバにしてもかまいません。 ただし NIS サーバが使えなくなると、 すべての クライアントに影響をおよぼす、 という点には注意しなければなりません。
元となるすべての NIS 情報は、 NIS マスターサーバと呼ばれる 1 台のマシンに格納されます。 この情報が格納されるデータベースを NIS マップと呼びます。 FreeBSD では、このマップは /var/yp/[domainname] に置かれます。 [domainname] は、 サーバがサービスする NIS ドメインです。 1 台の NIS サーバが複数のドメインをサポートすることも可能です。 つまり、このディレクトリを各々のドメインごとに作ることができます。 それぞれのドメインは、 独立したマップの集合を持つことになります。
NIS のマスターサーバとスレーブサーバ上では、 ypserv デーモンがすべての NIS 要求を処理します。 ypserv は NIS クライアントからの要求を受け付け、 ドメイン名とマップ名を対応するデータベースファイルへのパスに変換し、 データをクライアントに返送します。
やりたいことにもよりますが NIS マスターサーバの設定は比較的単純です。 FreeBSD は初期状態で NIS に対応しています。 必要なのは以下の行を /etc/rc.conf に追加することだけで、 あとは FreeBSD がやってくれます。
nisdomainname="test-domain"この行はネットワークの設定後に (たとえば再起動後に) NIS のドメイン名を test-domain に設定します。
nis_server_enable="YES"これは FreeBSD に次にネットワークが立ち上がったとき NIS のサーバプロセスを起動させます。
nis_yppasswdd_enable="YES"これは rpc.yppasswdd デーモンを有効にします。上述したようにこれはユーザが NIS のパスワードをクライアントのマシンから変更することを可能にします。
注意: NIS の設定によっては、 さらに他のエントリを付け加える必要があるかもしれません。 詳細については、下記の NIS クライアントとしても動作している NIS サーバ 節を参照してください。
さて、あとはスーパユーザ権限で /etc/netstart コマンドを実行するだけです。 これにより /etc/rc.conf で定義された値を使ってすべての設定が行なわれます。
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"
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 サーバを再起動してください。
NIS クライアントは ypbind デーモンを使って、特定の NIS サーバとの間に結合 (binding) と呼ばれる関係を成立させます。 ypbind はシステムのデフォルトのドメイン (domainname コマンドで設定されます) を確認し、RPC 要求をローカルネットワークにブロードキャストします。 この RPC 要求により ypbind が結合を成立させようとしているドメイン名が指定されます。 要求されているドメイン名に対してサービスするよう設定されたサーバが ブロードキャストを受信すると、 サーバは ypbind に応答しypbind は応答のあったサーバのアドレスを記録します。複数のサーバ (たとえば一つのマスターサーバと、複数のスレーブサーバ) が利用可能な場合、ypbind は、 最初に応答したサーバのアドレスを使用します。 これ以降、クライアントのシステムは、 すべての NIS の要求をそのサーバに向けて送信します。 ypbind は、 サーバが順調に動作していることを確認するため、 時々 “ping” をサーバに送ります。 反応が戻ってくるべき時間内に ping に対する応答が来なければ、 ypbind は、そのドメインを結合不能 (unbound) として記録し、別のサーバを見つけるべく、 再びブロードキャストパケットの送信を行います。
FreeBSD マシンを NIS クライアントにする設定は非常に単純です。
ネットワークの起動時に NIS ドメイン名を設定して ypbind を起動させるために /etc/rc.conf ファイルを編集して以下の行を追加します。
nisdomainname="test-domain" nis_client_enable="YES"
NIS サーバから、 利用可能なパスワードエントリをすべて取り込むため、 /etc/master.passwd からすべてのユーザアカウントを取り除いて、 vipw コマンドで以下の行を /etc/master.passwd の最後に追加します。
+:::::::::
注意: この行によって NIS サーバのパスワードマップにアカウントがある人全員にアカウントが与えられます。 この行を変更すると、 さまざまな NIS クライアントの設定を行なうことが可能です。 詳細は ネットグループ を、さらに詳しい情報については、O'Reilly の Managing NFS and NIS を参照してください。
注意: /etc/master.passwd 内に少なくとも一つのローカルアカウント (つまり NIS 経由でインポートされていないアカウント) を置くべきです。 また、このアカウントは wheel グループのメンバーであるべきです。 NIS がどこか調子悪いときには、 リモートからこのアカウントでログインし、 root になって修復するのに利用できます。
NIS サーバにあるすべてのグループエントリを取り込むため、 以下の行を /etc/group に追加します。
+:*::
上記の手順がすべて完了すれば、 ypcat passwd によって NIS サーバの passwd マップが参照できるようになっているはずです。
一般にドメイン名さえ知っていれば、 どこにいるリモートユーザでも 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 スレーブサーバにして自分自身に結び付くように強制すべきです。
わたしたちの研究室には basie という、 教員専用のマシンがあります。わたしたちはこのマシンを NIS ドメインの外に出したくないのですが、 マスタ NIS サーバの passwd ファイルには教員と学生の両方が載っています。 どうしたらいいでしょう?
当該人物が NIS のデータベースに載っていても、 そのユーザがマシンにログオンできないようにする方法があります。 そうするには -username をクライアントマシンの /etc/master.passwd ファイルの末尾に付け足します。 username はあなたがログインさせたくないと思っているユーザのユーザ名です。 これは vipw で行うべきです。 vipw は /etc/master.passwd への変更をチェックし、編集終了後パスワードデータベースを再構築します。 たとえば、ユーザ bill が basie にログオンするのを防ぎたいなら、以下のようにします。
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#
前節までに見てきた手法は、 極めて少ないユーザ/マシン向けに個別のルールを必要としている場合にはうまく機能します。 しかし大きなネットワークでは、 ユーザに触られたくないマシンへログオンを防ぐのを 忘れるでしょう し、 そうでなくとも各マシンを個別に設定して回らなければならず、 集中管理という NIS の恩恵を失ってしまいます。
NIS の開発者はこの問題を ネットグループ と呼ばれる方法で解決しました。 その目的と意味合いは UNIX のファイルシステムで使われている一般的なグループと比較できます。 主たる相違は数値 ID が存在しないことと、 ユーザアカウントと別のネットグループを含めたネットグループを定義できることです。
ネットグループは百人/台以上のユーザとマシンを含む、 大きく複雑なネットワークを扱うために開発されました。 あなたがこのような状況を扱わなければならないなら便利なものなのですが、 一方で、この複雑さは単純な例でネットグループの説明をすることをほとんど不可能にしています。 この節の残りで使われている例は、この問題を実演しています。
あなたの行なった、 研究室への NIS の導入の成功が上司の目に止ったとしましょう。 あなたの次の仕事は、あなたの NIS ドメインをキャンパスの他のいくつものマシンを覆うものへ拡張することです。 二つの表は新しいユーザと新しいマシンの名前とその説明を含んでいます。
| ユーザの名前 | 説明 |
|---|---|
| alpha, beta | IT 学科の通常の職員 |
| charlie, delta | IT 学科の新しい見習い |
| 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 つのフィールドは
その記述が有効なホスト (群) の名称。 ホスト名を特記しなければそのエントリはすべてのホストで有効です。 もしあなたがホスト名を特記するなら、 あなたは闇と恐怖と全き混乱の領域に入り込んでしまうでしょう。
このネットグループに所属するアカウントの名称。
そのアカウントの 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 -print は “No 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 マップのサイズを手頃な範囲に押さえるために、 マシン別のネットグループのかわりに役割別のネットグループを使うべきです。
NIS 環境にある今、 今までとは違ったやり方が必要なことがいくつかあります。
研究室にユーザを追加するときは、それをマスター NIS サーバに だけ 追加しなければならず、さらに NIS マップを再構築することを忘れてはいけません。 これを忘れると新しいユーザは NIS マスタ以外のどこにもログインできなくなります。 たとえば、新しくユーザ “jsmith” をラボに登録したいときは以下のようにします。
# pw useradd jsmith # cd /var/yp # make test-domain
pw useradd jsmith のかわりに adduser jsmith を使うこともできます。
管理用アカウントを NIS マップから削除してください。 管理用アカウントやパスワードを、 それらのアカウントへアクセスさせてはいけないユーザが居るかも知れないマシンにまで伝えて回りたいとは思わないでしょう。
NIS のマスタとスレーブをセキュアに、 そして機能停止時間を最短に保ってください。 もし誰かがこれらのマシンをクラックしたり、 あるいは単に電源を落としたりすると、 彼らは実質的に多くの人を研究室へログインできなくしてしまえます。
これはどの集中管理システムにとってももっとも大きな弱点でしょう。 あなたの NIS サーバを守らなければ怒れるユーザと対面することになるでしょう!
FreeBSD の ypserv は、 NIS v1 クライアントを部分的にサポートしています。 FreeBSD の NIS 実装は NIS v2 プロトコルのみを使用していますが、 ほかの実装では、古いシステムとの下位互換性を持たせるため v1 プロトコルをサポートしているものもあります。 そのようなシステムに付いている ypbind デーモンは、 必要がないにもかかわらず NIS v1 のサーバとの結合を成立させようとします (しかも v2 サーバからの応答を受信した後でも、 ブロードキャストをし続けるかも知れません)。 FreeBSD の ypserv は、 クライアントからの通常のリクエストはサポートしていますが、 v1 のマップ転送リクエストはサポートしていないことに注意してください。 つまり FreeBSD の ypserv を、 v1 だけをサポートするような古い 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) を参照してください。
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> まで電子メールを (英語で)
送ってください。