Finish syslogd section.
Clarify examples. Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
89d89516e8
commit
d15838fe7c
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43725
1 changed files with 56 additions and 94 deletions
|
|
@ -5520,80 +5520,43 @@ syslogd_flags="-a logclient.example.com -v -v"</programlisting>
|
|||
<sect2>
|
||||
<title>Log Client Configuration</title>
|
||||
|
||||
<para>A logging client is a machine which sends log information
|
||||
to a logging server in addition to keeping local
|
||||
copies.</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>Similar to log servers, clients must also meet a few
|
||||
minimum requirements:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>&man.syslogd.8; must be configured to send messages of
|
||||
specific types to a log server, which must accept
|
||||
them;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The firewall must allow <acronym>UDP</acronym> packets
|
||||
through on port 514;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Both forward and reverse <acronym>DNS</acronym> must
|
||||
be configured or have proper entries in the
|
||||
<filename>/etc/hosts</filename>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Client configuration is a bit more relaxed when compared
|
||||
to that of the servers. The client machine must have the
|
||||
following listing placed inside
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
<para>Once a logging server has been configured, edit
|
||||
<filename>/etc/rc.conf</filename> on the logging client:</para>
|
||||
|
||||
<programlisting>syslogd_enable="YES"
|
||||
syslogd_flags="-s -v -v"</programlisting>
|
||||
|
||||
<para>As before, these entries will enable the
|
||||
<command>syslogd</command> daemon on boot up, and increases
|
||||
the verbosity of logged messages. The <option>-s</option>
|
||||
option prevents logs from being accepted by this client from
|
||||
other hosts.</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>Facilities describe the system part for which a message
|
||||
is generated. For an example, <acronym>ftp</acronym> and
|
||||
<acronym>ipfw</acronym> are both facilities. When log
|
||||
messages are generated for those two services, they will
|
||||
normally include those two utilities in any log messages.
|
||||
Facilities are accompanied with a priority or level, which
|
||||
is used to mark how important a log message is. The most
|
||||
common will be the <literal>warning</literal> and
|
||||
<literal>info</literal>. Refer to &man.syslog.3;
|
||||
for a full list of available facilities and
|
||||
priorities.</para>
|
||||
|
||||
<para>The logging server must be defined in the client's
|
||||
<filename>/etc/syslog.conf</filename>. In this instance,
|
||||
the <literal>@</literal> symbol is used to send logging
|
||||
data to a remote server and would look similar to the
|
||||
following entry:</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>Once added, <command>syslogd</command> must be restarted
|
||||
<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
|
||||
<command>syslogd</command>:</para>
|
||||
<application>syslogd</application>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>logger
|
||||
"Test message from logclient"</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>logger "Test message from logclient"</userinput></screen>
|
||||
|
||||
<para>This message should now exist both in
|
||||
<filename>/var/log/messages</filename> on the client, and
|
||||
<filename>/var/log/messages</filename> on the client and
|
||||
<filename>/var/log/logclient.log</filename> on the
|
||||
log server.</para>
|
||||
</sect2>
|
||||
|
|
@ -5601,30 +5564,33 @@ syslogd_flags="-s -v -v"</programlisting>
|
|||
<sect2>
|
||||
<title>Debugging Log Servers</title>
|
||||
|
||||
<para>In certain cases, debugging may be required if messages
|
||||
are not being received on the log server. There are several
|
||||
reasons this may occur; however, the most common two are
|
||||
network connection issues and <acronym>DNS</acronym> issues.
|
||||
To test these cases, ensure both hosts are able to reach one
|
||||
another using the hostname specified in
|
||||
<filename>/etc/rc.conf</filename>. If this appears to be
|
||||
working properly, an alternation to the
|
||||
<literal>syslogd_flags</literal> option in
|
||||
<filename>/etc/rc.conf</filename> will be required.</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>In the following example,
|
||||
<filename>/var/log/logclient.log</filename> is empty, and the
|
||||
<filename>/var/log/messages</filename> files indicate no
|
||||
reason for the failure. To increase debugging output, change
|
||||
the <literal>syslogd_flags</literal> option to look like the
|
||||
following example, 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>
|
||||
|
||||
<screen>&prompt.root; <userinput>service syslogd restart</userinput></screen>
|
||||
|
||||
<para>Debugging data similar to the following will flash on the
|
||||
screen immediately after the restart:</para>
|
||||
console immediately after the restart:</para>
|
||||
|
||||
<screen>logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
|
||||
syslogd: restarted
|
||||
|
|
@ -5635,16 +5601,11 @@ cvthname(192.168.1.10)
|
|||
validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
|
||||
rejected in rule 0 due to name mismatch.</screen>
|
||||
|
||||
<para>It appears obvious the messages are being rejected due
|
||||
to a name mismatch. After reviewing the configuration bit
|
||||
by bit, it appears a typo in the following
|
||||
<filename>/etc/rc.conf</filename> line has an issue:</para>
|
||||
|
||||
<programlisting>syslogd_flags="-d -a logclien.example.com -v -v"</programlisting>
|
||||
|
||||
<para>The line should contain <literal>logclient</literal>, not
|
||||
<literal>logclien</literal>. After the proper alterations
|
||||
are made, a restart is issued with expected 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
|
||||
|
|
@ -5668,24 +5629,25 @@ Logging to FILE /var/log/messages</screen>
|
|||
<title>Security Considerations</title>
|
||||
|
||||
<para>As with any network service, security requirements should
|
||||
be considered before implementing this configuration. At
|
||||
times, log files may contain sensitive data about services
|
||||
be considered before implementing a logging server.
|
||||
Log files may contain sensitive data about services
|
||||
enabled on the local host, user accounts, and configuration
|
||||
data. Network data sent from the client to the server will
|
||||
not be encrypted nor password protected. If a need for
|
||||
encryption exists, it might be possible to use
|
||||
not be encrypted or password protected. If a need for
|
||||
encryption exists, consider using
|
||||
<package>security/stunnel</package>, which
|
||||
will transmit data over an encrypted tunnel.</para>
|
||||
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 these files to gain additional insight on system
|
||||
configuration. In those cases, setting proper permissions
|
||||
on these files will be critical. The &man.newsyslog.8;
|
||||
utility supports setting permissions on newly created and
|
||||
access log files to gain additional insight into system
|
||||
configuration. Setting proper permissions
|
||||
on log files is critical. The built-in log rotator, &man.newsyslog.8;,
|
||||
supports setting permissions on newly created and
|
||||
rotated log files. Setting log files to mode
|
||||
<literal>600</literal> should prevent any unwanted snooping
|
||||
by local users.</para>
|
||||
<literal>600</literal> should prevent unwanted access
|
||||
by local users. Refer to &man.newsyslog.conf.5; for
|
||||
additional information.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue