NAME¶
client-local.cfg - Local configuration settings for Xymon clients
SYNOPSIS¶
~xymon/server/etc/client-local.cfg
DESCRIPTION¶
The client-local.cfg file contains settings that are used by each Xymon client
when it runs on a monitored host. It provides a convenient way of configuring
clients from a central location without having to setup special configuration
maintenance tools on all clients.
The client-local.cfg file is currently used to configure what logfiles the
client should fetch data from, to be used as the basis for the
"msgs" status column; and to configure which files and directories
are being monitored in the "files" status column.
Note that there is a dependency between the client-local.cfg file and the
hobbit-clients.cfg(5) file. When monitoring e.g. a logfile, you must
first enter it into the client-local.cfg file, to trigger the Xymon client
into reporting any data about the logfile. Next, you must configure
hobbit-clients.cfg so the Xymon server knows what to look for in the file data
sent by the client. So: client-local.cfg defines what raw data is collected by
the client, and hobbit-clients.cfg defines how to analyze them.
PROPAGATION TO CLIENTS¶
The client-local.cfg file resides on the Xymon server.
When clients connect to the Xymon server to send in their client data, they will
receive part of this file back from the Xymon server. The configuration
received by the client is then used the next time the client runs.
This method of propagating the configuration means that there is a delay of up
to two poll cycles (i.e. 5-10 minutes) from a configuration change is entered
into the client-local.cfg file, and until you see the result in the status
messages reported by the client.
The file is divided into sections, delimited by "[name]" lines. A
section name can be either an operating system identifier - linux, solaris,
hp-ux, aix, freebsd, openbsd, netbsd, darwin - or a hostname. When deciding
which section to send to a client, Xymon will first look for a section named
after the hostname of the client; if such a section does not exist, it will
look for a section named by the operating system of the client. So you can
configure special configurations for individual hosts, and have a default
configuration for all other hosts of a certain type.
Apart from the section delimiter, the file format is free-form, or rather it is
defined by the tools that make use of the configuration.
LOGFILE CONFIGURATION ENTRIES¶
A logfile configuration entry looks like this:
log:/var/log/messages:10240
ignore MARK
trigger Oops
The
log:FILENAME:SIZE line defines the filename of the log, and the
maximum amount of data (in bytes) to send to the Xymon server. FILENAME is
usually an explicit full-path filename on the client. If it is enclosed in
backticks, it is a command which the Xymon client runs and each line of output
from this command is then used as a filename. This allows scripting which
files to monitor, e.g. if you have logfiles that are named with some sort of
timestamp.
The
ignore PATTERN line (optional) defines lines in the logfile which are
ignored entirely, i.e. they are stripped from the logfile data before sending
it to the Xymon server. It is used to remove completely unwanted
"noise" entries from the logdata processed by Xymon.
"PATTERN" is a regular expression.
The
trigger PATTERN line (optional) is used only when there is more data
in the log than the maximum size set in the "log:FILENAME:SIZE"
line. The "trigger" pattern is then used to find particularly
interesting lines in the logfile - these will always be sent to the Xymon
server. After picking out the "trigger" lines, any remaining space
up to the maximum size is filled in with the most recent entries from the
logfile. "PATTERN" is a regular expression.
COUNTING LOGENTRIES¶
A special type of log-handling is possible, where the number of lines matching a
regular expressions are merely counted. This is
linecount:FILENAME,
followed by a number of lines of the form
ID:PATTERN. E.g.
linecount:/var/log/messages
diskerrors:I/O error.*device.*hd
badlogins:Failed login
FILE CONFIGURATION ENTRIES¶
A file monitoring entry is used to watch the meta-data of a file: Owner, group,
size, permissions, checksum etc. It looks like this:
file:/var/log/messages[:HASH]
The
file:FILENAME line defines the filename of the file to monitor. As
with the "log:" entries, a filename enclosed in backticks means a
command which will generate the filenames dynamically. The optional [:HASH]
setting defines what type of hash to compute for the file:
md5,
sha1 or
rmd160. By default, no hash is calculated.
NOTE: If you want to check multiple files using a wildcard, you
must use a command to generate the filenames. Putting wildcards
directly into the
file: entry will not work.
DIRECTORY CONFIGURATION ENTRIES¶
A directory monitoring entry is used to watch the size of a directory and any
sub-directories. It looks like this:
dir:DIRECTORYNAME
The
dir:DIRECTORYNAME line defines the filename of the file to monitor.
As with the "log:" entries, a filename enclosed in backticks means a
command which will generate the filenames dynamically. The Xymon client will
run the
du(1) command with the directoryname as parameter, and send the
output back to the Xymon server.
NOTE: If you want to check multiple directories using a wildcard, you
must use a command to generate the directory names. Putting wildcards
directly into the
dir: entry will not work. E.g. use something like
dir:`find /var/log -maxdepth 1 -type d`
The "du" command used can be configured through the
DU
environment variable. On some systems, by default
du reports data in
disk blocks instead of KB (e.g. Solaris). So you may want to configure the
Xymon client to use a
du command which reports data in KB, e.g. by
setting
DU="du -k"
in the hobbitclient.cfg file.
NOTES¶
The ability of the Xymon client to calculate file hashes and monitor those can
be used for file integrity validation on a small scale. However, there is a
significant processing overhead in calculating these every time the Xymon
client runs, so this should not be considered a replacement for host-based
intrusion detection systems such as Tripwire or AIDE.
Use of the directory monitoring on directory structures with a large number of
files and/or sub-directories can be quite ressource-intensive.
SEE ALSO¶
hobbit-clients.cfg(5),
hobbitd_client(8),
hobbitd(8),
xymon(7)