Yellow Pages 2 : The client side
ArticleCategory:
System Administration
AuthorImage:
![[Frederic]](../../common/images/Frederic_Raynal.png)
TranslationInfo:
Original in fr Frédéric
Raynal
fr to en Jo
Simons
en to en:Lorne Bailey
AboutTheAuthor:
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
;-)
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+
ArticleIllustration:
![[Illustration]](../../common/images/illustration164.gif)
ArticleBody:
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
The only action needed to run an NIS client on a machine is to run
the ypbind daemon.
ypbind
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:
- 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
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.
- create your file /etc/yp.conf ;
- 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 ;
- create the directory /var/yp ;
- launch ypbind ;
-
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.
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:
- /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 netgroups3
+@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 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.
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:
- the NIS domain name
- 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 :
- Nobody : The user is not authenticated ;
- Owner : The user is authenticated as the owner ;
- Group : The user is authenticated and belongs to a group
having access to this object ;
- 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/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.