Michael Friedrich | 8 Jun 11:22 2011
Picon
Picon

Icinga 1.4.1 released

Icinga 1.4.0 contained several bugs which now have been fixed on the core and web side of development :-)

The XSS vulnerability in the Classic UI reported by Stefan Schurtz has been resolved too. Download Icinga 1.4.1 now!

 

Core/ClassicUI/IDOUtils

* core: fix retain status file over an init script reload #1579

* classic ui: fix cross site scripting vulnerability in config.cgi on config expander arguments #1605
* classic ui: better handling of writing to cgi.log in cmd.cgi #1161
* classic ui: fixing tac.cgi header problems with counting and adding pending and descritptions #1505 #1506 #1508
* classic ui: corrected behaviour of pending states in tac header #1508

* install: fix event handlers cmd file location in contrib #1501

Web/API

* fix LDAP auth allows empty passwords #1596
* fix ilter information wrong after saving cronk #1525
* fix prefs growing endlessly in Icinga-Web causing lot’s of traffic #1513
* fix cronks page make-up #1509
* principals now work with wildcards
* provided IE JS fix

Docs

* CFLAGS for FreeBSD #1604
* show_tac_header_pending #1529

As usual – please report any bugs/feature requests/etc to our development tracker and/or community channels! :-) -- DI (FH) Michael Friedrich Vienna University Computer Center Universitaetsstrasse 7 A-1010 Vienna, Austria email: michael.friedrich-4JhlDu4IDl0juwv8T7myQQ@public.gmane.org phone: +43 1 4277 14359 mobile: +43 664 60277 14359 fax: +43 1 4277 14338 web: http://www.univie.ac.at/zid http://www.aco.net Icinga Core & IDOUtils Developer http://www.icinga.org
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
icinga-devel mailing list
icinga-devel@...
https://lists.sourceforge.net/lists/listinfo/icinga-devel
Robert Marxreiter | 25 Jun 23:36 2011
Picon

Fwd: [Nagios-devel] host/servicegroup commands

Hello,

this bug seems to apply to icinga as well.

Regards
- Robert

-------- Original Message -------- Subject: Date: From: Reply-To: To:
[Nagios-devel] host/servicegroup commands
Sat, 25 Jun 2011 17:11:29 +0200
Sven Nierlein <sven.nierlein-A9AJeghD15qzQB+pC5nmwQ@public.gmane.org>
Nagios Developers List <nagios-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
nagios-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org


Hi, One of our customers found a bug in the nagios cgis. It's easy to reproduce: 1. create a new user 2. give him authorized_for_all_services and authorized_for_all_hosts in your cgi.cfg The contact should now be able to see all hosts and services but should not be allowed to submit any commands. However, if the contact submits hostgroup or servicegroup commands, they are accepted and executed. The attached patch fixes that behavior. Regards, Sven
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
Nagios-devel mailing list
Nagios-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
icinga-users mailing list
icinga-users@...
https://lists.sourceforge.net/lists/listinfo/icinga-users
Matthew Brooks | 26 Jun 00:43 2011

Re: [icinga-users] Fwd: [Nagios-devel] host/servicegroup commands

FYI looks like Ricardo handled it already



2011/6/25 Robert Marxreiter <rmarxreiter-S0/GAf8tV78@public.gmane.org>
Hello,

this bug seems to apply to icinga as well.

Regards
- Robert

-------- Original Message -------- Subject: Date: From: Reply-To: To:
[Nagios-devel] host/servicegroup commands
Sat, 25 Jun 2011 17:11:29 +0200
Sven Nierlein <sven.nierlein-A9AJeghD15qzQB+pC5nmwQ@public.gmane.org>
Nagios Developers List <nagios-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
nagios-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org


Hi, One of our customers found a bug in the nagios cgis. It's easy to reproduce: 1. create a new user 2. give him authorized_for_all_services and authorized_for_all_hosts in your cgi.cfg The contact should now be able to see all hosts and services but should not be allowed to submit any commands. However, if the contact submits hostgroup or servicegroup commands, they are accepted and executed. The attached patch fixes that behavior. Regards, Sven

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
icinga-users mailing list
icinga-users-5NWGOfrQmnc@public.gmane.orgurceforge.net
https://lists.sourceforge.net/lists/listinfo/icinga-users


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
icinga-devel mailing list
icinga-devel@...
https://lists.sourceforge.net/lists/listinfo/icinga-devel
Bernd Erk | 26 Jun 01:53 2011
Picon

Re: [icinga-users] Fwd: [Nagios-devel] host/servicegroup commands

Performance 1+ :-)

On 26.06.11 00:43, "Matthew Brooks" <matthew@...> wrote:

>FYI looks like Ricardo handled it already
>
>https://git.icinga.org/?p=icinga-core.git;a=commit;h=ed01c63
>
>
>
>2011/6/25 Robert Marxreiter <rmarxreiter@...>
>
>
>  
>
>    
>  
>  
>    Hello,
>    
>    this bug seems to apply to icinga as well.
>    
>    Regards
>    - Robert
>    
>    -------- Original Message --------
>    
>      
>        
>          Subject:
>          [Nagios-devel] host/servicegroup commands
>        
>        
>          Date: 
>          Sat, 25 Jun 2011 17:11:29 +0200
>        
>        
>          From: 
>          Sven Nierlein <sven.nierlein@...>
><mailto:sven.nierlein@...>
>        
>        
>          Reply-To:
>          
>          Nagios Developers List
>            <nagios-devel@...>
><mailto:nagios-devel@...>
>        
>        
>          To: 
>          nagios-devel@...
>        
>      
>    
>    
>    
>    Hi,
>
>One of our customers found a bug in the nagios cgis. It's easy to
>reproduce:
>
>1. create a new user
>2. give him authorized_for_all_services and authorized_for_all_hosts in
>your cgi.cfg
>
>The contact should now be able to see all hosts and services but should
>not be allowed to submit any commands.
>However, if the contact submits hostgroup or servicegroup commands, they
>are accepted and executed.
>The attached patch fixes that behavior.
>
>Regards,
>   Sven
>
>
>  
>
>--------------------------------------------------------------------------
>----
>All the data continuously generated in your IT infrastructure contains a
>definitive record of customers, application performance, security
>threats, fraudulent activity and more. Splunk takes this data and makes
>sense of it. Business sense. IT sense. Common sense..
>http://p.sf.net/sfu/splunk-d2d-c1
>_______________________________________________
>icinga-users mailing list
>icinga-users@...
>https://lists.sourceforge.net/lists/listinfo/icinga-users
>
>
>
>
>
>
>--------------------------------------------------------------------------
>----
>All the data continuously generated in your IT infrastructure contains a
>definitive record of customers, application performance, security
>threats, fraudulent activity and more. Splunk takes this data and makes
>sense of it. Business sense. IT sense. Common sense..
>http://p.sf.net/sfu/splunk-d2d-c1_________________________________________
>______
>icinga-devel mailing list
>icinga-devel@...
>https://lists.sourceforge.net/lists/listinfo/icinga-devel

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
http://p.sf.net/sfu/splunk-d2d-c1
Michael Friedrich | 29 Jun 15:50 2011
Picon
Picon

Icinga Core, Classic UI & IDOUtils 1.4.2 released

Due to the recent fixes in 1.4.1 the XSS vulnerability caused the command expander in config.cgi not to work as expected. Alongside this bug, there were various other things to resolve while working on the 1.5 dev branches. All important fixes have been backported into 1.4 tree and can now be found in a revamped 1.4.2 release on Core, Classic UI and IDOUtils.

Download 1.4.2 now or wait for your distribution to push updated packages :-) Special note: 1.4.2 does not require IDOUtils DB upgrading.

Changelog

  • core: fix freshness_threshold problem in host checks by using check_interval in HARD or OK state, else retry_interval (like service checks) #1331
  • classic ui: add a check for status data freshness into cgis #1667
  • classic ui: re-fix xss vulnerability and string escaping for command expansion #1605 #1624
  • classic ui: remove sidebar.html inclusion in index.html causing troubles on reload #1632
  • classic ui: fixed: User can execute host/servicegroup commands even if not authorized for (Sven Nierlein) #1679
  • classic ui: fixed: plugin_output_short didn’t get checked properly and caused segfault in status.cgi #1673
  • idoutils: do not update start_time of already started downtimes #1658
  • idoutils: fix started downtime update for table scheduleddowntime in oracle #1658
  • install: fix make install-idoutils overwrites sample – adding idoutils.cfg-sample instead #1625

 

Please report any bugs/feature requests/etc to our development tracker and/or community channels! :-)

--

https://www.icinga.org/2011/06/29/icinga-core-classic-ui-idoutils-1-4-2-released/
-- DI (FH) Michael Friedrich Vienna University Computer Center Universitaetsstrasse 7 A-1010 Vienna, Austria email: michael.friedrich-4JhlDu4IDl0juwv8T7myQQ@public.gmane.org phone: +43 1 4277 14359 mobile: +43 664 60277 14359 fax: +43 1 4277 14338 web: http://www.univie.ac.at/zid http://www.aco.net Icinga Core & IDOUtils Developer http://www.icinga.org
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
icinga-users mailing list
icinga-users@...
https://lists.sourceforge.net/lists/listinfo/icinga-users
Gunnar Beutner | 29 Jun 14:18 2011
Picon

Icinga Core API

Hello,

as requested by Michael Friedrich I'm pushing the discussion that's so 
far taken place on our internal team list to the icinga-devel list. For 
anyone new to join this discussion here's a short introduction to what 
this is all about:

During the Icinga meet-up last weekend we've discussed some ideas for an 
Icinga Core API and a way to deal with scalability issues in large-scale 
monitoring setups.

The basic idea revolves around using a message queue to decouple 
components like service checks and API methods from the Icinga Core 
while providing a unified interface to these components that can be used 
either locally (i.e. in-process or via IPC) or remotely (via TCP). For 
now we've been thinking about using ZeroMQ for this which is an 
embeddable, (mostly) platform-agnostic message queue library written in C.

You can find an updated in-depth description of the proposed changes 
involved in the MQ implementation at 
https://wiki.icinga.org/display/Dev/Ideas+for+new+Core+API . I'd love to 
hear your feedback about the design specifications which for now are 
primarily being worked on by Ricardo and me.

Best regards
Gunnar Beutner

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
Michael Friedrich | 29 Jun 18:51 2011
Picon
Picon

Re: Icinga Core API

Hi,

Gunnar Beutner wrote:
Hello, as requested by Michael Friedrich I'm pushing the discussion that's so far taken place on our internal team list to the icinga-devel list. For anyone new to join this discussion here's a short introduction to what this is all about:

i do think that such things are way off the hook to be kept internal. those are major changes to be discussed, and not just implemented and thrown at someone.


During the Icinga meet-up last weekend we've discussed some ideas for an Icinga Core API and a way to deal with scalability issues in large-scale monitoring setups.

i wasn't taking part during the meeting, so my opinion only reflects what i was reading and reflecting in the past 3 days.


those things are 2 seperated portions to take care of.

1) a core api

* adding things like mklivestatus already proposed (GET)
* allowing the SET/POST bidirectional communication
* don't introduce external dependencies
* providing compatibility to existing addons

2) a distributed message queue system

* can be done either as (neb) module (mod_gearman!) or on the new core api layer
* stays independent from the existing setup, can be provided "as is" and loaded if demanded
* does the internal message queueing itsself and what might be on the top layer
* doesn't bypass the core api

The basic idea revolves around using a message queue to decouple components like service checks and API methods from the Icinga Core while providing a unified interface to these components that can be used either locally (i.e. in-process or via IPC) or remotely (via TCP). For now we've been thinking about using ZeroMQ for this which is an embeddable, (mostly) platform-agnostic message queue library written in C.

i'd love to hear opinions why exactly this should be zeromq and not rabbitmq or other candicates like described here e.g.
http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes


You can find an updated in-depth description of the proposed changes involved in the MQ implementation at https://wiki.icinga.org/display/Dev/Ideas+for+new+Core+API . I'd love to hear your feedback about the design specifications which for now are primarily being worked on by Ricardo and me.

summarizing the points i've already posted in recent internal mails,

* the newly introduced core api should be used as poc for classicui and integrated live search, providing simple GET hosts in json and nothing more basically


* the libicinga is on top of the mq architecture, which then remains rather independant of the underlaying core architecture. so whatever you are wrapping around, you could still do it a layer down below, if you know what you are doing .... "libicinga is built on zeromq and people tend to use other technologies - like gearman or livestatus wrappers for nagvis, nagiosbp and such. the idea is *not* to reinvent the wheel, but stay compatible to existing solutions. addons devs won't jump onto that just because it's cool and costs dev time."


* the proof of concept for distributed monitoring should take place with the current neb architecture .... "proof of concept as core module - take a look at mod_gearman, and replace that parts with zeromq, realize the proof of concept as neb module with NEB_CALLBACK_OVERRIDE or NEB_CALLBACK_CANCEL and threadinng locks."


* the core api should be extendable. not only for icingamq but also for ...

** idoutils replacement, with a cached worker

** add configs via api, store internally, provide a config editor (or at least a community addon) like demanded over http://feedback.icinga.org/forums/50329-general/suggestions/754152-api-to-add-new-hosts-groups-services-commands-auto?ref=title

[--SNIP--]
1) design a core api capable of that (icingamq doesn't include that by default as far as i have read) 2) allow simple configs to be added into the core, and still written somewhere 3) adopt a config data layout 4) build a custom config web onto that 5) integrate that web in classicui and icingaweb [--SNIP--]

* the core api as well as the icingamq design *must* entirely stay out of the current 1.x tree and probably provided as package to be tested, but not provided officially (and also not supported).
and tbh, this would be something for icinga 2.x where new features can be introduced and some show stoppers can be deprecated whilst introducing new things.


* the message format for icingamq must be discussed either on icinga-devel or icinga-users mailinglists (or a public poll if there was a decision), allowing the community to add their ideas to a general RFC - which needs to be written in the first place.


* evaluate the core logic on the eventloop block for api fetches, or threaded synchronisation. this includes feeding checkresults e.g.


* keep the code clean, follow the style guide and developer guidelines. this includes doxygen and also further documentation / rfcs.



kind regards,
michael

-- DI (FH) Michael Friedrich Vienna University Computer Center Universitaetsstrasse 7 A-1010 Vienna, Austria email: michael.friedrich-4JhlDu4IDl0juwv8T7myQQ@public.gmane.org phone: +43 1 4277 14359 mobile: +43 664 60277 14359 fax: +43 1 4277 14338 web: http://www.univie.ac.at/zid http://www.aco.net Icinga Core & IDOUtils Developer http://www.icinga.org
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
icinga-devel mailing list
icinga-devel@...
https://lists.sourceforge.net/lists/listinfo/icinga-devel
Gunnar Beutner | 30 Jun 09:59 2011
Picon

Re: Icinga Core API

Am 29.06.2011 18:51, schrieb Michael Friedrich:
> Hi,
Hello,

>
> Gunnar Beutner wrote:
>> Hello,
>>
>> as requested by Michael Friedrich I'm pushing the discussion that's so
>> far taken place on our internal team list to the icinga-devel list. For
>> anyone new to join this discussion here's a short introduction to what
>> this is all about:
>
> i do think that such things are way off the hook to be kept internal. 
> those are major changes to be discussed, and not just implemented and 
> thrown at someone.
>
Something as complex as our MQ idea should definitely be able to stand 
up to a certain amount of scrutiny. I'd rather spend more time on 
discussing issues with our design (we're not infallible after all :)) 
than to start coding only to realize later on that we've missed some 
major problems.

>
>>
>> During the Icinga meet-up last weekend we've discussed some ideas for an
>> Icinga Core API and a way to deal with scalability issues in large-scale
>> monitoring setups.
>
> i wasn't taking part during the meeting, so my opinion only reflects 
> what i was reading and reflecting in the past 3 days.
>
>
> those things are 2 seperated portions to take care of.
>
> 1) a core api
>
> * adding things like mklivestatus already proposed (GET)
> * allowing the SET/POST bidirectional communication
> * don't introduce external dependencies
> * providing compatibility to existing addons
>
> 2) a distributed message queue system
>
> * can be done either as (neb) module (mod_gearman!) or on the new core 
> api layer
> * stays independent from the existing setup, can be provided "as is" 
> and loaded if demanded
> * does the internal message queueing itsself and what might be on the 
> top layer
> * doesn't bypass the core api
It would definitely make sense to break down the MQ design into 
individual milestones which can be reviewed independently - we're 
certainly not going to throw a big blob of code at you once everything 
is "finished".

>
>>
>> The basic idea revolves around using a message queue to decouple
>> components like service checks and API methods from the Icinga Core
>> while providing a unified interface to these components that can be used
>> either locally (i.e. in-process or via IPC) or remotely (via TCP). For
>> now we've been thinking about using ZeroMQ for this which is an
>> embeddable, (mostly) platform-agnostic message queue library written in C.
>
> i'd love to hear opinions why exactly this should be zeromq and not 
> rabbitmq or other candicates like described here e.g.
> http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
It doesn't necessarily have to be ZeroMQ. The description on the wiki is 
actually pretty much implementation-agnostic. ZeroMQ is merely what we 
came up with during the weekend and it seems to have a number of 
properties other MQ implementations do not have. For one it doesn't have 
any external dependencies (like Java or Oracle DB) and can be embedded 
directly into applications - without having to run a separate message 
broker.

Obviously RabbitMQ and other MQs have their own advantages too. I'll try 
and come up with a more detailed comparison matrix for the MQ 
implementations we've been investigating so far.

>
>
>> You can find an updated in-depth description of the proposed changes
>> involved in the MQ implementation at
>> https://wiki.icinga.org/display/Dev/Ideas+for+new+Core+API  . I'd love to
>> hear your feedback about the design specifications which for now are
>> primarily being worked on by Ricardo and me.
>
> summarizing the points i've already posted in recent internal mails,
>
> * the newly introduced core api should be used as poc for classicui 
> and integrated live search, providing simple GET hosts in json and 
> nothing more basically
While the first proof-of-concept version of the API/MQ implementation 
will most likely not feature the whole spectrum of API commands we 
shouldn't just focus on read-only GET queries as in doing so we might 
easily miss issues we'll encounter later on (like the whole 
thread-safety issue when updating/creating Icinga objects via the MQ).

>
>
> * the libicinga is on top of the mq architecture, which then remains 
> rather independant of the underlaying core architecture. so whatever 
> you are wrapping around, you could still do it a layer down below, if 
> you know what you are doing .... "libicinga is built on zeromq and 
> people tend to use other technologies - like gearman or livestatus 
> wrappers for nagvis, nagiosbp and such. the idea is *not* to reinvent 
> the wheel, but stay compatible to existing solutions. addons devs 
> won't jump onto that just because it's cool and costs dev time."
>
>
> * the proof of concept for distributed monitoring should take place 
> with the current neb architecture .... "proof of concept as core 
> module - take a look at mod_gearman, and replace that parts with 
> zeromq, realize the proof of concept as neb module with 
> NEB_CALLBACK_OVERRIDE or NEB_CALLBACK_CANCEL and threadinng locks."
>
>
> * the core api should be extendable. not only for icingamq but also 
> for ...
>
> ** idoutils replacement, with a cached worker
>
> ** add configs via api, store internally, provide a config editor (or 
> at least a community addon) like demanded over 
> http://feedback.icinga.org/forums/50329-general/suggestions/754152-api-to-add-new-hosts-groups-services-commands-auto?ref=title
Ideally these components wouldn't be accessing the Core API directly but 
would instead use libicinga. One benefit of that would be that idoutils 
could asynchronously pull event notifications from the message queue and 
process these events without blocking the Icinga Core. In that scenario 
the message queue would also take care of buffering events - which I 
guess is what you meant by "cached worker".

Being able to dynamically reconfigure Icinga would be a very cool 
feature. However the changes required for this lie somewhat outside the 
scope of the API. In order to implement this the Icinga Core would first 
have to provide basic support for this sort of reconfiguration 
(persisting dynamically added objects, ability to remove objects, etc.). 
One thing I'm concerned about here is backwards-compatibility with other 
plugins like mk_livestatus (which probably wouldn't be able to 
gracefully handle deleted objects - not without modifications anyway).

>
> [--SNIP--]
> 1) design a core api capable of that (icingamq doesn't include that by
> default as far as i have read)
> 2) allow simple configs to be added into the core, and still written
> somewhere
> 3) adopt a config data layout
> 4) build a custom config web onto that
> 5) integrate that web in classicui and icingaweb
> [--SNIP--]
>
> * the core api as well as the icingamq design *must* entirely stay out 
> of the current 1.x tree and probably provided as package to be tested, 
> but not provided officially (and also not supported).
> and tbh, this would be something for icinga 2.x where new features can 
> be introduced and some show stoppers can be deprecated whilst 
> introducing new things.
>
>
While it should be made obvious to our users that the Core API/MQ 
feature-set is highly experimental in the first couple of versions (and 
therefore should be disabled by default) having these components as an 
external set of patches or a NEB module would impede our efforts to 
actually get people to test these changes - which is pretty much the 
only way of finding bugs and other problems.

> * the message format for icingamq must be discussed either on 
> icinga-devel or icinga-users mailinglists (or a public poll if there 
> was a decision), allowing the community to add their ideas to a 
> general RFC - which needs to be written in the first place.
>
>
> * evaluate the core logic on the eventloop block for api fetches, or 
> threaded synchronisation. this includes feeding checkresults e.g.
>
>
> * keep the code clean, follow the style guide and developer 
> guidelines. this includes doxygen and also further documentation / rfcs.
>
>
>
> kind regards,
> michael
Best regards,
Gunnar

>
> -- 
> DI (FH) Michael Friedrich
>
> Vienna University Computer Center
> Universitaetsstrasse 7 A-1010 Vienna, Austria
>
> email: 	michael.friedrich@...
> phone: 	+43 1 4277 14359
> mobile: +43 664 60277 14359
> fax: 	+43 1 4277 14338
> web:	http://www.univie.ac.at/zid
> 	http://www.aco.net
>
> Icinga Core&  IDOUtils Developer
> http://www.icinga.org
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
>
>
> _______________________________________________
> icinga-devel mailing list
> icinga-devel@...
> https://lists.sourceforge.net/lists/listinfo/icinga-devel

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2

Gmane