Chapter 5: NIS in the NERC File Structure


Back to contents

Introduction

Network Information Services (NIS), ( formerly known as YP), is a 'distributed data lookup service for sharing information between systems on a (Local Area) network'. This means a 'data' file can be modified in a single place but all other hosts on the network have access to the latest version without copying the data file round the hosts or NFS mounting the data directory everywhere. This is achieved by using a NIS makefile to translate the ASCII data file into NIS database files, copies of which are kept on one or more hosts, and the information is served out in response to requests across the network from remote hosts. All the UNIX operating systems used in NERC support the sharing of passwd, group, services and other files via NIS. NIS uses the concept of a domain to mean a number of hosts on a network who share the same NIS data files. Within the domain there will be one host known as the NIS master server, possibly one or more other hosts known as slave or secondary servers and the rest of the hosts are clients. This is not the same as a DNS domain, which is a Wide Area concept.
 

NIS Master

This host  has the one and only copy of the raw ASCII data files, eg. /etc/services, therefore there can only be one master host per domain. You must be on this host to edit the data file and 'make' them into NIS databases; the act of 'making' will propagate the changes out to any NIS slaves.
 

NIS Slave

Slave servers (sometimes known as secondary servers) are optional and hold copies of the NIS database files to share the load of answering requests from NIS client machines and to act as a backup in the event that the NIS master host goes down.
 

NIS Client

The majority of hosts in a NIS domain will be clients; they don't hold any NIS information. Instead, at boot time they start up a ypbind daemon which binds to the first NIS server (master or slave) that answers their request to join that particular NIS domain.This is known as 'broadcasting' and avoids the need for a client to know which the servers are at any time. However this is not universally applicable and for some hosts and under some circumstances the ypbind daemon has to be given a list of possible servers ( Solaris on first bootup in a new domain, Cray always). Once the 'bind' is complete, that server will respond to all the client's requests for NIS served information. If the client's server goes down for some reason the client may 'hang' while it searches for another server on the domain, but should in any case rebind within 10 minutes. If there is no operational NIS server the entire network will hang until a server returns.
 

NIS in NERC

In its simplest form NIS can supply information for the system files which normally live in /etc - for example passwd, group, services, netgroup, networks, rpc and one or two others. In NERC we have added extra maps to identify user home directories and the locations of applications software, among others. These are used by the automounter. The Makefile can be customised, as we have done, to pick up some of the maps from directories other than /etc. In the NERC implementation the NIS map sources are kept in /nerc/<domain>/yp. These include passwd, group, netgroup and hosts - but not services or rpc which MUST be left in /etc.

Useful NIS commands:

ypwhich Shows which yp server is serving the current host.

ypwhich -m Shows which maps are being served and which host holds the 'raw' ASCII file, ie. the NIS master.

ypcat <map> Lists (cat) the contents of the NIS database, NOT the 'raw' ascii file. Good for checking whether a NIS make succeeded.

ypcat -k <map> Includes the database lookup 'key' in the listing. Useful for checking automounter maps.

ypmatch <value> <map> Good for finding a single entry in a map

rpcinfo -b ypserv 2 To check a workstation can see the NIS servers. Does a broadcast.

Administering NIS

NIS is controlled by a set of maps, most of which are in source form, and a Makefile. The Makefile lives in /var/yp.    The maps may be edited using any UNIX editor.

Making the Maps

Each time a source file is edited, for example when adding a new user to the passwd file, the map is remade by either

cd /var/yp

./make <mapname>

or on an IRIX system

./ypmake <mapname>

The new map will be available immediately everywhere, as it is 'pushed' to the slaves as part of the make process.


Back to contents

This page last updated February 19th 1998 by rfcr@itss.nerc.ac.uk