svn commit: r44346 - head/en_US.ISO8859-1/books/handbook/config
Dru Lavigne
dru at FreeBSD.org
Mon Mar 24 21:22:34 UTC 2014
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>
More information about the svn-doc-all
mailing list