Seite wählen

NETWAYS Blog

Icinga mit IcingaDB auf Ubuntu 20.04 / 22.04 installieren

Wer nach einer Open Source Monitoring Lösung zur System- und Netzwerküberwachung sucht, kommt an Icinga (auch als Icinga 2 bekannt) nicht vorbei. Es hilft dir dabei Verfügbarkeit, Leistung und Trends der gesamten IT-Infrastruktur zu überwachen. Dank individualisierbarer Benachrichtigungseinstellungen kommen die Informationen immer genau an der gewünschten Stelle an.

Mit diesem Guide wollen wir dir dabei helfen, einen leichten Einstieg ins Icinga Monitoring zu finden und Icinga, Icinga DB und Redis erfolgreich installierst.
In diesem Guide spielt die IDO keine Rolle mehr, da diese von Icinga DB als Datenbackend abgelöst wurde. Die neue Komponente sorgt für eine bessere Performance und Skalierbarkeit von Icinga.

Voraussetzungen für die Icinga und Icinga DB Installation

Damit dieser Guide erfolgreich umgesetzt werden kann, gibt es einige wichtige Voraussetzungen:

  • Einen Ubuntu 20.04 / 22.04 Server mit mindestens 2 GB RAM und 20 GB freiem Speicherplatz
  • Der sudo – Benutzer ist auf dem Server eingerichtet und du hast das Recht, ihn zu nutzen
  • Zugriff auf eine SQL-Datenbank (in diesem Guide wird MariaDB verwendet)
  • Die aktuellste PHP-Version ist auf dem Server installiert
  • Eine Internetverbindung auf den Server
  • Optional: Ein Webserver (Apache, Nginx, etc.) ist auf dem Server installiert (als Teil des LAMP-Stack)

Du kannst hinter alle diese Punkte einen Haken setzen? Dann legen wir los!

Anmerkung: Alle nachfolgende Schritte werden als root-User durchgeführt. Überprüfe, ob du den richtigen Benutzer verwendest!

Schritt 1: Icinga Repository hinzufügen

Um die aktuelle Version von Icinga zu installieren, wird das offizielle Icinga-Repository zu unserem System hinzugefügt. Dazu führst du in deinem Terminal die folgenden Befehle aus:

apt update 
apt -y install apt-transport-https wget gnupg 
wget -O - https://packages.icinga.com/icinga.key | gpg --dearmor -o /usr/share/keyrings/icinga-archive-keyring.gpg
. /etc/os-release; if [ ! -z ${UBUNTU_CODENAME+x} ]; then DIST="${UBUNTU_CODENAME}"; else DIST="$(lsb_release -c| awk '{print $2}')"; fi; \
 echo "deb [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] https://packages.icinga.com/ubuntu icinga-${DIST} main" > \
 /etc/apt/sources.list.d/${DIST}-icinga.list  
echo "deb-src [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] https://packages.icinga.com/ubuntu icinga-${DIST} main" >> \
 /etc/apt/sources.list.d/${DIST}-icinga.list
apt update

Sobald dieser Befehlsblock erfolgreich durchgelaufen ist, siehst du in deinem Terminal, dass die neuen Repos nun in deiner Liste zu finden sind. Es sollte in etwa so aussehen:

Screenshot eines Ubuntu Terminals, bei dem eine Auflistung aller dem System hinzugefügten Repositories zu sehen ist. Der Screenshot soll verdeutlichen wie es aussieht, wenn die offiziellen Icinga Repositores zum System hinzugefügt wurden

Schritt 2: Icinga-Paket auf Ubuntu 20.04 oder Ubuntu 22.04 installieren

Da du nun Zugriff auf das Icinga-Repository hast, kannst du direkt damit weiter machen und das Icinga Paket installieren. Dafür nutzt du:

apt install -y icinga2

Dieses Paket ist die Basis der gesamten Icinga 2 Monitoring Installation. Um zu überprüfen, ob die Installation erfolgreich war, nutzt du

icinga2 daemon -C

Mithilfe dieses Befehls kannst zukünftige Konfigurationsanpassungen mit einem Terminalbefehl überprüfen.

Screenshot eines Ubuntu Terminals, bei dem das Kommando icinga2 daemon -C inklusive seiner Ausgabe zu sehen ist. Der Screenshot soll verdeutlichen wie die Ausgabe dieses Befehls im Terminal visualisiert wird

Schritt 3: Aktivieren der Icinga API und Installieren der Monitoring Plugins

Ein Monitoringsystem ist nur so gut wie die Daten, die es sammelt und die Checks, die ausgeführt werden.
Für moderne, aus Nagios hervorgegangene Open Source Monitoring Systeme haben sich die bereits am Anfang angesprochenen Monitoring Plugins etabliert. Diese installierst du im nächsten Schritt.

Damit kannst du direkt nach Abschluss dieses Icinga Installationsguides die ersten Checks anlegen und mit deinem System Monitoring oder Netzwerk Monitoring starten. Dafür nutzt du im Terminal den folgenden Befehl:

apt install monitoring-plugins

 

Um die Ergebnisse der Check Plugins abzurufen oder mit Icinga zu interagieren, muss die Icinga API eingerichtet werden. Das machst du ganz einfach mit diesen beiden Befehlen:

icinga2 api setup
systemctl restart icinga2

Damit legst du in der Konfigurationsdatei /etc/icinga2/conf.d/api-users.conf einen API-User (inkl. zufallsgeneriertem Passwort) an.
(Die hier erzeugten Zugangsdaten benötigst du im weiteren Verlauf bei der Einrichtung von Icinga Web. Du wirst im entsprechenden Schritt noch einmal darauf hingewiesen!)

Falls du bestimmte Vorgaben erfüllen musst oder generell mehr über die Icinga API erfahren willst, lege ich dir entsprechende Seite in den Icinga Docs ans Herz.

Weiter geht es mit der Einrichtung von Icinga DB.

Schritt 4: Icinga DB einrichten

Icinga DB ist keine, wie der Name vielleicht vermuten lässt, eigenständige Datenbank.
Vielmehr handelt es sich hierbei um eine Sammlung von Komponenten zur Veröffentlichung, Synchronisierung und Visualisierung von Überwachungsdaten im Icinga-Ökosystem. Dazu gehören Redis, das IcingaDB-Feature des Icinga Core und der Icinga DB-Daemon.

Schritt 4.1: Redis Server installieren

Um Icinga DB zu nutzen, benötigst du einen Redis Server. Für einen reibungslosen Installations- und Konfigurationsprozess bietet das Icinga Team ein eigenes Redis-Paket an, das speziell auf Icinga zugeschnitten ist.
icindadb-redis umfasst deshalb eine aktuelle Version von Redis und kommt out of the box mit Anpassungen der Freigabe auf Port 6380 statt dem sonst für Redis üblichen Port 6379.
Das Paket installierst du mit:

apt install icingadb-redis

Hinweis: Der Redis Server kann grundsätzlich überall in deiner Icinga Umgebung installiert werden. Es ist jedoch sinnvoll, diesen auf dem zentralen Icinga-Node zu installieren, um die Latenz so niedrig wie möglich zu halten.
Ein bereits vorhandener und selbst konfigurierter Redis Server kann ebenso verwendet werden. Hier sind jedoch entsprechende Anpassungen notwendig, weshalb die Nutzung des entsprechenden Icinga-Pakets empfohlen wird.

Schritt 4.2: Aktivieren von Redis

Die Installation von icingadb-redis installiert automatisch alle systemd Dateien, die Icinga DB Redis braucht. Der Service kann also direkt aktiviert und gestartet werden:

systemctl enable --now icingadb-redis-server

Standardmäßig lauscht icingadb-redis nur auf 127.0.0.1, also deinem localhost. Wenn Icinga Web 2 oder Icinga 2 auf einer anderen Node laufen als Redis, dann muss das in der Konfigurationsdatei

/etc/icingadb-redis/icingadb-redis.conf

angepasst werden.

Auch wenn in diesem Guide alle Schritte auf einer Icinga-Node durchgeführt werden, wird die Konfigurationsdatei so angepasst, dass das Aufsetzen weiterer Nodes in der Zukunft kein Problem darstellen.
Dafür sind innerhalb der Konfigurationsdatei zwei kleine Anpassungen notwendig:

  • protected-mode von yes auf no
  • bind von 127.0.0.1 auf 0.0.0.0 –> Dadurch können alle Interfaces auf Redis zugreifen

Um die Änderungen zu aktivieren, muss der Service neu gestartet werden:

systemctl restart icingadb-redis

Damit Icinga über Icinga DB später Daten an Redis weitergibt, muss das entsprechende Feature aktiviert und Icinga anschließend neu gestartet werden:

icinga2 feature enable icingadb 
systemctl restart icinga2

Sicherheitshinweis:
Redis hat standardmäßig KEINE Authentifizierung aktiviert!
Mit der Änderung von bind auf 0.0.0.0 wird dringend, um unbefugten Zugriff zu verhindern, empfohlen, einige Sicherheitsmaßnahmen durchzuführen. Dazu gehören: Einrichten eines Passworts, Aufstellen von Firewall-Regeln oder Einrichten von TLS.
Zur einfacheren Installation wird in diesem Guide jedoch auf diese Schritte verzichtet! Diese Anpassungen lassen sich ebenfalls nachträglich durchführen.

Schritt 4.3: Installieren von Icinga DB und einrichten der Datenbank

Nachdem im gerade abgeschlossenen Schritt die Schnittstelle von Icinga 2 zu Icinga DB aktiviert wurde, wird nun Icinga DB selbst installiert:

apt-get install icingadb

Damit das gerade installierte Paket die verarbeiteten Daten auch speichern kann, muss eine Datenbank für Icinga DB angelegt und Zugriff dazu gewährt werden. (In diesem Guide wird MariaDB 10.6.12 verwendet. Die Einrichtung von MySQL ist mit den gleichen Befehlen möglich. Nutzt du PostgreSQL findest du die entsprechenden Befehle in den offiziellen Icinga Docs.)

mysql -u root -p 
CREATE DATABASE icingadb; 
CREATE USER 'icingadb'@'localhost' IDENTIFIED BY 'SAFEPASSWORDINHERE'; 
GRANT ALL ON icingadb.* TO 'icingadb'@'localhost';

Damit hast du die Datenbank und den Datenbank-Nutzer erfolgreich angelegt. Icinga DB stellt zudem ein Datenbankschema zur Verfügung, dass nun importiert wird:

mysql -u root -p icingadb </usr/share/icingadb/schema/mysql/schema.sql

Schritt 4.3: Zugriffsberechtigungen anpassen

Während der Installation von Icinga DB wird unter /etc/icingadb/config.yml eine Konfigurationsdatei angelegt, die mit Standardwerten gefüllt ist. Damit die Verbindung von Icinga DB zu Redis und MariaDB erfolgreich stattfinden kann, müssen diese Werte überprüft und gegebenenfalls angepasst werden.

Öffne also den Pfad mit einem Texteditor deiner Wahl und passe die folgenden Parameter gegebenenfalls an.

Für die Datenbank:
host mit dem entsprechenden Hostname/Host-IP deiner Datenbank, database mit dem Namen deiner Datenbank (in diesem Guide icingadb), user mit dem Namen deines Datenbanknutzers und password mit dem Passwort, dass du für deine Datenbank vergeben hast.

Für Redis:
host mit dem entsprechenden Hostname/Host-IP deiner Redis Instanz. Wenn du während der Installation deines Redis-Servers den port geändert oder ein password gesetzt hast, musst du dies hier ebenfalls eintragen.

Sobald diese Änderungen abgeschlossen sind, kann der Icinga DB Service aktiviert werden:

systemctl enable --now icingadb

Schritt 5: Icinga Node Wizard ausführen

Nachdem die Grundkomponenten für die Nutzung von Icinga installiert und konfiguriert wurden, muss noch er Node Wizard ausgeführt werden. Dieses interaktive Skript hilft dir dabei, Zonen einzustellen und die Endpunkte deines Icinga Monitoring festzulegen.

Dafür gibst du im Terminal diesen Befehl ein:

icinga2 node wizard

Da hier einige wichtige Einstellungen vorgenommen werden, hier eine Übersicht der einzelnen Punkte:

  • Is this agent/satellite setup? –> Hier ’n‘ eingeben und mit Enter bestätigen
  • Specifiy common name (FQDN of your master) –> Nichts eingeben und mit Enter bestätigen
  • Master zone name –> Nichts eingeben und mit Enter bestätigen
  • Specify additional global zones –> Nichts eingeben und mit Enter bestätigen
  • Specify API bind host/port –> Nichts eingeben und mit Enter bestätigen
  • Bind Host –> Nichts eingeben und mit Enter bestätigen
  • Bind Port –> Nichts eingeben und mit Enter bestätigen
  • Disable inclusion of conf.d directory –> Nichts eingeben und mit Enter bestätigen

Screenshot der Ubuntu Terminalausgabe, bei dem das Kommando icinga2 node wizard inklusive seiner Ausgabe zu sehen ist. Der Screenshot soll verdeutlichen wie die Ausgabe dieses Befehls im Terminal visualisiert wird

Im Anschluss verifizierst du die getätigte Konfiguration und lädst Icinga 2 neu:

icinga2 daemon -C 
systemctl reload icinga2

Damit hast alle wichtigen Schritte zur Icinga und Icinga DB abgeschlossen!

Wie gehts es nun weiter?

Herzlichen Glückwunsch, du hast erfolgreich ein lokales Icinga installiert und konfiguriert! Damit könntest du nun direkt loslegen und über die Icinga2 API deine ersten Objekte anlegen, Actions triggern oder Templates bauen. Welche API-Calls dir dafür zur Verfügung stehen, kannst du übersichtlich in den Icinga Docs nachlesen.

Grundsätzlich ist die Icinga Installation nun einsatzbereit. Damit eine Open Source Monitoring Lösung wie Icinga aber produktiv genutzt werden kann, müssen die gesammelten Daten noch visualisiert werden.
Dabei helfen Icinga Web und Icinga DB Web. Wie diesen beiden Tools installiert und mit der hier aufgesetzten Basis verbunden werden erfährst du im Installationsguide zu Icinga Web und Icinga DB Web auf Ubuntu 20.04 / 22.04.

Squid – Mit Proxy schneller zum Ziel

Bereits in zwei meiner Blogposts habe ich besonders interessante Ausbildungsprojekte vorgestellt. Im Beitrag Your own Mini-NAS zeige ich, wie einfach es ist, einen Massenspeicher im eigenen Netzwerk zu erstellen, in Pi-Hole – das Urgestein der DNS-basierten Werbeblocker geht es, wie der Name schon vermuten lässt, um die Installation und Einrichtung von Pi-Hole auf einem Raspberry Pi.

Auch im heutigen Post geht es um ein für mich interessantes Ausbildungsprojekt aus meinem ersten Ausbildungsjahr zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services: die Installation und Konfiguration eines Proxy-Servers mit Squid.

Was genau macht ein Proxy-Server?

Der Begriff „Proxy“ ist in vielen Bereichen der IT anzutreffen und für die meisten IT-Profis bereits ein alter Hut. Nichtsdestotrotz stelle ich einmal kurz und knapp die wichtigsten Anwendungsbereiche eines Proxy-Servers vor.

Caching – Beschleunigung beim Datenaufruf

Der wohl bekannteste Einsatzbereich von Proxys ist die Funktion als Zwischenspeicher. Dafür wird die entsprechende Software als „Mittelsmann“ in die Kommunikation von Host und Datacenter/Server eingesetzt. Jede Anfrage eines Hosts im Netzwerk, zum Beispiel der Aufruf einer Homepage über den Browser sowie die Antwort vom Server wird über den Proxy geleitet. Die eingehenden Daten werden in seinem Speicher ablegt, das nennt man Caching.
Durch das Caching ist der Proxy in der Lage, regelmäßig auftretende Anfragen deutlich schneller zu beantworten, da er viele Daten bereits aus seinem Speicher laden kann. So wird nicht nur Zeit, sondern auch Bandbreite gespart.

Lastenverteilung

Neben dem Caching, kann ein Proxy auch für eine bessere Lastenverteilung zwischen mehreren angeschlossenen Systemen sorgen. Diese Funktion kommt häufig bei Anfragen auf (Web-)Servern zum Einsatz. Um das einmal zu veranschaulichen, stellen wir uns eine beliebte Homepage vor, die pro Sekunde Tausende Anfragen bekommt. Damit der Webserver unter der Last nicht zusammenbricht, kommt ein Proxy zum Einsatz, der checkt, wie groß die Last auf Webserver 1 ist und bei Bedarf neue Anfragen auf Webserver 2 umleitet. Auf beiden Servern liegen die exakt gleichen Inhalte. So kann ein Zusammenbruch der Homepage verhindert werden.

Filterung des Datenverkehrs

Blocklisten sind eine einfach umsetzbare Möglichkeit den Datenverkehr innerhalb des eigenen Netzwerks zu reglementieren. Mit dem Squid Proxy-Server lassen sich diese Regeln einfach umsetzen, dazu weiter unten im Text aber noch mehr.
Der Administrator des Netzwerks kann mithilfe eines Proxy-Servers festlegen, welche Seiten aus dem eigenen Netzwerk aufgerufen werden können und welche nicht. Sobald eine „verbotene“ Website aufgerufen werden soll, kann eine Weiterleitung auf eine Landingpage genutzt werden, auf welcher diese Regeln erklärt sind.

Authentifizierung

Ähnlich wie die Listen zur Filterung von Datenverkehr kann mit Access Control Lists (ACL) der Zugang zum Netzwerk oder zu bestimmten Teilen des Netzwerks beschränkt oder freigeschalten werden. Dadurch kann anhand von IP’s und/oder MAC-Adressen sowie durch Authentifizierung exakt eingestellt werden, welche Systeme oder Nutzer auf welche Bereiche eines Netzwerks Zugriff bekommen.

Installation von Squid

DISCLAIMER: Alle in diesem Blogbeitrag genannten Installations- und Konfigurationsschritte wurden nur auf CentOS 9 getestet. Für andere Distributionen, besonders Debian / Ubuntu, wird keine Gewähr für eine problemlose Funktionalität gegeben.

Um einen Proxy zu konfigurieren benötigt es zunächst einmal die passende Open Source Software, in diesen Fall der häufig verwendete Squid Proxy Server. Die Installation von Squid selbst ist mit drei CLI-Befehlen so einfach wie unkompliziert.

yum -y install squid
systemctl start squid
systemctl enable squid

Um zu überprüfen, ob Squid Proxy wie gewünscht läuft, kann der aktuelle Status mit dem Command

systemctl status squid

angezeigt werden. Haben die hier gelisteten Parameter den gewünschten Status (active und enabled), kann die Konfiguration starten.

Konfiguration von Squid Proxy

Um kleinere Stolpersteine beim Einsatz von Squid direkt bei der Erstkonfiguration aus dem Weg zu räumen wird in der Firewall der von Squid benötigte Port 3128 freigeschaltet. Nun können die Zugriffsregelungen, Benutzerauthentifizierung sowie Blocklisten konfiguriert werden. In diesem Post beschränke ich mich auf die Konfiguration der Zugriffsregelungen sowie der Blocklisten.

Einrichten der Zugriffsregeln

Auf dem Proxy-Server

Bevor Authentifizierung und Listen genutzt werden können, muss der Zugriff auf den Squid-Proxy geregelt werden. Dafür werden die IP-Adressen der Hosts benötigt, die ihre Verbindungen über den Proxy-Server leiten sollen.
Die IP-Adressen können auf zwei verschiedene Arten bereitgestellt werden. Zum einen können sie mit dem entsprechenden Befehl direkt in die config-Datei von Squid geschrieben werden. Zum anderen kann eine eigene Textdatei mit allen relevanten Adressen angelegt und eingelesen werden. Letzteres Vorgehen ist besonders bei großen Netzwerken hilfreich und sinnvoll. Best Practice ist es, alle selbst erstellten Listen im Squid-Proxy-Ordner /etc/squid anzulegen.

Egal welche Methode genutzt wird, der entsprechende Befehl wird an den Anfang der Squid-Config-Datei geschrieben, damit die neue Direktive vor den bereits vordefinierten ACLs angewendet wird. Der entsprechende Befehl ist für die direkte Eingabe einer IP-Adresse

acl NAME_DER_ACL src IP_DES_SYSTEMS

und für die Verwendung einer Textdatei

acl NAME_DER_ACL dstdomain "PFAD_ZUR_TEXTDATEI"

Mit diesen Befehlen wurde eine neue ACL definiert, sie ist aber noch nicht aktiv. Dafür wird ein weiterer Befehl benötigt, der direkt unter den gerade geschriebenen Befehl eingefügt wird. Hier kann sowohl allow als auch deny genutzt werden, je nachdem, was das Ziel der neuen ACL ist, aber niemals beide zusammen in einem Befehl.

http_access allow NAME_DER_ACL
http_access deny NAME_DER_ACL

Auf den Clients im Netzwerk

Nachdem der Proxy-Server entsprechend konfiguriert ist, müssen auch auf den Clients, die den Proxy nutzen sollen, einige Anpassungen vorgenommen werden. In /etc/environment werden nun unabhängig vom bisherigen Inhalt der Datei die folgenden Zeilen eingefügt bzw. angepasst:

http_proxy=http://IP_DES_PROXY:3128/
https_proxy=http://IP_DES_PROXY:3128/
ftp_proxy=http://IP_DES_PROXY:3128/
no_proxy="localhost,127.0.0.1,localaddress,.localdomain"
HTTP_PROXY=http://IP_DES_PROXY:3128/
HTTPS_PROXY=http://IP_DES_PROXY:3128/
FTP_PROXY=http://IP_DES_PROXY:3128/
NO_PROXY="localhost,127.0.0.1,localaddress,.localdomain"

Damit sollten sowohl systemseitig als auch auf dem Proxy alle Konfigurationen für eine erfolgreiche Kommunikation der beiden durchgeführt sein.

Blocken von Websites und Keywords

Um eine Blockliste für Websites oder Keywords zu erstellen, müssen die zu sperrenden Seiten oder Begriffe in eigens dafür angelegten Textdateien gesammelt werden. Um welche zu sperrenden Inhalte es sich dabei handelt, ist von Anwendungsfall zu Anwendungsfall unterschiedlich. Häufig werden sie jedoch dafür genutzt, den Aufruf von Social Media-Kanälen zu beschränken, nicht-jugendfreie Inhalte aus dem Datenverkehr auszuschließen oder restriktiv alle Inhalte zu filtern, die für zu viel Ablenkung sorgen könnten.

Der Pfad zu den angelegten Listen, Best Bractice ist auch hier /etc/squid/…, wird nun in die squid.conf eingepflegt. Da die Konfigurationsdatei hierarchisch von oben nach unten abgearbeitet wird, MÜSSEN Blocklisten vor den Zugangsberechtigungen stehen.

acl blocked_sites dstdomain "PFAD_ZUR_EIGENEN_LINK-BLACKLIST"
acl blocked_keywords dstdomain "PFAD_ZUR_EIGENEN_KEY-BLACKLIST"
http_access deny blocked_sites
http_access deny blocked_keywords

Nachdem die Änderungen gespeichert wurden, ist noch ein Neustart von Squid-Proxy notwendig, um die Änderungen wirksam zu machen.

systemctl restart squid

Wenn alles korrekt eingerichtet wurde, ist der Squid-Proxy-Server nun einsatzbereit.

Die ersten Zeilen der veränderten squid.conf könnten nun in etwa so aussehen:

squid proxy configuration file with sample code

Wenn die eigene Konfigurationsdatei jedoch mehr oder weniger Inhalte beinhaltet oder diese in einer anderen Reihenfolge stehen, ist das kein Problem. Dieser Screenshot dient lediglich als Hilfestellung.

Ausbildung und #lifeatnetways

Wenn auch Du nun Lust bekommen hast, Dich mit diesem oder ähnlichen Projekten zu befassen oder bereits viel IT-Erfahrung mitbringst und direkt tiefer einsteigen willst, schick uns noch heute deine Bewerbung. Aktuell suchen wir besonders IT-Spezialist:innen in den verschiedensten Bereichen. Doch auch für das im September 2023 beginnende neue Lehrjahr kannst Du Dich bereits heute bewerben.
Wenn Du mehr über NETWAYS, freie Stellen oder unsere Firmenkultur erfahren willst, klick einfach auf den entsprechenden Link oder such auf Twitter, LinkedIn oder Instagram nach #lifeatnetways.

OSMC 2022 | Recap Day 1

Welcome to our recap series of the Open Source Monitoring Conference 2022 (OSMC 2022) in Nuremberg. Last year the workshop and hackathon concluded the OSMC. This year three workshops will kick-off our long awaited conference. While the conference will be consecutive talks about amazing new innovations and features the workshops are the calm before the storm.

In a calm but constructive and educational environment, our experienced trainers provide theoretical insights and practical exercises in their field. Today I will guide you through the following workshops: Kubernetes, Icinga  Director and Director Branches and last but not least Prometheus.

A little disclaimer beforehand: this blog post is no detailed overview of the workshops. If you want to learn more about one of the topics I highly encourage you to visit the respective training, it’s worth it. With this said: let’s get going!

 

First Stop: Container Orchestration with Kubernetes

Our colleague in NETWAYS Professional Services Consulting Daniel Bodky is holding his first workshop at OSMC, after he got a first impression of the conference as a visitor last year. Already at the beginning he sets the stage for his Kubernetes workshop. The next few hours are planned to be a dialog with impressions from the paritcipants’ work reality.

Since Kubernetes is a ’new‘ technology for container orchestration, the group of participants is mixed. Participants with experience in the area of Docker and Kubernetes as well as beginners are present. So the starting point of the workshop is Docker. Because before you can deal with Kubernetes, it is important to learn and know about Docker containers and how they work. They are the very basis for the successful use of Kubernetes.

To build this base Daniel guides his attendees through the theoretical and practical handling of Docker images. Now that all the groundwork is done the attendees take their first steps in Kubernetes … with a theoretical overview of what Kubernetes is and isn’t. After all this theory it is time to put the gained knowledge into action. The following practical topics like Deployment, Service & Ingress or Volumes in Kubernetes offer the possibility to get hands-on experience.

Through the structure of theory (for all levels of knowledge) and practical exercises to apply the new knowledge all attendees can easily participate and achieve success. With this impressions of the OSMC Kubernetes workshop let’s go to our next stop: Prometheus.

 

Second Stop: Metric Monitoring with Prometheus

The second ‘new’ tool which got a lot of buzz over the last few years is Prometheus. Why is it so popular? Apart from the big companies using it (e.g. SoundCloud and Docker) it is using a different monitoring approach than well known tools like our Icinga 2 or Nagios.

The Prometheus-team is putting metrics and data in the center of their monitoring approach. With his vast ecosystem of different components it can be complex if getting into it without the proper introduction. The trainer of this workshop Julien Pivotto of O11y knows this from experience and is giving his attendees the needed guidance through the Prometheus world and how Prometheus and its different components work together.

As it is a workshops designed for beginners in the world of Prometheus after the introduction the first hands-on lab is the download and installation of the Prometheus ecosystem. After the first hands-on experience is done and the first fear of contact is lifted it is time to get accustomed with some more essentials. Like with every new tool it is important to understand two things: wording and how the system works. Like which functions and aggregators are commonly used in Prometheus or what tools help you use and understand the metrics of Prometheus better. Julien is showing a lot of insights in common mistakes and also the complexity of Prometheus.

Why complexity? Because Prometheus is collecting ALL THE METRICS. If there are no conditions set a lot of data is displayed. So it is important to know what you want to check and customize Prometheus to meet your goals. There are so much more topics I could write about like Grafana as go-to Dashboard or how Prometheus handles alerts if certain conditions are met. But it is time for our last workshop: Icinga Director and Director Branches.

 

Third Stop: Configuration with the Icinga Director and Director Branches

While the Prometheus workshop is about getting started with the monitoring tool, the Icinga Director workshop offers hands-on exercises and related knowledge about the Icinga 2 web configuration tool. In addition to the introduction to the Icinga Director, practical questions will be addressed from the beginning, since many of the participants already deal with Icinga 2 monitoring in their daily practice.

For many, the workshop serves as a support for explicit practical problems, where the experienced Principal Consultant of NETWAYS Professional Services Dirk Götz can offer best practices from his years of consulting experience. In order to make the best possible use of the Director’s many setting options, the workshop focuses on relevant setting options and how these can be and how they can best be implemented.

The many configuration options also show the strengths of Icinga 2 as a monitoring tool and the monitoring tool and the Director as a configuration tool: customizability.
No matter what logic is required, what specifications there are and what objectives the monitoring has everything can be set via the Icinga Director. Like every OSMC workshop this one also offers a balanced mix of theoretical input and hands-on labs to give the attendees the chance to test out their new knowledge.

After the introduction into the Icinga Director, Blerim Sheqa, Chief Product Office of the Icinga GmbH is introducing a new feature: Director Branches. This new tool is an extension for the Icinga Director and aims to provide a safe virtual working environment for development and administration teams.
The workflow of Director branches is based on git. You can create different configuration branches and in the end merge them into your productive environment. With this virtual safe space you and your teams can try out different adjustments and settings without the risk of crashing you complete monitoring setup.

Another benefit is the possibility for different teams and users to work at their own parts at the same time without getting into each others way. Another nice feature is the comment section every merge must have. Every time you check the activity log your administrators can check what changes have been deployed. With this look at a new Icinga Director feature our little tour through todays workshops comes to a close.

 

Last but not Least: A Little Peak Behind the Scenes

Even tough today the OSMC 2022 started with the three workshops the work to set-up the conference are still going. The team of NETWAYS Event Services (NES) are busy organizing the different sites to ensure everything is running smoothly the next two days.

Apart from me as todays blogger and NES there is also our marketing team around. Since 9.00 o’clock this morning they are busy taking pictures and videos, while helping at the check-in counter. So if you see some of their content in your social media feed be sure to like and subscribe.
If you post pictures of your attendance at the OSMC 2022 online don’t forget to use our official hashtag #OSMC to possibly get a repost from our official channels.

There is one feature of this years OSMC I’ve kept till the end: our new Activity Area! Here you can challenge other attendees at giant Connect four and giant Jenga as well as relax between the talks. We have one last surprise in store for you, but this one you have to see for yourself at the Open Source Monitoring Conference 2022 at the Holiday Inn Conference Hotel here in Nuremberg.

 

To get a few impressions of the first OSMC day I have prepared a slider with lots of awesome pictures of the first conference day. Enjoy! 😄

NETWAYS stellt sich vor – Marc Rupprecht

This entry is part 39 of 62 in the series NETWAYS stellt sich vor

Name: Marc Rupprecht

Alter: 33

Position bei NETWAYS: Junior Consultant

Bei NETWAYS seit: September 2021

 

Wie bist du zu NETWAYS gekommen und was genau gehört zu Deinem Aufgabenbereich?

Die Kurzfassung ist schnell erzählt: Ich habe mich auf den Ausbildungsplatz zum Fachinformatiker für Systemintegration beworben, wurde genommen und jetzt bin ich glücklicher Azubi bei NETWAYS Professional Services.

Mit ein wenig mehr Hintergrund liest sich das ein bisschen komplexer:
Nach meinem Bachelorabschluss in Technikjournalismus / Technik-PR und 2 1/2 Jahren als Online-Redakteur bei einem Nürnberger Health-Tech Start-Up habe ich gemerkt, dass mich dieser Job immer unglücklicher macht und ich eine Veränderung brauche.
Da ich mich schon seit meiner Jugend für IT-Themen interessiere und ich in meinem Studium ebenfalls den Fokus auf IT- und Onlinethemen gelegt habe, fiel die Entscheidung schnell auf eine Ausbildung zum Fachinformatiker.

Nun sitze ich hier und bin seit September 2021 als Junior Consultant bei NPS tätig. Zu meinen Aufgabengebieten zählen hier zunächst die Grundlagen von Linux kennenlernen und darauf aufbauend in Azubiprojekten mein Fachwissen immer weiter zu steigern.

 

Was macht dir an deiner Arbeit am meisten Spaß?

Dass ich bei jedem Projekt etwas neues dazulerne. Ich merke bei jedem neuen Projekt, dass ich Wissen aus den vorangegangenen Aufgaben einfließen lassen kann und Aufgaben die zu Beginn noch länger gedauert haben, nun deutlich leichter von der Hand gehen.
Wenn ich mein erstes eigenes Projekt mit meinem letzten vergleiche merke ich, wie stark mein Wissenszuwachs in den letzten Monaten war und daraus schöpfe ich viel Spaß und Energie.
Zudem begeistern mich die abwechslungsreichen Aufgaben die ich als Azubi bearbeiten darf und dass ich dabei nicht nur auf technische Themen beschränkt bin. Eine abteilungsübergreifende Zusammenarbeit zwischen Technik und Marketing? Kein Problem! Diese vielfältigen Möglichkeiten, die eigenen Interessen und Stärken einfließen zu lassen sind wirklich top.

 

Was machst du, wenn du nicht bei NETWAYS bist?

Da gibt es so Einiges, manche sind fixe Termine in meiner Woche, manche gehen leider nur auf Reisen.
Ende letzten Jahres habe ich das Standardtanzen für mich entdeckt. Hier bin ich aktuell einmal in der Woche im Kurs und versuche mit meinem bisher nicht vorhandenen Taktgefühl keine allzu schlechte Figur auf dem Parkett abzugeben.

Ich versuche, wenn nicht gerade Pandemie ist, all meine Urlaubstage auf Reisen zu verbringen und davon mindestens die Hälfte an Orten an denen es warm ist und Meer um die Ecke. Das Meer ist nämlich Voraussetzung dafür, dass ich Tauchen gehen kann, eine Leidenschaft die vor 2 Jahren geweckt wurde und der ich mit viel Freude nachgehe.

Ansonsten liege ich aber auch gerne einfach faul auf der Couch und streame Serien, Filme, Dokus, etc., zocke am PC oder bin in Nürnberg oder anderen Städten unterwegs.
Man merkt, langweilig wird mir in den seltensten Fällen.

 

Wie geht es in Zukunft bei dir weiter?

Bis 2024 steht jetzt erst einmal die Ausbildung auf dem Plan. Danach hoffe und freue ich mich darauf weitere Jahre bei NETWAYS zu verbringen. Wie es in 7 Jahren oder so aussieht, ist aktuell noch offen. Auf jede Überlegung was ich in Zukunft machen will, kommen zwei die ich schon wieder verworfen habe.

 

Pi-hole – Mit einem Raspberry Pi zur Werbefreiheit

This entry is part 2 of 2 in the series Werbeblocker

Im Rahmen meiner Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services arbeite ich regelmäßig an neuen Projekte. Dabei steht neben dem Kennenlernen neuer Technik und Software besonders die Vertiefung von Schulungsinhalten im Fokus.
Im Rahmen des Projekts zur DNS-Schulung (Domain Name System) habe ich den DNS-basierten Werbeblocker Pi-hole aufgesetzt und konfiguriert. Pi-hole ist seit vielen Jahren die bekannteste und am weitesten verbreitete Anwendung für ein netzwerkweites Ad-Blocking. Das liegt besonders an den individuellen Konfigurationsmöglichkeiten, welche die Software anbietet sowie an der unkomplizierten Installation.

Warum ist ein DNS-Werbeblocker sinnvoll?

Viele Dienste und Websites im Internet bieten ihre Dienste für Endkunden kostenlos an. Da sich mit kostenlosen Inhalten in der Regel aber kein Geld verdienen lässt, sind Werbeanzeigen in den letzten zehn Jahren für viele Unternehmen eine, teilweise gar die wichtigste Einnahmequelle geworden.
Während der Einsatz von Werbung aus unternehmerischer Sicht sinnvoll und nachvollziehbar sind, können für die Nutzer:innen der Website / des Dienstes Probleme durch diese Werbeeinblendungen auftreten.

Teilweise sorgen Anzeigen „nur“ dafür, dass Websites nicht richtig funktionieren oder sie die Ästhetik stören. Es gab jedoch schon Fälle, in denen Werbeanzeigen zum Verteilen von schädlichem Code genutzt wurden. Um das eigene Netzwerk werbefrei zu halten, gibt es verschiedene Möglichkeiten. Die bekanntesten sind Pi-hole und AdGuard Home.
Dank dieser Programme kann das Auspielen von Werbung auf allen mit dem Netzwerk verbundenen Geräten verhindert werden. Dieser Text beschäftigt sich mit der Einrichtung und Konfiguration von Pi-hole, während unser Blogartikel von letzter Woche AdGuard Home genauer unter die Lupe nimmt.

Was ist Pi-hole?

Pi-hole ist eine Open-Source-Software, die als Werbe- und Trackingblocker fungiert. Welche Inhalte dabei für welches Gerät im lokalen Netzwerk geblockt werden, lässt sich individuell konfigurieren. Die Anwendung basiert auf Linux und ist dafür optimiert, um auf Computern mit minimaler Ausstattung, etwa dem Raspberry Pi, zu funktionieren.

Damit die Blockfunktion von Pi-hole wie gewünscht funktioniert, fungiert das Programm als DNS-Server für das eigene Netzwerk, über den der komplette Netzwerkverkehr sowohl ausgehend als auch eingehend geleitet wird. Mithilfe dieser Schnittstellenfunktion bekommt Pi-hole Zugriff auf alle eingehenden IP-Adressen, die mit dem Abruf einer Homepage oder eines Dienstes verbunden sind.
Diese Funktion sorgt dafür, dass Filter angewendet werden können, die Werbe- und Tracking-IP’s herausfiltern und z. B. die Website in einer werbefreien Form anzeigen. Die Werbung wird also verhindert, bevor das Endgerät überhaupt die Chance hat, den entsprechenden Inhalt zu laden.

Die angesprochenen Filter werden in Form von Filterlisten implementiert, die verschiedene Ziele erfüllen können. Neben dem bekannten Werbe- und Trackingblocker kann auch der Zugriff auf spezielle Seiten, etwa mit Inhalten der Erwachsenenunterhaltung oder soziale Netzwerke, eingeschränkt oder komplett verhindert werden. Sollten aufgrund einer oder mehrerer angewendeter Blocklisten Seiten gesperrt werden, auf die eigentlich zugegriffen werden soll, besteht die Möglichkeit, diese über eine Whitelist explizit für die gewünschten Clients freizugeben.

Technische Voraussetzungen

Um ein eigenes funktionierendes Pi-hole zu installieren, sind nicht viele Komponenten nötig. Die technischen Voraussetzungen sind:

  • Ein Raspberry Pi mit Raspberry Pi OS+ Zubehör & Netzteil
  • Eine MicroSD-Karte (mindestens 8GB Speicherkapazität)
  • Ethernet- oder WiFi-Verbindung (bei Raspis mit WLAN-Modul) zum Router des lokalen Netzwerks, damit Pi-hole als DNS-Server fungieren kann
  • Zugang zur Command Line Interface (CLI) des Pi

Die Einrichtung des Raspberry Pi vor der Installation von Pi-hole ist simpel und unkompliziert. Es gibt ausreichend Guides, die diese Arbeit Schritt-für-Schritt erklären.

Installation von Pi-hole

-HINWEIS-
Nach der Installation von Pi-hole kann der Raspberry Pi problemlos ohne Peripheriegeräte betrieben werden. Für den Zugriff auf die Weboberfläche der Anwendung ist jedoch die statische IP-Adresse des Pi nötig, welche über das Terminal des Betriebssystems ausgelesen werden kann. Aus diesem Grund ist es sinnvoll, dass für die Dauer der Installation des Betriebssystems und des Werbeblockers Monitor und Tastatur angeschlossen sind.

Die Pi-hole Installation ist unkompliziert und wird von einem ausführlichen Installationsassistenten begleitet, der jeden Schritt mit einer kurzen Erklärung begleitet. Um das Installationsskript zu starten, muss zunächst das Pi-hole git-Repository geklont werden, in der das Skript enthalten ist. Anschließend wird das Skript ausgeführt. Die entsprechenden Befehle dafür sind:

git clone --depth 1 https://github.com/pi-hole/pi-hole.git Pi-hole
cd "Pi-hole/automated install/"
sudo bash basic-install.sh

Der automatisierte Pi-hole Installer konfiguriert die Punkte:

  • Statische IP-Adresse
  • Auswahl des von Pi-hole verwendeten Upstream DNS-Providers
  • Einfügen einer ersten, von den Pi-hole-Entwickler:innen kuratierten Blockliste
  • Installation des Webinterface (kann ausgeschalten werden, wenn die Konfiguration komplett über SSH und CLI gemacht werden will)
  • Installation des Webservers lightttpd (Ist für die Anzeige des Webinterface unerlässlich)
  • Privacy level und loggen von Anfragen

Nachdem der Installer seine Arbeit getan hat, ist die Weboberfläche erreichbar und Pi-hole ohne weitere Einstellungen direkt einsetzbar.

Individuelle Konfiguration von Pi-hole …

Mit der vom Installer vorgegebenen Grundkonfiguration ist der Einsatz des Werbe- und Trackingblocker Pi-hole ohne weitere Einstellungen möglich. Es wäre jedoch kein anständiges Linux- bzw. Open Source-Projekt, wenn es nicht vielfältige Konfigurationsmöglichkeiten geben würde, um Pi-hole an die eigene Umgebung und die persönlichen Präferenzen anzupassen.

Zugriff auf die verschiedenen Konfigurationsmöglichkeiten bekommt man über das Dashboard, welches im Browser über http://IP-Adresse-des-Pi/admin (z. B. 192.168.123.456/admin o. Ä.) aufgerufen werden kann. Nachfolgend werde ich einige wichtige Einstellungen vorstellen.

… als DNS-Server

Wie bereits angesprochen, agiert Pi-hole im lokalen Netzwerk als DNS-Server. Damit das funktioniert, muss im Menü unter Settings -> DNS ein Upstream DNS Server ausgewählt werden, mit dem der Pi kommunizieren kann. Zur Auswahl stehen einige vorkonfigurierte Möglichkeiten (u.A. Google, OpenDNS oder Quad9). Zudem können bis zu vier weitere DNS-Server hinzugefügt werden, indem die entsprechende IP-Adresse eingetragen wird. Somit haben Nutzer die volle Kontrolle über den genutzten Upstream DNS und können z. B. datenschutzfreundliche DNS-Anbieter verwenden.

… und Benutzer- / Gruppenmanagement

Die individuelle Konfigurierbarkeit ist einer der Gründe, warum sich Pi-hole seit Jahren großer Beliebtheit erfreut. Dazu gehört besonders das Benutzer- und Gruppenmanagement.
Du möchtest verschiedene Gruppen anlegen, um für einen oder mehrere Client(s) Content zu sperren, für die anderen aber nicht? Kein Problem!
Du willst einen Client mehreren Gruppen hinzufügen? Kein Problem!
Um individuelle Gruppen anzulegen, muss einfach Group Management -> Groups aufgerufen werden. Die Client-Verwaltung wiederum befindet sich im gleichen Menü jedoch unter dem Unterpunkt Clients.

… und Adlists

Bei der Grundkonfiguration über den Pi-hole-Installer wird eine kuratierte Adlist mitgeliefert, dass Pi-hole direkt einsatzbereit ist. Bei dieser einen Liste muss es aber nicht bleiben. Egal was geblockt werden soll, es gibt die passende Liste dafür. Die folgenden drei Links bieten eine vielfältige Auswahl an regelmäßig aktualisierten Blocklisten:

Eingefügt werden die gewünschten Listen über Group Management -> Adlists. Hier lassen sich alle Listen zentral verwalten (z. B. Kommentare zu einzelnen Listen, Zuweisung zu Nutzergruppen, u.v.m.).

Es existieren noch viele weitere Einstellungsmöglichkeiten wie DHCP, Domainmanagement oder Whitelists, aber diese vorzustellen würde den Rahmen sprengen. Deshalb nun noch ein Punkt, der nicht unerwähnt bleiben sollte.

Grenzen von Pi-hole

Wer bis hierhin gelesen hat, kann den Eindruck bekommen, dass Pi-hole eine großartige Möglichkeit ist, um Werbung und Tracking aus dem eigenen Netzwerk zu verbannen. Und das ist auch zu 95 Prozent richtig. Doch Ehrlichkeit muss sein: NICHT JEDE WERBUNG lässt sich blockieren.

Wenn sich der abgerufene Inhalt und die Werbung den Server und die IP-Adresse teilen, führt ein Blockieren der Werbung zu einem Blockieren des Inhalts. Das bekannteste Beispiel für dieses Vorgehen ist YouTube, dass damit DNS-Werbeblockern wie Pi-hole oder AdGuard Home zuvorkommen will. Um diese Inhalte abzurufen, muss man in den meisten Fällen ein wenig Werbung in Kauf nehmen.
Besonders für Nutzer von Smart-TVs oder TV-Sticks ist das eine bedauerliche Nachricht. (Während es auch hier Optionen gibt, hust SmartTube hust).

Wenn du nun auch Lust auf abwechslungsreiche Projekte in einem modernen IT-Unternehmen im wunderschönen Nürnberg hast und aktuell noch einen spannenden Ausbildungsplatz suchst, dann solltest du noch heute deine Bewerbung an NETWAYS schicken.