Jump to content

Hesiod (name service): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Charm (talk | contribs)
m some small corrections to punctuation, spelling, and grammar
m top: clean up spacing around commas and other punctuation fixes, replaced: ,I → , I
 
(21 intermediate revisions by 20 users not shown)
Line 1: Line 1:
{{Short description|Computer network information service}}
In [[computing]], the '''Hesiod''' [[name service]] originated in [[Project Athena]] (1983 - 1991). It uses [[Domain Name System|DNS]] functionality to provide access to [[database]]s of [[information]] that change infrequently. In [[Unix]] environments it often serves to distribute information kept in the <tt>/etc/passwd</tt>, <tt>/etc/group</tt>, and <tt>/etc/printcap</tt> files, among others.
{{More citations needed|date=June 2019}}

In [[computing]], the '''Hesiod''' [[name service]] originated in [[Project Athena]] (1983–1991).<ref name="Athena Network Services">{{cite journal|title=Network Services in the Athena Environment|author=Jennifer G. Steiner|author2=Daniel E. Geer, Jr.|date=21 July 1988|journal=Proceedings of the Winter 1988 Usenix Conference|citeseerx = 10.1.1.31.8727}}</ref> It uses [[Domain Name System|DNS]] functionality to provide access to [[database]]s of [[information]] that change infrequently. In [[Unix]] environments it often serves to distribute information kept in the {{mono|[[/etc/passwd]]}}, {{mono|[[/etc/group]]}}, and {{mono|/etc/printcap}} files, among others.
Frequently an [[Lightweight Directory Access Protocol|LDAP]] server is used to distribute the same kind of information that Hesiod does. However, because Hesiod can leverage existing DNS servers, deploying it to a network is fairly easy.
Frequently an [[Lightweight Directory Access Protocol|LDAP]] server is used to distribute the same kind of information that Hesiod does. However, because Hesiod can leverage existing DNS servers, deploying it to a network is fairly easy.


In a [[Unix-like]] system users usually have a line in the /etc/passwd file like:
In a [[Unix-like]] system users usually have a line in the {{code|/etc/passwd}} file for each local user like:


foo:x:100:10:Foo Bar:/home/foo:/bin/sh
foo:x:100:10:Foo Bar:/home/foo:/bin/sh


This line is composed of seven colon-separated fields which hold the following data:
This line tells the machine what your user id is, what group you belong to, your full name, where your home directory is, and what shell you use. This system works fine for a small number of users on a small number of machines. But when more users start using more machines having this information managed in one location becomes critical. This is where Hesiod enters.
# user login name (string);
# password hash or "x" if [[shadow password]] file is in use (string);
# user id (unsigned integer);
# user's primary group id (unsigned integer);
# [[Gecos field]] (four comma separated fields, string);
# user home directory (string);
# user login shell (string).

This system works fine for a small number of users on a small number of machines. But when more users start using more machines, having this information managed in one location becomes critical. This is where Hesiod enters.


Instead of having this information stored on every machine, Hesiod stores it in records on your DNS server. Then each client can query the DNS server for this information instead of looking for it locally. In [[BIND]] the records for the above user might look something like:
Instead of having this information stored on every machine, Hesiod stores it in records on your DNS server. Then each client can query the DNS server for this information instead of looking for it locally. In [[BIND]] the records for the above user might look something like:
Line 14: Line 26:
100.uid.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"


There are three records because the system needs to be able to access the information in different ways. The first line supports looking up the user by their login name and the second two allow it to look up information by the user's uid. Note the use of the ''HS'' class instead of ''IN'' as might be expected. The [[Domain Name System]] has a special [[Domain Name System#DNS resource records|class of service]] for Hesiod's purpose.
There are three records because the system needs to be able to access the information in different ways. The first line supports looking up the user by their login name and the second two allow it to look up information by the user's uid. Note the use of the ''HS'' class instead of ''IN'' as might be expected. The [[Domain Name System]] has a special [[Domain Name System#resource records|class of service]] for Hesiod's purpose.


On the client side some configuration also needs to happen. The /etc/hesiod.conf file for this setup might look something like:
On the client side some configuration also needs to happen. The /etc/hesiod.conf file for this setup might look something like:
Line 20: Line 32:
rhs=.example.net
rhs=.example.net
lhs=.ns
lhs=.ns
classes=HS,IN
classes=HS, IN


Also make sure your /etc/resolv.conf file is using the name servers that have your Hesiod records. Once this is configured you can test your setup using the ''hesinfo'' program:
The /etc/resolv.conf file uses the name servers that have the Hesiod records. Then

hesinfo foo passwd

should return


$ hesinfo foo passwd
foo:x:100:10:Foo Bar:/home/foo:/bin/sh
foo:x:100:10:Foo Bar:/home/foo:/bin/sh


What happens here is that the ''foo'' and the ''passwd'' are combined with the ''lhs'' and ''rhs'' values in the /etc/hesiod.conf file to create a fully qualified name of ''foo.passwd.ns.hesiod''. The DNS server is then queried for this entry and returns the value of that record.
What happens here is that the ''foo'' and the ''passwd'' are combined with the ''lhs'' and ''rhs'' values in the /etc/hesiod.conf file to create a fully qualified name of ''foo.passwd.ns.example.net''. The DNS server is then queried for this entry and returns the value of that record.


== See also ==
== See also ==
Line 37: Line 46:
* [[Lightweight Directory Access Protocol]] (LDAP)
* [[Lightweight Directory Access Protocol]] (LDAP)
* [[Kerberos (protocol)|Kerberos]]
* [[Kerberos (protocol)|Kerberos]]

==References==
{{Reflist}}


== External links ==
== External links ==
Line 42: Line 54:
* [http://www.usenix.org/events/lisa98/full_papers/grubb/grubb.pdf Single Sign-On and the System Administrator]
* [http://www.usenix.org/events/lisa98/full_papers/grubb/grubb.pdf Single Sign-On and the System Administrator]


{{unix-stub}}
[[Category:Directory services]]
[[Category:Directory services]]
[[Category:Domain name system]]
[[Category:Domain Name System]]
[[Category:Massachusetts Institute of Technology software]]

[[hu:Hesiod]]

Latest revision as of 00:01, 6 February 2024

In computing, the Hesiod name service originated in Project Athena (1983–1991).[1] It uses DNS functionality to provide access to databases of information that change infrequently. In Unix environments it often serves to distribute information kept in the /etc/passwd, /etc/group, and /etc/printcap files, among others. Frequently an LDAP server is used to distribute the same kind of information that Hesiod does. However, because Hesiod can leverage existing DNS servers, deploying it to a network is fairly easy.

In a Unix-like system users usually have a line in the /etc/passwd file for each local user like:

foo:x:100:10:Foo Bar:/home/foo:/bin/sh

This line is composed of seven colon-separated fields which hold the following data:

  1. user login name (string);
  2. password hash or "x" if shadow password file is in use (string);
  3. user id (unsigned integer);
  4. user's primary group id (unsigned integer);
  5. Gecos field (four comma separated fields, string);
  6. user home directory (string);
  7. user login shell (string).

This system works fine for a small number of users on a small number of machines. But when more users start using more machines, having this information managed in one location becomes critical. This is where Hesiod enters.

Instead of having this information stored on every machine, Hesiod stores it in records on your DNS server. Then each client can query the DNS server for this information instead of looking for it locally. In BIND the records for the above user might look something like:

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"

There are three records because the system needs to be able to access the information in different ways. The first line supports looking up the user by their login name and the second two allow it to look up information by the user's uid. Note the use of the HS class instead of IN as might be expected. The Domain Name System has a special class of service for Hesiod's purpose.

On the client side some configuration also needs to happen. The /etc/hesiod.conf file for this setup might look something like:

rhs=.example.net
lhs=.ns
classes=HS, IN

The /etc/resolv.conf file uses the name servers that have the Hesiod records. Then

$ hesinfo foo passwd
foo:x:100:10:Foo Bar:/home/foo:/bin/sh

What happens here is that the foo and the passwd are combined with the lhs and rhs values in the /etc/hesiod.conf file to create a fully qualified name of foo.passwd.ns.example.net. The DNS server is then queried for this entry and returns the value of that record.

See also

[edit]

References

[edit]
  1. ^ Jennifer G. Steiner; Daniel E. Geer, Jr. (21 July 1988). "Network Services in the Athena Environment". Proceedings of the Winter 1988 Usenix Conference. CiteSeerX 10.1.1.31.8727.
[edit]