aboutsummaryrefslogtreecommitdiff
path: root/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
diff options
context:
space:
mode:
Diffstat (limited to 'en_US.ISO8859-1/books/handbook/network-servers/chapter.xml')
-rw-r--r--en_US.ISO8859-1/books/handbook/network-servers/chapter.xml1265
1 files changed, 820 insertions, 445 deletions
diff --git a/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml b/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
index e8c035e014..98d96ed097 100644
--- a/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
+++ b/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
@@ -47,6 +47,16 @@
</listitem>
<listitem>
+ <para>How to set &os; up to act as an <acronym>LDAP</acronym>
+ server or client</para>
+ </listitem>
+
+ <listitem>
+ <para>How to set &os; up to act as an <acronym>LDAP</acronym>
+ server or client</para>
+ </listitem>
+
+ <listitem>
<para>How to set up automatic network settings using
DHCP.</para>
</listitem>
@@ -126,9 +136,9 @@
<sect2 id="network-inetd-overview">
<title>Overview</title>
- <para>&man.inetd.8; is sometimes referred to as the
+ <para>The &man.inetd.8; daemon is sometimes referred to as the
<quote>Internet Super-Server</quote> because it manages
- connections for several services. When a connection is
+ 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
@@ -175,8 +185,7 @@
<screen>&prompt.root; <userinput>service inetd rcvar</userinput></screen>
- <para>
- can be run to display the current effective setting.</para>
+ <para>can be run to display the current effective setting.</para>
<para>Additionally, different command-line options can be passed
to <application>inetd</application> via the
@@ -202,9 +211,9 @@
<para>Although we mention rate-limiting options below, novice
users may be pleased to note that these parameters usually do
- not need to be modified. These options may be useful should
- you find that you are receiving an excessive amount of
- connections. A full list of options can be found in the
+ not need to be modified. These options may be useful if
+ an excessive amount of connections are being established.
+ A full list of options can be found in the
&man.inetd.8; manual.</para>
<variablelist>
@@ -509,7 +518,7 @@ server-program-arguments</programlisting>
place <option>max-connections-per-ip-per-minute</option>,
<option>max-child</option> or
<option>max-child-per-ip</option> limitations on certain
- daemons if you find that you have too many connections.</para>
+ daemons if there are too many connections.</para>
<para>By default, TCP wrapping is turned on. Consult the
&man.hosts.access.5; manual page for more information on
@@ -529,8 +538,7 @@ server-program-arguments</programlisting>
services of <application>inetd</application>.</para>
<para>The <application>auth</application> service provides
- identity
- network services, and is
+ identity network services, and is
configurable to a certain degree, whilst the others are simply
on or off.</para>
@@ -677,8 +685,8 @@ server-program-arguments</programlisting>
<para><acronym>NFS</acronym> configuration is a relatively
straightforward process. The processes that need to be
- running can all start at boot time with a few modifications to
- your <filename>/etc/rc.conf</filename> file.</para>
+ running can all start at boot time with a few modifications
+ to <filename>/etc/rc.conf</filename>.</para>
<para>On the <acronym>NFS</acronym> server, make sure that the
following options are configured in the
@@ -704,8 +712,8 @@ mountd_flags="-r"</programlisting>
system. Along with what machines have access to that file
system, access options may also be specified. There are many
such options that can be used in this file but only a few will
- be mentioned here. You can easily discover other options by
- reading over the &man.exports.5; manual page.</para>
+ be mentioned here. Other options are discussed in
+ the &man.exports.5; manual page.</para>
<para>Here are a few example <filename>/etc/exports</filename>
entries:</para>
@@ -717,11 +725,11 @@ mountd_flags="-r"</programlisting>
<para>The following examples give an idea of how to export
file systems, although the settings may be different depending
- on your environment and network configuration. For instance,
+ 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
- your <filename>/etc/hosts</filename> file. The
+ the <filename>/etc/hosts</filename> file. The
<option>-ro</option> flag makes the exported file system
read-only. With this flag, the remote system will not be able
to write any changes to the exported file system.</para>
@@ -729,7 +737,7 @@ mountd_flags="-r"</programlisting>
<programlisting>/cdrom -ro host1 host2 host3</programlisting>
<para>The following line exports <filename>/home</filename> to
- three hosts by IP address. This is a useful setup if you have
+ three hosts by IP address. This is a useful setup on
a private network without a <acronym>DNS</acronym> server
configured. Optionally the <filename>/etc/hosts</filename>
file could be configured for internal hostnames; please review
@@ -755,8 +763,7 @@ mountd_flags="-r"</programlisting>
<para>In order for a client to access an exported file system,
the client must have permission to do so. Make sure the
- client is listed in your <filename>/etc/exports</filename>
- file.</para>
+ client is listed in <filename>/etc/exports</filename>.</para>
<para>In <filename>/etc/exports</filename>, each line represents
the export information for one file system to one host. A
@@ -778,8 +785,9 @@ mountd_flags="-r"</programlisting>
<para>The properties of one file system exported to a given host
must all occur on one line. Lines without a client specified
- are treated as a single host. This limits how you can export
- file systems, but for most people this is not an issue.</para>
+ are treated as a single host. This limits how file systems
+ may be exported; however, for most environments, this is not
+ an issue.</para>
<para>The following is an example of a valid export list, where
<filename>/usr</filename> and <filename>/exports</filename>
@@ -828,9 +836,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>. If you only want to temporarily
- mount a remote file system or would rather test the
- configuration, just 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>
@@ -841,11 +848,11 @@ mountd_flags="-r"</programlisting>
<para>This will mount the <filename>/home</filename> directory
on the server at <filename>/mnt</filename> on the client. If
- everything is set up correctly you should be able to enter
- <filename>/mnt</filename> on the client and see all the files
- that are on the server.</para>
+ everything is set up correctly, the server's files should be
+ visible and available in the <filename>/mnt</filename>
+ directory.</para>
- <para>If you want to automatically mount a remote file system
+ <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>
@@ -911,10 +918,9 @@ rpc_statd_enable="YES"</programlisting>
<listitem>
<para>Several machines could have a common
- <filename>/usr/ports/distfiles</filename> directory. That
- way, when you need to install a port on several machines,
- you can quickly access the source without downloading it
- on each machine.</para>
+ <filename>/usr/ports/distfiles</filename> directory. This
+ allows for quick access to the source files without
+ downloading them on each machine.</para>
</listitem>
</itemizedlist>
</sect2>
@@ -974,10 +980,10 @@ rpc_statd_enable="YES"</programlisting>
<title>Mounting an Export with
<application>amd</application></title>
- <para>You can view the available mounts of a remote host with
- the <command>showmount</command> command. For example, to
- view the mounts of a host named <hostid>foobar</hostid>, you
- can use:</para>
+ <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>
<screen>&prompt.user; <userinput>showmount -e foobar</userinput>
Exports list on foobar:
@@ -1062,9 +1068,8 @@ Exports list on foobar:
<para>It should be noted that there is a different problem,
sometimes mistaken for this one, when the NFS servers and
clients are on different networks. If that is the case, make
- <emphasis>certain</emphasis> that your routers are routing the
- necessary <acronym>UDP</acronym> information, or you will not
- get anywhere, no matter what else you are doing.</para>
+ <emphasis>certain</emphasis> that the routers are routing the
+ necessary <acronym>UDP</acronym> information.</para>
<para>In the following examples, <hostid>fastws</hostid> is the
host (interface) name of a high-performance workstation, and
@@ -1076,7 +1081,7 @@ Exports list on foobar:
client for the exported file system. In all cases, note that
additional options, such as <option>hard</option> or
<option>soft</option> and <option>bg</option> may be desirable
- in your application.</para>
+ in the application.</para>
<para>Examples for the FreeBSD system (<hostid>freebox</hostid>)
as the client in <filename>/etc/fstab</filename> on
@@ -1211,12 +1216,12 @@ Exports list on foobar:
</sect2>
<sect2>
- <title>Terms/Processes You Should Know</title>
+ <title><acronym>NIS</acronym>Terms and Processes</title>
- <para>There are several terms and several important user
- processes that you will come across when attempting to
- implement NIS on FreeBSD, whether you are trying to create an
- NIS server or act as an 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>
@@ -1386,18 +1391,17 @@ Exports list on foobar:
<sect3>
<title>Planning</title>
- <para>Let us assume that you are the administrator of a small
- university lab. This lab, which consists of 15 FreeBSD
+ <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
+ 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, when you add a user to the lab, you
- must run <command>adduser</command> on all 15 machines.
- Clearly, this has to change, so you have decided to convert
- the lab to use NIS, using two of the machines as
- servers.</para>
+ 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
+ <acronym>NIS</acronym> servers.</para>
<para>Therefore, the configuration of the lab now looks
something like:</para>
@@ -1446,10 +1450,10 @@ Exports list on foobar:
</tgroup>
</informaltable>
- <para>If you are setting up a NIS scheme for the first time,
- it is a good idea to think through how you want to go about
- it. No matter what the size of your network, there are a
- few decisions that need to be made.</para>
+ <para>If this is the first time a <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.</para>
<sect4>
<title>Choosing a NIS Domain Name</title>
@@ -1458,8 +1462,8 @@ Exports list on foobar:
<primary>NIS</primary>
<secondary>domainname</secondary>
</indexterm>
- <para>This might not be the <quote>domainname</quote> that
- you are used to. It is more accurately called the
+ <para>This might not be the normal <quote>domainname</quote>
+ for the network. It is more accurately called the
<quote>NIS domainname</quote>. When a client broadcasts
its requests for info, it includes the name of the NIS
domain that it is part of. This is how multiple servers
@@ -1471,19 +1475,19 @@ Exports list on foobar:
domainname for their NIS domainname. This is not
recommended as it can cause confusion when trying to debug
network problems. The NIS domainname should be unique
- within your network and it is helpful if it describes the
+ 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> NIS domain. For this example,
- assume you have chosen the name
+ assume the chosen name will be
<literal>test-domain</literal>.</para>
<indexterm><primary>SunOS</primary></indexterm>
<para>However, some operating systems (notably &sunos;) use
their NIS domain name as their Internet domain name. If
- one or more machines on your network have this
- restriction, you <emphasis>must</emphasis> use the
- Internet domain name as your NIS domain name.</para>
+ one or more machines on the network have this
+ restriction, it <emphasis>must</emphasis> be used as the
+ Internet domain name for the NIS domain name.</para>
</sect4>
<sect4>
@@ -1496,16 +1500,15 @@ Exports list on foobar:
for its NIS domain, very often the machine becomes
unusable. The lack of user and group information causes
most systems to temporarily freeze up. With this in mind
- you should make sure to choose a machine that will not be
- prone to being rebooted regularly, or one that might be
+ be sure to choose a machine that will not be
+ prone to being rebooted frequently, or one that might be
used for development. The NIS server should ideally be a
stand alone machine whose sole purpose in life is to be an
- NIS server. If you have a network that is not very
+ NIS server. If the network is not very
heavily used, it is acceptable to put the NIS server on a
- machine running other services, just keep in mind that if
- the NIS server becomes unavailable, it will affect
- <emphasis>all</emphasis> of your NIS clients
- adversely.</para>
+ machine running other services, however; if
+ the NIS server becomes unavailable, it will adversely affect
+ <emphasis>all</emphasis> NIS clients.</para>
</sect4>
</sect3>
@@ -1540,11 +1543,10 @@ Exports list on foobar:
<secondary>server configuration</secondary>
</indexterm>
<para>Setting up a master NIS server can be relatively
- straight forward, depending on your needs. FreeBSD comes
- with support for NIS out-of-the-box. All you need is to
- add the following lines to
- <filename>/etc/rc.conf</filename>, and FreeBSD will do the
- rest for you.</para>
+ straight forward, depending on environmental needs. &os;
+ comes with support for NIS out-of-the-box. It only needs to
+ be enabled by adding the following lines to
+ <filename>/etc/rc.conf</filename>:</para>
<procedure>
<step>
@@ -1574,8 +1576,8 @@ Exports list on foobar:
</procedure>
<note>
- <para>Depending on your NIS setup, you may need to add
- further entries. See the <link
+ <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>
@@ -1583,7 +1585,7 @@ Exports list on foobar:
<para>After setting up the above entries, run the command
<command>/etc/netstart</command> as superuser. It will
- set up everything for you, using the values you defined in
+ set up everything, using the values defined in
<filename>/etc/rc.conf</filename>. As a last step, before
initializing the NIS maps, start the
<application>ypserv</application> daemon manually:</para>
@@ -1602,44 +1604,44 @@ Exports list on foobar:
that are kept in the <filename>/var/yp</filename>
directory. They are generated from configuration files in
the <filename>/etc</filename> directory of the NIS master,
- with one exception: the
- <filename>/etc/master.passwd</filename> file. This is for
- a good reason, you do not want to propagate passwords to
- your <username>root</username> and other administrative
+ with one exception: <filename>/etc/master.passwd</filename>.
+ This is for
+ a good reason, never propagate passwords for
+ <username>root</username> and other administrative
accounts to all the servers in the NIS domain. Therefore,
- before we initialize the NIS maps, you should:</para>
+ before the 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>
&prompt.root; <userinput>vi master.passwd</userinput></screen>
- <para>You should remove all entries regarding system
+ <para>It is advisable to remove all entries regarding system
accounts (<username>bin</username>,
<username>tty</username>, <username>kmem</username>,
<username>games</username>, etc), as well as any accounts
- that you do not want to be propagated to the NIS clients
+ that do not need to be propagated to the NIS clients
(for example <username>root</username> and any other UID 0
(superuser) accounts).</para>
- <note><para>Make sure the
+ <note><para>Ensure the
<filename>/var/yp/master.passwd</filename> is neither
- group nor world readable (mode 600)! Use the
- <command>chmod</command> command, if
+ group or world readable (mode 600)! Use the
+ <command>chmod</command> command, as
appropriate.</para></note>
<indexterm><primary>Tru64 UNIX</primary></indexterm>
- <para>When you have finished, it is time to initialize the
- NIS maps! FreeBSD includes a script named
- <command>ypinit</command> to do this for you (see its
+ <para>When this task has been completed, it is time to
+ initialize the NIS maps. FreeBSD includes a script named
+ <command>ypinit</command> to do this (see its
manual page for more information). Note that this script
is available on most &unix; Operating Systems, but not on
all. On Digital UNIX/Compaq Tru64 UNIX it is called
<command>ypsetup</command>. Because we are generating
maps for an NIS master, we are going to pass the
<option>-m</option> option to <command>ypinit</command>.
- To generate the NIS maps, assuming you already performed
- the steps above, run:</para>
+ To generate the NIS maps run:</para>
<screen>ellington&prompt.root; <userinput>ypinit -m test-domain</userinput>
Server Type: MASTER Domain: test-domain
@@ -1665,14 +1667,14 @@ Is this correct? [y/n: y] <userinput>y</userinput>
NIS Map update completed.
ellington has been setup as an YP master server without any errors.</screen>
- <para><command>ypinit</command> should have created
- <filename>/var/yp/Makefile</filename> from
+ <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 you are operating
- in a single server NIS environment with only FreeBSD
+ 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, you must edit
- <filename>/var/yp/Makefile</filename>:</para>
+ 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>
@@ -1756,12 +1758,12 @@ ypxfr: Exiting: Map successfully transferred
coltrane has been setup as an YP slave server without any errors.
Don't forget to update map ypservers on ellington.</screen>
- <para>You should now have a directory called
+ <para>There should be a directory called
<filename>/var/yp/test-domain</filename>. Copies of the
- NIS master server's maps should be in this directory. You
- will need to make sure that these stay updated. The
+ NIS master server's maps should be in this directory. These
+ files must always be up to date. The
following <filename>/etc/crontab</filename> entries on
- your slave servers should do the job:</para>
+ the slave servers should do the job:</para>
<programlisting>20 * * * * root /usr/libexec/ypxfr passwd.byname
21 * * * * root /usr/libexec/ypxfr passwd.byuid</programlisting>
@@ -1769,7 +1771,7 @@ Don't forget to update map ypservers on ellington.</screen>
<para>These two lines force the slave to sync its maps with
the maps on the master server. These entries are not
mandatory because the master server automatically attempts
- to push any map changes to its slaves. However, due to
+ to push any map changes to its slaves; however, due to
the importance of correct password information on other
clients depending on the slave server, it is recommended
to specifically force the password map updates frequently.
@@ -1785,10 +1787,10 @@ Don't forget to update map ypservers on ellington.</screen>
<sect3>
<title>NIS Clients</title>
- <para> An NIS client establishes what is called a binding to a
+ <para>An NIS client establishes what is called a binding to a
particular NIS server using the
- <command>ypbind</command> daemon.
- <command>ypbind</command> checks the system's default
+ <command>ypbind</command> daemon. The
+ <command>ypbind</command> command checks the system's default
domain (as set by the <command>domainname</command>
command), and begins broadcasting RPC requests on the local
network. These requests specify the name of the domain for
@@ -1820,9 +1822,9 @@ Don't forget to update map ypservers on ellington.</screen>
<procedure>
<step>
- <para>Edit the file <filename>/etc/rc.conf</filename>
+ <para>Edit <filename>/etc/rc.conf</filename>
and add the following lines in order to set the NIS
- domainname and start <command>ypbind</command> upon
+ domainname and start <command>ypbind</command> during
network startup:</para>
<programlisting>nisdomainname="test-domain"
@@ -1831,7 +1833,7 @@ nis_client_enable="YES"</programlisting>
<step>
<para>To import all possible password entries from the
- NIS server, remove all user accounts from your
+ NIS server, remove all user accounts from the
<filename>/etc/master.passwd</filename> file and use
<command>vipw</command> to add the following line to
the end of the file:</para>
@@ -1841,7 +1843,7 @@ nis_client_enable="YES"</programlisting>
<note>
<para>This line will afford anyone with a valid
account in the NIS server's password maps an
- account. There are many ways to configure your NIS
+ account. There are many ways to configure the NIS
client by changing this line. See the
<link
linkend="network-netgroups">netgroups
@@ -1851,8 +1853,8 @@ nis_client_enable="YES"</programlisting>
</note>
<note>
- <para>You should keep at least one local account (i.e.
- not imported via NIS) in your
+ <para>Keep in mind that at least one local account (i.e.
+ not imported via NIS) must exist in
<filename>/etc/master.passwd</filename> and this
account should also be a member of the group
<groupname>wheel</groupname>. If there is something
@@ -1864,8 +1866,8 @@ nis_client_enable="YES"</programlisting>
<step>
<para>To import all possible group entries from the NIS
- server, add this line to your
- <filename>/etc/group</filename> file:</para>
+ server, add this line to
+ <filename>/etc/group</filename>:</para>
<programlisting>+:*::</programlisting>
</step>
@@ -1877,18 +1879,19 @@ nis_client_enable="YES"</programlisting>
<screen>&prompt.root; <userinput>/etc/netstart</userinput>
&prompt.root; <userinput>service ypbind start</userinput></screen>
- <para>After completing these steps, you should be able to
- run <command>ypcat passwd</command> and see the NIS
+ <para>After completing these steps, the command,
+ <command>ypcat passwd</command>, should show the
server's passwd map.</para>
- </sect4> </sect3>
+ </sect4>
+ </sect3>
</sect2>
<sect2>
<title>NIS Security</title>
- <para>In general, any remote user can issue an RPC to
- &man.ypserv.8; and retrieve the contents of your NIS maps,
- provided the remote user knows your domainname. To prevent
+ <para>In general, any remote user may issue an RPC to
+ &man.ypserv.8; and retrieve the contents of the NIS maps,
+ provided the remote user knows the domainname. To prevent
such unauthorized transactions, &man.ypserv.8; supports a
feature called <quote>securenets</quote> which can be used to
restrict access to a given set of hosts. At startup,
@@ -1934,7 +1937,7 @@ nis_client_enable="YES"</programlisting>
<para>While both of these access control mechanisms provide
some security, they, like the privileged port test, are
vulnerable to <quote>IP spoofing</quote> attacks. All
- NIS-related traffic should be blocked at your
+ NIS-related traffic should be blocked at the
firewall.</para>
<para>Servers using <filename>/var/yp/securenets</filename>
@@ -1951,15 +1954,15 @@ nis_client_enable="YES"</programlisting>
<para>Using <filename>/var/yp/securenets</filename> on a
server with such an archaic implementation of TCP/IP is a
really bad idea and will lead to loss of NIS functionality
- for large parts of your network.</para>
+ for large parts of the network.</para>
<indexterm><primary>TCP Wrappers</primary></indexterm>
- <para>The use of the <application>TCP Wrapper</application>
- package increases the latency of your NIS server. The
+ <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 your client systems
- suffers from these symptoms, you should convert the client
+ 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>
@@ -1977,21 +1980,21 @@ nis_client_enable="YES"</programlisting>
<para>There is a way to bar specific users from logging on to a
machine, even if they are present in the NIS database. To do
- this, all you must do is add
+ 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 you wish to bar from logging in.
+ 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 your changes
+ since <command>vipw</command> will sanity check the changes
to <filename>/etc/master.passwd</filename>, as well as
- automatically rebuild the password database when you finish
- editing. For example, if we wanted to bar user
+ automatically rebuild the password database after
+ editing. For example, to bar user
<username>bill</username> from logging on to
- <hostid>basie</hostid> we would:</para>
+ <hostid>basie</hostid>:</para>
<screen>basie&prompt.root; <userinput>vipw</userinput>
<userinput>[add -bill::::::::: to the end, exit]</userinput>
@@ -2037,10 +2040,10 @@ basie&prompt.root;</screen>
<indexterm><primary>netgroups</primary></indexterm>
<para>The method shown in the previous section works reasonably
- well if you need special rules for a very small number of
- users and/or machines. On larger networks, you
- <emphasis>will</emphasis> forget to bar some users from
- logging onto sensitive machines, or you may even have to
+ 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>
@@ -2054,15 +2057,15 @@ 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 if you are forced to deal with such a situation.
+ 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 your successful introduction of NIS in
- your laboratory caught your superiors' interest. Your next
- job is to extend your NIS domain to cover some of the other
+ <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>
@@ -2121,7 +2124,7 @@ basie&prompt.root;</screen>
<entry><hostid>war</hostid>,
<hostid>death</hostid>, <hostid>famine</hostid>,
<hostid>pollution</hostid></entry>
- <entry>Your most important servers. Only the IT
+ <entry>The most important servers deployed. Only the IT
employees are allowed to log onto these
machines.</entry>
</row>
@@ -2154,37 +2157,37 @@ basie&prompt.root;</screen>
</tgroup>
</informaltable>
- <para>If you tried to implement these restrictions by separately
- blocking each user, you would have to add one
+ <para>An attempt to implement these restrictions by separately
+ blocking each user, would require the addition of the
<literal>-<replaceable>user</replaceable></literal> line to
- each system's <filename>passwd</filename> for each user who is
- not allowed to login onto that system. If you forget just one
- entry, you could be in trouble. It may be feasible to do this
- correctly during the initial setup, however you
- <emphasis>will</emphasis> eventually forget to add the lines
- for new users during day-to-day operations. After all, Murphy
- was an optimist.</para>
+ each system's <filename>passwd</filename>. One line for each user
+ who is not allowed to login onto that system. Forgetting just one
+ entry could cause significant trouble. It may be feasible to
+ do this correctly during the initial setup; however, eventually
+ someone will forget to add these lines
+ for new users.</para>
<para>Handling this situation with netgroups offers several
- advantages. Each user need not be handled separately; you
- assign a user to one or more netgroups and allow or forbid
- logins for all members of the netgroup. If you add a new
- machine, you will only have to define login restrictions for
- netgroups. If a new user is added, you will only have to add
- the user to one or more netgroups. Those changes are
+ 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 your NIS setup is planned
- carefully, you will only have to modify exactly one central
- configuration file to grant or deny access to machines.</para>
+ 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. FreeBSD's &man.ypinit.8; does not create this map
- by default, but its NIS implementation will support it once it
- has been created. 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>
- <para>and start adding content. For our example, we need at
+ <para>and begin adding content. For our example, we need at
least four netgroups: IT employees, IT apprentices, normal
employees and interns.</para>
@@ -2202,10 +2205,10 @@ INTERNS (,able,test-domain) (,baker,test-domain)</programlisting>
<orderedlist>
<listitem>
<para>The name of the host(s) where the following items are
- valid. If you do not specify a hostname, the entry is
- valid on all hosts. If you do specify a hostname, you
- will enter a realm of darkness, horror and utter
- confusion.</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>
@@ -2214,43 +2217,41 @@ INTERNS (,able,test-domain) (,baker,test-domain)</programlisting>
</listitem>
<listitem>
- <para>The NIS domain for the account. You can import
- accounts from other NIS domains into your netgroup if you
- are one of the unlucky fellows with more than one NIS
- domain.</para>
+ <para>The NIS domain for the account. Accounts may be
+ imported from other NIS domains into a netgroup.</para>
</listitem>
</orderedlist>
- <para>Each of these fields can contain wildcards. See
+ <para>Each of these fields may contain wildcards. See
&man.netgroup.5; for details.</para>
<note>
<indexterm><primary>netgroups</primary></indexterm>
<para>Netgroup names longer than 8 characters should not be
- used, especially if you have machines running other
- operating systems within your NIS domain. The names are
- case sensitive; using capital letters for your netgroup
+ 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 FreeBSD) cannot handle
+ <para>Some NIS clients (other than &os;) cannot handle
netgroups with a large number of entries. For example, some
older versions of &sunos; start to cause trouble if a
netgroup contains more than 15 <emphasis>entries</emphasis>.
- You can circumvent this limit by creating several
- sub-netgroups with 15 users or less and a real netgroup that
- consists of the sub-netgroups:</para>
+ This limit may be circumvented by creating several
+ sub-netgroups with 15 users or fewer and a real netgroup
+ consisting of the sub-netgroups:</para>
<programlisting>BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...]
BIGGRP2 (,joe16,domain) (,joe17,domain) [...]
BIGGRP3 (,joe31,domain) (,joe32,domain)
BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3</programlisting>
- <para>You can repeat this process if you need more than 225
- users 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 your new NIS map is
+ <para>Activating and distributing the new NIS map is
easy:</para>
<screen>ellington&prompt.root; <userinput>cd /var/yp</userinput>
@@ -2260,7 +2261,7 @@ ellington&prompt.root; <userinput>make</userinput></screen>
<filename>netgroup</filename>,
<filename>netgroup.byhost</filename> and
<filename>netgroup.byuser</filename>. Use &man.ypcat.1; to
- check if your new NIS maps are available:</para>
+ check if the new NIS maps are available:</para>
<screen>ellington&prompt.user; <userinput>ypcat -k netgroup</userinput>
ellington&prompt.user; <userinput>ypcat -k netgroup.byhost</userinput>
@@ -2268,13 +2269,13 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
<para>The output of the first command should resemble the
contents of <filename>/var/yp/netgroup</filename>. The second
- command will not produce output if you have not specified
- host-specific netgroups. The third command can be used to
+ 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>
<para>The client setup is quite simple. To configure the server
- <hostid>war</hostid>, you only have to start
- &man.vipw.8; and replace the line</para>
+ <hostid>war</hostid>, use
+ &man.vipw.8; to replace the line</para>
<programlisting>+:::::::::</programlisting>
@@ -2295,8 +2296,8 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
<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, you will have to import all user entries
- <emphasis>without allowing them to login onto your
+ 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
@@ -2306,9 +2307,9 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
<para><literal>+:::::::::/sbin/nologin</literal>, meaning
<quote>Import all entries but replace the shell with
<filename>/sbin/nologin</filename> in the imported
- entries</quote>. You can replace any field in the
+ entries</quote>. It is possible to replace any field in the
<literal>passwd</literal> entry by placing a default value in
- your <filename>/etc/master.passwd</filename>.</para>
+ <filename>/etc/master.passwd</filename>.</para>
<!-- Been there, done that, got the scars to prove it - ue -->
<warning>
@@ -2320,9 +2321,9 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
shell.</para>
</warning>
- <para>After this change, you will only have to change one NIS
- map if a new employee joins the IT department. You could use
- a similar approach for the less important servers by replacing
+ <para>After this change, the NIS map will only need modification
+ when a new employee joins the IT department. A similar approach
+ for the less important servers may be used by replacing
the old <literal>+:::::::::</literal> in their local version
of <filename>/etc/master.passwd</filename> with something like
this:</para>
@@ -2342,16 +2343,16 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
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. You
- add a new netgroup <literal>IT_INTERN</literal>, add the new
- IT interns to this netgroup and start to change the
- configuration on each and every machine... As the old saying
+ 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
be used to prevent situations like these. One possibility is
- the creation of role-based netgroups. For example, you could
+ the creation of role-based netgroups. For example, one might
create a netgroup called <literal>BIGSRV</literal> to define
the login restrictions for the important servers, another
netgroup called <literal>SMALLSRV</literal> for the less
@@ -2359,7 +2360,7 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
<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 your NIS map netgroup should look like
+ entries for the NIS map netgroup should look like
this:</para>
<programlisting>BIGSRV IT_EMP IT_APP
@@ -2367,10 +2368,11 @@ SMALLSRV IT_EMP IT_APP ITINTERN
USERBOX IT_EMP ITINTERN USERS</programlisting>
<para>This method of defining login restrictions works
- reasonably well if you can define groups of machines with
- identical restrictions. Unfortunately, this is the exception
- and not the rule. Most of the time, you will need the ability
- to define login restrictions on a per-machine basis.</para>
+ reasonably well when it is possible to define groups of machines
+ with identical restrictions. Unfortunately, this is the
+ exception and not the rule. Most of the time, the ability
+ to define login restrictions on a per-machine basis is
+ required.</para>
<para>Machine-specific netgroup definitions are the other
possibility to deal with the policy change outlined above. In
@@ -2386,8 +2388,8 @@ USERBOX IT_EMP ITINTERN USERS</programlisting>
<programlisting>+@<replaceable>BOXNAME</replaceable>:::::::::
+:::::::::/sbin/nologin</programlisting>
- <para>Once you have completed this task for all your machines,
- you will not have 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
@@ -2429,50 +2431,52 @@ ONE SECURITY
TWO (,hotel,test-domain)
# [...more groups to follow]</programlisting>
- <para>If you are using some kind of database to manage your user
- accounts, you should be able to create the first part of the
- map with your database's report tools. This way, new users
+ <para>If some kind of database is used to manage the user
+ accounts, it may be possible to create the first part of the
+ map using the database's reporting tools. This way, new users
will automatically have access to the boxes.</para>
<para>One last word of caution: It may not always be advisable
- to use machine-based netgroups. If you are deploying a couple
+ to use machine-based netgroups. When deploying a couple
of dozen or even hundreds of identical machines for student
- labs, you should use role-based netgroups instead of
- machine-based netgroups to keep the size of the NIS map within
- reasonable limits.</para>
+ labs, role-based netgroups instead of
+ machine-based netgroups may be used to keep the size of the NIS
+ map within reasonable limits.</para>
</sect2>
<sect2>
<title>Important Things to Remember</title>
- <para>There are still a couple of things that you will need to
- do differently now that you are in an NIS environment.</para>
+ <para>There are still a couple of things administrators need to
+ do differently now that machines are in an NIS
+ environment.</para>
<itemizedlist>
<listitem>
- <para>Every time you wish to add a user to the lab, you
- must add it to the master NIS server
- <emphasis>only</emphasis>, and <emphasis>you must remember
- to rebuild the NIS maps</emphasis>. If you forget to do
- this, the new user will not be able to login anywhere
- except on the NIS master. For example, if we needed to
- add a new user <username>jsmith</username> to the lab, we
- would:</para>
+ <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
+ needed to add a new user <username>jsmith</username> to
+ the lab, we would:</para>
<screen>&prompt.root; <userinput>pw useradd jsmith</userinput>
&prompt.root; <userinput>cd /var/yp</userinput>
&prompt.root; <userinput>make test-domain</userinput></screen>
- <para>You could also run <command>adduser jsmith</command>
+ <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>. You do not want to be propagating
- administrative accounts and passwords to machines that
- will have users that should not have access to those
- accounts.</para>
+ NIS maps</emphasis>. This is undesirable as it will
+ create a security risk. These users and passwords should
+ not be propagated to all machines. Especially if these
+ 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
@@ -2482,8 +2486,9 @@ TWO (,hotel,test-domain)
login to the lab.</para>
<para>This is the chief weakness of any centralized
- administration system. If you do not protect your NIS
- servers, you will have a lot of angry users!</para>
+ administration system. If the NIS servers are not
+ protected, there will be a lot of angry users and
+ unhappy management!</para>
</listitem>
</itemizedlist>
</sect2>
@@ -2491,19 +2496,19 @@ TWO (,hotel,test-domain)
<sect2>
<title>NIS v1 Compatibility</title>
- <para> FreeBSD's <application>ypserv</application> has some
- support for serving NIS v1 clients. FreeBSD's NIS
- implementation only uses the NIS v2 protocol, however other
+ <para>&os;'s <application>ypserv</application> has some
+ support for serving NIS v1 clients. &os;'s NIS
+ implementation only uses the NIS v2 protocol; however, other
implementations include support for the v1 protocol for
backwards compatibility with older systems. The
<application>ypbind</application> daemons supplied with these
- systems will try to establish a binding to an NIS v1 server
+ systems will attempt to establish a binding to an NIS v1 server
even though they may never actually need it (and they may
persist in broadcasting in search of one even after they
receive a response from a v2 server). Note that while support
for normal client calls is provided, this version of
<application>ypserv</application> does not handle v1 map
- transfer requests; consequently, it cannot be used as a master
+ transfer requests. Additionally, it cannot be used as a master
or slave in conjunction with older NIS servers that only
support the v1 protocol. Fortunately, there probably are not
any such servers still in use today.</para>
@@ -2512,7 +2517,7 @@ TWO (,hotel,test-domain)
<sect2 id="network-nis-server-is-client">
<title>NIS Servers That Are Also NIS Clients</title>
- <para> Care must be taken when running
+ <para>Care must be taken when running
<application>ypserv</application> in a multi-server domain
where the server machines are also NIS clients. It is
generally a good idea to force the servers to bind to
@@ -2525,11 +2530,11 @@ TWO (,hotel,test-domain)
present since the servers might bind to each other all over
again.</para>
- <para>You can force a host to bind to a particular server by
+ <para>A host may be forced to bind to a particular server by
running <command>ypbind</command> with the <option>-S</option>
- flag. If you do not want to do this manually each time you
- reboot your NIS server, you can add the following lines to
- your <filename>/etc/rc.conf</filename>:</para>
+ flag. Add the following lines to
+ <filename>/etc/rc.conf</filename> to enable this feature
+ during every system boot:</para>
<programlisting>nis_client_enable="YES" # run client stuff as well
nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</replaceable>"</programlisting>
@@ -2546,12 +2551,12 @@ nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</
</indexterm>
<para>One of the most common issues that people run into when
trying to implement NIS is password format compatibility. If
- your NIS server is using DES encrypted passwords, it will only
- support clients that are also using DES. For example, if you
- have &solaris; NIS clients in your network, then you will
- almost certainly need to use DES encrypted passwords.</para>
+ the NIS server is using DES encrypted passwords, it will only
+ support clients that are also using DES. For example, if any
+ &solaris; NIS clients exist on the network, there is a highly
+ likelihood DES must be used for encrypted passwords.</para>
- <para>To check which format your servers and clients are using,
+ <para>To check which format the servers and clients are using,
look at <filename>/etc/login.conf</filename>. If the host is
configured to use DES encrypted passwords, then the
<literal>default</literal> class will contain an entry like
@@ -2567,9 +2572,9 @@ nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</
<literal>blf</literal> and <literal>md5</literal> (for
Blowfish and MD5 encrypted passwords, respectively).</para>
- <para>If you have made changes to
- <filename>/etc/login.conf</filename>, you will also need to
- rebuild the login capability database, which is achieved by
+ <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
<username>root</username>:</para>
@@ -2582,26 +2587,380 @@ nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</
rebuilt.</para></note>
<para>Next, in order to ensure that passwords are encrypted with
- the format that you have chosen, you should also check that
+ the chosen format, check that
the <literal>crypt_default</literal> in
- <filename>/etc/auth.conf</filename> gives precedence to your
- chosen password format. To do this, place the format that you
- have chosen first in the list. For example, when using DES
+ <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>
<programlisting>crypt_default = des blf md5</programlisting>
<para>Having followed the above steps on each of the &os; based
- NIS servers and clients, you can be sure that they all agree
- on which password format is used within your network. If you
+ 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:
- if you want to deploy an NIS server for a heterogeneous
- network, you will probably have to use DES on all systems
+ 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>
+ <sect1 id="network-ldap">
+ <sect1info>
+ <authorgroup>
+ <author>
+ <firstname>Tom</firstname>
+ <surname>Rhodes</surname>
+ <contrib>Written by </contrib>
+ </author>
+ </authorgroup>
+ </sect1info>
+ <title>&os; and <acronym>LDAP</acronym></title>
+
+ <indexterm><primary>LDAP</primary></indexterm>
+
+ <para><acronym>LDAP</acronym>, the Lightweight Directory Access
+ Protocol, is an application layer protocol used to access,
+ modify, and authenticate (bind) using a distributed directory
+ information service. Think of it as a phone or record book which
+ stores several levels of hierarchical, homogeneous information.
+ It is often used in networks where users often need access to
+ several levels of internal information utilizing a single
+ account. For example, email authentication, pulling employee
+ contact information, and internal website authentication might
+ all make use of a single user in the <acronym>LDAP</acronym>
+ server's record base.</para>
+
+ <para>This section will not provide a history or the implementation
+ details of the protocol. These sections were authored to get an
+ <acronym>LDAP</acronym> server and/or client configured both
+ quickly and securely; however, any information base requires
+ planning and this is no exception.</para>
+
+ <para>Planning should include what type of information will be
+ stored, what that information will be used for, whom should
+ have access to said information, and how to secure this
+ information from prying eyes.</para>
+
+ <sect2>
+ <title><acronym>LDAP</acronym> Terminology and Structure</title>
+
+ <para>Before continuing, several parts of <acronym>LDAP</acronym>
+ must be explained to prevent confusion. And confusion with
+ this configuration is relatively simple. To begin, all
+ directory entries consist of a group of
+ <emphasis>attributes</emphasis>. Each of these attribute sets
+ contain a name, a unique identifier known as a
+ <acronym>DN</acronym> or distinguished name normally built from
+ several other attributes such as the <acronym>RDN</acronym>.
+ The <acronym>RDN</acronym> or relative distinguished name, is
+ a more common name for the attribute. Like directories have
+ absolute and relative paths, consider a <acronym>DN</acronym>
+ as an absolute path and the <acronym>RDN</acronym> as the
+ relative path.</para>
+
+ <para>As an example, an entry might look like the
+ following:</para>
+
+ <screen>&prompt.user; ldapsearch -xb "uid=trhodes,ou=users,o=example.com"</screen>
+
+ <programlisting># extended LDIF
+#
+# LDAPv3
+# base &lt;uid=trhodes,ou=users,o=example.com&gt; with scope subtree
+# filter: (objectclass=*)
+# requesting: ALL
+#
+
+# trhodes, users, example.com
+dn: uid=trhodes,ou=users,o=example.com
+mail: trhodes@example.com
+cn: Tom Rhodes
+uid: trhodes
+telephoneNumber: (xxx) xxx-xxxx
+
+# search result
+search: 2
+result: 0 Success
+
+# numResponses: 2
+# numEntries: 1</programlisting>
+
+ <para>In this example, it is very obvious what the various
+ attributes are; however, the <acronym>cn</acronym> attribute
+ should be noticed. This is the <acronym>RDN</acronym> discussed
+ previously. In addition, there is a unique user id provided
+ here. It is common practice to have specific uid or uuids for
+ entries to ease in any future migration.</para>
+ </sect2>
+
+ <sect2>
+ <title>Configuring an <acronym>LDAP</acronym> Server</title>
+
+ <indexterm><primary>LDAP Server</primary></indexterm>
+
+ <para>To configure &os; to act as an <acronym>LDAP</acronym>
+ server, the OpenLDAP port needs installed. This may be
+ accomplished using the <command>pkg_add</command> command
+ or by installing the
+ <filename role="port">net/openldap24-server</filename>
+ port. Building the port is recommended as the administrator
+ may select a great deal of options at this time and disable
+ some options. In most cases, the defaults will be fine;
+ however, this is the time to enable SQL support if
+ needed.</para>
+
+ <para>A few directories will be required from this point on,
+ at minimal, a data directory and a directory to store the
+ certificates in. Create them both with the following
+ commands:</para>
+
+ <screen>&prompt.root; <userinput>mkdir /var/db/openldap-data</userinput></screen>
+
+ <screen>&prompt.root; <userinput>mkdir /usr/local/etc/openldap/private</userinput></screen>
+
+ <para>Copy over the database configuration file:</para>
+
+ <screen>&prompt.root; <userinput>cp /usr/local/etc/openldap/DB_CONFIG.example /var/db/openldap-data/DB_CONFIG</userinput></screen>
+
+ <para>The next phase is to configure the <acronym>SSL</acronym>
+ certificates. While creating certificates is discussed in
+ the <link linkend="openssl">OpenSSL</link> section in this
+ book, a certificate authority is needed so a different method
+ will be used. It is recommended that this section be reviewed
+ prior to configuring to ensure correct information is entered
+ 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>
+
+ <screen>&prompt.root; <userinput>openssl req -days 365 -nodes -new -x509 -keyout ca.key -out ../ca.crt</userinput></screen>
+
+ <para>The entries for these may be completely generic
+ <emphasis>except</emphasis> for the
+ <emphasis>Common Name</emphasis> entry. This entry must have
+ something different than the system hostname. If the entry
+ is the hostname, it would be like the hostname is attempting
+ to verify hostname. In cases with a self signed certificate
+ like this example, just prefix the hostname with
+ <acronym>CA</acronym> for certificate authority.</para>
+
+ <para>The next task is to create a certificate signing request
+ and a private key. To do this, issue the following
+ commands:</para>
+
+ <screen>&prompt.root; <userinput>openssl req -days 365 -nodes -new -keyout server.key -out server.csr</userinput></screen>
+
+ <para>During the certificate generation process, be sure to
+ correctly set the common name attribute. After this has
+ been completed, the key will need signed:</para>
+
+ <screen>&prompt.root; <userinput>openssl x509 -req -days 365 -in server.csr -out ../server.crt -CA ../ca.crt -CAkey ca.key -CAcreateserial</userinput></screen>
+
+ <para>The final part of the certificate generation process
+ is to generate and sign the client certificates:</para>
+
+ <screen>&prompt.root; <userinput>openssl req -days 365 -nodes -new -keyout client.key -out client.csr</userinput></screen>
+
+ <screen>&prompt.root; <userinput>openssl x509 -req -days 3650 -in client.csr -out ../client.crt -CA ../ca.crt -CAkey ca.key</userinput></screen>
+
+ <para>Remember, again, to respect the common name attribute. This
+ is a common cause for confusion during the first attempt to
+ configure <acronym>LDAP</acronym>. In addition, ensure that
+ a total of eight (8) new files have been generated through
+ the proceeding commands. If so, the next step is to edit
+ <filename>/usr/local/etc/openldap/slapd.conf</filename> and add
+ the following options:</para>
+
+ <programlisting>TLSCipherSuite HIGH:MEDIUM:+SSLv3
+TLSCertificateFile /usr/local/etc/openldap/server.crt
+TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key
+TLSCACertificateFile /usr/local/etc/openldap/ca.crt</programlisting>
+
+ <para>In addition, edit
+ <filename>/usr/local/etc/openldap/ldap.conf</filename> and
+ add the following lines:</para>
+
+ <programlisting>TLS_CACERT /usr/local/etc/openldap/ca.crt
+TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3</programlisting>
+
+ <para>While editing these this file, set the <option>BASE</option>
+ to the desired values, and uncomment all three of the
+ <option>URI</option>, <option>SIZELIMIT</option> and
+ <option>TIMELIMIT</option> options. In addition, set the
+ <option>URI</option> to contain <option>ldap://</option>
+ and <option>ldaps://</option>.</para>
+
+ <para>The resulting file should look similar to the following
+ shown here:</para>
+
+ <programlisting>BASE dc=example,dc=com
+URI ldap:// ldaps://
+
+SIZELIMIT 12
+TIMELIMIT 15
+#DEREF never
+
+TLS_CACERT /usr/local/etc/openldap/ca.crt
+TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3</programlisting>
+
+ <para>A password for the server will need to be created as the
+ default is extremely poor as is normal in this industry. To
+ do this, issue the following command, sending the output to
+ <filename>slapd.conf</filename>:</para>
+
+ <screen>&prompt.root; <userinput>slappasswd -h "{SHA}" &gt;&gt; /usr/local/etc/openldap/slapd.conf</userinput></screen>
+
+ <para>There will be a prompt for entering the password and,
+ if the process does not fail, a password hash will be added
+ to the end of <filename>slapd.conf</filename>. The
+ <command>slappasswd</command> understands several hashing
+ formats, refer to the manual page for more information.</para>
+
+ <para>Edit <filename>/usr/local/etc/openldap/slapd.conf</filename>
+ and add the following lines:</para>
+
+ <programlisting>password-hash {sha}
+allow bind_v2</programlisting>
+
+ <para>In addition, the <option>suffix</option> in this file must
+ be updated to match the <option>BASE</option> from the previous
+ configuration. The <option>rootdn</option> option should
+ also be set. A good recommendation is something like
+ <option>cn=Manager</option>. Before saving this file, place
+ the <option>rootpw</option> option in front of the password
+ output from the <command>slappasswd</command> and delete the
+ old <option>rootpw</option> option above. The end result
+ should look similar to this:</para>
+
+ <programlisting>TLSCipherSuite HIGH:MEDIUM:+SSLv3
+TLSCertificateFile /usr/local/etc/openldap/server.crt
+TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key
+TLSCACertificateFile /usr/local/etc/openldap/ca.crt
+rootpw {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=</programlisting>
+
+ <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
+ lines:</para>
+
+ <programlisting>slapd_enable="YES"
+slapd_flags="-4 -h ldaps:///"</programlisting>
+
+ <para>At this point the server should be ready to be brought
+ up and tested. To perform this task, issue the following
+ command:</para>
+
+ <screen>&prompt.root; <userinput>service slapd start</userinput></screen>
+
+ <para>If everything was configured correctly, a search of the
+ directory should show a successful connection with a single
+ response as in this example:</para>
+
+ <screen>&prompt.root; <userinput>ldapsearch -Z</userinput></screen>
+
+ <programlisting># extended LDIF
+#
+# LDAPv3
+# base &lt;dc=example,dc=com&gt; (default) with scope subtree
+# filter: (objectclass=*)
+# requesting: ALL
+#
+
+# search result
+search: 3
+result: 32 No such object
+
+# numResponses: 1</programlisting>
+
+ <para>Considering the service should now be responding, as it
+ is above, the directory may be populated using the
+ <command>ldapadd</command> command. In this example, there
+ is a file containing a list of users to be added to this
+ particular directory. First, create a file to be imported
+ with the following dataset:</para>
+
+ <programlisting>dn: dc=example,dc=com
+objectclass: dcObject
+objectclass: organization
+o: Example
+dc: Example
+
+dn: cn=Manager,dc=example,dc=com
+objectclass: organizationalRole
+cn: Manager</programlisting>
+
+ <note>
+ <para>To debug any of the following, stop the
+ <command>slapd</command> service using the
+ <command>service</command> command and start it using with
+ debugging options. To accomplish this, issue the following
+ command:</para>
+
+ <screen>&prompt.root; <userinput>/usr/local/libexec/slapd -d -1</userinput></screen>
+ </note>
+
+ <para>To import this datafile, issue the following command,
+ assuming the file is <filename>import.ldif</filename>:</para>
+
+ <screen>&prompt.root; <userinput>ldapadd -Z -D "cn=Manager,dc=example,dc=com" -W -f <replaceable>import.ldif</replaceable></userinput></screen>
+
+ <para>There will be a request for the password specified earlier,
+ and the output should look like this:</para>
+
+ <screen>Enter LDAP Password:
+adding new entry "dc=example,dc=com"
+
+adding new entry "cn=Manager,dc=example,dc=com"</screen>
+
+ <para>Verify the data was added by issuing a search on the
+ server using <command>ldapsearch</command>. In this case
+ the output should look like this:</para>
+
+ <screen>&prompt.user; <userinput>ldapsearch -Z</userinput></screen>
+
+ <screen># extended LDIF
+#
+# LDAPv3
+# base &lt;dc=example,dc=com&gt; (default) with scope subtree
+# filter: (objectclass=*)
+# requesting: ALL
+#
+
+# example.com
+dn: dc=example,dc=com
+objectClass: dcObject
+objectClass: organization
+o: Example
+dc: Example
+
+# Manager, example.com
+dn: cn=Manager,dc=example,dc=com
+objectClass: organizationalRole
+cn: Manager
+
+# search result
+search: 3
+result: 0 Success
+
+# numResponses: 3
+# numEntries: 2</screen>
+
+ <para>It is of course advisable to read about the structure of
+ <acronym>LDAP</acronym> directories and the various manual
+ pages mentioned in this section. At this point, the server
+ should be configured and functioning properly.</para>
+ </sect2>
+ </sect1>
+
<sect1 id="network-dhcp">
<sect1info>
<authorgroup>
@@ -2693,7 +3052,7 @@ nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</
fill in the network configuration information
automatically.</para>
- <para>There are two things you must do to have your system use
+ <para>There are two things required to have the system use
DHCP upon startup:</para>
<indexterm>
<primary>DHCP</primary>
@@ -2702,30 +3061,33 @@ nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</
<itemizedlist>
<listitem>
<para>Make sure that the <devicename>bpf</devicename>
- device is compiled into your kernel. To do this, add
- <literal>device bpf</literal> to your kernel
+ 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 FreeBSD, so if you do not have a custom kernel, you
- should not need to create one in order to get DHCP
- working.</para>
+ 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 properly.</para>
+
<note>
<para>For those who are particularly security conscious,
- you should be warned that <devicename>bpf</devicename>
+ 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, but if you are very sensitive
- about security, you probably should not add
- <devicename>bpf</devicename> to your
+ 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 you will be using DHCP.</para>
+ future the system will be using DHCP.</para>
</note>
</listitem>
+
<listitem>
<para>By default, DHCP configuration on &os; runs in the
background, or <firstterm>asynchronously</firstterm>.
@@ -2761,9 +3123,10 @@ nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</
<xref linkend="config-network-setup"/>.</para>
</note>
- <para>If you are using a different location for
- <command>dhclient</command>, or if you wish to pass
- additional flags to <command>dhclient</command>, also
+ <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>
<programlisting>dhclient_program="/sbin/dhclient"
@@ -2846,10 +3209,11 @@ dhclient_flags=""</programlisting>
(Internet Systems Consortium) implementation of the DHCP
server.</para>
- <para>The server is not provided as part of FreeBSD, and so
- you will need to install the <filename
- role="package">net/isc-dhcp42-server</filename> port to
- provide this service. See <xref linkend="ports"/> for
+ <para>The server is not provided as part of &os;, and so
+ the <filename
+ role="package">net/isc-dhcp42-server</filename> port must
+ be installed to provide this service.
+ See <xref linkend="ports"/> for
more information on using the Ports Collection.</para>
</sect3>
@@ -2860,33 +3224,35 @@ dhclient_flags=""</programlisting>
<primary>DHCP</primary>
<secondary>installation</secondary>
</indexterm>
- <para>In order to configure your FreeBSD system as a DHCP
- server, you will need to ensure that the &man.bpf.4;
- device is compiled into your kernel. To do this, add
- <literal>device bpf</literal> to your kernel
+ <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 FreeBSD, so you do not need to create a
- custom kernel in order to get DHCP working.</para>
+ 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 work
+ the device that allows packet sniffers to function
correctly (although such programs still need
- privileged access). <devicename>bpf</devicename>
- <emphasis>is</emphasis> required to use DHCP, but if
- you are very sensitive about security, you probably
- should not include <devicename>bpf</devicename> in
- your kernel purely because you expect to use DHCP at
- some point in the future.</para>
+ 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 you will need to do is edit the
+ <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.
@@ -2993,9 +3359,9 @@ host mailhost {
</callout>
</calloutlist>
- <para>Once you have finished writing your
- <filename>dhcpd.conf</filename>,
- you should enable the DHCP server in
+ <para>Once the configuration of
+ <filename>dhcpd.conf</filename> has been completed,
+ enable the DHCP server in
<filename>/etc/rc.conf</filename>, i.e., by adding:</para>
<programlisting>dhcpd_enable="YES"
@@ -3003,23 +3369,21 @@ dhcpd_ifaces="dc0"</programlisting>
<para>Replace the <literal>dc0</literal> interface name with
the interface (or interfaces, separated by whitespace)
- that your DHCP server should listen on for DHCP client
+ that the DHCP server should listen on for DHCP client
requests.</para>
- <para>Then, you can proceed to start the server by issuing
+ <para>Proceed to start the server by issuing
the following command:</para>
<screen>&prompt.root; <userinput>service isc-dhcpd start</userinput></screen>
- <para>Should you need to make changes to the configuration
- of your server in the future, it is important to note that
- sending a <literal>SIGHUP</literal> signal to
- <application>dhcpd</application> does
- <emphasis>not</emphasis> result in the configuration being
- reloaded, as it does with most daemons. You will need to
- send a <literal>SIGTERM</literal> signal to stop the
- process, and then restart it using the command
- above.</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>
@@ -3067,7 +3431,7 @@ dhcpd_ifaces="dc0"</programlisting>
<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 you require this functionality,
+ 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
@@ -3390,8 +3754,8 @@ 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. However, if you are interested in
- the startup options for <application>named</application> on
+ 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
@@ -3487,7 +3851,7 @@ options {
<warning>
<para><hostid role="ipaddr">127.0.0.1</hostid> will
<emphasis>not</emphasis> work here. Change this
- <acronym>IP</acronym> address to a name server at your
+ <acronym>IP</acronym> address to a name server at the
uplink.</para>
</warning>
@@ -4527,9 +4891,9 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
world. The majority of web servers on the Internet are using
the <application>Apache HTTP Server</application>.
<application>Apache</application> software packages should be
- included on your FreeBSD installation media. If you did not
- install <application>Apache</application> when you first
- installed FreeBSD, then you can install it from the <filename
+ included on the &os; installation media. If
+ <application>Apache</application> was not installed while
+ installing &os;, then it can be installed from the <filename
role="package">www/apache22</filename> port.</para>
<para>Once <application>Apache</application> has been installed
@@ -4582,7 +4946,7 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
<listitem>
<para>The address to which problems with the server should
- be emailed. This address appears on some
+ be emailed. This address also appears on some
server-generated pages, such as error documents.</para>
</listitem>
</varlistentry>
@@ -4591,10 +4955,11 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
<term><literal>ServerName www.example.com</literal></term>
<listitem>
- <para><literal>ServerName</literal> allows you to set a
- host name which is sent back to clients for your server
- if it is different than the one that the host is
- configured with (i.e., use <hostid>www</hostid> instead
+ <para><literal>ServerName</literal> allows an administrator
+ to set a host name which is sent back to clients for the
+ server. This is useful if the host is different than the
+ one that it is configured with (i.e., use
+ <hostid>www</hostid> instead
of the host's real name).</para>
</listitem>
</varlistentry>
@@ -4604,8 +4969,8 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
"/usr/local/www/apache22/data"</literal></term>
<listitem>
- <para><literal>DocumentRoot</literal>: The directory out
- of which you will serve your documents. By default, all
+ <para><literal>DocumentRoot</literal>: The directory
+ where documents will be served from. By default, all
requests are taken from this directory, but symbolic
links and aliases may be used to point to other
locations.</para>
@@ -4613,11 +4978,13 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
</varlistentry>
</variablelist>
- <para>It is always a good idea to make backup copies of your
+ <para>It is always a good idea to make backup copies of the
<application>Apache</application> configuration file before
- making changes. Once you are satisfied with your initial
- configuration you are ready to start running
- <application>Apache</application>.</para>
+ making changes. When the configuration of
+ <application>Apache</application>, is complete, save the
+ file and verify the configuration using &man.apachectl.8;.
+ To do this, issue <command>apachectl configtest</command>
+ which should return <literal>Syntax OK</literal>.</para>
</sect2>
<sect2>
@@ -4645,8 +5012,7 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
<programlisting>apache22_flags=""</programlisting>
<para>The <application>Apache</application> configuration can be
- tested for errors before starting the <command>httpd</command>
- daemon for the first time, or after making subsequent
+ tested for errors after making subsequent
configuration changes while <command>httpd</command> is
running. This can be done by the &man.rc.8; script directly,
or by the &man.service.8; utility by issuing one of the
@@ -4691,14 +5057,14 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
<para>To setup <application>Apache</application> to use
Name-based Virtual Hosting add an entry like the following to
- your <filename>httpd.conf</filename>:</para>
+ <filename>httpd.conf</filename>:</para>
<programlisting>NameVirtualHost *</programlisting>
- <para>If your webserver was named <hostid
- role="fqdn">www.domain.tld</hostid> and you wanted to setup
+ <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 you would
+ role="fqdn">www.someotherdomain.tld</hostid> then
add the following entries to
<filename>httpd.conf</filename>:</para>
@@ -4712,8 +5078,8 @@ ServerName www.someotherdomain.tld
DocumentRoot /www/someotherdomain.tld
&lt;/VirtualHost&gt;</screen>
- <para>Replace the addresses with the addresses you want to use
- and the path to the documents with what you are using.</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>
@@ -4746,7 +5112,7 @@ DocumentRoot /www/someotherdomain.tld
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 so that you can run
+ a trusted certificate signing authority to run
a secure web server on &os;.</para>
<para>The <application>mod_ssl</application> module is built
@@ -4802,8 +5168,8 @@ DocumentRoot /www/someotherdomain.tld
<para>Django depends on <application>mod_python</application>,
<application>Apache</application>, and an SQL database
- engine of your choice. The FreeBSD Port will install all of
- these pre-requisites for you with the appropriate
+ engine. The &os; Port will install all of
+ these pre-requisites with the appropriate
flags.</para>
<example id="network-www-django-install">
@@ -4815,22 +5181,23 @@ DocumentRoot /www/someotherdomain.tld
<screen>&prompt.root; <userinput>cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL</userinput></screen>
</example>
- <para>Once Django and these pre-requisites are installed, you
- will need to create a Django project directory and then
- configure Apache to use the embedded Python interpreter to
- call your application for specific URLs on your site.</para>
+ <para>Once Django and these pre-requisites are installed,
+ the application will need a Django project directory along
+ with the Apache configuration to use the embedded Python
+ interpreter. This will be the interpreter to
+ call the application for specific URLs on the site.</para>
<example id="network-www-django-apache-config">
<title>Apache Configuration for Django/mod_python</title>
- <para>You will need to add a line to the apache
+ <para>A line must be added to the apache
<filename>httpd.conf</filename> file to configure Apache
- to pass requests for certain URLs to your web
+ to pass requests for certain URLs to the web
application:</para>
<screen>&lt;Location "/"&gt;
SetHandler python-program
- PythonPath "['/dir/to/your/django/packages/'] + sys.path"
+ PythonPath "['/dir/to/the/django/packages/'] + sys.path"
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonAutoReload On
@@ -5020,7 +5387,7 @@ DocumentRoot /www/someotherdomain.tld
<para>The most important configuration step is deciding which
accounts will be allowed access to the FTP server. A normal
- FreeBSD system has a number of system accounts used for
+ &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
@@ -5029,7 +5396,8 @@ DocumentRoot /www/someotherdomain.tld
specific users here that should not be allowed access to
FTP.</para>
- <para>You may want to restrict the access of some users without
+ <para>In some cases it may be desirable to restrict the access
+ of some users without
preventing them completely from using FTP. This can be
accomplished with the <filename>/etc/ftpchroot</filename>
file. This file lists users and groups subject to FTP access
@@ -5041,10 +5409,10 @@ DocumentRoot /www/someotherdomain.tld
<secondary>anonymous</secondary>
</indexterm>
- <para>If you would like to enable anonymous FTP access to your
- server, then you must create a user named
- <username>ftp</username> on your &os; system. Users will then
- be able to log on to your FTP server with a username of
+ <para>To enable anonymous FTP access to the
+ server, create a user named
+ <username>ftp</username> on the &os; system. Users will then
+ be able to log on to the FTP server with a username of
<username>ftp</username> or <username>anonymous</username> and
with any password (by convention an email address for the user
should be used as the password). The FTP server will call
@@ -5074,7 +5442,7 @@ DocumentRoot /www/someotherdomain.tld
the <application>inetd</application> configuration must be
reloaded after this configuration file is changed. Please
refer to <xref linkend="network-inetd-settings"/> for details
- on enabling <application>inetd</application> on your
+ on enabling <application>inetd</application> on the
system.</para>
<para>Alternatively, <application>ftpd</application> can also be
@@ -5091,7 +5459,7 @@ DocumentRoot /www/someotherdomain.tld
<screen>&prompt.root; <userinput>service ftpd start</userinput></screen>
- <para>You can now log on to your FTP server by typing:</para>
+ <para>You can now log on to the FTP server by typing:</para>
<screen>&prompt.user; <userinput>ftp localhost</userinput></screen>
@@ -5119,13 +5487,14 @@ DocumentRoot /www/someotherdomain.tld
</indexterm>
<para>Be aware of the potential problems involved with running
- an anonymous FTP server. In particular, you should think
- twice about allowing anonymous users to upload files. You may
- find that your FTP site becomes a forum for the trade of
- unlicensed commercial software or worse. If you do need to
- allow anonymous FTP uploads, then you should set up the
+ an anonymous FTP server. In particular, think
+ twice about allowing anonymous users to upload files. It may
+ turn out that the FTP site becomes a forum for the trade of
+ unlicensed commercial software or worse. If anonymous
+ FTP uploads are required, then verify the
permissions so that these files can not be read by other
- anonymous users until they have been reviewed.</para>
+ anonymous users until they have been reviewed by an
+ administrator.</para>
</sect2>
</sect1>
@@ -5160,13 +5529,13 @@ DocumentRoot /www/someotherdomain.tld
<para><application>Samba</application> is a popular open source
software package that provides file and print services for
&microsoft.windows; clients. Such clients can connect to and
- use FreeBSD filespace as if it was a local disk drive, or
- FreeBSD printers as if they were local printers.</para>
+ use &os; filespace as if it was a local disk drive, or
+ &os; printers as if they were local printers.</para>
<para><application>Samba</application> software packages should
- be included on your FreeBSD installation media. If you did
- not install <application>Samba</application> when you first
- installed FreeBSD, then you can install it from the <filename
+ be included on the &os; installation media. If they were
+ not installed when first
+ installing &os;, then they may be installed from the <filename
role="package">net/samba34</filename> port or package.</para>
<!-- mention LDAP, Active Directory, WinBIND, ACL, Quotas, PAM, .. -->
@@ -5186,8 +5555,8 @@ DocumentRoot /www/someotherdomain.tld
<para>The <filename>smb.conf</filename> file contains runtime
configuration information for
<application>Samba</application>, such as definitions of the
- printers and <quote>file system shares</quote> that you would
- like to share with &windows; clients. The
+ printers and <quote>file system shares</quote> that will
+ be shared with &windows; clients. The
<application>Samba</application> package includes a web based
tool called <application>swat</application> which provides a
simple way of configuring the <filename>smb.conf</filename>
@@ -5212,16 +5581,18 @@ DocumentRoot /www/someotherdomain.tld
reloaded after this configuration file is changed.</para>
<para>Once <application>swat</application> has been enabled in
- <filename>inetd.conf</filename>, you can use a browser to
- connect to <ulink url="http://localhost:901"></ulink>. You
- will first have to log on with the system
- <username>root</username> account.</para>
-
-<!-- XXX screenshots go here, loader is creating them -->
-
- <para>Once you have successfully logged on to the main
- <application>Samba</application> configuration page, you can
- browse the system documentation, or begin by clicking on the
+ <filename>inetd.conf</filename>, a web browser may be used to
+ connect to <ulink url="http://localhost:901"></ulink>. At
+ first login, the system
+ <username>root</username> account must be used.</para>
+
+<!-- XXX screenshots go here, loader is creating them
+ XXXTR: I'll believe it when I see it. -->
+
+ <para>Once successfully logging on to the main
+ <application>Samba</application> configuration page, the
+ system documentation will be available, or configuration may
+ begin by clicking on the
<guimenu>Globals</guimenu> tab. The
<guimenu>Globals</guimenu> section corresponds to the
variables that are set in the <literal>[global]</literal>
@@ -5232,9 +5603,9 @@ DocumentRoot /www/someotherdomain.tld
<sect3>
<title>Global Settings</title>
- <para>Whether you are using <application>swat</application> or
- editing <filename>/usr/local/etc/smb.conf</filename>
- directly, the first directives you are likely to encounter
+ <para>Whether <application>swat</application> is being used or
+ <filename>/usr/local/etc/smb.conf</filename> is being edited
+ directly, the first directives encountered
when configuring <application>Samba</application>
are:</para>
@@ -5288,14 +5659,14 @@ DocumentRoot /www/someotherdomain.tld
<listitem>
<para>The two most common options here are
<literal>security = share</literal> and
- <literal>security = user</literal>. If your clients
+ <literal>security = user</literal>. If the clients
use usernames that are the same as their usernames on
- your &os; machine then you will want to use user level
- security. This is the default security policy and it
+ the &os; machine then user level security should be
+ used. This is the default security policy and it
requires clients to first log on before they can
access shared resources.</para>
- <para>In share level security, client do not need to log
+ <para>In share level security, clients do not need to log
onto the server with a valid username and password
before attempting to connect to a shared resource.
This was the default security model for older versions
@@ -5312,8 +5683,8 @@ DocumentRoot /www/someotherdomain.tld
<indexterm><primary>SQL database</primary></indexterm>
<para><application>Samba</application> has several
- different backend authentication models. You can
- authenticate clients with LDAP, NIS+, a SQL database,
+ different backend authentication models. Clients may
+ be authenticated with LDAP, NIS+, an SQL database,
or a modified password file. The default
authentication method is <literal>smbpasswd</literal>,
and that is all that will be covered here.</para>
@@ -5325,8 +5696,8 @@ DocumentRoot /www/someotherdomain.tld
backend is used, the
<filename>/usr/local/etc/samba/smbpasswd</filename> file
must be created to allow <application>Samba</application> to
- authenticate clients. If you would like to give
- your &unix; user accounts access from &windows; clients, use
+ authenticate clients. To provide
+ the &unix; user accounts access from &windows; clients, use
the following command:</para>
<screen>&prompt.root; <userinput>smbpasswd -a username</userinput></screen>
@@ -5344,9 +5715,10 @@ DocumentRoot /www/someotherdomain.tld
url="http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/">Official
Samba HOWTO</ulink>
for additional information about configuration
- options. With the basics outlined here, you should have
- everything you need to start running
- <application>Samba</application>.</para>
+ options. With the basics outlined here, the minimal required
+ start running <application>Samba</application> will
+ be explained. Other documentation should be consulted in
+ addition to the information here.</para>
</sect3>
</sect2>
@@ -5386,16 +5758,17 @@ Starting smbd.</screen>
more information about using rc scripts.</para>
<para><application>Samba</application> actually consists of
- three separate daemons. You should see that both the
+ three separate daemons. Notice that both the
<application>nmbd</application> and
<application>smbd</application> daemons are started by the
- <filename>samba</filename> script. If you enabled winbind
- name resolution services in <filename>smb.conf</filename>,
- then you will also see that the
- <application>winbindd</application> daemon is started.</para>
+ <filename>samba</filename> script. If winbind,
+ name resolution services were enabled in
+ <filename>smb.conf</filename>,
+ the <application>winbindd</application> daemon will be
+ started as well.</para>
- <para>You can stop <application>Samba</application> at any time
- by typing :</para>
+ <para><application>Samba</application> may be stopped at any time
+ by typing:</para>
<screen>&prompt.root; <userinput>service samba stop</userinput></screen>
@@ -5426,7 +5799,7 @@ Starting smbd.</screen>
<title>Overview</title>
<para>Over time, a computer's clock is prone to drift. The
- Network Time Protocol (NTP) is one way to ensure your clock
+ Network Time Protocol (NTP) is one way to ensure the clock
stays accurate.</para>
<para>Many Internet services rely on, or greatly benefit from,
@@ -5443,11 +5816,11 @@ Starting smbd.</screen>
<primary>NTP</primary>
<secondary>ntpd</secondary>
</indexterm>
- <para>FreeBSD ships with the &man.ntpd.8; <acronym
+ <para>&os; ships with the &man.ntpd.8; <acronym
role="Network Time Protocol">NTP</acronym> server which can
be used to query other <acronym
role="Network Time Protocol">NTP</acronym> servers to set
- the clock on your machine or provide time
+ the clock on the machine or provide time
services to others.</para>
</sect2>
@@ -5459,27 +5832,27 @@ Starting smbd.</screen>
<secondary>choosing servers</secondary>
</indexterm>
- <para>In order to synchronize your clock, you will need to find
- one or more <acronym role="Network Time
- Protocol">NTP</acronym> servers to use. Your network
+ <para>In order to synchronize the clock, one or more
+ <acronym role="Network Time Protocol">NTP</acronym> servers
+ must be defined. The network
administrator or ISP may have set up an NTP server for this
purpose&mdash;check their documentation to see if this is the
case. There is an <ulink
url="http://support.ntp.org/bin/view/Servers/WebHome">online
- list of publicly accessible NTP servers</ulink> which you can
- use to find an NTP server near to you. Make sure you are
- aware of the policy for any servers you choose, and ask for
- permission if required.</para>
+ list of publicly accessible NTP servers</ulink> which may be
+ referenced to find an NTP server nearest to the system.
+ Take care to review the policy for any chosen servers, and ask
+ for permission if required.</para>
<para>Choosing several unconnected NTP servers is a good idea in
- case one of the servers you are using becomes unreachable or
+ case one of the servers being used becomes unreachable or
its clock is unreliable. &man.ntpd.8; uses the responses it
receives from other servers intelligently&mdash;it will favor
unreliable servers less than reliable ones.</para>
</sect2>
<sect2>
- <title>Configuring Your Machine</title>
+ <title>Configuring The Machine</title>
<indexterm>
<primary>NTP</primary>
@@ -5491,8 +5864,8 @@ Starting smbd.</screen>
<indexterm><primary>ntpdate</primary></indexterm>
- <para>If you only wish to synchronize your clock when the
- machine boots up, you can use &man.ntpdate.8;. This may be
+ <para>To synchronize the clock only when the
+ machine boots up, use &man.ntpdate.8;. This may be
appropriate for some desktop machines which are frequently
rebooted and only require infrequent synchronization, but
most machines should run &man.ntpd.8;.</para>
@@ -5505,8 +5878,8 @@ Starting smbd.</screen>
<para>To enable &man.ntpdate.8; at boot time, add
<literal>ntpdate_enable="YES"</literal> to
- <filename>/etc/rc.conf</filename>. You will also need to
- specify all servers you wish to synchronize with and any
+ <filename>/etc/rc.conf</filename>. Also
+ specify all synchronization servers and any
flags to be passed to &man.ntpdate.8; in
<varname>ntpdate_flags</varname>.</para>
</sect3>
@@ -5552,7 +5925,7 @@ driftfile /var/db/ntp.drift</programlisting>
<para>The <literal>driftfile</literal> option specifies which
file is used to store information about previous responses
- from the NTP servers you are using. This file contains
+ from the NTP servers being used. This file contains
internal information for NTP. It should not be modified by
any other process.</para>
</sect3>
@@ -5560,27 +5933,27 @@ driftfile /var/db/ntp.drift</programlisting>
<sect3>
<title>Controlling Access to Your Server</title>
- <para>By default, your NTP server will be accessible to all
+ <para>By default, the NTP server will be accessible to all
hosts on the Internet. The <literal>restrict</literal>
- option in <filename>/etc/ntp.conf</filename> allows you to
- control which machines can access your server.</para>
+ option in <filename>/etc/ntp.conf</filename>
+ controls which machines can access the server.</para>
- <para>If you want to deny all machines from accessing your NTP
+ <para>To deny all machines from accessing the NTP
server, add the following line to
<filename>/etc/ntp.conf</filename>:</para>
<programlisting>restrict default ignore</programlisting>
<note>
- <para>This will also prevent access from your server to
- any servers listed in your local configuration. If you
- need to synchronise your NTP server with an external NTP
- server you should allow the specific server. See the
+ <para>This will also prevent access from the server to
+ any servers listed in the local configuration. If there is
+ a need to synchronise the NTP server with an external NTP
+ server, allow only that specific server. See the
&man.ntp.conf.5; manual for more information.</para>
</note>
- <para>If you only want to allow machines within your own
- network to synchronize their clocks with your server, but
+ <para>To allow machines within the
+ network to synchronize their clocks with the server, but
ensure they are not allowed to configure the server or used
as peers to synchronize against, add</para>
@@ -5588,14 +5961,14 @@ driftfile /var/db/ntp.drift</programlisting>
<para>instead, where <hostid
role="ipaddr">192.168.1.0</hostid> is an IP address on
- your network and <hostid
- role="netmask">255.255.255.0</hostid> is your network's
+ the network and <hostid
+ role="netmask">255.255.255.0</hostid> is the network's
netmask.</para>
- <para><filename>/etc/ntp.conf</filename> can contain multiple
- <literal>restrict</literal> options. For more details, see
- the <literal>Access Control Support</literal> subsection of
- &man.ntp.conf.5;.</para>
+ <para>The <filename>/etc/ntp.conf</filename> file can contain
+ multiple <literal>restrict</literal> options. For more
+ details, see the <literal>Access Control Support</literal>
+ subsection of &man.ntp.conf.5;.</para>
</sect3>
</sect2>
@@ -5604,12 +5977,12 @@ driftfile /var/db/ntp.drift</programlisting>
<para>To ensure the NTP server is started at boot time, add the
line <literal>ntpd_enable="YES"</literal> to
- <filename>/etc/rc.conf</filename>. If you wish to pass
+ <filename>/etc/rc.conf</filename>. To pass
additional flags to &man.ntpd.8;, edit the
<varname>ntpd_flags</varname> parameter in
<filename>/etc/rc.conf</filename>.</para>
- <para>To start the server without rebooting your machine, run
+ <para>To start the server without rebooting the machine, run
<command>ntpd</command> being sure to specify any additional
parameters from <varname>ntpd_flags</varname> in
<filename>/etc/rc.conf</filename>. For example:</para>
@@ -5623,10 +5996,10 @@ driftfile /var/db/ntp.drift</programlisting>
<para>The &man.ntpd.8; program does not need a permanent
connection to the Internet to function properly. However, if
- you have a temporary connection that is configured to dial out
+ there is a temporary connection that is configured to dial out
on demand, it is a good idea to prevent NTP traffic from
- triggering a dial out or keeping the connection alive. If you
- are using user PPP, you can use <literal>filter</literal>
+ triggering a dial out or keeping the connection alive. PPP
+ users can use the <literal>filter</literal>
directives in <filename>/etc/ppp/ppp.conf</filename>. For
example:</para>
@@ -5646,7 +6019,7 @@ driftfile /var/db/ntp.drift</programlisting>
<note>
<para>Some Internet access providers block low-numbered ports,
preventing NTP from functioning since replies never
- reach your machine.</para>
+ reach the machine.</para>
</note>
</sect2>
@@ -5682,7 +6055,7 @@ driftfile /var/db/ntp.drift</programlisting>
<para>Centralized logging to a specific logging host can reduce
some of the administrative burden of log file administration.
- Log file aggregation, merging and rotation can be configured in
+ Log file aggregation, merging and rotation may be configured in
one location, using the native tools of &os;, such as
&man.syslogd.8; and &man.newsyslog.8;. In the following example
configuration, host <hostid>A</hostid>, named <hostid
@@ -5716,15 +6089,15 @@ driftfile /var/db/ntp.drift</programlisting>
</listitem>
<listitem>
- <para>syslogd has been configured to accept remote messages
- from client machines;</para>
+ <para><command>syslogd</command> has been configured to
+ accept remote messages from client machines;</para>
</listitem>
<listitem>
- <para>The syslogd server and all client machines must have
- valid entries for both forward and reverse
- <acronym>DNS</acronym>, or be properly configured in
- <filename>/etc/hosts</filename>.</para>
+ <para>The <command>syslogd</command> server and all client
+ machines must have valid entries for both forward and
+ reverse <acronym>DNS</acronym>, or be properly configured
+ in <filename>/etc/hosts</filename>.</para>
</listitem>
</itemizedlist>
@@ -5770,13 +6143,14 @@ syslogd_flags="-a logclient.example.com -v -v"</programlisting>
does not matter, but &man.touch.1; works great for situations
such as this:</para>
- <screen>&prompt.root; <userinput>touch <filename>/var/log/logclient.log</filename></userinput></screen>
+ <screen>&prompt.root; <userinput><command>touch</command>
+ <filename>/var/log/logclient.log</filename></userinput></screen>
<para>At this point, the <command>syslogd</command> daemon
should be restarted and verified:</para>
- <screen>&prompt.root; <userinput>service syslogd restart</userinput>
-&prompt.root; <userinput>pgrep syslog</userinput></screen>
+ <screen>&prompt.root; <userinput>service <command>syslogd</command> restart</userinput>
+&prompt.root; <userinput><command>pgrep</command> syslog</userinput></screen>
<para>If a <acronym>PID</acronym> is returned, the server has
been restarted successfully, and client configuration may
@@ -5851,13 +6225,14 @@ syslogd_flags="-s -v -v"</programlisting>
<para>Once added, <command>syslogd</command> must be restarted
for the changes to take effect:</para>
- <screen>&prompt.root; <userinput>service syslogd restart</userinput></screen>
+ <screen>&prompt.root; <userinput>service <command>syslogd</command> restart</userinput></screen>
<para>To test that log messages are being sent across the
network, use &man.logger.1; on the client to send a message to
<command>syslogd</command>:</para>
- <screen>&prompt.root; <userinput>logger "<replaceable>Test message from logclient</replaceable>"</userinput></screen>
+ <screen>&prompt.root; <userinput><command>logger</command>
+ "<replaceable>Test message from logclient</replaceable>"</userinput></screen>
<para>This message should now exist both in
<filename>/var/log/messages</filename> on the client, and
@@ -5888,7 +6263,7 @@ syslogd_flags="-s -v -v"</programlisting>
<programlisting>syslogd_flags="-d -a logclien.example.com -v -v"</programlisting>
- <screen>&prompt.root; <userinput>service syslogd restart</userinput></screen>
+ <screen>&prompt.root; <userinput>service <command>syslogd</command> restart</userinput></screen>
<para>Debugging data similar to the following will flash on the
screen immediately after the restart:</para>
@@ -5913,7 +6288,7 @@ rejected in rule 0 due to name mismatch.</screen>
<literal>logclien</literal>. After the proper alterations
are made, a restart is issued with expected results:</para>
- <screen>&prompt.root; <userinput>service syslogd restart</userinput>
+ <screen>&prompt.root; <userinput>service <command>syslogd</command> restart</userinput>
logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
syslogd: restarted
logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel