Yellow Pages 3: The Server Side

ArticleCategory:

System Administration

AuthorImage:

TranslationInfo:[Author + translation history. mailto: or http://homepage]

Original in frFrédéric Raynal

fr to deBernhard Spanyar

de to enGuido Socher

en to en Lorne Bailey

AboutTheAuthor:

Frédéric Raynal is currently preparing his final theses at the INRIA in computer science. I often listen to the latest album of "16 Horse Power" (very fine, but also powerful) and "The for carnation", a little cold but still very good.

Abstract:

In this article we present a step by step installation of a NIS server. We will take a look at the required software, configuration files and the creation of a database.

ArticleIllustration:

ArticleBody:

Introduction

We have seen in the previous article how to configure a NIS client. We emphasized the security risks when running this service. It is questionable whether we should really call it a security risk. The developers of NIS had a closed LAN or a network separated via firewalls in mind when they designed NIS and were not really concerned about security.

In this article we will now see how to configure the server side and we will give some tips on how to use NIS.

NIS and NYS

There are two variants of NIS, the "traditional NIS" and NYS - but most people just call them both NIS. For an administrator there's hardly any difference between the two since they both configure clients and servers the same way. The new version, NYS, supports such things as shadow passwords.

In this article we talk about this more recent version of ypserv. We recommend a version later than 1.3.2 since we want to support shadow passwords. In other words, we are really talking about NYS and not the "traditional NIS", although we will use the word NIS throughout the article.

The NIS server

There are two servers : ypserv and yps. According to the author of the NIS-HOWTO there is no real difference between them, but yps is no longer maintained by its author, so we will only concern ourselves with ypserv.

First we will explain the steps that are necessary to install the server. In this article we are working on a host called "charly". The NIS domain is "bosley" and the slave servers are "iron1", "iron2" and "iron3".

Installation

As a first step, you need to make sure that the portmap daemon is running. If it's not you must start it.

Next, you need to decide the name of the NIS domain. This is not a domain from DNS but a name for the YP region. For security reasons, this name should be different from the name of the NIS server.

The domain is set with the command domainname :-) In our case this is:

root@charly >> /bin/domainname bosley

This command sets the NIS domain name only in RAM. To make it permanent you need to add the following line to /etc/sysconfig/network:

NISDOMAIN=bosley

This will then set the NIS domain name automatically at the next reboot.

Before we can start the ypserv daemon we need to configure it by editing the file /etc/ypserv.conf. This is a ASCII file with the following syntax:

Comments: these are lines starting with a #-sign.
Options for the daemon: The syntax is as shown below.
option: [yes|no]
Possible options are dns, the server will ask DNS to find the clients which are not in the hosts-maps, sunos_kludge, obsolete and xfr_check_port to use a port below 1024 for the server (default is yes).
Additional rules: The format for those is:
host:map:security:mangle[:field]
These rules decide who may see what information.

The man-page of ypserv.conf gives very clear explanations for all options and possibilities.

Now we can start the server:

root@charly >> /etc/rc.d/init.d/ypserv start

To run the server automatically at startup you need to edit the rc.d files or under Redhat you can run the command :

root@charly >> /sbin/chkconfig --level 345 ypserv on

To verify that everything is running use:

root@charly >> /usr/sbin/rpcinfo -u localhost ypserv
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting

Before going into details we should remember what we learned in the first article. There are 2 types of servers: master and slave. The slave servers only have a copy of the master server's 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 database needs to be maintained on the master only. It is copied over to the clients.

Everything is now ready ... except for the database. We have to generate it first. Generate means, use a Makefile ;-] The Makefile is pre-prepared so we just need to change a few lines. The Makefile is in /var/yp and is clearly commented. The most important line is the one where the maps are defined. On host charly that is:

all: passwd group hosts rpc services netid protocols mail shadow
# netgrp publickey
# networks ethers bootparams printcap \
# amd.home auto.master auto.home passwd.adjunct

In addition to the default you should add shadow password handling. To do that you need to add "passwd" and "shadow" to the list of files and set the value of the variable MERGE_PASSWD to true. MERGE_PASSWD determines if the files /etc/passwd and /etc/shadow are merged.

A final detail before we start the server: Access writes. There are two methods to control the access. Either ypserv's own methods or via tcp_wrapper. We will talk about ypserv's own security methods.

If you only have binaries of ypserv then the option -v prints out the configuration options that ypserv was compiled with. We need option "securenets" to use ypserv's own access control.

root@charly >> /usr/sbin/ypserv -v
ypserv - NYS YP Server version 1.3.9 (with securenets)

The file /var/yp/securenets contains pairs of netmask/network numbers which we can use to control server access. By default this is:

0.0.0.0 0.0.0.0

This allows access for everybody in the world. We must change that. To allow connections from any host within the 131.234.223.0 network you would write:

255.255.255.0 131.234.223.0

Please note that you can only have IP addresses in this file. It is not possible to use host names.

Now we can create the NIS-Database using the command ypinit. By default (defined in the Makefile) it will read the files from /etc and write to /var/yp. The files that will go into our database are /etc/passwd, /etc/group, /etc/hosts, /etc/networks, /etc/services, /etc/protocols, /etc/netgroup, /etc/rpc.

The option -m allows you to initialize the Server with raw data (-m for master), the option -s copies the master database to a slave (-s like slave).

On Charly we initialize our database as follows:

root@charly >> /usr/lib/yp/ypinit -m
At this point, we have to construct a list of the hosts which will run NIS
servers. localhost is in the list of NIS server hosts. Please continue to add
the names for the other hosts, one per line. When you are done with the
list, type a <control D>.
        next host to add: localhost
        next host to add: iron1
        next host to add: iron2
        next host to add: iron3
        next host to add:
The current list of NIS servers looks like this:

localhost
iron1
iron2
iron3

Is this correct? [y/n: y] y
We need some minutes to build the databases...
Building /var/yp/bosley/ypservers...
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/bosley'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
Updating shadow.byname...
# shadow publickey # networks ethers bootparams printcap \
# amd.home auto.master auto.home passwd.adjunct
gmake[1]: Leaving directory `/var/yp/bosley'

Et voila, the database is ready :). On each of the slave servers the command ypinit needs now to be executed:

root@iron3 >> /usr/lib/yp/ypinit -s charly

To test the system use one of the servers as a client and run a request from it:

root@iron3 >> ypcat passwd mulder:x:500:100::/home/mulder:/bin/csh scully:x:501:100::/home/scully:/bin/bash

You can also see that the shadow passwords are working. We have an "x" where the password should be :)

Installation of a NIS-Server

Initialize portmap
Define the NIS-Domain Name
Prepare the configuration files of the NIS server: /etc/ypserv.conf
Start the ypserv daemon
Define the maps in /var/yp/Makefile
Set the access rights to the NIS server in /var/yp/securenets
Create the NIS master database using the command ypinit -m
Create the NIS slave database using the command ypinit -s <master server>

Updating the NIS database

As soon as one of the maps has changed, i.e. to add a new server or user you must update the NIS database.

To add a new slave server run the command
/usr/lib/yp/ypinit -s charly
on the new server and to add its name to the file /var/yp/ypservers on the master server.

If you add a new user then several maps will change (passwd, shadow, alias, etc ...).

After the maps have been changed you just run make in /var/yp/ on the master server. This will update the databases and push the data (using yppush) to the slaves.

The program rpc.ypxfrd can speed up the transaction between master and slave by just copying them from the master instead of re-creating them on the slave. rpc.ypxfrd should be started at the same time as ypserv and solely on the master. This program is only needed if you have very big maps.

A few tips

Everybody knows that NIS is not secure. However the services are very useful once you extend your network to more than just one host. Therefore, you must implement some additional security measures.

Just as there are passwords which are easy to guess, there are predictable NIS domain names. Obvious candidates are machine names and it is possible to test the NIS domain with ypwhich.

The NIS domain name shows up in several places, especially in the directory /var/yp and its subdirectories. They should not be readable for anyone other than root and must not be exported via NFS.

It doesn't hurt to use tcp_wrapper in addition to /var/yp/securenets to control the portmap process.

It is also an advantage to have no default route on the NIS server and use only static routing to the clients and the slave servers. That way the server can not answer requests that come from unknown hosts.

Firewall rules on the router are a very effective measures to control access to the NIS servers.

These security measures do not improve the security of NIS itself but the framework around it. Despite these problems, is NIS a very valuable tool.

Documentation

NIS-HOWTO : like all HOWTOs very good and extensive documentation
http://www.suse.de/~kukuk/ : He works on NIS and NIS+. His page contains several FAQs
The Network Administrators' Guide which can be found at http://www.linuxdoc.org/LDP/nag