Yellow Pages 2 : The client side


System Administration




Original in fr Frédéric Raynal

fr to en Jo Simons

en to en:Lorne Bailey


Frédéric Raynal is writing his thesis in informatics at the INRIA. He likes to read (Tolkien as well as Balzac) and to listen to music (from Mozart to Philip Glass and from Led Zeppelin to Massive Attack over Björk and Boris Vian, but carefully avoiding rap, techno and some other kinds of noise ;-)


The previous article was an introduction to the basic concepts of yellow pages (YPs). In this one, we will see how to configure your client, a practical example showing how the client works and a presentation of the different tools that come along. At the end, we will say something about NIS+





The client side of services connected to yellow pages is essentially based on the ypbind daemon: it sends the requests to the YP server. We will first explain how it works and how to configure it. After that, we will also see how the NIS protocol works. The last part of the article is dedicated to the different client side tools of YP (yp-tools).

Configuring your NIS client

The only action needed to run an NIS client on a machine is to run the ypbind daemon.


ypbind establishes a link between the client and the NIS server. This link is visible in the directory /var/yp/binding1 in the file that's usually named domainname.version. The only supported version at the time being is version 2. So, if my NIS domain name is "messiah", the file name will be messiah.2

The program ypbind belongs to the super user (i.e. root), consequently it has to be located in /sbin, or in /usr/sbin.

When run, ypbind will go and find its instructions in the file /etc/yp.conf. This file consists of the following:

If this configuration file is wrong or if it doesn't exist, ypbind will broadcast2 a search on the local network for the NIS server of the local domain.

Some basic actions allow us to verify that ypbind is configured correctly.

  1. create your file /etc/yp.conf ;
  2. verify that portmap is working (ps aux | grep portmap). If it isn't, we want to launch it. This program associates the computer's TCP/IP ports (or UDP/IP) with the programs. During the initialization of an RPC server, it signals to portmap the ports it is listening on and the program numbers it wants to launch. When a client emits an RPC request to a given program number, it will first contact portmap to know which port the RPC packets have to be sent. This explanation shows that it is necessary to have portmap running before ypbind ;
  3. create the directory /var/yp ;
  4. launch ypbind ;
  5. use the command rpcinfo to make sure that ypbind is working correctly : or you can try: depending on the version of ypbind. The important message is the one about version 2.
Now that ypbind is working correctly, your machine has become an NIS client. So you can use it to send requests to your server. For instance, "ypcat passwd.byname" will give you all the passwords, sorted by user name, that are present in the corresponding directory.

Last details

Some files still need some minor modifications to make the YPs work efficiently: The shadow passwords on NIS are only supported with glibc2.x. You have to remember to specify them in nsswitch.conf

The NIS protocol

Now that our NIS client is fully operational, we will see how it retrieves the information it needs.

When a client needs a piece of information sitting in a map of YPs, it starts by looking for an YP server. To find one, it opens a TCP connection to the local ypbind. The client informs it of the domain (the NIS domain) to which it belongs and ypbind broadcasts by means of the function RPC YPPROC_DOMAIN_NOACK. Only the NIS servers that serve this domain respond with an ACK. The others keep silent.

ypbind sends the client the result of the lookup (success or failure) and, if it has it, the address of the first YP server that answered. The client can now address the server with its request by specifying the domain, the map, and the key.

This protocol is rather slow since it uses TCP connections. To make things worse, it also uses a lot of sockets. To avoid this, ypbind doesn't wait for a client to contact it before finding the servers. In fact, it keeps a list of servers for each domain in the file /var/yp/binding/<domainename>.<version> and regularly verifies whether they work properly.


This section briefly presents some tools of the yp-tools package. To learn more about them you can invoke a very detailed man page for each of these instructions ;-P

A Few Words on NIS+

Up until now we haven't spoken about a variant of NIS. On a network, using NIS poses a great security risk. For instance, if the NIS server is poorly protected and if a person with bad intentions discovers:

  1. the NIS domain name
  2. the IP address of an NIS client
it becomes very easy to spoof (act as if it were this machine) this machine's IP address and send a ypcat passwd to retrieve the password list with the greatest ease. :-(

NIS+ offers an extra security layer by integrating an authentication protocol based on the exchange of keys and it supports data encryption.

The information is kept in tables, which are located in different directories. Every column of a table has a header specifying, for instance, whether the data is "case sensitive", in binary format, etc ...

The aforementioned structure allows simply to maintain access rights on directories and tables, and on the columns of the tables as well. This means it is possible to prohibit access to the password table by any user that is not authenticated on the NIS+ server. But it allows all the authenticated users access on the entire password table, except to the field "passwd". Only the owner of the "passwd" field can retrieve that.

There are 4 levels of security :

  1. Nobody : The user is not authenticated ;
  2. Owner : The user is authenticated as the owner ;
  3. Group : The user is authenticated and belongs to a group having access to this object ;
  4. World : The user is authenticated but he is not the owner and he doesn't belong to a group with access for this object .

In this configuration, root is just another user ... well, almost ;-) If she doesn't have the proper permissions, she cannot see the other user's passwords anymore. So she would not be able to authenticate as an other user anymore ... but, she can still easily perform an su :)

The data circulating on the network will not be encrypted, except for the passwords : no password is transmitted clear text on the network.

NIS+ is a powerful tool ... but it is hard to set up. Thorsten Kuduk writes the following (he works on NIS, NIS+, NIS-HOWTO ... so he knows what he is talking about ;-) :
"The choice between NIS and NIS+ is easy to make : use NIS as long as you don't have important security needs. NIS+ is a lot more problematic to administrate (especially on the server side)"


We learned how to add a new machine to an existing network, where an NIS server is already set up. In the following article we will see how to configure the server and how it works.


... var/yp/binding1
The exact locations of the files aren't often specified, since they vary from one distribution to another. For instance, to set up a ypbind daemon started at boot time : /etc/init.d/nis, /sbin/init.d/ypclient, /etc/rc.d/init.d/ypbind, /etc/rc.local
... broadcast2
This means that the message is transmitted on the entire subnet without a specific destination address (type X.Y.0.0)
... netgroup3
The file /etc/netgroup defines groups composed of triplets (host, user, domain) serving to verify permissions when you use remote commands (like remote logins, shells or mount). Consult the man page for more details.