SSL leicht gemacht – CSR und Keyfile erstellen und Zertifikat ordern

This entry is part 1 of 1 in the series SSL leicht gemacht

Oftmals kommt trotz der breiten Verfügbarkeit von Letsencrypt der Wunsch nach kostenpflichtigen Zertifikaten auf. Die Gründe sind vielfältig: längere Gültigkeit, Wildcard-, Multidomain- oder Extended-Validation (Grüne-Leiste) Zertifikate – all das bietet Letsencrypt leider nicht und deshalb ist der Bedarf nach solchen Zertifikaten noch immer vorhanden. In den nächsten Wochen werden wir immer wieder Blogposts zum Thema SSL erstellen, alle zu finden in unserer Serie “SSL leicht gemacht”

Zu aller Anfang wird ein CSR (Certificate Signing Request) und ein Keyfile (privater Schlüssel) benötigt. Aus Sicherheitsgründen empfehlen wir prinzipiell die Erstellung gleich auf dem Zielsystem des Zertifikates vorzunehmen, so müssen die Daten nicht umgezogen werden und bleiben nicht “zufällig” irgendwo liegen.

Los geht’s mit dem Kommando

openssl req -new -nodes -keyout netways.de.key -out netways.de.csr -newkey rsa:4096

Dadurch wird im aktuellen Verzeichnis ein Privatekey mit einer Schlüssellänge von 4096 Bit (default 2048) angelegt. Der folgende Wizard sammelt nun noch die Daten für das CSR ein.

Hier wird nach dem Land, dem Staat, der Stadt, der Firma, der Abteilung, der zu sichernden Domain und der Kontaktmailadresse gefragt. Eingaben können auch leergelassen werden und mit der Eingabetaste übersprungen werden (ACHTUNG: Defaultwerte (sofern vorhanden) aus den eckigen Klammern werden übernommen).

Zur Kontrolle kann das CSR noch mit dem Kommando

openssl req -in netways.de.csr -noout -text

überprüft werden. Übrigens gibt es bei Umlauten (wie so oft) Probleme. Wir vermeiden diese gern durch die Verwendung englischer Städtenamen wie im aktuellen Beispiel zu sehen.
Abschließend kontrollieren wir das Keyfile noch (zumindest, ob es so in der Art aussieht).

Fertig, nun geht man zur Bestellung des Zertifikates über. Hierzu kann man auf jeden beliebigen Zertifikatshändler zurückgreifen. Wegen anhaltender “Unstimmigkeiten” bei Google und Symantec empfehle ich persönlich (bei der Neubestellung) auf Produkte von Comodo zurückzugreifen. Die Comodo-Zertifikate sind preislich im Mittelfeld und die Akzeptanz der Zertifikate ist hoch. Für die Bestellung wird nur der CSR benötigt. Das Keyfile sollte keinesfalls an irgendjemanden weitergegeben werden und auf dem Server verbleiben.

Bei der Bestellung werden nochmal alle möglichen Daten, gewünschte Laufzeit usw. abgefragt. Unter anderem auch die Mailadresse. Die Auswahlmöglichkeiten dieser ist oftmals beschränkt. Die ausgewählte Mailadresse muss zwingend verfügbar sein, um die Validierung via Mail abzuschließen und ein Zertifikat zu erhalten. Sofern alles geklappt hat, bekommt man später in der Regel per Mail das Zertifikat und ggf. das CA-Bundle zugeschickt.

Wie das alles nun zusammen eingerichtet wird, schreibe ich im nächsten Artikel.

Georg Mimietz

Autor: Georg Mimietz

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Icinga Web 2 Modul fileshipper imports im Director

Es werden viele Importe im Icinga Web 2 Modul Director via Ldap / SQL-Ressource getätigt, aber viele übesehen eine einfache Möglichkeit bestehende Dateien mittels Icinga 2 Modul “fileshipper” in den Icinga Web 2 Director zu importieren. Wie man dieses umsetzt werde ich an einem einfachen Beispiel, einer CSV-Datei hier beschreiben.

Zuerst muss man sich das Fileshipper-Modul von Github per “git clone” oder .zip-Datei herunterladen und in dem Verzeichnis '/usr/share/icingaweb2/modules/' ablegen und anschießend das Verzeichnis in “fileshipper” umbennen, denn sonst erkennt es Icinga Web 2 als Modul nicht an.
# cd /usr/share/icingaweb2/modules/ && git clone https://github.com/Icinga/icingaweb2-module-fileshipper.git
oder
# cd /usr/share/icingaweb2/modules/ && unzip master.zip

Anschließend muss das neu installierte Modul noch aktiviert werden,  mit dem icingacli Kommando:
# icingacli module enable fileshipper
icingacli module list
MODULE VERSION STATE DESCRIPTION
director 1.3.1 enabled Director - Config tool for Icinga 2
doc 2.4.1 enabled Documentation module
fileshipper 1.0.0 enabled Fileshipper for Icinga Director
monitoring 2.4.1 enabled Icinga monitoring module

Es geht aber aber auch über die Icinga Web 2 –  Oberfläche siehe Screenshot:

Nachdem das Modul installiert und aktiviert ist kann es losgehen. Zuerst erstellt man das Verzeichnis “fileshipper” unter # mkdir /etc/icingaweb2/modules/fileshipper und erstellt eine import.ini Datei in der das Verzeichnis angeben wird, wo sich die zu importierenden Dateien (.csv) liegen.
[fileshipper files]
basedir = "/usr/local/share/"

Dann wird im Icinga Web 2 => Director => Automation => Add Import Source

ein Name des zukünftigen Imports z.B fileshipper-import-hosts vergeben und bei Source “Import from files (fileshipper) ausgewählt.

Jetzt muss die neue Import-Quelle noch modifiziert werden z.B. so:

Ich denke das Bild ist selbsterklärend und Bedarf keiner weiteren Erklärung.

Jetzt kann man einen Import run starten in dem man auf die Import-Source fileshipper-import-hosts und Trigger Import Run auswählt.

Nun sollte in der Voransicht (Preview) die importierten Hosts sichtbar werden.

Um jetzt aus diesen RAW-Daten Icinga 2 konforme Objekte werden zu lassen brauchen wir eine Sync-Rule die man z.B.so anlegt:


Hier wird in der Maske angeben, welcher Typ (Host-Objekt) daraus werden soll und ob bereits existierende Daten ersetzt (replace) oder zusammengeführt (merge) werden sollen.
Mit Purge können bereits existierende Daten gelöscht werde, JA oder NEIN.

Im Kartei-Reiter “Properties/Eigenschaften” werden die Felder vom Import (Source/Quelle) den Icinga 2 konformen Zielen (Destination) zugeordnet:

Danach kann der Sync-Run der erstellten Sync-Rule gestartet werden und bei erfolgreichen Lauf, werden Konfigurations-Dateien erstellt und sind bereit für den Director zu deployen.

Im Activity-Log kann der Vorgang nochmals überprüft werden, bevor man die Konfiguration per Director deploy übernehmen kann.

So jetzt sollten nach erfolgreichem Deployment die Hosts im Icinga Web 2 unter Hosts sichtbar sein.

 

Im Rahmen einer Icinga 2 Fundamentals Schulung, die wir anbieten, werden auch noch weitere Import-Quellen besprochen und praktisch vollzogen.

Unter anderem haben wir noch weitere Schulungen zu Open Source Themen im Portofolio, einen Überblick bekommen Sie hier bei NETWAYS-Schulungen.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Apply Service for im Icinga Director

Mit den Icinga 2 Apply Rules ist es spielend einfach möglich Services zu erstellen. Möchte man mehrere, gleiche Services erstellen (z. B. mehrere Port-Checks oder SNMP-Counteer) kommt Apply For zum Einsatz.

Im Zusammenhang mit dem Icinga Director erhalten wir ab und an Fragen zur Konfiguration von Apply For und sehr oft stellt sich dabei heraus das die Erklärung dieser Konfiguration per E-Mail oder Telefon sehr umständlich ist. Daher habe ich ein kleines Video für euch vorbereitet.

 

Schönes Wochenende! 🙂

Tobias Redel

Autor: Tobias Redel

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.

Fehlerkultur – Das Fundament für Innovation

Wer ab und an mal einen DevOpsDays-Event besucht oder einigen Galionsfiguren bei Twitter folgt, ist vermutlich schon über den Begriff Fehlerkultur gestolpert. Der Begriff ist im Grunde nicht neu und bereits seit den 70ern beschäftigt man sich mit der positiven Auswirkung einer vorhanden Fehlerkultur.

Was bedeutet Fehlerkultur

Etwas hemdsärmelig betrachtet würde ich sagen, dass es die Art und Weise beschreibt wie ein Gruppe bzw. Firma mit gemachten Fehlern, deren Kommunikation und möglichen Konsequenzen umgeht. Sprich die Reaktion auf Fehler, unabhängig davon ob die Mitarbeiter hierarchisch darüber, daneben oder darunter stehen. Das der Umgang mit Fehlern darüber hinaus auch abhängig von realen “Kulturen”, also Europäern oder bspw. Asiaten ist, ist ein Sachverhalt auf den ich nicht eingehe. Bei einer globalen Zusammenarbeit (haben wir kaum), ist er jedoch von großer Bedeutung und findet bei großen Unternehmen und deren HR-Abteilungen auch Beachtung.

Keiner macht gerne Fehler!

Fehler zu machen und dann auch noch zuzugeben schadet unserem Selbstwertgefühl. Somit ist es erstmal vollkommen “natürlich”, dass man sich mit einem “Sorry, ich habe es verkackt!” nicht wirklich wohl fühlt. Menschen mit einem sowieso schon geringen Selbstwertgefühlt fällt es umso schwererer eigene Unzulänglichkeiten zuzugeben und es verlangt ihnen viel Überwindung und Energie ab.

Das “hochhalten” des eigenen Selbstwertgefühls ist auch Basis für eine ganz bekannte kognitive Befangenheit, der Selbstwertdienlichen Verzerrung. So projizieren wir Misserfolge nahezu automatisch auf DIE ANDEREN und Erfolge auf uns selber. Jeder wird sich bei eigenem Scheitern schon mal dabei erwischt haben den Fehler, Ursache, oder besser die Wurzel allen Übels beim Kollegen oder Chef zu suchen. Für den Perfektionisten ist es dabei besonders schwierig Fehler zuzugeben. Da er im Vergleich zu anderen viel mehr Energie in Überlegung und Umsetzung s(eines) Projekts investiert hat, trifft ihn ein Scheitern und die eigene Einsicht darüber besonders hart.

Wie man man Menschen zur Fehlerkommunikation ertüchtigen?

Mit Sicherheit gibt es kein einfaches Erfolgsrezept um Menschen zur Kommunikation von Fehlern zu motivieren, aber es gibt durchaus einiges was mit im Team und Unternehmen dafür tun kann:

  • Gebt selbst Fehler zu
    Das bedeutet natürlich erstmal sich selbst zu überwinden und sich eigene Schwächen zuzugestehen. Persönlich ist mir dass vor vielen Jahren unglaublich schwer gefallen und ich war eher motiviert in tagelanger Nachtarbeit die gemachten Fehler zu “verschleiern”. Heute fällt es mir wesentlich leichter vor Kollegen und Mitarbeitern die eigenen Unzulänglichkeiten zuzugeben. Die Menschen um uns rum haben darüber hinaus meist eh ein besseres Gefühl darüber, als wir Ihnen zutrauen und die klassische Schuldverschiebung schwächt einen über die Zeit mehr als sie einem guttut. Vor einigen Tagen wurde ich bei einem Vortrag in Amsterdam gefragt “Gibt es Ding die Du heute anders machen würdest?”. Meine Antwort darauf: “Kann ich Dir eine Excel-Liste schicken?”
  • Versucht Probleme in der Gruppe zu analysieren
    Einer einzelnen Person fällt es aus genannten Gründen immer schwer die eigenen Unzulänglichkeiten zuzugeben. In der Gruppe verschwindet die Angst häufig und das Empfinden die Fehlerkonsequenz auch gemeinsam zu schultern nimmt dem Einzelnen den Druck. Klar ist, dass auch in der Gruppe jemand den Anfang machen muss, aber hat sich so ein Vorgehen einmal etabliert findet sich der- oder diejenige immer leichter.
  • Entwickeln sie Empathie und zeigen sie diese auch
    Das klingt jetzt natürlich einfacher als es ist, aber einige Denkmuster kann man sich schon zurechtlegen. Es ist wichtig anderen das Gefühl zu geben, das Fehler unabdingbar sind. Ist ein Fehler Resultat eines neuen Ansatzes oder des Versuchs Dinge zu verbessern, sollte man natürlich trotzdem kritisch über den Fehler sprechen. Umso mehr dann aber auch das Bestreben nach dem nächsten Versuch unterstützen und die Angst vor Fehlern nehmen.
    Aus der eigenen Perspektive ist es darüber hinaus wichtig, die eigene Unzufriedenheit über eine Situation zu äußern. Auch wenn Fehler gemacht werden und gemacht werden sollen, haben mögliche Fehlerauswirkungen auch Konsequenzen. Diese müssen den Beteiligen Personen dann aber auch klar sein und kommuniziert werden. Der Grat zwischen “Mach nichts falsch, denn sonst kostet es viel Geld” und “Versuch doch mal was Neues” ist definitiv schwierig, aber sonst könnte es ja jeder

Was bringt das alles?

Ich denke es ist wichtig sich selbst und auch allen anderen immer wieder klar zu machen, dass es ohne Fehler keine Innovation gibt. Wenn Menschen Angst vor dem Eingeständnis haben, sich in der Gruppe unwohl fühlen und der Chef sie im Meeting zusammenfaltet werden sie in der Regel alles tun um Fehler zu vermeiden. Ergo machen sie es wie “immer” und so bleibt eben dann auch alles wie es ist. Ich bezweifle stark, dass man eine solche Kultur einfach nur ein Meeting erzeugen kann, aber daran zu arbeiten und sich mögliche Konsequenzen vor Augen zu halten ist eine wichtige Selbstreflektion.

An mir selbst merke ich immer wieder, dass ich kein Problem mit einem Fehlerzugeständnis oder der Tatsache das etwas nicht funktioniert hat, habe.  Grantig macht es mich aber, wenn ich das unter den Teppich gekehrte dann doch herausbekomme ohne das es mir gesagt wird.

Und ich gehe gleich noch mit gutem Beispiel voran, der Blogpost sollte eigentlich um 11:00 raus. Ich habs verkackt! 🙂

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

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".

Icinga 2 – Monitoring automatisiert mit Puppet: “Icinga 2”-Agent

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

Nachdem Lennart sich bereits mit vielen Aspekte des Moduls befasst hat, will ich dieses Mal auf die Installation von Icinga 2 als Agenten eingehen. Neben einem generellen Einstieg mit zu beachtenden Konfigurationsoptionen, will ich hierbei auf die verschiedenen Möglichkeiten für die benötigten Zertifikate und Anbindung an die übergeordnete Zone eingehen.

Puppet-Icinga2

Die Installation und Feature-Konfiguration erfolgt wie Lennart dies in den ersten beiden Teilen der Serie beschrieben hat. Hierbei möchte ich beim Agent sicherstellen, dass keine lokale Konfiguration angezogen wird, da ich für die Verteilung der CheckCommands die Konfigurationssynchronisation von Icinga 2 nutzen möchte. Alternativ können diese zwar auch über Puppet verteilt werden, da ja auch die Plugins installiert werden müssen, aber in den meisten Umgebungen trenne ich an dieser Stelle Konfiguration der Monitoring-Infrastruktur von der eigentlichen Monitoring-Konfiguration. Der Start meines Agenten-Profils sieht also meist so aus:

  class { 'icinga2':
    confd       => false,
    manage_repo => true,
    features    => ['checker','mainlog'],
  }

(more…)

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.