Operations | Monitoring | ITSM | DevOps | Cloud

Once a year, the Icinga team goes for a team event somewhere about an hour or two away from the office. This year’s edition landed us at the Adventure Campus in Treuchtlichen, right in the middle of this year’s first heatwave. The heat was unbearable. At one point we gave up on the room we had been using and moved everyone down into a basement meeting room instead. It was quite a bit more retro in style, with an overhead projector, that we had a lot of fun with.

We are shipping a new batch of Icinga Web ecosystem releases today. Icinga Web 2.14 is the headline, bringing the baseline for two-factor authentication support, configurable password policies, a configurable Content Security Policy, and a round of developer tooling improvements that have been in the works for a while. Icinga Certificate Monitoring 1.4, Icinga Reporting 1.1, and Icinga PDF Export 0.13 join it with PHP 8.5 support across the board and a set of focused improvements for each module.

This release roundup brings together Icinga Web SSO v1.0.0, Icinga Director v1.11.9, and Icinga vSphere Integration v1.8.4. It introduces OpenID Connect single sign-on for Icinga Web and includes compatibility updates for the upcoming Icinga PHP Library 1.0.0 release.

Since I started using Claude Code more frequently, I kept noticing a “worktree” checkbox popping up whenever I started a session in a Git repository. I had no idea what it meant, so I did what any curious developer would do and started digging. What I found was a Git feature I somehow never came across before: git worktrees.

When you work closely with Icinga Web 2, developing modules, building dashboards, poking around the internals, you naturally pick up on features that most users never think about. Some are usability improvements that deserve more attention than they get. Others are developer conveniences that turn out to be genuinely useful in the right user situation too. They’re just the kind of thing that rarely makes it into the getting-started guide. Not all of these will apply to your daily workflow.

A container reporting “up” tells you the process is running, not that the workload is healthy – but that caveat is true of any service, on a container or a bare server.

Most form fields ask users for a single value like a name, an email, or a date. But some need a list of values. A plain text input with comma-separated values can technically do the job, but it gives no feedback while typing, no suggestions, and one invalid entry rejects the whole field. The ipl-web TermInput solves this problem. Each value becomes a separate term with its own validation; terms can be enriched, and the input even supports suggestions.

If you’ve been using Icinga 2 for a while, you probably know the built-in checks cover a lot of ground: disk space, CPU, memory, ping. But sooner or later you’ll run into something specific to your setup that no existing plugin handles. That’s where writing your own plugin comes in. The good news? It’s simpler than it sounds. Icinga 2 doesn’t care what language your plugin is written in. It just runs the script, reads the exit code, and displays the output. That’s it.

Today, we are going to look at a few things related to handling secrets. While Icinga 2 has no dedicated mechanisms for secret handling, there are a few tricks you can do with standard features. This is not meant as a step-by-step tutorial, but rather as an inspiration where you can adopt the ideas that make sense in your setup.

Lots of big companies lock down their IT infrastructure in the internal network, sometimes they even use only locally mirrored repositories. I totally understand this, especially since our CVE-2024-49369. Nowadays, when LLMs find security holes even in OpenBSD, you definitely shouldn’t expose any services to the public without need.