White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
b6c9d3d7d8
commit
f6e673c23b
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44346
1 changed files with 277 additions and 271 deletions
|
|
@ -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"</programlisting>
|
|||
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 netmask 255.255.255.255"</programlisting>
|
|||
|
||||
<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 netmask 255.255.255.255"</programlisting>
|
|||
<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>
|
||||
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>
|
||||
<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 netmask 255.255.255.255"</programlisting>
|
|||
|
||||
<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 netmask 255.255.255.255"</programlisting>
|
|||
*.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.* /var/log/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.* /var/log/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.* /var/log/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.* /var/log/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/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>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>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.* /var/log/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>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>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>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>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>
|
||||
<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>
|
||||
<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>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>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>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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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 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>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>
|
||||
<programlisting>syslogd_flags="-d -a logclien.example.com -v -v"</programlisting>
|
||||
|
||||
<screen>&prompt.root; <userinput>service syslogd restart</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>service syslogd restart</userinput></screen>
|
||||
|
||||
<para>Debugging data similar to the following will flash on the
|
||||
console immediately after the restart:</para>
|
||||
<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
|
||||
<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.example.com, msg Dec 11 02:01:28 trhodes
|
|||
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>
|
||||
<para>At this point, the messages are being properly received
|
||||
and placed in the correct file.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Security Considerations</title>
|
||||
<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>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>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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue