From owner-svn-doc-all@FreeBSD.ORG Sat Feb 1 18:37:55 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07A8AC04; Sat, 1 Feb 2014 18:37:55 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DBF711386; Sat, 1 Feb 2014 18:37:54 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id s11IbsMc010118; Sat, 1 Feb 2014 18:37:54 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.7/8.14.7/Submit) id s11IbsvU010117; Sat, 1 Feb 2014 18:37:54 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402011837.s11IbsvU010117@svn.freebsd.org> From: Dru Lavigne Date: Sat, 1 Feb 2014 18:37:54 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 18:37:55 -0000 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 Log Client Configuration - A logging client is a machine which sends log information - to a logging server in addition to keeping local - copies. - - Similar to log servers, clients must also meet a few - minimum requirements: - - - - &man.syslogd.8; must be configured to send messages of - specific types to a log server, which must accept - them; - - - - The firewall must allow UDP packets - through on port 514; - - - - Both forward and reverse DNS must - be configured or have proper entries in the - /etc/hosts. - - - - Client configuration is a bit more relaxed when compared - to that of the servers. The client machine must have the - following listing placed inside - /etc/rc.conf: + A logging client sends log entries + to a logging server on the network. The client also keeps a local + copy of its own logs. + + Once a logging server has been configured, edit + /etc/rc.conf on the logging client: syslogd_enable="YES" syslogd_flags="-s -v -v" - As before, these entries will enable the - syslogd daemon on boot up, and increases - the verbosity of logged messages. The - option prevents logs from being accepted by this client from - other hosts. - - Facilities describe the system part for which a message - is generated. For an example, ftp and - ipfw 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 warning and - info. Refer to &man.syslog.3; - for a full list of available facilities and - priorities. - - The logging server must be defined in the client's - /etc/syslog.conf. In this instance, - the @ symbol is used to send logging - data to a remote server and would look similar to the - following entry: + The first entry enables + syslogd on boot up. The second entry + prevents logs from being accepted by this client from + other hosts () and increases + the verbosity of logged messages. + + Next, define the logging server in the client's + /etc/syslog.conf. In this example, all + logged facilities are sent to a remote system, denoted by + the @ symbol, + with the specified hostname: *.* @logserv.example.com - Once added, syslogd must be restarted + After saving the edit, restart syslogd for the changes to take effect: &prompt.root; service syslogd restart To test that log messages are being sent across the network, use &man.logger.1; on the client to send a message to - syslogd: + syslogd: - &prompt.root; logger - "Test message from logclient" + &prompt.root; logger "Test message from logclient" This message should now exist both in - /var/log/messages on the client, and + /var/log/messages on the client and /var/log/logclient.log on the log server. @@ -5601,30 +5564,33 @@ syslogd_flags="-s -v -v" Debugging Log Servers - 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 DNS issues. - To test these cases, ensure both hosts are able to reach one - another using the hostname specified in - /etc/rc.conf. If this appears to be - working properly, an alternation to the - syslogd_flags option in - /etc/rc.conf will be required. - - In the following example, - /var/log/logclient.log is empty, and the - /var/log/messages files indicate no - reason for the failure. To increase debugging output, change - the syslogd_flags option to look like the - following example, and issue a restart: + 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 ping + each other using the hostname specified in their + /etc/rc.conf. If this fails, check the + network cabling, the firewall ruleset, and the hostname entries + in the DNS server or + /etc/hosts on both the logging server and + clients. Repeat until the ping is + successful from both hosts. + + If the ping 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, + /var/log/logclient.log on the logging server is empty and + /var/log/messages on the logging client does not indicate a + reason for the failure. To increase debugging output, edit the + syslogd_flags entry on the logging server and issue a restart: syslogd_flags="-d -a logclien.example.com -v -v" &prompt.root; service syslogd restart Debugging data similar to the following will flash on the - screen immediately after the restart: + console immediately after the restart: 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. - 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 - /etc/rc.conf line has an issue: - - syslogd_flags="-d -a logclien.example.com -v -v" - - The line should contain logclient, not - logclien. After the proper alterations - are made, a restart is issued with expected results: + 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 logclient, not + logclien. Fix the typo, issue + a restart, and verify the results: &prompt.root; service syslogd restart logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart @@ -5668,24 +5629,25 @@ Logging to FILE /var/log/messagesSecurity Considerations 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 security/stunnel, which - will transmit data over an encrypted tunnel. + will transmit the logging data over an encrypted tunnel. 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 - 600 should prevent any unwanted snooping - by local users. + 600 should prevent unwanted access + by local users. Refer to &man.newsyslog.conf.5; for + additional information.