svn commit: r43725 - head/en_US.ISO8859-1/books/handbook/network-servers
Dru Lavigne
dru at FreeBSD.org
Sat Feb 1 18:37:55 UTC 2014
Author: dru
Date: Sat Feb 1 18:37:54 2014
New Revision: 43725
URL: http://svnweb.freebsd.org/changeset/doc/43725
Log:
Finish syslogd section.
Clarify examples.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Sat Feb 1 17:01:49 2014 (r43724)
+++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Sat Feb 1 18:37:54 2014 (r43725)
@@ -5520,80 +5520,43 @@ syslogd_flags="-a logclient.example.com
<sect2>
<title>Log Client Configuration</title>
- <para>A logging client is a machine which sends log information
- to a logging server in addition to keeping local
- copies.</para>
-
- <para>Similar to log servers, clients must also meet a few
- minimum requirements:</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>
+ <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"
syslogd_flags="-s -v -v"</programlisting>
- <para>As before, these entries will enable the
- <command>syslogd</command> daemon on boot up, and increases
- the verbosity of logged messages. The <option>-s</option>
- option prevents logs from being accepted by this client from
- other hosts.</para>
-
- <para>Facilities describe the system part for which a message
- is generated. For an example, <acronym>ftp</acronym> and
- <acronym>ipfw</acronym> are both facilities. When log
- messages are generated for those two services, they will
- normally include those two utilities in any log messages.
- 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>
+ <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>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
- "Test message from logclient"</userinput></screen>
+ <screen>&prompt.root; <userinput>logger "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
- are not being received on the log server. There are several
- reasons this may occur; however, the most common two are
- network connection issues and <acronym>DNS</acronym> issues.
- To test these cases, ensure both hosts are able to reach one
- another using the hostname specified in
- <filename>/etc/rc.conf</filename>. If this appears to be
- working properly, an alternation to the
- <literal>syslogd_flags</literal> option in
- <filename>/etc/rc.conf</filename> will be required.</para>
-
- <para>In the following example,
- <filename>/var/log/logclient.log</filename> is empty, and the
- <filename>/var/log/messages</filename> files indicate no
- reason for the failure. To increase debugging output, change
- the <literal>syslogd_flags</literal> option to look like the
- following example, and issue a restart:</para>
+ <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>
<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
- to a name mismatch. After reviewing the configuration bit
- by bit, it appears a typo in the following
- <filename>/etc/rc.conf</filename> line has an issue:</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>
+ <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>
logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
@@ -5668,24 +5629,25 @@ Logging to FILE /var/log/messages</scree
<title>Security Considerations</title>
<para>As with any network service, security requirements should
- be considered before implementing this configuration. At
- times, log files may contain sensitive data about services
+ 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 nor password protected. If a need for
- encryption exists, it might be possible to use
+ not be encrypted or password protected. If a need for
+ 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
- configuration. In those cases, setting proper permissions
- on these files will be critical. The &man.newsyslog.8;
- utility supports setting permissions on newly created and
+ access log files to gain additional insight into system
+ configuration. Setting proper permissions
+ on log files is critical. The built-in log rotator, &man.newsyslog.8;,
+ supports setting permissions on newly created and
rotated log files. Setting log files to mode
- <literal>600</literal> should prevent any unwanted snooping
- by local users.</para>
+ <literal>600</literal> should prevent unwanted access
+ by local users. Refer to &man.newsyslog.conf.5; for
+ additional information.</para>
</sect2>
</sect1>
More information about the svn-doc-all
mailing list