First 1/2 of syslogd section.
Tighten wording and clarify unclear bits. Sponsored by: iXsystems
This commit is contained in:
parent
38f15b463e
commit
902c48c6a0
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43714
1 changed files with 52 additions and 70 deletions
|
|
@ -5422,117 +5422,99 @@ driftfile /var/db/ntp.drift</programlisting>
|
||||||
|
|
||||||
<para>Interacting with system logs is a crucial aspect of both
|
<para>Interacting with system logs is a crucial aspect of both
|
||||||
security and system administration. Monitoring the log files of
|
security and system administration. Monitoring the log files of
|
||||||
multiple hosts can get very unwieldy when these hosts are
|
multiple hosts can become unwieldy as the number of systems increases.
|
||||||
distributed across medium or large networks, or when they are
|
Configuring centralized logging can reduce
|
||||||
parts of various different types of networks. In these cases,
|
some of the administrative burden of log file administration.</para>
|
||||||
configuring remote logging may make the whole process a lot more
|
|
||||||
comfortable.</para>
|
<para>Centralized log file aggregation, merging, and rotation can be configured
|
||||||
|
using &os; native tools, such as
|
||||||
<para>Centralized logging to a specific logging host can reduce
|
&man.syslogd.8; and &man.newsyslog.8;. This section demonstrates an example
|
||||||
some of the administrative burden of log file administration.
|
configuration, where host <systemitem>A</systemitem>, named
|
||||||
Log file aggregation, merging and rotation may be configured in
|
|
||||||
one location, using the native tools of &os;, such as
|
|
||||||
&man.syslogd.8; and &man.newsyslog.8;. In the following example
|
|
||||||
configuration, host <systemitem>A</systemitem>, named
|
|
||||||
<systemitem
|
<systemitem
|
||||||
class="fqdomainname">logserv.example.com</systemitem>, will
|
class="fqdomainname">logserv.example.com</systemitem>, will
|
||||||
collect logging information for the local network. Host
|
collect logging information for the local network. Host
|
||||||
<systemitem>B</systemitem>, named <systemitem
|
<systemitem>B</systemitem>, named <systemitem
|
||||||
class="fqdomainname">logclient.example.com</systemitem> will
|
class="fqdomainname">logclient.example.com</systemitem>, will be configured to
|
||||||
pass logging information to the server system. In live
|
pass logging information to the logging server.</para>
|
||||||
configurations, both hosts require proper forward and reverse
|
|
||||||
<acronym>DNS</acronym> or entries in
|
|
||||||
<filename>/etc/hosts</filename>. Otherwise, data will be
|
|
||||||
rejected by the server.</para>
|
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Log Server Configuration</title>
|
<title>Log Server Configuration</title>
|
||||||
|
|
||||||
<para>Log servers are machines configured to accept logging
|
<para>A log server is a system that has been configured to accept logging
|
||||||
information from remote hosts. In most cases this is to ease
|
information from other hosts. Before configuring a log server, check the following:</para>
|
||||||
configuration, in other cases it may just be a better
|
|
||||||
administration move. Regardless of reason, there are a few
|
|
||||||
requirements before continuing.</para>
|
|
||||||
|
|
||||||
<para>A properly configured logging server has met the following
|
|
||||||
minimal requirements:</para>
|
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The firewall ruleset allows for <acronym>UDP</acronym>
|
<para>If there is a firewall between the logging server and
|
||||||
to be passed on port 514 on both the client and
|
any logging clients, ensure that the firewall ruleset allows <acronym>UDP</acronym>
|
||||||
server;</para>
|
port 514 for both the clients and the
|
||||||
|
server.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><command>syslogd</command> has been configured to
|
<para>The logging server and all client
|
||||||
accept remote messages from client machines;</para>
|
machines must have forward and reverse entries in
|
||||||
</listitem>
|
the local <acronym>DNS</acronym>. If the network does not have
|
||||||
|
a <acronym>DNS</acronym> server, create entries in each system's
|
||||||
<listitem>
|
<filename>/etc/hosts</filename>. Proper name resolution is required
|
||||||
<para>The <command>syslogd</command> server and all client
|
so that log entries are not rejected by the logging server.</para>
|
||||||
machines must have valid entries for both forward and
|
|
||||||
reverse <acronym>DNS</acronym>, or be properly configured
|
|
||||||
in <filename>/etc/hosts</filename>.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
|
||||||
<para>To configure the log server, the client must be listed
|
<para>On the log server, edit
|
||||||
in <filename>/etc/syslog.conf</filename>, and the logging
|
<filename>/etc/syslog.conf</filename> to specify the name of
|
||||||
facility must be specified:</para>
|
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>
|
||||||
|
|
||||||
<programlisting>+logclient.example.com
|
<programlisting>+logclient.example.com
|
||||||
*.* /var/log/logclient.log</programlisting>
|
*.* /var/log/logclient.log</programlisting>
|
||||||
|
</example>
|
||||||
|
|
||||||
<note>
|
<para>When adding multiple log clients, add a similar two-line entry
|
||||||
<para>More information on various supported and available
|
for each client. More information about the available
|
||||||
<emphasis>facilities</emphasis> may be found in
|
facilities may be found in
|
||||||
&man.syslog.conf.5;.</para>
|
&man.syslog.conf.5;.</para>
|
||||||
</note>
|
|
||||||
|
|
||||||
<para>Once added, all <literal>facility</literal> messages will
|
<para>Next, configure <filename>/etc/rc.conf</filename>:</para>
|
||||||
be logged to the file specified previously,
|
|
||||||
<filename>/var/log/logclient.log</filename>.</para>
|
|
||||||
|
|
||||||
<para>The server machine must also have the following listing
|
|
||||||
placed inside <filename>/etc/rc.conf</filename>:</para>
|
|
||||||
|
|
||||||
<programlisting>syslogd_enable="YES"
|
<programlisting>syslogd_enable="YES"
|
||||||
syslogd_flags="-a logclient.example.com -v -v"</programlisting>
|
syslogd_flags="-a logclient.example.com -v -v"</programlisting>
|
||||||
|
|
||||||
<para>The first option will enable the
|
<para>The first entry starts
|
||||||
<command>syslogd</command> daemon on boot up, and the second
|
<application>syslogd</application> at system boot. The second
|
||||||
option allows data from the specified client to be accepted on
|
entry allows log entries from the specified client.
|
||||||
this server. The latter part, using <option>-v -v</option>,
|
The <option>-v -v</option>
|
||||||
will increase the verbosity of logged messages. This is
|
increases the verbosity of logged messages. This is
|
||||||
extremely useful for tweaking facilities as administrators are
|
useful for tweaking facilities as administrators are
|
||||||
able to see what type of messages are being logged under which
|
able to see what type of messages are being logged under each
|
||||||
facility.</para>
|
facility.</para>
|
||||||
|
|
||||||
<para>Multiple <option>-a</option> options may be specified to
|
<para>Multiple <option>-a</option> options may be specified to
|
||||||
allow logging from multiple clients. <acronym>IP</acronym>
|
allow logging from multiple clients. <acronym>IP</acronym>
|
||||||
addresses and whole netblocks may also be specified. Refer to
|
addresses and whole netblocks may also be specified. Refer to
|
||||||
&man.syslog.3; for a full list of possible
|
&man.syslogd.8; for a full list of possible
|
||||||
options.</para>
|
options.</para>
|
||||||
|
|
||||||
<para>Finally, the log file should be created. The method used
|
<para>Finally, create the log file:</para>
|
||||||
does not matter, but &man.touch.1; works great for situations
|
|
||||||
such as this:</para>
|
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>touch
|
<screen>&prompt.root; <userinput>touch /var/log/logclient.log</userinput></screen>
|
||||||
/var/log/logclient.log</userinput></screen>
|
|
||||||
|
|
||||||
<para>At this point, the <command>syslogd</command> daemon
|
<para>At this point, <application>syslogd</application>
|
||||||
should be restarted and verified:</para>
|
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>
|
&prompt.root; <userinput>pgrep syslog</userinput></screen>
|
||||||
|
|
||||||
<para>If a <acronym>PID</acronym> is returned, the server has
|
<para>If a <acronym>PID</acronym> is returned, the server
|
||||||
been restarted successfully, and client configuration may
|
restarted successfully, and client configuration can
|
||||||
begin. If the server has not restarted, consult the
|
begin. If the server did not restart, consult
|
||||||
<filename>/var/log/messages</filename> log for any
|
<filename>/var/log/messages</filename> for the error.</para>
|
||||||
output.</para>
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue