It's not clear that this is really helpful; it's more or less notes I took while researching NIS (Yellow Pages). Note that Sun originally called it Yellow Pages, but British Telecom already had this name for something else. While a lot of interface-level prefixes were left yp, NIS was chosen instead.
Most of the contents of this document were plagierized from http://www.tldp.org/HOWTO/NIS-HOWTO/ , dated 1 July 2003.
One machine acting as server, but read-only copies of database on 0+ slave servers.
Slaves notified of modifications via yppush.
NIS+ side note: NIS+ is newer version, not universally used, easy for clients, but nightmare for server administrator, supports data encryption and authentication over secure remote procedure call (RPC).
Database manager (DBM) format, fixed-size buckets and hashing techniques enabling retrieval by key. Derived from ASCII databases (/etc/passwd and /etc/group), the master NIS server should retain both (ASCII and binary).
Older ypbind versions do a broadcast to find a running server, but this is insecure (anyone could answer). Newer versions keep a host configuration file, /var/yp/binding/... (if set up; mine isn't).
NIS uses remote procedure calls (RPS). The server is portmap and converts RPC program numbers into TCP (UDP)/IP port numbers. It must be running to make RPC calls, what the NIS client does, to NIS servers on their respective hosts. When an RPC server is launched, it tells portmap what port number it is listening on and what RPC program numbers it is prepared to serve. When a client makes a call to a given program number, it first contacts portmap on the server to determine the port number where the RPC packets should be sent.
portmap should be started before inetd since that dæmon can start (and stop) it. A separate, omnipresent instance is needed.
NIS+ side note: for secure RPC, a time service is needed and must be enabled in /etc/inetd.conf on all participating hosts.
In particular, using yppassword, which often just maps to passwd, sends the old password in clear text over the network to the NIS master server. If the change to a new password is successful, no problem. However, upon failure, the old password remains in effect until it can be changed and, meanwhile, anyone having sniffed it, can attack using that password. Worse, if the system administrator changes the NIS password for a user, its root password is sent in clear text over the wire.
Without going to NIS+, one solution to this makes use of rpasswd which goes over a secure SSL connection.
On Linux, one generally installs the ypbind dæmon in /usr/sbin and the other binaries, ypwhich, ypcat, yppasswd, yppoll and ypmatch, in /usr/bin.
This configuration file determines the order of look-ups when information is requested just as /etc/hosts is consulted when performing host look-ups.
For example, a line such as:
passwd: files nis vas3
tells NIS that the password look-up functions should first consult /etc/passwd (in the local "file" system) or look to a NIS server for it and, those approaches failing, ask Vintela Authentication Services (VAS) for it (in the case of a VAS user that is not also a local Unix user).
New maps are created using ypinit -m (when setting up the NIS server for the first time). Maintaining the maps in use is a matter of updating /var/yp/Makefile and rebuilding (make -C /var/yp) each time. This holds for after making changes to one or more maps too.
Map entries are limited to 1024 characters, governed by YPMAXRECORD, which cannot be simply modified. The glibc implementation removes this limit, but all servers and clients on the network must participate.
One way around this for group names is to break them out onto multiple lines, each with a slightly different name and keeping the same GID of course. The first entry should contain the "real" group name (and the GID); to save space, don't put any users on that line. The cleverness happens because looking for a username, you get the right GID while looking by groupname you also get the right GID (and ignore the bogus groupnames).
To survive reboot, there needs to be a ypbind (server) or ypclient (client) script in the init script directory (/etc/init.d, etc.).
Nothing to do with Halloween themes, these two commands list the maps and the master offering them and reveal the contents thereof. Think of ypwhich sort of as ls for the NIS maps and ypcat as cat to see their contents.
* “and now back to our show.”