blue-devel Mailing List for blue

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

hello blue

http://steamphone.com/Papa.php?various=hgz1nn6r4bt61

Regards
mlugert

Hi All,

I have the CVS checkout(anonymous), and tried to run the blue by the 2 
.sh scripts on linux machine, but it is giving me error.

Failed to load Main-Class manifest attribute from blue-console.jar

The same error appear if try to run server script.

Help !!

Lokesh

Hello,

I am testing blue 0.8.1 (from the sourceforge archive) on OpenVMS (Alpha and Itanium servers). It works pretty well. Plugins blue-check-ping et blue-check-ftp are ok but plugin blue-check-nt (used with NSClient++) returns an error for UPTIME and dumb results for USEDDISKSPACE.

Do you have developped new plugins (for example, blue-check-http and blue-check-snmp) ?

When do you plan the next release of blue ?

Best regards. 

All,

The registry code is about 75% refactored, but is not yet complete.

I hope to have this ready in the next couple of days.

cheers

Rob

On 5/16/07, Rob Blake <rob...@ar...> wrote:
>
> All,
>
> The agent code has been refactored and is now available under
> org.blue.star.registry.agent. I'll be updating the build file shortly to
> extrapolate the build of the agent from within the registry target.
>
> Next on the list is to re-factor the registry code.
>
> 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
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Blue-devel mailing list
> Blu...@li...
> https://lists.sourceforge.net/lists/listinfo/blue-devel
>

All,

The agent code has been refactored and is now available under 
org.blue.star.registry.agent. I'll be updating the build file shortly to 
extrapolate the build of the agent from within the registry target.

Next on the list is to re-factor the registry code.

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

All,

I've begun the process of refactoring the registry code to the
org.blue.starpackaging structure.

cheers

Rob

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4302520
By: akuns

I have not tried this. 
There are three parts to blue
1. server
2. console
3. plugins

I wrote something which starts blue and jetty/console in one shot to simplify.
you can run server and console separate, the main console is a war with just
servlets.
Should just drop right into any app server.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4300685
By: ikomarenko

Hi all.

I would like to try Blue in WebSphere Application Server. I know that Blue is
integrated with Jetty Web Server, but I think Blue also should work great in
WebSphere Application Server.

Did anyone try Blue in WebSphere or any other Application Server?

Thanks,

Ihor

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4279288
By: rob_blake

Rob,

No that class is the actual code for the check_http plugin itself. But it looks
like the plugin code is being bundled up with the web application code as well.
I can't really see a reason for this to be so (other than it's easier for our
build process to include everything that way) so I'll open up a low priority
feature request to get this ironed out for the next release.

The code that you are interested in running is the blue-check-http.jar that
resides in the $BLUE_HOME directory. Essentially this acts as a wrapper for
the check_http.class so when you run java -jar blue-check-http.jar from within
Blue, its actually calling the check_http.class. The version of the check_http.class
that is executed is contained within the blue-plugins.jar (hence me wondering
why there is a need for us to bundle the plugin code with the webapp other than
for ease of build) in the ~lib directory of your Blue installation. The
blue-check-http.jar version does a few house keeping tasks such as setting the
correct classpath for the check_http.class. The check_http plugin makes use
of the commons-httpclient libraries from Apache and these need to be on the
classpath of the plugin at runtime.

Thanks for the testing offer. Any feedback is appreciated. I'll try and set
aside some time for finishing off the check_http plugin shortly.

cheers

Rob

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4278551
By: rgjordan

Let me know if I can help with testing. So the following java class has to do
with the admin/config app server rather than the http service check?

/opt/blue/webapps/blue/WEB-INF/classes/org/blue/plugins/check_http.class

Thanks,

Rob

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4277519
By: rob_blake

Rob,

Yeah it does look like you are calling the plugin incorrectly.

To get it working, your $USER1$ macro should be pointing to the install location
of your Blue directory i.e. /opt/blue

The command to get it working will be:

java -jar $USER1$/blue-check-http.jar -H $ARG1$ -p $ARG2$ -u $ARG3$

If I remember rightly the check_http.java plugin isn't quite finished yet. Hopefully
I'll have some spare time shortly to get it completed.

cheers

Rob

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4271994
By: rgjordan

I think I'm calling the plugin incorrectly.

I have a similar plugin working in nagios:
./check_http -H some.website.com -p 80 -u /index.html

Here's what I have setup in Blue:
Macro ID:
1	/opt/blue/webapps/blue/WEB-INF/classes/org/blue/plugins

Command (check_http):
java $USER1$/check_http -H $ARG1$ -p $ARG2$ -u $ARG3$

Service:
check_http !some.website.com!8890!/index.html

Log:
[1177077953] SERVICE ALERT:
some.website.com;website_http;WARNING;HARD;5;libgcj-java-placeholder.sh

Thanks,

Rob

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812

As part of some renaming we had to bite the bullet ....

I moved over everything EXCEPT registry, though had to update the code
for this to point to package structure.

All source is org.blue.star.....

Painful migration/syncrhonization.... 
You might want to move over your local code to org.blue.star and then
sync to see changes.  I know my changes were not clean (I got in some of
my other changes as well) but i have run a build and started some
testing. 

Rich

Realize that the system needs to be abstract enough to call something
from the command line.   The key item in making all languages first
class is to NOT use a java interface as the mechanism by which to
integrate things.  If everything plays on the same level, all languages
can integrate the same exact way.  Hence if you write a neb module for
blue it could/might work with nagios. 

Yes we could have an interface and then a command line implementation to
leverage those from nagios.  But why complicate?  Make it simple, dead
simple.  

I realize you lose flexiblity, but you gain decision and forward
movement.   

On Tue, 2007-04-10 at 07:33 -0700, Mark Lugert wrote:
> So I'm a little confused with why we use this pattern.  Typically when
> writing modules that plug-in to a system you provide an API, which is
> what your abstract class would become, and make the module implement
> an interface.  Then you use reflection to load up all the modules and
> call the proper methods when the time comes.
>  
> This is how blue does plug-ins also.  Is there a reason for this, or
> is it just the way nagios did it and we kept that pattern?
>  
> -mark
> 
> 
> ----- Original Message ----
> From: Rob Blake <rob...@gm...>
> To: "Blue, a java port of Nagios" <blu...@li...>
> Sent: Tuesday, April 10, 2007 7:44:21 AM
> Subject: Re: [Blue-devel] Blue Neb Module Interface.
> 
> Further to this I've also added an abstract class,
> org.blue.nebmodules.BaseBlueNebModule, that can be used as a base from
> which to implement Blue NEBModules. It simplifies the process of
> registering your callbacks and deregistering your callbacks. 
> 
> Rob
> 
> On 4/2/07, Rob Blake <rob...@ar...> wrote: 
>         All,
>         
>         I've added a BlueNebModule interface to the package
>         org.blue.nebmodules.
>         The interface defines the methods required of all Blue NEB
>         Modules. This
>         work is a pre-cursor to doing something similar to NDOUtils. 
>         
>         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
>         
>         
>         ------------------------------------------------------------------------- 
>         Take Surveys. Earn Cash. Influence the Future of IT
>         Join SourceForge.net's Techsay panel and you'll get the chance
>         to share your
>         opinions on IT & business topics through brief surveys-and
>         earn cash
>         http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>         _______________________________________________ 
>         Blue-devel mailing list
>         Blu...@li...
>         https://lists.sourceforge.net/lists/listinfo/blue-devel 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Blue-devel mailing list
> Blu...@li...
> https://lists.sourceforge.net/lists/listinfo/blue-devel
> 
> 
> 
> 
> ______________________________________________________________________
> The fish are biting.
> Get more visitors on your site using Yahoo! Search Marketing.
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________ Blue-devel mailing list Blu...@li... https://lists.sourceforge.net/lists/listinfo/blue-devel

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4256497
By: akuns

I agree NRPE and Blue Agent should be the same thing. 

I think the repository idea is perfect, and a very very very simple
version of that would be to use http:// or https:// as the location of
the jars.  Blue Agent can use http://my-blue-server/plugins/ as the
directory to pull in jar files.   I know this is not a real repo
concept, but would work fairly well.   JBoss use something like this
concept in one of it's startup modes.  Similar to an applet. 

Other option use jnlp to launch the agent?

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812

So I'm a little confused with why we use this pattern.  Typically when writing modules that plug-in to a system you provide an API, which is what your abstract class would become, and make the module implement an interface.  Then you use reflection to load up all the modules and call the proper methods when the time comes.

This is how blue does plug-ins also.  Is there a reason for this, or is it just the way nagios did it and we kept that pattern?

-mark

----- Original Message ----
From: Rob Blake <rob...@gm...>
To: "Blue, a java port of Nagios" <blu...@li...>
Sent: Tuesday, April 10, 2007 7:44:21 AM
Subject: Re: [Blue-devel] Blue Neb Module Interface.

Further to this I've also added an abstract class, org.blue.nebmodules.BaseBlueNebModule, that can be used as a base from which to implement Blue NEBModules. It simplifies the process of registering your callbacks and deregistering your callbacks. 

Rob

On 4/2/07, Rob Blake <rob...@ar...> wrote:
All,

I've added a BlueNebModule interface to the package org.blue.nebmodules.
The interface defines the methods required of all Blue NEB Modules. This
work is a pre-cursor to doing something similar to NDOUtils. 

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

------------------------------------------------------------------------- 
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ 
Blue-devel mailing list
Blu...@li...
https://lists.sourceforge.net/lists/listinfo/blue-devel 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Blue-devel mailing list
Blu...@li...
https://lists.sourceforge.net/lists/listinfo/blue-devel

____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html
Further to this I've also added an abstract class,
org.blue.nebmodules.BaseBlueNebModule, that can be used as a base from which
to implement Blue NEBModules. It simplifies the process of registering your
callbacks and deregistering your callbacks.

Rob

On 4/2/07, Rob Blake <rob...@ar...> wrote:
>
> All,
>
> I've added a BlueNebModule interface to the package org.blue.nebmodules.
> The interface defines the methods required of all Blue NEB Modules. This
> work is a pre-cursor to doing something similar to NDOUtils.
>
> 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
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Blue-devel mailing list
> Blu...@li...
> https://lists.sourceforge.net/lists/listinfo/blue-devel
>

All,

I've checked in an update to the org.blue.base.nebmods class. It fixes an
issue whereby NebModules were not being loaded when the
neb_register_callback method was called. I've also added an additional check
to the code to verify that any NEBModule loaded implements the interface
org.blue.nebmodules.BlueNebModule.

Rob

All,

I've added a BlueNebModule interface to the package org.blue.nebmodules. 
The interface defines the methods required of all Blue NEB Modules. This 
work is a pre-cursor to doing something similar to NDOUtils.

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

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4222622
By: rob_blake

I've checked in the first version of the code to remove objects from Blue on
the fly.

cheers

Rob

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812

All,

I've checked in the latest registry & agent code. If you have the chance 
to play with this, please do as I'd really appreciate some feedback.

I also checked in two new commands, namely delete_host and 
delete_service. As the name would suggest, they enable you to remove 
hosts/services from blue on the fly. The commands try to be as clean as 
they can be by firstly stopping all checks of any hosts/services 
specified in these commands. To facilitate this I have also checked in 
an update to commands.java, which is explained below.

There are three changes to commands.java. The first is to expose a new 
method, namely disable_host_services(objects_h.host host). This method 
will disable all services on a given host. While I appreciate that there 
is an external command for this task already, this simple extension 
prevents us from having to write to the external command file.

There are also two updates to commands.java to fix bug id 1686153. The 
bug has been logged on the tracker and the fix has been checked in.

There is also an update to objects.java. Within objects.java there are 
several new methods:

remove_host(string hostname),
remove_host_services(string hostname)
remove_host_from_host_list(string hostname)
remove_host_from_host_hashlist()
remove_host_from_hostgroups
remove_host_from_hostgroups_list
remove_host_from_hostgroups_hashlist()

and the same for services. These are there to support the above commands 
that allow objects to be removed from Blue.

I've also checked in an extremely small update to blue.java. In this 
I've moved the location in which the embedded console is started. Blue 
will now complete sanity checks of it's configuration before attempting 
to launch the console. It became increasingly annoying having to wait 
for the console to load only for Blue to bail out due to an error in the 
config files.

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

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4216909
By: rob_blake

Further to this, I'm now about 50% through the code to remove objects from the
object and xod systems.

Hopefully should have this completed within the next day or so.

cheers

Rob

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4216597
By: rob_blake

All,

I've added a further option to the dynamic_template object defintion. This option
is persist_registration. It instructs the dynamic registry as to whether or
not registrations of this type should be made persistent over restarts of the
Blue Server. At the moment this simply means that the generated .cfg file for
the dynamically registered host will be stored into a specified cfg_dir.

Rob

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4216461
By: rob_blake

All,

As discussed on the mailing list, there is now an initial version of an NRPE-esque
daemon checked in. It is part of the Blue Agent code and can be started either
as an individual service on the remote host, or can be used in conjunction with
dynamic registration to allow for execution of plugins on dynamically registered
hosts.

NRPE in Blue follows the same stance as NRPE in Nagios. The first of the components
is a plugin called check_remote. The plugin has the following options:

-H  = remote host to check
-P  = Port of remote host to connect to.
-C  = Name of check to execute
-T  = transport to use to connect to remote host (currently socket only)
args = anything further is assumed to be args to the remote check.

The plugin is executed as with any other in blue, java -jar check-remote.jar
and command defintions within Blue should be reflective of their distributed
nature i.e.

define command{
 command_name   check_remote_time
 command_line   java -jar blue-check-remote.jar -H $HOSTADDRESS$ -C
check_remote_time
}

With regards to how the command is configured on the remote host, currently
it makes use of the configuration files that are associated with the Blue Agent.
The configuration of commands is in the following format:

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

when receiving a request to execute a command, the agent will consult it's list
of pre-registered commands and then execute them accordingly.

The user also has the ability to pass command arguments to the remote command,
so the above command definition could be refactored as follows:

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

For this to work, the user must enabled allow_command_arguments in the configuration
file of the Blue Agent.

Rob

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812

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

2006	Jan	Feb	Mar	Apr	May (8)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2007	Jan	Feb (16)	Mar (13)	Apr (11)	May (5)	Jun	Jul	Aug	Sep	Oct (1)	Nov (1)	Dec
2016	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec

blue-devel Mailing List for blue

blue-devel — Blue Development Mailing List