コンピューティングの世界では、Hesiod ネーム サービスはProject Athena (1983–1991)で生まれました。 [1] DNS機能を使用して、頻繁に変更されない情報のデータベースへのアクセスを提供します。Unix 環境では、/etc/passwd、/etc/group、/etc/printcapファイルなどに保管されている情報を配布するために使用されます。Hesiod と同じ種類の情報を配布するために、 LDAPサーバーがよく使用されます。ただし、Hesiod は既存の DNS サーバーを活用できるため、ネットワークへの展開はかなり簡単です。
Unix のようなシステムでは、通常、/etc/passwdファイル内に各ローカル ユーザー用の
行が存在します。
foo:x:100:10:Foo バー:/home/foo:/bin/sh
この行は、コロンで区切られた 7 つのフィールドで構成され、次のデータを保持します。
- ユーザーのログイン名(文字列)
- パスワード ハッシュ、またはシャドウ パスワードファイルが使用されている場合は "x" (文字列)。
- ユーザーID(符号なし整数)
- ユーザーのプライマリグループ ID (符号なし整数)。
- Gecos フィールド(コンマで区切られた 4 つのフィールド、文字列)。
- ユーザーのホームディレクトリ(文字列)
- ユーザーのログインシェル (文字列)。
このシステムは、少数のユーザーが少数のマシンを使用する場合には問題なく機能します。しかし、より多くのユーザーがより多くのマシンを使用するようになると、この情報を 1 か所で管理することが重要になります。ここで Hesiod の出番となります。
Hesiod は、この情報を各マシンに保存するのではなく、DNS サーバーのレコードに保存します。これにより、各クライアントはローカルでこの情報を探す代わりに、DNS サーバーに問い合わせることができます。BIND では、上記のユーザーのレコードは次のようになります。
foo.passwd.ns.example.net HS TXT "foo:x:100:10:Foo Bar:/home/foo:/bin/sh" 100.passwd.ns.example.net HS TXT "foo:x:100:10:Foo Bar:/home/foo:/bin/sh" 100.uid.ns.example.net HS TXT "foo:x:100:10:Foo Bar:/home/foo:/bin/sh"
システムがさまざまな方法で情報にアクセスできるようにする必要があるため、レコードが 3 つあります。最初の行は、ログイン名によるユーザーの検索をサポートし、次の 2 行は、ユーザーの uid による情報の検索を可能にします。予想どおり、INではなくHSクラスが使用されていることに注意してください。ドメイン ネーム システムには、 Hesiod の目的のための 特別なサービス クラスがあります。
クライアント側でもいくつかの設定が必要です。この設定の /etc/hesiod.conf ファイルは次のようになります。
rhs=.example.net lhs=.ns クラス=HS、IN
/etc/resolv.confファイルはHesiodレコードを持つネームサーバーを使用します。
$ hesinfo foo パスワード foo:x:100:10:Foo バー:/home/foo:/bin/sh
ここで何が起きるかというと、fooとpasswdが/etc/hesiod.conf ファイルのlhs値とrhs値と結合され、 foo.passwd.ns.example.netという完全修飾名が作成されます。次に、DNS サーバーにこのエントリが照会され、そのレコードの値が返されます。
参照
- ネーム サービス スイッチ(NSS)
- ネットワーク情報サービス(NIS)
- 軽量ディレクトリ アクセス プロトコル(LDAP)
- ケルベロス
参考文献
- ^ Jennifer G. Steiner、Daniel E. Geer, Jr. (1988 年 7 月 21 日)。 「 Athena 環境におけるネットワーク サービス」。1988年冬期 Usenix カンファレンス議事録。CiteSeerX 10.1.1.31.8727。
