Provided by: hobbit_4.2.0.dfsg-12_i386 bug


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




       The  client-local.cfg  file  contains  settings  that  are used by each
       Hobbit 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
       Hobbit client into reporting any data about the logfile. Next, you must
       configure hobbit-clients.cfg so the Hobbit 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 Hobbit server.

       When clients connect to the Hobbit server to send in their client data,
       they will receive part of this file back from the Hobbit  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, Hobbit 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 Hobbit server.
       FILENAME is usually an explicit full-path filename on the client. If it
       is  enclosed in backticks, it is a command which the Hobbit 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 Hobbit server. It is used to remove completely
       unwanted   "noise"  entries  from  the  logdata  processed  by  Hobbit.
       "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
       Hobbit 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.


       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 Hobbit
       client will run the du(1) command with the directoryname as  parameter,
       and send the output back to the Hobbit 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 Hobbit
       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 Hobbit 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  Hobbit  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-


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