I was thinking the same thing about using the config parameter of the hobbit/bigbrother protocol. Only difference in what I was thinking was one large global file i.e. in the format of the bb-msgstab. Running only every hour is too long for me. Would need some type of tool to check the log(s) with only updated info from the last time the log(s) were checked.

-----Original Message-----
From: Bob Gordon [mailto:rgordonjr at gmail.com] 
Sent: Thursday, January 19, 2006 12:58 PM
To: hobbit at hswn.dk
Subject: [hobbit] Client log parsing (suggestion)


Hi Henrick -

In one of the previous messages, you had mentioned that you

wanted to keep as much configuration data on the server as possible in order to make adminstration easier. To that end I offer the following suggestion for the message configuration..

In the bb man page (4.1.2 early snapshot) there is a section

that reads as follows:

>>>>>>>>>>>>>>
     config FILENAME
          Retrieve one of the Hobbit configuration files from

the server. This command allows a client to pull files from the $BBHOME/etc/ directory on the server, allowing for semi-automatic updates of the client configuration. Since the configuration files are designed to have a common file for the configuration of all hosts in the system - and this is in fact the recommended way of configuring your clients - this makes it easier to keep the configuration files synchronized. >>>>>>>>>>>>>>

Why not set things up as follows:
1 - On the server have a "hobbit-msg" file that contains default

configuration information that applies to all systems. (I.E. Alert on kernel warning and panic messages from the syslog). 2 - In the same directory (or a subdirectory) have seperate hobbit-msg.<servername> files that contain specific configuration information for the specified hosts. 3 - Once an hour (or other configurable time frame) have the client systems issue a command to pull the default file as well as the system specific file from the server. If the client specific file is not available use the default file, otherwise use the standard configuration..

Doing it this way would still allow for central administration

of the configuration files as well as allow for custom message parsing configurations on the target systems..

Anyways..  Just a thought..

Later -

-- 
--==[ Bob Gordon ]==--