Directory Servers

Prerequisites: Host Install Tools

You'll need to provide your client machines with hostname resolution, UID and GID mappings, automount maps, and possibly other items of data that are generally read-only (this does not include authentication -- see Authentication Servers ). The servers you use for these functions should be part of your infrastructure rather than standalone. The master copies of the data they serve will need to be backed up somewhere easily accessible.

You'll probably want to use DNS for hostnames, and either use LDAP, NIS, or file replication for UID, GID, and automounter mapping.

Here are some things to consider while choosing directory services:

• Is the protocol available on every machine you are likely to use? Some protocols, most notably NIS+, have very limited availability.
• Does it work on every machine you are likely to use? A poor implementation of NIS once forced us to use file replication instead.
• Is it unnecessarily complicated? A full-featured database with roll-back and checkpoints to perform IP service name to number mapping is probably overkill.
• How much will you have to pay to train new administrators? An esoteric, in-house system may solve the problem, but what happens when the admin who wrote and understands it leaves?
• Is it ready for prime-time? We used one product for a while for authentication services that we wanted to abandon because we kept hearing "Oh, that is available in the next release."

DNS, LDAP, NIS and the file replication tools described in the following sections eventually tend to become necessary components of most of our infrastructures. DNS provides hostname to IP address mapping, as it is easy to implement and allows subdomain admins to maintain their hosts without appealing to a corporate registry. DNS is also the standard for the Internet -- a fact often lost in the depths of some corporate environments. LDAP or NIS provide the authentication mechanism, as described in the next section. LDAP is today a better choice than NIS in most cases.

When using NIS, we want our machines to be able to boot with no network present. This dictates that each of our clients be a NIS slave. Pulling the maps down on an hourly or six-minute cycle and keeping hundreds of 'ypserv' daemons sane requires a good deal of management code which runs on each client. [nis_watchdog] Other infrastructures we've seen also make all clients caching DNS servers.

We recommend that directory server hosts not be unique, standalone, hand-built machines. Use your host install tools to build and configure them in a repeatable way, so they can be easily maintained and your most junior sysadmin can quickly replace them when they fail. We found that it's easy to go overboard with this though: It's important to recognize the difference between mastering the server and mastering the data it's serving. Mastering the directory database contents from the gold server generally guarantees problems unless you always use the gold server (and the same mastering mechanism) to make modifications to the database, or if you enforce periodic and frequent dumps to the gold server from the live database. Other methods of managing native directory data we've seen include cases such as mastering DNS data from a SQL database.

We tend to use hostname aliases in DNS, and in our scripts and configuration files, to denote which hosts currently offer which services. This way, we don't have to edit scripts when a service moves from one host to another. For example, we might create CNAMEs of 'sup' for the SUP server, 'gold' for the gold server, and 'cvs' for the CVS repository server, even though these might all be the same machine.