svn commit: r42526 - head/en_US.ISO8859-1/books/handbook/network-servers
Warren Block
wblock at FreeBSD.org
Fri Aug 9 21:49:13 UTC 2013
Author: wblock
Date: Fri Aug 9 21:49:13 2013
New Revision: 42526
URL: http://svnweb.freebsd.org/changeset/doc/42526
Log:
Whitespace-only fixes. Translators, please ignore.
Modified:
head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Fri Aug 9 20:37:45 2013 (r42525)
+++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Fri Aug 9 21:49:13 2013 (r42526)
@@ -32,7 +32,6 @@
<para>By the end of this chapter, readers will know:</para>
<itemizedlist>
-
<listitem>
<para>How to manage the <application>inetd</application>
daemon.</para>
@@ -90,7 +89,6 @@
<command>syslogd</command>, to accept logs from remote
hosts.</para>
</listitem>
-
</itemizedlist>
<para>This chapter assumes a basic knowledge of:</para>
@@ -108,7 +106,6 @@
<para>Installation of additional third-party
software (<xref linkend="ports"/>).</para>
</listitem>
-
</itemizedlist>
</sect1>
@@ -164,15 +161,13 @@
<title>Settings</title>
<para><application>inetd</application> is initialized through
- the &man.rc.8; system. The
- <literal>inetd_enable</literal> option is set to
- <literal>NO</literal> by default. It can be enabled
- by placing:</para>
+ the &man.rc.8; system. The <literal>inetd_enable</literal>
+ option is set to <literal>NO</literal> by default. It can be
+ enabled by placing:</para>
<programlisting>inetd_enable="YES"</programlisting>
- <para>into
- <filename>/etc/rc.conf</filename>.
+ <para>into <filename>/etc/rc.conf</filename>.
<application>inetd</application> will now start at boot time.
The command:</para>
@@ -291,8 +286,8 @@ user[:group][/login-class]
server-program
server-program-arguments</programlisting>
- <para>An example entry for the &man.ftpd.8; daemon
- using IPv4 might read:</para>
+ <para>An example entry for the &man.ftpd.8; daemon using IPv4
+ might read:</para>
<programlisting>ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l</programlisting>
@@ -338,6 +333,7 @@ server-program-arguments</programlisting
<entry>Explanation</entry>
</row>
</thead>
+
<tbody>
<row>
<entry>tcp, tcp4</entry>
@@ -423,15 +419,15 @@ server-program-arguments</programlisting
<para>A stream-type multi-threaded daemon without any
<option>max-child</option>,
<option>max-connections-per-ip-per-minute</option> or
- <option>max-child-per-ip</option> limits
- would simply be: <literal>nowait</literal>.</para>
+ <option>max-child-per-ip</option> limits would simply
+ be: <literal>nowait</literal>.</para>
<para>The same daemon with a maximum limit of ten daemons
would read: <literal>nowait/10</literal>.</para>
- <para>The same setup with a limit of twenty
- connections per IP address per minute and a maximum
- total limit of ten child daemons would read:
+ <para>The same setup with a limit of twenty connections
+ per IP address per minute and a maximum total limit of
+ ten child daemons would read:
<literal>nowait/10/20</literal>.</para>
<para>These options are utilized by the default
@@ -498,22 +494,22 @@ server-program-arguments</programlisting
by default. If there is no apparent need for a particular
daemon, consider disabling it. Place a <quote>#</quote> in
front of the daemon in question in
- <filename>/etc/inetd.conf</filename>, and then <link
- linkend="network-inetd-reread">reload the
- inetd configuration</link>. Some daemons, such as
+ <filename>/etc/inetd.conf</filename>, and then
+ <link linkend="network-inetd-reread">reload the
+ inetd configuration</link>. Some daemons, such as
<application>fingerd</application>, may not be desired at all
- because they provide
- information that may be useful to an attacker.</para>
+ because they provide information that may be useful to an
+ attacker.</para>
<para>Some daemons are not security-conscious and have long or
non-existent timeouts for connection attempts. An attacker
can send connections to a particular daemon, eventually
- consuming available resources and resulting in a Denial of
+ consuming available resources and resulting in a Denial of
Service (<acronym>DoS</acronym>).
<literal>max-connections-per-ip-per-minute</literal>,
<literal>max-child</literal> and
- <literal>max-child-per-ip</literal> can be used to limit
- such attacks.</para>
+ <literal>max-child-per-ip</literal> can be used to limit such
+ attacks.</para>
<para>By default, TCP wrapping is turned on. Consult the
&man.hosts.access.5; manual page for more information on
@@ -533,9 +529,8 @@ server-program-arguments</programlisting
services of <application>inetd</application>.</para>
<para>The <application>auth</application> service provides
- identity network services, and is
- configurable to a certain degree, whilst the others are simply
- on or off.</para>
+ identity network services, and is configurable to a certain
+ degree, whilst the others are simply on or off.</para>
<para>Consult the &man.inetd.8; manual page for more in-depth
information.</para>
@@ -636,6 +631,7 @@ server-program-arguments</programlisting
<entry>Description</entry>
</row>
</thead>
+
<tbody>
<row>
<entry><application>nfsd</application></entry>
@@ -718,10 +714,10 @@ mountd_flags="-r"</programlisting>
<secondary>export examples</secondary>
</indexterm>
- <para>The following examples give an idea of how to export
- file systems, although the settings may be different depending
- on the environment and network configuration. For instance,
- to export the <filename>/cdrom</filename> directory to three
+ <para>The following examples give an idea of how to export file
+ systems, although the settings may be different depending on
+ the environment and network configuration. For instance, to
+ export the <filename>/cdrom</filename> directory to three
example machines that have the same domain name as the server
(hence the lack of a domain name for each) or have entries in
the <filename>/etc/hosts</filename> file. The
@@ -826,8 +822,8 @@ mountd_flags="-r"</programlisting>
<para>Now everything should be ready to actually mount a remote
file system. In these examples the server's name will be
<hostid>server</hostid> and the client's name will be
- <hostid>client</hostid>. For testing or to temporarily
- mount a remote file system execute a command like this as
+ <hostid>client</hostid>. For testing or to temporarily mount
+ a remote file system execute a command like this as
<username>root</username> on the client:</para>
<indexterm>
@@ -842,8 +838,8 @@ mountd_flags="-r"</programlisting>
visible and available in the <filename>/mnt</filename>
directory.</para>
- <para>To permanently mount a remote file system
- each time the computer boots, add the file system to the
+ <para>To permanently mount a remote file system each time the
+ computer boots, add the file system to the
<filename>/etc/fstab</filename> file. Here is an
example:</para>
@@ -940,12 +936,11 @@ rpc_statd_enable="YES"</programlisting>
<primary>automatic mounter daemon</primary>
</indexterm>
- <para>&man.amd.8; (the automatic mounter daemon)
- automatically mounts a
- remote file system whenever a file or directory within that
- file system is accessed. Filesystems that are inactive for a
- period of time will also be automatically unmounted by
- <application>amd</application>. Using
+ <para>&man.amd.8; (the automatic mounter daemon) automatically
+ mounts a remote file system whenever a file or directory
+ within that file system is accessed. Filesystems that are
+ inactive for a period of time will also be automatically
+ unmounted by <application>amd</application>. Using
<application>amd</application> provides a simple alternative
to permanent mounts, as permanent mounts are usually listed in
<filename>/etc/fstab</filename>.</para>
@@ -957,8 +952,8 @@ rpc_statd_enable="YES"</programlisting>
<application>amd</application> looks up the corresponding
remote mount and automatically mounts it.
<filename>/net</filename> is used to mount an exported file
- system from an IP address, while <filename>/host</filename>
- is used to mount an export from a remote hostname.</para>
+ system from an IP address, while <filename>/host</filename> is
+ used to mount an export from a remote hostname.</para>
<para>An access to a file within
<filename>/host/foobar/usr</filename> would tell
@@ -971,9 +966,8 @@ rpc_statd_enable="YES"</programlisting>
<application>amd</application></title>
<para>The <command>showmount</command> command shows the
- available mounts on a remote host. For example, to
- view the mounts of a host named
- <hostid>foobar</hostid>:</para>
+ available mounts on a remote host. For example, to view the
+ mounts of a host named <hostid>foobar</hostid>:</para>
<screen>&prompt.user; <userinput>showmount -e foobar</userinput>
Exports list on foobar:
@@ -1208,10 +1202,10 @@ Exports list on foobar:
<sect2>
<title><acronym>NIS</acronym>Terms and Processes</title>
- <para>There are several terms and important user
- processes that will be explained while attempting to
- implement NIS on FreeBSD, regardless if the system is a
- NIS server or a NIS client:</para>
+ <para>There are several terms and important user processes that
+ will be explained while attempting to implement NIS on
+ FreeBSD, regardless if the system is a NIS server or a NIS
+ client:</para>
<indexterm>
<primary><application>rpcbind</application></primary>
@@ -1231,6 +1225,7 @@ Exports list on foobar:
<entry>Description</entry>
</row>
</thead>
+
<tbody>
<row>
<entry>NIS domainname</entry>
@@ -1296,7 +1291,6 @@ Exports list on foobar:
</informaltable>
<!-- XXX Missing: rpc.ypxfrd (not important, though) May only run
on the master -->
-
</sect2>
<sect2>
@@ -1380,15 +1374,14 @@ Exports list on foobar:
<title>Planning</title>
<para>Let us assume that an administrator of a small
- university lab, which consists of 15 FreeBSD
- machines, currently has no centralized point of
- administration. Each machine has its own
- <filename>/etc/passwd</filename> and
+ university lab, which consists of 15 FreeBSD machines,
+ currently has no centralized point of administration. Each
+ machine has its own <filename>/etc/passwd</filename> and
<filename>/etc/master.passwd</filename>. These files are
kept in sync with each other only through manual
intervention; currently, a user is added to the lab, the
- process must be ran on all 15 machines.
- The lab would clearly benefit from the addition of two
+ process must be ran on all 15 machines. The lab would
+ clearly benefit from the addition of two
<acronym>NIS</acronym> servers.</para>
<para>Therefore, the configuration of the lab now looks
@@ -1403,6 +1396,7 @@ Exports list on foobar:
<entry>Machine role</entry>
</row>
</thead>
+
<tbody>
<row>
<entry><hostid>ellington</hostid></entry>
@@ -1807,15 +1801,15 @@ Remember to update map ypservers on elli
<primary>NIS</primary>
<secondary>client configuration</secondary>
</indexterm>
- <para>Setting up a FreeBSD machine to be a NIS
- client is fairly straightforward.</para>
+ <para>Setting up a FreeBSD machine to be a NIS client is
+ fairly straightforward.</para>
<procedure>
<step>
- <para>Edit <filename>/etc/rc.conf</filename>
- and add the following lines in order to set the NIS
- domainname and start <command>ypbind</command> during
- network startup:</para>
+ <para>Edit <filename>/etc/rc.conf</filename> and add the
+ following lines in order to set the NIS domainname and
+ start <command>ypbind</command> during network
+ startup:</para>
<programlisting>nisdomainname="test-domain"
nis_client_enable="YES"</programlisting>
@@ -1835,10 +1829,9 @@ nis_client_enable="YES"</programlisting>
account in the NIS server's password maps an
account. There are many ways to configure the NIS
client by changing this line. See the
- <link
- linkend="network-netgroups">netgroups
- section</link> below for more information. For more
- detailed reading see O'Reilly's book on
+ <link linkend="network-netgroups">netgroups
+ section</link> below for more information. For
+ more detailed reading see O'Reilly's book on
<literal>Managing NFS and NIS</literal>.</para>
</note>
@@ -1948,13 +1941,13 @@ nis_client_enable="YES"</programlisting>
<indexterm><primary>TCP Wrappers</primary></indexterm>
<para>The use of <application>TCP Wrapper</application>
- increases the latency of the NIS server. The
- additional delay may be long enough to cause timeouts in
- client programs, especially in busy networks or with slow
- NIS servers. If one or more of the client systems
- suffers from these symptoms, convert the client
- systems in question into NIS slave servers and force them
- to bind to themselves.</para>
+ increases the latency of the NIS server. The additional
+ delay may be long enough to cause timeouts in client
+ programs, especially in busy networks or with slow NIS
+ servers. If one or more of the client systems suffers from
+ these symptoms, convert the client systems in question into
+ NIS slave servers and force them to bind to
+ themselves.</para>
</note>
</sect2>
@@ -1972,19 +1965,18 @@ nis_client_enable="YES"</programlisting>
machine, even if they are present in the NIS database. To do
this, add
<literal>-<replaceable>username</replaceable></literal> with
- the correct number of colons like other entries to the
- end of the <filename>/etc/master.passwd</filename> file on the
- client machine, where <replaceable>username</replaceable> is
- the username of the user to bar from logging in.
- The line with the blocked user must be before the
- <literal>+</literal> line for allowing NIS users.
- This should preferably be done using <command>vipw</command>,
- since <command>vipw</command> will sanity check the changes
- to <filename>/etc/master.passwd</filename>, as well as
- automatically rebuild the password database after
- editing. For example, to bar user
- <username>bill</username> from logging on to
- <hostid>basie</hostid>:</para>
+ the correct number of colons like other entries to the end of
+ the <filename>/etc/master.passwd</filename> file on the client
+ machine, where <replaceable>username</replaceable> is the
+ username of the user to bar from logging in. The line with
+ the blocked user must be before the <literal>+</literal> line
+ for allowing NIS users. This should preferably be done using
+ <command>vipw</command>, since <command>vipw</command> will
+ sanity check the changes to
+ <filename>/etc/master.passwd</filename>, as well as
+ automatically rebuild the password database after editing.
+ For example, to bar user <username>bill</username> from
+ logging on to <hostid>basie</hostid>:</para>
<screen>basie&prompt.root; <userinput>vipw</userinput>
<userinput>[add -bill::::::::: to the end, exit]</userinput>
@@ -2033,10 +2025,9 @@ basie&prompt.root;</screen>
well for special rules in an environment with small numbers of
users and/or machines. On larger networks, administrators
<emphasis>will</emphasis> likely forget to bar some users from
- logging onto sensitive machines, or may even have to
- modify each machine separately, thus losing the main benefit
- of NIS: <emphasis>centralized</emphasis>
- administration.</para>
+ logging onto sensitive machines, or may even have to modify
+ each machine separately, thus losing the main benefit of NIS:
+ <emphasis>centralized</emphasis> administration.</para>
<para>The NIS developers' solution for this problem is called
<emphasis>netgroups</emphasis>. Their purpose and semantics
@@ -2047,18 +2038,16 @@ basie&prompt.root;</screen>
<para>Netgroups were developed to handle large, complex networks
with hundreds of users and machines. On one hand, this is a
- Good Thing in such a situation.
- On the other hand, this complexity makes it almost impossible
- to explain netgroups with really simple examples. The example
- used in the remainder of this section demonstrates this
- problem.</para>
+ Good Thing in such a situation. On the other hand, this
+ complexity makes it almost impossible to explain netgroups
+ with really simple examples. The example used in the
+ remainder of this section demonstrates this problem.</para>
<para>Let us assume that the successful introduction of NIS in
- the laboratory caught a superiors' interest. The next
- task is to extend the NIS domain to cover some of the other
- machines on campus. The two tables contain the names of the
- new users and new machines as well as brief descriptions of
- them.</para>
+ the laboratory caught a superiors' interest. The next task is
+ to extend the NIS domain to cover some of the other machines
+ on campus. The two tables contain the names of the new users
+ and new machines as well as brief descriptions of them.</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
@@ -2159,21 +2148,21 @@ basie&prompt.root;</screen>
<para>Handling this situation with netgroups offers several
advantages. Each user need not be handled separately; they
- would be assigned to one or more netgroups and logins would
- be allowed or forbidden for all members of the netgroup.
- While adding a new
- machine, login restrictions must be defined for all
- netgroups. If a new user is added, they must be added
- to one or more netgroups. Those changes are
- independent of each other: no more <quote>for each combination
- of user and machine do...</quote> If the NIS setup is planned
- carefully, only one central configuration file
- needs modification to grant or deny access to machines.</para>
+ would be assigned to one or more netgroups and logins would be
+ allowed or forbidden for all members of the netgroup. While
+ adding a new machine, login restrictions must be defined for
+ all netgroups. If a new user is added, they must be added to
+ one or more netgroups. Those changes are independent of each
+ other: no more
+ <quote>for each combination of user and machine do...</quote>
+ If the NIS setup is planned carefully, only one central
+ configuration file needs modification to grant or deny access
+ to machines.</para>
<para>The first step is the initialization of the NIS map
- netgroup. &os;'s &man.ypinit.8; does not create this map
- by default, but its NIS implementation will support it
- after creation. To create an empty map, simply type</para>
+ netgroup. &os;'s &man.ypinit.8; does not create this map by
+ default, but its NIS implementation will support it after
+ creation. To create an empty map, simply type</para>
<screen>ellington&prompt.root; <userinput>vi /var/yp/netgroup</userinput></screen>
@@ -2195,10 +2184,9 @@ INTERNS (,able,test-domain) (,baker,
<orderedlist>
<listitem>
<para>The name of the host(s) where the following items are
- valid. If a hostname is not specified, the entry is
- valid on all hosts. If a hostname is specified, it
- will need to be micro-managed within this
- configuration.</para>
+ valid. If a hostname is not specified, the entry is valid
+ on all hosts. If a hostname is specified, it will need to
+ be micro-managed within this configuration.</para>
</listitem>
<listitem>
@@ -2218,11 +2206,11 @@ INTERNS (,able,test-domain) (,baker,
<note>
<indexterm><primary>netgroups</primary></indexterm>
<para>Netgroup names longer than 8 characters should not be
- used, especially with machines running other
- operating systems within the NIS domain. The names are
- case sensitive; using capital letters for netgroup
- names is an easy way to distinguish between user, machine
- and netgroup names.</para>
+ used, especially with machines running other operating
+ systems within the NIS domain. The names are case
+ sensitive; using capital letters for netgroup names is an
+ easy way to distinguish between user, machine and netgroup
+ names.</para>
<para>Some NIS clients (other than &os;) cannot handle
netgroups with a large number of entries. For example, some
@@ -2237,8 +2225,8 @@ BIGGRP2 (,joe16,domain) (,joe17,domain
BIGGRP3 (,joe31,domain) (,joe32,domain)
BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3</programlisting>
- <para>Repeat this process if more than 225
- users will exist within a single netgroup.</para>
+ <para>Repeat this process if more than 225 users will exist
+ within a single netgroup.</para>
</note>
<para>Activating and distributing the new NIS map is
@@ -2260,12 +2248,12 @@ ellington&prompt.user; <userinput>ypcat
<para>The output of the first command should resemble the
contents of <filename>/var/yp/netgroup</filename>. The second
command will not produce output without specified
- host-specific netgroups. The third command may be used to
- get the list of netgroups for a user.</para>
+ host-specific netgroups. The third command may be used to get
+ the list of netgroups for a user.</para>
<para>The client setup is quite simple. To configure the server
- <hostid>war</hostid>, use
- &man.vipw.8; to replace the line</para>
+ <hostid>war</hostid>, use &man.vipw.8; to replace the
+ line</para>
<programlisting>+:::::::::</programlisting>
@@ -2275,19 +2263,19 @@ ellington&prompt.user; <userinput>ypcat
<para>Now, only the data for the users defined in the netgroup
<literal>IT_EMP</literal> is imported into
- <hostid>war</hostid>'s password database and only
- these users are allowed to login.</para>
+ <hostid>war</hostid>'s password database and only these users
+ are allowed to login.</para>
<para>Unfortunately, this limitation also applies to the
<literal>~</literal> function of the shell and all routines
converting between user names and numerical user IDs. In
- other words, <command>cd
- ~<replaceable>user</replaceable></command> will not work,
- <command>ls -l</command> will show the numerical ID instead of
- the username and <command>find . -user joe -print</command>
- will fail with <errorname>No such user</errorname>. To fix
- this, import all user entries
- <emphasis>without allowing them to login into the
+ other words,
+ <command>cd ~<replaceable>user</replaceable></command> will
+ not work, <command>ls -l</command> will show the numerical ID
+ instead of the username and
+ <command>find . -user joe -print</command> will fail with
+ <errorname>No such user</errorname>. To fix this, import all
+ user entries <emphasis>without allowing them to login into the
servers</emphasis>.</para>
<para>This can be achieved by adding another line to
@@ -2333,11 +2321,11 @@ ellington&prompt.user; <userinput>ypcat
change a few weeks later: The IT department starts hiring
interns. The IT interns are allowed to use the normal
workstations and the less important servers; and the IT
- apprentices are allowed to login onto the main servers.
- Add a new netgroup <literal>IT_INTERN</literal>, then add the
- new IT interns to this netgroup and start to change the
- configuration on each and every machine. As the old saying
- goes: <quote>Errors in centralized planning lead to global
+ apprentices are allowed to login onto the main servers. Add a
+ new netgroup <literal>IT_INTERN</literal>, then add the new IT
+ interns to this netgroup and start to change the configuration
+ on each and every machine. As the old saying goes:
+ <quote>Errors in centralized planning lead to global
mess</quote>.</para>
<para>NIS' ability to create netgroups from other netgroups can
@@ -2347,11 +2335,10 @@ ellington&prompt.user; <userinput>ypcat
the login restrictions for the important servers, another
netgroup called <literal>SMALLSRV</literal> for the less
important servers and a third netgroup called
- <literal>USERBOX</literal> for the normal
- workstations. Each of these netgroups contains the netgroups
- that are allowed to login onto these machines. The new
- entries for the NIS map netgroup should look like
- this:</para>
+ <literal>USERBOX</literal> for the normal workstations. Each
+ of these netgroups contains the netgroups that are allowed to
+ login onto these machines. The new entries for the NIS map
+ netgroup should look like this:</para>
<programlisting>BIGSRV IT_EMP IT_APP
SMALLSRV IT_EMP IT_APP ITINTERN
@@ -2378,12 +2365,12 @@ USERBOX IT_EMP ITINTERN USERS</progra
<programlisting>+@<replaceable>BOXNAME</replaceable>:::::::::
+:::::::::/sbin/nologin</programlisting>
- <para>Once this task is completed on all the machines,
- there is no longer a need to modify the local versions of
+ <para>Once this task is completed on all the machines, there is
+ no longer a need to modify the local versions of
<filename>/etc/master.passwd</filename> ever again. All
further changes can be handled by modifying the NIS map. Here
- is an example of a possible netgroup map for this
- scenario with some additional goodies:</para>
+ is an example of a possible netgroup map for this scenario
+ with some additional goodies:</para>
<programlisting># Define groups of users first
IT_EMP (,alpha,test-domain) (,beta,test-domain)
@@ -2443,8 +2430,8 @@ TWO (,hotel,test-domain)
<itemizedlist>
<listitem>
- <para>Every time a new user is added to the lab, they
- must be added to the master NIS server and the
+ <para>Every time a new user is added to the lab, they must
+ be added to the master NIS server and the
<acronym>NIS</acronym> maps will need rebuilt. If this
step is omitted, the new user will not be able to login
anywhere except on the NIS master. For example, if we
@@ -2458,8 +2445,8 @@ TWO (,hotel,test-domain)
<para>The user may also be added using
<command>adduser jsmith</command>
instead of <command>pw useradd jsmith</command>.</para>
-
</listitem>
+
<listitem>
<para><emphasis>Keep the administration accounts out of the
NIS maps</emphasis>. This is undesirable as it will
@@ -2468,6 +2455,7 @@ TWO (,hotel,test-domain)
machines will have users whom should not have access to
those accounts.</para>
</listitem>
+
<listitem>
<para><emphasis>Keep the NIS master and slave secure, and
minimize their downtime</emphasis>. If somebody either
@@ -2570,30 +2558,32 @@ nis_client_flags="-S <replaceable>NIS do
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
- <note><para>The format of passwords already in
- <filename>/etc/master.passwd</filename> will not be updated
- until a user changes his password for the first time
- <emphasis>after</emphasis> the login capability database is
- rebuilt.</para></note>
+ <note>
+ <para>The format of passwords already in
+ <filename>/etc/master.passwd</filename> will not be updated
+ until a user changes his password for the first time
+ <emphasis>after</emphasis> the login capability database is
+ rebuilt.</para>
+ </note>
<para>Next, in order to ensure that passwords are encrypted with
- the chosen format, check that
- the <literal>crypt_default</literal> in
+ the chosen format, check that the
+ <literal>crypt_default</literal> in
<filename>/etc/auth.conf</filename> gives precedence to the
chosen password format. To do this, place the chosen format
- first in the list. For example, when using DES
- encrypted passwords, the entry would be:</para>
+ first in the list. For example, when using DES encrypted
+ passwords, the entry would be:</para>
<programlisting>crypt_default = des blf md5</programlisting>
<para>Having followed the above steps on each of the &os; based
- NIS servers and clients, verify that they all agree
- on which password format is used within the network. If users
- have trouble authenticating on an NIS client, this is a pretty
- good place to start looking for possible problems. Remember:
- to deploy an NIS server for a heterogeneous
- network, they will probably have to use DES on all systems
- because it is the lowest common standard.</para>
+ NIS servers and clients, verify that they all agree on which
+ password format is used within the network. If users have
+ trouble authenticating on an NIS client, this is a pretty good
+ place to start looking for possible problems. Remember: to
+ deploy an NIS server for a heterogeneous network, they will
+ probably have to use DES on all systems because it is the
+ lowest common standard.</para>
</sect2>
</sect1>
@@ -2840,8 +2830,8 @@ rootpw {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g
<para>Finally, enable the <application>OpenLDAP</application>
service in <filename>rc.conf</filename>. At this time,
setting up a <acronym>URI</acronym> and providing the group
- and user to run as may be useful.
- Edit <filename>/etc/rc.conf</filename> and add the following
+ and user to run as may be useful. Edit
+ <filename>/etc/rc.conf</filename> and add the following
lines:</para>
<programlisting>slapd_enable="YES"
@@ -3133,10 +3123,10 @@ dhclient_flags=""</programlisting>
<secondary>server</secondary>
</indexterm>
<para>The DHCP server, <application>dhcpd</application>, is
- included as part of the <filename
- role="package">net/isc-dhcp42-server</filename> port in
- the ports collection. This port contains the ISC DHCP
- server and documentation.</para>
+ included as part of the
+ <filename role="package">net/isc-dhcp42-server</filename>
+ port in the ports collection. This port contains the ISC
+ DHCP server and documentation.</para>
</sect2>
<sect2>
@@ -3188,7 +3178,7 @@ dhclient_flags=""</programlisting>
<para>The DHCP protocol is fully described in <ulink
url="http://www.freesoft.org/CIE/RFC/2131/">RFC
- 2131</ulink>. An informational resource has also been set
+ 2131</ulink>. An informational resource has also been set
up at <ulink url="http://www.dhcp.org/"></ulink>.</para>
</sect2>
@@ -3654,16 +3644,15 @@ dhcpd_ifaces="dc0"</programlisting>
</listitem>
</itemizedlist>
- <para>When one queries for <hostid
- role="fqdn">www.FreeBSD.org</hostid>, the resolver usually
- queries the uplink <acronym>ISP</acronym>'s name server, and
- retrieves the reply. With a local, caching
+ <para>When one queries for
+ <hostid role="fqdn">www.FreeBSD.org</hostid>, the resolver
+ usually queries the uplink <acronym>ISP</acronym>'s name
+ server, and retrieves the reply. With a local, caching
<acronym>DNS</acronym> server, the query only has to be made
once to the outside world by the caching
<acronym>DNS</acronym> server. Additional queries will not
have to go outside the local network, since the information is
- cached
- locally.</para>
+ cached locally.</para>
</sect2>
<sect2>
@@ -3708,14 +3697,14 @@ dhcpd_ifaces="dc0"</programlisting>
</informaltable>
<para>Depending on how a given zone is configured on the server,
- the files related to that zone can be found in the <filename
- class="directory">master</filename>, <filename
- class="directory">slave</filename>, or <filename
- class="directory">dynamic</filename> subdirectories of the
- <filename class="directory">/etc/namedb</filename> directory.
- These files contain the <acronym>DNS</acronym> information
- that will be given out by the name server in response to
- queries.</para>
+ the files related to that zone can be found in the
+ <filename class="directory">master</filename>,
+ <filename class="directory">slave</filename>, or
+ <filename class="directory">dynamic</filename> subdirectories
+ of the <filename class="directory">/etc/namedb</filename>
+ directory. These files contain the <acronym>DNS</acronym>
+ information that will be given out by the name server in
+ response to queries.</para>
</sect2>
<sect2>
@@ -3731,10 +3720,10 @@ dhcpd_ifaces="dc0"</programlisting>
<para>The default <application>named</application> configuration
is that of a basic resolving name server, running in a
- &man.chroot.8; environment, and restricted to listening on
- the local IPv4 loopback address (127.0.0.1).
- To start the server one time with
- this configuration, use the following command:</para>
+ &man.chroot.8; environment, and restricted to listening on the
+ local IPv4 loopback address (127.0.0.1). To start the server
+ one time with this configuration, use the following
+ command:</para>
<screen>&prompt.root; <userinput>service named onestart</userinput></screen>
@@ -3747,12 +3736,11 @@ dhcpd_ifaces="dc0"</programlisting>
<para>There are obviously many configuration options for
<filename>/etc/namedb/named.conf</filename> that are beyond
the scope of this document. There are other startup options
- for <application>named</application> on
- &os;, take a look at the
- <literal>named_<replaceable>*</replaceable></literal> flags in
- <filename>/etc/defaults/rc.conf</filename> and consult the
- &man.rc.conf.5; manual page. The <xref
- linkend="configtuning-rcd"/> section is also a good
+ for <application>named</application> on &os;, take a look at
+ the <literal>named_<replaceable>*</replaceable></literal>
+ flags in <filename>/etc/defaults/rc.conf</filename> and
+ consult the &man.rc.conf.5; manual page. The
+ <xref linkend="configtuning-rcd"/> section is also a good
read.</para>
</sect2>
@@ -3765,11 +3753,11 @@ dhcpd_ifaces="dc0"</programlisting>
</indexterm>
<para>Configuration files for <application>named</application>
- currently reside in <filename
- class="directory">/etc/namedb</filename> directory and will
- need modification before use unless all that is needed is a
- simple resolver. This is where most of the configuration will
- be performed.</para>
+ currently reside in
+ <filename class="directory">/etc/namedb</filename> directory
+ and will need modification before use unless all that is
+ needed is a simple resolver. This is where most of the
+ configuration will be performed.</para>
<sect3>
<title><filename>/etc/namedb/named.conf</filename></title>
@@ -4128,10 +4116,10 @@ zone "1.168.192.in-addr.arpa" {
<secondary>zone files</secondary>
</indexterm>
- <para>An example master zone file for <hostid
- role="domainname">example.org</hostid> (existing within
- <filename>/etc/namedb/master/example.org</filename>) is as
- follows:</para>
+ <para>An example master zone file for
+ <hostid role="domainname">example.org</hostid> (existing
+ within <filename>/etc/namedb/master/example.org</filename>)
+ is as follows:</para>
<programlisting>$TTL 3600 ; 1 hour default TTL
example.org. IN SOA ns1.example.org. admin.example.org. (
@@ -4296,21 +4284,21 @@ mail IN A 192.168.
<programlisting> IN A 192.168.1.1</programlisting>
- <para>This line assigns IP address <hostid
- role="ipaddr">192.168.1.1</hostid> to the current origin,
- in this case <hostid
- role="domainname">example.org</hostid>.</para>
+ <para>This line assigns IP address
+ <hostid role="ipaddr">192.168.1.1</hostid> to the current
+ origin, in this case
+ <hostid role="domainname">example.org</hostid>.</para>
<programlisting>www IN CNAME @</programlisting>
<para>The canonical name record is usually used for giving
aliases to a machine. In the example, <hostid>www</hostid>
is aliased to the <quote>master</quote> machine whose name
- happens to be the same as the domain name <hostid
- role="domainname">example.org</hostid> (<hostid
- role="ipaddr">192.168.1.1</hostid>). CNAMEs can never be
- used together with another kind of record
- for the same hostname.</para>
+ happens to be the same as the domain name
+ <hostid role="domainname">example.org</hostid>
+ (<hostid role="ipaddr">192.168.1.1</hostid>). CNAMEs can
+ never be used together with another kind of record for the
+ same hostname.</para>
<indexterm>
<primary>MX record</primary>
@@ -4318,11 +4306,11 @@ mail IN A 192.168.
<programlisting> IN MX 10 mail.example.org.</programlisting>
- <para>The MX record indicates which mail
- servers are responsible for handling incoming mail for the
- zone. <hostid role="fqdn">mail.example.org</hostid> is the
- hostname of a mail server, and 10 is the priority of
- that mail server.</para>
+ <para>The MX record indicates which mail servers are
+ responsible for handling incoming mail for the zone.
+ <hostid role="fqdn">mail.example.org</hostid> is the
+ hostname of a mail server, and 10 is the priority of that
+ mail server.</para>
<para>One can have several mail servers, with priorities of
10, 20 and so on. A mail server attempting to deliver to
@@ -4466,22 +4454,22 @@ mail IN A 192.168.
were last updated. This output actually contains two keys.
The first key in the listing, with the value 257 after the
DNSKEY record type, is the one needed. This value indicates
- that this is a Secure Entry Point (<acronym
- role="Secure Entry Point">SEP</acronym>), commonly known
- as a Key Signing Key (<acronym
- role="Key Signing Key">KSK</acronym>). The second key,
- with value 256, is a subordinate key, commonly called a Zone
- Signing Key (<acronym
- role="Zone Signing Key">ZSK</acronym>). More on the
- different key types later in <xref
- linkend="dns-dnssec-auth"/>.</para>
+ that this is a Secure Entry Point
+ (<acronym role="Secure Entry Point">SEP</acronym>), commonly
+ known as a Key Signing Key
+ (<acronym role="Key Signing Key">KSK</acronym>). The second
+ key, with value 256, is a subordinate key, commonly called a
+ Zone Signing Key
+ (<acronym role="Zone Signing Key">ZSK</acronym>). More on
+ the different key types later in
+ <xref linkend="dns-dnssec-auth"/>.</para>
<para>Now the key must be verified and formatted so that
<acronym>BIND</acronym> can use it. To verify the key,
generate a <acronym role="Delegation Signer">DS</acronym>
<acronym role="Resource Record">RR</acronym> set. Create a
- file containing these <acronym
- role="Resource Record">RR</acronym>s with</para>
+ file containing these
+ <acronym role="Resource Record">RR</acronym>s with</para>
<screen>&prompt.user; <userinput>dnssec-dsfromkey -f root-dnskey . > root.ds</userinput></screen>
@@ -4579,12 +4567,12 @@ dnssec-validation yes;</programlisting>
required. A zone is signed using cryptographic keys which
must be generated. It is possible to use only one key for
this. The preferred method however is to have a strong
- well-protected Key Signing Key (<acronym
- role="Key Signing Key">KSK</acronym>) that is
- not rotated very often and a Zone Signing Key (<acronym
- role="Zone Signing Key">ZSK</acronym>) that is rotated more
- frequently. Information on recommended operational
- practices can be found in <ulink
+ well-protected Key Signing Key
+ (<acronym role="Key Signing Key">KSK</acronym>) that is
+ not rotated very often and a Zone Signing Key
+ (<acronym role="Zone Signing Key">ZSK</acronym>) that is
+ rotated more frequently. Information on recommended
+ operational practices can be found in <ulink
url="http://tools.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym>
4641: <acronym>DNSSEC</acronym> Operational
Practices</ulink>. Practices regarding the root zone can
@@ -4594,29 +4582,29 @@ dnssec-validation yes;</programlisting>
<acronym>KSK</acronym> operator</ulink> and <ulink
url="http://www.root-dnssec.org/wp-content/uploads/2010/06/vrsn-dps-00.txt"><acronym>DNSSEC</acronym>
Practice Statement for the Root Zone
- <acronym>ZSK</acronym> operator</ulink>. The <acronym
- role="Key Signing Key">KSK</acronym> is used to build a
- chain of authority to the data in need of validation and as
- such is also called a Secure Entry Point (<acronym
- role="Secure Entry Point">SEP</acronym>) key. A message
- digest of this key, called a Delegation Signer (<acronym
- role="Delegation Signer">DS</acronym>) record, must be
- published in the parent zone to establish the trust chain.
- How this is accomplished depends on the parent zone owner.
- The <acronym
- role="Zone Signing Key">ZSK</acronym> is used to sign the
- zone, and only needs to be published there.</para>
-
- <para>To enable <acronym>DNSSEC</acronym> for the <hostid
- role="domainname">example.com</hostid> zone depicted in
- previous examples, the first step is to use
+ <acronym>ZSK</acronym> operator</ulink>. The
+ <acronym role="Key Signing Key">KSK</acronym> is used to
+ build a chain of authority to the data in need of validation
+ and as such is also called a Secure Entry Point
+ (<acronym role="Secure Entry Point">SEP</acronym>) key. A
+ message digest of this key, called a Delegation Signer
+ (<acronym role="Delegation Signer">DS</acronym>) record,
+ must be published in the parent zone to establish the trust
+ chain. How this is accomplished depends on the parent zone
+ owner. The <acronym role="Zone Signing Key">ZSK</acronym>
+ is used to sign the zone, and only needs to be published
+ there.</para>
+
+ <para>To enable <acronym>DNSSEC</acronym> for the
+ <hostid role="domainname">example.com</hostid> zone depicted
+ in previous examples, the first step is to use
<application>dnssec-keygen</application> to generate the
<acronym>KSK</acronym> and <acronym>ZSK</acronym> key pair.
This key pair can utilize different cryptographic
algorithms. It is recommended to use RSA/SHA256 for the
keys and 2048 bits key length should be enough. To generate
- the <acronym>KSK</acronym> for <hostid
- role="domainname">example.com</hostid>, run</para>
+ the <acronym>KSK</acronym> for
+ <hostid role="domainname">example.com</hostid>, run</para>
<screen>&prompt.user; <userinput>dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen>
@@ -4632,9 +4620,9 @@ dnssec-validation yes;</programlisting>
(private). The <literal>nnnnn</literal> part of the file
name is a five digit key ID. Keep track of which key ID
belongs to which key. This is especially important when
- having more than one key in a zone. It is
- also possible to rename the keys. For each
- <acronym>KSK</acronym> file do:</para>
+ having more than one key in a zone. It is also possible to
+ rename the keys. For each <acronym>KSK</acronym> file
+ do:</para>
<screen>&prompt.user; <userinput>mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnnn.KSK.key</userinput>
&prompt.user; <userinput>mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private</userinput></screen>
@@ -4651,8 +4639,8 @@ $include Kexample.com.+005+nnnnn.ZSK.key
<para>Finally, sign the zone and tell <acronym>BIND</acronym>
to use the signed zone file. To sign a zone
<application>dnssec-signzone</application> is used. The
- command to sign the zone <hostid
- role="domainname">example.com</hostid>, located in
+ command to sign the zone
+ <hostid role="domainname">example.com</hostid>, located in
<filename>example.com.db</filename> would look similar
to</para>
@@ -4672,11 +4660,11 @@ $include Kexample.com.+005+nnnnn.ZSK.key
with all <acronym>RR</acronym>s signed. This output will
end up in a file with the extension
<literal>.signed</literal>, such as
- <filename>example.com.db.signed</filename>. The <acronym
- role="Delegation Signer">DS</acronym> records will also be
- written to a separate file
- <filename>dsset-example.com</filename>.
- To use this signed zone just modify the zone directive in
+ <filename>example.com.db.signed</filename>. The
+ <acronym role="Delegation Signer">DS</acronym> records will
+ also be written to a separate file
+ <filename>dsset-example.com</filename>. To use this signed
+ zone just modify the zone directive in
<filename>named.conf</filename> to use
<filename>example.com.db.signed</filename>. By default, the
signatures are only valid 30 days, meaning that the zone
@@ -4709,19 +4697,19 @@ $include Kexample.com.+005+nnnnn.ZSK.key
feature called <emphasis>Smart Signing</emphasis> was
introduced. This feature aims to make the key management
and signing process simpler by automating parts of the task.
- By putting the keys into a directory called a <emphasis>key
- repository</emphasis>, and using the new option
- <literal>auto-dnssec</literal>, it is possible to create a
- dynamic zone which will be resigned as needed. To update
- this zone use <application>nsupdate</application> with the
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-all
mailing list