Finish syslogd section.

Clarify examples.

Sponsored by: iXsystems

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

@@ -5520,80 +5520,43 @@ syslogd_flags="-a logclient.example.com -v -v"</programlisting>
     <sect2>
       <title>Log Client Configuration</title>
 
-      <para>A logging client is a machine which sends log information
+      <para>A logging client sends log entries
-	to a logging server in addition to keeping local
+	to a logging server on the network.  The client also keeps a local
-	copies.</para>
+	copy of its own logs.</para>
 
-      <para>Similar to log servers, clients must also meet a few
+      <para>Once a logging server has been configured, edit
-	minimum requirements:</para>
+	<filename>/etc/rc.conf</filename> on the logging client:</para>
-
-      <itemizedlist>
-	<listitem>
-	  <para>&man.syslogd.8; must be configured to send messages of
-	    specific types to a log server, which must accept
-	    them;</para>
-	</listitem>
-
-	<listitem>
-	  <para>The firewall must allow <acronym>UDP</acronym> packets
-	    through on port 514;</para>
-	</listitem>
-
-	<listitem>
-	  <para>Both forward and reverse <acronym>DNS</acronym> must
-	    be configured or have proper entries in the
-	    <filename>/etc/hosts</filename>.</para>
-	</listitem>
-      </itemizedlist>
-
-      <para>Client configuration is a bit more relaxed when compared
-	to that of the servers.  The client machine must have the
-	following listing placed inside
-	<filename>/etc/rc.conf</filename>:</para>
 
       <programlisting>syslogd_enable="YES"
 syslogd_flags="-s -v -v"</programlisting>
 
-      <para>As before, these entries will enable the
+      <para>The first entry enables
-	<command>syslogd</command> daemon on boot up, and increases
+	<application>syslogd</application> on boot up.  The second entry
-	the verbosity of logged messages.  The <option>-s</option>
+	prevents logs from being accepted by this client from
-	option prevents logs from being accepted by this client from
+	other hosts (<option>-s</option>) and increases
-	other hosts.</para>
+	the verbosity of logged messages.</para>
 
-      <para>Facilities describe the system part for which a message
+      <para>Next, define the logging server in the client's
-	is generated.  For an example, <acronym>ftp</acronym> and
+	<filename>/etc/syslog.conf</filename>.  In this example, all
-	<acronym>ipfw</acronym> are both facilities.  When log
+	logged facilities are sent to a remote system, denoted by 
-	messages are generated for those two services, they will
+	the <literal>@</literal> symbol,
-	normally include those two utilities in any log messages.
+	with the specified hostname:</para>
-	Facilities are accompanied with a priority or level, which
-	is used to mark how important a log message is.  The most
-	common will be the <literal>warning</literal> and
-	<literal>info</literal>.  Refer to &man.syslog.3;
-	for a full list of available facilities and
-	priorities.</para>
-
-      <para>The logging server must be defined in the client's
-	<filename>/etc/syslog.conf</filename>.  In this instance,
-	the <literal>@</literal> symbol is used to send logging
-	data to a remote server and would look similar to the
-	following entry:</para>
 
       <programlisting>*.*		@logserv.example.com</programlisting>
 
-      <para>Once added, <command>syslogd</command> must be restarted
+      <para>After saving the edit, restart <application>syslogd</application>
 	for the changes to take effect:</para>
 
       <screen>&prompt.root; <userinput>service syslogd 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>
+	<application>syslogd</application>:</para>
 
-      <screen>&prompt.root; <userinput>logger
+      <screen>&prompt.root; <userinput>logger "Test message from logclient"</userinput></screen>
-        "Test message from logclient"</userinput></screen>
 
       <para>This message should now exist both in
-	<filename>/var/log/messages</filename> on the client, and
+	<filename>/var/log/messages</filename> on the client and
 	<filename>/var/log/logclient.log</filename> on the
 	log server.</para>
     </sect2>
@@ -5601,30 +5564,33 @@ syslogd_flags="-s -v -v"</programlisting>
     <sect2>
       <title>Debugging Log Servers</title>
 
-      <para>In certain cases, debugging may be required if messages
+      <para>If no messages are
-	are not being received on the log server.  There are several
+	being received on the log server, the cause is most likely a
-	reasons this may occur; however, the most common two are
+	network connectivity issue, a hostname resolution issue, or a typo in a configuration file.
-	network connection issues and <acronym>DNS</acronym> issues.
+	To isolate the cause, ensure that both the logging server and the logging client are able to <command>ping</command>
-	To test these cases, ensure both hosts are able to reach one
+	each other using the hostname specified in their
-	another using the hostname specified in
+	<filename>/etc/rc.conf</filename>.  If this fails, check the
-	<filename>/etc/rc.conf</filename>.  If this appears to be
+	network cabling, the firewall ruleset, and the hostname entries
-	working properly, an alternation to the
+	in the <acronym>DNS</acronym> server or
-	<literal>syslogd_flags</literal> option in
+	<filename>/etc/hosts</filename> on both the logging server and
-	<filename>/etc/rc.conf</filename> will be required.</para>
+	clients.  Repeat until the <command>ping</command> is
+	successful from both hosts.</para>
 
-      <para>In the following example,
+      <para>If the <command>ping</command> succeeds on both hosts but
-	<filename>/var/log/logclient.log</filename> is empty, and the
+	log messages are still not being received, temporarily
-	<filename>/var/log/messages</filename> files indicate no
+	increase logging verbosity to narrow down the configuration
-	reason for the failure.  To increase debugging output, change
+	issue. In the following example,
-	the <literal>syslogd_flags</literal> option to look like the
+	<filename>/var/log/logclient.log</filename> on the logging server is empty and
-	following example, and issue a restart:</para>
+	<filename>/var/log/messages</filename> on the logging client does not indicate a
+	reason for the failure.  To increase debugging output, edit the
+	<literal>syslogd_flags</literal> entry on the logging server and issue a restart:</para>
 
       <programlisting>syslogd_flags="-d -a logclien.example.com -v -v"</programlisting>
 
       <screen>&prompt.root; <userinput>service syslogd restart</userinput></screen>
 
       <para>Debugging data similar to the following will flash on the
-	screen immediately after the restart:</para>
+	console immediately after the restart:</para>
 
       <screen>logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
 syslogd: restarted
@@ -5635,16 +5601,11 @@ cvthname(192.168.1.10)
 validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
 rejected in rule 0 due to name mismatch.</screen>
 
-      <para>It appears obvious the messages are being rejected due
+      <para>In this example, the log messages are being rejected due to a
-	to a name mismatch.  After reviewing the configuration bit
+	typo which results in
-	by bit, it appears a typo in the following
+	a hostname mismatch.  The client's hostname should be <literal>logclient</literal>, not
-	<filename>/etc/rc.conf</filename> line has an issue:</para>
+	<literal>logclien</literal>.  Fix the typo, issue
-
+	a restart, and verify the results:</para>
-      <programlisting>syslogd_flags="-d -a logclien.example.com -v -v"</programlisting>
-
-      <para>The line should contain <literal>logclient</literal>, not
-	<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>
 logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
@@ -5668,24 +5629,25 @@ Logging to FILE /var/log/messages</screen>
       <title>Security Considerations</title>
 
       <para>As with any network service, security requirements should
-	be considered before implementing this configuration.  At
+	be considered before implementing a logging server.
-	times, log files may contain sensitive data about services
+	Log files may contain sensitive data about services
 	enabled on the local host, user accounts, and configuration
 	data.  Network data sent from the client to the server will
-	not be encrypted nor password protected.  If a need for
+	not be encrypted or password protected.  If a need for
-	encryption exists, it might be possible to use
+	encryption exists, consider using
 	<package>security/stunnel</package>, which
-	will transmit data over an encrypted tunnel.</para>
+	will transmit the logging data over an encrypted tunnel.</para>
 
       <para>Local security is also an issue.  Log files are not
 	encrypted during use or after log rotation.  Local users may
-	access these files to gain additional insight on system
+	access log files to gain additional insight into system
-	configuration.  In those cases, setting proper permissions
+	configuration.  Setting proper permissions
-	on these files will be critical.  The &man.newsyslog.8;
+	on log files is critical.  The built-in log rotator, &man.newsyslog.8;,
-	utility supports setting permissions on newly created and
+	supports setting permissions on newly created and
 	rotated log files.  Setting log files to mode
-	<literal>600</literal> should prevent any unwanted snooping
+	<literal>600</literal> should prevent unwanted access
-	by local users.</para>
+	by local users.  Refer to &man.newsyslog.conf.5; for
+	additional information.</para>
     </sect2>
   </sect1>