FreeBSD Bugzilla – Attachment 9197 Details for
Bug 18926
Submission of NIS tutorial
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Help
|
New Account
|
Log In
Remember
[x]
|
Forgot Password
Login:
[x]
file.shar
file.shar (text/plain), 23.24 KB, created by
eogren
on 2000-06-01 01:50:01 UTC
(
hide
)
Description:
file.shar
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<!-- $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
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 18926
:
9196
| 9197