I really love YP. But i didn't fall in love on the first look, but my love grew with my knowledge, constant use and experimenting.
Yellow Pages are a distributed network database for some of the important files in /etc. If you have more than two machines connected by a network (ethernet), then you'll probably need such a thing like YP. It will simplify administration greatly. If you want to add a new user, you do not have to edit all the /etc/passwd files on all machines but only change the /etc/passwd on the YP master server and invoke the "magic words". And immediately, all other machines will accept the new user.
YP was invented by Bill Joy and others at Berkeley (it was part of the Berkeley Software Distribution) and Bill took it to Sun Microsystems later. The people at Sun enhanced YP a lot and gave it its todays appearance. They had to change the name (to NIS: Network Information System) too, because British Telecom sued them. Later, they made a totally new approach and called it NIS+. In this document i'll avoid the name NIS, because it may lead to confusion. And BTW: The program names still start with the letters yp...
As long as you can go with editing the /etc files, you don't need YP. This is true for a single machine, and maybe for two or three, where you have a small number of users. If you have more machines and (very important:) more users which occasionally want to change their passwords (and they really should do that once in a while for security reasons) without your help, a distributed network database like YP makes sense.
If the number of machines approaches 300, the number of users raises to 10,000 and the machines are on several network segments, then YP begins to degrade in performance and starts to make more and more trouble. In this cases, something better (like NIS+) is really needed.
If you have a heterogenous cluster, YP is often the only choice, because it was part of BSD Unix and many workstation vendors included it with their Unix. But there are subtle differences...
YP uses a couple of programs to do it's work. I'll describe them here briefly, because it might be convenient to know them already if you read further.
As example, i'll use a fictive network of six machines (bilbo, frodo, pippin, merry, dick, sam). The machines should be running ok without YP and know each other (/etc/hosts).
First, choose a domain name for the YP. Do not confuse this with the DNS domain name. Some people prefer to use the same domain name for DNS and YP, but this is not necessary. But there is a subtle relationship between them and it may lead to confusion. On the other side, it works and it may simplify some things. But make sure you know the little difference. For me, a YP domain name like "Moria" or "Gandalf" is much more enjoying than "bagsend.hobbingen.au".
- ypbind: Initiates the communication with a YP database server by "binding" to it.
- ypserv: Runs on a YP database server and does the main work.
- ypxfrd: Transfers the databases to other servers
- yppasswdd: Copes with shadow passwords
- ypupdated: Runs if a user changes his password
- ypcat: Runs a list query on a database
- ypwhich: Finds out which machine serves a database
- ypinit: Shell script to set up YP
- ypmatch: Find a matching entry in a database
- ypset: Redirect ypbind to another YP server
- domainname: Query and set the YP domain name
- makedbm: Converts a "ndbm" database to a human readable text file and vice versa
Create a file /etc/defaultdomain, that contains the YP domainname. Distribute it to all machines, that will share the YP domain.
echo "Gollum" >/etc/defaultdomain
foreach host (bilbo frodo pippin merry dick sam)
rdist -c /etc/defaultdomain $host
Then choose YP servers. This should be machines which are very reliable and will run all the time. If you have a big server in a closed room, then this beast would be a good choice. For a handful of machines, only one YP server is needed. But if you have a lot of machines, then follow this general rules:
One of the YP servers will be the YP master server. Use the most important and most reliable machine for that task. Make sure, it does have a (otherwise empty) /var/yp directory that contains the YP Makefile.
- At least one for every network segment
- Every important file server (especially if it serves diskless clients)
- Every powerful machine with lots of users
Hint: On SunOS 4.1.X, there is a copy of the YP Makefile in /usr/lib/NIS-Makefile.
On the master server (in the example: bilbo), invoke:
domainname `cat /etc/defaultdomain`
Besides some stupid questions, ypinit asks for the name of the master and slave servers (bilbo and frodo). Wait for the reboot to finish and watch the new daemons to start: ypserv, ypbind, ypxfrd, yppasswdd and ypupdated.
On each slave server (in the example: frodo), invoke:
domainname `cat /etc/defaultdomain`
ypinit -s bilbo
Wait for the reboot to finish and watch the new daemons to start: ypserv and ypbind.
On each client (in the example: pippin, merry, dick and sam), invoke:
domainname `cat /etc/defaultdomain`
Do not wait until the reboot is done, the only new daemon is ypbind (you have seen this earlier already).
It is possible to work around the reboot, but this is difficult on BSD based machines and boring on SysVish ones. If you're an expert (or running a HA cluster) snoop through the /etc/rc* files to find out the necessary commands.
It's very instructive to glimpse into the /etc/rc* files and see which things happen on which event. For example here you can find out, what is necessary for a particular daemon to become started.
For example i wasn't pleased with the way SunOS decided if a machine was the YP master server. I changed the line to
if [ -f /var/yp/Makefile ]; then
and live happily whith it since years.
There are a lot of functions in the C runtime library (for short: libc) which are used to browse the /etc files. This saves a lot of work for a programmer and makes YP possible. YP intercepts these functions and instead of browsing the /etc files it asks a YP server via the network for an answer. Examples for these functions are: gethostbyname, getpwent, getservent and getnetbyaddr. Read their manpages and see what these are good for.
YP uses Remote Procedure Calls (RPC) to query a database on the server. These databases are built using "ndbm" and reside in /var/yp/`domainname`. The following /etc files are usually in the YP databases:
On many implementations, there are additional databases like:
- passwd: the users
- group: the groups
- hosts: the hosts
- ethers: the ethernet addresses
- networks: the networks (normally unused)
- rpc: the RPC database
- protocols: the internet protocols
- netgroup: the netgroups
- netmasks: the netmasks
- services: the internet service ports
- bootparams: the bootparams for diskless clients
- aliases: the mail aliases
- timezone: the timezone file
- publickey: for secure NFS, YP and NIS+
- shadow: the passwords
- auto.master: the automounter master table
- auto.home: the automounter table for the home filesystems
- amd.home: the Berkeley automounter table for the home filesystems
Some Operating Systems even implement a general mechanism for that. Solaris 2 does (hence the /etc/nsswitch.conf) as well as Linux with the new GNU libc. On such systems you can easily add more /etc files to the YP (/etc/printcap might be an example).
On the other hand you can easily remove some /etc files from the YP. Simply take out the name of the file from the "all:" line in the YP Makefile and remove the database file in /var/yp/`domainname`. This is often necessary on a heterogenous network where not all machines like the /etc files of a master with a completely different operating system. /etc/services is prone to this disease. Or you might decide that a file isn't changed often enough to allow for such an overhead. I usually do not include the services, bootparams, aliases and timezone in my YP.
Using YP is quite simple (if it's running): Make any change in the /etc files on the master server and invoke the "magic words":
and voila! The changes are instantly available on all machines.
If YP slave servers are present, the master sends a copy of the changed database files to them.
If a user wants to change the password, he should use "yppasswd". It will automatically invoke the "magic words" to update the YP password database. "yppasswd" is often a link of "/bin/passwd".
SunOS 4.1.X for example doesn't use DNS to lookup hosts. But DNS should be the only trusted source of such information, if the machine is directly connected to the internet.
To overcome this behaviour, you can plug the DNS resolver library into the dynamically linked libc. But if you have YP, there is a much simpler approach: Edit the YP Makefile and look for the -b option. If enabled, the YP server will do DNS lookups, if he doesn't find a hostname in the hosts database. Simply set up an apropriate /etc/resolv.conf.
Host names ending in the YP domainname will be resolved by YP itself. If you can assure, that the /etc/hosts of the master server is always the same as the DNS database for your DNS domain, you can use your DNS domainname as YP domainname. On the other hand never use a legal DNS domainname (other than your own) as YP domainname or something strange may happen.
If you get an old machine from somewhere, it might be used to have a YP. Or if you plan to take a machine with you to a conference or presentation, it won't find it's YP servers. Such a machine simply won't boot up in multiuser mode unless YP gets deactivated. This is simple. Boot up the machine in single user mode and remove (rename) /etc/defaultdomain and /var/yp:
mv /etc/defaultdomain /etc/defaultdomain.off
mv /var/yp /var/yp.off
You now might make other changes (hostname, /etc/hosts, /etc/passwd, /etc/fstab and such) and then try to boot it up in multiuser mode.
The list of YP servers given at the very beginning (at "ypinit -m") is distributed over YP too. A new slave server has to be entered into this database. Unfortunately the data is only available as "ndbm"-database so we have to convert the database to human readable form, edit it and convert it back. The program "makedbm" does these conversion tasks. We'll now add "pippin" as new slave server in our example:
makedbm -u ypservers >ypservers
echo "pippin pippin" >>ypservers
makedbm ypservers ypservers
Then you continue as described above setting up a YP slave server.
The same procedure applies, if you want to remove a YP slave server. Edit the file "ypservers" and delete the appropriate line. Then create the new database and invoke the "magic words". On the former YP server remove /var/yp/`domainname` and reboot.
Unfortunately this does not work for the YP master server.
YP works best, if all YP servers are ok and the network is fine. Terrible things may happen, if that's not the case. Especially older YP implementations (ala SunOS 4.1.X) cannot dynamically rebind to a new YP server. The default behaviour is: A YP client shouts for a YP server on the net as it boots and binds to the first one who answers. If this machine crashes, the client hangs too. To minimize problems, i've adopted some useful techniques.
If a YP server boots up, it starts the "ypserv" daemon very early. But since the machine is under heavy load at that moment, some other YP server (sitting idle) might answer faster to "ypbind" than the local "ypserv". That's not good, because server does have all the databases himself so there is no use in asking another machine over the network.
And worse: If two YP servers reboot at the same time (which can happen after a power failure), they can bind to each other. This is a particular evil situation, because if one machine stops later (crash, reboot), not only its clients will hang but the other YP server and all of its clients too! And sometimes this server may not be able to recover even if the first server starts up again.
A dataless or diskless client should find the YP on it's NFS server. The NFS server is already a single point of failure and binding to another machine for the YP would create another one. Single points of failure lead to faults that do not sum up but multiply exponentially!
The solution is simple: There is an option for ypbind which allows to change the YP server later (-ypsetme). This can be used to guarantee, that a YP server always binds to itself. And a diskless client can bind to a YP server which is already a single point of failure (so not to add another one).
At the point, where "ypbind" is started, i add "-ypsetme" and later i set the YP server of choice to something reasonable.
if [ "$dname" -a -d /var/yp ]; then
ypbind -ypsetme; echo -n ' ypbind'
if [ -d /var/yp/`dname` ]; then
server=`grep ":.*[ ][ ]*/[ ]" /etc/fstab |\
sed -e "/^#/d" -e "s/:.*//"`
if [ "$server" ]; then
intr -a rdate $server
if [ "$dname" -a -d /var/yp ]; then
Note, that the above is only a crude excerpt of the real thing. It should only give you an idea how it can be done.
As long as it is not the YP master server, you can make such a change by redirecting the clients and removing the YP on that slave server completely. Change its IP address then and set up the machine as YP slave server from scratch.
If you have to change the IP address of the YP master server, remove the YP completely on all machines and afterwards set up a new one from scratch. All else won't work.
Ok, ok, just kidding. If your YP does know a /var/yp/securenets, then use it! This will help a lot.
Other tools for security can help with YP too. You really should install a recent version of the portmapper. Either grab a patch from your vendor or compile Wietse Venema's portmapper.
A paranoid admin should definately run the YP daemons under the control of a wrapper-libc.
Shadow passwords can be used under YP, but the YP server should reject every query but "ypmatch" on the shadow or passwd.adjunct database. Sun's "ypserv" unfortunaltely allows list queries, if they come from a port less than 1024, so every non-trusted host on the network (a dumb PC for example) can get all the (encrypted) passwords.
It might be a good idea to transfer the shadow or passwd.adjunct database encrypted to the slave servers if ypxfrd supports this.
YP differs slightly from one operating system to another. The operating systems not mentioned have almost plain decendants of 4.3reno BSD's YP.
Sun's RPC-4.0 and XDR packages are the base of every modern YP. In addition to 4.3BSD, SunOS offers shadow passwords over YP and some security (based on IP addresses: /var/yp/securenets). SunOS implements a fixed access strategy in the libc: If YP is not activated, it browses the /etc files, else it asks the YP. There are two exceptions to this rule: passwd and group (and their shadow adjuct companions) are always read from /etc and if they contain lines starting with a "+", special actions are required. Normally, you'll add a line with a single "+" at the end of these files to activate YP, but the "+" mechanism allows more fancy things.
Under Solaris 2.0, YP had vanished in favour of NIS+, but came back (in usable form) as NISkit-1.1 for 2.3. Since 2.6, NISkit-1.2 is included in the operating system. Solaris does have a general mechanism to browse /etc files (/etc/nsswitch.conf) and can use various sources for that task. For example the line describing the mechanism for hosts could look as follows:
hosts: files dns [NOTFOUND=return] nis
That means: Look up a name in /etc/hosts. If unsuccesful, query DNS and if DNS doesn't find it, quit. If DNS gives an error, ask YP.
YP occured first in BSD Unix. Modern BSD Unices like NetBSD and FreeBSD have adopted many of the SunOS and Solaris enhancements.
Linux makes use of freely available YP implementations. These offer simillar functionality than Sun's YP and have more security features. Unfortunately this focus on security has killed the support for shadow passwords over YP which makes it pretty useless if you have lots of users and you want some security.
Besides the programs shipped with the operating system, there are some other useful programs that can make use of YP:
- amd: The Berkeley automounter (the newest version is now called am-tools)
- sendmail: For sendmail V8, you need to add -DYP -DNDBM to the compile flags