Original in fr Frédéric Raynal
fr to en: Jo Simons
en to en:Lorne Bailey
The Network Information Service (NIS) was initially created by Sun and known as Sun Yellow Pages (commonly known simply as the Yellow Pages or YP). This, however, is a trademark of British Telecom and consequently can not be used without the proper permissions. These Yellow Pages refer to the ones where we look up telephone numbers.
The NIS servers maintain copies of common configuration files on several networked machines in a database. The NIS clients address their requests to the servers instead of using their own configuration files.
Let's pretend to be a user on the network who wants to change his password. Let's first imagine YP is not installed. This user will have to logon to all the machines on the network to change his password. If YP were installed it would be possible for him/her to change his password on one of the machines where a NIS client is running, The new password will then be tranferred to the server where it will be changed in the server database. After this when a user wants to connect to a networked machine (on which a NIS client is running of course ;-), the password will be compared to the one registered in the database of the server.
There are different versions of YP but since this article is an introduction, we will only look at the principles of how it works without going into the details. We will come to the details later on.glibc 2.x (libc6) supports the use of NSS (Name Switch Service) which determines the order in which the information has to be searched (see the file /etc/nsswitch.conf). It maintains the aliases, subnets, groups, hosts, netgroups, networks, protocols, publickey, passwd, rpc, services and shadow maps.
There will be machine on the network serving as an NIS server for a domain. This domain corresponds, more or less, to the name of the database the server will administer. This is the key NIS clients use to locate the needed information on the NIS server. This domain name has absolutely nothing to do with the DNS domain name. There can be more than one NIS server on the same domain. They can each administer a different domain (on the NIS level), or they could administer the same domain (in this case there will be a master server and slave servers).
The slave servers only have a copy of the master servers database. These servers supplement the master server when it is taking too long to answer the client's requests or when the master server goes down.
The slave servers are notified of every change in the database by the program yppush and they will update there own databases to reflect exactly the state of the database on the server.
The clients, on their side, don't need any "maintenance" since they are continually contacting the NIS server to lookup the information in its database.
The YP database are in the GDBM format, taken from the ASCII format. They are set up during the installation of the server by the makedbm program.
These maps establish correspondences between a key and its value. All the YP maps are based on this model. From the server's point of view, the contents have no meaning (well, besides some exceptions concerning data about the main server or dates). This means that, to the server, a map with passwords or groups etc. is nothing more than a set of key/value pairs. Only the YP client knows how to search these maps to find the information it needs.
This representation of the date can be problematic. As the server cannot "read" the value of a key to find a second key inside it, it will be necessary to duplicate the data. For instance in the case of passwords, one might want to be able to look them up by using the login name or by the user ID or UID (a unique identifier for each user on the network). This will lead to an information redundancy, as can be seen by the presence of the passwd.byname and passwd.byuid files. Consequently there will be a new map created for every key, meaning that the data has to be transmitted twice in case of a change.
Three parameters are needed for a client to find the information it needs from the database :
This leads to a very flexible system, since setting up a new domain is reduced to the creation of the directory /var/yp/new_domain, copying the Makefile and executing it with the correct options.
YP's functionality is essentially based on Remote Procedure Calls (RPCs) accepting requests between the server and its clients.
The RPC portmapper (portmap) is a program that converts the RPC program numbers into port numbers. When an RPC is started, it will tell portmap which port it will use and the RPC program numbers it is administering. When a client wants to make an RPC request to a certain program number, it will first contact the portmap server to obtain the port number on which the program is running. After obtaining this port number it addresses the RPC packets to the corresponding port. The client/server model of YPs is nothing more than a particular case of client/server RPC.
The file yp_prot.h contains the structures and the prototypes of 11 functions defining the RPC protocol between the clients and the YP server.