1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML><HEAD><TITLE>Man page of CLIENT-LOCAL.CFG</TITLE>
</HEAD><BODY>
<H1>CLIENT-LOCAL.CFG</H1>
Section: File Formats (5)<BR>Updated: Version 4.3.17: 23 Feb 2014<BR><A HREF="#index">Index</A>
<A HREF="../index.html">Return to Main Contents</A><HR>
<A NAME="lbAB"> </A>
<H2>NAME</H2>
client-local.cfg - Local configuration settings for Xymon clients
<P>
<A NAME="lbAC"> </A>
<H2>SYNOPSIS</H2>
<B>~xymon/server/etc/client-local.cfg</B>
<P>
<A NAME="lbAD"> </A>
<H2>DESCRIPTION</H2>
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.
<P>
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.
<P>
Note that there is a dependency between the client-local.cfg file
and the
<I><A HREF="../man5/analysis.cfg.5.html">analysis.cfg</A>(5)</I>
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 analysis.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 analysis.cfg defines how to analyze them.
<P>
<A NAME="lbAE"> </A>
<H2>PROPAGATION TO CLIENTS</H2>
The client-local.cfg file resides on the Xymon server.
<P>
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.
<P>
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.
<P>
By default, xymond will look for a matching entry by matching the client
hostname, classname or operating system name against the section expressions.
Hostname matches are used first, then classname matches, then OS matches.
The first match found is the one that is returned to the client.
<P>
If xymond is started with the "--merge-clientlocal" option, then xymond
will instead merge all of the matching sections into one, and return all
of this data to the client. So you can have host-specific entries, and
then supplement them with class- or os-generic entries. Note that the
merging does not remove entries, so if you have e.g. a "log" entry defined
in both a hostname- and an osname-matching section, then both entries
will be sent back to the client.
<P>
<P>
<A NAME="lbAF"> </A>
<H2>FILE FORMAT</H2>
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.
<P>
It will often be practical to use regular expressions for hostnames.
To do this you must use
<P>
<BR> [host=<expression>]
<P>
where <expression> is a Perl-compatible regular expression. The same
kind of matching can be done on operating system or host class, using
<P>
<BR> [os=<expresssion>]
<BR>
<BR> [class=<expression>]
<P>
<P>
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.
<P>
<A NAME="lbAG"> </A>
<H2>LOGFILE CONFIGURATION ENTRIES</H2>
A logfile configuration entry looks like this:
<P>
<BR> log:/var/log/messages:10240
<BR>
<BR> ignore MARK
<BR>
<BR> trigger Oops
<P>
The <B>log:FILENAME:SIZE</B> 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.
<P>
The <B>ignore PATTERN</B> 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.
<P>
The <B>trigger PATTERN</B> 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.
<P>
<A NAME="lbAH"> </A>
<H2>COUNTING LOGENTRIES</H2>
A special type of log-handling is possible, where the number of lines matching
a regular expressions are merely counted. This is <B>linecount:FILENAME</B>,
followed by a number of lines of the form <B>ID:PATTERN</B>. E.g.
<P>
<BR> linecount:/var/log/messages
<BR>
<BR> diskerrors:I/O error.*device.*hd
<BR>
<BR> badlogins:Failed login
<P>
<P>
<A NAME="lbAI"> </A>
<H2>FILE CONFIGURATION ENTRIES</H2>
A file monitoring entry is used to watch the meta-data of a file: Owner,
group, size, permissions, checksum etc. It looks like this:
<P>
<BR> file:/var/log/messages[:HASH]
<P>
The <B>file:FILENAME</B> 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:
<B>md5</B>, <B>sha1</B> or <B>rmd160</B>. By default, no hash is calculated.
<BR>
<B>NOTE:</B> If
you want to check multiple files using a wildcard, you <B>must</B> use
a command to generate the filenames. Putting wildcards directly into
the <B>file:</B> entry will not work.
<P>
<A NAME="lbAJ"> </A>
<H2>DIRECTORY CONFIGURATION ENTRIES</H2>
A directory monitoring entry is used to watch the size of a directory
and any sub-directories. It looks like this:
<P>
<BR> dir:DIRECTORYNAME
<P>
The <B>dir:DIRECTORYNAME</B> 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
<I><A HREF="../man1/du.1.html">du</A>(1)</I>
command with the directoryname as parameter, and send the output back to the
Xymon server.
<BR>
<B>NOTE:</B> If you want to check multiple directories using a
wildcard, you <B>must</B> use a command to generate the directory names. Putting
wildcards directly into the <B>dir:</B> entry will not work. E.g. use something
like
<BR>
<TT> </TT>dir:`find /var/log -maxdepth 1 -type d`<BR>
<P>
The "du" command used can be configured through the <B>DU</B> environment
variable. On some systems, by default <B>du</B> reports data in disk blocks
instead of KB (e.g. Solaris). So you may want to configure the Xymon client
to use a <B>du</B> command which reports data in KB, e.g. by setting
<BR>
<BR> DU="du -k"
<BR>
in the xymonclient.cfg file.
<P>
<A NAME="lbAK"> </A>
<H2>NOTES</H2>
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.
<P>
Use of the directory monitoring on directory structures with a large number
of files and/or sub-directories can be quite ressource-intensive.
<P>
<A NAME="lbAL"> </A>
<H2>SEE ALSO</H2>
<A HREF="../man5/analysis.cfg.5.html">analysis.cfg</A>(5), <A HREF="../man8/xymond_client.8.html">xymond_client</A>(8), <A HREF="../man8/xymond.8.html">xymond</A>(8), <A HREF="../man7/xymon.7.html">xymon</A>(7)
<P>
<P>
<HR>
<A NAME="index"> </A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">PROPAGATION TO CLIENTS</A><DD>
<DT><A HREF="#lbAF">FILE FORMAT</A><DD>
<DT><A HREF="#lbAG">LOGFILE CONFIGURATION ENTRIES</A><DD>
<DT><A HREF="#lbAH">COUNTING LOGENTRIES</A><DD>
<DT><A HREF="#lbAI">FILE CONFIGURATION ENTRIES</A><DD>
<DT><A HREF="#lbAJ">DIRECTORY CONFIGURATION ENTRIES</A><DD>
<DT><A HREF="#lbAK">NOTES</A><DD>
<DT><A HREF="#lbAL">SEE ALSO</A><DD>
</DL>
<HR>
This document was created by
<A HREF="/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 09:41:02 GMT, February 23, 2014
</BODY>
</HTML>
|
