[Blue-devel] Latest Registry, Agent and Remote checking code.

[Rob B. <rob...@ar...>]

All,

I've checked in the latest registry, agent and the remote checking code 
that I have been working on.

The remote checking works in the following ways. The agent can now be 
started with the -d option and a configuration file. This instructs the 
agent to enter "daemon" only mode. The daemon only mode simply opens a 
socket on port 5667 (the same as used by NRPE) and listens for requests 
to execute plugins.

The plugins that can be executed by the daemon are defined the 
configuration file. The commands must be defined in the following way:

command[command_name]=command_line

so
command[check_local_time=java -jar blue-check-local-time.jar -H 
europe.pool.ntp.org -w 30 -c 50

The agent also supports an option called allow_command_arguments in 
which the user can send arguments across with the name of the plugin to 
execute. In this case the agent will replace all macros in the command 
definition with the values received from the request:

i.e.
command[check_local_time]=java -jar blue-check-local-time.jar -H $ARG1$ 
-w $ARG2$ -c $ARG3$

would have the $ARG$ values replaced with those sent in the command 
definition. The replacing of the $ARGs$ values still needs to be 
implemented, I ran out of time this week.

The agent can also open the checking port when it registers with the 
remote blue server. So this allows for remote command executions to be 
completed with dynamic registration. All that is needed is that the 
command definition on the Blue Server uses the check_remote plugin.

As mentioned there is also now a check_remote plugin. This is a first 
pass at this and it uses JBoss remoting to connect to the remote service 
launched by the agent. It simply takes a remote host name, the name of a 
command to execute, the transport to use (defaults to socket and this is 
the only one that I've implemented so far), the port to connect on and 
then any args to pass to the remote plugin. It returns the output of the 
remote plugin and the exit code of the remote plugin to the main Blue 
process.

The agent has also been designed so that the user can pass the class 
name of the command to execute so for instance 
org.blue.plugins.check_local_time. This is so we can run plugins in the 
same vm as the Agent and simply instantiate an instance of the class 
rather than running exec(). I haven't implemented this functionality yet 
as there is a bit of work to do on the plugins side of things to get 
them running in vm.

I have also left the agent with the ability to contact a remote 
repository server to download any plugins that it does not have. The 
obvious thinking behind this is that it means that plugins do not have 
to be installed on remote hosts before they can be checked. Currently 
you will need to have the plugins.jar on the classpath of the agent on 
the remote host.

The agent is also zipped and tarred up into a distributable format, so 
within the ~blue directory you should see blue-agent.zip and 
blue-agent.tar.gz. This should allow people to easily distribute the 
agent to any remote hosts.

One other thing of note, I have replaced the jbossall-client.jar with 
the individual jars that are required. This helped to reduced the 
footprint of the agent dramatically. I've placed this .jar files into 
${lib} as they are shared between the registry, the check_remote plugin 
and the agent.

I'd appreciate any comments & feedback on all this.

cheers

Rob

-- 
Registered Office: Floor A, Milburn House, Dean Street, Newcastle upon Tyne, NE1 1LE
VAT Registration No: 764173128. Company registered in England 
Registration No: 4497081