NETWAYS Webinare – Hinter den Kulissen

NETWAYS Seit 2013 veranstalten wir in regelmäßigen Abständen Webinare, um auf Neuheiten in der Open Source Welt, Integrationsmöglichkeiten sowie auf Neuerungen in unserer eigenen Cloud oder SaaS Plattform hinzuweisen.

Im Laufe der Zeit haben sich nicht nur die Themen und die konkreten Inhalte geändert, sondern auch die zugrundeliegende Hard- und Software. Ich als geheimer perfektionist lege bei den Webinarvideos welche auf unserem YouTube-Kanal erscheinen vor allem sehr großen Wert auf Video- und Audioqualität. Wer möchte denn schon ein verwaschenes und knarzendes Video zu bspw. dem Icinga Director ansehen?

Um die Qualität noch zu steigern, haben wir im Juni diesen Jahres die komplette Hardware ausgetauscht. Dadurch sind nun genügend Ressourcen für die Demonstration, den Webcast über GotoWebinar, virtuelle Maschinen und die Aufnahme verfügbar. Darüber hinaus haben wir mit einem neuen Audio-Equipment nun eine viel bessere Tonqualität – sowohl während den Webinaren als auch auf YouTube.

Hardware Technisch kommt dabei ein kleiner Intel NUC zum Einsatz sowie ein Rode Mikrofon mit passendem Mischpult.

Für den Webcast während des Webinars haben wir uns für die Lösung GotoWebinar entschieden, da hiermit sowohl von Windows-PC’s als auch Mac’s ein Webcast durchgeführt werden kann und Benutzer mit Linux-Systemen über den Browser das Webinar verfolgen können. Somit können wir allen eine Live-Teilnahme ermöglichen.

Getreu unserem Firmenmotto “We love Open Source” nutzen wir für die Aufnahme des Webinars für unseren YouTube-Kanal die Open Source Lösung OBS Studio. Dieses mächtige Tool erlaubt nicht nur die Aufnahme von Videos in sehr hoher Qualität, sondern auch die Nutzung von mehreren Audiospuren – was besonders bei der Nachbearbeitung sehr hilfreich ist.

Mit dieser soliden Basis an Hard- und Software gibt es keine Einschränkungen mehr für künftige Webinare und können eine noch bessere Qualität als zuvor abliefern. Alle bisherigen Webinare finden sich natürlich in unserem Webinar Archiv oder direkt auf unserem YouTube-Kanal zum nachträglichen anschauen.

Das nächste Webinar mit dem Thema Icinga 2: Enterprise Monitoring Umgebung ist bereits für den 12. Juli 2017 um 10:30 Uhr geplant. Die Registrierung ist hier möglich.

Vielen Dank an dieser Stelle an die vielen Teilnahmen bisher und auf hoffentlich viele weitere Webinare!

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Chrome, certificates and missing_subjectAltNames

Google has been actively trying to ensure certificate security especially in the last months.

Sometimes this created quite some buzz in the IT World, e.g. when Symantecs policies came into the focus.

Current version 58 of Google Chrome has again adjusted the certificate policy.

Certificates provide two ways to store hostnames: CommonName and SubjectAltName (SAN). RFC 2818 specified in 2000 that CommonName should be deprecated, which Chrome now complies to.

Other browsers are currently still accepting the CommonName, which is mostly used by selfsigned certificates, as in our case :/

Users who wanted to access our internal sites encountered error messages and were forced to use quick and dirty workarounds, such as using a Windows registry “hack”:

Open a cmd-Shell as Administrator and enter:

reg add \HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome /v EnableCommonNameFallbackForLocalAnchors /t REG_DWORD /d 1 /f

which reactivates the fallback to CommonName

As this is just a temporary “solution”, you should issue an RFC 2818 conform certificate. This can be realized by using a complete and compliant certificate signing request (CSR).

You can either use a specially designed *.conf File for this or simply adapt the following shell command:

openssl req -new-key endpoint.com.key -sha256 -nodes  -subj '/C=US/ST=New York/L=New York/O=End Point/OU=Hosting Team/CN=www.endpoint.com/
         emailAddress=administrative-not-existent-address@our-awesome-domain.com/
         subjectAltName=DNS.1=endpoint.com,
         DNS.2=usually-not-convered-domain.endpoint.com,
         DNS.3=multiple-domains-crt.endpoint.com' > www.endpoint.com.csr
The created csr can be fed e.g. into your local CA to issue new certificates which can be rolled out in your environment.
Live long and prosper and be RFC compliant 🙂
Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Monitoring Powershell scripts with Icinga 2


The need to to monitor arbitrary Powershell scripts comes up now and then and often there are some workarounds or alternatives, NSClient for example, named. However in order to have something I can link refer people to when the topic comes up again, I’ll try to provide a quick and simple to adapt solution. Keep in mind that this assumes you have Icinga 2 up and running on your Windows host, Powershell installed and are reasonably sane.

First the the check script I used for demonstration purposes in this case, all it does is check whether a process is running and returning OK or CRITICAL based on that.

if ($args.Length -lt 1) {
	Write-Output "Script requires one argument (Process)"
	Exit(3)
}

$proc=$args[0]

$state = Get-Process $proc -ErrorAction SilentlyContinue
if ($state) {
	Write-Output "PROCESS OK '$proc' is running"
	Exit(0)
} else {
	Write-Output "PROCESS CRITICAL '$proc' is not running"
	Exit(2)
}

Safe it as check_proccess.ps1 somewhere you can find it again. In this case I put next to the other check plugins.

The following are the check_command object and Service apply. And as it turns out it’s not that easy of a task as I thought, it’s mostly Windows fault really… Getting the exit code of a script from Powershell returned to icinga2 required some trickery (credit goes to NSClient for that one). The result is a bit of weird CheckCommand, which can and should be improved.

object CheckCommand "powershell" {
    import "plugin-check-command"
    command = [ "cmd" ]
    arguments = { 
        "Weird command" = { 
            value = "/c echo $powershell_script$ $powershell_args$ ; exit ($$lastexitcode) | powershell.exe -command -"
            description = "This is needed because powershell would not tell us the exit code otherwise"
            skip_key = true
        }
    }   
}

apply Service "check_powerpoint" {
    import "generic-service"
    check_command = "powershell"
    vars.powershell_script = PluginDir + "\check_process.ps1"
    vars.powershell_args = "POWERPNT"
    assign where host.vars.os == "Windows"
}
Jean-Marcel Flach

Autor: Jean-Marcel Flach

Auch wenn man Anderes vermuten möchte: Jean ist nicht unser französischer Austauschazubi, sondern waschechter Bamberger. Die Uni war ihm zu langweilig, deshalb knöpft er sich nun im Development gleich die kniffligsten Aufgaben vor.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 1: Installation

This entry is part 1 of 7 in the series Icinga 2 Monitoring automatisiert mit Puppet

Der erste Release vom Rewrite des Puppetmoduls zu Icinga 2 liegt nun auch schon einige Monate zurück und somit wird es Zeit sich im Zuge einer Blog-Serie genauer damit zu befassen. Zu beziehen ist das Module entweder über die Puppet Forge oder via GitHub.

Zu Beginn steht natürlich immer erstmal die “Installation” bzw. weil Puppet deklarativ arbeitet, die Beschreibung installiert zu sein. Schon hier zeigt sich das Modul flexibel und kann vom Benutzer angepasst benutzt werden. So greift puppet bei einer einfachen Deklaration ohne Parameter auf die auf dem System konfigurierten Repositories zurück. Es bietet jedoch auch die Möglichkeit für die unterstützten Plattformen RedHat, Debian, Ubuntu und Suse, die automatisch Einbindung der offiziellen Icinga-Repositories auf packages.icinga.com.

class { '::icinga2':
  manage_repo => true,
}

Betreibt man selbst ein internes Repository, z.B. als Spiegel des offiziellen, muss dieses vor der Deklaration der Klasse ::icinga2 erfolgen. Beispielhaft hier für RedHat-Systeme:

yumrepo { 'ICINGA-release':
  descr => 'ICINGA (stable release for epel)',
  baseurl => 'http://packages.icinga.org/epel/$releasever/release/',
  failovermethod => 'priority',
  enabled => '1',
  gpgcheck => '1',
  gpgkey => 'http://packages.icinga.org/icinga.key',
}
->
class { '::icinga2': }

Ein Problem beim Einsatz in verteilten Umgebungen und vor allem durch die Benutzung von Icinga als Agent ist die Software-Verwaltung. So sollte keine Instanzen miteinander kommunizieren die zwei Major Releases auseinander liegen, z.B. 2.6.x mit 2.5.x sollte noch ok sein, 2.6er mit 2.4.x und früher jedoch nicht. Besser ist jedoch die Benutzung ausschließlich von 2.6er Versionen. Setzt man hierfür kein Software-Management-Tool ein, kann Puppet helfen. Voraussetzung sollte jedoch ein Repository-Spiegel sein, den man nur zu gegebenen Zeitpunkten synchronisiert.

package { 'icinga2':
  ensure => latest,
}
->
class { '::icinga2':
  manage_package => false,
}

Damit wird bei jedem Puppetlauf dafür gesorgt, das die neuste Version installiert ist. Welche das ist, steuert man über den “händischen” Repo-Sync. Sind für einzelne Features zusätzliche Pakte erforderlich, müssen dann auch diese durch eigene Package-Resources verwaltet werden. Betroffen sind hier außer auf Windows oder FreeBSD die Features idomysql und idopgsql.
Auch das Handling des Icinga Services kann angeschaltet werden. Standardmäßig zieht jede Änderung an einer mit Puppet verwalteten Konfigurationsdatei einen Reload des icinga-Prozesses nach sich. Vor Version 1.2.0 von puppet-icinga2 wird allerdings noch ein Neustart ausgelöst. Für den Fall, dass lediglich zu bestimmten Zeiten eine neue Konfiguration eingelesen werden soll, kann man wie folgt vorgehen:

schedule { 'everyday':
  range  => '2 - 4',
  period => daily,
  repeat => 1,
}

class { '::icinga2':
  manage_service => false,
}
~>
service { 'icinga2':
  ensure => running,
  enable => true,
  schedule => 'everyday',
}

Zu bedenken ist hier nur der Nachteil, dass auch nur zwischen 2 und 4 nachts der Dienst wieder gestartet wird, falls er nicht laufen sollte. Aber dafür gibt es ja das Monitoring. Abschließend für Heute kann nicht unerwähnt bleiben, auch um benötigte Plugins darf sich der Benutzer selbst kümmern. Hierbei ist die Reihenfolge, ob erst die Plugins und dann Icinga oder umgekehrt, unerheblich.

Lennart Betz

Autor: Lennart Betz

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.

Wird auch mal Zeit, dass einer reagiert…

Dass unsere Gesellschaft es sich gut und gerne möglichst bequem macht hat Bernd schon hinreichend ausgeführt.

Dies gilt allerdings nicht nur im politischen Kontext, sondern auch im IT-Kontext.

Paradebeispiel

M$ Windows gehört aktuell der Löwenanteil des Desktop-PC-Marktes – aber nicht unbedingt der Qualität wegen, sondern u.a. aus folgendem Grund:

Einige (vor allem im gewerblichen Bereich) häufig unumgängliche “Killer-Apps” wie M$ Office oder Adobe Photoshop laufen schlichtweg nur auf Windows (oder Mac OS).

Um von diesem hoch unsicheren, kostenpflichtigen, spionierenden und nicht-quelloffenen Betriebssystem wegzukommen, muss der Benutzer zumindest folgende Hürden überwinden:

  • (darauf kommen, dass überhaupt ein Betriebssystem außer Windows und Mac OS existiert)
  • bspw. GNU/Linux herunterladen und auf CD/DVD/USB-Stick brennen
  • davon booten und das System installieren
  • sich in das System und die Unterschiede zu Windows einarbeiten
  • Alternativen für ihre Killer-Apps suchen (sofern überhaupt vorhanden!)
  • sich in letztgenannte einarbeiten…

In solchen Fällen habe ich volles Verständnis für den Sieg der Faulheit. Henry Ford hat mal gesagt:

Denken ist die schwerste Arbeit, die es gibt. Das ist wahrscheinlich auch der Grund, warum sich so wenige Leute damit beschäftigen.

Aber das geht auch viel einfacher – ohne als böser Raubkopierer vom rechten Weg abzukommen – mit …

ReactOS

ReactOS ist keine GNU/Linux-Distribution, die es sich zur Aufgabe gemacht hat, Windows äußerlich möglichst ähnlich zu sehen.

Es ist ein eigenständiges, von Grund auf geschriebenes Betriebssystem, dessen Ziel es ist, möglichst vollständig zu Windows kompatibel zu sein.

Ich selbst habe ReactOS ausprobiert und teile meine Erfahrungen hier mit euch…

Ran an die Buletten!

Wie üblich habe ich das OS in einer virtuellen Maschine ausprobiert – konkret mit VirtualBox. Nachdem ich das ISO-Abbild heruntergeladen habe erstellte ich eine neue virtuelle Maschine…

Es ist wichtig, dass das Modell der (virtuellen) Netzwerkkarte mit dem von mir gewählten übereinstimmt (3. Bild) – sonst kann es passieren, dass das Netzwerk überhaupt nicht funktioniert.

Sobald der Bootvorgang abgeschlossen war, fand ich einen Windows-XP-ähnlichen Assistenten vor – mit dem Unterschied, dass ich die Sprache frei wählen konnte. (Pfeiltasten oben/unten, dann Eingabetaste)

Sobald das vollbracht ist, muss eigentlich nur noch die Eingabetaste malträtiert werden, bis dieser Assistent durch ist…

Dann gilt es einen Neustart abzuwarten. Beim darauf folgenden Assistenten muss man fast genau so wenig den Kopf anstrengen.

Ich habe zwar Name und Organisation angegeben, hätte aber auch genau so gut immer nur direkt “weiter” drücken können…

Nachdem einem weiteren Neustart kann man auch schon loslegen. Fehlermeldungen wie diese habe ich für meinen Teil bedenkenlos weggeklickt:

Aber…

Da war noch was…

Ein gesunder Geist in einem gesunden Körper. Und ein guter Web-Browser auf einem guten Betriebssystem.

Ich habe die Firefox-Versionen 3.6, 28 und 45 aus dem ReactOS-Paketmanager (Ja, Paketmanager! 😀 ) ausprobiert und meine, dass 28 aktuell der beste Kompromiss aus Funktionalität und Stabilität ist…

Fazit

Ist ReactOS nun für den Produktivbetrieb zu empfehlen?

Meiner Meinung nach noch definitiv nicht.

Neben der o.g. mangelhaften Unterstützung von Netzwerkkarten ist das System (… wie sagt man da noch gleich politisch korrekt …) leicht absturzgefährdet.

Konkret habe ich versucht, mir Visual Studio 2015 Community herunterzuladen (erstmal nur herunterzuladen!) …

(-.-“)

Alexander Klimov

Autor: Alexander Klimov

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Icinga 2 Best Practice Teil 2: Konfiguration synchronisieren

This entry is part 2 of 6 in the series Icinga 2 Best Practice

Im heutigen Teil 2 dieser Serie, befassen wir uns mit Konfiguration und deren Synchronisation zwischen Icinga 2 Instanzen in verteilten Umgebungen. Hierbei ist eine solche verteilte Umgebung schon gegeben, wenn der Agent zum Einsatz kommt, also immer wenn Endpoints und Zones beteiligt sind. In Teil 1 wurde Tipps zur Konfiguration der Verbindungsdaten gegeben, heute vertiefen wir, was auf dem Agenten passiert und was dort zusätzlich zum Icinga 2 Core benötigt wird.
Zuerst werden die jeweiligen Plugins auf den Agenten benötigt, seien es für Linux die Monitoring-Plugins oder auf der Windows-Seite die nativen aus dem Icinga-Projekt oder die Plugins vom NSClient++. Bei Icinga, auch in der neuen Version 2, ist das Objekt vom Typ CheckCommand das Bindeglied zwischen Host- bzw. Service-Objekt und dem konfigurierten Plugin, was zur Statusermittlung aufzurufen ist. Wobei ein lokal auszuführender Host-Check üblicherweise nicht Praxisrelevant ist. Das CheckCommand beschreibt wie das Plugin aufzurufen ist, den Ort im Dateisystem wie auch mit welchen Optionen das Plugin ausgeführt wird.

object CheckCommand "mem" {
  command = [ PluginContribDir + "/check_mem.pl" ]

  arguments = {
    "-u" = {
      set_if = "$mem_used$"
      description = "Check USED memory"
    }
...

Für die Pfadangabe zum Plugin ist immer die Verwendung einer Konstanten zu empfehlen, da sich der Ort von Plattform zu Plattform unterscheiden kann und eine Konstante ist für jede Instanz und damit für jeden Agenten gesondert setzbar. Standardmäßig sollten Konstanten in constants.conf im Icinga-Konfigurationsverzeichnis definiert werden.
Beim Plugin check_mem.pl im obigen Beispiel handelt es sich nicht um eines vom Monitoring-Plugin-Projekt, sondern um eines was gesondert auf den Agenten zu installieren ist. Ausserdem benötigen die Icinga-Instanzen der Agenten obige Definition. Für das CheckCommand mem wird diese schon in der ITL (Icinga Template Library) mit geliefert und muss nicht selbst erstellt werden. Auf den jeweiligen Agenten ist lediglich die Definition in icinga2.conf als include einzubinden. Sie befindet sich im PluginContrib-Bereich der ITL.

include <plugins>
include <plugins-contrib>  

In plugins hingegen befinden sich die Definitionen zu Plugins aus dem Monitoring-Projekt. Bei Windows empfiehlt sich die Definitionen der nativen (windows-plugins) bzw. NSClient++-Plugins (nscp) einzubinden.
Was aber nun, wenn man nun für ein Plugin selbst ein CheckCommand-Objekt anlegen muss? Es jeweils auf allen Agenten in die ITL legen? Nein, der ITL-Bereich ist ausschließlich für vom Projekt gepflegte Objekte, eigene würden beim nächsten Update wieder verschwinden. Ausserdem ist eine zusätzliche Pflege von sich ändernden Konfigurationsdateien für jeden Agenten nicht erstrebenswert. Hier kommen nun globale Zonen ins Spiel, die einem Konfiguration auf beliebige Endpoints synchronisieren und automatisch laden.

object Zone "linux-commands" {
  global = true
}
object Zone "windows-commands" {
  global = true
}

Im Gegensatz zum Server bzw. Master und Satelliten-Systemen, ist auf den Windows- und Linux-Agenten nur die entsprechende Zone in der zones.conf einzutragen. In beiden werden auch wirklich nur CheckCommands hinterlegt, Services und Templates werden in der Regel nicht auf Agenten benötigt und sind damit Informationen die besser nicht leicht zugänglich sowie zentral gehalten werden.
Windows kennt leider keinen graceful restart bzw. reload wie Unixsysteme und somit ist hier die Trennung sinnvoll, da Windows einen Stop des Dienstes und nachgelagertem Start nur ausführen muss, wenn es wirklich nötig ist.

Teil 3 dieser Reihe wird sich dann mit praktischen Definition von Services beschäftigen und wie diese ausschließlich aus den zugehörigen Host-Objekten parametresiert werden.

Lennart Betz

Autor: Lennart Betz

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.