Fundamentals for Puppet Goes Public

Heute geben wir bekannt, dass nach Veröffentlichung der Schulungsunterlagen unserer Foreman Schulung, auch die Unterlagen zum Kurs Fundamentals for Puppet als Github Pages und im Source-Code zum nicht kommerziellen Gebrauch bereit stehen. In den kommenden Wochen und Monaten werden Veröffentlichungen zu den weiterführenden Puppetschulungen folgen.

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.

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.