Like many, I’ve been experimenting with Claude recently and tried to explore not only its capabilities, but of course also its limitations. The illusion that I could assign it a task and the AI tool would easily execute the work vanished quickly and I experienced rather the latter. Not only did easy tasks burn a lot of tokens quickly and I hit my limits rather than expected, the results also weren’t that convincing. So in this post, I will give you some insights into how I utilized the Figma MCP with Claude Code. I experimented with creating a new design system from scratch, starting with a standard Button set. For the first effort I let Claude create a ShadCN-like documentation project. ShadCN already provides a library of standard UI components so it acted as a great reference for the beginning. I also referenced Tailwind CSS since it features a solid concept for CSS modifiers for variants. I did not want to clutter my system, so I asked for a no install approach. On top of that, I asked to create variables for a tokenized approach. The goal was, that I will have global design tokens in Figma to make the […]

The post I tried to build a design system with Figma and Claude from Scratch appeared first on Icinga.

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. In this post we will build a small “weekday picker” to show the core features of the TermInput. Let’s start with a minimal working setup, a form with a single TermInput. <?php namespace Icinga\Module\Test\Forms; use ipl\Web\Compat\CompatForm; use ipl\Web\FormElement\TermInput; use ipl\Web\FormElement\TermInput\Term; use ipl\Web\Url; class WeekdayPickerForm extends CompatForm { protected function assemble(): void { $weekdays = (new TermInput('weekdays', [ 'label' => 'Selected weekdays', ])) ->setRequired() ->setVerticalTermDirection() ->setReadOnly(); $this->addElement($weekdays); $this->addElement('submit', 'save', ['label' => 'Save']); } } setVerticalTermDirection() stacks the selected terms below the input field instead of showing them inline. setReadOnly() means existing terms can’t be edited, only removed. setRequired() requires at least one term to be selected before submitting. This already allows the user to enter any term they like and displays it […]

The post IPL: How to use the ipl-web TermInput appeared first on Icinga.

Today, we are announcing the release of Icinga 2 v2.16.1 which fixes an issue with some performance data writers. We have received a number of problem reports for v2.16.0 which could be traced back to some rework of the writers we did in that version. These issues can prevent Icinga 2 from working entirely and we are still investigating the exact cause. This release effectively reverts the ElasticsearchWriter, GraphiteWriter, GelfWriter, InfluxdbWriter, Influxdb2Writer, and OpenTsdbWriter features to the state they were in v2.15.3, to bring back the more reliable functionality in the meantime. Additionally, the documentation now clarifies that the OTLPMetricsWriter for OpenTelemetry is not available on some older Linux distributions (Debian 11, Ubuntu 22.04, Amazon Linux 2) due to dependency version constraints. As usual, the source code of this new version is available on GitHub, packages are from our package repositories, and new container images will soon be pushed to Docker Hub and the GitHub Container Registry.

The post Icinga 2 v2.16.1 Bugfix Release appeared first on Icinga.

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. In this post we’ll build a real-world example: a plugin that checks whether a fresh backup file exists in a directory. If the newest backup is older than expected, we want to know about it. What Icinga 2 Expects From a Plugin Every Icinga 2 plugin follows the same simple contract: Exit Code Meaning 0 OK 1 WARNING 2 CRITICAL 3 UNKNOWN The plugin should print one line of output (optionally followed by | perfdata for graphs) and exit with one of the codes above. That’s the entire interface. Create the Plugin We want to check: is there a backup file in a given directory that is newer than X minutes? Here’s the full PHP plugin: […]

The post How to Create Your Own Plugins and Check Commands in Icinga 2 appeared first on Icinga.

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. Hiding Secret Values in Lambdas If you add vars.example_password = "N0t4n4cTuAlP4S5w0rd" to a service definition, the value is synced to the database and may be shown in the custom variables section in Icinga Web, unless they are limited by the icingadb/denylist/variables or icingadb/protect/variables restrictions. However, there is a neat little trick you can do: Just write vars.example_password = {{ "N0t4n4cTuAlP4S5w0rd" }} instead. {{ ... }} is the shorthand syntax for an anonymous lambda function that takes no parameters (the long form would be () => { ... }). Usually, lambdas are used if you want to have a short piece of code generating a dynamic value. However, nothing is stopping you from just returning a constant string. If you use "$example_password$" in a macro string, functions will be evaluated transparently, so it will work the same in your CheckCommands, but […]

The post Tips and Tricks for Handling Secrets in Icinga 2 appeared first on Icinga.

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. But there’s a disadvantage. Firewalling a service makes it harder to get a regular domain validated certificate, e.g. from Let’s Encrypt. It can’t simply verify your web server because latter is behind your firewall. In the past, sysadmins just bought a TLS certificate once a year and updated their Puppet/Ansible. Unfortunately, since March 15 this year, newly issued certificates must not be valid for longer than 200 days. Next year it will be 100 days and in 2029 even only 47 days. Imagine you have to manually renew all services’ TLS certificates every 47 days… Luckily, the ACME protocol offers an alternative to the CA directly contacting the service to issue a certificate for. This allows you to fully automate certificate renewal while keeping your internal services protected via firewall. All you need is a dedicated authoritative nameserver, which is reachable (port 53, both UDP and TCP) from both the internet […]

The post Get Valid TLS Certificates for Icinga Web Despite a Firewall appeared first on Icinga.

NETGEAR AV Line monitoring With the new NETGEAR AV Line monitoring plugin, you can easily monitor NETGEAR AV Line devices in Icinga 2. This lightweight yet powerful Go-based tool communicates directly with the devices’ API and provides clear status values – including perfdata. What the Plugin Does for NETGEAR AV Line Monitoring This plugin was built specifically for the NETGEAR AV Line. It is not intended for other models, as those might return incorrect results.It collects and checks several important hardware and network metrics, such as: CPU and RAM usage Fan speed and temperature sensors Port statistics (inbound and outbound traffic) PoE data (power consumption and activation status) These checks provide a quick overview of your device’s health. Therefore, it’s ideal for AV or network infrastructures where stability and temperature control are crucial. Integration in Icinga The plugin uses the go-check framework and returns its results in an Icinga-compatible format. Because of that, you can integrate this plugin just like any other Icinga 2 check command. A simple example: check_netgear -u admin -p VerySecurePassword --mode basic Result: [WARNING] Device Info: Uptime - 1 days, 0 hrs, 31 mins, 29 secs \_[OK] CPU Usage: 7.13% \_[OK] RAM Usage: 32.46% \_[OK] Temperature […]

The post New Icinga plugin: NETGEAR monitoring with Go appeared first on Icinga.

The post Icinga 2 Meets OpenTelemetry: Native Metrics Export in v2.16 appeared first on Icinga.

We are happy to announce the release of two new versions of Icinga 2 today, 2.16.0 and 2.15.3. The first one includes some new features highlighted below, as well as a number of bug fixes and other improvements. The latter one is a small bug fix release that brings some of the other fixes included in 2.16.0 to the 2.15.x branch as well. OpenTelemetry Metrics Writer In the last year, we have received surprisingly many requests for a single feature: OpenTelemetry support. As the name already suggests, OpenTelemetry is an open standard for telemetry, which includes, among many other things, a wire protocol for sending metrics. Icinga 2 now features a new writer that sends the performance data metrics collected by the individual check commands to compatible receivers using the OpenTelemetry Protocol (OTLP). For one, following a vendor-neutral standard also allows integrating Icinga 2 metrics into more metrics backends than before. For example, it is now also possible to write metrics directly to Prometheus as it has an OpenTelemetry receiver as well. Additionally, it is supposed to replace the existing ElasticsearchWriter. We considered fixes to the dedicated writer’s index template and support for the Elasticsearch data stream feature in the […]

The post Announcing Icinga 2.16.0 and 2.15.3 appeared first on Icinga.

CMake tends to have a bad reputation for being to complex and convoluted, but often that notion stems from very old versions of CMake. Sure, CMake is a Turing-complete scripting language, but that is really needed for an ecosystem as complex as that of C and C++. And as Greenspun’s tenth rule of programming goes: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. There are countless build-systems and build-system generators for the C/C++ ecosystem. Some of them tried to use a simple, declarative approach. But there’s always edge-cases and either the build-system lacks the feature to support them, or it needs to add scripting capabilities at some point. CMake was designed with that in mind from the start. So C/C++ build-systems are always going to be complex, but what they don’t have to be, however, is ugly and hard to maintain. And thankfully, CMake walks that line quite well, at least if you know how to use the right idiomatic approach in the form of “modern” CMake, which describes anything from version 3.0 (released in 2014) onward. In this blog post I want to showcase a few of […]

The post Modernizing a legacy CMake build-system appeared first on Icinga.