Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 1 Feb 2014 18:51:59 +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: r43726 - head/en_US.ISO8859-1/books/handbook/network-servers
Message-ID:  <201402011851.s11IpxpT016922@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: dru
Date: Sat Feb  1 18:51:59 2014
New Revision: 43726
URL: http://svnweb.freebsd.org/changeset/doc/43726

Log:
  Whitespace fix only. Translators can ignore.
  
  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 18:37:54 2014	(r43725)
+++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml	Sat Feb  1 18:51:59 2014	(r43726)
@@ -5422,130 +5422,131 @@ driftfile /var/db/ntp.drift</programlist
 
     <para>Interacting with system logs is a crucial aspect of both
       security and system administration.  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>Centralized log file aggregation, merging, and rotation can be configured
-      using &os; native tools, such as
-      &man.syslogd.8; and &man.newsyslog.8;.  This section demonstrates an example
+      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>Centralized log file aggregation, merging, and rotation can
+      be configured using &os; native tools, such as &man.syslogd.8;
+      and &man.newsyslog.8;.  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>
+	class="fqdomainname">logclient.example.com</systemitem>, will
+      be configured to pass logging information to the logging
+      server.</para>
 
     <sect2>
       <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>
+	    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>
+	  <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 
+      <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
+	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>
+	the log entries in
+	<filename>/var/log/logclient.log</filename>.</para>
 
       <example>
 	<title>Sample Log Server Configuration</title>
 
-      <programlisting>+logclient.example.com
+	<programlisting>+logclient.example.com
 *.*     /var/log/logclient.log</programlisting>
       </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>
 
       <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>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>
+	&man.syslogd.8; for a full list of possible options.</para>
 
       <para>Finally, create the log file:</para>
 
       <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>
 &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
+	restarted successfully, and client configuration can begin.
+	If the server did not restart, consult
 	<filename>/var/log/messages</filename> for the error.</para>
     </sect2>
 
     <sect2>
       <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>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>
+	<filename>/etc/rc.conf</filename> on the logging
+	client:</para>
 
       <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>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>
+	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>
+      <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>
 
@@ -5557,21 +5558,22 @@ syslogd_flags="-s -v -v"</programlisting
 
       <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>
+	<filename>/var/log/logclient.log</filename> on the log
+	server.</para>
     </sect2>
 
     <sect2>
       <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
+      <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
+	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>
@@ -5579,11 +5581,13 @@ syslogd_flags="-s -v -v"</programlisting
       <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>
+	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>
 
@@ -5601,11 +5605,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>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>
 logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
@@ -5629,25 +5633,23 @@ Logging to FILE /var/log/messages</scree
       <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>
+	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, &man.newsyslog.8;,
-	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>
+	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 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?201402011851.s11IpxpT016922>