Date: Sat, 1 Feb 2014 18:37:54 +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: r43725 - head/en_US.ISO8859-1/books/handbook/network-servers Message-ID: <201402011837.s11IbsvU010117@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402011837.s11IbsvU010117>