# The client-local.cfg file contains configuration for
# the Xymon clients running on monitored systems. When
# clients contact the Xymon server, they get the section
# from this file which matches their hostname or operating
# system.
#
# The following configuration items are currently possible:
#   "log:FILENAME:MAXDATA"
#       Monitor the text-based logfile FILENAME, and report
#       back at most MAXDATA bytes. The Xymon client will
#       only report back entries generated during the past
#       30 minutes, so MAXDATA is an upper limit.
#   "ignore EXPRESSION"
#       Must follow a "log:..." entry. Lines matching the 
#       regular EXPRESSION are not sent to the Xymon server.
#   "trigger EXPRESSION"
#       Must follow a "log:..." entry. Lines matching the
#       regular EXPRESSION are always sent to the Xymon server.
#       Use this for extremely critical errors that must be
#       reported.
#
#   "linecount:FILENAME"
#       Monitor the text-based logfile FILENAME, but just
#       count the number of times certain expressions appear.
#       This processes the entire file every time. It must
#       be followed by one or more lines with
#   "KEYWORD PATTERN"
#       KEYWORD identifies this count. You can use any string
#       except whitespace. PATTERN is a regular expression
#       that you want to search for in the file.
#
#   "file:FILENAME[:hash]"
#       Monitor the file FILENAME by reporting file metadata.
#       The Xymon client will report back all of the file 
#       meta-data, e.g. size, timestamp, filetype, permissions
#       etc. The optional "hash" setting is "md5", "sha1" or
#       "rmd160", and causes the Xymon client to compute a
#       file hash using the MD5, SHA-1 or RMD160 algorithm.
#       Note: Computing the hash value may be CPU-intensive,
#             so You should use this sparingly. For large-scale
#             file integrity monitoring, use a real host-based
#             IDS (Tripwire, AIDE or similar).
#
#   "dir:DIRECTORY"
#       Monitor the size of DIRECTORY, including sub-directories.
#       This causes the Xymon client to run a "du" on DIRECTORY
#       and send this back to the Xymon server.
#       Note: Running "du" on large/deep directory structures can
#             cause a significant system load.
#
# NB: If FILENAME and/or DIRECTORY are of the form `COMMAND`,
#     then COMMAND is run on the client, and the lines output
#     by the command are used as the file- or directory-names.
#     This allows you to monitor files where the names change,
#     as long as you can script some way of determining the
#     interesting filenames.

[sunos]
log:/var/adm/messages:10240

[osf1]
log:/var/adm/messages:10240

[aix]
log:/var/adm/syslog/syslog.log:10240

[hp-ux]
log:/var/adm/syslog/syslog.log:10240

[win32]

[freebsd]
log:/var/log/messages:10240

[netbsd]
log:/var/log/messages:10240

[openbsd]
log:/var/log/messages:10240

[linux]
log:/var/log/messages:10240
ignore MARK
file:/var/lib/puppet/state/state.yaml

[linux22]
log:/var/log/messages:10240
ignore MARK

[redhat]
log:/var/log/messages:10240
ignore MARK

[debian]
log:/var/log/messages:10240
ignore MARK

[suse]
log:/var/log/messages:10240
ignore MARK

[mageia]
log:/var/log/messages:10240
ignore MARK

[mandrivalinux]
log:/var/log/messages:10240
#log:/var/log/secure:10240
ignore MARK

[redhatAS]
log:/var/log/messages:10240
ignore MARK

[redhatES]
log:/var/log/messages:10240
ignore MARK

[rhel3]
log:/var/log/messages:10240
ignore MARK

[irix]
log:/var/adm/SYSLOG:10240

[darwin]
log:/var/log/system.log:10240

[sco_sv]
log:/var/adm/syslog:10240