First 1/2 of syslogd section.

Tighten wording and clarify unclear bits.

Sponsored by: iXsystems

en_US.ISO8859-1/books/handbook/network-servers/chapter.xml

@@ -5422,117 +5422,99 @@ driftfile /var/db/ntp.drift</programlisting>
 
     <para>Interacting with system logs is a crucial aspect of both
       security and system administration.  Monitoring the log files of
-      multiple hosts can get very unwieldy when these hosts are
-      distributed across medium or large networks, or when they are
-      parts of various different types of networks.  In these cases,
-      configuring remote logging may make the whole process a lot more
-      comfortable.</para>
-
-    <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 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 <systemitem>A</systemitem>, named
+      multiple hosts can become unwieldy as the number of systems increases.
+      Configuring centralized logging can reduce
+      some of the administrative burden of log file administration.</para>
+      
+    <para>Centralized log file aggregation, merging, and rotation can be configured
+      using &os; native tools, such as
+      &man.syslogd.8; and &man.newsyslog.8;.  This section demonstrates an example
+      configuration, where host <systemitem>A</systemitem>, named
       <systemitem
 	class="fqdomainname">logserv.example.com</systemitem>, will
       collect logging information for the local network.  Host
       <systemitem>B</systemitem>, named <systemitem
-	class="fqdomainname">logclient.example.com</systemitem> will
-      pass logging information to the server system.  In live
-      configurations, both hosts require proper forward and reverse
-      <acronym>DNS</acronym> or entries in
-      <filename>/etc/hosts</filename>.  Otherwise, data will be
-      rejected by the server.</para>
+	class="fqdomainname">logclient.example.com</systemitem>, will be configured to
+      pass logging information to the logging server.</para>
 
     <sect2>
       <title>Log Server Configuration</title>
 
-      <para>Log servers are machines configured to accept logging
-	information from remote hosts.  In most cases this is to ease
-	configuration, in other cases it may just be a better
-	administration move.  Regardless of reason, there are a few
-	requirements before continuing.</para>
-
-      <para>A properly configured logging server has met the following
-	minimal requirements:</para>
+      <para>A log server is a system that has been configured to accept logging
+	information from other hosts.  Before configuring a log server, check the following:</para>
 
       <itemizedlist>
 	<listitem>
-	  <para>The firewall ruleset allows for <acronym>UDP</acronym>
-	    to be passed on port 514 on both the client and
-	    server;</para>
+	  <para>If there is a firewall between the logging server and
+	    any logging clients, ensure that the firewall ruleset allows <acronym>UDP</acronym>
+	    port 514 for both the clients and the
+	    server.</para>
 	</listitem>
 
 	<listitem>
-	  <para><command>syslogd</command> has been configured to
-	    accept remote messages from client machines;</para>
-	</listitem>
-
-	<listitem>
-	  <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>
+	  <para>The logging server and all client
+	    machines must have forward and reverse entries in
+      the local <acronym>DNS</acronym>.  If the network does not have 
+      a <acronym>DNS</acronym> server, create entries in each system's
+      <filename>/etc/hosts</filename>.  Proper name resolution is required
+      so that log entries are not rejected by the logging server.</para>
 	</listitem>
       </itemizedlist>
 
-      <para>To configure the log server, the client must be listed
-	in <filename>/etc/syslog.conf</filename>, and the logging
-	facility must be specified:</para>
+      <para>On the log server, edit 
+	<filename>/etc/syslog.conf</filename> to specify the name of
+	the client to receive log entries from, the logging
+	facility to be used, and the name of the log to store the
+	host's log entries.  This example adds the hostname of
+	<systemitem>B</systemitem>, logs all facilities, and stores
+	the log entries in <filename>/var/log/logclient.log</filename>.</para>
+
+      <example>
+	<title>Sample Log Server Configuration</title>
 
       <programlisting>+logclient.example.com
 *.*     /var/log/logclient.log</programlisting>
+      </example>
 
-      <note>
-	<para>More information on various supported and available
-	  <emphasis>facilities</emphasis> may be found in
+	<para>When adding multiple log clients, add a similar two-line entry
+	  for each client.  More information about the available
+	  facilities may be found in
 	  &man.syslog.conf.5;.</para>
-      </note>
 
-      <para>Once added, all <literal>facility</literal> messages will
-	be logged to the file specified previously,
-	<filename>/var/log/logclient.log</filename>.</para>
-
-      <para>The server machine must also have the following listing
-	placed inside <filename>/etc/rc.conf</filename>:</para>
+      <para>Next, configure <filename>/etc/rc.conf</filename>:</para>
 
       <programlisting>syslogd_enable="YES"
 syslogd_flags="-a logclient.example.com -v -v"</programlisting>
 
-      <para>The first option will enable the
-	<command>syslogd</command> daemon on boot up, and the second
-	option allows data from the specified client to be accepted on
-	this server.  The latter part, using <option>-v -v</option>,
-	will increase the verbosity of logged messages.  This is
-	extremely useful for tweaking facilities as administrators are
-	able to see what type of messages are being logged under which
+      <para>The first entry starts
+	<application>syslogd</application> at system boot.  The second
+	entry allows log entries from the specified client.
+	The <option>-v -v</option>
+	increases the verbosity of logged messages.  This is
+	useful for tweaking facilities as administrators are
+	able to see what type of messages are being logged under each
 	facility.</para>
 
       <para>Multiple <option>-a</option> options may be specified to
 	allow logging from multiple clients.  <acronym>IP</acronym>
 	addresses and whole netblocks may also be specified.  Refer to
-	&man.syslog.3; for a full list of possible
+	&man.syslogd.8; for a full list of possible
 	options.</para>
 
-      <para>Finally, the log file should be created.  The method used
-	does not matter, but &man.touch.1; works great for situations
-	such as this:</para>
+      <para>Finally, create the log file:</para>
 
-      <screen>&prompt.root; <userinput>touch
-        /var/log/logclient.log</userinput></screen>
+      <screen>&prompt.root; <userinput>touch /var/log/logclient.log</userinput></screen>
 
-      <para>At this point, the <command>syslogd</command> daemon
+      <para>At this point, <application>syslogd</application>
 	should be restarted and verified:</para>
 
       <screen>&prompt.root; <userinput>service syslogd restart</userinput>
 &prompt.root; <userinput>pgrep syslog</userinput></screen>
 
-      <para>If a <acronym>PID</acronym> is returned, the server has
-	been restarted successfully, and client configuration may
-	begin.  If the server has not restarted, consult the
-	<filename>/var/log/messages</filename> log for any
-	output.</para>
+      <para>If a <acronym>PID</acronym> is returned, the server
+	restarted successfully, and client configuration can
+	begin.  If the server did not restart, consult
+	<filename>/var/log/messages</filename> for the error.</para>
     </sect2>
 
     <sect2>