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...
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...
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
end
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`
ypinit -m
bilbo
frodo
Ctrl-D
reboot
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.
domainname `cat /etc/defaultdomain`
ypinit -s bilbo
reboot
Wait for the reboot to finish and watch the new daemons to start: ypserv and ypbind.
domainname `cat /etc/defaultdomain`
ypinit -c
reboot
Do not wait until the reboot is done, the only new daemon is ypbind (you have seen this earlier already).
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.
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:
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.
cd /var/yp
make
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".
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.
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.
cd /var/yp/`domainname`
makedbm -u ypservers >ypservers
echo "pippin pippin" >>ypservers
makedbm ypservers ypservers
cd /var/yp
make
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.
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.
dname=`domainname`
if [ "$dname" -a -d /var/yp ]; then
ypbind -ypsetme; echo -n ' ypbind'
fi
if [ -d /var/yp/`dname` ]; then
sleep 5
/usr/etc/yp/ypset `hostname`
fi
server=`grep ":.*[ ][ ]*/[ ]" /etc/fstab |\
sed -e "/^#/d" -e "s/:.*//"`
if [ "$server" ]; then
intr -a rdate $server
if [ "$dname" -a -d /var/yp ]; then
/usr/etc/yp/ypset $server
fi
fi
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.
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.
hosts: files dns [NOTFOUND=return] nisThat 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.