Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Mar 2014 21:22:34 +0000 (UTC)
From:      Dru Lavigne <dru@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r44346 - head/en_US.ISO8859-1/books/handbook/config
Message-ID:  <201403242122.s2OLMYGM003696@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: dru
Date: Mon Mar 24 21:22:33 2014
New Revision: 44346
URL: http://svnweb.freebsd.org/changeset/doc/44346

Log:
  White space fix only. Translators can ignore.
  
  Sponsored by:	iXsystems

Modified:
  head/en_US.ISO8859-1/books/handbook/config/chapter.xml

Modified: head/en_US.ISO8859-1/books/handbook/config/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/config/chapter.xml	Mon Mar 24 20:55:36 2014	(r44345)
+++ head/en_US.ISO8859-1/books/handbook/config/chapter.xml	Mon Mar 24 21:22:33 2014	(r44346)
@@ -568,8 +568,8 @@ sshd is running as pid 433.</screen>
 
       <para>A number of strategies may be applied in clustered
 	applications to separate site-wide configuration from
-	system-specific configuration in order to reduce administration
-	overhead.  The recommended approach is to place
+	system-specific configuration in order to reduce
+	administration overhead.  The recommended approach is to place
 	system-specific configuration into
 	<filename>/etc/rc.conf.local</filename>.  For example, these
 	entries in <filename>/etc/rc.conf</filename> apply to all
@@ -587,9 +587,10 @@ defaultrouter="10.1.1.254"</programlisti
 ifconfig_fxp0="inet 10.1.1.1/8"</programlisting>
 
       <para>Distribute <filename>/etc/rc.conf</filename> to every
-	system using an application such as <application>rsync</application> or
-	<application>puppet</application>,
-	while <filename>/etc/rc.conf.local</filename> remains
+	system using an application such as
+	<application>rsync</application> or
+	<application>puppet</application>, while
+	<filename>/etc/rc.conf.local</filename> remains
 	unique.</para>
 
       <para>Upgrading the system will not overwrite
@@ -1202,7 +1203,7 @@ ifconfig_fxp0_alias7="inet 202.0.75.20 n
 
   <sect1 xml:id="configtuning-syslog">
     <info>
-      <title>Configuring System Logging</title>
+    <title>Configuring System Logging</title>
 
       <authorgroup>
 	<author>
@@ -1225,26 +1226,28 @@ ifconfig_fxp0_alias7="inet 202.0.75.20 n
       <primary>&man.syslogd.8;</primary>
     </indexterm>
 
-    <para>Generating and reading system logs is an important aspect of system
-      administration.  The information in system logs can be used to detect hardware and software
-      issues as well as application and system configuration errors.  This information also plays an important role
-      in security auditing and incident response.  Most system daemons
-      and applications will generate log entries.</para>
+    <para>Generating and reading system logs is an important aspect of
+      system administration.  The information in system logs can be
+      used to detect hardware and software issues as well as
+      application and system configuration errors.  This information
+      also plays an important role in security auditing and incident
+      response.  Most system daemons and applications will generate
+      log entries.</para>
 
     <para>&os; provides a system logger,
       <application>syslogd</application>, to manage logging.  By
-      default, <application>syslogd</application> is
-	started when the system boots.  This is controlled by the variable
-	<literal>syslogd_enable</literal> in
-	<filename>/etc/rc.conf</filename>.  There are numerous
-	application arguments that can be set using
-	<literal>syslogd_flags</literal> in
-	<filename>/etc/rc.conf</filename>.  Refer to &man.syslogd.8;
-	for more information on the available arguments.</para>
-
-    <para>This section describes how to configure the &os;
-      system logger for both local and remote logging and how to perform log rotation
-      and log management.</para>
+      default, <application>syslogd</application> is started when the
+      system boots.  This is controlled by the variable
+      <literal>syslogd_enable</literal> in
+      <filename>/etc/rc.conf</filename>.  There are numerous
+      application arguments that can be set using
+      <literal>syslogd_flags</literal> in
+      <filename>/etc/rc.conf</filename>.  Refer to &man.syslogd.8; for
+      more information on the available arguments.</para>
+
+    <para>This section describes how to configure the &os; system
+      logger for both local and remote logging and how to perform log
+      rotation and log management.</para>
 
     <sect2>
       <title>Configuring Local Logging</title>
@@ -1253,29 +1256,29 @@ ifconfig_fxp0_alias7="inet 202.0.75.20 n
 
       <para>The configuration file,
 	<filename>/etc/syslog.conf</filename>, controls what
-	<application>syslogd</application> does with log entries as they are
-	received.  There are several parameters to control the
-	handling of incoming events.
-	The <firstterm>facility</firstterm> describes
-	which subsystem generated the message, such as the kernel or a
-	daemon, and the <firstterm>level</firstterm> describes the severity of the event that
-	occurred.  This makes it possible to configure if and where a log message is
-	logged, depending on the facility
+	<application>syslogd</application> does with log entries as
+	they are received.  There are several parameters to control
+	the handling of incoming events.  The
+	<firstterm>facility</firstterm> describes which subsystem
+	generated the message, such as the kernel or a daemon, and the
+	<firstterm>level</firstterm> describes the severity of the
+	event that occurred.  This makes it possible to configure if
+	and where a log message is logged, depending on the facility
 	and level.  It is also possible to take action depending on
 	the application that sent the message, and in the case of
-	remote logging, the hostname of the machine generating
-	the logging event.</para>
+	remote logging, the hostname of the machine generating the
+	logging event.</para>
 
-      <para>This configuration file contains one
-	line per action, where the syntax for each line is a selector
-	field followed by an action field.  The syntax of the selector
-	field is <replaceable>facility.level</replaceable> which will
-	match log messages from <replaceable>facility</replaceable>
-	at level <replaceable>level</replaceable> or higher.  It is
-	also possible to add an optional comparison flag before the
-	level to specify more precisely what is logged.  Multiple
-	selector fields can be used for the same action, and are
-	separated with a semicolon (<literal>;</literal>).  Using
+      <para>This configuration file contains one line per action,
+	where the syntax for each line is a selector field followed by
+	an action field.  The syntax of the selector field is
+	<replaceable>facility.level</replaceable> which will match log
+	messages from <replaceable>facility</replaceable> at level
+	<replaceable>level</replaceable> or higher.  It is also
+	possible to add an optional comparison flag before the level
+	to specify more precisely what is logged.  Multiple selector
+	fields can be used for the same action, and are separated with
+	a semicolon (<literal>;</literal>).  Using
 	<literal>*</literal> will match everything.  The action field
 	denotes where to send the log message, such as to a file or
 	remote log host.  As an example, here is the default
@@ -1292,7 +1295,7 @@ ifconfig_fxp0_alias7="inet 202.0.75.20 n
 *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err   /var/log/messages
 security.*                                      /var/log/security
 auth.info;authpriv.info                         /var/log/auth.log
-mail.info                                       /var/log/maillog 
+mail.info                                       /var/log/maillog
 lpr.info                                        /var/log/lpd-errs
 ftp.info                                        /var/log/xferlog
 cron.*                                          /var/log/cron
@@ -1312,15 +1315,15 @@ cron.*                                  
 # news.notice                                   /var/log/news/news.notice
 # Uncomment this if you wish to see messages produced by devd
 # !devd
-# *.>=info  
+# *.>=info
 !ppp
 *.*                                             /var/log/ppp.log
 !*</programlisting>
 
       <para>In this example:</para>
 
-	<itemizedlist>
-	  <listitem>
+      <itemizedlist>
+	<listitem>
 	  <para>Line 8 matches all messages with a level of
 	    <literal>err</literal> or higher, as well as
 	    <literal>kern.warning</literal>,
@@ -1328,38 +1331,37 @@ cron.*                                  
 	    <literal>mail.crit</literal>, and sends these log messages
 	    to the console
 	    (<filename>/dev/console</filename>).</para>
-	  </listitem>
+	</listitem>
 
 	<listitem>
-	  <para>Line 12 matches all messages from the <literal>mail</literal>
-	    facility at level <literal>info</literal> or above and
-	    logs the messages to
+	  <para>Line 12 matches all messages from the
+	    <literal>mail</literal> facility at level
+	    <literal>info</literal> or above and logs the messages to
 	    <filename>/var/log/maillog</filename>.</para>
-	  </listitem>
+	</listitem>
 
 	<listitem>
 	  <para>Line 17 uses a comparison flag (<literal>=</literal>)
 	    to only match messages at level <literal>debug</literal>
 	    and logs them to
 	    <filename>/var/log/debug.log</filename>.</para>
-	  </listitem>
+	</listitem>
 
 	<listitem>
 	  <para>Line 33 is an example usage of a program
-	      specification.  This makes the rules
-	    following it only valid for the specified program.
-	    In this case, only the
+	    specification.  This makes the rules following it only
+	    valid for the specified program.  In this case, only the
 	    messages generated by <application>ppp</application> are
-	    logged to
-	    <filename>/var/log/ppp.log</filename>.</para>
-	  </listitem>
-	</itemizedlist>
+	    logged to <filename>/var/log/ppp.log</filename>.</para>
+	</listitem>
+      </itemizedlist>
 
       <para>The available levels, in order from most to least
-	critical are <literal>emerg</literal>, <literal>alert</literal>,
-	<literal>crit</literal>, <literal>err</literal>,
-	<literal>warning</literal>, <literal>notice</literal>,
-	<literal>info</literal>, and <literal>debug</literal>.</para>
+	critical are <literal>emerg</literal>,
+	<literal>alert</literal>, <literal>crit</literal>,
+	<literal>err</literal>, <literal>warning</literal>,
+	<literal>notice</literal>, <literal>info</literal>, and
+	<literal>debug</literal>.</para>
 
       <para>The facilities, in no particular order, are
 	<literal>auth</literal>, <literal>authpriv</literal>,
@@ -1373,10 +1375,9 @@ cron.*                                  
 	<literal>local7</literal>.  Be aware that other operating
 	systems might have different facilities.</para>
 
-      <para>To log everything
-	of level <literal>notice</literal> and
-	higher to <filename>/var/log/daemon.log</filename>, add
-	the following entry:</para>
+      <para>To log everything of level <literal>notice</literal> and
+	higher to <filename>/var/log/daemon.log</filename>, add the
+	following entry:</para>
 
       <programlisting>daemon.notice                                        /var/log/daemon.log</programlisting>
 
@@ -1395,30 +1396,30 @@ cron.*                                  
       <indexterm><primary>log rotation</primary></indexterm>
       <indexterm><primary>log management</primary></indexterm>
 
-      <para>Log files can grow quickly, taking up disk space and 
-	making it more difficult to locate useful
-	information.  Log management
-	attempts to mitigate this.  In &os;, <application>newsyslog</application> is used
-	to manage log files.  This built-in program periodically rotates and
+      <para>Log files can grow quickly, taking up disk space and
+	making it more difficult to locate useful information.  Log
+	management attempts to mitigate this.  In &os;,
+	<application>newsyslog</application> is used to manage log
+	files.  This built-in program periodically rotates and
 	compresses log files, and optionally creates missing log files
 	and signals programs when log files are moved.  The log files
-	may be generated by <application>syslogd</application> or
-	by any other program which generates log files.
-	While <application>syslogd</application> is normally run from
+	may be generated by <application>syslogd</application> or by
+	any other program which generates log files.  While
+	<application>syslogd</application> is normally run from
 	&man.cron.8;, it is not a system daemon.  In the default
 	configuration, it runs every hour.</para>
 
-	<para>To know which actions to take, <application>newsyslog</application> reads
-	  its configuration file,
-	  <filename>/etc/newsyslog.conf</filename>.  This
-	  file contains one line for each log file that
-	  <application>newsyslog</application> manages.  Each line states the file
-	  owner, permissions, when to rotate that file, optional flags
-	  that affect log rotation, such as compression, and programs
-	  to signal when the log is rotated.  Here is the default
-	  configuration in &os;:</para>
+      <para>To know which actions to take,
+	<application>newsyslog</application> reads its configuration
+	file, <filename>/etc/newsyslog.conf</filename>.  This file
+	contains one line for each log file that
+	<application>newsyslog</application> manages.  Each line
+	states the file owner, permissions, when to rotate that file,
+	optional flags that affect log rotation, such as compression,
+	and programs to signal when the log is rotated.  Here is the
+	default configuration in &os;:</para>
 
-	<programlisting># configuration file for newsyslog
+      <programlisting># configuration file for newsyslog
 # $FreeBSD$
 #
 # Entries which do not specify the '/pid_file' field will cause the
@@ -1458,36 +1459,33 @@ cron.*                                  
 /var/log/weekly.log                     640  5     1    $W6D0 JN
 /var/log/xferlog                        600  7     100  *     JC</programlisting>
 
-	<para>Each line starts with the name of the log to be
-	  rotated, optionally followed by an owner and group for both
-	  rotated and newly created files.  The
-	  <literal>mode</literal> field sets the permissions on the
-	  log file and <literal>count</literal> denotes how many
-	  rotated log files should be kept.  The
-	  <literal>size</literal> and <literal>when</literal> fields
-	  tell <application>newsyslog</application> when to rotate the file.  A log
-	  file is rotated when either its size is larger than the
-	  <literal>size</literal> field or when the time in the
-	  <literal>when</literal> filed has passed.
-	  An asterisk (<literal>*</literal>) means that this field is ignored.  The
-	  <replaceable>flags</replaceable> field gives
-	  further instructions, such as how to
-	  compress the rotated file or to create the log file if it
-	  is missing.  The last two fields are optional and
-	  specify the name of the Process ID
-	  (<acronym>PID</acronym>) file of a
-	  process and a signal number to send to that process when the
-	  file is rotated.</para>  
-
-	<para>For more information on all fields, valid
-	  flags, and how to specify the rotation time, refer to
-	  &man.newsyslog.conf.5;.  Since <application>newsyslog</application> is run from
-	  &man.cron.8;, it can not rotate files more often than it is
-	  scheduled to run from &man.cron.8;.</para>
+      <para>Each line starts with the name of the log to be rotated,
+	optionally followed by an owner and group for both rotated and
+	newly created files.  The <literal>mode</literal> field sets
+	the permissions on the log file and <literal>count</literal>
+	denotes how many rotated log files should be kept.  The
+	<literal>size</literal> and <literal>when</literal> fields
+	tell <application>newsyslog</application> when to rotate the
+	file.  A log file is rotated when either its size is larger
+	than the <literal>size</literal> field or when the time in the
+	<literal>when</literal> filed has passed.  An asterisk
+	(<literal>*</literal>) means that this field is ignored.  The
+	<replaceable>flags</replaceable> field gives further
+	instructions, such as how to compress the rotated file or to
+	create the log file if it is missing.  The last two fields are
+	optional and specify the name of the Process ID
+	(<acronym>PID</acronym>) file of a process and a signal number
+	to send to that process when the file is rotated.</para>
+
+      <para>For more information on all fields, valid flags, and how
+	to specify the rotation time, refer to &man.newsyslog.conf.5;.
+	Since <application>newsyslog</application> is run from
+	&man.cron.8;, it can not rotate files more often than it is
+	scheduled to run from &man.cron.8;.</para>
     </sect2>
 
-  <sect2 xml:id="network-syslogd">
-    <info>
+    <sect2 xml:id="network-syslogd">
+      <info>
       <title>Configuring Remote Logging</title>
 
       <authorgroup>
@@ -1501,182 +1499,188 @@ cron.*                                  
       </authorgroup>
     </info>
 
-    <para>Monitoring the log files of
-      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>In &os;, centralized log file aggregation, merging, and rotation can
-      be configured using <application>syslogd</application>
-      and<application>newsyslog</application>.  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
+      <para>Monitoring the log files of 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>In &os;, centralized log file aggregation, merging, and
+	rotation can be configured using
+	<application>syslogd</application> and
+	<application>newsyslog</application>.  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
       be configured to pass logging information to the logging
       server.</para>
 
-    <sect3>
-      <title>Log Server Configuration</title>
+      <sect3>
+	<title>Log Server Configuration</title>
 
-      <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>
+	<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>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>
+	<itemizedlist>
+	  <listitem>
+	    <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>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>
+	  <listitem>
+	    <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>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>
+	<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>
+	<example>
+	  <title>Sample Log Server Configuration</title>
 
-	<programlisting>+logclient.example.com
+	  <programlisting>+logclient.example.com
 *.*     /var/log/logclient.log</programlisting>
-      </example>
+	</example>
 
-      <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>
+	<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>
 
-      <para>Next, configure <filename>/etc/rc.conf</filename>:</para>
+	<para>Next, configure
+	  <filename>/etc/rc.conf</filename>:</para>
 
-      <programlisting>syslogd_enable="YES"
+	<programlisting>syslogd_enable="YES"
 syslogd_flags="-a logclient.example.com -v -v"</programlisting>
 
-      <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.syslogd.8; for a full list of possible options.</para>
+	<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.syslogd.8; for a full list of possible
+	  options.</para>
 
-      <para>Finally, create the log file:</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, <application>syslogd</application> should
-	be restarted and verified:</para>
+	<para>At this point, <application>syslogd</application> should
+	  be restarted and verified:</para>
 
-      <screen>&prompt.root; <userinput>service syslogd restart</userinput>
+	<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
-	restarted successfully, and client configuration can begin.
-	If the server did not restart, consult
-	<filename>/var/log/messages</filename> for the error.</para>
-    </sect3>
-
-    <sect3>
-      <title>Log Client Configuration</title>
-
-      <para>A logging client sends log entries to a logging server on
-	the network.  The client also keeps a local copy of its own
-	logs.</para>
-
-      <para>Once a logging server has been configured, edit
-	<filename>/etc/rc.conf</filename> on the logging
-	client:</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>
+      </sect3>
+
+      <sect3>
+	<title>Log Client Configuration</title>
+
+	<para>A logging client sends log entries to a logging server
+	  on the network.  The client also keeps a local copy of its
+	  own logs.</para>
+
+	<para>Once a logging server has been configured, edit
+	  <filename>/etc/rc.conf</filename> on the logging
+	  client:</para>
 
-      <programlisting>syslogd_enable="YES"
+	<programlisting>syslogd_enable="YES"
 syslogd_flags="-s -v -v"</programlisting>
 
-      <para>The first entry enables <application>syslogd</application>
-	on boot up.  The second entry prevents logs from being
-	accepted by this client from other hosts (<option>-s</option>)
-	and increases the verbosity of logged messages.</para>
-
-      <para>Next, define the logging server in the client's
-	<filename>/etc/syslog.conf</filename>.  In this example, all
-	logged facilities are sent to a remote system, denoted by the
-	<literal>@</literal> symbol, with the specified
-	hostname:</para>
-
-      <programlisting>*.*		@logserv.example.com</programlisting>
-
-      <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
-	<application>syslogd</application>:</para>
-
-      <screen>&prompt.root; <userinput>logger "<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
-	<filename>/var/log/logclient.log</filename> on the log
-	server.</para>
-    </sect3>
-
-    <sect3>
-      <title>Debugging Log Servers</title>
-
-      <para>If no messages are being received on the log server, the
-	cause is most likely a network connectivity issue, a hostname
-	resolution issue, or a typo in a configuration file.  To
-	isolate the cause, ensure that both the logging server and the
-	logging client are able to <command>ping</command> each other
-	using the hostname specified in their
-	<filename>/etc/rc.conf</filename>.  If this fails, check the
-	network cabling, the firewall ruleset, and the hostname
-	entries in the <acronym>DNS</acronym> server or
-	<filename>/etc/hosts</filename> on both the logging server and
-	clients.  Repeat until the <command>ping</command> is
-	successful from both hosts.</para>
-
-      <para>If the <command>ping</command> succeeds on both hosts but
-	log messages are still not being received, temporarily
-	increase logging verbosity to narrow down the configuration
-	issue.  In the following example,
-	<filename>/var/log/logclient.log</filename> on the logging
-	server is empty and <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>
+	<para>The first entry enables
+	  <application>syslogd</application> on boot up.  The second
+	  entry prevents logs from being accepted by this client from
+	  other hosts (<option>-s</option>) and increases the
+	  verbosity of logged messages.</para>
+
+	<para>Next, define the logging server in the client's
+	  <filename>/etc/syslog.conf</filename>.  In this example, all
+	  logged facilities are sent to a remote system, denoted by
+	  the <literal>@</literal> symbol, with the specified
+	  hostname:</para>
+
+	<programlisting>*.*		@logserv.example.com</programlisting>
+
+	<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 <application>syslogd</application>:</para>
+
+	<screen>&prompt.root; <userinput>logger "<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
+	  <filename>/var/log/logclient.log</filename> on the log
+	  server.</para>
+      </sect3>
+
+      <sect3>
+	<title>Debugging Log Servers</title>
 
-      <programlisting>syslogd_flags="-d -a logclien.example.com -v -v"</programlisting>
+	<para>If no messages are being received on the log server, the
+	  cause is most likely a network connectivity issue, a
+	  hostname resolution issue, or a typo in a configuration
+	  file.  To isolate the cause, ensure that both the logging
+	  server and the logging client are able to
+	  <command>ping</command> each other using the hostname
+	  specified in their <filename>/etc/rc.conf</filename>.  If
+	  this fails, check the network cabling, the firewall ruleset,
+	  and the hostname entries in the <acronym>DNS</acronym>
+	  server or <filename>/etc/hosts</filename> on both the
+	  logging server and clients.  Repeat until the
+	  <command>ping</command> is successful from both
+	  hosts.</para>
+
+	<para>If the <command>ping</command> succeeds on both hosts
+	  but log messages are still not being received, temporarily
+	  increase logging verbosity to narrow down the configuration
+	  issue.  In the following example,
+	  <filename>/var/log/logclient.log</filename> on the logging
+	  server is empty and <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>
 
-      <screen>&prompt.root; <userinput>service syslogd restart</userinput></screen>
+	<programlisting>syslogd_flags="-d -a logclien.example.com -v -v"</programlisting>
 
-      <para>Debugging data similar to the following will flash on the
-	console immediately after the restart:</para>
+	<screen>&prompt.root; <userinput>service syslogd restart</userinput></screen>
 
-      <screen>logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
+	<para>Debugging data similar to the following will flash on
+	  the console immediately after the restart:</para>
+
+	<screen>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
 Logging to FILE /var/log/messages
@@ -1685,13 +1689,13 @@ 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>In this example, the log messages are being rejected due
-	to a typo which results in a hostname mismatch.  The client's
-	hostname should be <literal>logclient</literal>, not
-	<literal>logclien</literal>.  Fix the typo, issue a restart,
-	and verify the results:</para>
+	<para>In this example, the log messages are being rejected due
+	  to a typo which results in a hostname mismatch.  The
+	  client's hostname should be <literal>logclient</literal>,
+	  not <literal>logclien</literal>.  Fix the typo, issue a
+	  restart, and verify the results:</para>
 
-      <screen>&prompt.root; <userinput>service syslogd restart</userinput>
+	<screen>&prompt.root; <userinput>service syslogd 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
@@ -1705,31 +1709,33 @@ logmsg: pri 15, flags 0, from logclient.
 Logging to FILE /var/log/logclient.log
 Logging to FILE /var/log/messages</screen>
 
-      <para>At this point, the messages are being properly received
-	and placed in the correct file.</para>
-    </sect3>
-
-    <sect3>
-      <title>Security Considerations</title>
-
-      <para>As with any network service, security requirements should
-	be considered before implementing a logging server.  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 or
-	password protected.  If a need for encryption exists, consider
-	using <package>security/stunnel</package>, which 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 log files to gain additional insight into system
-	configuration.  Setting proper permissions on log files is
-	critical.  The built-in log rotator, <application>newsyslog</application>,
-	supports setting permissions on newly created and rotated log
-	files.  Setting log files to mode <literal>600</literal>
-	should prevent unwanted access by local users.  Refer to
-	&man.newsyslog.conf.5; for additional information.</para>
+	<para>At this point, the messages are being properly received
+	  and placed in the correct file.</para>
+      </sect3>
+
+      <sect3>
+	<title>Security Considerations</title>
+
+	<para>As with any network service, security requirements
+	  should be considered before implementing a logging server.
+	  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 or password protected.  If a need for encryption
+	  exists, consider using <package>security/stunnel</package>,
+	  which 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 log files to gain additional insight into system
+	  configuration.  Setting proper permissions on log files is
+	  critical.  The built-in log rotator,
+	  <application>newsyslog</application>, supports setting
+	  permissions on newly created and rotated log files.  Setting
+	  log files to mode <literal>600</literal> should prevent
+	  unwanted access by local users.  Refer to
+	  &man.newsyslog.conf.5; for additional information.</para>
       </sect3>
     </sect2>
   </sect1>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201403242122.s2OLMYGM003696>