Attachment 9197 Details for Bug 18926 – file.shar

file.shar

file.shar (text/plain), 23.24 KB, created by eogren on 2000-06-01 01:50:01 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: eogren

Created: 2000-06-01 01:50:01 UTC

Size: 23.24 KB

patch

obsolete

># 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
>X
>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     &ldquo;binds&rdquo; 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 &lt;control D&gt;.
>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 +::::::::: &gt;&gt; /etc/master.passwd</userinput>
>X  someclient&prompt.root; <userinput>echo +:*:: &gt;&gt; /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 &ldquo;jsmith&rdquo; 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

Actions: View

Attachments on bug 18926: 9196 | 9197