Provided by: xymon_4.3.0~beta2.dfsg-9.1_amd64 bug


       client-local.cfg - Local configuration settings for Xymon clients




       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

       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.


       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


       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.


       A logfile configuration entry looks like this:

           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


       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.

           diskerrors:I/O error.*device.*hd
           badlogins:Failed login


       A file monitoring entry is used to watch the meta-data of  a  file:  Owner,  group,  size,
       permissions, checksum etc. It looks like this:


       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.


       A  directory  monitoring  entry  is  used  to  watch  the size of a directory and any sub-
       directories. It looks like this:


       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.


       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

       Use of the directory monitoring on directory structures  with  a  large  number  of  files
       and/or sub-directories can be quite ressource-intensive.


       hobbit-clients.cfg(5), hobbitd_client(8), hobbitd(8), xymon(7)