> So - I think some other solution is needed, and I've been
> thinking about how to do it. So far it's just ideas - no
> code. But I believe the log checking has to happen on each
> client, but controlled by a central configuration. So what I
> plan to implement is something like this:
>
> * The configuration of what logs to monitor and what strings to
> look for is maintained on the central Hobbit server, either as
> an addition to the hobbit-clients.cfg file, or in a separate
> file - that isn't really important.
> * When a client connects and sends in a client-side message, the
> Hobbit server accepts the client message, but also sends back
> the current log-check configuration info. By re-using the
> client connection, the overhead involved in pushing the
> configuration to each client becomes almost nil.
> * When the client has a log-check configuration, it knows what logs
> to check for what strings, and can include that information in
> the normal client message it sends back to the Hobbit server.
> That means the client will need a tool to do the logfile checking;
> probably using a client-side regular-expression matching tool
> like "grep". It can either be built into the Hobbit client, or
> it could just rely on the existing "grep" utility found on the
> system - this would probably be the simplest to implement.
>
I had come to the same conclusion when trying to think how to implement
msgs tests in a 'hobbit' way. So it seems that hobbit needs some manner
of 'push' mechanism. Of course this is just pushing configuration, but
since you are talking about a 'push' mechanism what about pushing files
too ? Though this option may be cosidered a security hole. But this
would be nice for pushing out updates. Whether it is a full Hobbit
client update, or if a particular script/test needed to be pushed out
and updated.
Pushing out files could be a configureable option that can be
enable/disabled.