Post by Erwin Embse » Tue, 04 Jul 1995 04:00:00

Archive-name: linux/howto/nis
Last-modified: 2 Jul 95


*** The Linux NIS HOWTO is posted automatically by the Linux
*** HOWTO coordinator, Greg Hankins <>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Erwin Embsen <>.

- --- BEGIN Linux NIS HOWTO part 1/1 ---

  Andrea Dell'Amico, Mitchum DSouza, Erwin Embsen, Peter Eriksson
  v0.5, 24 January 1995

  1.  Glossary of Terms

  In this document a lot of acronyms are used. Here are the most
  important acronyms and a brief explanation:

        DataBase Management, a library of functions which maintain key-
        content pairs in a data base.

        Dynamically Linked Library, a library linked to an executable
        program at run-time.

        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).

        File Transfer Protocol, a protocol used to transfer files
        between two computers.

        Name services library, a library of name service calls
        (getpwnam, getservbyname, etc...) on SVR4 Unixes.

        Socket services library, a library for the socket service calls
        (socket, bind, listen, etc...) on SVR4 Unixes.

        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".

        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
        _large_ installations.

        This is the name of a project and stands for NIS+, YP and Switch
        and is managed by Peter Eriksson <>. It
        contains among other things a complete reimplementation of the
        NIS (=YP) code that uses the Name Services Switch functionality
        of the NYS library.

        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 SunRPC variant.

     YP Yellow Pages(tm), a registered trademark in the UK of British
        Telecom plc.

        Transmission Control Protocol/Internet Protocol. It's a data
        communication protocol often used on Unix machines.

  1.1.  Some General Information

  The next three lines are quoted from the Sun(tm) System & Network
  Administration Manual:

           "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."

  NIS stands for Network Information Service. It's 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

  o  login names/passwords/home directories (/etc/passwd)

  o  group information (/etc/group)

  So, for example, if your password entry is recorded in the NIS passwd
  database, you will be able to login on all machines on the net which
  have the NIS client programs running.

  Sun is a trademark of Sun Microsystems, Inc. licensed to SunSoft, Inc.

  2.  Introduction

  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. It can also (with the NYS library) act as a
  limited NIS+ client.

  This document tries to answer questions about setting up NIS(YP) on
  your Linux machine. It does not talk about how to set up NIS+. Don't
  forget to read section 5.1, The RPC Portmapper.

  2.1.  New versions of this document

  New versions of this document will be posted periodically (about every
  month) to the newsgroups comp.os.linux.announce and
  comp.os.linux.misc.  The document is archived on a number of Linux FTP
  sites, including in /pub/Linux/docs/HOWTO.

  2.2.  Disclaimer

  Although this document has been put together to the best of our
  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. We will attempt to keep this document as error free as

  2.3.  Feedback

  If you have any comments, questions or suggestions please email them
  to Erwin Embsen <>. Definitely contact him if you find
  errors or obvious omissions.

  2.4.  Acknowledgements

  We would like to thank all the people who have contributed (directly
  or indirectly) to this document. In alphabetical order:

       Andrea Dell'Amico <>
       Mitchum DSouza    <Mitch.Dso...@Dubai.Sun.COM>
       Erwin Embsen      <>
       Byron A Jeff      <>
       Peter Eriksson    <>

  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).

  3.  NIS or NIS+ ?

  The choice between NIS and NIS+ is easy - use NIS if you don't have to
  use NIS+ or 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 is still under developement - one major
  thing it still lacks is support for data encryption/authentication
  which is _the_ major thing why anyone would want to use NIS+...

  3.1.  Traditional NIS or the NYS library ?

  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

  The "traditional NIS" code is in the standard C library and has been
  around longer and sometimes suffers from it's age and slight

  The NIS code in the NYS library, on the other hand requires you either
  to recompile and relink all your programs to the libnsl library, or
  recompile the libc library to include the libnsl code into the libc
  library (or maybe you can go get a precompiled version of libc from
  someone who has already done it).

  Another difference is that the traditional NIS code has some support
  for NIS Netgroups, which the NYS code doesn't (yet). On the other hand
  the NYS code allows you to handle Shadow Passwords in a transparent

  4.  How it works

  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 said
  to be 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...

  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 quicker.

  NIS databases are in so-called DBM format, derived from ASCII
  databases.  For example, the files /etc/passwd and /etc/group can be
  directly converted to DBM format using ASCII-to-DBM translation
  software ("dbload", it's included with the server software). The
  master NIS server should have both, the ASCII databases and the DBM

  Slave servers  will be notified of any change to the NIS maps, (via
  the "yppush" program), and automatically retrieve the necessary
  changes in order to synchronize their databases. NIS clients does not
  need to do this since they always talks to the NIS server to read the
  information stored in it's DBM databases.

  The author of the YP clients for linux has informed us that the newest
  ypbind (from yp-clients.tar.gz) is able to get the server from a
  configuration file - thus no need to broadcast (which is insecure -
  due to the fact that anyone may install a NIS server and answer the
  broadcast queries...)

  5.  What do you need to set up NIS?

  5.1.  The RPC Portmapper

  To run any of the software mentioned below you will need to run the
  program /usr/sbin/rpc.portmap. Some Linux distributions already have
  the code in /etc/rc.d/rc.inet2 to start up this daemon.  All you have
  to do is comment it out and reboot your Linux machine to activate it.

  The RPC portmapper (portmap(8c)) 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 client
  software does) to RPC servers (like a 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

read more »



Post by Risto Kankkun » Thu, 13 Jul 1995 04:00:00

I need to set up a slave NIS server to a linux box. The NIS HOWTO says:

>  [...] to set up a NIS server on your Linux machine using the "ypserv"

>  this implementation does NOT support the master-slave concept talked
>  about in section 3. Using this software, all your NIS servers will be
>  master servers. There is also another free NIS server available,
>  called "yps", written by Tobias Reber in Germany which does support
>  the master-slave concept, but has other limitations.

So, where can I get the yps server? Or is ypserv updated yet to support
slave configuration?