Keywords: Supervision, Icinga, Nagios, Linux

3.6. CGI Configuration File Options
Prev | Chapter 3. Configuring Icinga | Next

## 3.6. CGI Configuration File Options

Notes

When creating and/or editing configuration files, keep the following in mind:

1. Lines that start with a '#' character are taken to be comments and are not processed

2. Variables names must begin at the start of the line - no white space is allowed before the name

3. Variable names are case-sensitive

Sample Configuration

| Tip
A sample CGI configuration file (/usr/local/icinga/etc/cgi.cfg) is installed for you when you follow the quickstart installation guide.

Config File Location

By default, Icinga expects the CGI configuration file to be named cgi.cfg and located in the config file directory along with the main config file. If you need to change the name of the file or its location, you can configure Apache to pass an environment variable named ICINGA_CGI_CONFIG (which points to the correct location) to the CGIs. See the Apache documentation for information on how to do this.

Configuration File Variables

Below you will find descriptions of each main Icinga configuration file option...

Main Configuration File Location

Format: | main_config_file=<file_name>
Example: | main_config_file=/usr/local/icinga/etc/icinga.cfg

This specifies the location of your main configuration file. The CGIs need to know where to find this file in order to get information about configuration information, current host and service status, etc.

Physical HTML Path

Format: | physical_html_path=<path>
Example: | physical_html_path=/usr/local/icinga/share

This is the physical path where the HTML files for Icinga are kept on your workstation or server. Icinga assumes that the documentation and images files (used by the CGIs) are stored in subdirectories called docs/ and images/, respectively.

URL HTML Path

Format: | url_html_path=<path>
Example: | url_html_path=/icinga

If, when accessing Icinga via a web browser, you point to an URL like http://www.myhost.com/icinga, this value should be /icinga. Basically, its the path portion of the URL that is used to access the Icinga HTML pages.

URL CGI Path

Format: | url_cgi_path=<path>
Example: | url_cgi_path=/icinga/cgi-bin

This is the path portion of the URL that corresponds to the physical location of the Icinga CGI files. It is evaluated by the cmd.cgi CSRF protection. This value should be changed if the CGI files are accessible under a different path than the default installation path. If not set, the default location will be used (url_cgi_path=url_html_path/cgi-bin).

URL Stylesheet Path

Format: | url_stylesheet_path=<path>/stylesheets
Example: | url_stylesheet_path=/icinga/stylesheets

This option allows to define an url stylesheet path other than the default. This will be useful when adding custom stylesheets in another location. If not set, the default location will be used (url_stylesheets_path=url_html_path/stylesheets).

Authentication Usage

Format: | use_authentication=[0/1]
Example: | use_authentication=1

This option controls whether or not the CGIs will use the authentication and authorisation functionality when determining what information and commands users have access to. We would strongly suggest that you use the authentication functionality for the CGIs. If you decide not to use authentication, make sure to remove the command CGI to prevent unauthorised users from issuing commands to Icinga. The CGI will not issue commands to Icinga if authentication is disabled, but we would suggest removing it altogether just to be on the safe side. More information on how to setup authentication and configure authorisation for the CGIs can be found here.

- 0 = Don't use authentication functionality

- 1 = Use authentication and authorisation functionality (default)

Use Client Certificates

Format: | use_ssl_authentication=[0/1]
Example: | use_ssl_authentication=0

This option controls whether the value of the web server environment variable `REMOTE_USER` or `SSL_CLIENT_S_DN_CN` will be used. The name of the directive is a bit misleading because unless you set up the use of client certificates the value has to be set to zero (0). Setting the value to one (1) requires "`SSLUserName SSL_CLIENT_S_DN_CN`" and several other options in your web server config. Please consult your web server configuration documentation for details.

- 0 = Use web server environment variable `REMOTE_USER` to get the user logged in. Don't use client certificates (default)

- 1 = Use web server environment variable `SSL_CLIENT_S_DN_CN` to get the user logged in. Use client certificates

Default User Name

Format: | default_user_name=<username>
Example: | default_user_name=guest

Setting this variable will define a default username that can access the CGIs. This allows people within a secure domain (i.e., behind a firewall) to access the CGIs without necessarily having to authenticate to the web server. You may want to use this to avoid having to use basic authentication if you are not using a secure server, as basic authentication transmits passwords in clear text over the Internet.

Important: Do not define a default username unless you are running a secure web server and are sure that everyone who has access to the CGIs has been authenticated in some manner! If you define this variable, anyone who has not authenticated to the web server will inherit all rights you assign to this user!

System/Process Information Access

Format: | authorized_for_system_information=<user1>,<user2>,<user3>,...<usern>
Example: | authorized_for_system_information=icingaadmin,theboss

This is a comma-delimited list of names of authenticated users who can view system/process information in the extended information CGI. Users in this list are not automatically authorised to issue system/process commands. If you want users to be able to issue system/process commands as well, you must add them to the authorized_for_system_commands variable. More information on how to setup authentication and configure authorisation for the CGIs can be found here. You can alternatively specify `authorized_contactgroup_for_system_information` to authorise a contactgroup instead of a contact.

System/Process Command Access

Format: | authorized_for_system_commands=<user1>,<user2>,<user3>,...<usern>
Example: | authorized_for_system_commands=icingaadmin

This is a comma-delimited list of names of authenticated users who can issue system/process commands via the command CGI. Users in this list are not automatically authorised to view system/process information. If you want users to be able to view system/process information as well, you must add them to the authorized_for_system_information variable. More information on how to setup authentication and configure authorisation for the CGIs can be found here. You can alternatively specify `authorized_contactgroup_for_system_commands` to authorise a contactgroup instead of a contact.

Configuration Information Access

Format: | authorized_for_configuration_information=<user1>,<user2>,<user3>,...<usern>
Example: | authorized_for_configuration_information=icingaadmin

This is a comma-delimited list of names of authenticated users who can view configuration information in the configuration CGI. Users in this list can view information on all configured hosts, host groups, services, contacts, contact groups, time periods, and commands. More information on how to setup authentication and configure authorisation for the CGIs can be found here. You can alternatively specify `authorized_contactgroup_for_configuration_information` to authorise a contactgroup instead of a contact.

Global Host Information Access

Format: | authorized_for_all_hosts=<user1>,<user2>,<user3>,...<usern>
Example: | authorized_for_all_hosts=icingaadmin,theboss

This is a comma-delimited list of names of authenticated users who can view status and configuration information for all hosts. Users in this list are also automatically authorised to view information for all services. Users in this list are not automatically authorised to issue commands for all hosts or services. If you want users able to issue commands for all hosts and services as well, you must add them to the authorized_for_all_host_commands variable. More information on how to setup authentication and configure authorisation for the CGIs can be found here. You can alternatively specify `authorized_contactgroup_for_all_hosts` to authorise a contactgroup instead of a contact.

Global Host Command Access

Format: | authorized_for_all_host_commands=<user1>,<user2>,<user3>,...<usern>
Example: | authorized_for_all_host_commands=icingaadmin

This is a comma-delimited list of names of authenticated users who can issue commands for all hosts via the command CGI. Users in this list are also automatically authorised to issue commands for all services. Users in this list are not automatically authorised to view status or configuration information for all hosts or services. If you want users able to view status and configuration information for all hosts and services as well, you must add them to the authorized_for_all_hosts variable. More information on how to setup authentication and configure authorisation for the CGIs can be found here. You can alternatively specify `authorized_contactgroup_for_all_host_commands` to authorise a contactgroup instead of a contact.

Global Service Information Access

Format: | authorized_for_all_services=<user1>,<user2>,<user3>,...<usern>
Example: | authorized_for_all_services=icingaadmin,theboss

This is a comma-delimited list of names of authenticated users who can view status and configuration information for all services. Users in this list are not automatically authorised to view information for all hosts. Users in this list are not automatically authorised to issue commands for all services. If you want users able to issue commands for all services as well, you must add them to the authorized_for_all_service_commands variable. More information on how to setup authentication and configure authorisation for the CGIs can be found here. You can alternatively specify `authorized_contactgroup_for_all_services` to authorise a contactgroup instead of a contact.

Global Service Command Access

Format: | authorized_for_all_service_commands=<user1>,<user2>,<user3>,...<usern>
Example: | authorized_for_all_service_commands=icingaadmin

This is a comma-delimited list of names of authenticated users who can issue commands for all services via the command CGI. Users in this list are not automatically authorised to issue commands for all hosts. Users in this list are not automatically authorised to view status or configuration information for all hosts. If you want users able to view status and configuration information for all services as well, you must add them to the authorized_for_all_services variable. More information on how to setup authentication and configure authorisation for the CGIs can be found here. You can alternatively specify `authorized_contactgroup_for_all_service_commands` to authorise a contactgroup instead of a contact.

Show All Services A Host Is Authorized For

Format: | show_all_services_host_is_authorized_for=[0|1]
Example: | show_all_services_host_is_authorized_for=1

By default, a user can see all services on a host, if the user is authorised as contact for the host only. By disabling this option, the user must be an authorised contact for the service too in order to view it. Keep in mind that setting the user in authorized_for_all_services obsoletes this option.

Deny Access To Commands And Comments

Format: | authorized_for_read_only=<user1>,<user2>,<user3>,...<usern>
Example: | authorized_for_read_only=icingalook

This is a comma-delimited list of names of authenticated users who have read-only rights in the CGIs. This will block any host or service commands. It will also block comments from being shown to read-only users. Users in this list are not automatically authorised to view status or configuration information for all hosts. If you want users able to view status and configuration information for all services as well, you must add them to the authorized_for_all_services variable. More information on how to setup authentication and configure authorisation for the CGIs can be found here. You can alternatively specify `authorized_contactgroup_for_read_only` to authorise a contactgroup instead of a contact.

Read-Only For Comments

Format: | authorized_for_comments_read_only=<user1>,<user2>,<user3>,...<usern> | authorized_contactgroup_for_comments_read_only=<contactgroup1>,<contactgroup2>,...<contactgroupn>
Example: | authorized_for_comments_read_only=icingalook | authorized_contactgroup_for_comments_read_only=readonlyusers

This is comma-delimited list of usernames or contactgroups that have rights to view comments in the CGIs. If the user/contactgroup is defined as read-only and you add the same user/contactgroup to this option, then the user/contactgroup can see the comments. If the user is NOT read-only then the options to delete comments in extinfo.cgi are not displayed as well.

| Note
This option is available starting with Icinga 1.8

Read-Only For Downtimes

Format: | authorized_for_downtimes_read_only=<user1>,<user2>,<user3>,...<usern> | authorized_contactgroup_for_downtimes_read_only=<contactgroup1>,<contactgroup2>,...<contactgroupn>
Example: | authorized_for_downtimes_read_only=icingalook | authorized_contactgroup_for_downtimes_read_only=readonlyusers

This is a comma-delimited list of usernames or contactgroups that have rights to view downtimes in the CGIs. If the user is defined as read-only and you add the same user/contactgroup to this options, then the user/contactgroup can still see downtimes. If the user is NOT read-only then the options to delete downtimes in extinfo.cgi are not displayed as well.

| Note
This option is available starting with Icinga 1.8

Lock Author Names

Format: | lock_author_names=[0/1]
Example: | lock_author_names=1

This option allows you to restrict users from changing the author name when submitting comments, acknowledgements, and scheduled downtime from the web interface. If this option is enabled, users will be unable to change the author name associated with the command request.

- 0 = Allow users to change author names when submitting commands

- 1 = Prevent users from changing author names (default)

Default Expiring Disabled Notifications Duration

Format: | default_expiring_disabled_notifications_duration=[seconds]
Example: | default_expiring_disabled_notifications_duration=86400

This option defines the default duration (in seconds) of an expiring for global disabled notifications. Default is 86400 seconds (1 day).

| Note
This option is available starting with Icinga 1.8

Status Show Long Plugin Output

Format: | status_show_long_plugin_output=[0/1]
Example: | status_show_long_plugin_output=1

This option allows you to specify the length of status information in output of status.cgi. If you set the value to 1 it shows the full plugin output instead of the first line only. Default value is 0.

- 0 = Display only the first line of plugin output (default)

- 1 = Display the complete plugin output

Statusmap CGI Background Image

Format: | statusmap_background_image=<image_file>
Example: | statusmap_background_image=smbackground.gd2

This option allows you to specify an image to be used as a background in the statusmap CGI if you use the user-supplied coordinates layout method. The background image is not be available in any other layout methods. It is assumed that the image resides in the HTML images path (i.e. /usr/local/icinga/share/images). This path is automatically determined by appending "/images" to the path specified by the physical_html_path directive.

| Note
The image file can be in GIF, JPEG, PNG, or GD2 format. However, GD2 format (preferably in uncompressed format) is recommended, as it will reduce the CPU load when the CGI generates the map image.

Statusmap Transparency Index Colour

Format: | color_transparency_index_r=<0...255> color_transparency_index_g=<0...255> color_transparency_index_b=<0...255>
Example: | color_transparency_index_r=255

These options set the r,g,b values of the background colour used for the statusmap CGI, so normal browsers that can't show real png transparency set the desired colour as a background colour instead (to make it look pretty). Defaults to white: (R,G,B) = (255,255,255).

Default Statusmap Layout Method

Format: | default_statusmap_layout=<layout_number>
Example: | default_statusmap_layout=4

This option allows you to specify the default layout method used by the statusmap CGI. Valid options are:

<layout_number> Value | Layout Method
0 | User-defined coordinates
1 | Depth layers
2 | Collapsed tree
3 | Balanced tree
4 | Circular
5 | Circular (Marked Up)
6 | Circular (Balloon)

CGI Refresh Rate

Format: | refresh_rate=<rate_in_seconds>
Example: | refresh_rate=90

This option allows you to specify the number of seconds between page refreshes for the status, statusmap, and extinfo CGIs.

CGI Refresh Type

Format: | refresh_type=<0|1>
Example: | refresh_type=1

This option determines what type of refresh should be used. You can choose between http header and javascript. By default javascript (1) is activated. If you have trouble using javascript then try refresh via http header (0).

Audio Alerts

Formats: | host_unreachable_sound=<sound_file> host_down_sound=<sound_file> service_critical_sound=<sound_file> service_warning_sound=<sound_file> service_unknown_sound=<sound_file> normal_sound=<sound_file>
Examples: | host_unreachable_sound=hostu.wav host_down_sound=hostd.wav service_critical_sound=critical.wav service_warning_sound=warning.wav service_unknown_sound=unknown.wav normal_sound=noproblem.wav

These options allow you to specify an audio file that should be played in your browser if there are problems when you are viewing the status CGI. If there are problems, the audio file for the most critical type of problem will be played. The most critical type of problem is on or more unreachable hosts, while the least critical is one or more services in an unknown state (see the order in the example above). Audio files are assumed to be in the media/ subdirectory in your HTML directory (i.e. /usr/local/icinga/share/media).

Escape HTML Tags Option

Format: | escape_html_tags=[0/1]
Example: | escape_html_tags=1

This option determines whether or not HTML tags in host and service (plugin) output is escaped in the CGIs. If you enable this option, your plugin output will not be able to contain clickable hyperlinks.

Notes URL Target

Format: | notes_url_target=[target]
Example: | notes_url_target=_blank

This option determines the name of the frame target that notes URLs should be displayed in. Valid options include _blank, _self, _top, _parent, or any other valid target name.

Action URL Target

Format: | action_url_target=[target]
Example: | action_url_target=_blank

This option determines the name of the frame target that action URLs should be displayed in. Valid options include _blank, _self, _top, _parent, or any other valid target name.

Tac Show Only Hard State

Format: | tac_show_only_hard_state=[0/1]
Example: | tac_show_only_hard_state=1

This option allows you to specify if the tactical overview should only show hard states on hosts and services. If you set this option to 1 the tactical overview shows only states on hosts and services. By default disabled, all states will be shown.

Splunk Integration Option

Format: | enable_splunk_integration=[0/1]
Example: | enable_splunk_integration=1

This option determines whether integration functionality with Splunk is enabled in the web interface. If enabled, you'll be presented with "Splunk It" links in various places in the CGIs (log file, alert history, host/service detail, etc). Useful if you're trying to research why a particular problem occurred. For more information on Splunk, visit http://www.splunk.com/.

Splunk URL

Format: | splunk_url=<path>
Example: | splunk_url=http://127.0.0.1:8000/

This option is used to define the base URL to your Splunk interface. This URL is used by the CGIs when creating links if the enable_splunk_integration option is enabled.

Persistent Acknowledge Comments

Format: | persistent_ack_comments=<0|1>
Example: | persistent_ack_comments=1

This option controls the initial state of the check box "persistent comment" to acknowledge problem hosts or services. It can be used to reinstate the behaviour of Nagios 2. Default is "0" to be compatible with Nagios 3.

- 0 = Leave check box "persistent comment" unchecked (default)

- 1 = Set check box "persistent comment"

Set field separator for CSV export

Format: | csv_delimiter=<char>
Example: | csv_delimiter=,

This option determines the character which should act as field separator. Default is a semicolon (;).

Set field enclosure character for CSV export

Format: | csv_data_enclosure=<char>
Example: | csv_data_enclosure='

This option determines the character which should be used to enclose fields. Default is a single quote (').

Show initial states

Format: | showlog_initial_states=<0|1>
Example: | showlog_initial_states=1

This option allows you to specify if initial states of hosts and services should be shown in showlog.cgi.

| Note
This option only works if the option "log_initial_states" in icinga.cfg is set to 1.

- 0 = Don't show initial states in showlog.cgi (default)

- 1 = Show initial states in showlog.cgi

Show current states

Format: | showlog_current_states=<0|1>
Example: | showlog_current_states=1

This option allows you to specify if current states of hosts and services should be shown in showlog.cgi.

| Note
This option only works if the option "log_current_states" in icinga.cfg is set to 1.

- 0 = Don't show current states in showlog.cgi (default)

- 1 = Show current states in showlog.cgi

Show object type in tab title

Format: | tab_friendly_titles=<0|1>
Example: | tab_friendly_titles=1

Activating this option changes the <title> of status.cgi and extinfo.cgi when they refer to a single host, service, or group.

They will then read:

- [Host]

- {HostGroup}

- ServiceDesc @ Host

- (ServiceGroup)

These are easier to read and find if you use (many) tabs in your browser.

- 0 = Don't show object type in tab title

- 1 = Show object type in tab title (default)

Show service state and notification number

Format: | add_notif_num_hard=n
| add_notif_num_soft=n
Example: | add_notif_num_hard=28

Set this to an OR of the service state identifiers for which status.cgi should not only report "attempts" (e.g., "3/3" for a HARD non-OK state with max_check_attempts=3) but also the current notification number ("(#0)" if no problem notification has been sent yet, etc.). This is helpful to identify services which switched between different non-OK states a lot, or services which have a first_notification_delay set and are "not yet officially" considered in trouble.

Relevant values from include/statusdata.h (look them up *there* if you want to be *really* sure):

     #define    SERVICE_PENDING     1
     #define    SERVICE_OK          2
     #define    SERVICE_WARNING     4
     #define    SERVICE_UNKNOWN     8
     #define    SERVICE_CRITICAL   16

You'll likely want to use add_notif_num_hard=0 (default) or add_notif_num_hard=28 (warn+crit+unknown).

There's an add_notif_num_soft affecting services in a SOFT state for sake of completeness, too.

Set HTTP character set

Format: | http_charset=<char-set>
Example: | http_charset=utf-8

This is the character set which is sent with HTTP headers. Default is utf-8.

Set first day of week

Format: | first_day_of_week=<0|1>
Example: | first_day_of_week=1

This sets the first day of the week which is used in several CGI-reports. Default is 0 = sunday. 1 = monday will be suitable for countries adhering to ISO 8601.

Logging of CGI commands

Format: | use_logging=<0|1>
Example: | use_logging=1

This option enables the logging of CGI commands in a separate log file. Default is 0 = logging disabled, 1 = logging enabled.

CGI log file

Format: | cgi_log_file=<file_name>
Example: | cgi_log_file=/usr/local/icinga/share/log/icinga-cgi.log

This option sets the location of the CGI log file.

CGI log file rotation method

Format: | log file rotation method=<d|w|m>
Example: | cgi_log_rotation_method=d

This is the rotation method that you would like Icinga to use for your CGI log file. Values are as follows:

- n = None (do not rotate the log)

- h = Hourly (rotate the log at top of the hour)

- d = Daily (rotate the log at midnight each day - this is the default)

- w = Weekly (rotate the log at midnight on Saturday)

- m = Monthly (rotate the log at midnight on the last day of the month)

CGI Log Archive Path

Format: | cgi_log_archive_path=<archive directory>
Example: | cgi_log_archive_path=/usr/local/icinga/share/log

This is the directory where Icinga should place CGI log files that have been rotated. This option is ignored if you choose to not use the CGI log rotation functionality.

Enforce comments on actions

Format: | enforce_comments_on_actions=<0|1>
Example: | enforce_comments_on_actions=1

Enforces the need to enter a comment on actions entered via the CGIs. 0 = do not enforce comment (default), 1 = enforce comment.

| Note
The option use_logging has to be enabled, otherwise there will be no logging of comments.

Show header with tactical information

Format: | show_tac_header=<0|1>
Example: | show_tac_header=0

There's a new CGI driven top frame that is enabled by default. The new view has a similar feel to the header that is in Icinga Web and includes important tactical and monitor performance information so you can always be informed of issues.

If you want to keep the old minimalistic look, the new CGI top view can be disabled with the directive: `show_tac_header=0`

The layout for the display of entries for each type is "X / Y / Z" where:

X = Active unacknowledged
Y = Passive unacknowledged
Z = Acknowledged

The X/Y/Z numbers themselves are click-able and will bring you to a list of all the services or hosts related to the respective entry.

Colouring for these entries has the following logical flow:

     1+ / *  / *  = Full colour, full saturation
     0  / 1+ / *  = Full colour but desaturated, rim coloured
     0  / 0  / 1+ = Rim coloured, text coloured and bold
     0  / 0  / *  = Grey

These colours are located in `html/stylesheets/tacheader.css` for easy customisation. For example, if your setup is distributed and primarily depends upon passive checks then you may prefer to make passive check issues stand out with the same colouring as active checks.

Figure 3.1. Example of new header

Show header including pending counts

Format: | show_tac_header_pending=<0|1>
Example: | show_tac_header_pending=0

This option enables the display of pending counts in the tac header. If your display is less than 1024x768 and this is enabled, the tactical information may not fit well in the top frame. By default it is disabled.

Set default downtime duration

Format: | default_downtime_duration=n
Example: | default_downtime_duration=7200

This option defines the default duration (in seconds) of fixed and flexible downtimes. Default is 7200 seconds (2 hours).

Suppress objects in maintenance/downtime state

Format: | suppress_maintenance_downtime=<0|1>
Example: | suppress_maintenance_downtime=0

The current Classic UI view shows the state of hosts including attention grabbing colours even if the host/service is scheduled for downtime. This tends to distract from discerning which problems really exist between those which were planned or expected. It is disabled by default to maintain the old behaviour, however those wishing to enable it will note that rather than displaying issues in their regular colour, they will be grey (similar to the pending state). The status, however will still display the actual state and this is intended behaviour. This is so the user can use icinga to see what the state is in before the downtime ends. A useful example for this is so it can be seen that a host/service that was being worked on actually came back online. In addition, hosts in scheduled downtime will be grey in the statusmap.cgi.

Show partial hostgroups

Format: | show_partial_hostgroups=<0|1>
Example: | show_partial_hostgroups=1

By default (meaning the directive is not present or disabled), a user only sees a hostgroup and the hosts within it if they are an authorised contact for all of the hosts of the group. The behaviour can be changed using the directive `show_partial_hostgroups=1`.

When enabled, the hostgroups overview will show a partial listing of hosts that the user is an authorised contact for within each hostgroup.

It will also add the string "(Partial Hostgroups Enabled)" to the top of the Hostgroup Overview to help prevent any confusion over whether the option is in use or not. However for privacy reasons, hostgroups that are only showing a partial listing are not specifically indicated.

COMPATIBILITY NOTICE: As with any tweak made to the output of the CGIs, enabling this option may adversely impact third party programs that rely on 'screen scraping' to get their information. If you encounter such a problem, turn this option back to its default of off and encourage the developer(s) of the program to use JSON for their data needs instead.

Highlight rows in status.cgi

Format: | highlight_table_rows=<0|1>
Example: | highlight_table_rows=0

This option allows you to define if table rows in status.cgi will be highlighted or not. Sometimes with a lot of rows or a large screen resolution it is hard to see which rows you are working on: Values: 0 = disables row highlighting; 1 = enables row highlighting (default).

Select state to be shown while pending

Format: | use_pending_states=<0|1>
Example: | use_pending_states=0

This option determines what states should be displayed in the web interface for hosts/services that have not yet been checked. Values: 0 = leave hosts/services that have not been checked yet in their original state; 1 = mark hosts/services that have not been checked yet as PENDING (default).

Set expiration period of acknowledgements

Format: | default_expiring_acknowledgement_duration=<n>
Example: | default_expiring_acknowledgement_duration=86400

This option allows you to define the period (in seconds) after which acknowledgements will expire (meaning they will be deleted). The default is 86,400 seconds (one day).

Show child host(s)

Format: | extinfo_show_child_hosts=<0|1|2>
Example: | extinfo_show_child_hosts=1

This option allows you to specify if the extended host information cgi will show child hosts for the selected host.

- 0 = disabled (default)

- 1 = only show immediate child host(s)

- 2 = show immediate and subsequent child host(s)

| Important
Option 2 could be a real performance killer in large installations, so use with care.

| Note
This option is disabled by default as it can degrade overall performance.

Allow user(s) for FULL command line view

Format: | authorized_for_full_command_resolution=<user1>,<user2>,<user3>,...<usern>
Example: | authorized_for_full_command_resolution=icingaadmin

This option is a comma-delimited list of all usernames that can view a command in config command expander as Icinga would execute it. To resolve all MACROS it is necessary to allow read access to the web server for `resource.cfg` as well.

Alternatively you can specify contactgroups, too.

| Important
$USERXX$ vars and custom vars can contain sensitive data so access should be strictly limited.

Display Host/Status Status Totals

Format: | display_status_totals=0|1
Example: | display_status_totals=0

This option allows you to specify if the Host Status Totals and Service Status Totals should be displayed. Default value is 0.

Limit number of page entries to be displayed

Format: | result_limit=<n>
Example: | result_limit=50

This options specifies the number of page entries displayed by default in various cgi's. To display all entries by default set this value to 0. Default is 50.

| Note
This option is available starting with Icinga 1.8

Convert user name to lowercase

Format: | lowercase_user_name=0|1
Example: | lowercase_user_name=1

This option controls whether or not the username is converted to all lowercase letters. Can be useful if the username is stored in Active Directory (case-insensitive). Default is 1.

| Note
This option is available starting with Icinga 1.8

Set initial state of "Send notification" checkbox

Format: | send_ack_notifications=0|1
Example: | send_ack_notifications=1

This option controls the initial state of the "Send Notification:" checkbox when acknowledging a problem. Set this to 1 to send notifications by default and 0 to not. This default value may be overridden in the CGI dialogue. The default is 1 (send notifications on problem acknowledgement).

| Note
This option is available starting with Icinga 1.9

Set initial state of "Set Expire time" checkbox

Format: | set_expire_ack_by_default=0|1
Example: | set_expire_ack_by_default=1

This option controls the initial state of the "Use Expire Time:" checkbox when acknowledging a problem. Set this to 1 to use expiry by default and 0 to not. The default is 0 (do not use auto-expiry). This may be overridden in the CGI dialogue.

| Note
This option is available starting with Icinga 1.9

Enable Classic UI Standalone Installation

Format: | standalone_installation=0|1
Example: | standalone_installation=1

This option controls if Classic UI is used as standalone setup. This option was mainly implemented for Icinga 2 and its compat layer, but may be helpful in other setups as well, like for a standalone dashboard next to the default install. Enabling this option will make Classic UI ignore the main_config_file setting and require all options to be set in cgi.cfg instead. The section "Standalone (Icinga 2)" within the sample config holds all needed settings.

| Note
This option is available starting with Icinga 1.9

Allow viewing partial service groups

Format: | show_partial_servicegroups=0|1
Example: | show_partial_servicegroups=1

By default (meaning the directive is not present or disabled), a user only sees a servicegroup and the hosts and services within it if she is an authorised contact for all of the hosts and services of the group. The behaviour can be changed using the directive `show_partial_servicegroups=1`. When enabled, the servicegroups overview will show a partial listing of hosts and services that the user is an authorised contact for within each servicegroup. It will also add the string "(Partial Servicegroups Enabled)" to the top of the Servicegroup Overview to help prevent any confusion over whether the option is in use or not. However for privacy reasons, servicegroups that are only showing a partial listing are not specifically indicated.

Disable CSRF protection for command cgi

Format: | disable_cmd_cgi_csrf_protection=0|1
Example: | disable_cmd_cgi_csrf_protection=1

By default (meaning the directive is not present or disabled), a command submitted by an external program (like Nagstamon) accessing cmd.cgi directly will be rejected to protect against CSRF attacks (Cross-Site Request Forgery). Enable (=1) this option only if you need this functionality.

- 0 - disabled, protect against CSRF attacks (default)

- 1 - enabled, allow external programs to submit commands

| Note
This option is available starting with Icinga 1.11

Exclude display of custom variable names

Format: | exclude_customvar_name=<name1[,name2,...]|*>
Example: | exclude_customvar_name=<password>

Custom variables are visible in the Classic UI (as of Icinga 1.11). Due to the fact that some names contain sensitive information it should be possible to hide it from the user. The directive "exclude_customvar_name" specifies a comma-separated list of strings. Variable names containing these strings will not be displayed. Specifying "*" instead of a list will exclude all custom variable names.

| Note
This option is available starting with Icinga 1.11

Exclude display of custom variable values

Format: | exclude_customvar_value=<value1[,value2,...]|*>
Example: | exclude_customvar_value=<secret>

Custom variables are visible in the Classic UI (as of Icinga 1.11). Due to the fact that some values contain sensitive information it should be possible to hide it from the user. The directive "exclude_customvar_value" specifies a comma-separated list of strings. Variable values containing these strings will not be displayed. Specifying "*" instead of a list will exclude all custom variable values.

| Note
This option is available starting with Icinga 1.11

Sort status data by default

Format: | sort_status_data_by_default=<0|1>
Example: | sort_status_data_by_default=<0>

This option forces status.cgi to sort status data by default. Data will be sorted ascending. First by host name and then by service description. This is helpful if status data in status.dat is not sorted properly. This can occur especially if you use Icinga2. By default this options is switched off (0) to avoid possible higher cpu load in huge environments.

| Note
This option is available starting with Icinga 1.12

State of stickiness of acknowledgements

Format: | set_sticky_acknowledgment=<0|1>
Example: | set_sticky_acknowledgment=<0>

This option controls the initial state of the "Sticky Acknowledgment:" checkbox when acknowledging a problem. Set this to 1 to force stickiness by default and 0 to not. The default is 1 (ACKs are sticky). This may be overridden in the CGI dialogue.

| Note
This option is available starting with Icinga 1.12

Prev | Up | Next
3.5. Custom Object Variables | Home | Chapter 4. Running Icinga

© 1999-2009 Ethan Galstad, 2009-2015 Icinga Development Team, http://www.icinga.org