Yellow Pages, part 1

ArticleCategory:

AuthorImage:

TranslationInfo:

Original in fr Frédéric Raynal

fr to en: Jo Simons

en to en:Lorne Bailey

AboutTheAuthor:

Abstract:

ArticleIllustration:

ArticleBody:

Introduction

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.

How does it work

Structure

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 maps

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 :

1. the domain name : this is the name of the database on the YP server
2. the map name
3. the key name

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.

Remote Procedure Calls (RPC)

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.

• YPPROC_DOMAIN and YPPROC_DOMAIN_NOACK allow the clients to find a server for a given domain.
• The functions YPPROC_MATCH, YPPROC_FIRST, YPPROC_NEXT and YPPROC_ALL allow access to the maps data.
• YPPROC_XFR is called by yppush to signal the slave servers that the map on the master server has changed and they need to update their copies.
• YPPROC_CLEAR cleans out the cache and the file handles. This function is called after updating a map, for instance after the makedbm -c command.
• YPPROC_MASTER, YPPROC_ORDER and YPPROC_MAPLIST allow to obtain special information about the maps. For instance, to change the password, the yppasswd program makes a call to YPPROC_MASTER to determine the server before changing the password.

Conclusion