Seite wählen

NETWAYS Blog

Neues vom Icinga-Installer

Mein letzter Blog Icinga Installation mit Director in 10 Minuten zeigte wie man mit dem Icinga-Installer und etwas Nacharbeit per Hand zu einem arbeitsfähigen Icinga-Server mit Director bekam.

Inzwischen ist eine neue Version 0.5.0 vom Icinga-Installer veröffentlicht, die einem auch komplett die Installation und Konfiguration des Directors inkl. Datenbank-Setup und erstem Kickstart-Lauf abnimmt.

Abschließend noch ein kleiner Tipp, wie unter zur Hilfenahme des Installers, die GUI des Icinga Webs ausschließlich per HTTPS ereichbar gemacht wird. Voraussetzung sind natürlich ein vorhandenes Zertifikat nebst privatem Schlüssel und das CA-zertifikat bzw. ein Chain-File. Diese müssen zuvor an den angegeben Orte im Dateisystem abgelegt werden. Die erforderlichen Einstellungen können nicht interaktiv vorgenommen werden, lassen sich aber in /etc/icinga-installer/custom-hiera.yaml (hier ein Beispiel für ein RedHat basiertes System) festlegen:


---
apache::default_vhost: false
apache::default_ssl_vhost: true
apache::default_ssl_cert: /etc/pki/tls/certs/apache.crt
apache::default_ssl_key: /etc/pki/tls/private/apache.key
apache::default_ssl_ca: /etc/pki/tls/certs/my-ca.crt

Möchte oder muss man eine CA-Chain angeben, lautet die Option apache::default_ssl_chain. Diese ersetzt die Zeile mit default_ssl_ca.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Apache Rewrite von HTTP auf HTTPS am Beispiel von Icinga Web 2

Heute gibt es einen kleinen Tipp, wie man seine über einen Apache ausgelieferten Seiten, von HTTP einfach auf HTTPS umleiten kann. Eine einfache Rewrite-Regel sorgt dafür, dass beliebige URLs korrekt auf HTTPS umgeleitet werden. So sind auch als HTTP-URLs gespeicherte Bookmarks weiterhin uneingeschränkt nutzbar. Voraussetzung ist das Laden der Modules rewrite.

Das nun folgende Beispiel bezieht sich auf die Default-Site, es kann aber leicht für weitere Sites abgewandelt werden. Hierzu ist das Beispiel um die Direktiven ServerName und optional ServerAlias zu ergänzen.


<VirtualHost *:80>
RewriteEngine on
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>


<VirtualHost _default_:443>
SSLEngine on
Alias /icingaweb2 "/usr/share/icingaweb2/public"
...
</VirtualHost>

Alle weiteren für TLS und Icinga Web 2 nötigen Einstellungen wurden hier ausgelassen.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Graphite-API für Grafana und Icinga Web 2

Ziel dieses Posts ist es, am Ende die Metriken über die Graphite-API als Backend für Grafana und das Icinga-Web-2-Module graphite betreiben zu können.

Grafana übernimmt hierbei optional die Visualisierung über eigene Dashboards, was ansonsten Graphite-Web leistet. Für Icinga Web 2 ist Grafana nur erforderlich, falls nicht das Module graphite zum Einsatz kommen soll, sondern stattdessen grafana zur Darstellung im Icinga Web 2 verwendet werden sollte.

Die Graphite-API ist in Python implementiert und soll hierbei via HTTPS angesprochen werden. Zusätzlich ist der Zugriff via Basis-Authentifizierung zu beschränken. Dies alles überlassen wir dem Apache, auch die API lassen wir mittels WSGI im Apache laufen.

Der Vorteil gegenüber dem Graphite-Web liegt darin, die ganzen Django-Bibliotheken nicht zu benötigen und auch kein DB-Backend a la SQLite, MySQL oder PostgreSQL. Nachteil ist, das Projekt Graphite-API wird nicht vom Graphite-Team betrieben, somit ist die Pflege und Aktualität nicht sichergestellt.
mehr lesen…

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Monthly Snap January > OSDC 2018, MySQL Cluster Configuration, Firmware version 1.07, Icinga Camp 2018, OSBConf 2018


Hello Two Thousand Eighteen!! It‘s been one month already and lot had happened. Michael shared some information on Modern open source community platforms with Discourse, Thomas took us security tour of Generational change for GnuPG/ PGP keys, Keya discussed 5 reasons why you should be a speaker at OSDC 2018 in Berlin.
Georg said SSL made easy – set up forced forwarding of HTTP to HTTPS, Marius’s A plea for the daydream, Johannes analysed the Galera MySQL Cluster configuration, Martin introduced NETWAYS Monitor – The New Firmware version 1.07.
Keya welcomes you to be a speaker at OSBConf 2018 in Cologne, Gunnar talked about Userspace – Tracing with DTrace, Julia shared upcoming Icinga Camp Berlin 2018 #Monitoringlove, Ufuk talked about server administration with ISPConfig 3. In last Keya introduced the First speakers of OSDC 2018! Happy February!!

Keya Kher
Keya Kher
Marketing Specialist

Keya ist seit Oktober 2017 in unserem Marketing Team. Nach ihrer Elternzeit ist sie seit Februar 2024 wieder zurück, um sich speziell um Icinga-Themen zu kümmern. Wenn sie sich nicht kreativ auslebt, entdeckt sie andere Städte oder schmökert in einem Buch. Ihr Favorit ist “The Shiva Trilogy”.  

SSL leicht gemacht – forcierte Weiterleitung von HTTP auf HTTPS einrichten


In den vorherigen Teilen der Serie wurde bereits die Erstellung und Einbindung der Zertifikate beschrieben. Eines Tages wünscht sich der Admin jedoch die sichere Verbindung aller Seitenbesucher, ohne dass diese manuell ein https voranstellen müssen. Gerade bei einer Migration einer bestehenden Seite wird der
Parallelbetrieb erst nach eingehenden Tests eingestellt und das SSL jeweils forciert, um Seitenbesucher nicht mit ungültigen Zertifikaten oder Mixed Content zu verunsichern.
Die eigentliche Umsetzung ist dann relativ einfach und wird in unserem Beispiel direkt in der Vhost-Definition des Apache vorgenommen. Übrigens, die verfügbaren Vhosts sind zu finden unter: /etc/apache2/sites-available. Hier wird nun der HTTP-Vhost (Port 80) um den unten aufgezeigten Block mit den Rewrites erweitert.

<VirtualHost *:80>
  ServerAdmin webmaster@netways.de
  ServerName www.netways.de
  DocumentRoot /var/www/html/netways.de/
  <Directory /var/www/html/netways.de/>
   Options FollowSymLinks
   AllowOverride All
  </Directory>
  ErrorLog /var/log/apache2/error.log
  LogLevel warn
  CustomLog /var/log/apache2/access.log combined
  RewriteEngine on
  RewriteCond %{SERVER_NAME} =www.netways.de [OR]
  RewriteCond %{SERVER_NAME} =netways.de
  RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
 </VirtualHost>

Damit das Ganze nun auch funktioniert, muss natürlich der SSL-Vhost unter Port 443 erreichbar sein. Wie dieser initial erstellt wird, ist im Artikel SSL-Zertifikat einbinden beschrieben.
Übrigens: wer Let’s Encrypt verwendet, wird im Wizard gleich gefragt, ob SSL forciert werden soll. Der Wizard übernimmt dann die oben gezeigten Schritte. Wie man Let’s Encrypt einsetzt, haben wir natürlich auch schon einmal beschrieben. Damit später keine Seitenbesucher verloren gehen, sollte der HTTP-Vhost, der auf Port 80 läuft, nicht abgeschaltet werden. Die Verbindung ist mit dieser Maßnahme sicher und alle Besucher werden auf https umgeleitet.
Wer damit gar nichts zu tun haben will, und trotzdem stets auf der sicheren Seite sein will, der kann natürlich seine Seite auch bei NETWAYS im Managed Hosting betreuen lassen. Hier kümmern wir uns darum.
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um: