Whitespace-only fixes. Translators, please ignore.
This commit is contained in:
Warren Block
parent
eda432163d
commit
a79b58e9c6
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=42603
1 changed files with 389 additions and 404 deletions
|
|
@ -22,12 +22,11 @@
|
|||
<sect1 id="network-servers-synopsis">
|
||||
<title>Synopsis</title>
|
||||
|
||||
<para>This chapter covers some of the more frequently used
|
||||
network services on &unix; systems. This includes
|
||||
installing, configuring, testing, and maintaining
|
||||
many different types of network services. Example
|
||||
configuration files are included throughout this
|
||||
chapter for reference.</para>
|
||||
<para>This chapter covers some of the more frequently used network
|
||||
services on &unix; systems. This includes installing,
|
||||
configuring, testing, and maintaining many different types of
|
||||
network services. Example configuration files are included
|
||||
throughout this chapter for reference.</para>
|
||||
|
||||
<para>By the end of this chapter, readers will know:</para>
|
||||
|
||||
|
|
@ -134,16 +133,15 @@
|
|||
|
||||
<para>The &man.inetd.8; daemon is sometimes referred to as the
|
||||
<quote>Internet Super-Server</quote> because it manages
|
||||
connections for many services. When a connection is
|
||||
received by <application>inetd</application>, it determines
|
||||
which program the connection is destined for, spawns the
|
||||
particular process and delegates the socket to it (the program
|
||||
is invoked with the service socket as its standard input,
|
||||
output and error descriptors). Running
|
||||
<application>inetd</application> for servers that are not
|
||||
heavily used can reduce the overall system load, when compared
|
||||
to running each daemon individually in stand-alone
|
||||
mode.</para>
|
||||
connections for many services. When a connection is received
|
||||
by <application>inetd</application>, it determines which
|
||||
program the connection is destined for, spawns the particular
|
||||
process and delegates the socket to it (the program is invoked
|
||||
with the service socket as its standard input, output and
|
||||
error descriptors). Running <application>inetd</application>
|
||||
for servers that are not heavily used can reduce the overall
|
||||
system load, when compared to running each daemon individually
|
||||
in stand-alone mode.</para>
|
||||
|
||||
<para>Primarily, <application>inetd</application> is used to
|
||||
spawn other daemons, but several trivial protocols are handled
|
||||
|
|
@ -413,8 +411,7 @@ server-program-arguments</programlisting>
|
|||
<option>nowait</option> is mandatory.
|
||||
<option>max-child</option>,
|
||||
<option>max-connections-per-ip-per-minute</option> and
|
||||
<option>max-child-per-ip</option> are
|
||||
optional.</para>
|
||||
<option>max-child-per-ip</option> are optional.</para>
|
||||
|
||||
<para>A stream-type multi-threaded daemon without any
|
||||
<option>max-child</option>,
|
||||
|
|
@ -560,8 +557,8 @@ server-program-arguments</programlisting>
|
|||
<para>&os; supports the Network File System
|
||||
(<acronym>NFS</acronym>), which allows a server to share
|
||||
directories and files with clients over a network. With
|
||||
<acronym>NFS</acronym>, users and programs can access files
|
||||
on remote systems as if they were stored locally.</para>
|
||||
<acronym>NFS</acronym>, users and programs can access files on
|
||||
remote systems as if they were stored locally.</para>
|
||||
|
||||
<para>The most notable benefits that
|
||||
<acronym>NFS</acronym> provides are:</para>
|
||||
|
|
@ -690,15 +687,14 @@ mountd_flags="-r"</programlisting>
|
|||
|
||||
<programlisting>nfs_client_enable="YES"</programlisting>
|
||||
|
||||
<para><filename>/etc/exports</filename> specifies which
|
||||
file systems the <acronym>NFS</acronym> server will
|
||||
export. Each line in
|
||||
<filename>/etc/exports</filename> specifies a file system to
|
||||
be exported and which clients have access to that file system,
|
||||
as well as any access options. There are many
|
||||
such options that can be used in this file, but only a few will
|
||||
be mentioned here. See &man.exports.5; for the full list of
|
||||
options.</para>
|
||||
<para><filename>/etc/exports</filename> specifies which file
|
||||
systems the <acronym>NFS</acronym> server will export. Each
|
||||
line in <filename>/etc/exports</filename> specifies a file
|
||||
system to be exported and which clients have access to that
|
||||
file system, as well as any access options. There are many
|
||||
such options that can be used in this file, but only a few
|
||||
will be mentioned here. See &man.exports.5; for the full list
|
||||
of options.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
|
|
@ -736,14 +732,14 @@ mountd_flags="-r"</programlisting>
|
|||
|
||||
<para>This next line exports
|
||||
<filename class="directory">/a</filename> so that two clients
|
||||
from different domains may access the file system.
|
||||
The <option>-maproot=root</option> flag allows the
|
||||
from different domains may access the file system. The
|
||||
<option>-maproot=root</option> flag allows the
|
||||
<username>root</username> user on the remote system to write
|
||||
data on the exported file system as <username>root</username>.
|
||||
If the <literal>-maproot=root</literal> flag is not specified,
|
||||
the client's <username>root</username> user will be mapped
|
||||
to the server's <username>nobody</username> account and will
|
||||
be subject to the access limitations defined for user,
|
||||
the client's <username>root</username> user will be mapped to
|
||||
the server's <username>nobody</username> account and will be
|
||||
subject to the access limitations defined for user,
|
||||
<username>nobody</username>.</para>
|
||||
|
||||
<programlisting>/a -maproot=root host.example.com box.example.org</programlisting>
|
||||
|
|
@ -765,9 +761,9 @@ mountd_flags="-r"</programlisting>
|
|||
/usr/ports client</programlisting>
|
||||
|
||||
<para>The <filename class="directory">/usr</filename> file
|
||||
system has two lines
|
||||
specifying exports to the same host, <hostid>client</hostid>.
|
||||
The correct format for this situation is:</para>
|
||||
system has two lines specifying exports to the same host,
|
||||
<hostid>client</hostid>. The correct format for this
|
||||
situation is:</para>
|
||||
|
||||
<programlisting>/usr/src /usr/ports client</programlisting>
|
||||
|
||||
|
|
@ -802,9 +798,8 @@ mountd_flags="-r"</programlisting>
|
|||
more information about using rc scripts.</para>
|
||||
|
||||
<para>On a new server being configured with
|
||||
<acronym>NFS</acronym> services, the server can be
|
||||
started by running this command as
|
||||
<username>root</username>:</para>
|
||||
<acronym>NFS</acronym> services, the server can be started by
|
||||
running this command as <username>root</username>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service nfsd start</userinput></screen>
|
||||
|
||||
|
|
@ -816,9 +811,9 @@ mountd_flags="-r"</programlisting>
|
|||
file system. In these examples, the server's name is
|
||||
<hostid>server</hostid> and the client's name is
|
||||
<hostid>client</hostid>. For testing or to temporarily mount
|
||||
a remote file system, execute
|
||||
<application>mount</application> as
|
||||
<username>root</username> on <hostid>client</hostid>:</para>
|
||||
a remote file system, execute <application>mount</application>
|
||||
as <username>root</username> on
|
||||
<hostid>client</hostid>:</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
|
|
@ -826,14 +821,11 @@ mountd_flags="-r"</programlisting>
|
|||
</indexterm>
|
||||
<screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen>
|
||||
|
||||
<para>This mounts the
|
||||
<hostid>server</hostid>:
|
||||
<filename class="directory">/home</filename>
|
||||
file system to the
|
||||
<hostid>client</hostid>:
|
||||
<filename class="directory">/mnt</filename> mount
|
||||
point. The files and directories in the
|
||||
<hostid>server</hostid>
|
||||
<para>This mounts the <hostid>server</hostid>:
|
||||
<filename class="directory">/home</filename> file system to
|
||||
the <hostid>client</hostid>:
|
||||
<filename class="directory">/mnt</filename> mount point. The
|
||||
files and directories in the <hostid>server</hostid>
|
||||
<filename class="directory">/home</filename> file system will
|
||||
now be available on <hostid>client</hostid>, in the
|
||||
<filename class="directory">/mnt</filename> directory.</para>
|
||||
|
|
@ -864,17 +856,17 @@ rpc_statd_enable="YES"</programlisting>
|
|||
<acronym>NFS</acronym> client and server are already
|
||||
configured.</para>
|
||||
|
||||
<para>Start the application, as
|
||||
<username>root</username>, with:</para>
|
||||
<para>Start the application, as <username>root</username>,
|
||||
with:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service lockd start</userinput>
|
||||
&prompt.root; <userinput>service statd start</userinput></screen>
|
||||
|
||||
<para>If locking is not required on the server, the
|
||||
<acronym>NFS</acronym> client can be configured to
|
||||
lock locally by passing <option>-L</option> to
|
||||
&man.mount.nfs.8;. Refer to the &man.mount.nfs.8;
|
||||
manual page for further details.</para>
|
||||
<acronym>NFS</acronym> client can be configured to lock
|
||||
locally by passing <option>-L</option> to &man.mount.nfs.8;.
|
||||
Refer to the &man.mount.nfs.8; manual page for further
|
||||
details.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
|
|
@ -889,10 +881,10 @@ rpc_statd_enable="YES"</programlisting>
|
|||
</indexterm>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Share a <acronym>CD-ROM</acronym> or other media
|
||||
with any number of clients. It is often more
|
||||
convenient to install software on multiple
|
||||
machines from a single location.</para>
|
||||
<para>Share a <acronym>CD-ROM</acronym> or other media with
|
||||
any number of clients. It is often more convenient to
|
||||
install software on multiple machines from a single
|
||||
location.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -904,8 +896,8 @@ rpc_statd_enable="YES"</programlisting>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Several clients may need access to the
|
||||
<filename class="directory">/usr/ports/distfiles</filename>
|
||||
<para>Several clients may need access to the <filename
|
||||
class="directory">/usr/ports/distfiles</filename>
|
||||
directory. Sharing that directory allows for quick access
|
||||
to the source files without having to download them to
|
||||
each client.</para>
|
||||
|
|
@ -949,19 +941,19 @@ rpc_statd_enable="YES"</programlisting>
|
|||
|
||||
<para><application>amd</application> operates by attaching
|
||||
itself as an NFS server to the
|
||||
<filename class="directory">/host</filename>
|
||||
and <filename class="directory">/net</filename> directories. When a file is
|
||||
accessed within one of these directories,
|
||||
<filename class="directory">/host</filename> and
|
||||
<filename class="directory">/net</filename> directories. When
|
||||
a file is accessed within one of these directories,
|
||||
<application>amd</application> looks up the corresponding
|
||||
remote mount and automatically mounts it.
|
||||
<filename class="directory">/net</filename> is used to mount an exported file
|
||||
system from an IP address, while
|
||||
<filename class="directory">/host</filename> is
|
||||
used to mount an export from a remote hostname.</para>
|
||||
<filename class="directory">/net</filename> is used to mount
|
||||
an exported file system from an IP address, while
|
||||
<filename class="directory">/host</filename> is used to mount
|
||||
an export from a remote hostname.</para>
|
||||
|
||||
<para>For instance, an attempt to access a file within
|
||||
<filename class="directory">/host/foobar/usr</filename> would tell
|
||||
<application>amd</application> to mount the
|
||||
<filename class="directory">/host/foobar/usr</filename> would
|
||||
tell <application>amd</application> to mount the
|
||||
<filename class="directory">/usr</filename> export on the host
|
||||
<hostid>foobar</hostid>.</para>
|
||||
|
||||
|
|
@ -981,13 +973,13 @@ Exports list on foobar:
|
|||
&prompt.user; <userinput>cd /host/foobar/usr</userinput></screen>
|
||||
</example>
|
||||
|
||||
<para>The output from <command>showmount</command>
|
||||
shows <filename class="directory">/usr</filename> as an
|
||||
export. When changing directories to
|
||||
<para>The output from <command>showmount</command> shows
|
||||
<filename class="directory">/usr</filename> as an export.
|
||||
When changing directories to
|
||||
<filename class="directory">/host/foobar/usr</filename>,
|
||||
<application>amd</application> intercepts the request and
|
||||
attempts to resolve the hostname <hostid>foobar</hostid>.
|
||||
If successful, <application>amd</application> automatically
|
||||
attempts to resolve the hostname <hostid>foobar</hostid>. If
|
||||
successful, <application>amd</application> automatically
|
||||
mounts the desired export.</para>
|
||||
|
||||
<para><application>amd</application> is enabled by placing
|
||||
|
|
@ -1005,11 +997,10 @@ Exports list on foobar:
|
|||
|
||||
<programlisting>amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"</programlisting>
|
||||
|
||||
<para><filename>/etc/amd.map</filename> defines the
|
||||
default options with which exports are mounted.
|
||||
<filename>/etc/amd.conf</filename> defines some of the
|
||||
more advanced features of
|
||||
<application>amd</application>.</para>
|
||||
<para><filename>/etc/amd.map</filename> defines the default
|
||||
options with which exports are mounted.
|
||||
<filename>/etc/amd.conf</filename> defines some of the more
|
||||
advanced features of <application>amd</application>.</para>
|
||||
|
||||
<para>Consult the &man.amd.8; and &man.amd.conf.5; manual pages
|
||||
for more information.</para>
|
||||
|
|
@ -1139,7 +1130,6 @@ Exports list on foobar:
|
|||
|
||||
<row>
|
||||
<entry><application>ypbind</application></entry>
|
||||
|
||||
<entry><quote>Binds</quote> an NIS client to its NIS
|
||||
server. It will take the NIS domainname from the
|
||||
system, and using <acronym>RPC</acronym>, connect to
|
||||
|
|
@ -1449,10 +1439,10 @@ Exports list on foobar:
|
|||
|
||||
<note>
|
||||
<para>Depending on the NIS setup, additional entries may
|
||||
be required. See the <link
|
||||
linkend="network-nis-server-is-client">section about
|
||||
NIS servers that are also NIS clients</link>, below, for
|
||||
details.</para>
|
||||
be required. See the
|
||||
<link linkend="network-nis-server-is-client">section
|
||||
about NIS servers that are also NIS clients</link>,
|
||||
below, for details.</para>
|
||||
</note>
|
||||
|
||||
<para>After setting up the above entries, run the command
|
||||
|
|
@ -1481,8 +1471,8 @@ Exports list on foobar:
|
|||
good reason, never propagate passwords for
|
||||
<username>root</username> and other administrative
|
||||
accounts to all the servers in the NIS domain. Therefore,
|
||||
before the NIS maps are initialized, configure the
|
||||
primary password files:</para>
|
||||
before the NIS maps are initialized, configure the primary
|
||||
password files:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cp /etc/master.passwd /var/yp/master.passwd</userinput>
|
||||
&prompt.root; <userinput>cd /var/yp</userinput>
|
||||
|
|
@ -1541,12 +1531,11 @@ ellington has been setup as an YP master server without any errors.</screen>
|
|||
|
||||
<para>At this point, <command>ypinit</command> should have
|
||||
created <filename>/var/yp/Makefile</filename> from
|
||||
<filename>/var/yp/Makefile.dist</filename>.
|
||||
When created, this file assumes that the operating
|
||||
environment is a single server NIS system with only &os;
|
||||
machines. Since <literal>test-domain</literal> has
|
||||
a slave server as well, edit
|
||||
<filename>/var/yp/Makefile</filename> as well:</para>
|
||||
<filename>/var/yp/Makefile.dist</filename>. When created,
|
||||
this file assumes that the operating environment is a
|
||||
single server NIS system with only &os; machines. Since
|
||||
<literal>test-domain</literal> has a slave server as well,
|
||||
edit <filename>/var/yp/Makefile</filename> as well:</para>
|
||||
|
||||
<screen>ellington&prompt.root; <userinput>vi /var/yp/Makefile</userinput></screen>
|
||||
|
||||
|
|
@ -2440,9 +2429,8 @@ nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</
|
|||
Blowfish and MD5 encrypted passwords, respectively).</para>
|
||||
|
||||
<para>If any changes were made to
|
||||
<filename>/etc/login.conf</filename>, the
|
||||
login capability database must be rebuilt by
|
||||
running the following command as
|
||||
<filename>/etc/login.conf</filename>, the login capability
|
||||
database must be rebuilt by running the following command as
|
||||
<username>root</username>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
|
||||
|
|
@ -2603,12 +2591,12 @@ result: 0 Success
|
|||
during the certificate creation process below.</para>
|
||||
|
||||
<para>The following commands must be executed in the
|
||||
<filename class="directory">
|
||||
/usr/local/etc/openldap/private</filename> directory. This
|
||||
is important as the file permissions will need to be
|
||||
restrictive and users should not have access to these files
|
||||
directly. To create the certificates, issues the following
|
||||
commands.</para>
|
||||
<filename
|
||||
class="directory">/usr/local/etc/openldap/private</filename>
|
||||
directory. This is important as the file permissions will
|
||||
need to be restrictive and users should not have access to
|
||||
these files directly. To create the certificates, issues the
|
||||
following commands.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>openssl req -days 365 -nodes -new -x509 -keyout ca.key -out ../ca.crt</userinput></screen>
|
||||
|
||||
|
|
@ -2917,11 +2905,10 @@ result: 0 Success
|
|||
<application>sysinstall</application>. When configuring a
|
||||
network interface within
|
||||
<application>sysinstall</application>, the second question
|
||||
asked is: <quote>Do you want to try DHCP configuration of
|
||||
the interface?</quote>. Answering affirmatively will
|
||||
execute <command>dhclient</command>, and if successful, will
|
||||
fill in the network configuration information
|
||||
automatically.</para>
|
||||
asked is: <quote>Do you want to try DHCP configuration of the
|
||||
interface?</quote>. Answering affirmatively will execute
|
||||
<command>dhclient</command>, and if successful, will fill in
|
||||
the network configuration information automatically.</para>
|
||||
|
||||
<para>There are two things required to have the system use
|
||||
DHCP upon startup:</para>
|
||||
|
|
@ -2931,33 +2918,33 @@ result: 0 Success
|
|||
</indexterm>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Make sure that the <devicename>bpf</devicename>
|
||||
device is compiled into the kernel. To do this, add
|
||||
<literal>device bpf</literal> to the kernel
|
||||
configuration file, and rebuild the kernel. For more
|
||||
information about building kernels, see
|
||||
<para>Make sure that the <devicename>bpf</devicename> device
|
||||
is compiled into the kernel. To do this, add
|
||||
<literal>device bpf</literal> to the kernel configuration
|
||||
file, and rebuild the kernel. For more information about
|
||||
building kernels, see
|
||||
<xref linkend="kernelconfig"/>.</para>
|
||||
|
||||
<para>The <devicename>bpf</devicename> device is already
|
||||
part of the <filename>GENERIC</filename> kernel that is
|
||||
supplied with &os;, thus there is no need to build a
|
||||
custom kernel for <acronym>DHCP</acronym>. In the case
|
||||
of a custom kernel configuration file, this device must
|
||||
be present for <acronym>DHCP</acronym> to function
|
||||
custom kernel for <acronym>DHCP</acronym>. In the case of
|
||||
a custom kernel configuration file, this device must be
|
||||
present for <acronym>DHCP</acronym> to function
|
||||
properly.</para>
|
||||
|
||||
<note>
|
||||
<para>For those who are particularly security conscious,
|
||||
take note that <devicename>bpf</devicename>
|
||||
is also the device that allows packet sniffers to work
|
||||
correctly (although they still have to be run as
|
||||
take note that <devicename>bpf</devicename> is also the
|
||||
device that allows packet sniffers to work correctly
|
||||
(although they still have to be run as
|
||||
<username>root</username>).
|
||||
<devicename>bpf</devicename> <emphasis>is</emphasis>
|
||||
required to use DHCP; however, the security sensitive
|
||||
types should probably not add
|
||||
<devicename>bpf</devicename> to the
|
||||
kernel in the expectation that at some point in the
|
||||
future the system will be using DHCP.</para>
|
||||
<devicename>bpf</devicename> to the kernel in the
|
||||
expectation that at some point in the future the system
|
||||
will be using DHCP.</para>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
|
|
@ -2969,12 +2956,12 @@ result: 0 Success
|
|||
|
||||
<para>Background DHCP works well when the DHCP server
|
||||
responds quickly to requests and the DHCP configuration
|
||||
process goes quickly. However, DHCP may take a long
|
||||
time to complete on some systems. If network services
|
||||
attempt to run before DHCP has completed, they will
|
||||
fail. Using DHCP in <firstterm>synchronous</firstterm>
|
||||
mode prevents the problem, pausing startup until DHCP
|
||||
configuration has completed.</para>
|
||||
process goes quickly. However, DHCP may take a long time
|
||||
to complete on some systems. If network services attempt
|
||||
to run before DHCP has completed, they will fail. Using
|
||||
DHCP in <firstterm>synchronous</firstterm> mode prevents
|
||||
the problem, pausing startup until DHCP configuration has
|
||||
completed.</para>
|
||||
|
||||
<para>To connect to a DHCP server in the background while
|
||||
other startup continues (asynchronous mode), use the
|
||||
|
|
@ -2997,10 +2984,9 @@ result: 0 Success
|
|||
</note>
|
||||
|
||||
<para>When using a different file system location for
|
||||
<command>dhclient</command>, or if
|
||||
additional flags must be passed to
|
||||
<command>dhclient</command>,
|
||||
include (editing as necessary):</para>
|
||||
<command>dhclient</command>, or if additional flags must
|
||||
be passed to <command>dhclient</command>, include (editing
|
||||
as necessary):</para>
|
||||
|
||||
<programlisting>dhclient_program="/sbin/dhclient"
|
||||
dhclient_flags=""</programlisting>
|
||||
|
|
@ -3013,9 +2999,9 @@ dhclient_flags=""</programlisting>
|
|||
</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>
|
||||
<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>
|
||||
|
|
@ -3028,24 +3014,26 @@ dhclient_flags=""</programlisting>
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><filename>/etc/dhclient.conf</filename></para>
|
||||
|
||||
<para><command>dhclient</command> requires a configuration
|
||||
file, <filename>/etc/dhclient.conf</filename>.
|
||||
Typically the file contains only comments, the defaults
|
||||
being reasonably sane. This configuration file is
|
||||
described by the &man.dhclient.conf.5; manual
|
||||
page.</para>
|
||||
file, <filename>/etc/dhclient.conf</filename>. Typically
|
||||
the file contains only comments, the defaults being
|
||||
reasonably sane. This configuration file is described by
|
||||
the &man.dhclient.conf.5; manual page.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/sbin/dhclient</filename></para>
|
||||
|
||||
<para><command>dhclient</command> is statically linked and
|
||||
resides in <filename>/sbin</filename>. The
|
||||
&man.dhclient.8; manual page gives more information
|
||||
about <command>dhclient</command>.</para>
|
||||
&man.dhclient.8; manual page gives more information about
|
||||
<command>dhclient</command>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/sbin/dhclient-script</filename></para>
|
||||
|
||||
<para><command>dhclient-script</command> is the
|
||||
FreeBSD-specific DHCP client configuration script. It
|
||||
is described in &man.dhclient-script.8;, but should not
|
||||
|
|
@ -3054,8 +3042,9 @@ dhclient_flags=""</programlisting>
|
|||
|
||||
<listitem>
|
||||
<para><filename>/var/db/dhclient.leases.<replaceable>interface</replaceable></filename></para>
|
||||
<para>The DHCP client keeps a database of valid leases
|
||||
in this file, which is written as a log.
|
||||
|
||||
<para>The DHCP client keeps a database of valid leases in
|
||||
this file, which is written as a log.
|
||||
&man.dhclient.leases.5; gives a slightly longer
|
||||
description.</para>
|
||||
</listitem>
|
||||
|
|
@ -3065,8 +3054,8 @@ dhclient_flags=""</programlisting>
|
|||
<sect2>
|
||||
<title>Further Reading</title>
|
||||
|
||||
<para>The DHCP protocol is fully described in <ulink
|
||||
url="http://www.freesoft.org/CIE/RFC/2131/">RFC
|
||||
<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
|
||||
up at <ulink url="http://www.dhcp.org/"></ulink>.</para>
|
||||
</sect2>
|
||||
|
|
@ -3077,8 +3066,8 @@ dhclient_flags=""</programlisting>
|
|||
<sect3>
|
||||
<title>What This Section Covers</title>
|
||||
|
||||
<para>This section provides information on how to configure
|
||||
a FreeBSD system to act as a DHCP server using the ISC
|
||||
<para>This section provides information on how to configure a
|
||||
FreeBSD system to act as a DHCP server using the ISC
|
||||
(Internet Systems Consortium) implementation of the DHCP
|
||||
server.</para>
|
||||
|
||||
|
|
@ -3096,38 +3085,36 @@ dhclient_flags=""</programlisting>
|
|||
<primary>DHCP</primary>
|
||||
<secondary>installation</secondary>
|
||||
</indexterm>
|
||||
<para>In order to configure the &os; system as a DHCP
|
||||
server, first ensure that the &man.bpf.4; device is
|
||||
compiled into the kernel. To do this, add
|
||||
<literal>device bpf</literal> to the kernel configuration
|
||||
file, and rebuild the kernel. For more information about
|
||||
building kernels, see
|
||||
|
||||
<para>In order to configure the &os; system as a DHCP server,
|
||||
first ensure that the &man.bpf.4; device is compiled into
|
||||
the kernel. To do this, add <literal>device bpf</literal>
|
||||
to the kernel configuration file, and rebuild the kernel.
|
||||
For more information about building kernels, see
|
||||
<xref linkend="kernelconfig"/>.</para>
|
||||
|
||||
<para>The <devicename>bpf</devicename> device is already
|
||||
part of the <filename>GENERIC</filename> kernel that is
|
||||
supplied with &os;, so there is no need to create a
|
||||
custom kernel in order to get <acronym>DHCP</acronym>
|
||||
working.</para>
|
||||
<para>The <devicename>bpf</devicename> device is already part
|
||||
of the <filename>GENERIC</filename> kernel that is supplied
|
||||
with &os;, so there is no need to create a custom kernel in
|
||||
order to get <acronym>DHCP</acronym> working.</para>
|
||||
|
||||
<note>
|
||||
<para>Those who are particularly security conscious
|
||||
should note that <devicename>bpf</devicename> is also
|
||||
the device that allows packet sniffers to function
|
||||
correctly (although such programs still need
|
||||
privileged access). The <devicename>bpf</devicename>
|
||||
device <emphasis>is</emphasis> required to use DHCP, but
|
||||
if the sensitivity of the system's security is high,
|
||||
this device should not be included in the kernel purely
|
||||
because the use of <acronym>DHCP</acronym> may, at some
|
||||
point in the future, be desired.</para>
|
||||
<para>Those who are particularly security conscious should
|
||||
note that <devicename>bpf</devicename> is also the device
|
||||
that allows packet sniffers to function correctly
|
||||
(although such programs still need privileged access).
|
||||
The <devicename>bpf</devicename> device
|
||||
<emphasis>is</emphasis> required to use DHCP, but if the
|
||||
sensitivity of the system's security is high, this device
|
||||
should not be included in the kernel purely because the
|
||||
use of <acronym>DHCP</acronym> may, at some point in the
|
||||
future, be desired.</para>
|
||||
</note>
|
||||
|
||||
<para>The next thing that is needed is to edit the
|
||||
sample <filename>dhcpd.conf</filename> which was installed
|
||||
by the <filename
|
||||
role="package">net/isc-dhcp42-server</filename> port.
|
||||
By default, this will be
|
||||
<para>The next thing that is needed is to edit the sample
|
||||
<filename>dhcpd.conf</filename> which was installed by the
|
||||
<filename role="package">net/isc-dhcp42-server</filename>
|
||||
port. By default, this will be
|
||||
<filename>/usr/local/etc/dhcpd.conf.sample</filename>, and
|
||||
you should copy this to
|
||||
<filename>/usr/local/etc/dhcpd.conf</filename> before
|
||||
|
|
@ -3248,13 +3235,12 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
|
||||
<screen>&prompt.root; <userinput>service isc-dhcpd start</userinput></screen>
|
||||
|
||||
<para>Any future changes to the configuration
|
||||
of the server will require the sending of a
|
||||
<literal>SIGTERM</literal> signal to
|
||||
<application>dhcpd</application> rather than a
|
||||
<literal>SIGHUP</literal>. It is definitely more
|
||||
simple to use &man.service.8; to completely restart
|
||||
the service.</para>
|
||||
<para>Any future changes to the configuration of the server
|
||||
will require the sending of a <literal>SIGTERM</literal>
|
||||
signal to <application>dhcpd</application> rather than a
|
||||
<literal>SIGHUP</literal>. It is definitely more simple to
|
||||
use &man.service.8; to completely restart the
|
||||
service.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
|
|
@ -3267,30 +3253,33 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><filename>/usr/local/sbin/dhcpd</filename></para>
|
||||
|
||||
<para><application>dhcpd</application> is statically
|
||||
linked and resides in
|
||||
<filename>/usr/local/sbin</filename>. The
|
||||
&man.dhcpd.8; manual page installed with the port
|
||||
gives more information about
|
||||
<filename>/usr/local/sbin</filename>. The &man.dhcpd.8;
|
||||
manual page installed with the port gives more
|
||||
information about
|
||||
<application>dhcpd</application>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/usr/local/etc/dhcpd.conf</filename></para>
|
||||
|
||||
<para><application>dhcpd</application> requires a
|
||||
configuration file,
|
||||
<filename>/usr/local/etc/dhcpd.conf</filename> before
|
||||
it will start providing service to clients. This file
|
||||
<filename>/usr/local/etc/dhcpd.conf</filename> before it
|
||||
will start providing service to clients. This file
|
||||
needs to contain all the information that should be
|
||||
provided to clients that are being serviced, along
|
||||
with information regarding the operation of the
|
||||
server. This configuration file is described
|
||||
by the &man.dhcpd.conf.5; manual page installed
|
||||
by the port.</para>
|
||||
provided to clients that are being serviced, along with
|
||||
information regarding the operation of the server. This
|
||||
configuration file is described by the
|
||||
&man.dhcpd.conf.5; manual page installed by the
|
||||
port.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/var/db/dhcpd.leases</filename></para>
|
||||
|
||||
<para>The DHCP server keeps a database of leases it has
|
||||
issued in this file, which is written as a log. The
|
||||
manual page &man.dhcpd.leases.5;, installed by the
|
||||
|
|
@ -3299,14 +3288,15 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
|
||||
<listitem>
|
||||
<para><filename>/usr/local/sbin/dhcrelay</filename></para>
|
||||
|
||||
<para><application>dhcrelay</application> is used in
|
||||
advanced environments where one DHCP server forwards a
|
||||
request from a client to another DHCP server on a
|
||||
separate network. If this functionality is required,
|
||||
then install the <filename
|
||||
role="package">net/isc-dhcp42-relay</filename> port.
|
||||
The &man.dhcrelay.8; manual page provided with the
|
||||
port contains more detail.</para>
|
||||
then install the
|
||||
<filename role="package">net/isc-dhcp42-relay</filename>
|
||||
port. The &man.dhcrelay.8; manual page provided with
|
||||
the port contains more detail.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect3>
|
||||
|
|
@ -3345,11 +3335,11 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
of the <acronym>DNS</acronym> protocol.
|
||||
<acronym>DNS</acronym> is the protocol through which names are
|
||||
mapped to <acronym>IP</acronym> addresses, and vice versa.
|
||||
For example, a query for <hostid
|
||||
role="fqdn">www.FreeBSD.org</hostid> will receive a reply
|
||||
with the <acronym>IP</acronym> address of The &os; Project's
|
||||
web server, whereas, a query for <hostid
|
||||
role="fqdn">ftp.FreeBSD.org</hostid> will return the
|
||||
For example, a query for
|
||||
<hostid role="fqdn">www.FreeBSD.org</hostid> will receive a
|
||||
reply with the <acronym>IP</acronym> address of The &os;
|
||||
Project's web server, whereas, a query for
|
||||
<hostid role="fqdn">ftp.FreeBSD.org</hostid> will return the
|
||||
<acronym>IP</acronym> address of the corresponding
|
||||
<acronym>FTP</acronym> machine. Likewise, the opposite can
|
||||
happen. A query for an <acronym>IP</acronym> address can
|
||||
|
|
@ -3479,12 +3469,11 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
</itemizedlist>
|
||||
|
||||
<para>As one can see, the more specific part of a hostname
|
||||
appears to its left. For example, <hostid
|
||||
role="domainname">example.org.</hostid> is more specific
|
||||
than <hostid>org.</hostid>, as <hostid>org.</hostid> is more
|
||||
specific than the root zone. The layout of each part of a
|
||||
hostname is
|
||||
much like a file system: the
|
||||
appears to its left. For example,
|
||||
<hostid role="domainname">example.org.</hostid> is more
|
||||
specific than <hostid>org.</hostid>, as <hostid>org.</hostid>
|
||||
is more specific than the root zone. The layout of each part
|
||||
of a hostname is much like a file system: the
|
||||
<filename class="directory">/dev</filename> directory falls
|
||||
within the root, and so on.</para>
|
||||
</sect2>
|
||||
|
|
@ -3493,8 +3482,8 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
<title>Reasons to Run a Name Server</title>
|
||||
|
||||
<para>Name servers generally come in two forms: authoritative
|
||||
name servers, and caching (also known as resolving)
|
||||
name servers.</para>
|
||||
name servers, and caching (also known as resolving) name
|
||||
servers.</para>
|
||||
|
||||
<para>An authoritative name server is needed when:</para>
|
||||
|
||||
|
|
@ -3505,10 +3494,10 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A domain, such as <hostid
|
||||
role="domainname">example.org</hostid>, is registered
|
||||
and <acronym>IP</acronym> addresses need to be assigned
|
||||
to hostnames under it.</para>
|
||||
<para>A domain, such as
|
||||
<hostid role="domainname">example.org</hostid>, is
|
||||
registered and <acronym>IP</acronym> addresses need to be
|
||||
assigned to hostnames under it.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -4141,16 +4130,16 @@ www IN CNAME example.org.</programlisting>
|
|||
<term><literal>2006051501</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>the serial number of the file. This
|
||||
must be incremented each time the zone file is
|
||||
modified. Nowadays, many admins prefer a
|
||||
<para>the serial number of the file. This must be
|
||||
incremented each time the zone file is modified.
|
||||
Nowadays, many admins prefer a
|
||||
<literal>yyyymmddrr</literal> format for the serial
|
||||
number. <literal>2006051501</literal> would mean
|
||||
last modified 05/15/2006, the latter
|
||||
<literal>01</literal> being the first time the zone
|
||||
file has been modified this day. The serial number
|
||||
is important as it alerts slave name servers for a
|
||||
zone when it is updated.</para>
|
||||
number. <literal>2006051501</literal> would mean last
|
||||
modified 05/15/2006, the latter <literal>01</literal>
|
||||
being the first time the zone file has been modified
|
||||
this day. The serial number is important as it alerts
|
||||
slave name servers for a zone when it is
|
||||
updated.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
|
@ -4263,12 +4252,12 @@ mail IN A 192.168.1.5</programlisting>
|
|||
</indexterm>
|
||||
|
||||
<para>Domain Name System Security Extensions, or <acronym
|
||||
role="Domain Name Security Extensions">DNSSEC</acronym>
|
||||
for short, is a suite of specifications to protect resolving
|
||||
name servers from forged <acronym>DNS</acronym> data, such
|
||||
as spoofed <acronym>DNS</acronym> records. By using digital
|
||||
signatures, a resolver can verify the integrity of the
|
||||
record. Note that <acronym role="Domain Name Security
|
||||
role="Domain Name Security Extensions">DNSSEC</acronym> for
|
||||
short, is a suite of specifications to protect resolving name
|
||||
servers from forged <acronym>DNS</acronym> data, such as
|
||||
spoofed <acronym>DNS</acronym> records. By using digital
|
||||
signatures, a resolver can verify the integrity of the record.
|
||||
Note that <acronym role="Domain Name Security
|
||||
Extensions">DNSSEC</acronym> only provides integrity via
|
||||
digitally signing the Resource Records (<acronym
|
||||
role="Resource Record">RR</acronym>s). It provides neither
|
||||
|
|
@ -4929,10 +4918,10 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
|
|||
|
||||
<programlisting>NameVirtualHost *</programlisting>
|
||||
|
||||
<para>If the webserver was named <hostid
|
||||
role="fqdn">www.domain.tld</hostid> and
|
||||
a virtual domain for <hostid
|
||||
role="fqdn">www.someotherdomain.tld</hostid> then
|
||||
<para>If the webserver was named
|
||||
<hostid role="fqdn">www.domain.tld</hostid> and
|
||||
a virtual domain for
|
||||
<hostid role="fqdn">www.someotherdomain.tld</hostid> then
|
||||
add the following entries to
|
||||
<filename>httpd.conf</filename>:</para>
|
||||
|
||||
|
|
@ -4946,8 +4935,8 @@ ServerName www.someotherdomain.tld
|
|||
DocumentRoot /www/someotherdomain.tld
|
||||
</VirtualHost></screen>
|
||||
|
||||
<para>Replace the addresses with the addresses needed
|
||||
and the path to the documents with what are being used.</para>
|
||||
<para>Replace the addresses with the addresses needed and the
|
||||
path to the documents with what are being used.</para>
|
||||
|
||||
<para>For more information about setting up virtual hosts,
|
||||
please consult the official <application>Apache</application>
|
||||
|
|
@ -4981,9 +4970,9 @@ DocumentRoot /www/someotherdomain.tld
|
|||
OpenSSL library to provide strong cryptography via the
|
||||
Secure Sockets Layer (SSL v2/v3) and Transport Layer
|
||||
Security (TLS v1) protocols. This module provides
|
||||
everything necessary to request a signed certificate from
|
||||
a trusted certificate signing authority to run
|
||||
a secure web server on &os;.</para>
|
||||
everything necessary to request a signed certificate from a
|
||||
trusted certificate signing authority to run a secure web
|
||||
server on &os;.</para>
|
||||
|
||||
<para>The <application>mod_ssl</application> module is built
|
||||
by default, but can be enabled by specifying
|
||||
|
|
@ -5132,18 +5121,17 @@ DocumentRoot /www/someotherdomain.tld
|
|||
<secondary>PHP</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para><acronym>PHP</acronym>, also known as <quote>PHP:
|
||||
Hypertext Preprocessor</quote> is a general-purpose
|
||||
scripting language that is especially suited for Web
|
||||
development. Capable of being embedded into
|
||||
<acronym>HTML</acronym> its syntax draws upon C, &java;,
|
||||
and Perl with the intention of allowing web developers to
|
||||
write dynamically generated webpages quickly.</para>
|
||||
<para><acronym>PHP</acronym>, also known as
|
||||
<quote>PHP: Hypertext Preprocessor</quote> is a
|
||||
general-purpose scripting language that is especially suited
|
||||
for Web development. Capable of being embedded into
|
||||
<acronym>HTML</acronym> its syntax draws upon C, &java;, and
|
||||
Perl with the intention of allowing web developers to write
|
||||
dynamically generated webpages quickly.</para>
|
||||
|
||||
<para>To gain support for <acronym>PHP</acronym>5 for the
|
||||
<application>Apache</application> web server, begin by
|
||||
installing the
|
||||
<filename role="package">lang/php5</filename>
|
||||
installing the <filename role="package">lang/php5</filename>
|
||||
port.</para>
|
||||
|
||||
<para>If the <filename role="package">lang/php5</filename>
|
||||
|
|
@ -5260,14 +5248,13 @@ DocumentRoot /www/someotherdomain.tld
|
|||
|
||||
<para>The most important configuration step is deciding which
|
||||
accounts will be allowed access to the FTP server. A normal
|
||||
&os; system has a number of system accounts used for
|
||||
various daemons, but unknown users should not be allowed to
|
||||
log in with these accounts. The
|
||||
<filename>/etc/ftpusers</filename> file is a list of users
|
||||
disallowed any FTP access. By default, it includes the
|
||||
aforementioned system accounts, but it is possible to add
|
||||
specific users here that should not be allowed access to
|
||||
FTP.</para>
|
||||
&os; system has a number of system accounts used for various
|
||||
daemons, but unknown users should not be allowed to log in
|
||||
with these accounts. The <filename>/etc/ftpusers</filename>
|
||||
file is a list of users disallowed any FTP access. By
|
||||
default, it includes the aforementioned system accounts, but
|
||||
it is possible to add specific users here that should not be
|
||||
allowed access to FTP.</para>
|
||||
|
||||
<para>In some cases it may be desirable to restrict the access
|
||||
of some users without preventing them completely from using
|
||||
|
|
@ -5334,7 +5321,6 @@ DocumentRoot /www/someotherdomain.tld
|
|||
<para>You can now log on to the FTP server by typing:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>ftp localhost</userinput></screen>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
|
|
@ -5644,7 +5630,6 @@ Starting smbd.</screen>
|
|||
functionality beyond the basic installation described here,
|
||||
please see <ulink url="http://www.samba.org"></ulink>.</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="network-ntp">
|
||||
|
|
@ -5674,8 +5659,8 @@ Starting smbd.</screen>
|
|||
since a certain time. In a local area network environment, it
|
||||
is essential that computers sharing files from the same file
|
||||
server have synchronized clocks so that file timestamps stay
|
||||
consistent. Services such as &man.cron.8; also rely on
|
||||
an accurate system clock to run commands at the specified
|
||||
consistent. Services such as &man.cron.8; also rely on an
|
||||
accurate system clock to run commands at the specified
|
||||
times.</para>
|
||||
|
||||
<indexterm>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue