Replace spaces with tabs in Visual Studio 2017

Visual Studio has several source code edit settings. This defaults to 4 spaces and no tabs by default and is slightly different to what we use in Icinga 2. There we put focus on tabs in our code style.

Editing the Icinga 2 source code on Windows with Visual Studio requires adjusting the editor settings. Navigate into Tools > Options > Text Editor > C# and C++ and adjust the settings to “Keep tabs”.

I accidentally forgot to specify these settings for C# too, and had the problem that half of the Icinga 2 setup wizard code had 4 spaces instead of tabs. Luckily I’ve found this blog post which sheds some lights in the comments.

Hit Ctrl+H to open the replace search window. Tick the icon to use regular expressions and search for “((\t)*)([ ]{4})”. Add “\t” as replacement text.

Happy coding for Icinga 2 v2.8 – ready for OSMC ūüôā

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach N√ľrnberg mit der Vorliebe, √∂sterreichische K√∂stlichkeiten zu importieren – so mancher Kollege verzweifelt an den s√ľchtig machenden Dragee-Keksi. Oder schlicht am √∂sterreichischen Dialekt der gerne mit Thomas im B√ľro intensiviert wird (“Jo eh.”).
Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am n√§chsten LEGO-Projekt oder geniesst das sch√∂ne N√ľrnberg. Oder – at an Icinga Camp near you ūüėČ

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

Geboren und aufgewachsen in Bamberg, kam Jean (das “-Marcel” ist still) nach einem Ausflug an die Uni, als Azubi zu NETWAYS. Dort sitzt er seit 2014 im Icinga 2 core Entwicklungsteam.

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.