Icinga Web 2 – Where to go today?

Since Alexander showed you how to create a new module for Icinga Web 2 pretty easily (German) some time ago, I’ll continue this today by describing how to add some basic navigation elements to the Hello World-Module.
So we’re currently here:

Subsidiary Menu Entries

To split up our main menu entry on the left hand into additional topics we need to take another look at the configuration.php file:

<?php
$section = $this->menuSection('Hello World', array(
    'url' => 'helloworld'
));

We’ll split it up into two entries in this example:

<?php
$section = $this->menuSection('Hello', array(
    'icon'  => 'globe'
));
$section->add('World', array(
    'url'       => 'helloworld',
    'priority'  => 100
));
$section->add('Universe', array(
    'url'       => 'helloworld/universe',
    'priority'  => 101
));

Who’s taking a closer look will probably notice that our main menu entry doesn’t point to a URL anymore. It’s just a simple entry now whose main purpose is to group other entries together and to expand them once the user clicks on it. But on the other hand it has got a neat icon so that it suits the surrounding entries properly. The two new entries are introducing a new property which is being used to adjust the order of an entry as by default they are in alphabetical order.
The menu should now look as follows:

Tabs

In case another menu entry is not applicable it’s also possible to show some tabs in our views. For convenience’ sake or because I can’t think of an alternative right now we’ll add both menu entries we’ve created earlier again, but this time as tabs. Let’s take a look a the IndexController:

<?php
use Icinga\Web\Controller\ModuleActionController;
class HelloWorld_IndexController extends ModuleActionController
{
    public function indexAction()
    {
        $this->getTabs()->activate('world');
    }
    public function getTabs()
    {
        $tabs = parent::getTabs();
        $tabs->add(
            'world',
            array(
                'title' => 'World',
                'url'   => 'helloworld'
            )
        );
        $tabs->add(
            'universe',
            array(
                'title' => 'Universe',
                'url'   => 'helloworld/universe'
            )
        );
        return $tabs;
    }
}

To actually show the tabs in our view we’ll need to extend the view script for the indexAction: (index.phtml)

<?php if (! $this->compact): ?>
<div class="controls">
  <?= $tabs; ?>
</div>
<?php endif ?>
<div class="content">
  <h1>Hello World</h1>
</div>

You should consider the new template as a convention. No one forces you to use it but doing it exactly this way you’ll make sure that your view is looking properly when being viewed in full-screen mode or on the dashboard.
Due to the fact that the menu entry and tab for the universe is currently leading into the void.. we need to create a controller for this route. To accomplish this we’ll create a new file called UniverseController.php and the respective view script:

<?php
use Icinga\Web\Controller\ModuleActionController;
class HelloWorld_UniverseController extends ModuleActionController
{
    public function indexAction()
    {
        $this->getTabs()->activate('universe');
    }
    public function getTabs()
    {
        $tabs = parent::getTabs();
        $tabs->add(
            'world',
            array(
                'title' => 'World',
                'url'   => 'helloworld'
            )
        );
        $tabs->add(
            'universe',
            array(
                'title' => 'Universe',
                'url'   => 'helloworld/universe'
            )
        );
        return $tabs;
    }
}
<?php if (! $this->compact): ?>
<div class="controls">
  <?= $tabs; ?>
</div>
<?php endif ?>
<div class="content">
  <h1>Hello Universe</h1>
</div>

The file structure should now look as follows:

Columns

Who’s using the monitoring module has probably noticed that not all URLs cause a complete change of context, but are causing Icinga Web 2 to open a new column on your screen. Now to prevent our new route, which we’re going to define, from changing the context we’ll need to change this explicitly.
UniverseController.php

// *Snip*
    public function galaxyAction()
    {
        $galaxy = $this->params->getRequired('galaxy');
        $this->view->galaxy = $galaxy;
    }
    public function getTabs()
// *Snip*

views/scripts/universe/galaxy.phtml

<?php if (! $this->compact): ?>
<div class="controls">
  <?= $tabs->showOnlyCloseButton(); ?>
</div>
<?php endif ?>
<div class="content">
  <h1>Hello <?= $galaxy; ?></h1>
</div>

views/scripts/universe/index.phtml

<!-- *Snip* -->
  <h1>Hello Universe</h1>
  <?= $this->qlink('Greet the Milky Way', 'helloworld/universe/galaxy', array('galaxy' => 'Milky Way')); ?>
  <br>
  <?= $this->qlink('Greet Andromeda', 'helloworld/universe/galaxy', array('galaxy' => 'Andromeda')); ?>
</div>

To greet a galaxy in a new column we’ll have to apply the following change in the view script above:
views/scripts/universe/index.phtml

<!-- *Snip* -->
<div class="content" data-base-target="_next">
<!-- *Snip* -->

This data- attribute accepts the following values:

Value Description
_main Use the first column and close all others (Default)
_self Use the current column, all others are kept as is
_next Use a new column at the right and close the first left column if there’s not enough space available
<id> Use the container with the id <id>. This can be either any HTML-container or one of the predefined column ids: col1, col2

Usage of this attribute is not limited to a specific sub-set of HTML elements and it can be nested freely. This means that only the most significant attribute is being considered when a URL is processed by Icinga Web 2. (e.g. <div data-base-target=”_next”><a data-base-target=”_self” …></a></div> _self is more significant than _next)
We’ve now arrived at the end of this guide. I hope it is informative enough but if there are still questions I’ll recommend you to ask us (me) on the forums. Thanks, see you next time!

Icinga Web 2 v2.0.0-rc1 released

Thank God, RC1 is out!
This release candidate is the result of 751 days of blood, sweat and tears and round about 7K commits in our git. It was not easy and we learned our lessons but now we’re very proud to put a rc tag on Icinga Web 2. Created from scratch, a clean and reduced interface is born with everything you need: Speed, accessible and extensible. The new interface is a monitoring swiss army knife without tailoring or customisation. It is focused on your problems and provide context sensitive interaction with your IT infrastructure.
Please grab another cup of coffee, lean back and enjoy monitoring!
Beside this awesome moment we want to thank all the testers, patchers, issue-openers, developers and all the brave men out there using a so-called beta software already! You are the greatest!
Have you seen the new full screen and compact mode (try /icingaweb2/dashboard?showFullscreen&showCompact as url)? Buts that’s only a small change. RC1 also contains full-featured user- and group management interfaces, enforces restrictions and permissions on every view. And we ship the package with a fully working Postgres 9.1 backend implementation.
Enjoy Icinga Web 2, check the Changelog below and start your download!

What’s New in Version 2.0.0-rc1

Changes

  • Improve layout and look and feel in many ways
  • Apply host, service and custom variable restrictions to all monitoring objects
  • Add fullscreen mode (?showFullscreen)
  • User and group management
  • Comment and Downtime Detail View
  • Show icon_image in host/service views
  • Show Icinga program version in monitoring health

Features

  • Feature 4139: Notify monitoring backend availability problems
  • Feature 4498: Allow to add columns to monitoring views via URL
  • Feature 6392: Resolve Icinga 2 runtime macros in action and notes URLs
  • Feature 6729: Fullscreen mode
  • Feature 7343: Fetch user groups from LDAP
  • Feature 7595: Remote connection resource configuration
  • Feature 7614: Right-align icons
  • Feature 7651: Add module information (module.info) to all core modules
  • Feature 8054: Host Groups should list number of hosts (as well as services)
  • Feature 8235: Show host and service notes in the host and service detail view
  • Feature 8247: Move notifications to the bottom of the page
  • Feature 8281: Improve layout of comments and downtimes in the host and service detail views
  • Feature 8310: Improve layout of performance data and check statistics in the host and service detail views
  • Feature 8565: Improve look and feel of the monitoring multi-select views
  • Feature 8613: IDO queries related to concrete objects should not depend on collations
  • Feature 8665: Show icon_image in the host and service detail views
  • Feature 8781: Automatically deselect rows when closing the detail area
  • Feature 8826: User and group management
  • Feature 8849: Show only three (or four) significant digits (e.g. in check execution time)
  • Feature 8877: Allow module developers to implement new/custom authentication methods
  • Feature 8886: Require mandatory parameters in controller actions and CLI commands
  • Feature 8902: Downtime detail view
  • Feature 8903: Comment detail view
  • Feature 9009: Apply host and service restrictions to related views as well
  • Feature 9203: Wizard: Validate that a resource is actually an IDO instance
  • Feature 9207: Show icinga program version in Monitoring Health
  • Feature 9223: Show the active ido endpoint in the monitoring health view
  • Feature 9284: Create a ServiceActionsHook
  • Feature 9300: Support icon_image_alt
  • Feature 9361: Refine UI for RC1
  • Feature 9377: Permission and restriction documentation
  • Feature 9379: Provide an about.md

Bugfixes

  • Bug 6281: ShowController’s hostAction() and serviceAction() do not respond with 400 for invalid/missing parameters and with 404 if the host or service wasn’t found
  • Bug 6778: Duration and history time formatting isn’t correct
  • Bug 6952: Unauthenticated users are provided helpful error messages
  • Bug 7151: Play nice with form-button-double-clickers
  • Bug 7165: Invalid host address leads to exception w/ PostgreSQL
  • Bug 7447: Commands sent over SSH are missing the -i option when using a ssh user aside from the webserver’s user
  • Bug 7491: Switching from MySQL to PostgreSQL and vice versa doesn’t change the port in the resource configuration
  • Bug 7642: Monitoring menu renderers should be moved to the monitoring module
  • Bug 7658: MenuItemRenderer is not so easy to extend
  • Bug 7876: Not all views can be added to the dashboard w/o breaking the layout
  • Bug 7931: Can’t acknowledge multiple selected services which are in downtime
  • Bug 7997: Service-Detail-View tabs are changing their context when clicking the Host-Tab
  • Bug 7998: Navigating to the Services-Tab in the Service-Detail-View displays only the selected service
  • Bug 8006: Beautify command transport error exceptions
  • Bug 8205: List views should not show more than the five worst pies
  • Bug 8241: Take display_name into account when searching for host and service names
  • Bug 8334: Perfdata details partially hidden depending on the resolution
  • Bug 8339: Lib: SimpleQuery::paginate() must not fetch page and limit from request but use them from parameters
  • Bug 8343: Status summary does not respect restrictions
  • Bug 8363: Updating dashlets corrupts their URLs
  • Bug 8453: The filter column “_dev” is not allowed here
  • Bug 8472: Missing support for command line arguments in the format –arg=
  • Bug 8474: Improve layout of dictionaries in the host and service detail views
  • Bug 8624: Delete multiple downtimes and comments at once
  • Bug 8696: Can’t search for Icinga 2 custom variables
  • Bug 8705: Show all shell commands required to get ready in the setup wizard
  • Bug 8706: INI files should end with a newline character and should not contain superfluous newlines
  • Bug 8707: Wizard: setup seems to fail with just one DB user
  • Bug 8711: JS is logging “ugly” side exceptions
  • Bug 8731: Apply host restrictions to service views
  • Bug 8744: Performance data metrics with value 0 are not displayed
  • Bug 8747: Icinga 2 boolean variables not shown in the host and service detail views
  • Bug 8777: Server error: Service not found exception when service name begins or ends with whitespaces
  • Bug 8815: Only the first external command is sent over SSH when submitting commands for multiple selected hosts or services
  • Bug 8847: Missing indication that nothing was found in the docs when searching
  • Bug 8860: Host group view calculates states from service states; but states should be calculated from host states instead
  • Bug 8927: Tactical overview does not respect restrictions
  • Bug 8928: Host and service groups views do not respect restrictions
  • Bug 8929: Setup wizard does not validate whether the PostgreSQL user for creating the database owns the CREATE ROLE system privilege
  • Bug 8930: Error message about refused connection to the PostgreSQL database server displayed twice in the setup wizard
  • Bug 8934: Status text for ok/up becomes white when hovered
  • Bug 8941: Long plugin output makes the whole container horizontally scrollable instead of just the row containing the long plugin output
  • Bug 8950: Improve English for “The last one occured %s ago”
  • Bug 8953: LDAP encryption settings have no effect
  • Bug 8956: Can’t login when creating the database connection for the preferences store fails
  • Bug 8957: Fall back on syslog if the logger’s type directive is misconfigured
  • Bug 8958: Switching LDAP encryption to LDAPS doesn’t change the port in the resource configuration
  • Bug 8960: Remove exclamation mark from the notification “Authentication order updated!”
  • Bug 8966: Show custom variables visually separated in the host and service detail views
  • Bug 8967: Remove right petrol border from plugin output in the host and service detail views
  • Bug 8972: Can’t view Icinga Web 2’s log file
  • Bug 8994: Uncaught exception on empty session.save_path()
  • Bug 9000: Only the first line of a stack trace is shown in the applications log view
  • Bug 9007: Misspelled host and service names in commands are not accepted by icinga
  • Bug 9008: Notification overview does not respect restrictions
  • Bug 9022: Browser title does not change in case of an error
  • Bug 9023: Toggling feature…
  • Bug 9025: A tooltip of the service grid’s x-axe makes it difficult to click the title of the currently hovered column
  • Bug 9026: Add To Dashboard … on the dashboard
  • Bug 9046: Detail View: Downtimes description misses space between duration and comment text
  • Bug 9056: Filter for host/servicegroup search doesn’t work anymore
  • Bug 9057: contact_notify_host_timeperiod
  • Bug 9059: Can’t initiate an ascending sort by host or service severity
  • Bug 9198: monitoring/command/feature/object does not grant the correct permissions
  • Bug 9202: The config\* permission does not permit to navigate to the configuration
  • Bug 9211: Empty filters are being rendered to SQL which leads to syntax errors
  • Bug 9214: Detect multitple icinga_instances entries and warn the user
  • Bug 9220: Centralize submission and apply handling of sort rules
  • Bug 9224: Allow anonymous LDAP binding
  • Bug 9281: Problem with Icingaweb 2 after PHP Upgrade 5.6.8 -> 5.6.9
  • Bug 9317: Web 2’s ListController inherits from the monitoring module’s base controller
  • Bug 9319: Downtimes overview does not respect restrictions
  • Bug 9350: Menu disappears in user group management view
  • Bug 9351: Timeline links are broken
  • Bug 9352: User list should be sorted
  • Bug 9353: Searching for users fails, at least with LDAP backend
  • Bug 9355: msldap seems not to be a first-class citizen
  • Bug 9378: Rpm calls usermod w/ invalid option on openSUSE
  • Bug 9384: Timeline+Role problem
  • Bug 9392: Command links seem to be broken

Icinga Web 2 – Not everyone is permitted

I would like to present the different ways to define the rights of users in Icinga Web 2. Especially in companies with many employees or with a wide circle of customers this is of high importance to answer the question whether Icinga Web 2 is productively deployable or not. Since we are heading towards our first release candidate, this post should also show what can be expected in the near future.

The Group / Role Concept

First of all, a basic introduction. Those already conversant with this subject may skip this passage. In Icinga Web 2 users (Not to be confused with Icinga’s contacts. Only Icinga Web 2 is aware of its users!) have several ways to log in, e.g. via basic auth, database or Active Directory. When groups have been configured to be assigned to certain users, Icinga Web 2 registers the user´s group assignments after a successful login. Now all necessary information exists to assign the available roles to a user. A role defines permissions and restrictions applicable for specific areas in Icinga Web2.

Permissions

A permission defines thematically the user´s rights according to the motto all or none. Regarding Icinga Web 2 itself this applies to the application’s configuration. Through certain permissions you define what a user is allowed to configure: roles, groups or everything. The monitoring module (the actual heart communicating with Icinga) also provides the possibility of defining permissions. In this case, however, permissions apply to commands. You define whether a user has the permission to do everything or just to add comments, or to send acknowledgments and schedule downtimes. These permissions are not related to specific hosts or services but are equally valid for all.

Restrictions

A restriction is additionally set to a possibly necessary permission and – as its name implies – further restricts the access.
At the moment this is done by the monitoring module for hosts and services and limits the view of the actual objects, and with the release candidate also the corresponding connected data, e.g. comments, downtimes and notifications. As soon as the release candidate is available it will be extended to host and service groups and all possible aliases and custom variables. We have not taken a final decision on whether an automated connection of a user with a contact will be possible.
Regarding the custom variables there is one special feature in the monitoring module: It is possible to completely block access to certain custom variables independently from a role. This usually makes sense when sensitive data exist, like passwords etc.

The URL filtering syntax

As the definitions of a restriction for hosts and services is currently done with a URL filter (just like everywhere in Icinga Web 2) and as there is no assistance available in the corresponding configuration view yet, I will show an example of how such a filter could look like. Astute users may already have tried to use the editor in the corresponding list view because there you can currently compose the desired filters. When all desired filter are applied, its representation appears in the address bar of your browser and can be copied directly.
/icingaweb2/monitoring/list/hosts?(hostgroup_name=customer1|hostgroup_name=customer2)&host_name=office-*
Here you can already see the basic structure of a filter. It can consist of connections (OR |, AND &, NOT !) and comparisons (EQUAL =, NOT EQUAL !=, GREATER >, LESS <, GREATER OR EQUAL >=, LESS OR EQUAL <=). If you want to sum conditions you have to put them in round brackets. If only hosts of the host group “customer2” should apply with certain custom variables, the filter has to be modified as follows: (hostgroup_name=customer1|(hostgroup_name=customer2&_host_support_level>=2))&host_name=office-*
The notation for custom variables regarding services is as follows: _service_variable_name
With this in mind, I wish you lots of fun when assigning permissions and restrictions. See you soon! Next time, I will tell you even more about the pure awesomeness of Icinga Web 2.

Icinga Web 2 – Mastered by the Impaired

So this time I’ll take the opportunity to write a blog post here at icinga.org as well. It’s all about a topic that is mostly overlooked:

Accessibility

Especially in open source it’s not rare that software is either not being adjusted or way later than the initial production use, given the ever-increasing interest and the integration of disadvantaged individuals. In most cases, this is due to the development model. Someone requires a particular tool that doesn’t exist yet or is not as functional as it could be, leading to a new or customized solution that is made available to the public and being adjusted by interested users. In the majority of such conditions, the number of actual users is usually not or only partially predictable, so accessibility is not considered.
In projects that are developed or commissioned by large companies, is, however, usually a special interest in this subject. The product must be fully accessible either because of marketing reasons or prescribed company guidelines, before it can be sold or used productively. Since some time ago a large German company has spoken to us, the „Team Web“ will increasingly put a focus on this subject so that the final version of Icinga Web 2 is really accessible.
We will be guided by two specific standards, but only partially. Especially the “WCAG” standard describes a large number of requirements, whose cost is very high, their relevance for Icinga Web 2, however, is either too small or can’t be estimated by us yet.
Web Content Accessibility Guidelines (WCAG) as well as parts of ISO 9241
These two standards describe the basic features of accessibility in modern web applications as well as the requirements for a successful interaction between man and machine:

  • Colours and contrasts
  • Dialogues
  • Control
  • Navigation
  • Legibility
  • Intelligibility

Accessible Rich Internet Applications Suite (ARIA)
This standard extends HTML, so screen readers can navigate within the web application without error and advanced features that would otherwise be accessible only with the mouse, are also made fully usable with just the keyboard.

In addition, we’ll make sure to use HTML semantically correct. The ever-popular <div> is thus under high scrutiny.
Many improvements will be directly integrated into the framework, but all adjustments limiting Icinga Web 2 in its graphical functionality and the variety of operating elements are realized by means of a dedicated module.