Date: Mon, 24 Mar 2014 21:22:34 +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: r44346 - head/en_US.ISO8859-1/books/handbook/config Message-ID: <201403242122.s2OLMYGM003696@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201403242122.s2OLMYGM003696>