LDP/LDP/howto/docbook/NIS-HOWTO.sgml

2416 lines
64 KiB
Plaintext

<!DOCTYPE Article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<Article id="index">
<ArtHeader>
<Title>The Linux NIS(YP)/NYS/NIS+ HOWTO</Title>
<AUTHOR
>
<FirstName>Thorsten Kukuk</FirstName>
</AUTHOR
>
<PubDate>v1.3, 1 July 2003</PubDate>
<Abstract>
<Para>
<IndexTerm><Primary>HOWTOs!NIS</Primary></IndexTerm>
<IndexTerm><Primary>HOWTOs!YP</Primary></IndexTerm>
<IndexTerm><Primary>HOWTOs!NYS</Primary></IndexTerm>
<IndexTerm><Primary>HOWTOs!NIS+</Primary></IndexTerm>
This document describes how to configure Linux as NIS(YP) or NIS+ client
and how to install as NIS server.
</Para>
</Abstract>
</ArtHeader>
<Sect1 id="introduction">
<Title>Introduction</Title>
<Para>
More and more, Linux machines are installed as part of a network of
computers. To simplify network administration, most networks (mostly
Sun-based networks) run the Network Information Service. Linux machines
can take full advantage of existing NIS service or provide NIS service
themselves. Linux machines can also act as full NIS+ clients, this
support is in beta stage.
</Para>
<Para>
This document tries to answer questions about setting up NIS(YP) and NIS+
on your Linux machine. Don't forget to read
<XRef LinkEnd="portmapper">.
</Para>
<Para>
The NIS-Howto is edited and maintained by
</Para>
<Para>
<Screen>
Thorsten Kukuk, &#60;kukuk@suse.de&#62;
</Screen>
</Para>
<Para>
The primary source of the information for the initial NIS-Howto was from:
</Para>
<Para>
<Screen>
Andrea Dell'Amico &#60;adellam@ZIA.ms.it&#62;
Mitchum DSouza &#60;Mitch.DSouza@NetComm.IE&#62;
Erwin Embsen &#60;erwin@nioz.nl&#62;
Peter Eriksson &#60;peter@ifm.liu.se&#62;
</Screen>
</Para>
<Para>
who we should thank for writing the first versions of this document.
</Para>
<Sect2>
<Title>New Versions of this Document</Title>
<Para>
You can always view the latest version of this document on the
World Wide Web via the
URL <ULink
URL="http://www.linux-nis.org/nis-howto/HOWTO/NIS-HOWTO.html"
>http://www.linux-nis.org/nis-howto/HOWTO/NIS-HOWTO.html</ULink
>.
</Para>
<Para>
New versions of this document will also be uploaded to various
Linux WWW and FTP sites, including the LDP home page.
</Para>
<Para>
Links to translations of this document could be found at
<ULink
URL="http://www.linux-nis.org/nis-howto/"
>http://www.linux-nis.org/nis-howto/</ULink
>.
</Para>
</Sect2>
<Sect2>
<Title>Disclaimer</Title>
<Para>
Although this document has been put together to the best of my
knowledge it may, and probably does contain errors. Please read any
README files that are bundled with any of the various pieces of
software described in this document for more detailed and accurate
information. I will attempt to keep this document as error free as
possible.
</Para>
</Sect2>
<Sect2>
<Title>Feedback and Corrections</Title>
<Para>
If you have questions or comments about this document, please feel
free to mail Thorsten Kukuk, at <ULink
URL="mailto:kukuk@linux-nis.org"
>kukuk@linux-nis.org</ULink
>. I welcome any
suggestions or criticisms. If you find a mistake with this
document, please let me know so I can correct it in the next
version. Thanks.
</Para>
<Para>
Please do <Emphasis>not</Emphasis> mail me questions about special problems with your Linux
Distribution! I don't know every Linux Distribution. But I will try to add
every solution you send me.
</Para>
</Sect2>
<Sect2>
<Title>Acknowledgements</Title>
<Para>
We would like to thank all the people who have contributed (directly
or indirectly) to this document. In alphabetical order:
</Para>
<Para>
<Screen>
Byron A Jeff &#60;byron@cc.gatech.edu&#62;
Markus Rex &#60;msrex@suse.de&#62;
Miquel van Smoorenburg &#60;miquels@cistron.nl&#62;
Dan York &#60;dyork@lodestar2.com&#62;
Christoffer Bromberg &#60;christoffer@web.de&#62;
</Screen>
</Para>
<Para>
Theo de Raadt is responsible for the original yp-clients code.
Swen Thuemmler ported the yp-clients code to Linux and also ported
the yp-routines in libc (again based on Theo's work).
Thorsten Kukuk has written the NIS(YP) and NIS+ routines for
GNU libc 2.x from scratch.
</Para>
</Sect2>
</Sect1>
<Sect1 id="glossary">
<Title>Glossary and General Information</Title>
<Sect2>
<Title>Glossary of Terms
<IndexTerm><Primary>NIS!glossary</Primary></IndexTerm>
<IndexTerm><Primary>YP!glossary</Primary></IndexTerm>
<IndexTerm><Primary>NYS!glossary</Primary></IndexTerm>
<IndexTerm><Primary>NIS+!glossary</Primary></IndexTerm>
<IndexTerm><Primary>glossary!NIS/NYS/YP/NIS+</Primary></IndexTerm>
</Title>
<Para>
In this document a lot of acronyms are used. Here are the most
important acronyms and a brief explanation:
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>DBM</Term>
<ListItem>
<Para>
DataBase Management, a library of functions which
maintain key-content pairs in a data base.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>DLL</Term>
<ListItem>
<Para>
Dynamically Linked Library, a library linked to an
executable program at run-time.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>domainname</Term>
<ListItem>
<Para>
A name "key" that is used by NIS clients to be
able to locate a suitable NIS server that serves that
domainname key. Please note that this does not necessarily
have anything at all to do with the DNS "domain"
(machine name) of the machine(s).
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>FTP</Term>
<ListItem>
<Para>
File Transfer Protocol, a protocol used to transfer
files between two computers.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>libnsl</Term>
<ListItem>
<Para>
Name services library, a library of name service calls
(getpwnam, getservbyname, etc...) on SVR4 Unixes. GNU libc
uses this for the NIS (YP) and NIS+ functions.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>libsocket</Term>
<ListItem>
<Para>
Socket services library, a library for the socket
service calls (socket, bind, listen, etc...) on SVR4 Unixes.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>NIS</Term>
<ListItem>
<Para>
Network Information Service, a service that provides
information, that has to be known throughout the network,
to all machines on the network. There is support for NIS
in Linux's standard libc library, which in the following text
is referred to as "traditional NIS".
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>NIS+</Term>
<ListItem>
<Para>
Network Information Service (Plus :-), essentially NIS on
steroids. NIS+ is designed by Sun Microsystems Inc. as a
replacement for NIS with better security and better handling
of &lowbar;large&lowbar; installations.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>NYS</Term>
<ListItem>
<Para>
This is the name of a project and stands for NIS+, YP and Switch
and is managed by Peter Eriksson &lt;peter@ifm.liu.se&#62;. It contains
among other things a complete reimplementation of the NIS (= YP) code
that uses the Name Services Switch functionality of the NYS library.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>NSS</Term>
<ListItem>
<Para>
Name Service Switch. The /etc/nsswitch.conf file determines the order
of lookups performed when a certain piece of information is requested.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>RPC</Term>
<ListItem>
<Para>
Remote Procedure Call. RPC routines allow C programs to
make procedure calls on other machines across the network.
When people talk about RPC they most often mean the Sun RPC
variant.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>YP</Term>
<ListItem>
<Para>
Yellow Pages(tm), a registered trademark in the UK of
British Telecom plc.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>TCP-IP</Term>
<ListItem>
<Para>
Transmission Control Protocol/Internet Protocol. It is the
data communication protocol most often used on Unix machines.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
</Sect2>
<Sect2>
<Title>Some General Information
<IndexTerm><Primary>NIS!general information</Primary></IndexTerm>
<IndexTerm><Primary>YP!general information</Primary></IndexTerm>
<IndexTerm><Primary>NYS!general information</Primary></IndexTerm>
<IndexTerm><Primary>NIS+!general information</Primary></IndexTerm>
</Title>
<Para>
The next four lines are quoted from the Sun(tm) System &amp; Network
Administration Manual:
</Para>
<Para>
<Screen>
"NIS was formerly known as Sun Yellow Pages (YP) but
the name Yellow Pages(tm) is a registered trademark
in the United Kingdom of British Telecom plc and may
not be used without permission."
</Screen>
</Para>
<Para>
NIS stands for Network Information Service. Its purpose is to
provide information, that has to be known throughout the network,
to all machines on the network. Information likely to be
distributed by NIS is:
<ItemizedList>
<ListItem>
<Para>
login names/passwords/home directories (/etc/passwd)
</Para>
</ListItem>
<ListItem>
<Para>
group information (/etc/group)
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
If, for example, your password entry is recorded in the NIS
passwd database, you will be able to login on all machines on the
network which have the NIS client programs running.
</Para>
<Para>
Sun is a trademark of Sun Microsystems, Inc. licensed to
SunSoft, Inc.
</Para>
</Sect2>
</Sect1>
<Sect1 id="which">
<Title>NIS, NYS or NIS+ ?</Title>
<Sect2>
<Title>libc 4/5 with traditional NIS or NYS ?
<IndexTerm><Primary
>libc4/5, use with NIS/NYS</Primary></IndexTerm>
<IndexTerm><Primary
>NIS/NYS, use with libc4/5</Primary></IndexTerm>
</Title>
<Para>
The choice between "traditional NIS" or the NIS code in the NYS library
is a choice between laziness and maturity vs. flexibility and love of
adventure.
</Para>
<Para>
The "traditional NIS" code is in the standard C library and has been
around longer and sometimes suffers from its age and slight
inflexibility.
</Para>
<Para>
The NIS code in the NYS library requires you to recompile the libc
library to include the NYS code into it (or maybe you can
get a precompiled version of libc from someone who has already done it).
</Para>
<Para>
Another difference is that the traditional NIS code has some support
for NIS Netgroups, which the NYS code doesn't. On the other hand
the NYS code allows you to handle Shadow Passwords in a transparent
way. The "traditonal NIS" code doesn't support Shadow Passwords over NIS.
</Para>
</Sect2>
<Sect2>
<Title>glibc 2 and NIS/NIS+
<IndexTerm><Primary
>glibc2, use with NIS/NIS+</Primary></IndexTerm>
<IndexTerm><Primary
>NIS/NIS+, use with glibc2</Primary></IndexTerm>
</Title>
<Para>
Forgot all this if you use the new GNU C Library 2.x (aka libc6). It
has real NSS (name switch service) support, which makes it very flexible,
and contains support for the following NIS/NIS+ maps: aliases, ethers, group,
hosts, netgroups, networks, protocols, publickey, passwd, rpc, services
and shadow. The GNU C Library has no problems with shadow passwords over NIS.
</Para>
</Sect2>
<Sect2>
<Title>NIS or NIS+ ?
<IndexTerm><Primary
>NIS vs. NIS+</Primary></IndexTerm>
</Title>
<Para>
The choice between NIS and NIS+ is easy - use NIS+ only if you have
severe security needs. NIS+ is much more problematic to administer
(it's pretty easy to handle on the client side, but the server side
is horrible). Another problem is that the support for NIS+ under Linux
contains a lot of bugs and that the development has stopped.
</Para>
</Sect2>
</Sect1>
<Sect1 id="operation">
<Title>How it works</Title>
<Sect2>
<Title>How NIS works
<IndexTerm><Primary
>NIS/YP, theory of operation</Primary></IndexTerm>
</Title>
<Para>
Within a network there must be at least one machine acting as a NIS
server. You can have multiple NIS servers, each serving different NIS
"domains" - or you can have cooperating NIS servers, where one is the
master NIS server, and all the other are so-called slave NIS servers
(for a certain NIS "domain", that is!) - or you can have a mix
of them...
</Para>
<Para>
Slave servers only have copies of the NIS databases and receive these
copies from the master NIS server whenever changes are made to the
master's databases. Depending on the number of machines in your
network and the reliability of your network, you might decide to
install one or more slave servers. Whenever a NIS server goes down or
is too slow in responding to requests, a NIS client connected to that
server will try to find one that is up or faster.
</Para>
<Para>
NIS databases are in so-called DBM format, derived from ASCII
databases. For example, the files <filename>/etc/passwd</filename> and
<filename>/etc/group</filename> can be directly converted to DBM format
using ASCII-to-DBM translation software (<Command>makedbm</Command>,
included with the server software). The master NIS server should have
both, the ASCII databases and the DBM databases.
</Para>
<Para>
Slave servers will be notified of any change to the NIS maps, (via the
<Command>yppush</Command> program), and automatically retrieve the
necessary changes in order to synchronize their databases. NIS clients
do not need to do this since they always talk to the NIS server to read
the information stored in it's DBM databases.
</Para>
<Para>
Old ypbind versions do a broadcast to find a running NIS server.
This is insecure, due the fact that anyone may install a NIS server
and answer the broadcast queries. Newer Versions of ypbind
(ypbind-3.3 or ypbind-mt) are able to get the server from a
configuration file - thus no need to broadcast.
</Para>
</Sect2>
<Sect2>
<Title>How NIS+ works
<IndexTerm><Primary
>NIS+!theory of operation</Primary></IndexTerm>
</Title>
<Para>
NIS+ is a new version of the network information nameservice from Sun.
The biggest difference between NIS and NIS+ is that NIS+ has
support for data encryption and authentication over secure RPC.
</Para>
<Para>
The naming model of NIS+ is based upon a tree structure. Each node in
the tree corresponds to an NIS+ object, from which we have six types:
directory, entry, group, link, table and private.
</Para>
<Para>
The NIS+ directory that forms the root of the NIS+ namespace is called
the root directory. There are two special NIS+ directories:
org_dir and groups_dir. The org_dir directory consists of all
administration tables, such as passwd, hosts, and mail_aliases. The
groups_dir directory consists of NIS+ group objects which are used for
access control. The collection of org_dir, groups_dir and their parent
directory is referred to as an NIS+ domain.
</Para>
</Sect2>
</Sect1>
<Sect1 id="portmapper">
<Title>The RPC Portmapper
<IndexTerm><Primary
>RPC portmapper</Primary></IndexTerm>
<IndexTerm><Primary
>portmapper, RPC</Primary></IndexTerm>
<IndexTerm><Primary
>NIS!use of RPC portmapper</Primary></IndexTerm>
</Title>
<Para>
To run any of the software mentioned below you will need to run the
program /sbin/portmap. Some Linux distributions already have
the code in the /sbin/init.d/ or /etc/rc.d/ files to start up this
daemon. All you have to do is to activate it and reboot your Linux
machine. Read your Linux Distribution Documentation how to do this.
</Para>
<Para>
The RPC portmapper (portmap(8)) is a server that converts RPC program
numbers into TCP/IP (or UDP/IP) protocol port numbers. It must be
running in order to make RPC calls (which is what the NIS/NIS+ client
software does) to RPC servers (like a NIS or NIS+ server) on that machine.
When an RPC server is started, it will tell portmap what port number it
is listening to, and what RPC program numbers it is prepared to serve.
When a client wishes to make an RPC call to a given program number, it
will first contact portmap on the server machine to determine the port
number where RPC packets should be sent.
</Para>
<Para>
Since RPC servers could be started by inetd(8), portmap should
be running before inetd is started.
</Para>
<Para>
For secure RPC, the portmapper needs the Time service. Make sure, that the
Time service is enabled in /etc/inetd.conf on all hosts:
<Screen>
#
# Time service is used for clock syncronization.
#
time stream tcp nowait root internal
time dgram udp wait root internal
</Screen>
</Para>
<Para>
IMPORTANT: Don't forget to restart inetd after changes on its
configuration file !
</Para>
</Sect1>
<!-- openjade forbids underscore in id="" attribute; thus setting-NIS -->
<Sect1 id="setting-NIS">
<Title>What do you need to set up NIS?
<IndexTerm><Primary
>NIS!setting up</Primary></IndexTerm>
</Title>
<Sect2>
<Title>Determine whether you are a Server, Slave or Client.
<IndexTerm><Primary
>NIS!determining system type</Primary></IndexTerm>
</Title>
<Para>
To answer this question you have to consider two cases:
</Para>
<Para>
<OrderedList>
<ListItem>
<Para>
Your machine is going to be part of a network with existing NIS servers
</Para>
</ListItem>
<ListItem>
<Para>
You do not have any NIS servers in the network yet
</Para>
</ListItem>
</OrderedList>
</Para>
<Para>
In the first case, you only need the client programs (ypbind, ypwhich,
ypcat, yppoll, ypmatch). The most important program is ypbind. This
program must be running at all times, which means, it should always appear
in the list of processes. It is a daemon process and needs to
be started from the system's startup file (eg. /etc/init.d/nis,
/sbin/init.d/ypclient, /etc/rc.d/init.d/ypbind, /etc/rc.local).
As soon as ypbind is running your system has become a NIS client.
</Para>
<Para>
In the second case, if you don't have NIS servers, then you will also
need a NIS server program (usually called ypserv). <XRef LinkEnd="ypserv">
describes how to set up a NIS server on your Linux machine using the
<Command>ypserv</Command>
daemon.
</Para>
</Sect2>
<Sect2>
<Title>The Software
<IndexTerm><Primary
>NIS!library requirements</Primary></IndexTerm>
</Title>
<Para>
The system library "/usr/lib/libc.a" (version 4.4.2 and better) or the
shared library "/lib/libc.so.x" contain all necessary system calls to
succesfully compile the NIS client and server software. For the
GNU C Library 2 (glibc 2.x), you also need /lib/libnsl.so.1.
</Para>
<Para>
Some people reported that NIS only works with "/usr/lib/libc.a" version
4.5.21 and better so if you want to play it safe don't use older
libc's. The NIS client software can be obtained from:
</Para>
<Para>
<Screen>
Site Directory File Name
ftp.kernel.org /pub/linux/utils/net/NIS yp-tools-2.8.tar.gz
ftp.kernel.org /pub/linux/utils/net/NIS ypbind-mt-1.13.tar.gz
ftp.kernel.org /pub/linux/utils/net/NIS ypbind-3.3.tar.gz
ftp.kernel.org /pub/linux/utils/net/NIS ypbind-3.3-glibc5.diff.gz
</Screen>
</Para>
<Para>
Once you obtained the software, please follow the instructions which
come with the software. yp-clients 2.2 are for use with libc4 and libc5
until 5.4.20. libc 5.4.21 and glibc 2.x needs yp-tools 1.4.1 or later.
The new yp-tools 2.4 should work with every Linux libc. Since there was
a bug in the NIS code, you shouldn't use libc 5.4.21-5.4.35. Use libc
5.4.36 or later instead, or the most YP programs will not work.
ypbind 3.3 will work with all libraries, too. If you use gcc 2.8.x or
greater, egcs or glibc 2.x, you should add the ypbind-3.3-glibc5.diff
patch to ypbind 3.3. If possible you should avoid the use of ypbind 3.3
for security reasons.
ypbind-mt is a new, multithreaded daemon. It needs a Linux 2.2 kernel
and glibc 2.1 or later.
</Para>
</Sect2>
</Sect1>
<!-- openjade forbids underscore in id="" attribute; thus settingup-client -->
<Sect1 id="settingup-client">
<Title>Setting Up the NIS Client
</Title>
<Sect2>
<Title>The ypbind daemon
<IndexTerm><Primary
>NIS!ypbind daemon</Primary></IndexTerm>
<IndexTerm><Primary
>ypbind NIS daemon</Primary></IndexTerm>
<IndexTerm><Primary
>daemon!ypbind</Primary></IndexTerm>
</Title>
<Para>
After you have succesfully compiled the software you are now ready
to install it. A suitable place for the ypbind daemon is the directory
/usr/sbin. Some people may tell you that you don't need
ypbind on a system with NYS. This is wrong. ypwhich and ypcat need it
always.
</Para>
<Para>
You must do this as root of course. The other binaries (ypwhich,
ypcat, yppasswd, yppoll, ypmatch) should go in a directory accessible
by all users, normally /usr/bin.
</Para>
<Para>
Newer ypbind versions have a configuration file called /etc/yp.conf. You can
hardcode a NIS server there - for more info see the manual page for ypbind(8).
You also need this file for NYS.
An example:
<Screen>
ypserver 10.10.0.1
ypserver 10.0.100.8
ypserver 10.3.1.1
</Screen>
</Para>
<Para>
If the system can resolve the hostnames without NIS, you may use
the name, otherwise you have to use the IP address. ypbind 3.3 has a bug
and will only use the last entry (ypserver 10.3.1.1 in the example). All
other entries are ignored. ypbind-mt handle this correct and uses
that one, which answerd at first.
</Para>
<Para>
It might be a good idea to test ypbind before incorporating it in the
startup files. To test ypbind do the following:
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
Make sure you have your YP-domain name set. If it is not set then
issue the command:
<Screen>
/bin/domainname nis.domain
</Screen>
where <Literal remap="tt">nis.domain</Literal> should be some string _NOT_ normally
associated with the DNS-domain name of your machine! The reason for
this is that it makes it a little harder for external crackers
to retreive the password database from your NIS servers. If you
don't know what the NIS domain name is on your network, ask
your system/network administrator.
</Para>
</ListItem>
<ListItem>
<Para>
Start up "<Command>/sbin/portmap</command>" if it is not already running.
</Para>
</ListItem>
<ListItem>
<Para>
Create the directory <filename>/var/yp</filename> if it does not exist.
</Para>
</ListItem>
<ListItem>
<Para>
Start up <Command>/usr/sbin/ypbind</Command>
</Para>
</ListItem>
<ListItem>
<Para>
Use the command <Command>rpcinfo -p localhost</Command> to check if
ypbind was able to register its service with the portmapper. The
output should look like:
<Screen>
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100007 2 udp 637 ypbind
100007 2 tcp 639 ypbind
</Screen>
or
<Screen>
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
</Screen>
Depending on the ypbind version you are using.
</Para>
</ListItem>
<ListItem>
<Para>
You may also run <Command>rpcinfo -u localhost ypbind</Command>.
This command should produce something like:
<Screen>
program 100007 version 2 ready and waiting
</Screen>
or
<Screen>
program 100007 version 1 ready and waiting
program 100007 version 2 ready and waiting
</Screen>
The output depends on the ypbind version you have installed.
Important is only the "version 2" message.
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
At this point you should be able to use NIS client programs like ypcat,
etc... For example, <Command>ypcat passwd.byname</Command> will give
you the entire NIS password database.
</Para>
<Para>
IMPORTANT: If you skipped the test procedure then make sure you have set
the domain name, and created the directory
</Para>
<Para>
<Screen>
/var/yp
</Screen>
</Para>
<Para>
This directory MUST exist for ypbind to start up succesfully.
</Para>
<Para>
To check if the domainname is set correct, use the
<Command>/bin/ypdomainname</Command> from
yp-tools 2.2. It uses the yp_get_default_domain() function which is more
restrict. It doesn't allow for example the "(none)" domainname, which
is the default under Linux and makes a lot of problems.
</Para>
<Para>
If the test worked you may now want to change your startupd files
so that ypbind will be started at boot time and your system will
act as a NIS client. Make sure that the domainname will
be set before you start ypbind.
</Para>
<Para>
Well, that's it. Reboot the machine and watch the boot messages to see
if ypbind is actually started.
</Para>
</Sect2>
<Sect2>
<Title>Setting up a NIS Client using Traditional NIS
<IndexTerm><Primary
>NIS!client setup</Primary></IndexTerm>
</Title>
<Para>
For host lookups you must set (or add) "nis" to the lookup order line
in your <filename>/etc/host.conf</filename> file. Please read the
manpage "resolv+.8" for more details.
</Para>
<Para>
Add the following line to <filename>/etc/passwd</filename>
on your NIS clients:
</Para>
<Para>
<Screen>
+::::::
</Screen>
</Para>
<Para>
You can also use the + and - characters to include/exclude or change
users. If you want to exclude the user guest just add -guest to your
<filename>/etc/passwd</filename> file.
You want to use a different shell (e.g. ksh) for
the user "linux"? No problem, just add "+linux::::::/bin/ksh"
(without the quotes) to your <filename>/etc/passwd</filename>. Fields
that you don't want
to change have to be left empty. You could also use Netgroups for
user control.
</Para>
<Para>
For example, to allow login-access only to miquels, dth and ed, and
all members of the sysadmin netgroup, but to have the account data
of all other users available use:
</Para>
<Para>
<Screen>
+miquels:::::::
+ed:::::::
+dth:::::::
+@sysadmins:::::::
-ftp
+:*::::::/etc/NoShell
</Screen>
</Para>
<Para>
Note that in Linux you can also override the password field, as we did
in this example. We also remove the login "ftp", so it isn't known any
longer, and anonymous ftp will not work.
</Para>
<Para>
The netgroup would look like
<Screen>
sysadmins (-,software,) (-,kukuk,)
</Screen>
</Para>
<Para>
IMPORTANT: The netgroup feature is implemented starting from libc 4.5.26.
If you have a version of libc earlier than 4.5.26, every user in the
NIS password database can access your linux machine if you run "ypbind" !
</Para>
</Sect2>
<Sect2>
<Title>Setting up a NIS Client using NYS
<IndexTerm><Primary
>NYS!client setup</Primary></IndexTerm>
</Title>
<Para>
All that is required is that the NIS configuration file
(/etc/yp.conf) points to the correct server(s) for its information.
Also, the Name Services Switch configuration file (/etc/nsswitch.conf)
must be correctly set up.
</Para>
<Para>
You should install ypbind. It isn't needed by the libc, but the NIS(YP)
tools need it.
</Para>
<Para>
If you wish to use the include/exclude user feature (+/-guest/+@admins),
you have to use "passwd: compat" and "group: compat" in nsswitch.conf.
Note that there is no "shadow: compat"! You have to
use "shadow: files nis" in this case.
</Para>
<Para>
The NYS sources are part of the libc 5 sources. When run configure,
say the first time "NO" to the "Values correct" question,
then say "YES" to "Build a NYS libc from nys".
</Para>
</Sect2>
<Sect2>
<Title>Setting up a NIS Client using glibc 2.x
<IndexTerm><Primary
>NIS!client setup!using glibc 2.x</Primary></IndexTerm>
</Title>
<Para>
The glibc uses "traditional NIS", so you need to start ypbind. The
Name Services Switch configuration file (/etc/nsswitch.conf) must be
correctly set up. If you use the compat mode for passwd, shadow or group,
you have to add the "+" at the end of this files and you can use
the include/exclude user feature. The configuration is excatly the same
as under Solaris 2.x.
</Para>
</Sect2>
<Sect2>
<Title>The nsswitch.conf File
<IndexTerm><Primary
>nsswitch.conf file</Primary></IndexTerm>
<IndexTerm><Primary
>NIS!nsswitch.conf file</Primary></IndexTerm>
</Title>
<Para>
The Network Services switch file /etc/nsswitch.conf determines the
order of lookups performed when a certain piece of information is
requested, just like the /etc/host.conf file which determines the way
host lookups are performed. For example, the line
</Para>
<Para>
<Screen>
hosts: files nis dns
</Screen>
</Para>
<Para>
specifies that host lookup functions should first look in the local
/etc/hosts file, followed by a NIS lookup and finally through the domain
name service (/etc/resolv.conf and named), at which point if no match
is found an error is returned. This file must be readable for every
user! You can find more information in the man-page nsswitch.5
or nsswitch.conf.5.
</Para>
<Para>
A good /etc/nsswitch.conf file for NIS is:
<Screen>
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
# nisplus Use NIS+ (NIS version 3)
# nis Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# db Use the /var/db databases
# [NOTFOUND=return] Stop searching if not found so far
#
passwd: compat
group: compat
# For libc5, you must use shadow: files nis
shadow: compat
passwd_compat: nis
group_compat: nis
shadow_compat: nis
hosts: nis files dns
services: nis [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
protocols: nis [NOTFOUND=return] files
rpc: nis [NOTFOUND=return] files
ethers: nis [NOTFOUND=return] files
netmasks: nis [NOTFOUND=return] files
netgroup: nis
bootparams: nis [NOTFOUND=return] files
publickey: nis [NOTFOUND=return] files
automount: files
aliases: nis [NOTFOUND=return] files
</Screen>
</Para>
<Para>
passwd_compat, group_compat and shadow_compat are only supported by glibc 2.x.
If there are no shadow rules in /etc/nsswitch.conf, glibc will use the passwd
rule for lookups. There are some more lookup module for glibc like hesoid.
For more information, read the glibc documentation.
</Para>
</Sect2>
<Sect2>
<Title>Shadow Passwords with NIS
<IndexTerm><Primary
>NIS!shadow passwords</Primary></IndexTerm>
</Title>
<Para>
Shadow passwords over NIS are always a bad idea. You loose the security,
which shadow gives you, and it is supported by only some few Linux C
Libraries. A good way to avoid shadow passwords over NIS is,
to put only the local system users in /etc/shadow. Remove the NIS user
entries from the shadow database, and put the password back in passwd.
So you can use shadow for the root login, and normal passwd for NIS
user. This has the advantage that it will work with every NIS client.
</Para>
<Sect3>
<Title>Linux</Title>
<Para>
The only Linux libc which supports shadow passwords over NIS, is the
GNU C Library 2.x. Linux libc5 has no support for it. Linux
libc5 compiled with NYS enabled has some code for it. But this code
is badly broken in some cases and doesn't work with all correct
shadow entries.
</Para>
</Sect3>
<Sect3>
<Title>Solaris</Title>
<Para>
Solaris does not support shadow passwords over NIS.
</Para>
</Sect3>
<Sect3>
<Title>PAM
<IndexTerm><Primary
>PAM!shadow passwords</Primary></IndexTerm>
</Title>
<Para>
Linux-PAM 0.75 and newr does support Shadow passwords over NIS if you
use the pam_unix.so Module or if you install the extra pam_unix2.so
Module. Old systems using pam_pwdb/libpwdb (for example Red Hat
Linux 5.x)
need to change the /etc/pam.d/* entries. All pam_pwdb rules should
be replaced through a pam_unix_* module.
</Para>
<Para>
An example /etc/pam.d/login file looks like:
</Para>
<Para>
<Screen>
#%PAM-1.0
auth requisite pam_unix2.so nullok #set_secrpc
auth required pam_securetty.so
auth required pam_nologin.so
auth required pam_env.so
auth required pam_mail.so
account required pam_unix2.so
password required pam_pwcheck.so nullok
password required pam_unix2.so nullok use_first_pass use_authtok
session required pam_unix2.so none # debug or trace
session required pam_limits.so
</Screen>
</Para>
</Sect3>
</Sect2>
</Sect1>
<Sect1 id="nisplus">
<Title>What do you need to set up NIS+ ?</Title>
<Sect2>
<Title>The Software
<IndexTerm><Primary
>NIS+!software required</Primary></IndexTerm>
</Title>
<Para>
The Linux NIS+ client code was developed for the GNU C library 2.
There is also a port for Linux libc5, since most commercial Applications
where linked against this library in the past, and you cannot recompile
them for using glibc. There are problems with libc5 and NIS+:
static programs cannot be linked with it, and programs compiled
with this library will not work with other libc5 versions.
</Para>
<Para>
As base System you need a glibc based Distribution like Debian,
Red Hat Linux or SuSE Linux. If you have a Linux Distribution, which
does not have glibc 2.1.1 or later, you need to update to a newer
version.
</Para>
<Para>
The NIS+ client software can be obtained from:
<Screen>
Site Directory File Name
ftp.gnu.org /pub/gnu/glibc glibc-2.3.2.tar.gz,
glibc-linuxthreads-2.3.2.tar.gz
ftp.kernel.org /pub/linux/utils/net/NIS+ nis-utils-1.4.1.tar.gz
</Screen>
</Para>
<Para>
You should also have a look at
<ULink
URL="http://www.linux-nis.org/nisplus/"
>http://www.linux-nis.org/nisplus/</ULink
>
for more information and the latest sources.
</Para>
</Sect2>
<Sect2>
<Title>Setting up a NIS+ client
<IndexTerm><Primary
>NIS+!client setup</Primary></IndexTerm>
</Title>
<Para>
IMPORTANT: For setting up a NIS+ client read your Solaris NIS+ docs
what to do on the server side! This document only describes what to do
on the client side!
</Para>
<Para>
After installing the new libc and nis-tools, create the credentials for
the new client on the NIS+ server. Make sure portmap is running. Then
check if your Linux PC has the same time as the NIS+ Server. For secure RPC,
you have only a small window from about 3 minutes, in which the credentials
are valid. A good idea is to run xntpd on every host. After this, run
</Para>
<Para>
<Screen>
domainname nisplus.domain.
nisinit -c -H &#60;NIS+ server&#62;
</Screen>
</Para>
<Para>
to initialize the cold start file. Read the nisinit man page for more
options. Make sure that the domainname will always be set after a reboot.
If you don't know what the NIS+ domain name is on your network, ask
your system/network administrator.
</Para>
<Para>
Now you should change your <filename>/etc/nsswitch.conf</filename>
file. Make sure that the
only service after publickey is nisplus ("publickey: nisplus"), and nothing
else!
</Para>
<Para>
Then start keyserv and make sure, that it will always be started
as first daemon after portmap at boot time. Run
<Screen>
keylogin -r
</Screen>
to store the root secretkey on your system. (I hope you have added the
publickey for the new host on the NIS+ Server?).
</Para>
<Para>
<Command>niscat passwd.org_dir</Command>
should now show you all entries in the passwd database.
</Para>
</Sect2>
<Sect2>
<Title>NIS+, keylogin, login and PAM
<IndexTerm><Primary
>NIS+!use of PAM with</Primary></IndexTerm>
</Title>
<Para>
When the user logs in, he need to set his secretkey to keyserv. This is done
by calling "keylogin". The login from the shadow package will do this for the
user, if it was compiled against glibc 2.1. For a PAM aware login, you have
to change the /etc/pam.d/login file to
use pam_unix2, not pwdb, which doesn't support NIS+. An example:
</Para>
<Para>
<Screen>
#%PAM-1.0
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_unix2.so set_secrpc
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_unix2.so
password required /lib/security/pam_unix2.so
session required /lib/security/pam_unix2.so
</Screen>
</Para>
</Sect2>
<Sect2>
<Title>The nsswitch.conf File
<IndexTerm><Primary
>nsswitch.conf file</Primary></IndexTerm>
<IndexTerm><Primary
>NIS+!nsswitch.conf file</Primary></IndexTerm>
</Title>
<Para>
The Network Services switch file <filename>/etc/nsswitch.conf</filename>
determines the order of lookups performed when a certain piece of
information is requested, just like the
<filename>/etc/host.conf</filename> file which determines the way
host lookups are performed. For example, the line
</Para>
<Para>
<Screen>
hosts: files nisplus dns
</Screen>
</Para>
<Para>
specifies that host lookup functions should first look in the local
<filename>/etc/hosts</filename> file, followed by a NIS+ lookup and
finally through the domain
name service (<filename>/etc/resolv.conf</filename> and named), at
which point if no match is found an error is returned.
</Para>
<Para>
A good <filename>/etc/nsswitch.conf</filename> file for NIS+ is:
<Screen>
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
# nisplus Use NIS+ (NIS version 3)
# nis Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# db Use the /var/db databases
# [NOTFOUND=return] Stop searching if not found so far
#
passwd: compat
group: compat
shadow: compat
passwd_compat: nisplus
group_compat: nisplus
shadow_compat: nisplus
hosts: nisplus files dns
services: nisplus [NOTFOUND=return] files
networks: nisplus [NOTFOUND=return] files
protocols: nisplus [NOTFOUND=return] files
rpc: nisplus [NOTFOUND=return] files
ethers: nisplus [NOTFOUND=return] files
netmasks: nisplus [NOTFOUND=return] files
netgroup: nisplus
bootparams: nisplus [NOTFOUND=return] files
publickey: nisplus
automount: files
aliases: nisplus [NOTFOUND=return] files
</Screen>
</Para>
</Sect2>
</Sect1>
<Sect1 id="ypserv">
<Title>Setting up a NIS Server
<IndexTerm><Primary
>NIS!server setup</Primary></IndexTerm>
</Title>
<Sect2>
<Title>The Server Program ypserv
<IndexTerm><Primary
>ypserv!setup</Primary></IndexTerm>
<IndexTerm><Primary
>NIS!ypserv setup</Primary></IndexTerm>
</Title>
<Para>
This document only describes how to set up the "ypserv" NIS server.
</Para>
<Para>
The NIS server software can be found on:
</Para>
<Para>
<Screen>
Site Directory File Name
ftp.kernel.org /pub/linux/utils/net/NIS ypserv-2.9.tar.gz
ftp.kernel.org /pub/linux/utils/net/NIS ypserv-2.9.tar.bz2
</Screen>
</Para>
<Para>
You could also look at
<ULink
URL="http://www.linux-nis.org/nis/"
>http://www.linux-nis.org/nis/</ULink
>
for more information.
</Para>
<Para>
The server setup is the same for both traditional NIS and NYS.
</Para>
<Para>
Compile the software to generate the <Command>ypserv</Command> and
<Command>makedbm</Command>
programs. ypserv-2.x only supports the securenets file for access
restrictions.
</Para>
<Para>
If you run your server as master, determine what files you require to be
available via NIS and then add or remove the appropriate
entries to the "all" rule in <filename>/var/yp/Makefile</filename>.
You always should look at the Makefile and edit the Options at the
beginning of the file.
</Para>
<Para>
There was one big change between ypserv 1.1 and ypserv 1.2. Since
version 1.2, the file handles are cached. This means you have to
call makedbm always with the -c option if you create new maps. Make
sure, you are using the
new <filename>/var/yp/Makefile</filename> from ypserv 1.2 or later,
or add the -c flag to makedbm in the Makefile. If you don't do that,
ypserv will continue to use the old maps, and not the updated one.
</Para>
<Para>
Now edit <filename>/var/yp/securenets</filename> and
<filename>/etc/ypserv.conf</filename>.
For more information, read the ypserv(8) and ypserv.conf(5) manual pages.
</Para>
<Para>
Make sure the portmapper (portmap(8)) is running, and start the
server <Command>ypserv</Command>. The command
</Para>
<Para>
<Screen>
% rpcinfo -u localhost ypserv
</Screen>
</Para>
<Para>
should output something like
</Para>
<Para>
<Screen>
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting
</Screen>
</Para>
<Para>
The "version 1" line could be missing, depending on the ypserv version and
configuration you are using. It is only necessary if you have old
SunOS 4.x clients.
</Para>
<Para>
Now generate the NIS (YP) database. On the master, run
</Para>
<Para>
<Screen>
% /usr/lib/yp/ypinit -m
</Screen>
</Para>
<Para>
On a slave make sure that <Command>ypwhich -m</Command> works. This means,
that your slave
must be configured as NIS client before you could run
<Screen>
% /usr/lib/yp/ypinit -s masterhost
</Screen>
to install the host as NIS slave.
</Para>
<Para>
That's it, your server is up and running.
</Para>
<Para>
If you have bigger problems, you could start <Command>ypserv</Command> and
<Command>ypbind</Command> in debug
mode on different xterms. The debug output should show you what goes
wrong.
</Para>
<Para>
If you need to update a map, run <Command>make</Command> in the
<Literal remap="tt">/var/yp</Literal>
directory on the NIS master. This will update a map if the source file
is newer, and push the files to the slave servers. Please don't use
<Command>ypinit</Command> for updating a map.
</Para>
<Para>
You might want to edit root's crontab *on the slave* server and add the
following lines:
</Para>
<Para>
<Screen>
20 * * * * /usr/lib/yp/ypxfr_1perhour
40 6 * * * /usr/lib/yp/ypxfr_1perday
55 6,18 * * * /usr/lib/yp/ypxfr_2perday
</Screen>
This will ensure that most NIS maps are kept up-to-date, even if an
update is missed because the slave was down at the time the update was
done on the master.
</Para>
<Para>
You can add a slave at every time later. At first, make sure that
the new slave server has permissions to contact the NIS master. Then run
<Screen>
% /usr/lib/yp/ypinit -s masterhost
</Screen>
on the new slave. On the master server, add the new slave server name
to <filename>/var/yp/ypservers</filename> and run
<Command>make</Command> in <Literal remap="tt">/var/yp</Literal>
to update the map.
</Para>
<Para>
If you want to restrict access for users to your NIS server, you'll have
to setup the NIS server as a client as well by running ypbind and adding the
plus-entries to <filename>/etc/passwd</filename> _halfway_
the password file. The library
functions will ignore all normal entries after the first NIS entry, and
will get the rest of the info through NIS. This way the NIS access rules
are maintained. An example:
</Para>
<Para>
<Screen>
root:x:0:0:root:/root:/bin/bash
daemon:*:1:1:daemon:/usr/sbin:
bin:*:2:2:bin:/bin:
sys:*:3:3:sys:/dev:
sync:*:4:100:sync:/bin:/bin/sync
games:*:5:100:games:/usr/games:
man:*:6:100:man:/var/catman:
lp:*:7:7:lp:/var/spool/lpd:
mail:*:8:8:mail:/var/spool/mail:
news:*:9:9:news:/var/spool/news:
uucp:*:10:50:uucp:/var/spool/uucp:
nobody:*:65534:65534:noone at all,,,,:/dev/null:
+miquels::::::
+:*:::::/etc/NoShell
[ All normal users AFTER this line! ]
tester:*:299:10:Just a test account:/tmp:
miquels:1234567890123:101:10:Miquel van Smoorenburg:/home/miquels:/bin/zsh
</Screen>
</Para>
<Para>
Thus the user "tester" will exist, but have a shell of /etc/NoShell. miquels
will have normal access.
</Para>
<Para>
Alternatively, you could edit the <filename>/var/yp/Makefile</filename> file
and set NIS to use
another source password file. On large systems the NIS password and group
files are usually stored in <Literal remap="tt">/etc/yp/</Literal>. If you do this the normal
tools to administrate the password file such as <Literal remap="tt">passwd</Literal>, <Literal remap="tt">chfn</Literal>,
<Literal remap="tt">adduser</Literal> will not work anymore and you need special homemade tools
for this.
</Para>
<Para>
However, <Literal remap="tt">yppasswd</Literal>, <Literal remap="tt">ypchsh</Literal> and <Literal remap="tt">ypchfn</Literal> will
work of course.
</Para>
</Sect2>
<Sect2>
<Title>The Server Program yps
<IndexTerm><Primary
>NIS!yps server</Primary></IndexTerm>
<IndexTerm><Primary
>yps NIS server</Primary></IndexTerm>
</Title>
<Para>
To set up the "yps" NIS server please refer to the previous paragraph.
The "yps" server setup is similar, _but_ not exactly the same so
beware if you try to apply the "ypserv" instructions to "yps"!
"yps" is not supported by any author, and contains some security leaks.
You really shouldn't use it !
</Para>
<Para>
The "yps" NIS server software can be found on:
</Para>
<Para>
<Screen>
Site Directory File Name
ftp.lysator.liu.se /pub/NYS/servers yps-0.21.tar.gz
ftp.kernel.org /pub/linux/utils/net/NIS yps-0.21.tar.gz
</Screen>
</Para>
</Sect2>
<Sect2>
<Title>The Program rpc.ypxfrd
<IndexTerm><Primary
>NIS&verbar;rpc.ypxfrd daemon</Primary></IndexTerm>
<IndexTerm><Primary
>rpc.ypxfrd daemon</Primary></IndexTerm>
</Title>
<Para>
rpc.ypxfrd is used for speed up the transfer of very large
NIS maps from a NIS master to NIS slave servers. If a
NIS slave server receives a message that there is a new
map, it will start ypxfr for transfering the new map.
ypxfr will read the contents of a map from the master
server using the yp_all() function. This process can take
several minutes when there are very large maps which have
to store by the database library.
</Para>
<Para>
The rpc.ypxfrd server speeds up the transfer process by
allowing NIS slave servers to simply copy the master
server's map files rather than building their own from
scratch. rpc.ypxfrd uses an RPC-based file transfer protocol,
so that there is no need for building a new map.
</Para>
<Para>
rpc.ypxfrd can be started by inetd. But since it starts
very slow, it should be started with ypserv. You need to start
rpc.ypxfrd only on the NIS master server.
</Para>
</Sect2>
<Sect2>
<Title>The Program rpc.yppasswdd
<IndexTerm><Primary
>NIS!rpc.yppasswdd daemon</Primary></IndexTerm>
<IndexTerm><Primary
>rpc.yppasswdd daemon</Primary></IndexTerm>
</Title>
<Para>
Whenever users change their passwords, the NIS password database and
probably other NIS databases, which depend on the NIS password
database, should be updated. The program "rpc.yppasswdd" is a server that
handles password changes and makes sure that the NIS information will
be updated accordingly. rpc.yppasswdd is now integrated in ypserv. You
don't need the older, separate yppasswd-0.9.tar.gz or yppasswd-0.10.tar.gz,
and you shouldn't use them any longer.
</Para>
<Para>
You need to start rpc.yppasswdd only on the NIS master server. By default,
users are not allowed to change their full name or the login shell.
You can allow this with the -e chfn or -e chsh option.
</Para>
<Para>
If your passwd and shadow files are not in another directory then
/etc, you need to add the -D option. For example, if you have put
all source files in /etc/yp and wish to allow the user to change
his shell, you need to start rpc.yppasswdd with the following parameters:
</Para>
<Para>
<Screen>
rpc.yppasswdd -D /etc/yp -e chsh
</Screen>
</Para>
<Para>
or
</Para>
<Para>
<Screen>
rpc.yppasswdd -s /etc/yp/shadow -p /etc/yp/passwd -e chsh
</Screen>
</Para>
<Para>
There is nothing more to do. You just need to make sure, that
<Literal remap="tt">rpc.yppasswdd</Literal> uses the same files as <Literal remap="tt">/var/yp/Makefile</Literal>.
Errors will be logged using syslog.
</Para>
</Sect2>
</Sect1>
<Sect1 id="verification">
<Title>Verifying the NIS/NYS Installation
<IndexTerm><Primary
>NIS!verification of operation</Primary></IndexTerm>
<IndexTerm><Primary
>NYS!verification of operation</Primary></IndexTerm>
</Title>
<Para>
If everything is fine (as it should be), you should be able to verify
your installation with a few simple commands. Assuming, for example,
your passwd file is being supplied by NIS, the command
</Para>
<Para>
<Screen>
% ypcat passwd
</Screen>
</Para>
<Para>
should give you the contents of your NIS passwd file. The command
</Para>
<Para>
<Screen>
% ypmatch userid passwd
</Screen>
</Para>
<Para>
(where userid is the login name of an arbitrary user) should give you
the user's entry in the NIS passwd file. The "ypcat" and "ypmatch"
programs should be included with your distribution of traditional
NIS or NYS.
</Para>
<Para>
If a user cannot log in, run the following program on the client:
<Screen>
#include &#60;stdio.h&#62;
#include &#60;pwd.h&#62;
#include &#60;sys/types.h&#62;
int
main(int argc, char *argv[])
{
struct passwd *pwd;
if(argc != 2)
{
fprintf(stderr,"Usage: getwpnam username\n");
exit(1);
}
pwd=getpwnam(argv[1]);
if(pwd != NULL)
{
printf("name.....: [%s]\n",pwd-&#62;pw_name);
printf("password.: [%s]\n",pwd-&#62;pw_passwd);
printf("user id..: [%d]\n", pwd-&#62;pw_uid);
printf("group id.: [%d]\n",pwd-&#62;pw_gid);
printf("gecos....: [%s]\n",pwd-&#62;pw_gecos);
printf("directory: [%s]\n",pwd-&#62;pw_dir);
printf("shell....: [%s]\n",pwd-&#62;pw_shell);
}
else
fprintf(stderr,"User \"%s\" not found!\n",argv[1]);
exit(0);
}
</Screen>
</Para>
<Para>
Running this program with the username as parameter will print all the
information the getpwnam function gives back for this user. This should
show you which entry is incorrect. The most common problem is, that the
password field is overwritten with a "*".
</Para>
<Para>
GNU C Library 2.1 (glibc 2.1) comes with a tool called getent. Use this
program instead the above on such a system. You could try:
<Screen>
getent passwd
</Screen>
or
<Screen>
getent passwd login
</Screen>
</Para>
</Sect1>
<Sect1 id="maps">
<Title>Creating and Updating NIS maps
<IndexTerm><Primary
>NIS!creating and updating maps</Primary></IndexTerm>
</Title>
<Sect2>
<Title>Creating new NIS maps
<IndexTerm><Primary
>MAP!creating</Primary></IndexTerm>
</Title>
<Para>
The initial NIS maps will be created by running
</Para>
<Screen>
% /usr/lib/yp/ypinit -m
</Screen>
<Para>
This is done when setting up the NIS master server for the first
time. For more information about this, read <XRef LinkEnd="ypserv">.
If you wish to add new maps to your server or remove old one, you
need to edit the <Literal remap="tt">/var/yp/Makefile</Literal> and
change the <Literal remap="tt">all:</Literal> rule. Add or remove
the name of the rule, which generates the map.
</Para>
<Para>
If you delete a map, you also have to remove the corresponding
files.
</Para>
<Para>
After this change, you only need to run
</Para>
<Screen>
% make -C /var/yp
</Screen>
<Para>
and the maps should be created.
</Para>
</Sect2>
<Sect2>
<Title>Updating NIS maps
<IndexTerm><Primary
>MAP!updating</Primary></IndexTerm>
</Title>
<Para>
If you modify the sources for the NIS maps (for example if you create
a new user by adding the account to the passwd file), you need to
regenerate the NIS maps. This is done by a simple
</Para>
<Screen>
% make -C /var/yp
</Screen>
<Para>
This command will check which sources have changed, creates the
maps new and tell ypserv that the maps have changed.
</Para>
</Sect2>
<Sect2>
<Title>Length of Map entries
<IndexTerm><Primary
>MAP!length of entries</Primary></IndexTerm>
</Title>
<Para>
The length of one entry is limited by the NIS protocol to 1024 characters.
You can't just increase this value and recompile the system. Every system
that uses NIS v2 expects key and data values to be no more than 1024 bytes
in size; if you suddenly make YPMAXRECORD larger on your client and server,
you will break interoperability with all other systems on your network that
use NIS. To make it work right, you'd have to go to every vendor that supports
NIS and get them to all make the change at the same time. Chances are you
won't be able to do this.
</Para>
<Para>
With glibc 2.1 and newer this limit was removed from the glibc NIS
implementation. So it is possible under Linux to use longer entries,
but only if you have no other NIS clients or servers in your network.
</Para>
<Para>
To allow the creation of NIS maps with a longer entry, you need to add
the <Literal remap="tt">--no-limit-check</Literal> option to the
<Literal remap="tt">makedbm</Literal> call in
<Literal remap="tt">/var/yp/Makefile</Literal>.
</Para>
<Para>
The result should look like:
</Para>
<Screen>
DBLOAD = $(YPBINDIR)/makedbm -c -m `$(YPBINDIR)/yphelper --hostname` --no-limit-check
</Screen>
<Para>
WARNING: This breaks the NIS protocol and even if Linux supports it,
not all Applictions running under Linux works with this change!
</Para>
<Para>
There is another way of solving this problem for
<filename>/etc/group</filename> entries. This idea is
from Ken Cameron:
</Para>
<Screen>
1. Break the entry into more than one line and name each group
slightly differnet.
2. keep the GID the same for all.
3. have the first entry with the right group name and the GID.
I don't put any user names in this one.
What happens is that going by user name you pick up the GID when the code
reads it. Then going the other way it stops after the first match of GID
and takes that name. It's ugly but works!
</Screen>
</Sect2>
</Sect1>
<Sect1 id="reboot">
<Title>Surviving a Reboot</Title>
<Para>
Once you have NIS correctly configured on the server and client, you do need
to be sure that the configuration will survive a reboot.
</Para>
<Para>
There are two separate issues to check: the existence of an init script and
the correct storage of the NIS domain name.
</Para>
<Sect2>
<Title>NIS Init Script</Title>
<Para>
In your version of Linux, you need to check your directory of init scripts,
typically <filename>/etc/init.d</filename>, <filename>/etc/rc.d/init.d
</filename> or <filename>/sbin/init.d</filename> to be sure there is a
startup script there for NIS. Usually this
file is called <filename>ypbind</filename> or <filename>ypclient</filename>.
</Para>
</Sect2>
<Sect2>
<Title>NIS Domain Name</Title>
<Para>
Perhaps the greatest issue that some people have with NIS is ensuring that
the NIS domain name is available after a reboot. According to Solaris 2.x,
the NIS domain name should be entered as a single line in:
</Para>
<Screen>
/etc/defaultdomain
</Screen>
<Para>
However, most Linux distributions does not seem to use this file.
</Para>
</Sect2>
<Sect2>
<Title>Distribution-specific Issues</Title>
<Para>
At this time, the following information is known about how various Linux
distributions handle the storage of the NIS domainname.
</Para>
<Sect3>
<Title>Caldera 2.x</Title>
<Para>
Caldera uses the file <filename>/etc/nis.conf</filename> which has the same format
as the normal <filename>/etc/yp.conf</filename>.
</Para>
</Sect3>
<Sect3>
<Title>Debian</Title>
<Para>
Debian appears to follow Sun's usage of <filename>/etc/defaultdomain</filename>.
</Para>
</Sect3>
<Sect3>
<Title>Red Hat Linux 6.x, 7.x, 8.x and 9</Title>
<Para>
Create or modify the variable <Command>NISDOMAIN</Command> in the file
<filename>/etc/sysconfig/network</filename>.
</Para>
</Sect3>
<Sect3>
<Title>SuSE Linux 6.x and 7.x</Title>
<Para>
Modify the variable <command>YP_DOMAINNAME</command> in <filename>/etc/rc.config</filename> and then run the command <command>SuSEconfig</command>.
</Para>
</Sect3>
<Sect3>
<Title>SuSE Linux 8.x and later</Title>
<Para>
Since version 8.0 SuSE Linux also follow Sun's usage of
<filename>/etc/defaultdomain</filename>.
</Para>
</Sect3>
</Sect2>
</Sect1>
<Sect1 id="rpasswdd">
<Title>Changing passwords with rpasswd
<IndexTerm><Primary
>NIS!changing passwords</Primary></IndexTerm>
</Title>
<Para>
The standard way to change a NIS password is to call
<command>yppasswd</command>, on some systems this is only
an alias for <command>passwd</command>. This commands uses
the yppasswd protocol and needs a running
<command>rpc.yppasswdd</command> process on the NIS master
server. The protocol has the disadvantage, that the old
password will be send in clear text over the network.
This is not so problematic, if the password change was
successfull. In this case, the old password is replaced
with the new one. But if the password change fails, an attacker
can use the clear password to login as this user.
Even more worse: If the system administrator changes the
NIS password for another user, the root password of the NIS
master server is transfered in clear text over the network.
And this one will not be changed.
</Para>
<Para>
One solution is to not use yppasswd for changing the password.
Instead, a good alternative is the <command>rpasswd</command>
command from the <Literal remap="tt">pwdutils</Literal> package.
</Para>
<Para>
<Screen>
Site Directory File Name
ftp.kernel.org /pub/linux/utils/net/NIS pwdutils-2.3.tar.gz
ftp.suse.com /pub/people/kukuk/pam/pam_pwcheck pam_pwcheck-2.2.tar.bz2
ftp.suse.com /pub/people/kukuk/pam/pam_unix2 pam_unix2-1.16.tar.bz2
</Screen>
</Para>
<Para>
<command>rpasswd</command> changes passwords for user accounts on
a remote server over a secure SSL connection. A normal user may
only change the password for their own account, if the user knows
the password of the administrator account (in the moment this is
the root password on the server), he may change the password for
any account if he calls <command>rpasswd</command> with the -a option.
</Para>
<Sect2>
<Title>Server Configuration
<IndexTerm><Primary
>rpasswdd!server configuration</Primary></IndexTerm>
</Title>
<Para>
For the server you need at first certificate, the default filename
for this is <filename>/etc/rpasswdd.pem</filename>. The file can be
created with the following command:
<Screen>
openssl req -new -x509 -nodes -days 730 -out /etc/rpasswdd.pem -keyout /etc/rpasswdd.pem
</Screen>
</Para>
<Para>
A PAM configuration file for <command>rpasswdd</command> is needed,
too. If the NIS accounts are stored in <filename>/etc/passwd</filename>,
the following is a good starting point for a working configuration:
<Screen>
#%PAM-1.0
auth required pam_unix2.so
account required pam_unix2.so
password required pam_pwcheck.so
password required pam_unix2.so use_first_pass use_authtok
password required pam_make.so /var/yp
session required pam_unix2.so
</Screen>
</Para>
<Para>
If sources for the NIS password maps are stored in another
location (for example in /etc/yp), the <Literal remap="tt">nisdir</Literal>
option of pam_unix2 can be used to find the source files in another place:
<Screen>
#%PAM-1.0
auth required pam_unix2.so
account required pam_unix2.so
password required pam_pwcheck.so nisdir=/etc/yp
password required pam_unix2.so nisdir=/etc/yp use_first_pass use_authtok
password required pam_make.so /var/yp
session required pam_unix2.so
</Screen>
</Para>
<Para>
Now start the <command>rpasswdd</command> daemon on the NIS master server.
</Para>
<Para>
Since the password change is done with PAM modules,
<command>rpasswdd</command> is also able to allow password changes
for NIS+, LDAP or other services supported by a PAM module.
</Para>
</Sect2>
<Sect2>
<Title>Client Configuration
<IndexTerm><Primary
>rpasswd!client configuration</Primary></IndexTerm>
</Title>
<Para>
On every client only the configuration file
<filename>/etc/rpasswd.conf</filename> which contains the name
of the server is neded. If the server does not run on the default
port, the correct port can alse be mentioned here:
</Para>
<Para>
<Screen>
# rpasswdd runs on master.example.com
server master.example.com
# Port 774 is the default port
port 774
</Screen>
</Para>
</Sect2>
</Sect1>
<Sect1 id="troubleshooting">
<Title>Common Problems and Troubleshooting NIS
<IndexTerm><Primary
>NIS!troubleshooting</Primary></IndexTerm>
<IndexTerm><Primary
>NIS!problems with</Primary></IndexTerm>
</Title>
<Para>
Here are some common problems reported by various users:
</Para>
<Para>
<OrderedList>
<ListItem>
<Para>
The libraries for 4.5.19 are broken. NIS won't work with it.
</Para>
</ListItem>
<ListItem>
<Para>
If you upgrade the libraries from 4.5.19 to 4.5.24 then the
su command breaks. You need to get the su command from the
slackware 1.2.0 distribution. Incidentally that's where you
can get the updated libraries.
</Para>
</ListItem>
<ListItem>
<Para>
When a NIS server goes down and comes up again ypbind starts
complaining with messages like:
<screen>
yp_match: clnt_call:
RPC: Unable to receive; errno = Connection refused
</screen>
and logins are refused for those who are registered in the
NIS database. Try to login as root and kill
ypbind and start it up again. An update to ypbind 3.3 or higher
should also help.
</Para>
</ListItem>
<ListItem>
<Para>
After upgrading the libc to a version greater then 5.4.20, the YP tools
will not work any longer. You need yp-tools 1.2 or later for
libc &#62;= 5.4.21 and glibc 2.x. For earlier libc version you need
yp-clients 2.2. yp-tools 2.x should work for all libraries.
</Para>
</ListItem>
<ListItem>
<Para>
In libc 5.4.21 - 5.4.35 yp_maplist is broken, you need 5.4.36 or later,
or some YP programs like ypwhich will segfault.
</Para>
</ListItem>
<ListItem>
<Para>
libc 5 with traditional NIS doesn't support shadow passwords over NIS.
You need libc5 + NYS or glibc 2.x.
</Para>
</ListItem>
<ListItem>
<Para>
ypcat shadow doesn't show the shadow map. This is correct, the name of
the shadow map is shadow.byname, not shadow.
</Para>
</ListItem>
<ListItem>
<Para>
Solaris doesn't use always privileged ports. So don't use password
mangling if you have a Solaris client.
</Para>
</ListItem>
</OrderedList>
</Para>
</Sect1>
<Sect1 id="faq">
<Title>Frequently Asked Questions
<IndexTerm><Primary
>NIS!frequently asked questions</Primary></IndexTerm>
</Title>
<Para>
Most of your questions should be answered by now. If there are still
questions unanswered you might want to post a message to
</Para>
<Para>
<Screen>
comp.os.linux.networking
</Screen>
</Para>
</Sect1>
</Article>