| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155 |
- The GNU C library contains an NSS module for the Hesiod name service.
- Hesiod is a general name service for a variety of applications and is
- based on the Berkeley Internet Name Daemon (BIND).
- Introduction
- ============
- The Hesiod NSS module implements access to all relevant standard
- Hesiod types, which means that Hesiod can be used for the `group',
- `passwd' and `services' databases. There is however a restriction.
- In the same way that it is impossible to use `gethostent()' to iterate
- over all the data provided by DNS, it is not possible to scan the
- entire Hesiod database by means of `getgrent()', `getpwent()' and
- `getservent()'. Besides, Hesiod only provides support for looking up
- services by name and not for looking them up by port. In essence this
- means that the Hesiod name service is only consulted as a result of
- one of the following function calls:
- * getgrname(), getgrgid()
- * getpwname(), getpwuid()
- * getservbyname()
- and their reentrant counterparts.
- Configuring your systems
- ========================
- Configuring your systems to make use the Hesiod name service requires
- one or more of the following steps, depending on whether you are
- already running Hesiod in your network.
- Configuring NSS
- ---------------
- First you should modify the file `/etc/nsswitch.conf' to tell
- NSS for which database you want to use the Hesiod name service. If
- you want to use Hesiod for all databases it can handle your
- configuration file could look like this:
- # /etc/nsswitch.conf
- #
- # Example configuration of GNU Name Service Switch functionality.
- #
- passwd: db files hesiod
- group: db files hesiod
- shadow: db files
- hosts: files dns
- networks: files dns
- protocols: db files
- services: db files hesiod
- ethers: db files
- rpc: db files
- For more information on NSS, please refer to the `The GNU C Library
- Reference Manual'.
- Configuring Hesiod
- ------------------
- Next, you will have to configure Hesiod. If you are already running
- Hesiod in your network, you probably already have a file named
- `hesiod.conf' on your machines (probably as `/etc/hesiod.conf' or
- `/usr/local/etc/hesiod.conf'). The Hesiod NSS module looks for
- `/etc/hesiod.conf' by default. If there is no configuration file you
- will want to create your own. It should look something like:
- rhs=.your.domain
- lhs=.ns
- classes=in,hs
- The optional classes settings specifies which DNS classes Hesiod
- should do lookups in. Possible values are IN (the preferred class)
- and HS (the deprecated class, still used by some sites).
- You may specify both classes separated by a comma to try one class
- first and then the other if no entry is available in the first
- class. The default value of the classes variable is `IN,HS'.
- The value of rhs can be overridden by the environment variable
- `HES_DOMAIN'.
- Configuring your name servers
- -----------------------------
- In addition, if you are not already running Hesiod in your network,
- you need to create Hesiod information on your central name servers.
- You need to run `named' from BIND 4.9 or higher on these servers, and
- make them authoritative for the domain `ns.your.domain' with a line in
- `/etc/named.boot' reading something like:
- primary ns.your.domain named.hesiod
- or if you are using the new BIND 8.1 or higher add something to
- `/etc/named.conf' like:
- zone "ns.your.domain" {
- type master;
- file "named.hesiod";
- };
- Then in the BIND working directory (usually `/var/named') create the
- file `named.hesiod' containing data that looks something like:
- ; SOA and NS records.
- @ IN SOA server1.your.domain admin-address.your.domain (
- 40000 ; serial - database version number
- 1800 ; refresh - sec servers
- 300 ; retry - for refresh
- 3600000 ; expire - unrefreshed data
- 7200 ) ; min
- NS server1.your.domain
- NS server2.your.domain
- ; Actual Hesiod data.
- libc.group TXT "libc:*:123:gnu,gnat"
- 123.gid CNAME libc.group
- gnu.passwd TXT "gnu:*:4567:123:GNU:/home/gnu:/bin/bash"
- 456.uid CNAME mark.passwd
- nss.service TXT "nss tcp 789 switch sw "
- nss.service TXT "nss udp 789 switch sw"
- where `libc' is an example of a group, `gnu' an example of an user,
- and `nss' an example of a service. Note that the format used to
- describe services differs from the format used in `/etc/services'.
- For more information on `named' refer to the `Name Server Operations
- Guide for BIND' that is included in the BIND distribution.
- Security
- ========
- Note that the information stored in the Hesiod database in principle
- is publicly available. Care should be taken with including vulnerable
- information like encrypted passwords in the Hesiod database. There
- are some ways to improve security by using features provided by
- `named' (see the discussion about `secure zones' in the BIND
- documentation), but one should keep in mind that Hesiod was never
- intended to distribute passwords. In the original design
- authenticating users was the job of the Kerberos service.
- More information
- ================
- For more information on the Hesiod name service take a look at some of
- the papers in ftp://athena-dist.mit.edu:/pub/ATHENA/usenix and the
- documentation that accompanies the source code for the Hesiod name
- service library in ftp://athena-dist.mit.edu:/pub/ATHENA/hesiod.
- There is a mailing list at MIT for Hesiod users, hesiod@mit.edu. To
- get yourself on or off the list, send mail to hesiod-request@mit.edu.
|