Date: Wed, 31 May 2000 20:44:10 -0400 (EDT) From: eogren@earthlink.net To: FreeBSD-gnats-submit@freebsd.org Subject: docs/18926: Article regarding setup of NIS Message-ID: <200006010044.e510iAx90594@rod.darktech.org>
next in thread | raw e-mail | index | archive | help
>Number: 18926
>Category: docs
>Synopsis: Submission of NIS tutorial
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: doc-bug
>Submitter-Id: current-users
>Arrival-Date: Wed May 31 17:50:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator: Eric Ogren
>Release: FreeBSD 4.0-STABLE i386
>Organization:
>Environment:
FreeBSD rod.darktech.org 4.0-STABLE FreeBSD 4.0-STABLE #1:
Sun May 21 04:00:32 EDT 2000
eogren@rod.darktech.org:/usr/src/sys/compile/BLUE i386
>Description:
Per a couple of requests on -doc, here's a tutorial on setting up an NIS
master, slave, and clients.
I just pretty much copied the Makefile from an already existing one; it
seems to work as far as I can tell (I can make, make install, and make
clean), but it may need tweaking; I'm not too sure how our doc build
system works.
>How-To-Repeat:
n/a
>How-To-Repeat:
>Fix:
Create doc/en_US.ISO_8859-1/articles/nis-guide, and extract the following
(below the Makefile patch) shell archive into it. Also, apply the simple
Makefile patch to doc/en_US.ISO_8859-1/articles/Makefile to put nis-guide
in the build. (There may be other build-related changes that I missed, but
I don't think so).
Index: Makefile
===================================================================
RCS file: /usr/local/doctree/doc/en_US.ISO_8859-1/articles/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile 2000/02/14 01:25:14 1.6
+++ Makefile 2000/05/31 19:43:23
@@ -7,6 +7,7 @@
SUBDIR+= mh
SUBDIR+= multi-os
SUBDIR+= new-users
+SUBDIR+= nis-guide
SUBDIR+= programming-tools
SUBDIR+= zip-drive
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# Makefile
# article.sgml
#
echo x - Makefile
sed 's/^X//' >Makefile << 'END-of-Makefile'
X# $FreeBSD$
X
XDOC?= article
X
XFORMATS?= html
X
XINSTALL_COMPRESSED?=gz
XINSTALL_ONLY_COMPRESSED?=
X
XSRCS= article.sgml
X
XDOC_PREFIX?= ${.CURDIR}/../../..
X
X.include "${DOC_PREFIX}/share/mk/doc.project.mk"
END-of-Makefile
echo x - article.sgml
sed 's/^X//' >article.sgml << 'END-of-article.sgml'
X<!-- $FreeBSD$ -->
X<!-- The FreeBSD Documentation Project -->
X
X<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V3.1-Based Extension//EN">
X
X<article>
X<artheader>
X <title>Setting up NIS (yp) under FreeBSD</title>
X
X <author>
X <firstname>Eric</firstname>
X <surname>Ogren</surname>
X <affiliation>
X <address><email>eogren@earthlink.net</email></address>
X </affiliation>
X </author>
X
X <copyright>
X <year>2000</year>
X <holder role="mailto:eogren@earthlink.net">Eric Ogren</holder>
X </copyright>
X
X <pubdate>June 1, 2000</pubdate>
X
X <abstract>
X <para>NIS is the closest thing FreeBSD has to Windows NT's domain
X system; it allows you to centralize username and passwords. This
X document will tell you how to set up an NIS server, as well as an
X NIS client on a FreeBSD system.</para>
X <para>This article will make several analogies between NIS and NT's
X domain system; although the internal implementation of the two
X aren't at all similar, the basic functionality can be compared.</para>
X </abstract>
X</artheader>
X
X<sect1>
X <title>Introduction to NIS</title>
X
X <para>NIS, which stands for Network Information Services, was
X developed by Sun Microsystems to centralize adminstration of Unix
X (originally Solaris) systems. It has now essentially become an
X industry standard; all major Unices (Solaris, HP-UX, AIX, Linux,
X NetBSD, OpenBSD, FreeBSD, etc) support NIS, and it is really the best
X way to centralize password and group files among Unix systems.</para>
X <para>NIS was formerly known as Yellow Pages (or yp), but due to
X copyright violations, Sun was forced to change the name.</para>
X </sect1>
X
X <sect1>
X <title>NIS architechture</title>
X
X <sect2>
X <title>Terms/processes you should know</title>
X
X <para>There are several terms and several important user processes
X that you will come across when
X attempting to implement NIS on FreeBSD, whether you are trying to
X create an NIS server or act an NIS client:</para>
X
X <itemizedlist>
X <listitem>
X <para><emphasis>The NIS domainname</emphasis>. An NIS master
X server and all of its clients (including its slave servers) have
X an NIS domainname. Similar to an NT domain name, the NIS
X domainname does not have anything to do with DNS. Indeed, your
X NIS domainname should <emphasis>not</emphasis> be the same as
X your DNS domainname; this is a security problem, and will also
X make it more difficult to decipher logs if you have
X problems.</para>
X </listitem>
X <listitem>
X <para><emphasis>portmap</emphasis>. <command>portmap</command>
X must be running in order to enable RPC (Remote Procedure Call, a
X network protocol used by NIS). If <command>portmap</command> is
X not running, it will be impossible to run an NIS server, or to
X act as an NIS client.</para>
X </listitem>
X <listitem>
X <para><emphasis>ypbind</emphasis>. <command>ypbind</command>
X “binds” an NIS client to its master
X server. It will take the NIS domainname from the system, and
X using RPC, connect to the master. <command>ypbind</command> is the core of
X client-server communication in an NIS environment; if
X <command>ypbind</command> dies on a client machine, it will not
X be able to access the NIS server.</para>
X </listitem>
X <listitem>
X <para><emphasis>ypserv</emphasis>. <command>ypserv</command>,
X which should only be running on NIS servers, is the NIS server
X process itself. If ypserv dies, then the server will no longer be
X able to respond to NIS requests (hopefully, there is a slave
X server to take over for it).</para>
X </listitem>
X <listitem>
X <para><emphasis>rpc.yppasswdd</emphasis>.
X <command>rpc.yppasswdd</command>, another process that should
X only be running on NIS servers, is a daemon that will allow NIS
X clients to change their NIS passwords. If this daemon is not
X running, users will have to login to the NIS master server and
X change their passwords there.</para>
X </listitem>
X </itemizedlist>
X </sect2>
X
X
X <sect2>
X <title>NIS machine types</title>
X <para>There are three major types of machines in an NIS
X environment:</para>
X
X <itemizedlist>
X <listitem>
X <para>An <emphasis>NIS master server</emphasis>.
X This server, analogous to a Windows
X NT primary domain controller, maintains the files used by all
X of the NIS clients. The <filename>passwd</filename>,
X <filename>group</filename>, and other various files used by the
X NIS clients live on the master server.</para>
X <para><note><para>It is possible for one machine to be an NIS
X master server for more than one NIS domain. However, this will
X not be covered in this article, which assumes a relatively
X small-scale NIS environment.</para></note></para>
X </listitem>
X <listitem>
X <para><emphasis>NIS slave servers</emphasis>.
X Similar to NT's backup domain
X controllers, NIS slave servers maintain copies of the NIS
X master's data files. The servers sit idle (except for receiving
X updates from the master) until the master server crashes, at
X which point they will begin answering requests. If you are in
X an environment where it is critical that availability be
X maintained, you will want to have at least one NIS slave
X servers.</para>
X </listitem>
X <listitem>
X <para><emphasis>NIS clients</emphasis>. NIS clients, like most
X NT workstations, authenticate against the NIS server (or the NT
X domain controller in the NT Workstation case) to logon.</para>
X </listitem>
X </itemizedlist>
X </sect2>
X </sect1>
X
X<sect1>
X <title>Setting up an NIS environment</title>
X
X <para>This section will deal with setting up a sample NIS
X environment.</para>
X <para><note><para>This section assumes that you are running FreeBSD 3.3 or
X later. The instructions given here will <emphasis>probably</emphasis>
X work for any version of FreeBSD greater than 3.0, but there are no
X guarantees that this is true.</para></note></para>
X
X <para>Let's assume that you are the administrator of a small
X university lab. This lab, which consists of 15 FreeBSD machines,
X currently has no centralized point of administration; each machine
X has its own <filename>/etc/passwd</filename> and
X <filename>/etc/master.passwd</filename>. These files are kept in sync
X with each other only through manual intervention; currently, when you
X add a user to the lab, you must run <command>adduser</command> on all
X 15 machines. Clearly, this has to change, so you have decided to
X convert the lab to use NIS, sacrificing two of the machines to be
X used as servers.</para>
X
X <para>Therefore, the configuration of the lab now looks something
X like:</para>
X
X <informaltable>
X <tgroup cols="3">
X <thead>
X <row>
X <entry>Machine name</entry>
X <entry>IP address</entry>
X <entry>Machine role</entry>
X </row>
X </thead>
X
X <tbody>
X <row>
X <entry><hostid>ellington</hostid></entry>
X <entry><hostid role="ipaddr">10.0.0.2</hostid></entry>
X <entry>NIS master</entry>
X </row>
X
X <row>
X <entry><hostid>coltrane</hostid></entry>
X <entry><hostid role="ipaddr">10.0.0.3</hostid></entry>
X <entry>NIS slave</entry>
X </row>
X
X <row>
X <entry><hostid>basie</hostid></entry>
X <entry><hostid role="ipaddr">10.0.0.4</hostid></entry>
X <entry>Faculty workstation</entry>
X </row>
X
X <row>
X <entry><hostid>bird</hostid></entry>
X <entry><hostid role="ipaddr">10.0.0.5</hostid></entry>
X <entry>Client machine</entry>
X </row>
X
X <row>
X <entry><hostid>cli[1-11]</hostid></entry>
X <entry><hostid role="ipaddr">10.0.0.[6-17]</hostid></entry>
X <entry>Other client machines (not used in this example)</entry>
X </row>
X
X </tbody>
X </tgroup>
X </informaltable>
X
X <sect2>
X <title>Setting up the NIS master</title>
X
X <sect3>
X <title>Modifying configuration files</title>
X
X <para>After determining which machine is going to be the NIS master,
X the first thing you have to do is determine what your NIS domainname
X is going to be. For this example, assume you have chosen the name
X <emphasis>jazz-lab</emphasis>.</para>
X
X <para>Now that we know what the NIS domainname is going to be, we
X can begin to set up the NIS master. The first thing to do is edit
X <filename>/etc/rc.conf</filename> and add the following
X lines:</para>
X
X <itemizedlist>
X <listitem>
X <para><emphasis>nisdomainname="jazz-lab"</emphasis>. This line
X will set the NIS domainname to <emphasis>jazz-lab</emphasis> upon
X reboot.</para>
X </listitem>
X <listitem>
X <para><emphasis>nis_server_enable="YES"</emphasis>. This will tell
X FreeBSD to start up the NIS server processes when the system is
X next brought up.</para>
X </listitem>
X <listitem>
X <para><emphasis>nis_yppasswdd_enable="YES"</emphasis>. This will
X enable the <command>rpc.yppasswdd</command> daemon, which, as
X mentioned above, will allow users to change their NIS password
X from a client machine.</para>
X </listitem>
X </itemizedlist>
X </sect3>
X
X <sect3>
X <title>Initializing the NIS maps</title>
X
X <para>The <emphasis>NIS maps</emphasis> are database files generated
X from configuration files in the <filename>/etc</filename> directory
X of the NIS master, with one exception: the
X <filename>/etc/master.passwd</filename> file. This is for a good
X reason; you don't want to propogate passwords to your root and other
X administrative accounts to all the servers in the NIS
X domain. Therefore, before we initialize the NIS maps, you
X should:</para>
X <screen>
X &prompt.root; <userinput>cp /etc/master.passwd /var/yp/master.passwd</userinput>
X &prompt.root; <userinput>cd /var/yp</userinput>
X &prompt.root; <userinput>vi master.passwd</userinput>
X </screen>
X
X <para>You should remove all entries regarding system accounts (bin,
X tty, kmem, games, etc), as well as any accounts that you don't want
X to be propogated to the NIS clients (for example root and any other
X UID 0 accounts).</para>
X <para>When you have finished, it's time to initialize the NIS maps!
X FreeBSD includes a script named <command>ypinit</command> to do this
X for you (see its man page for more information).
X Note that this script is <emphasis>not</emphasis> an
X industry standard; other Unix OSs are not going to have
X <command>ypinit</command>. Because we are generating maps for an NIS
X master, we are going to pass the <option>-m</option> option to
X <command>ypinit</command>. To generate the NIS maps, assuming you
X already performed the steps above, run:</para>
X
X <screen>
Xellington&prompt.root; <userinput>ypinit -m jazz-lab</userinput>
XServer Type: MASTER Domain: jazz-lab
XCreating an YP server will require that you answer a few questions.
XQuestions will all be asked at the beginning of the procedure.
XDo you want this procedure to quit on non-fatal errors? [y/n: n] <userinput>n</userinput>
XOk, please remember to go back and redo manually whatever fails.
XIf you don't, something might not work.
XAt this point, we have to construct a list of this domains YP servers.
Xrod.darktech.org is already known as master server.
XPlease continue to add any slave servers, one per line. When you are
Xdone with the list, type a <control D>.
X master server : ellington
X next host to add: <userinput>coltrane</userinput>
X next host to add: <userinput>^D</userinput>
XThe current list of NIS servers looks like this:
Xellington
Xcoltrane
XIs this correct? [y/n: y] <userinput>y</userinput>
X
X[..output from map generation..]
X
XNIS Map update completed.
Xellington has been setup as an YP master server without any errors.
X</screen>
X
X <para>You will probably see some errors similar to "Failed to send 'clear' to
X local 'ypserv'". This is to be expected; you haven't yet started
X your NIS server.</para>
X </sect3>
X
X <sect3>
X <title>Editing <filename>/var/yp/Makefile</filename></title>
X
X <para><command>ypinit</command> should have created
X <filename>/var/yp/Makefile</filename> from
X <filename>/var/yp/Makefile.dist</filename>. When created, this file
X assumes that you are operating in a single server NIS environment
X with only FreeBSD machines. Since <emphasis>jazz-lab</emphasis> has
X a slave server as well, you must edit
X <filename>/var/yp/Makefile</filename>:</para>
X
X <screen>
X ellington&prompt.root; <userinput>vi /var/yp/Makefile</userinput>
X </screen>
X
X <para>You should comment out the line that says `NOPUSH =
X "True"'. Although not required in this sample environment, you may
X also need to uncomment the `UNSECURE = "TRUE"' line in the
X Makefile.</para>
X </sect3>
X
X <sect3>
X <title>Reboot</title>
X
X <para>After this, all you need to do is reboot. Although it is not
X absolutely necessary to reboot to bring an NIS master online, it's
X easier: all of the NIS daemons will be started automatically,
X instead of you being required to do so by hand. So, we just need
X to:</para>
X
X <screen>
X ellington&prompt.root; <userinput>shutdown -r now</userinput>
X </screen>
X
X <para>..and we have finished configuring the NIS master!</para>
X </sect3>
X</sect2>
X
X <sect2>
X <title>Setting up the slave server</title>
X
X <para>Setting up a slave server is not much different from setting
X up the NIS master. Logon to the slave server and edit the
X <filename>/etc/rc.conf</filename> as you
X did before. The only difference is that we now must use the
X <option>-s</option> option when running
X <command>ypinit</command>. The <option>-s</option> option requires
X the name of the NIS master be passed to it as well, so our command
X line looks like:</para>
X
X <screen>
X coltrane&prompt.root; <userinput>ypinit -s ellington jazz-lab</userinput>
X </screen>
X
X <para>Then reboot as before.</para>
X </sect2>
X
X <sect2>
X <title>Setting up the clients</title>
X
X <para><warning><para>Setting up machines to act as NIS clients is not that
X difficult, but it does require you to edit
X <filename>/etc/master.passwd</filename> and
X <filename>/etc/group</filename>. As always when editing important
X system files, we strongly recommend that you take a backup before
X you attempt to do this!</para></warning></para>
X
X
X <para>To enable a machine as an NIS client, the first thing you
X must do is edit its
X <filename>/etc/rc.conf</filename> file. Add the following
X lines:</para>
X
X <itemizedlist>
X <listitem>
X <para><emphasis>nisdomainname="jazz-lab"</emphasis>. As it does on
X the NIS master and slaves, this tells FreeBSD to set the NIS
X domainname to <emphasis>jazz-lab</emphasis>.</para>
X </listitem>
X <listitem>
X <para><emphasis>nis_client_enable="YES"</emphasis>. This will
X instruct FreeBSD to start <command>ypbind</command> upon
X bootup. As explained above, <command>ypbind</command> is the
X process used to communicate to the master NIS server.</para>
X </listitem>
X </itemizedlist>
X
X <para>Next, we need to tell FreeBSD to import all user account and
X group names from the NIS server:</para>
X
X <screen>
X someclient&prompt.root; <userinput>echo +::::::::: >> /etc/master.passwd</userinput>
X someclient&prompt.root; <userinput>echo +:*:: >> /etc/group</userinput>
X someclient&prompt.root; <userinput>pwd_mkdb /etc/master.passwd</userinput>
X </screen>
X
X <para>You can also use <command>vipw</command> to add the entry to
X <filename>/etc/master.passwd</filename>, which means you will not
X have to run <filename>pwd_mkdb</filename>.</para>
X
X <para>Reboot the client. Again, although you do not have to reboot
X in order to enable NIS, this means you do not have to set the NIS
X domainname or start the daemons manually.</para>
X </sect2>
X</sect1>
X
X<sect1>
X <title>Testing NIS</title>
X
X <para>Once you have setup your NIS servers and client, logon to one
X of the client machines, and do:</para>
X
X <screen>
X someclient&prompt.user; <userinput>ypcat passwd</userinput>
X </screen>
X
X <para>If everything is configured correctly, you should be able to
X see the master server's <filename>passwd</filename> file, with the
X passwords asterisked out. If you run <command>ypcat</command> as
X root, you should be able to see the (encrypted) passwords.</para>
X
X <para>The next task is to actually logon as someone only present in
X the NIS database. In our test lab environment, using
X <command>vipw</command> on the client, we would remove
X a user account that is present both on the client and the NIS
X master. We would then try to login as this user account. The client
X should pull the user record from the NIS master, and the login should
X be successful.</para>
X
X <para>If the first test worked, and this one doesn't,
X make sure you put the correct entries in the client's
X <filename>/etc/master.passwd</filename> file (make sure you count the
X number of colons).</para>
X</sect1>
X
X<sect1>
X <title>Post-installation tasks</title>
X
X <para>After you have a working NIS installation, there are still a
X couple more things you can do. This section will describe
X them.</para>
X
X <sect2>
X <title>Making NIS a little more secure</title>
X
X <para>If you followed the steps above, <emphasis>anybody</emphasis>
X who guesses your NIS domainname and who is running FreeBSD will be
X able to access your NIS server and pull down its maps. If they have
X root access on this machine, they, like any other of your client
X machines, will be able to get the master's (slightly edited)
X <filename>master.passwd</filename> file. This is obviously not
X desirable. There is a file you can create to stop this from
X happening, however: <filename>/var/yp/securenets</filename>.</para>
X
X <para><filename>/var/yp/securenets</filename> is simply a file with
X a list of IPs and netmasks that are allowed to access the NIS
X server. If <filename>/var/yp/securenets</filename> is not present,
X then anybody who wants to can access the server. In our environemnt,
X <filename>/var/yp/securenets</filename> would probably look
X something like:</para>
X
X<screen>
X# Allow localhost to connect. !!MANDATORY!!
X127.0.0.1 255.255.255.255
X
X# Machines in the testlab
X10.0.0.2 255.255.255.0
X</screen>
X
X<para>...assuming that the lab has 10.0.0.* to itself. If it doesn't,
Xeach machine in the lab would be listed in
X<filename>securenets</filename>, with a netmask of <hostid
Xrole="netmask">255.255.255.255</hostid>.</para>
X</sect2>
X<sect2>
X <title>Barring some users from logging on</title>
X
X <para>In our lab, there is a machine <hostid>basie</hostid> that is
X supposed to be a faculty only workstation. We don't want to take this
X machine out of the NIS domain, yet the <filename>passwd</filename>
X file on the master NIS server contains accounts for both faculty and
X students. What can we do?</para>
X
X <para>There is a way to bar specific users from logging on to a
X machine, even if they are present in the NIS database. To do this,
X all you must do is add
X <emphasis>-<replaceable>username</replaceable></emphasis> to the end of
X the <filename>/etc/master.passwd</filename> file on the client
X machine, where <replaceable>username</replaceable> is the username of
X the user you wish to bar from logging in. This should preferably be
X done using <command>vipw</command>, since <command>vipw</command>
X will sanity check your changes to
X <filename>/etc/master.passwd</filename>, as well as
X automatically rebuild the password database when you
X finish editing. For example, if we wanted to bar user
X <emphasis>bill</emphasis> from logging on to <hostid>basie</hostid>
X we would:</para>
X
X <screen>
X basie&prompt.root; <userinput>vipw</userinput>
X <userinput>[add -bill to the end, exit]</userinput>
X vipw: rebuilding the database...
X vipw: done
X
X basie&prompt.root; <userinput>cat /etc/master.passwd</userinput>
X
Xroot:[password]:0:0::0:0:The super-user:/root:/bin/csh
Xtoor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
Xdaemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
Xoperator:*:2:5::0:0:System &:/:/sbin/nologin
Xbin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
Xtty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
Xkmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
Xgames:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
Xnews:*:8:8::0:0:News Subsystem:/:/sbin/nologin
Xman:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin
Xbind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
Xuucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
Xxten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
Xpop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
Xnobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
X+:::::::::
X-bill
X
Xbasie&prompt.root;
X</screen>
X
X</sect2>
X</sect1>
X
X<sect1>
X <title>Important things to remember</title>
X
X <para>There are still a couple of things that you will need to do
X differently now that you are in an NIS environment.</para>
X
X <itemizedlist>
X <listitem><para>Every time you wish to add a user to the lab, you
X must add it to the master NIS server <emphasis>only</emphasis>, and
X <emphasis>you must remember to rebuild the NIS maps</emphasis>. If
X you forget to do this, the new user will not be able to login
X anywhere except on the NIS master. For example, if we needed to add
X a new user “jsmith” to the lab, we would:</para>
X
X <screen>
X &prompt.root; <userinput>pw useradd jsmith</userinput>
X &prompt.root; <userinput>cd /var/yp</userinput>
X &prompt.root; <userinput>make jazz-lab</userinput>
X </screen>
X
X <para>You could also run <command>adduser jsmith</command> instead
X of <command>pw useradd jsmith</command>.</para>
X </listitem>
X <listitem>
X <para><emphasis>Keep the administration accounts out of the NIS
X maps</emphasis>. You don't want to be propogating administrative
X accounts and passwords to machines that will have users that
X shouldn't have access to those accounts.</para>
X </listitem>
X <listitem>
X <para><emphasis>Keep the NIS master and slave
X secure, and minimize their downtime</emphasis>.
X If somebody either hacks or simply turns off
X these machines, they have effectively rendered many people without
X the ability to login to the lab.</para>
X <para>This is the chief weakness of any centralized administration
X system, and it is probably the most important weakness. If you do
X not protect your NIS servers, you will have a lot of angry
X users!</para>
X </listitem>
X </itemizedlist>
X</sect1>
X
X
X</article>
X
END-of-article.sgml
exit
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006010044.e510iAx90594>