Icinga

6.4. Executing Classic UI modules (CGIs) on the command line

6.4.1. Introduction
6.4.2. Prerequisites
6.4.3. Examples

6.4.1. Introduction

In most cases you will use your browser to retrieve the information you need. There may be situations where you want to process the data with other tools to create wiki entries, send mails and so on. Together with the information on the CGI parameters you can call the Classic UI modules from the command line.

6.4.2. Prerequisites

Before actually calling the modules you have to set three environment variables:

  • REMOTE_USER

    This variable is set to the user which has permission to retrieve the information. In most cases this will be "icingaadmin" (set REMOTE_USER='icingaadmin')

  • REQUEST_METHOD

    set REQUEST_METHOD='GET'. Possible values are "GET", "POST" and "HEAD"

  • QUERY_STRING

    Instead of passing arguments to the modules via the command line you have to set the variable "QUERY_STRING" with the appropriate values.

    [Note] Note

    Most people find it difficult to read HTML output so it may be a good idea to add "jsonoutput" or "csvoutput" to this variable (QUERY_STRING='jsonoutput&...' or QUERY_STRING='jsonoutput') .

If you forgot to set the environment variables you'll receive the following lines:

 $> ./status.cgi
 getcgivars(): Unsupported REQUEST_METHOD -> ''

 I'm guessing you're trying to execute the CGI from a command line.
 In order to do that, you need to set the REQUEST_METHOD environment
 variable to either "GET", "HEAD", or "POST". When using the
 GET and HEAD methods, arguments can be passed to the CGI
 by setting the "QUERY_STRING" environment variable. If you're
 using the POST method, data is read from standard input. Also of
 note: if you've enabled authentication in the CGIs, you must set the
 "REMOTE_USER" environment variable to be the name of the user you're
 "authenticated" as.

6.4.3. Examples

[Note] Note

The modules are called from within the folder which contains the *.cgi files (e.g. /usr/local/icinga/sbin). This is not necessary but for the sake of simplicity. Unless otherwise specified the REQUEST_METHOD is set to 'GET'.

Tactical overview

 $> set QUERY_STRING='jsonoutput'
 $> ./tac.cgi

All hosts in DOWN state

 $> set QUERY_STRING='jsonoutput&style=hostdetail&hoststatustypes=4'
 $> ./status.cgi

All hosts in DOWN state being unacknowledged and not in a downtime

 $> set QUERY_STRING='jsonoutput&style=hostdetail&hoststatustypes=4&hostprops=10'
 $> ./status.cgi

All service in non-OK state

 $> set QUERY_STRING='jsonoutput&style=detail&servicestatustypes=28'
 $> ./status.cgi

All services being in CRITICAL state and being passive checks

 $> set QUERY_STRING='jsonoutput&style=detail&servicestatustypes=28&serviceprops=65536'
 $> ./status.cgi

Comments for all objects

 $> set QUERY_STRING='jsonoutput&type=3'
 $> ./extinfo.cgi

Trends for router_02 specifying a custom timeperiod using unix timestamps

 $> set QUERY_STRING='jsonoutput&host=router_02&timeperiod=custom&t1=130748400&t2=1307570400'
 $> ./extinfo.cgi

Trends for router_02 specifying a custom timeperiod using date and time

 $> set QUERY_STRING='jsonoutput&host=router_02&timeperiod=custom\
 &sday=6&smon=6&syear=2011&shour=0&smin=0&ssec=0\
 &eday=7&emon=6&eyear=2011&ehour=0&emin=0&esec=0'
 $> ./extinfo.cgi

(to be continued)