NISを効果的に利用するには
NISのすばらしい特徴の1つは、普通の人にも理解できることである。NISは各種ファイルをあちこちにコピーするのに似ていて、ほとんどの場合は管理者がNISの内部データ形式を意識する必要はない。管理は旧来と同じフラットファイルを用いて行われ、習得が必要な新しい手順はほんの1つか2つしかない。
NISドメインどうしをつなげることはできないので、すべてのマシンに同じ設定を適用するのでない限り、NISは大規模なネットワークの管理には向いていない。大規模なネットワークを複数のNISドメインに分割することは可能だが、各ドメインを別々に管理しなければならなくなる。また、たとえ大規模なネットワークの全体で同一の設定を用いる場合でも、スレーブサーバのスケーリングに対する制限から、実際にはNISサーバ間の同期をとるための別の仕組みをこれらのサイトに用意するのが普通である。結局、多くの場合、独自のバックエンドデータベースを稼働させ、各NISサーバにはこのセントラルソースからデータの取得を行わせることになる。
マップの変更時にスレーブサーバがダウンしているかアクセスできない場合、このスレーブのコピーは更新されない。各スレーブは定期的にマスターサーバにポーリングを行い、持っているマップがすべて最新のものであることを確認しなければならない。ポーリング用の基本的なツールはNISとともに提供されるとはいえ、自らの求めるポーリングのスキームはcronを使って自分で実装しなければならない。たとえそうしても、場合によっては1つのマップに対して2つの異なるバージョンがしばらく同時に提供される可能性があり、各クライアントはどちらかをランダムに参照することになってしまう。
NISは最低限のセキュリティしか提供しない。ブロードキャストモードは特にひどく、ネットワーク上の任意のホストが特定のドメインへのサービス提供を要求したり、NISクライアントに偽の管理データを与えたりすることができる。この問題は、許容可能なNISサーバをクライアントごとに明示的に列挙することで回避できる。
サーバのマップを参照できるホストを、明示的に/etc/ypserv.confファイルにリストすることにより、制限することは可能だが、この方法は100％安全とは言えない。その他の方法（rdistまたはrsync）を用いたシャドウパスワードファイルの配布によってシステムのセキュリティを向上させることもできるが、我々はNISを利用したシャドウパスワードの配布を推奨しない。
またLinux NISの以前のバージョンには既知のセキュリティホールが存在するので、古いシステムを実行している場合は、NISを起動する前に必ず最新の更新を入手する必要がある。
管理情報ソースの優先順位付け
設定情報はいくつかの方法で配布することができる。いかなるシステムもフラットファイルの内容を理解し、DNSを利用したホスト名およびインターネットアドレスの取得方法を知っている。また大半のシステムはNISについても理解している。所与の情報はいくつかのソースの候補から提供される可能性があるため、Linuxにはチェックすべきソースとチェックを行う順序を指定する方法が用意されている。
NISの元来（Linux以前）の実装では、一部の設定ファイル（具体的には/etc/passwdと/etc/group）を対応するNISマップの内容に「呼び込む」設定を行わなければならなかった。この操作は、そうしたファイル自体の中に特殊な宣言を含めることで拡張された。行頭に”+”だけを記述するとNISマップ全体が、”+@netgroup“のように記述すると特定のネットグループに関連するエントリだけが、また”+name“のようにすると単独のエントリがそれぞれ含まれることになる。
この方法は決して好評ではなかったため、集約された設定ファイル/etc/nsswitch.confに取って代わられている。このファイルでは、管理情報のタイプごとに検索パスを明示的に指定できる。元来のNISの動作は、互換性モードを使用すればエミュレート可能だが、新しく構築するネットワークでこの機能を使うことははおそらくないだろう （残念ながら、大半のディストリビューションではこのエミュレーションがデフォルトになっている）。
通常、nsswitch.confファイルの内容は次のようになっている。
passwd: files nis hosts: files dns group: files ...
それぞれの行では、情報の1つのタイプ（通常は1つのフラットファイルに相当）の設定を行う。代表的なソースとしてnis、nisplus、files、dns、compatがあり、それぞれNIS、NIS+、普通のフラットファイル（”+”などのトークンを無視）、DNS、NIS化されたフラットファイル（”+”を考慮）を表している。なおDNSは、ホストおよびネットワークの情報でのみ有効なデータソースである。
各ソースタイプは共有ライブラリ（/lib/libnss*）によってサポートされるため、サポートされるソースはディストリビューションによっていくらか異なる。一部のディストリビューションでは、LDAP（抜粋元の520ページを参照）と、DNSベースのディレクトリサービスHesiodの双方またはどちらかが最初からサポートされている。よくLinuxでサポートされる（残念ながら十分な文書化は行われていない）もう1つのソースがdbで、これは/var/db（たとえば/var/db/passwd.db）からハッシュ化されたマップの読み取りを行う。フラットファイルのサイズが大きい場合は、こうしたハッシュ版の利用によって検索速度を大幅に向上することができる。
各ソースに対する検索の試行は左に記されているものから順に行われ、ソースのいずれかによってクエリに対する回答が得られるまで続けられる。上記の例では、gethostbynameルーチンがまず/etc/hostsファイルをチェックし、該当するホストがそこにリストされていなかった場合は続いてDNSのチェックを行う。これに対し、UNIXのグループに関するクエリでは/etc/groupファイルだけがチェックされる。
必要であれば、ソースの後ろに角カッコで囲んだ式を記述することによって、ソースの「失敗（failure）」を定義することができる。たとえば、
hosts: dns [NOTFOUND=return] nis
と記述すると、利用可能な場合に限ってDNSが使用され、ネームサーバから否定的応答があったときにはNISのチェックを行わずにすぐに（失敗コードとともに）クエリを返す。ただし、ネームサーバが利用できない場合にはNISが用いられる。以下に、さまざまな失敗のタイプを示す。各タイプにはreturn（復帰）またはcontinue（継続）を設定して、クエリの実行を中断するのか次のソースに進むのかを指示することができる。
/etc/nsswitch.confで識別される失敗モード|
条件 |
意味 |
|
UNAVAIL |
ソースが存在しないかダウンしている。 |
|
NOTFOUND |
ソースは存在するがクエリに回答できない。 |
|
TRYAGAIN |
ソースは存在するがビジー状態にある。 |
|
SUCCESS |
ソースがクエリに対して回答できた。 |
どのLinuxディストリビューションにも、NISを利用しないスタンドアロンのマシンに合わせたnsswitch.confファイルがデフォルトで用意されている。ホスト検索を除くすべてのエントリはフラットファイルを参照し、ホスト検索ではまずフラットファイル、続いてDNSに対する問い合わせを行う。ほとんどのディストリビューションはデフォルトでpasswdおよびgroupがcompatモードになっているが、この部分は変更する価値があるだろう。本当にNISを使用するのなら、この設定はnsswitch.confファイルで明示的に行うだけで済むためである。
DebianやDebianとの関連が深いUbuntuでは、各種のプロトコル、サービス、イーサネット、RPCがdbの後にファイルを参照するようになっているが、これは少し奇妙なことである。というのも、実はDebianやUbuntuには/var/dbもそれを管理する仕組みも存在しないからである。直接ファイルを参照するほうがいくらか効率的に思われるので、必要ならそのように設定を変更するとよい。
ネットグループの利用
NISによって、ネットグループというよく知られた抽象化の概念が導入された。ネットグループは、他のシステムファイルにおける参照を容易にするために、ユーザ、マシン、ネットの各集合に名前を与える。それらは/etc/netgroupファイルに定義され、NISマップとしても共有される。
netgroupのエントリは、次のような形式になっている。
groupname list-of-members
それぞれの要素は空白で区切られ、各要素はネットグループ名か次の3つ組のどちらかである。
(hostname, username, nisdomainname)
3つ組内の空のフィールドはワイルドカードを表す。したがって”(boulder,,)”というエントリはboulderというホスト上のすべてのユーザおよびドメイン（あるいは、このネットグループが使われる状況によってはboulderというホストそのもの）を表す。フィールド内のダッシュ”-“は否定を意味する。よって”(boulder,-,)”というエントリの場合、boulderというマシンは含まれるがユーザは一切含まれない。なお、ネットグループの定義はネストさせることができる。
以下に/etc/netgroupファイルの簡単な例を示す。
bobcats (snake,,) (headrest,,) servers (anchor,,) (moet,,) (piper,,) (kirk,,) anchorclients (xx,,) (watneys,,) (molson,,) beers (anchor,,) (anchor-gateway,,) anchorclients allhosts beers bobcats servers
これらのネットグループはすべてホストに関する定義が行われているが、実世界でネットグループを用いる場合はそうするのが普通である。
ネットグループは、パーミッションを定義するいくつかのシステムファイルで使用することができる。最近、ネットグループが非常によく利用されるのがNFSエクスポートの設定である。ネットグループは、各ファイルシステムのマウントを許されたホストのグループを指定するための/etc/exportsファイル内に記述できる。このことは、多数のホストをエクスポートする場合、とりわけドメイン名の完全な指定が求められ、exportsファイルの行あたりの文字数が1024に制限されているシステムでは、とても役に立つ。
ネットグループはすばらしいアイデアである。システムファイルの内容が簡素化され、より理解しやすいものになる。またネットグループは、ユーザまたはマシンのステータスを15ものファイルではなく、わずか1つのファイルの変更で済ませることを許す間接レイヤも追加してくれる。
NISドメインの設定
NISの初期化は、マスターサーバ、スレーブサーバ、各クライアントのそれぞれで行わねばならない。この初期化は2つの段階に分けて行う。まずは、それぞれのサーバでypinitを実行する。次に、ドメイン内のすべてのマシンで/etc/domainnameまたはシステム起動ファイルの1つに記されたドメイン名を設定し、NISデータをインポートするように/etc/nsswitch.confの設定を行う。
通常、NISのサーバ側は別途ypservというオプションのパッケージとしてインストールされなければならない。ただし、DebianとUbuntuの場合は少々事情が異なり、nisパッケージにはクライアント側とサーバ側の両方が含まれる。
ypinitはドメインのマスターサーバおよびスレーブサーバの双方に対して初期化を実施する。マスタ側では、次のようなコマンドを実行する。
|
# cd /var/yp |
/* NISディレクトリの場所 */ |
|
|
# domainname foo |
/* 新しいドメインに名前を付ける */ |
|
|
# /usr/lib/yp/ypinit -m |
/* マスターサーバとして初期化 */ |
|
|
# ypserv |
/* NISサーバを起動 */ |
|
-mフラグによって、ypinitにはマスターサーバの設定を行うことが知らされる。この場合はスレーブサーバのリストを入力するように求められる。マスターサーバが起動して稼働している状態になったら、今度は -s（スレーブ）フラグを指定してypinitを実行することで、主要なスレーブサーバの初期化を行う。
# cd /var/yp # /usr/lib/yp/ypinit -s master /* 引数はマスターサーバのホスト名 */ # ypserv
ypinit -sを実行すると、マスターサーバが持つ現在のデータのローカルコピーが作られる。ドメインのデータファイルの存在により、マスターサーバがこのドメインにサービスを提供することがypservに知らされる。
各スレーブサーバでは、マスターサーバからすべてのマップの新しいコピーを取得するように、crontabエントリを設定する必要がある。コマンドypxfr map（mapの部分にはpasswd.byuidのような名前が入る）は、指定されたマップをマスターサーバから転送する。このコマンドは、マップごとに1回ずつ実行しなければならない。マップの変更頻度はそれぞれに異なる傾向があり、一部のマップは他のものより頻繁に転送する必要があるかもしれない。ほとんどの状況では、全マップの転送を1日に1、2回（おそらくは深夜に）行えば十分だろう。以下に、すべてのマップを転送するスクリプトを示す。
#!/bin/sh mydomain = '/bin/domainname' cd /var/yp/$mydomain # the NIS directory for map in '/bin/ls'; do /usr/lib/yp/ypxfr $map done
また/usr/lib/ypには、NISマップをさまざまな頻度で転送するスクリプト群（ypxfr_1perday、ypxfr_2perday、ypxfr_1perhour）が予め用意されている。
ユーザがyppasswdを使って各自のパスワードを変更できるようにする場合は、NISのマスターサーバでyppasswddデーモンを実行せねばならない。このデーモンのLinux版はよくクラッシュすることで知られているため、yppasswdコマンドが機能していないと思われる場合はこのデーモンが実行中かどうかを必ず検証する必要がある。
/etc/ypserv.confにおけるアクセス制御オプションの設定
Linux版のypservデーモンのオプションは/etc/ypserv.confで設定できるが、定義されるオプションはごくわずかで、大半のサイトではそれぞれのデフォルト値のままで問題ないだろう。
もっと重要なのは、ypservがNISデータへのアクセスの制御方法についての指示を求めてypserv.confファイルを参照することである。Linux版のypservは、従来の実装のように、受け取ったどのクエリに対してもいきなり回答を出すことはなく、アクセスリストを参照しながら入ってくる要求をチェックする。それぞれのコントロール行は次のような形をとる。
host:nisdomain:map:security
host、nisdomain、mapの各パラメータは要求の具体的なサブセットを指定するもので、securityパラメータは指定された要求に対して、要求を拒否する”deny”、許可されたネットワークポート番号（1024未満）から出たものに限って要求を許可する”port”、常に要求を許可する”none”、といった処理の方法を指定する。以下に、設定の例を示す。
128.138.24.0/255.255.252.0:atrustnis:*:none *:*:passwd.byuid:deny *:*:passwd.byname:deny 128.138.:atrustnis:*:port *:*:*:deny
host、nisdomain、mapの各フィールドでは、アスタリスク”*”を用いて任意の値にマッチさせることができるが、部分マッチは許されない （たとえば”passwd.*”によって/etc/passwdファイルから生じたすべてのマップに一致させることはできない）。コントロール行のチェックは、マッチする行が見つかるまで順に行われる。どの行もマッチしない場合は、デフォルト値が要求に対する回答となる。
上記の最初の行にあるように、hostパラメータにはネットマスクを含めることができるが、もっと一般的なCIDR表記はypservでは理解されない。また4行目に示すように、IPアドレスの後続要素を省略し、ypservにその部分を”0″で補完させて擬似的なネットマスクの役割をさせることもできる。
上記のルールでは、128.138.24/22の一方のネットワーク上にある任意のホストからのアクセスを許可している。128.138の範囲内にあるホストは、許可されたポートから出た要求である限り、/etc/passwdファイルから生じるものを除くatrustnis内のすべてのマップにアクセスできることがわかる。また、それ以外のアクセスはすべて拒否される。
ただし、こうしたアクセス制御はせいぜい暫定的な措置にしかならないことを忘れてはならない。この方法は、組織外の人々による不慮のブラウジングは抑制できるかもしれないが、意図的な攻撃者に対してはあまり効果的な抑止力にはならない。
以前からのセキュリティメカニズムである/var/yp/securenetsファイルも歴史的な理由からサポートされてはいるが、新たな設定ではypserv.confを利用すべきである。
NISクライアントの設定
サーバの設定が終わったら、今度は各クライアントマシンに新しいドメインのメンバであることを知らせる。一般的に、ドメインの各サーバはクライアントでもある。
マシンのNISドメインの設定は、domainnameコマンドによって行う。通常、このコマンドはブート時に起動スクリプトのいずれかによって実行される。この設定に必要となる正確な変更内容は、ディストリビューションによって異なるので、その詳細は後述する。
各クライアントは、少なくとも最低限のpasswd、group、hostsの各ファイルを個別に持っていなければならない。またpasswdおよびgroupファイルでは、NISサーバが利用できない場合にrootによるログインを許可しておく必要がある。これらのファイルには、標準的なシステムのアカウントおよびグループである、root、bin、daemonなどを含めるべきである。またNISの起動と実行が行われる以前に生じるブート時のクエリに回答するために、hostsファイル（またはDNS）も存在していなければならない。
NIS設定のディストリビューション別詳細
FedoraおよびRHELの場合は、NISのドメイン名を/etc/sysconfig/networkのNISDOMAIN変数を使って設定する。NISのサーバ側はypservという別パッケージとしてインストールされる。ypbind、ypserv、yppasswddの各デーモンの有効/無効の切り換えは、次のようにchkconfigを用いて行う。
# chkconfig ypbind on
SUSEの場合、NISのドメイン名はブート時に/etc/domainnameファイルから設定を行う。NISのサーバ側はやはりypservという別パッケージとしてインストールされる。chkconfigを使用して、システムがブート時に必ずypservおよび/またはypbindを自動的に起動するように設定する。ypbind用のコマンドラインオプションは、/etc/sysconfig/ypbindに設定することができる。ただし、このファイルのYPBIND_BROADCAST変数を”yes”に設定するか、/etc/yp.confファイルをインストールするかのどちらかを行わなければ、起動スクリプトによってypbindの起動が拒否されてしまう。
DebianとUbuntuの場合は、NISのドメイン名を/etc/defaultdomainに記述しておく。このファイルが存在すれば、起動スクリプトは自動的にypbindを実行する。ypservを実行するには、/etc/default/nisファイルを編集してNISSERVERの値を”slave”または”master”に設定すればよい。
© Copyright Pearson Education. All rights reserved.
