原作: Bill Swingle <unfurl@FreeBSD.org>, 2000 年 1 月 21 日,
監修: Eric Ogren <eogren@earthlink.net>, Udo Erdelhoff
<ue@nathan.ruhr.de>, 2000 年 6
月.
NIS とは Network Information Services の略で Sun Microsystems によって Unix の (もともとは SunOS の) 集中管理のために開発されました。 現在では事実上の業界標準になっており、 主要な Unix は (Solaris、 HP-UX、 AIX、 Linux、 NetBSD、 OpenBSD、 FreeBSD、 等々) すべてこれをサポートしています。
NIS は元々、 イエローページ (または yp) として知られていましたが、 著作権を侵害しているとして Sun はその名を変えさせられました。
NIS は RPC を使ったクライアント/サーバシステムです。 これを使うと NISドメイン内のマシン間で、 共通の設定ファイルを共有することができます。 また、 NIS を使うことでシステム管理者は最小限の設定データで NIS クライアントを立ち上げることができ、 1 ヶ所から設定データの追加、 削除、 変更が可能です。
NIS は Windows NT のドメインシステムに似ています。 内部の実装は似ても似つかないものですが、 基本的な機能を 対比することはできます。
NIS サーバの立ち上げや NIS クライアントの設定など、 NIS を FreeBSD に導入するにあたって、 目にするであろう用語や重要なユーザプロセスがいくつかあります。
NIS ドメイン名. NIS マスターサーバ一つと そのクライアント (スレーブサーバを含む) は一つの NIS ドメイン名を 持ちます。 NT のドメイン名同様、 NIS ドメイン名は DNS とは何の関係もありません。
portmap. portmap は RPC (Remote Procedure Call、 NIS で使われるネットワークプロトコル) を利用するために実行しておかなければなりません。 portmap が動いていなければ、 NIS サーバの起動もクライアントとしての機能も得られません。
ypbind. ypbind は NIS クライアントを NIS サーバに“結び付け”ます。 これは NIS ドメイン名をシステムから受け、 RPC を用いてサーバに接続します。 ypbind はクライアントとサーバのコミュニケーションの中枢であり、 もしクライアントマシンの ypbind が機能を停止した場合は NIS サーバへアクセスできなくなります。
ypserv. ypserv は NIS サーバでのみ実行されるもので、 NIS のサーバプロセスそのものです。 ypserv が機能を停止したときは、 サーバは NIS リクエストに答えられなくなります (運が良ければ、 スレーブサーバがいて代わりを努めるでしょう)。
Note: 今まで使っていたサーバが機能を停止したとき、 別のサーバに再接続しに行かない NIS の実装もいくつかあります (FreeBSD のものは違います)。 そのような場合に復帰するための唯一の方法は、 サーバプロセス (あるいはサーバ全体)、 もしくはクライアントの ypbind プロセスを再スタートすることです。
rpc.yppasswdd. rpc.yppasswdd は NIS マスターサーバで動かされるべきもう一つのプロセスで、 NIS クライアントから NIS パスワードを変更させるデーモンです。 このデーモンが動いていないときは、 ユーザは NIS マスターサーバに login し、 そこでパスワードを変更することになります。
NIS 環境にあるホストは、 次の 3 種類に分類されます。 それは、 マスターサーバ、 スレーブサーバ、 クライアントです。 サーバは、 ホストの設定情報の中心的な情報格納庫の役割をします。 マスターサーバは元となる信頼できる情報を保持し、 スレーブサーバは、 冗長性を確保するため、 この情報をミラーします。 そしてクライアントは、 サーバから情報の提供を受けて動作します。
この方法を用いることで、 数多くのファイルにある情報が共有できます。 よく NIS で共有されるのは、 master.passwd や group、 hosts といったファイルです。 クライアント上のプロセスで、 通常ローカルのファイルにある情報が必要 となったとき、 クライアントは接続しているサーバに問い合わせを行い、 その情報を得ます。
NIS マスターサーバ. このサーバは Windows NT で言うところのプライマリ ドメインコントローラにあたります。 すべての NIS クライアントで利用されるファイルを保守し、 passwd や group、 その他 NIS クライアントが参照するファイルは、 マスターサーバにあります。
Note: 一つのマシンが一つ以上の NIS ドメインのマスターサーバになることは可能です。 しかし、 ここでは比較的小規模の NIS 環境を対象としているため、 そのような場合については扱いません。
NIS スレーブサーバ。 NT で言うところのバックアップドメインコントローラに似たもので、 NIS スレーブサーバは NIS マスターサーバのデータファイルのコピーを保持します。 NIS スレーブサーバは重要な環境で必要とされる冗長性を提供し、 マスターサーバの負荷のバランスをとります。 NIS クライアントは常に最初にレスポンスを返したサーバを NIS サーバとして接続しますが、 これにはスレーブサーバも含まれます。
NIS クライアント。 NIS クライアントは大部分の NT ワークステーションのように、 logon に際して NIS サーバに対して (NT ワークステーションの場合では NT ドメインコントローラに) 認証します。
この節では NIS 環境の立ち上げ例を取り上げます。
Note: この節ではあなたが FreeBSD 3.3 以降を使っているものとします。 ここで与えられる指示はおそらく FreeBSD の 3.0 以降の、 どのバージョンでも機能するでしょうが、 それを保証するものではありません。
あなたが大学の小さな研究室の管理人であるとしましょう。 この研究室は 15 台の FreeBSD マシンからなっていて、 現在はまだ集中管理されていません。 すなわち、 各マシンは /etc/passwd と /etc/master.passwd を各々が持っています。 これらのファイルは手動でお互いに同期させています。 つまり現時点では、 新しいユーザをあなたが追加するとき、 adduser を 15 ヶ所すべてで実行しなければなりません。 これは明らかに変える必要があるため、 あなたはこのうち 2 台をサーバにして NIS を導入することを決めました。
その結果、 研究室の設定はこのようなものになります:
| マシンの名前 | IP address | 役割 |
|---|---|---|
| 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 のドメイン名として使うものもあります (特に SunOS)。 あなたのネットワークにそのような制限のあるマシンが 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 のパスワードをクライアントのマシンから変更することを可能にします。
あと、 あなたがしなければいけないことはスーパユーザ権限でコマンド /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、 etc) をすべて削除しなければなりません。 またあなたが NIS クライアントに伝えたくないと思うアカウント (たとえば root や他の UID が 0 (スーパユーザ) のアカウント) についても削除する必要があります。
Note: /var/yp/master.passwd が グループや全世界から読めるようになっていないようにしてください (モード 600)! 必要なら chmod コマンドを 使ってください。
すべてが終わったらマップを初期化します! 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 のみからなる、 サーバが一つだけの 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 クライアントの設定は非常に単純です。
/etc/rc.conf ファイルを編集して以下の行を追加し、 ネットワークのセットアップ時に NIS ドメイン名をセットして ypbind を起動させます。
nisdomainname="test-domain" nis_client_enable="YES"
NIS サーバにあるすべてのパスワードエントリを取り込むため、 vipw コマンドで以下の行を /etc/master.passwd に追加します。
+:::::::::
Note: この行によって NIS サーバのパスワードマップにアカウントがある人全員にアカウントが与えられます。 この行を変更すると、 さまざまな NIS クライアントの設定を行なうことが可能です。 詳細は netgroups の部分を、 さらに詳しい情報については、 O'Reilly の Managing NFS and NIS をお読みください。
NIS サーバにあるすべてのグループエントリを取り込むため、 以下の行を /etc/group に追加します。
+:*::
上記の手順がすべて完了すれば、 ypcat passwd によって NIS サーバの passwd マップが参照できるようになっているはずです。
一般にドメイン名さえ知っていれば、 どこにいるリモートユーザでも ypserv に RPC を発行して NIS マップの内容を引き出すことができます。 こういった不正なやりとりを防ぐため、 ypserv には securenets と呼ばれる機能があります。 これはアクセスを決められたホストだけに制限する機能です。 ypserv は起動時に /var/yp/securenets ファイルから securenets に関する情報を読み込みます。
Note: 上記のパス名は、
-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 が上記のルールの一つと合致するアドレスからの要求を受け取った場合、 処理は通常に行なわれます。 もしアドレスがルールに合致しなければ、 その要求は無視されて警告メッセージがログに記録されます。 また、 /var/yp/securenets が存在しない場合、 ypserv はすべてのホストからの接続を受け入れます。
ypserv は Wietse Venema 氏による tcpwrapper パッケージもサポートしています。 そのため、 /var/yp/securenets の代わりに tcpwrapper の設定ファイルを使ってアクセス制御を行なうことも可能です。
Note: これらのアクセス制御機能は一定のセキュリティを提供しますが、 どちらも特権ポートのテストのような “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#
netgroups の部分の原作: Udo Erdelhoff <ue@nathan.ruhr.de>.
2000 年 7 月.
前節までに見てきた手法は, 極めて少ないユーザ/マシン向けに個別のルールを必要としている場合にはうまく機能します。 しかし大きなネットワークでは, ユーザに触られたくないマシンへログオンを防ぐのを忘れるでしょうし, そうでなくとも各マシンを個別に設定して回らなければならず、 集中管理という NIS の恩恵を失ってしまいます。
NIS の開発者はこの問題を netgroups と呼ばれる方法で解決しました。 彼らの目的とその意味合いは UNIX のファイルシステムで使われている一般的なグループと比較できます。 主たる相違は数字による id を欠いていることと、 ネットグループを定義するのにユーザアカウントと別のネットグループの、 両方を含められる機能です。
ネットグループは百人/台以上のユーザとマシンを含む、 大きく複雑なネットワークを扱うために開発されました。 もし、 あなたがこのような状況を扱わなければならないなら便利なものなのですが、 この複雑さは単純な例でネットグループの説明をすることをほとんど不可能にしています。 この部の残りで使われている例は、 この問題を実演しています。
あなたの行なった、 研究室への NIS の導入の成功が上司の目に止ったとしましょう。 あなたの次の仕事は、 あなたの NIS ドメインをキャンパスの他のいくつものマシンを覆うものへ拡張することです。 二つの表は新しいユーザと新しいマシンの名前とその説明を含んでいます。
| ユーザの名前 | 説明 |
|---|---|
| alpha, beta | IT 学科の通常の職員 |
| charlie, delta | IT 学科の新しい見習い |
| echo, foxtrott, golf, ... | 一般の職員 |
| able, baker, ... | まだインターン |
| マシンの名前 | 説明 |
|---|---|
| war, death, famine, polution | 最も重要なサーバ。 IT 職員だけがログオンを許されます。 |
| pride, greed, envy, wraith, lust, sloth | あまり重要でないサーバ。 IT 学科の全員がログオンを許されます。 |
| one, two, three, four, ... | 通常のワークステーション。 本当の 職員だけがログオンを許されます。 |
| trashcan | 重要なデータの入っていないひどく古いマシン。 インターンでもこのマシンの使用を許されます。 |
もしあなたがこの手の制限を各ユーザを個別にブロックする形で実装するなら、 あなたはそのシステムにログオンすることが許されていない各ユーザについて -user という 1 行を、 各システムのパスワードに追加しなければならなくなるでしょう。 もしあなたが 1 エントリでも忘れればトラブルに巻き込まれてしまいます。 最初のセットアップの時にこれを正しく行えるのはありえることかも知れませんが、 遂には連日の業務の間に例の行を追加し忘れてしまうでしょう。 結局マーフィーは楽観主義者だったのです。
この状況をネットグループで扱うといくつかの有利な点があります。 各ユーザを別個に扱う必要はなく、 ユーザを一つ以上のネットグループに割り当て、 ネットグループの全メンバのログインを許可したり禁止したりすることができます。 新しいマシンを追加するときはネットグループへログインの制限を定義するだけ、 新しいユーザを追加するときはそのユーザを一つ以上のネットグループへ追加するだけで、 それぞれ行なうことができます。 これらの変更は互いに独立なので、 “ユーザとマシンの組合わせをどうするか” は存在しなくなります。 あなたの NIS のセットアップが注意深く計画されていれば、 マシンへのアクセスを認めるにも拒否するにも中心の設定をたった一カ所変更するだけです。
最初のステップは NIS マップ netgroup の初期化です。 FreeBSD の ypinit はこのマップをデフォルトで作りませんが、 その 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) をご覧ください。
Note: 8 文字以上のネットグループ名は、 特にあなたの NIS ドメインで他のオペレーティングシステムを走らせているときは使うべきではありません。 名前には大文字小文字の区別があります。 そのためネットグループ名に大文字を使う事は、 ユーザやマシン名とネットグループ名を区別する簡単な方法です。
NIS クライアントの中には (FreeBSD 以外で) 多数のエントリを扱えないものもあります。 たとえば SunOS の古い版では 15 以上のエントリを含むネットグループはトラブルを起こします。 この制限は 15 ユーザ以下のサブ・ネットグループをいくつも作り、 本当のネットグループはこのサブ・ネットグループからなるようにすることで回避できます。
BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe32,domain) (,joe33,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 の既定値から置き換えることも可能です。
Warning+:::::::::/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 番目はその他のアカウントを/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 環境にある今、 今までとは違ったやり方が必要なことが 2、3 あります。
研究室にユーザを追加するときは、 それをマスター 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 を実装しようする人の誰もがぶつかる問題の一つに、 暗号ライブラリの互換性があります。 NIS サーバが DES 暗号ライブラリを使っている場合には、 同様に DES を使用しているクライアントしかサポートできません。 サーバとクライアントがどのライブラリを使用しているかは、 /usr/lib のシンボリックリンクを見ればわかります。 あるマシンが DES ライブラリを使うように設定されている場合、 リンクは以下のようになっています。
% ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libdescrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libdescrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libdescrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libdescrypt_p.a -r--r--r-- 1 root wheel 13018 Nov 8 14:27 /usr/lib/libdescrypt.a lrwxr-xr-x 1 root wheel 16 Nov 8 14:27 /usr/lib/libdescrypt.so@ -> libdescrypt.so.2 -r--r--r-- 1 root wheel 12965 Nov 8 14:27 /usr/lib/libdescrypt.so.2 -r--r--r-- 1 root wheel 14750 Nov 8 14:27 /usr/lib/libdescrypt_p.a
マシンが FreeBSD の標準の MD5 暗号ライブラリを使うように 設定されている場合には、 以下のようになります。
% ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libscrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libscrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libscrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libscrypt_p.a -r--r--r-- 1 root wheel 6194 Nov 8 14:27 /usr/lib/libscrypt.a lrwxr-xr-x 1 root wheel 14 Nov 8 14:27 /usr/lib/libscrypt.so@ -> libscrypt.so.2 -r--r--r-- 1 root wheel 7579 Nov 8 14:27 /usr/lib/libscrypt.so.2 -r--r--r-- 1 root wheel 6684 Nov 8 14:27 /usr/lib/libscrypt_p.a
NIS クライアントの認証でトラブルが発生した場合には、 ここから問題となりそうな部分を探すと良いでしょう。 NIS サーバを異種混在ネットワークに配置したいときは DES が最大公約数となるでしょうから、 すべてのシステムで DES を使わなければいけなくなるでしょう。