|This document is available in: English Deutsch Francais Nederlands Portugues Russian Turkce|
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 ;-)
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).
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.
|program 100007 version 2 ready and waiting|
|program 100007 version 1 ready and waiting|
|program 100007 version 2 ready and waiting|
|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|
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
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:
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 :
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.
Webpages maintained by the LinuxFocus Editor team
© Frédéric Raynal, FDL
Click here to report a fault or send a comment to LinuxFocus
2001-06-29, generated by lfparser version 2.16