Hi Henrik,

I was reading about 4.5 release and maybe its time to think about store the data into a Database like MySQL/PostgreSQL, if you do that far more contributors can start to colaborate with customs web-interfaces, reports, etc etc.

With best regards,

Giovanni

On Mon, 9 Feb 2009 09:35:40 -0500, <Larry.Sherman at rbs.com> wrote:

Wonderful news Henrik! I have 2 servers waiting for just this occasion.

Many, many thanks to you.

Larry

Larry Sherman RBS Global Banking & Markets Office: +1 203 618 2515

-----Original Message----- From: henrik at hswn.dk [mailto:henrik at hswn.dk] Sent: Monday, February 09, 2009 9:03 AM To: hobbit at hswn.dk Subject: [hobbit] Xymon 4.3.0: Beta version available on Sourceforge

So you didn't think I'd do two releases in one day, eh?

I've uploaded the first beta version of xymon 4.3.0 to Sourceforge a few moments ago. If you have the time and a spare system to test it with, I'd appreciate any effort you can lend me in getting the bugs ironed out.

You should be aware that there IS a lot of new stuff in this version, and I more or less expect it to crash spectacularly in your setup. So putting it on mission- critical systems could be seen as slightly dangerous.

If you have looked at the "trunk" of the sourcecode repository, you will be familiar with the new stuff in this version. However if you compare it to what's in the current beta-release, you will notice that I have left out some of the more "dangerous" new components from this release. This was done to make testing a bit more manageable; I have a lot of new code for Xymon, and throwing all of it into one release would just wreak havoc on everyones systems.

So instead I am preparing for a series of releases over the coming months, where new features will be introduced in a controlled fashion.

But the current release is not void of new stuff. Far from it - here are the highlights of the 4.3.0 version:

Core changes:

• Hosts which appear on multiple pages in the web display can use any page they are on in the alerting rules and elsewhere.
• Support for defining holidays as non-working days in alerts and SLA calculations.
• Worker modules (RRD, client-data parsers etc) can operate on remote hosts from the hobbitd daemon, for load-sharing.
• New API's for loadhosts and sendmessage, in preparation for the full 5.0 changes.
• Always use getcurrenttime() instead of time().
• Various bugfixes collected over time.

Network test changes:

• Merged new network tests from trunk: SOAP-over-HTTP, SSL minimum cipher strength
• Changed network test code to always report a validity period for network tests, so it it possible to run network tests less often than every 30 minutes (e.g. once an hour).
• Make the content-type setting in HTTP POST tests configurable.
• Make the source-address used for TCP tests configurable.
• Make the acceptable HTTP result codes configurable.
• Use and save HTTP session cookies.

Web changes

• "NOCOLUMNS" changed to work for all columns.
• New "group-sorted" definition to auto-sort hosts in a group
• Use browser tooltips for host comments
• "Compact" status allows several statuses to appear as a single status on the overview webpages.
• Trends page can select the time period to show. Buttons provided for the common selections.
• Ghost list report now lists possible candidates for a ghost, based on IP-address or unqualified hostname.
• Support generic drop-down lists in templates.

Report changes

• Number of outages as SLA parameter

Miscellaneous

• hobbitlaunch support for running tasks only on certain hosts, and for a maximum time.
• Alert script get a unique ID for each alert.

The plan for the future is to let this release stabilize for a month or so, depending on how many bugs show up. Then I'll introduce new releases about once every two months - with the following schedule (everything subject to change):

Version 4.4:

• SNMP support for data collection
• Status updates based on data collected in the RRD files (this is really nice - essentially, *any* value you put into an RRD file can trigger a new or modified status in Xymon. So you could eg. change the status of your "http" test to go red, if the response time of a webpage exceeds 5 seconds).
• Status "flap" handling, to catch statuses that change rapidly.

Version 4.5:

• Support for communication between clients and Xymon to use compression and/or encryption.
• Support for client authentication via SSL certificates (so you cannot spoof a client message).

Version 4.6:

• Revised web interface - eliminate the need for webserver-based authentication, and provide more fine-grained authorization for the various Xymon components.
• Per-user custom login pages, so the login will always show those systems that the user has responsibility for / is allowed to access.

Somewhere along the road I will also introduce a new "ping" test daemon - I am getting to the point where ping'ing all hosts take longer than 5 minutes (I have a lot of hosts). So something needs to be done, and I think I know how to do it.

Have fun!

Henrik

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

********************************************************************This message (including any attachments) is confidential and/or privileged. It is to be used by the intended recipients only. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are inherently insecure and susceptible to change. The Royal Bank of Scotland Group, plc ("RBS") and its US subsidiaries, and affiliates and subsidiary undertakings, including but not limited to, RBS plc New York and Connecticut Branches, Greenwich Capital Markets, Inc., ABN AMRO Bank N.V. New York and Chicago Branches and, ABN AMRO Inc., Citizens Financial Group, Inc. and RBS Citizens, N.A., shall not be liable for the improper or incomplete transmission of the information contained in this communication or Attachment nor for any delay in its receipt or damage to your system. RBS does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. RBS and its subsidiaries and affiliates do not guarantee the accuracy of any email or attachment, that an email will be received or that RBS or its affiliates and subsidiaries will respond to an email.

RBS makes no representations that any information contained in this message (including any attachments) are appropriate for use in all locations or that transactions, securities, products, instruments or services discussed herein are available or appropriate for sale or use in all jurisdictions, or by all investors or counterparties. Those who utilize this information do so on their own initiative and are responsible for compliance with applicable local laws or

regulations.********************************************************************

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

On Mon, Feb 09, 2009 at 01:33:37PM -0800, Cleaver, Japheth wrote:

In theory, any backend can be used with the creation of an appropriate hobbitd_channel listener (eg, hobbitd_sqlstore). I was thinking of whipping one up a few days ago using perl DBI::mysql as a test, but was distracted figuring out the proper message-parsing mechanics out of hobbitd_sample.c.

Hey, it sounds like we just got the volunteer I asked for in my response to Giovanni :-)

Seriously, if you would like to work on this then I'll be happy to explain the way your worker module is being fed data from hobbitd. Parsing it in Perl should be pretty straight-forward.

It would help to have a standardized SQL schema for people to base third-party extensions off of though.

Probably, yes :-)

Regards, Henrik

I volunteer for the beta-testing! :-)

On Mon, 9 Feb 2009 14:02:36 -0800, "Cleaver, Japheth" <jcleaver at soe.sony.com> wrote:

Ha! Alright, I'll bite. :) I'd definitely be interested if you'd like to contact me off-list.

-jc

...

-----Original Message----- From: Henrik Størner [mailto:henrik at hswn.dk] Sent: Monday, February 09, 2009 1:39 PM To: hobbit at hswn.dk Subject: Re: [hobbit] SQL storage backends (was RE: [hobbit] Xymon 4.3.0:Beta version available on Sourceforge)

On Mon, Feb 09, 2009 at 01:33:37PM -0800, Cleaver, Japheth wrote:

...

In theory, any backend can be used with the creation of an appropriate hobbitd_channel listener (eg, hobbitd_sqlstore). I was thinking of whipping one up a few days ago using perl DBI::mysql as a test, but

was

...

distracted figuring out the proper message-parsing mechanics out of hobbitd_sample.c.

Hey, it sounds like we just got the volunteer I asked for in my response to Giovanni :-)

Seriously, if you would like to work on this then I'll be happy to explain the way your worker module is being fed data from hobbitd. Parsing it in Perl should be pretty straight-forward.

...

It would help to have a standardized SQL schema for people to base third-party extensions off of though.

Probably, yes :-)

Regards, Henrik

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

Hi Giovanni,

On Mon, Feb 09, 2009 at 07:21:43PM -0200, giovanni at redix.com.br wrote:

Hi Henrik,

I was reading about 4.5 release and maybe its time to think about store the data into a Database like MySQL/PostgreSQL, if you do that far more contributors can start to colaborate with customs web-interfaces, reports, etc etc.

this subject comes up once in a while. I have two problems with it:

1. I've never done any programming that interfaces to a database, so it would mean digging into one more API - but that is something I could probably handle.

2. The real problem is that unless the database is co-located with the Xymon server, then your monitoring suddenly becomes dependant on a remote database-server. So what happens if your database server loses the network connection to the Xymon server ? You won't get any alerts from Xymon, because it has no data available to generate alerts from.

It's the same reason that has kept me from using SAN storage for my production Xymon server at work. Much too complex for my taste, far too many ways it can break.

And the time when you need your Xymon server the most is *exactly* when everything else has gone down in flames.

What I *would* consider is to create a module like the hobbitd_filestore module, except it sends the status-data off to a database somewhere. Or even an external module for hobbitd_rrd that gets all of the parsed data we collect and use as the basis of all of the graphs. Such modules would be very easy to write for someone who knows how to do programming with the database API - my guess is that it wouldn't take more than a day or two.

So if you know someone who could voluteer for such an add-on, I would be very happy to work together with him/her on putting such an add-on together.

Regards, Henrik

Henrik Størner wrote:

2. The real problem is that unless the database is co-located with the Xymon server, then your monitoring suddenly becomes dependant on a remote database-server. So what happens if your database server loses the network connection to the Xymon server ? You won't get any alerts from Xymon, because it has no data available to generate alerts from.

A good number of db applications are implemented in a multi-tier configuration where the db server is separate from the app server. Xymon wouldn't necessarily be different in that respect.

My suggestion would be to leave the database location up to the implementation.

Now you perl zealots will probably freak out, but I probably wouldn't want that database code to be in Perl (sorry Japeth), it's too performance sensitive.

Part of Japeth's idea has great merit here, implement the db layer as DBI code. That way the implementation can choose any DBI compliant database they want.

-- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 http://www.linkedin.com/in/richsmrcina

Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009

How about you alert on the incoming as usual, then store the events (batched or not) into the backend database so that reports can be developed for management, history could use for lookups, etc... That might make this a little more palatable to you, and a lot more usable to those of us who have to prove to management that the time we invest in getting this doing what we want is not a drain on their resources.

Reports are management blood, no reports - no use... (for managers) - I have had managers tell me this in the past. (on the other hand - two weeks after I installed clients on one department's sun servers, the manager had some questions about server performance over the past few weeks = was quite pleased and surprised when I gave him a spreadsheet that laid out the data for all his servers in 1/2 hour, as was even more please when I showed him how to view his page of servers.)

Another thing that using a database to store history in - much better security for those of us who work in security realms and have to protect data - alarm history can give a lot of info away to a hacker if they gain access to the server running the master. With a database, it can be secured and only have authorized users that access it.

One thing everyone should remember - in business, as in life, perception is 80 % of the way things are seen - think about it...

lurch at inorbit.com -------Original Message-------

From: Henrik Størner Date: 2/9/2009 4:40:49 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Xymon 4.3.0: Beta version available on Sourceforge

Hi Giovanni,

On Mon, Feb 09, 2009 at 07:21:43PM -0200, giovanni at redix.com.br wrote:

Hi Henrik,

I was reading about 4.5 release and maybe its time to think about store the data into a Database like MySQL/PostgreSQL, if you do that far more contributors can start to colaborate with customs web-interfaces, reports, etc etc.

this subject comes up once in a while. I have two problems with it:

1. I've never done any programming that interfaces to a database, so it would mean digging into one more API - but that is something I could probably handle.

2. The real problem is that unless the database is co-located with the Xymon server, then your monitoring suddenly becomes dependant on a remote database-server. So what happens if your database server loses the network connection to the Xymon server ? You won't get any alerts from Xymon, because it has no data available to generate alerts from.

It's the same reason that has kept me from using SAN storage for my production Xymon server at work. Much too complex for my taste, far too many ways it can break.

And the time when you need your Xymon server the most is *exactly* when everything else has gone down in flames.

What I *would* consider is to create a module like the hobbitd_filestore module, except it sends the status-data off to a database somewhere. Or even an external module for hobbitd_rrd that gets all of the parsed data we collect and use as the basis of all of the graphs. Such modules would be very easy to write for someone who knows how to do programming with the database API - my guess is that it wouldn't take more than a day or two.

So if you know someone who could voluteer for such an add-on, I would be very happy to work together with him/her on putting such an add-on together.

Regards, Henrik

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

Your comment reminds me of this http://www.flickr.com/photos/straup/2247714432/

On a more serious note, I look forward to storing hobbit information in a relational database. Imagine the reporting flexibility we could have with SQL.

• Give me all server with root file system smaller than 8gb that have been over 80% in the last 3 months.
• give me a list of all servers with operating system X that are running custom test Y. There will be no limits to the level of reporting.

I think it would be a bad idea to abandon the old RRD in favour of RDB, but to rather have the ability to use RRD by default, and RDB as an additional reporting structure. This would limit the dependency issue.

Using an RDB would also allow for custom defined data points. Currently, with RRD, we only store 48 hours of data points at 5 minutes granularity. In an RDB we could define our own retention period. Because of the way RDBs work, there would probably need to be a purge job to purge old data, and accumulate it into data points for the table storing the next level of granularity.

It could be an interesting project, but would need to be very carefully constructed to prevent performance issues. Do we have any database architects on the list?

Regards Vernon

From: Brian Catlin [mailto:bcatlin at gmail.com] Sent: Tuesday, 10 February 2009 11:43 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Xymon 4.3.0: Beta version available on Sourceforge

How about you alert on the incoming as usual, then store the events (batched or not) into the backend database so that reports can be developed for management, history could use for lookups, etc... That might make this a little more palatable to you, and a lot more usable to those of us who have to prove to management that the time we invest in getting this doing what we want is not a drain on their resources.

Reports are management blood, no reports - no use... (for managers) - I have had managers tell me this in the past. (on the other hand - two weeks after I installed clients on one department's sun servers, the manager had some questions about server performance over the past few weeks = was quite pleased and surprised when I gave him a spreadsheet that laid out the data for all his servers in 1/2 hour, as was even more please when I showed him how to view his page of servers.)

Another thing that using a database to store history in - much better security for those of us who work in security realms and have to protect data - alarm history can give a lot of info away to a hacker if they gain access to the server running the master. With a database, it can be secured and only have authorized users that access it.

One thing everyone should remember - in business, as in life, perception is 80 % of the way things are seen - think about it...

lurch at inorbit.com -------Original Message-------

From: Henrik Størner<mailto:henrik at hswn.dk> Date: 2/9/2009 4:40:49 PM To: hobbit at hswn.dk<mailto:hobbit at hswn.dk> Subject: Re: [hobbit] Xymon 4.3.0: Beta version available on Sourceforge

Hi Giovanni,

On Mon, Feb 09, 2009 at 07:21:43PM -0200, giovanni at redix.com.br<mailto:giovanni at redix.com.br> wrote:

Hi Henrik,

I was reading about 4.5 release and maybe its time to think about store the data into a Database like MySQL/PostgreSQL, if you do that far more contributors can start to colaborate with customs web-interfaces, reports, etc etc.

this subject comes up once in a while. I have two problems with it:

1. I've never done any programming that interfaces to a database, so it would mean digging into one more API - but that is something I could probably handle.

2. The real problem is that unless the database is co-located with the Xymon server, then your monitoring suddenly becomes dependant on a remote database-server. So what happens if your database server loses the network connection to the Xymon server ? You won't get any alerts from Xymon, because it has no data available to generate alerts from.

It's the same reason that has kept me from using SAN storage for my production Xymon server at work. Much too complex for my taste, far too many ways it can break.

And the time when you need your Xymon server the most is *exactly* when everything else has gone down in flames.

What I *would* consider is to create a module like the hobbitd_filestore module, except it sends the status-data off to a database somewhere. Or even an external module for hobbitd_rrd that gets all of the parsed data we collect and use as the basis of all of the graphs. Such modules would be very easy to write for someone who knows how to do programming with the database API - my guess is that it wouldn't take more than a day or two.

So if you know someone who could voluteer for such an add-on, I would be very happy to work together with him/her on putting such an add-on together.

Regards, Henrik

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk>

NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments.

What's preventing that now? RRD is a database...Round Robin Database. It has an API and several applications at Tobi's site that already can facilitate this. The real difficulty with the web interface is that it's not fully abstracted from the service. Many of the components are generated within the C code. I seem to recall some effort around assisting with abstracting that layer. Reports can be created and added via shell scripts or other methods (I seem to recall a very nice PDF generation report making the rounds recently).

Adding that DB layer actually makes setup and configuration of Xymon more difficult. I've attempted to work with Nagios (which uses a DB backend) on several occasions and I always come back to Xymon for it's simplicity.

=G=

-----Original Message----- From: giovanni at redix.com.br [mailto:giovanni at redix.com.br] Sent: Monday, February 09, 2009 4:22 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Xymon 4.3.0: Beta version available on Sourceforge

Hi Henrik,

I was reading about 4.5 release and maybe its time to think about store the data into a Database like MySQL/PostgreSQL, if you do that far more contributors can start to colaborate with customs web-interfaces, reports, etc etc.

With best regards,

Giovanni

On Mon, 9 Feb 2009 09:35:40 -0500, <Larry.Sherman at rbs.com> wrote:

Wonderful news Henrik! I have 2 servers waiting for just this occasion.

Many, many thanks to you.

Larry

Larry Sherman RBS Global Banking & Markets Office: +1 203 618 2515

-----Original Message----- From: henrik at hswn.dk [mailto:henrik at hswn.dk] Sent: Monday, February 09, 2009 9:03 AM To: hobbit at hswn.dk Subject: [hobbit] Xymon 4.3.0: Beta version available on Sourceforge

So you didn't think I'd do two releases in one day, eh?

I've uploaded the first beta version of xymon 4.3.0 to Sourceforge a few moments ago. If you have the time and a spare system to test it with, I'd appreciate any effort you can lend me in getting the bugs ironed out.

You should be aware that there IS a lot of new stuff in this version, and I more or less expect it to crash spectacularly in your setup. So putting it on mission- critical systems could be seen as slightly dangerous.

If you have looked at the "trunk" of the sourcecode repository, you will be familiar with the new stuff in this version. However if you compare it to what's in the current beta-release, you will notice that I have left out some of the more "dangerous" new components from this release. This was done to make testing a bit more manageable; I have a lot of new code for Xymon, and throwing all of it into one release would just wreak havoc on everyones systems.

So instead I am preparing for a series of releases over the coming months, where new features will be introduced in a controlled fashion.

But the current release is not void of new stuff. Far from it - here are the highlights of the 4.3.0 version:

Core changes:

• Hosts which appear on multiple pages in the web display can use any page they are on in the alerting rules and elsewhere.
• Support for defining holidays as non-working days in alerts and SLA calculations.
• Worker modules (RRD, client-data parsers etc) can operate on remote hosts from the hobbitd daemon, for load-sharing.
• New API's for loadhosts and sendmessage, in preparation for the full 5.0 changes.
• Always use getcurrenttime() instead of time().
• Various bugfixes collected over time.

Network test changes:

• Merged new network tests from trunk: SOAP-over-HTTP, SSL minimum cipher strength
• Changed network test code to always report a validity period for network tests, so it it possible to run network tests less often than every 30 minutes (e.g. once an hour).
• Make the content-type setting in HTTP POST tests configurable.
• Make the source-address used for TCP tests configurable.
• Make the acceptable HTTP result codes configurable.
• Use and save HTTP session cookies.

Web changes

• "NOCOLUMNS" changed to work for all columns.
• New "group-sorted" definition to auto-sort hosts in a group
• Use browser tooltips for host comments
• "Compact" status allows several statuses to appear as a single status on the overview webpages.
• Trends page can select the time period to show. Buttons provided for the common selections.
• Ghost list report now lists possible candidates for a ghost, based on IP-address or unqualified hostname.
• Support generic drop-down lists in templates.

Report changes

• Number of outages as SLA parameter

Miscellaneous

• hobbitlaunch support for running tasks only on certain hosts, and for a maximum time.
• Alert script get a unique ID for each alert.

The plan for the future is to let this release stabilize for a month or so, depending on how many bugs show up. Then I'll introduce new releases about once every two months - with the following schedule (everything subject to change):

Version 4.4:

• SNMP support for data collection
• Status updates based on data collected in the RRD files (this is really nice - essentially, *any* value you put into an RRD file can trigger a new or modified status in Xymon. So you could eg. change the status of your "http" test to go red, if the response time of a webpage exceeds 5 seconds).
• Status "flap" handling, to catch statuses that change rapidly.

Version 4.5:

• Support for communication between clients and Xymon to use compression and/or encryption.
• Support for client authentication via SSL certificates (so you cannot spoof a client message).

Version 4.6:

• Revised web interface - eliminate the need for webserver-based authentication, and provide more fine-grained authorization for the various Xymon components.
• Per-user custom login pages, so the login will always show those systems that the user has responsibility for / is allowed to access.

Somewhere along the road I will also introduce a new "ping" test daemon - I am getting to the point where ping'ing all hosts take longer than 5 minutes (I have a lot of hosts). So something needs to be done, and I think I know how to do it.

Have fun!

Henrik

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

********************************************************************This message (including any attachments) is confidential and/or privileged. It is to be used by the intended recipients only. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are inherently insecure and susceptible to change. The Royal Bank of Scotland Group, plc ("RBS") and its US subsidiaries, and affiliates and subsidiary undertakings, including but not limited to, RBS plc New York and Connecticut Branches, Greenwich Capital Markets, Inc., ABN AMRO Bank N.V. New York and Chicago Branches and, ABN AMRO Inc., Citizens Financial Group, Inc. and RBS Citizens, N.A., shall not be liable for the improper or incomplete transmission of the information contained in this communication or Attachment nor for any delay in its receipt or damage to your system. RBS does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. RBS and its subsidiaries and affiliates do not guarantee the accuracy of any email or attachment, that an email will be received or that RBS or its affiliates and subsidiaries will respond to an email.

RBS makes no representations that any information contained in this message (including any attachments) are appropriate for use in all locations or that transactions, securities, products, instruments or services discussed herein are available or appropriate for sale or use in all jurisdictions, or by all investors or counterparties. Those who utilize this information do so on their own initiative and are responsible for compliance with applicable local laws or

regulations.********************************************************************

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

Hi Lars,

seems you have really good luck with my test versions today :-)

On Mon, Feb 09, 2009 at 05:40:13PM +0100, Lars Ebeling wrote:

Hobbitd:filestore crashes on HP-UX 11.11

Core was generated by `hobbitd_filest'. Program terminated with signal 6, Aborted.

#4 0x0000e130 in sigsegv_handler (signum=8216) at sig.c:57 #5 <signal handler called> #6 0x0000aa64 in call_locator (buf=0x4004ef58 "X|rrd|leopg9", bufsz=1130) at locator.c:76 #7 0x0000b57c in locator_query (hostname=0x400076b3 "leopg9",
svctype=ST_RRD, extras=0x7bfe3160) at locator.c:342 #12 0x00004bd4 in main (argc=1073772311, argv=0x400076ba) at hobbitd_filestore.c:325

Ok, must admit I have never tested hobbitd_filestore with the RRD graphs running remotely (I don't use that module myself).

The problem appears to be that the code which generates the links to the graph on the status page believe that the graphs are located on another server, so it generates a request to the new "locator" module to figure out where the graph is. Problem is, the locator module was never initialised, so hobbitd_filestore has no idea where the locator is - it doesn't know the IP+portnumber of the locator service.

What commandline were you using to launch the hobbitd_filestore program ?

I think the attached patch should fix it, if you use the right commandline to start hobbitd_filestore. I.e. you must add the "--locator=IP:PORTNUMBER" (probably the IP of your Xymon server, and port 1984) to the hobbitd_filestore command.

Regards, Henrik

Hi guys,

on Solaris 10 sparc I have got the same issue.

Service info, ConfigReports and enable/disable do not work with error "Internal Server Error" and "Premature end of script headers: " in the error_log

The installation of xymon 4.2.2 works successful.

Von: Keith Meserole [mailto:km at keithm.us] Gesendet: Montag, 9. Februar 2009 22:49 An: hobbit at hswn.dk Cc: henrik at hswn.dk Betreff: RE: [hobbit] Xymon 4.3.0: Beta version available on Sourceforge

All,

I loaded 4.3.0 on a Solaris 10 x86 server on top of an existing 4.2.2 installation. Largely it worked well except for the items listed below. The compile log is attached if anyone is curious.

Any suggestions are welcome - I can re-load this as needed.

+++++++++++++++++++++++++++++++++++++++++++++++++++++

Administration | Enable/Disable does not work

http://my-server.net/hobbit-seccgi/hobbit-enadis.sh

"Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, user at testdomain.net and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log."

Apache/2.0.59 (Unix) DAV/2 Server at my-server.net Port 80:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 1.1.4322; .NET CL R 3.0.04506.648) [Mon Feb 09 14:10:14 2009] [error] [client 10.139.201.168] Premature end of script headers: hobbit-enadis.sh, referer: http://my-server.net/hobbit/web/ws1/ws1.html

+++++++++++++++++++++++++++++++++++++++++++++++++++++

Info does not work - similar errors ++++++++++++++++++++++++++++++++++++++++++++++++++++++

All reports, sybpages of tests and web tools are missing the footer file. "link bb_footer" appears at the bottom of the page

++++++++++++++++++++++++++++++++++++++++++++++++++++++

Man pages still seem to be on version 4.2.2

Example CLIENT-LOCAL.CFG Section: File Formats (5) Updated: Version 4.2.2: 15 Dec 2008 Index Return to Main Contents

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

henrik at hswn.dk] -----Original Message----- From: Henrik Størner [mailto:henrik at hswn.dk <mailto:henrik at hswn.dk> ] Sent: Monday, February 09, 2009 9:03 AM To: hobbit at hswn.dk Subject: [hobbit] Xymon 4.3.0: Beta version available on Sourceforge

So you didn't think I'd do two releases in one day, eh?

I've uploaded the first beta version of xymon 4.3.0 to Sourceforge a few moments ago. If you have the time and a spare system to test it with, I'd appreciate any effort you can lend me in getting the bugs ironed out.

You should be aware that there IS a lot of new stuff in this version, and I more or less expect it to crash spectacularly in your setup. So putting it on mission- critical systems could be seen as slightly dangerous.

If you have looked at the "trunk" of the sourcecode repository, you will be familiar with the new stuff in this version. However if you compare it to what's in the current beta-release, you will notice that I have left out some of the more "dangerous" new components from this release. This was done to make testing a bit more manageable; I have a lot of new code for Xymon, and throwing all of it into one release would just wreak havoc on everyones systems.

So instead I am preparing for a series of releases over the coming months, where new features will be introduced in a controlled fashion.

But the current release is not void of new stuff. Far from it - here are the highlights of the 4.3.0 version:

Core changes:

• Hosts which appear on multiple pages in the web display can use any page they are on in the alerting rules and elsewhere.
• Support for defining holidays as non-working days in alerts and SLA calculations.
• Worker modules (RRD, client-data parsers etc) can operate on remote hosts from the hobbitd daemon, for load-sharing.
• New API's for loadhosts and sendmessage, in preparation for the full 5.0 changes.
• Always use getcurrenttime() instead of time().
• Various bugfixes collected over time.

Network test changes:

• Merged new network tests from trunk: SOAP-over-HTTP, SSL minimum cipher strength
• Changed network test code to always report a validity period for network tests, so it it possible to run network tests less often than every 30 minutes (e.g. once an hour).
• Make the content-type setting in HTTP POST tests configurable.
• Make the source-address used for TCP tests configurable.
• Make the acceptable HTTP result codes configurable.
• Use and save HTTP session cookies.

Web changes

• "NOCOLUMNS" changed to work for all columns.
• New "group-sorted" definition to auto-sort hosts in a group
• Use browser tooltips for host comments
• "Compact" status allows several statuses to appear as a single status on the overview webpages.
• Trends page can select the time period to show. Buttons provided for the common selections.
• Ghost list report now lists possible candidates for a ghost, based on IP-address or unqualified hostname.
• Support generic drop-down lists in templates.

Report changes

• Number of outages as SLA parameter

Miscellaneous

• hobbitlaunch support for running tasks only on certain hosts, and for a maximum time.
• Alert script get a unique ID for each alert.

The plan for the future is to let this release stabilize for a month or so, depending on how many bugs show up. Then I'll introduce new releases about once every two months - with the following schedule (everything subject to change):

Version 4.4:

• SNMP support for data collection
• Status updates based on data collected in the RRD files (this is really nice - essentially, *any* value you put into an RRD file can trigger a new or modified status in Xymon. So you could eg. change the status of your "http" test to go red, if the response time of a webpage exceeds 5 seconds).
• Status "flap" handling, to catch statuses that change rapidly.

Version 4.5:

• Support for communication between clients and Xymon to use compression and/or encryption.
• Support for client authentication via SSL certificates (so you cannot spoof a client message).

Version 4.6:

• Revised web interface - eliminate the need for webserver-based authentication, and provide more fine-grained authorization for the various Xymon components.
• Per-user custom login pages, so the login will always show those systems that the user has responsibility for / is allowed to access.

Somewhere along the road I will also introduce a new "ping" test daemon - I am getting to the point where ping'ing all hosts take longer than 5 minutes (I have a lot of hosts). So something needs to be done, and I think I know how to do it.

Have fun!

Henrik

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

I have installed the 4.3.0 Beta on my AIX 5.3 system and am having a few problems, particularly with RRD.

1. The disk graph problem has returned where it seems to have a problem counting the number of separate rrds and misses the last one or two graphs out but creates the missing graph image box.

2. The rrd updating can sometimes lag up to 20 minutes behind and this system is not stressed.

3. One of the processes I was tracking has stopped updating the rrd but still appears in the procs html page as OK.

Regards, Chris

This e-mail including any attachments is provided for general information purposes only and does not constitute advice except to the addressee if expressly stated in this email. For the avoidance of doubt the contents of this email and any attachments are subject to contract and are not intended to and will not constitute a legally binding contract or any part of a legally binding contract.

The information contained in this email and any attachments is confidential. It is intended only for the use of the intended recipient at the email address to which it has been addressed. If the reader of this message is not an intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution or copying of the message or associated attachments is strictly prohibited.

If you have received this e-mail in error, please notify postmaster at RWEsystemsUK.com and permanently delete the email and any attachments immediately from your system. You should not retain, copy or use this email or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you for your co-operation.

Neither RWE IT UK Ltd nor any of the other companies in the RWE Group from whom this e-mail originates accept any responsibility for losses or damage as a result of any viruses and it is your responsibility to check attachments (if any) for viruses.

RWE IT UK Ltd Registered office: Mistral, Westlea Campus, Chelmsford Road, Swindon, Wiltshire, SN5 7EZ. Registered in England and Wales: company number 6052966.

On Tue, Feb 10, 2009 at 06:28:47PM +0000, Keith wrote:

Hi Henrik,

In /tmp I untarred 4.3.O rc1 and did gmake. I downloaded the patch to /tmp and changed directory to lib. Tried to add patch with command.
Patch -p0 /tmp/sendmessage-emptyresponse.patch but this hung and I had to kill the process. Any ideas?

By default, "patch" reads the patch from stdin. So you should use the command

cd /tmp/xymon-4.3.0-RC1 cat /tmp/sendmessage-emptyresponse.patch | patch -p0 gmake

Regards, Henrik

This resolved the 500 errors for me as well.

Henrik Størner wrote:

On Mon, Feb 09, 2009 at 04:48:48PM -0500, Keith Meserole wrote:

...

http://my-server.net/hobbit-seccgi/hobbit-enadis.sh

"Internal Server Error

Info does not work - similar errors

I think this is a pretty widespread bug. The attached patch should fix it, but this code is used throughout Xymon, so a "make clean; make; make install" would probably be needed afterwards.

For testing, you can skip the "make install" and just copy web/*.cgi to your ~xymon/server/bin/ directory.

Let me know if it helps.

Regards, Henrik

---

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

-- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 http://www.linkedin.com/in/richsmrcina

Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009

On Tue, Mar 03, 2009 at 05:18:53PM +0100, Frank Gruellich wrote:

Hi,

Henrik St?rner wrote:

...

• Make the content-type setting in HTTP POST tests configurable.

I tried to make that feature working today, but I can't figure out how to use it. That's what I tried to configure after reading

          If  your  form-data  requires  a different content-type, you can
          specify it by beginning the form-data with  (content-type=TYPE),
          e.g.  "(content-type=text/xml)"  followed by the POST data.

in bb-hosts:

10.35.12.31 jupiter # post;http://10.35.12.31/some/application;(content-type=text/xml)<soapenv><lots_of_stuff></lots_of_stuff><soapenv>

I also tried without parentheses to no avail. tcpdumping around shows that (content-type=text/xml) is quoted directly into the POST and the default application/x-www-form-urlencoded is still there. What am I doing wrong?

Nothing. It's a bug. The attached patch should fix it, this works on all 4.2.x versions out there.

However, SOAP usually requires an extra header (SOAPAction), and the 4.2.x version of Xymon won't generate that. You'll need the 4.3.0 version (in beta, and a new beta is coming shortly) and then you can use the built-in SOAP test for it.

Regards, Henrik