Source string Read only

(itstool) path: sect2/programlisting
Context English State
<systemitem class="ipaddress">10.0.0.[6-17]</systemitem>
Other client machines
If this is the first time an <acronym>NIS</acronym> scheme is being developed, it should be thoroughly planned ahead of time. Regardless of network size, several decisions need to be made as part of the planning process.
Choosing a <acronym>NIS</acronym> Domain Name
<primary>NIS</primary> <secondary>domain name</secondary>
When a client broadcasts its requests for info, it includes the name of the <acronym>NIS</acronym> domain that it is part of. This is how multiple servers on one network can tell which server should answer which request. Think of the <acronym>NIS</acronym> domain name as the name for a group of hosts.
Some organizations choose to use their Internet domain name for their <acronym>NIS</acronym> domain name. This is not recommended as it can cause confusion when trying to debug network problems. The <acronym>NIS</acronym> domain name should be unique within the network and it is helpful if it describes the group of machines it represents. For example, the Art department at Acme Inc. might be in the <quote>acme-art</quote> <acronym>NIS</acronym> domain. This example will use the domain name <literal>test-domain</literal>.
However, some non-FreeBSD operating systems require the <acronym>NIS</acronym> domain name to be the same as the Internet domain name. If one or more machines on the network have this restriction, the Internet domain name <emphasis>must</emphasis> be used as the <acronym>NIS</acronym> domain name.
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.


User avatar None

New source string

FreeBSD Doc / books_handbookEnglish

New source string 4 months ago
Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks



English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect2/programlisting
no-wrap, read-only
Source string location
String age
4 months ago
Source string age
4 months ago
Translation file
books/handbook.pot, string 8889