Home  |  Map  |  Index  |  Search

Convert to GutenPalm or to PalmDoc by Frédéric Raynal About the author: 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 ;-) Content: ypbind Last details Talkback form for this article

Yellow Pages 2 : The client side

Abstract:

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+

Introduction

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

ypbind

ypbind establishes a link between the client and the NIS server. This link is visible in the directory /var/yp/binding¹ 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:

• domain nisdomain server hostname : the client will look for hostname for the domain nisdomain ;
• domain nisdomain broadcast : the client broadcasts on the local network concerning nisdomain ;
• ypserver hostname : the client addresses hostname directly for the local domain. In this configuration, the server's IP address has to be included in /etc/hosts.

If this configuration file is wrong or if it doesn't exist, ypbind will broadcast² 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 :
   • Executing a "rpc -p localhost" should give you the following information :

     program	vers	proto	port
     100000	2	tcp	111	portmapper
     100000	2	udp	111	portmapper
     100007	2	tcp	637	ypbind
     100007	2	udp	639	ypbind

     or

     program	vers	proto	port
     100000	2	tcp	111	portmapper
     100000	2	udp	111	portmapper
     100007	2	udp	758	ypbind
     100007	1	udp	758	ypbind
     100007	2	tcp	761	ypbind
     100007	1	tcp	761	ypbind

   or you can try:
   • "rpcinfo -u localhost ypbind" which should give you :
     

     program 100007 version 2 ready and waiting

     ou

     program 100007 version 1 ready and waiting

     program 100007 version 2 ready and waiting

   depending on the version of ypbind. The important message is the one about version 2.

Last details

• /etc/host.conf : add "nis" for host lookup ;
• /etc/passwd : add the following line:
  +::::::
  This will autorise all the users present in the server map to connect to the client. We can refine these authorizations using the symbols + and - to authorize or forbid access to the client. In order to forbid the guest user, you would add the line
  -guest::::::
  The fields you don't want to modify, should remain empty It is possible however to add more:
  +me::::::/bin/ksh
  The user "me" will use ksh instead of his/her usual shell (which is defined in /etc/passwd of the NIS server).
  As a final important note, I want to add that NIS perfectly supports the use of netgroups³
  +@sysadmins:::::::
  will authorize connections of the members of the netgroup sysadmin.
• /etc/group (and/or /etc/shadow for certain versions of libc) : like in /etc/passwd, you have to add
  +:
  You can also play with the group authorizations by adding + and -
• /etc/nsswitch.conf : the Network Services Switch enables us to specify in which order the information has to be searched, in the same way as with /etc/host.conf. The choices are:

  nisplus	lookup via NIS+ (i.e. NIS version 3, a secure version of NIS)
  nis	lookup via NIS (NIS version 2, alias YPs
  dns	lookup via a DNS (Domain Name Server)
  files	lookup in the local files
  db	lookup in the database /var/db

  After each lookup option, you can use a command of the following form
  `[' ( `!'? STATUS `=' ACTION )+ `]'
  where :
  • STATUS => "success" or "notfound" or "unavail" or "tryagain"
  • ACTION => "return" or "continue"
  Depending on the version of libc that is used, the lookups aren't all the same. For instance, the shadow passwords aren't managed with libc5. The supported services on a machine use a library /lib/libnss_SERVICE.so.X For more information on this service, see the man pages of 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.

yp-tools

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

• domainname : returns or fixes (depending on the option) the NIS domain name ;
• ypcat : shows the values of all the keys present in the NIS map ;
• ypmatch : shows the values of one or more keys present in an NIS map ;
• ypset : specifies which NIS server ypbind connects to ;
• ypwhich : returns the name of the NIS server. With -m as an argument followed by a map name, it returns the name of the master map.
• yppoll : takes a map as argument and returns the domain name of the master server.

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

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)"

Conclusion

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.

Footnotes

... var/yp/binding¹

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

... broadcast²

This means that the message is transmitted on the entire subnet without a specific destination address (type X.Y.0.0)

... netgroup³

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.

Talkback form for this article

2001-06-29, generated by lfparser version 2.16