Source string Read only

(itstool) path: callout/para
107/1070
Context English State
Physical Server Requirements
There are several things to keep in mind when choosing a machine to use as a <acronym>NIS</acronym> server. Since <acronym>NIS</acronym> clients depend upon the availability of the server, choose a machine that is not rebooted frequently. The <acronym>NIS</acronym> server should ideally be a stand alone machine whose sole purpose is to be an <acronym>NIS</acronym> server. If the network is not heavily used, it is acceptable to put the <acronym>NIS</acronym> server on a machine running other services. However, if the <acronym>NIS</acronym> server becomes unavailable, it will adversely affect all <acronym>NIS</acronym> clients.
Configuring the <acronym>NIS</acronym> Master Server
The canonical copies of all <acronym>NIS</acronym> files are stored on the master server. The databases used to store the information are called <acronym>NIS</acronym> maps. In FreeBSD, these maps are stored in <filename>/var/yp/[domainname]</filename> where <filename>[domainname]</filename> is the name of the <acronym>NIS</acronym> domain. Since multiple domains are supported, it is possible to have several directories, one for each domain. Each domain will have its own independent set of maps.
<acronym>NIS</acronym> master and slave servers handle all <acronym>NIS</acronym> requests through <citerefentry><refentrytitle>ypserv</refentrytitle><manvolnum>8</manvolnum></citerefentry>. This daemon is responsible for receiving incoming requests from <acronym>NIS</acronym> clients, translating the requested domain and map name to a path to the corresponding database file, and transmitting data from the database back to the client.
<primary>NIS</primary> <secondary>server configuration</secondary>
Setting up a master <acronym>NIS</acronym> server can be relatively straight forward, depending on environmental needs. Since FreeBSD provides built-in <acronym>NIS</acronym> support, it only needs to be enabled by adding the following lines to <filename>/etc/rc.conf</filename>:
nisdomainname="<replaceable>test-domain</replaceable>" <co xml:id="network-nis-co-domainname"/>
nis_server_enable="YES" <co xml:id="network-nis-co-server"/>
nis_yppasswdd_enable="YES" <co xml:id="network-nis-co-yppasswdd"/>
This line sets the <acronym>NIS</acronym> domain name to <literal>test-domain</literal>.
This automates the start up of the <acronym>NIS</acronym> server processes when the system boots.
This enables the <citerefentry><refentrytitle>rpc.yppasswdd</refentrytitle><manvolnum>8</manvolnum></citerefentry> daemon so that users can change their <acronym>NIS</acronym> password from a client machine.
Care must be taken in a multi-server domain where the server machines are also <acronym>NIS</acronym> clients. It is generally a good idea to force the servers to bind to themselves rather than allowing them to broadcast bind requests and possibly become bound to each other. Strange failure modes can result if one server goes down and others are dependent upon it. Eventually, all the clients will time out and attempt to bind to other servers, but the delay involved can be considerable and the failure mode is still present since the servers might bind to each other all over again.
A server that is also a client can be forced to bind to a particular server by adding these additional lines to <filename>/etc/rc.conf</filename>:
nis_client_enable="YES" <co xml:id="network-nis-co-client"/>
nis_client_flags="-S <replaceable>test-domain</replaceable>,<replaceable>server</replaceable>" <co xml:id="network-nis-co-clientflags"/>
This enables running client stuff as well.
This line sets the <acronym>NIS</acronym> domain name to <literal>test-domain</literal> and bind to itself.
After saving the edits, type <command>/etc/netstart</command> to restart the network and apply the values defined in <filename>/etc/rc.conf</filename>. Before initializing the <acronym>NIS</acronym> maps, start <citerefentry><refentrytitle>ypserv</refentrytitle><manvolnum>8</manvolnum></citerefentry>:
<prompt>#</prompt> <userinput>service ypserv start</userinput>
Initializing the <acronym>NIS</acronym> Maps
<primary>NIS</primary> <secondary>maps</secondary>
<acronym>NIS</acronym> maps are generated from the configuration files in <filename>/etc</filename> on the <acronym>NIS</acronym> master, with one exception: <filename>/etc/master.passwd</filename>. This is to prevent the propagation of passwords to all the servers in the <acronym>NIS</acronym> domain. Therefore, before the <acronym>NIS</acronym> maps are initialized, configure the primary password files:
<prompt>#</prompt> <userinput>cp /etc/master.passwd /var/yp/master.passwd</userinput>
<prompt>#</prompt> <userinput>cd /var/yp</userinput>
<prompt>#</prompt> <userinput>vi master.passwd</userinput>
It is advisable to remove all entries for system accounts as well as any user accounts that do not need to be propagated to the <acronym>NIS</acronym> clients, such as the <systemitem class="username">root</systemitem> and any other administrative accounts.
Ensure that the <filename>/var/yp/master.passwd</filename> is neither group or world readable by setting its permissions to <literal>600</literal>.
After completing this task, initialize the <acronym>NIS</acronym> maps. FreeBSD includes the <citerefentry><refentrytitle>ypinit</refentrytitle><manvolnum>8</manvolnum></citerefentry> script to do this. When generating maps for the master server, include <option>-m</option> and specify the <acronym>NIS</acronym> domain name:
ellington<prompt>#</prompt> <userinput>ypinit -m test-domain</userinput>
Server Type: MASTER Domain: test-domain
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n] <userinput>n</userinput>
Ok, please remember to go back and redo manually whatever fails.
If not, something might not work.
At this point, we have to construct a list of this domains YP servers.
rod.darktech.org is already known as master server.
Please continue to add any slave servers, one per line. When you are
done with the list, type a &lt;control D&gt;.
master server : ellington
next host to add: <userinput>coltrane</userinput>
next host to add: <userinput>^D</userinput>
The current list of NIS servers looks like this:
ellington
coltrane
Is this correct? [y/n: y] <userinput>y</userinput>

[..output from map generation..]

NIS Map update completed.
ellington has been setup as an YP master server without any errors.
This will create <filename>/var/yp/Makefile</filename> from <filename>/var/yp/Makefile.dist</filename>. By default, this file assumes that the environment has a single <acronym>NIS</acronym> server with only FreeBSD clients. Since <literal>test-domain</literal> has a slave server, edit this line in <filename>/var/yp/Makefile</filename> so that it begins with a comment (<literal>#</literal>):
NOPUSH = "True"
Adding New Users
Every time a new user is created, the user account must be added to the master <acronym>NIS</acronym> server and the <acronym>NIS</acronym> maps rebuilt. Until this occurs, the new user will not be able to login anywhere except on the <acronym>NIS</acronym> master. For example, to add the new user <systemitem class="username">jsmith</systemitem> to the <literal>test-domain</literal> domain, run these commands on the master server:
<prompt>#</prompt> <userinput>pw useradd jsmith</userinput>
<prompt>#</prompt> <userinput>cd /var/yp</userinput>
<prompt>#</prompt> <userinput>make test-domain</userinput>

Loading…

User avatar None

New source string

FreeBSD Doc / books_handbookEnglish

New source string 4 months ago
Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: callout/para
Flags
read-only
Source string location
book.translate.xml:54351
String age
4 months ago
Source string age
4 months ago
Translation file
books/handbook.pot, string 8897