FreeBSD NIS サービス

10年以上、２０年近く会社勤めをしていると、何かの偶然なのか、営業の方たちが同時に勢いに乗ったのか、それとも他社の落ち込みがひどすぎたのか、会社の成績が突き抜けることがたまにあります。そうなると誰しも考えることは同じなようで、全社で社員旅行！！国際通りから少し離れた沖映通の道しるべです。

大問題 / Windows Updates
NIS for NFS
NIS Master Server
NIS Domain と ypinit -m
ypbind
ypinit -s
nsswitch
動作確認
ypxfr

大問題 / Windows Updates

DNS のテストを pokemon さんや package さんで行ってきましたが、もとより不安定な Windows 上の vmware で動いていたことから windows update を完了するために windows OS が勝手に再起動し、結果として pokemon や package がクラッシュしてしまいました 🙁 そこで登場するのが dhcp さんです。息子が学生時代に使っていた筐体の分厚さが 4cm 位ある Windows XP マシンの 32bit 機です。i386 FreeBSD を入れてサーバー機能をクラッシュしない環境にする予定です。まずは、ご家庭版の DNS を pokemon さんや package さんから移し、pokemon さんをセカンダリに仕立てておきました。普段は不要ですが、dhcp をメンテナンスするときに肩代わりをしてくれます。

NIS for NFS

次は NFS について書こうかなと思っていたのですが、NFS を論じる前に NIS についてお話をしてみたいと思います。NIS は元々 YP よ呼ばれておりましたが、商標登録か何かの関係で、YP ( Yellow Page ) が使えなくなり、NIS ( Network Information Service ) と呼ばれるようになりました。しかし、使用できるコマンドは ypxxxx と未だに YP の色が濃く残っています。何故 NFS と NIS の関係が深いかというと、ファイルにはオーナーとグループがセットされていて、ファイルのモードでアクセス管理を行います。そうなると、NFS を使用しているサーバやクライアント間で使用しているユーザ情報が同じでなければ UNIX File System のセキュリティは成り立ちません。そこで、ユーザ情報に限らず、各種情報をネットワーク経由で共通に管理しようとしたのが YP、後の NIS です。私の会社の環境では、一般ユーザは Windows AD で管理して、サービスユーザは NIS で管理という感じでユーザソースを分けています。それで NIS ユーザでも AD ユーザでも同じように UN*X にログオンしたり、SAMBA のファイル共有を使ったりできるようにしています。また、M$ AD のコンピュータアカウントをスイッチの 801.2x を使用し freeradius3 経由で PC を認証/認可を行ったり、tacacs plus 4 でスイッチへのアクセスを M$ AD と統合したりしています。tac_plus4、freeradius3、M$ AD によるユーザ管理、あるいは NFSv4 での Kerberos の使用などは別の機会にしたいと思います。

NIS Master Server

元々 UN*X マシンのユーザ管理はマシンごとに /etc/passwd、/etc/group をいじってユーザを作っていました。これは NIS マスタサーバーでも同じです。この情報を NIS のスレーブサーバーへ転送して、クライアントは近所の NIS サーバーからユーザ情報をネットワーク経由で得ます。早速 dhcp さんを NIS ドメイン JF3VQB の NIS マスタサーバーに仕立ててみます。その後に package さんを NIS スレーブサーバに仕立てるという方針で行きます。まず、普通にユーザやグループを他の pokemon や package を参考に作ります。ユーザやグループは NIS が起動する前に必要となるものは、ローカルシステムに残しておきます。daemon が起動しなくなるかもしれませんので。。NIS 関係のファイルは /var/yp ディレクトリに格納されます。何も設定されていない状態では、Makefile のみがあります。ちょっと中身を見てみましょう。

まず注目すべきはこちらです。これが NIS マスタでネットワークで唯一のサーバであればこのままで。スレーブサーバがあるならば、NOPUSH は True ではない必要があります。今回の設計の方針では、package さんがスレーブサーバとなる予定なので、この変数はリセットします。

次に注目すべきはこちらです。FreeBSD の passwd ファイルには暗号化されたパスワードは含まれません。このパスワードは一般ピープルには見ることができない master.passwd ファイルに格納されています。最大の理由はパスワードが見れると力技で暗号化されたパスワードを解読される可能性があるからです。ところがこの仕組みが他の OS へ NIS 機能を提供するときに問題となるある場合があります。その場合は UNSECURE を True にして、暗号化されたパスワードを passwd ファイルの一部として見れるようにできます。今回は FreeBSD ばかりなので、こちらは変更せずに置きます。

NIS Domain と ypinit -m

ではまず dhcp さんを初期化してみましょう。NIS で使用するドメイン名は JF3VQB とします。因みに DNS のドメイン名と関連はありませんので、好きな文字列で OK です。

スレーブサーバー名以外はデフォルトで行きます。

NIS 関係のプロセスが起動していないので各種エラーが起こります。

master.passwd が /var/yp に無いといわれます。ソリャそうです。作っていないので。

ユーザ情報変更の度にこのファイルを /var/yp にコピーするのも面倒くさいので、オリジナルの /etc/master.passwd ファイルをこのファイル名に指定します。勿論毎度叩くのは面倒なので、/etc/make.conf に入れておきます。

もう一度初期化を行っておきます。

現在 /var/yp/JF3VQB にあるデータは作り直して OK です。

入力した情報に間違いがなければ ‘y’ で先に進みます。

今回は master.passwd ファイルに関するエラーは表示されませんでした。

dhcp さんに必要なサービスが自動で起動するように /etc/rc.conf ファイルをいじります。

package さんも同じようにいじります。異なるのは NIS サーバーの順番だけです。

ypbind

NIS クライアントは ypbind が動いていれば OK です。起動後に使用される NIS サーバーは nis_client_flags に書いた一番最後のサーバーが使用されます。もしこのサーバーが利用できなければその直前のサーバーが使用されます。今回のように単一のネットワークのみで NIS が使用されるのであればブロードキャストで構成することもできますが、ちょっと芸がなさすぎるので NIS サーバーを指定した使い方をしてみました。因みにブロードキャストで使うときは、ドメイン名をセットして、ypbind を引数なしで動かせば基本 OK です。

まず、動作確認を兼ねて dhcp さんを再起動してみましょう。

ypserv と ypbind が見えれば OK です。

ypinit -s

続いて、package さんを初期化します。

エラーなく終了したら動作確認のため再起動します。再起動後 dhcp と同じプロセスが見えるはずです。

pokemon さんも再起動して、ypbind が見えれば OK です。

マスタサーバ、スレーブサーバ、クライアント、それぞれ同じユーザが見えることを確認します。

確認できれば、ローカルのユーザを削除します。

SSH でつないでみようとしてみましたが、pokemon ユーザの公開鍵が見えないようです。

パスワードを入れてみても認証にはじかれます。ユーザが認識されていないようです。

nsswitch

/etc/nsswitch.conf を編集します。

そして、group と passwd の compat を “files nis” に変更します。

さて、これで OS にまずローカルのファイルを使用し、見当たらなければ NIS を使うように指示ができたはずです。確かに、公開鍵でログインできました。

では、他の２台も同じように nsswitch.conf を書き換えて、pokemon ユーザでログインできることを確認します。ユーザ名やグループ名が同じように見えますが、たまたま３台の FreeBSD 上で同じ UID/GID を使用してユーザを作ったからです。ただの偶然です。この偶然を必然にするために M$ AD や NFSv4 を使うことになります。

動作確認

アップデートが行えるかどうか確認するため、NIS マスタサーバーに新しいユーザを作り、/var/yp で push してみます。

make が終了したら他の２台で新しいユーザが見えるか確認します。

master.passwd も共有してるかどうか確かめます。hogehoge さんのパスワードを使ってログオンしてみます。

パスワードもコピーされているようです。ただ、ホームディレクトリがないので、ログインはできますが怒られます。

ypxfr

そこで、NFS の出番となるわけです。NFS は別記事でご紹介できると思います。

最後に、マスタ/スレーブ間の同期が確実で、必ず同じ情報が見えてほしいのですが、マスタサーバで push したときにたまたまスレーブの ypserv が止まっていたり、ネットワークが途切れてしまったりすることもないとは限りません。またここで作った JF3VQB ドメインは非常に小さなドメインなので、更新が頻繁ではありません。ですので、転送が失敗したらデータの矛盾が長期間続きます。このような事態を避けるために、スレーブサーバでは定期的にデータをチェックして、自分の持っているデータより新しそうであれば転送を要求して最新のデータを持っていることを確実にしておくことが望まれます。管理スクリプトを組んでチェックするようにしましょう。私は /etc/admin 配下に管理スクリプトを置くと決めていますので、ここでもそのようにします。