SSL leicht gemacht – CSR und Keyfile erstellen und Zertifikat ordern

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 Artikel Zertifikat einbinden (Apache2).
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

Georg Mimietz
Georg Mimietz
Lead Support Engineer

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.

Einbinden von NWS Icinga 2 Satelliten

Über unsere SaaS Plattform NWS bieten wir seit Beginn die Möglichkeit, Icinga 2 Satelliten Systeme zu betreiben und diese in die eigene Icinga 2 Monitoring Infrastruktur zu integrieren.
Dadurch wird ermöglicht, dass bspw. Webseiten oder andere externe Dienste (Mail, DNS, FTP, etc.) von außen überwacht werden können und die Ergebnisse in das Hausinterne Monitoring übertragen werden.
Hosted man bspw. einen Webshop wie wir (shop.netways.de), reicht es nicht nur zu überprüfen ob die MariaDB oder Apache Dienste funktionieren und die virtuelle Maschine in unserer Cloud verfügbar ist, sondern es ist auch wichtig die externe Sicht der Kunden zu überwachen. Somit erfährt man gleich ob eine externe Erreichbarkeit sichergestellt ist und Kunden bspw. einkaufen können.
In diesem Blogartikel möchte ich beschreiben, wie man den Icinga 2 Satelliten aufsetzt und per Icinga 2 Cluster Protokoll in das eigene Monitoring integriert.
Hat man sich in der NWS Plattform angemeldet, erreicht man über den oberen Reiter “Apps” alle von uns angebotenen Produkte. Nachdem man einen Icinga 2 Satelliten gestartet hat, klickt man auf diese App und folgender Bildschirm erscheint:
(mehr …)

Christian Stein
Christian Stein
Lead Senior Account Manager

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

Poor man's Docker mit ownCloud

Docket basketFür mich privat betreibe ich momentan 3 eigene Server, für WordPress, ownCloud, GitLab, E-Mail und lauter anderer Kleinkram der mich privat interessiert, oder einfach nicht in die Cloud legen möchte.
Früher habe ich von Hand einen Apache Server kompiliert, dann Pakete verstanden und genutzt, und jetzt gibt es da diese Docker… – Magie für viele.
Ich habe mich längere Zeit gefragt, wie ich, oder eine kleinere Firma effektiv mit Containern arbeiten kann. Ganz ohne eine große Cloud, und komplexe Prozesse die man erst aufbauen muss.
Eigentlich ist es ganz einfach, nur ein paar Grundregeln muss man verstehen:

  • Eine Anwendung pro Container
  • Mehrere Container zusammen geben eine große Anwendung
  • Ggf. sorgt ein Webserver davor für Bereitstellung ans Internet, und SSL
  • Der Server auf dem die Container laufen sollte eingeschränkt werden

Im folgenden möchte ich erklären wie ich meine eigene private ownCloud betreibe, vielleicht hilft es jemandem.
(mehr …)

Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

Eine aktuelle Fassung des logstash Quickstarts

Viele Open Source Projekte kommen so in Fahrt, dass man mit dem Verfolgen der Entwicklung kaum noch hinterherkommt. Auch wenn das zusätzliche Arbeit verursacht, so ist das dennoch ein Grund zur Freude. Dem entsprechend gibt es heute eine Aktualisierung des logstash Quickstart Tutorials, das ich vor einiger Zeit gepostet habe.logstash_01
Vieles hat sich beim Wechsel von Version 1.3 auf 1.4 geändert, dennoch sollten Migrationen (grossteils) reibungslos vonstatten gehen. Dieses Tutorial soll möglichst schlank und aufs Wesentliche beschränkt bleiben, weshalb ich hier nicht gross auf die Unterschiede eingehen möchte. Dennoch ist es etwas aufwändiger als die vorherige Version, dafür hat man danach eine Teststellung, die nicht nur zum Rumspielen taugt, sondern gleich der Grundstock einer Testumgebung werden kann. Genug der Vorrede, jetzt geht’s ans Eingemachte.
Inzwischen ist es auf jeden Fall empfehlenswert, logstash aus den zur Verfügung gestellten Paketen zu installieren, die praktischerweise auch noch in Repositories organisiert sind. Als Voraussetzung muss Java installiert sein. OpenJDK funktioniert für einfache Beispiele, auch wenn das Projekt inzwischen Sun, äh, Oracle Java empfiehlt.
Für die Installation werden die Repositories konfiguriert. Die nötigen Repofiles und eine Anleitung, wie man sie inkludiert, findet man hier für logstash und hier für elasticsearch.

yum install logstash elasticsearch

(Der aufmerksame Leser erkennt jetzt, dass dieses Tutorial für CentOS/RHEL/Fedora ausgelegt ist, es funktioniert aber ganz ähnlich mit Debian, SLES und diversen anderen Linuxdistributionen oder auch anderen Betriebssystemen) Etwas unüblich ist, dass sich logstash nach der Installation nicht sofort starten lässt, sondern erst eine Konfigurationsdatei angelegt werden muss. Ein Beispiel könnte folgendermassen aussehen:

input {
  file {
    path => "/var/log/messages"
  }
}
output {
  elasticsearch {
    cluster => "elasticsearch"
    protocol => "http"
  }
}

Die legt man nach /etc/logstash/conf.d/logstash.conf . Es ginge noch etwas einfacher mit einer embedded Variante von elasticsearch, aber so kann man den Testhost auch gleich für etwas grössere Tests verwenden und die zusätzliche Installation ist nicht wirklich aufwändig, wie man gesehen hat.
Da im Beispiel der logstash Prozess auf ein File zugreifen will, das eigentlich nur für root lesbar ist, sollte der Prozess nicht als User logstash, sondern als User root gestartet werden. Dazu in /etc/sysconfig/logstash (auf Debian /etc/default/logstash) folgenden Eintrag vornehmen: LS_USER=root. Für Tests schadet es übrigens auch nicht, erstmal SELinux auf permissive zu setzen.
Jetzt noch

service elasticsearch start
service logstash start
service logstash-web start

und mit dem Browser http://localhost:9292/index.html#/dashboard/file/logstash.json (oder statt localhost den Namen / die IP der Maschine mit logstash, falls man nicht lokal testet) aufrufen. Fertig. Ja, ehrlich, das wars. Logstash sammelt lokale Logfiles ein, speichert sie in Elasticsearch und dort kann man sie mit Kibana durchsuchen.
Wer jetzt ein wenig weiter experimentieren möchte, kann noch ein paar Filter mit einbauen, die die Lognachrichten weiter aufbereiten. Da auf jedem System andere Dienste in die Logs schreiben und oft auch andere Logformate eingesetzt werden, kann es sein, dass das folgende Beispiel nicht überall funktioniert.

input {
  file {
    path => "/var/log/messages"
  }
}
filter {
  grok {
    match => [ "message", "%{SYSLOGLINE}" ]
  }
}
output {
  elasticsearch {
    cluster => "elasticsearch"
    protocol => "http"
  }
}

Dieses Beispiel setzt den grok Filter ein, um Syslognachrichten mit einem mitgelieferten Muster in ihre Einzelteile zu zerlegen. Sieht man im Kibana (das vorhin aufgerufene Webinterface) nach, erscheinen am linken Rand plötzlich neue Felder, nach denen man Filtern kann. So wird beispielsweise das program Feld erkannt, das Teil des Syslog headers ist.
kibana_fields
Ein Beispiel, das auf allen Linux Systemen funktionieren sollte, ist das folgende.

input {
  file {
    path => "/var/log/messages"
    type => "syslog"
  }
  exec {
    type => "system-load-average"
    command => "cat /proc/loadavg | awk '{print $1,$2,$3}'"
    interval => 30
    tags => "sysstat"
  }
}
filter {
  if [type] == "syslog" {
    grok {
      match => [ "message", "%{SYSLOGLINE}" ]
    }
  }
  if [type] == "system-load-average" {
    grok {
      match => [ "message" , "%{NUMBER:load_avg_1m} %{NUMBER:load_avg_5m} %{NUMBER:load_avg_15m}" ]
      named_captures_only => true
      add_tag => "groked"
    }
  }
}
output {
  elasticsearch {
    cluster => "elasticsearch"
    protocol => "http"
  }
}

Hier wird in regelmässigen Abständen ein Shellcommand ausgeführt, das aus /proc die aktuelle Load ausliest und als Logevent verschickt. Die wird durch den grok Filter in Felder zerlegt, wo sie dann z.B. zum Zeichnen von Graphen in Kibana oder Graphite verwendet werden kann. Man könnte auch beim Überschreiten einer bestimmten Load ein passives Checkergebnis an Icinga schicken, um darüber zu alarmieren. Klar macht das letzte Beispiel in der Praxis wenig Sinn, wenn es die hervorragenden Monitoringplugins gibt, aber es zeigt, wie vielseitig logstash sein kann. Man könnte Icinga dabei sogar umgehen und beim Überschreiten einer Grenze der load gleich per Mail, IRC, oder Jabber einen Alarm an den zuständigen Admin schicken.
schulung_logstashIch kann nur jedem empfehlen, zumindest den Anfang des Quickstarts durchzuspielen. Das Experimentieren mit logstash und dem Rest vom ELK Stack macht einfach Spass. Wenn es dann daran geht, die Erkenntnisse so zu vertiefen, dass sie in einer Produktivumgebung eingesetzt werden sollen, geht’s hier zu Schulung und Consulting. Die beiden machen übrigens auch Spass.
Für Experimentierfreudige gibt’s als Dreingabe noch ein paar Stichworte zum Erweitern des Kibana Dashboards:

  • Rechts unten auf “Add row”, damit eine neue Zeile in hinzufügen.
  • In der neuen Zeile auf “Add panel to empty row”
  • Panel type: “terms”
  • Alle Felder so lassen, wie sie sind, nur die folgenden ändern: title: “Programme”, field: “program”, style: “pie”

 

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Der Klassiker: syslog -> logstash

Bevor es an den Aufbau neuer Features mit logstash geht, soll erst mal der übliche Vorläufer von logstash in Netzwerken ersetzt werden: Der gute alte Syslog Server.
Zu Syslog finden sich weiterführende Informationen in der Wikipedia, deshalb hier nur kurz umrissen: Syslog ist sowohl ein Protokoll, als auch der Name eines Tools, das dieses Protokoll benutzt, um Logs innerhalb eines Systems von Applikationen einzusammeln und in Logfiles zu schreiben und sie auch übers Netzwerk an andere Hosts zu schicken. Diese anderen Hosts sind normalerweise die eingangs erwähnten Syslog Server, die einfach mal alles an Logs sammeln, was ihnen präsentiert wird und in lokale Logfiles schreiben.logstash_01
Gegenüber Lösungen wie logstash ergeben sich bei Syslog vor allem 3 Probleme:

  1. Die Lösung skaliert nicht. Wenn ein Server nicht mehr mit dem Annehmen und Wegschreiben von Logs mitkommt, kann man ihn höchstens durch stärkere Hardware ersetzen. Irgendwann ist da aber Schluss.
  2. Die Logs liegen genau so am Syslog Server wie auf stand-alone Hosts auch. Also unstrukturiert. Durchsuchen und Auswerten verlangt normalerweise einiges an grep/awk oder Perl und Regex magic.
  3. Die Übertragung passiert normalerweise unverschlüsselt über UDP. Beides will man normalerweise nicht für kritische Logs. (Auch wenn Ableger wie rsyslog und syslog-ng da teilweise Abhilfe schaffen)

Punkt 1 und 2 kriegt man mit logstash sehr einfach in den Griff. Man kann mit logstash einen Syslog Server bauen, der Logs sowohl im klassischen Syslog Format vom syslog Tool, als auch von neueren Tools wie rsyslog, die auch über TCP und teilweise sogar verschlüsselt senden können, annehmen kann.

input {
  syslog {
    type => "syslog"
    port => 514
  }
}

Aus. Das war’s. Mehr ist nicht nötig und das ist sogar schon etwas mehr, als nötig ist. Der Port ist auch ohne Angabe auf dem Syslog Standard von 514, allerdings sowohl TCP, als auch UDP. Der type ist übrigens frei wählbar und wird nur später benutzt, um den Weg der Nachricht durch logstash zu planen. Er hat nichts damit zu tun, dass Daten im Syslog Format erwartet werden. Weitere Informationen zu den möglichen Optionen des Syslog Input gibt’s in der logstash Dokumentation.
Nochmal zusammengefasst reicht es, dem Quickstart aus dem ersten Beitrag dieser Serie zu folgen und den syslog Teil des obigen Beispiels zum input hinzuzufügen. Jetzt noch die IP Adresse des bisherigen Syslog Servers auf den logstash Server verschieben und fertig.
Zugegeben, natürlich war das Quickstart Beispiel nicht für eine Produktivumgebung gedacht. Dazu fehlt zumindest noch Ausfallsicherheit und die Meldungen werden immer noch ziemlich unstrukturiert abgelegt. Die zum Aufbereiten nötigen Filter können aber ebenso nach und nach hinzugefügt werden. Ziel dieses Artikels war ja, den Syslog Server zu ersetzen und auf weitere Verbesserungen vorzubereiten.
Was mehr Aufwand benötigt ist die gesicherte Übertragung der Syslog Nachrichten an den logstash Server. Mit syslog ist das sowieso nicht möglich. Mit rsyslog Sind aber auf jeden Fall Änderungen an der Konfiguration jedes sendenden Host nötig.
Wer das Beispiel einfach mal ausprobieren möchte und bisher keinen zentralen Syslog Server hatte, kann mit folgenden kurzen Codebeispielen andere Server zum Versand bringen.
syslog:

*.* @192.168.200.2

Wobei 192.168.200.2 hier die IP Adresse des logstash Servers ist. Der Eintrag ist eine Zeile aus /etc/syslog.conf auf den meisten Systemen. Danach muss syslog neu gestartet werden. Mit service syslog restart auf gängigen Linux Distributionen, sofern sie überhaupt noch syslog einsetzen und mit svcadm disable system-log ; svcadm enable system-log auf Solaris.
rsyslog:

*.* @@192.168.200.2:514

Wobei die doppelten @ dafür sorgen, dass die Übertragung über TCP stattfindet. Diese Zeile kann in eine eigene Datei in /etc/rsyslog.d gelegt werden.schulung_logstash
Es soll natürlich hier nicht verheimlicht werden, dass logstash auch eigene Möglichkeiten mitbringt, die Daten auf dem Host einzusammeln und an einen zentralen logstash Server zu schicken. Wie das geht, ist Inhalt eines späteren Artikels oder unserer logstash Schulungen.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

logstash – Der 15 Minuten Quickstart Guide

Da ich mich die letzte Zeit intensiv auf logstash Schulungen und – Consulting vorbereitet habe, liegt es nur nahe, dass ich auch zu diesem Thema blogge. Bei so zentralen Systemen ist es natürlich wichtig, sich intensiv damit auseinander zu setzen und viel Zeit zu investieren, um erstmal die Hintergründe und Zusammenhänge zu verstehen, damit man eine Installation planen kann, bevor man das erste Mal Code in die Hand nimmt. Prinzipiell ist das so richtig, aber es muss auch mal ok sein, einfach mal mit einem neuen, interessanten System rumzuspielen, bevor man sich intensiver damit beschäftigt, um erstmal ein gewisses Gefühl für die Arbeitsweise zu bekommen und weil es einfach Spass macht.

natural_logstashUnd genau dafür soll dieser Quickstart Guide sein. Zuvor aber dennoch ein paar Worte dazu, was logstash denn nun eigentlich ist und wozu man es verwenden kann und soll. Wer das schon weiss, darf auch weiter nach unten scrollen. Aber keine Sorge, weitere Infos über die Abläufe in einer logstash Installation kommen noch in dieser Blogserie. Genauso ein paar Beispiele, wie Logs von logstash aufbereitet werden können. Wer also keine Lust hat, sich mal kurz logstash zu installieren, muss nur ein wenig warten.

Jeder Computer und auch sonst fast jedes Gerät, mit dem man in der IT zu tun bekommt, schreibt Logfiles, wo besondere Ereignisse festgehalten werden. Das hilft nicht nur, aber insbesondere, beim Erkennen und Nachvollziehen von aufgetretenen Fehlern. Als Administrator steht man nun vor dem Problem, dass diese Logfiles auf den Systemen bleiben und man sich erstmal dorthin verbinden muss, um sie zu lesen. So bleiben oft kleinere Fehler, die grössere Ausfälle im Vorfeld ankündigen und helfen würden, diese zu verhinlogstash_01dern, unerkannt. Für diesen Fall bieten wir gerne Unterstützung mit Monitoring wie Icinga an. Wer aber nicht erst warten möchte, bis es kracht, sondern schon proaktiv handeln möchte, muss irgendwie an die Logfiles rankommen, ohne den halben Tag damit zu verbringen, sie von den Systemen abzuholen. Natürlich gibt es noch viele weitere Gründe, Logs zu sammeln, zu lesen und auszuwerten, aber das würde den Rahmen eines Einleitungsartikels sprengen. Es gibt bereits seit langer Zeit Lösungen wie logwatch oder syslog Server, die zumindest helfen, die Informationen aus Logfiles zu sammeln. Wozu dann logstash? Ein paar der Vorteile gegenüber herkömmlicher Lösungen sind:

  • logstash kann auf vielen verschiedenen Systemen ausgeführt werden und ist als Java (bzw. JRuby) Anwendung nicht auf ein paar Betriebssysteme beschränkt
  • logstash kann alle möglichen und unmöglichen Formate lesen. Syslog und Windows Eventlog sind naheliegend, aber auch über das Drupal dblog oder IRC können Nachrichten in logstash kommen. Gibt es keine Schnittstelle für einen Dienst, können auch beliebige Textfiles auf Systemen als Logfile angesehen und ausgewertet oder die Rückgabe beliebiger Programme gelesen werden.
  • logstash ist von vornherein darauf ausgelegt, hervorragend zu skalieren. Alle Komponenten können mehr oder weniger auf beliebig viele Server ausgebracht und miteinander verbunden werden. Teilweise als sehr einfach zu verwaltende loadbalancing und high availability cluster, teilweise einfach als redundante Instanzen, die nichts voneinander wissen und einfach jeweils nur einen Teil der zu verarbeitenden Daten erhalten. Und das, wie von Tools, die wir unterstützen, nicht anders zu erwarten, alles ohne Lizenzkosten. Wer dann noch freie Linux Distributionen einsetzt, wird eigentlich nur durch Anschaffungs- und Betriebskosten der Hardware in der Grösse der logstash Installation beschränkt.
  • logstash leitet Logs nicht einfach stumpf weiter, sondern zerlegt sie in Felder, die dann in der Auswertung genutzt werden können. Damit fällt die Regexbastelei zum Küren des grössten Spamempfängers anhand der Sendmail Logs weg, denn eine Information wie die Empfängeradresse kann schon beim Verarbeiten der Logs als eigenes Feld ausgewiesen werden, nach dem dann gefiltert oder mit dem dann Berechnungen angestellt werden können.

Jetzt aber wie versprochen die Kurzanleitung:

logstash wird als .jar File zum Download angeboten, das auch gleich ein paar andere der benötigten Tools in embedded Versionen enthält. Den Download findet man prominent unter http://logstash.net/ . Ausserdem muss Java installiert sein. logstash ist ziemlich unempfindlich, welche Java Version eingesetzt wird. In Tests hat OpenJDK-7 hervorragend funktioniert.

Als nächstes wird eine einfache Konfigurationsdatei namens logstash-quickstart.conf angelegt:

input {
  stdin {
    type => "stdinput"
  }
  file {
    path => "/var/log/messages"
    type => "syslog"
  }
}
output {
  stdout {
    codec => rubydebug
  }
  elasticsearch {
    embedded => true
  }
}

Dieses Beispiel muss mit einem User gestartet werden, der Leserechte auf /var/log/messages hat. Wer das nicht für einen Test möchte, kann den file Part einfach weglassen. Dieses Konfigfile lässt logstash Events aus /var/log/messages sowie von stdin annehmen und gibt sie auf stdout aus, speichert sie aber auch gleichzeitig in die im .jar File mitgebrachte Elasticsearch Instanz.

Gestartet wird logstash mit

java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web

Dann passiert erstmal nicht viel. Nach ein paar Sekunden erhält man eine Warnung, dass verwendete Plugins noch nicht als stabil gekennzeichnet sind, die man für einen Test einfach mal ignorieren kann. Dann wartet logstash auf neue Logmeldungen. Falls nicht zufällig eine neue Nachricht in /var/log/messages geschrieben wird, kann man auch einfach eine Testnachricht abschicken, die dann logstash durchläuft und aufgeschlüsselt wieder ausgegeben wird. Ohne weitere Konfiguration wird aber natürlich nicht viel aufgeschlüsselt, sondern die gesamte Nachricht im message Feld wieder ausgegeben. Ein paar zusätzliche Felder fügt logstash automatisch hinzu und der type wurde ebenfalls über die Konfiguration gesetzt.

[root@fenris ~]# java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web
Using milestone 2 input plugin 'file'. This plugin should be stable, but if you see strange behavior, please let us know! For more information on plugin milestones, see http://logstash.net/docs/1.3.3/plugin-milestones {:level=>:warn}
hello world
{
       "message" => "hello world",
      "@version" => "1",
    "@timestamp" => "2014-01-23T12:06:27.895Z",
          "type" => "stdinput",
          "host" => "fenris.int.netways.de"
}

“hello world” ist die eingetippte Testnachricht.

Um logstash zu beenden, kann Ctrl+C gedrückt werden. Aber zuvor lohnt sich ein Blick auf http://localhost:9292/index.html#/dashboard/file/logstash.json . Woah! Das ist Kibana. Das mitgelieferte Webinterface zur Analyse der gespeicherten Events.schulung_logstash

Und jetzt kommt der Clou: Die logstash Installation ist voll funktionsfähig und die gesammelten Events bleiben auch gespeichert, wenn man logstash beendet und später wieder neu startet. Ab hier geht es “nur” mehr darum, die Daten in mehr und brauchbare Felder zu zerlegen, sie von mehr Quellen zu sammeln, sie zwischen Hosts mit logstash Instanzen weiterzuleiten und die beteiligten Systeme zu tunen und zu skalieren. Dazu wird es Sinn machen, die embedded Versionen von Elasticsearch und Kibana als eigenständige Instanzen ausserhalb des .jar Files zu installieren und es um weitere Tools wie Redis zu ergänzen.

Wer jetzt schon überzeugt ist, dass logstash eine feine Sache ist, findet sich sicher etwas bei unseren logstash Starterpaketen oder logstash Schulungen . Wer nicht, hat noch ein paar Folgen dieser Blogserie Zeit, sich überzeugen zu lassen.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Backup Quick 'n Dirty

Backuptools sind komplex und aufwändig. Das ist so und das wird sich auch so schnell nicht ändern. Wer sich auf sein Backup verlassen will, muss einfach Zeit, Aufwand und/oder Geld investieren. Was aber tun, wenn man keine hohe Sicherheit braucht, aber unter Umständen auf alte Stände des Systems / der Konfiguration zugreifen will? Weil vielleicht ein ausgefeiltes Backuptool vorhanden ist, aber ein Restore sehr umständlich wäre und man einen Abkürzung braucht? Geht sie – super! Geht sie nicht, gibt’s immer noch das eigentliche Backup.
Eine Möglichkeit wären vcs Systeme wie Git, aber auch die sind selten trivial in ihrer Bedienung – ausserdem müssen sie normalerweise dazu gebracht werden, einen aktuellen Stand eines Systems / einer Konfiguration zu sichern und das vergisst man leicht bzw. kann man es evtl nicht allen Usern zumuten. Ganz zu schweigen davon, dass man ja auch mal etwas sichern möchte, ohne, dass man dabei “anwesend” ist. Und nicht zuletzt sind vcs Systeme dafür gedacht, Textdateien wie Quellcode und Config zu sichern und nicht ganze Server.
Eine mögliche Lösung sind Tools wie Rsnapshot. Backup, das leicht zu bedienen ist, aber, oder weil es, auf viele Features verzichtet.
Rsnapshot ist sehr schnell eingerichtet und braucht beinahe keine Ressourcen.
Die Installation funktioniert in aller Regel über den Paketmanager der ausgewählten Distribution und die Konfiguration ist ziemlich selbst erklärend mit einigen Kommentaren in der Beispielkonfig, weshalb ich hier nicht weiter darauf eingehen möchte. Bedarf kann gern in den Kommentaren angemeldet werden, dann reiche ich gern einen Artikel dazu nach.
Kurz zusammengefasst erstellt das Tool eine Kopie des Dateisystems mit rsync und erstellt Kopien dieser Kopie mit Hilfe von Hardlinks. Dadurch benötigen nur die Dateien, die sich seit dem letzten Lauf geändert haben, tatsächlich Platz auf der Festplatte. Ein Restore funktioniert dann einfach via cp oder ähnlichen Bordmitteln. Aber bitte nicht mv, da dies die interne Struktur der Backups durcheinanderbringen kann.
Ein paar mehr Details sind für das weitere Verständnis allerdings noch hilfreich: rsnapshot kennt verschiedene Intervalle, die in der Konfiguration sortiert sind und immer vom Kürzesten zum Längsten genannt werden. Dabei ist es völlig unerheblich, wie die Intervalle benannt werden, wichtig ist, nur dass die Reihung kürzer -> länger immer eingehalten wird. Der Einfachheit halber hat es sich eingebürgert, sie nach Zeitspannen zu bennnen und sie ihrem Namen entsprechend auszuführen, also hourly stündlich, daily, täglich, etc. . Im Sinne einer einfacheren Lesbarkeit werde ich davon ausgehen, dass es genauso umgesetzt wird – ich bitte also um Verständnis, wenn ich “stündliches Backup” und nicht “am häufigsten ausgeführte Backupkonfiguration” schreibe. Ausserdem gehe ich davon aus, dass 24 hourly, 7 daily, 4 weekly, 12 monthly und 10 yearly aufgehoben werden sollen. Genauso gut könnte ich 6 hourly, 17 daily und 8 quonko aufheben, aber das wird jetzt schon klar sein.
rsnapshot wird nach der Konfiguration via cron aufgerufen und zwar immer in der Art rsnapshot [intervallname], wobei eben hourly stündlich, daily täglich, etc. ausgeführt wird. Anders ausgedrückt muss für jeden Intervall ein eigener Job eingerichtet werden.
Im internen Ablauf passiert bei jedem Dtündlichen ein rsync, das die zu sichernden Verzeichnisse nach hourly.0 unter dem angegbenen Zielpfad kopiert (hourly entspricht wieder dem frei wählbaren Intervallnamen). Ausserdem wird hourly.23 (wegen dem Beginn bei 0 gibt es natürlich kein hourly.24) gelöscht, hourly.22 via mv in hourly.23 umbenannt, hourly.21 in hourly.22, etc. Das passiert noch vor dem Ausführen des rsync, weshalb bereits davor kein hourly.1 mehr existiert. hourly.0 wird mithilfe von Hardlinks nach hourly.1 kopiert – erst dann findet der zuvor genannte rsync statt.
Bei einem Lauf mit rsnapshot daily wird daily.6 gelöscht, daily.5 in daily.6 umbenannt, etc. . hourly.23 wird in daily.0 umbenannt. Existiert zu diesem Zeitpunkt kein hourly.23, gibt’s auch kein neues daily. Das bedeuet auch, dass erst daily erstellt werden, wenn alle hourly existieren. Das gilt es zu bedenken, wenn man z.B. 96 hourly behalten will. Ausserdem ist somit jedes daily älter als jedes hourly, jedes weekly älter als jedes daily, etc. In der angenommenen Konfiguration könnten wir also alleine durch hourly und daily 8 Tage zurück.
Wirklich hilfreich werden tools wie rsnapshot aber erst, wenn man etwas länger daran herumspielt. Ein Problem ist zum Beispiel, dass bei jedem Lauf alle bereits erstellten Backups umbenannt werden. Sucht man ein bestimmtes Backup, so muss man ausrechnen, wie es aktuell heisst und hoffen, dass alle Sicherungen nur via cron angestossen wurden. Eine mögliche Abhilfe ist, sich einen Ordner anzulegen, in dem man Dateien hinterlegt, die nur für die Dauer eines Backuplaufs existieren und das Backup identifizeren. z.B /root/snap/mysql_coldbackup . Nach der Datei kann man dann den Zielordner durchsuchen (aber bitte nicht mit locate, sondern mit etwas, das den aktuellen Zustand des Filesystems überprüft 🙂 ). Man kann das auch automatisieren, in dem man durch cron unmittelbar vor jedem backup einen timestamp dort hinterlegen lässt. Es ist auch denkbar, gewisse Zustände so zu verewigen. z.B Softwareversionsstände im Laufe einer Migration (geht ebenfalls automatisiert, vor allem da die meisten tools beim Aufruf mit -V ihre aktuelle Versionsnummer ausgeben.) oder noch ausstehende Schritte. So habe ich mir angewohnt, vor grösseren Schritten, erst touch /root/snap/[namedesgroesserenschrittes] ; rsnapshot hourly && rm -f /root/snap/[namedesgroesserenschrittes] auszuführen. So kann ich, wenn was schief geht, leicht auf alte Konfig zugreifen, kann das aber durchaus öfter machen, da diese Backups durch die stündliche Rotation wieder rausfallen. Evtl. geht eines davon auf die Reise durch die weiteren Intervalle, aber das stört mich nicht weiter.
Dabei muss man natürlich bedenken, wie lange man die Backups aufheben möchte. Da rsnapshot die einzelnen Intervalle unabhängig voneinander rotiert, passiert es leicht, dass ein Zustand, der nur in einer einzigen Sicherung vorhanden ist, bei der stündlichen Rotation rausfällt. Möchte man, dass gewisse Dateien länger im Backup bleiben, gibt es leider keine Garantie dafür. Wenn alles glatt geht, sollte das Aufheben aber funktionieren, wenn man die Datei einen Intervall des Backupzyklus lang verfügbar macht, für das man es aufhält. Ist eine Datei also eine Woche lang auf dem Filesystem zu finden, hat man gute Chancen, sie in allen hourly, allen daily und mindestens einem weekly zu finden, bis die Rotation sie aus dem letzten weekly wirft. In unserem Beispiel also 5 Wochen und 1 Tag lang. Gefährdet wird diese Logik vor allem, wenn man ausgiebig Gebrauch von den oben erwähnten “händischen Backups” macht. Damit erhöht sich die Zeit, die ein Status bestehen muss, um ins daily überzugehen natürlich entsprechend.
Die yearly backups scheinen in den meisten Fällen überzogen, aber das ist aus meiner Sicht der beste Weg, einen Zustand dauerhaft zu bewahren. Dazu ein Beispiel aus der Praxis. Bevor ich eine grössere Migration beginne, in deren Rahmen ich rsnapshot einführe, lege ich die Konfiguration an und lasse, dem obigen Beispiel folgend, 24+7+4+12+10 mal folgenden Befehl laufen: rsnapshot hourly ; rsnapshot daily ; rsnapshot weekly ; rsnapshot monthly ; rsnapshot yearly. Das dauert nicht sehr lange und braucht nur minimal mehr Platz als eine einzige Kopie des zu sichernden Filesystems. Ab da beginne ich die normalen cron Läufe mit hourly stündlich, daily täglich… . So kann ich davon ausgehen, dass für die ganze Dauer der Migration und auch jedes spätere Mal, wenn ich zu diesem Kunden komme, die ursprüngliche Ausgangssituation im letzten yearly noch vorhanden ist.
Noch ein paar Worte der Warnung. Als Ziel wird rsnapshot ein Verzeichnis angegeben. Wenn dort ein anderes Filesystem, z.B. von einer USB Festplatte, gemountet ist und man diese entfernt, legt rsnapshot einfach in dieses Verzeichnis neue Backups an, womit man sich ganz schnell Festplatten anfüllen kann. Dieses Verhalten ist allerdings konfigurierbar. Falls das reguläre Backuptool das rsnapshot Zielverzeichnis inkludiert und nicht mit Hardlinks umgehen kann, wird man bald einen Backupadmin mit einer roten Kletzn (österr. für “Kopf”) im Büro stehen haben, weil man bei der obigen Konfig 24+7+4+12+10+1 mal den gesamten Platz des zu sichernden Filesystems wegkopiert. Das selbe gilt bei Netzwerkshares, etc. auf die man hinschreibt, sofern die nicht mit Hardlinks umgehen können. Aus dem gleichen Grund kann man auch nicht einfach via ssh oder ähnliches auf einen entfernten Server sichern. Um das hinzubekommen, muss man via rsync auf den Zielhost sichern und dort dann rsnapshot laufen lassen. Wer auf andere Hosts sichern, selbst auf dem selben Host die Backupkonfiguration verwalten und Backups auch noch verschlüsseln will, sollte sich evtl. duplicity und die vielen kleinen Tools, die einem das Leben damit deutlich einfacher machen, wie duply oder deja-dup ansehen. Eine Stolperfalle, in die man immer wieder gerne tappt, ist das Konfigfile, das Optionsname und Wert immer mit Tabulator getrennt verlangt und bei Zeilen, die Leerzeilen statt Tabs enthalten, Fehler wirft. Daher bietet es sich immer an, einen rsnapshot hourly Lauf nach Konfigänderungen zu machen.
Nicht zuletzt sollte man immer daran denken, Restores nur mit Kopien zu machen, da man Daten tatsächlich aus den Backups rausnehmen kann und so unter Umständen alle Kopien vernichtet. Umgekehrt muss man Backupsets, die man aus der Rotation entfernt (Pfade, die nicht mehr gesichert werden oder wenn man z.B. von 48 hourly auf 24 hourly umstellt) selbst löschen. Das nimmt einem rsnapshot nicht ab.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Backporting – Quick and a bit dirty

Oftmals steht man vor der Problematik, dass man auf seinem Produktivsystem eine aktuellere Version von einem Programm benötigt als sie bereits im Repository der stabilen Ausgabe von Debian vorhanden ist. Für solche Problemfälle gibt es das Backports-Projekt, indem aber natürlich auch nicht alle Pakete enthalten sind, da nur selektiv einzelne Pakete aus dem neuen “testing”-Zweig von Debian gegen ein Stable-Environment gebaut werden.
Häufig werden dann die benötigten Programme in aktueller Version selbst übersetzt und somit aus der Paketverwaltung ausgekoppelt, was das Einspielen von Updates erschwert.
Der direktere Weg ist selbst sich Pakete zu backporten. Dies hat folgende Vorteile:

  • Integration in die Paketverwaltung (Vereinfachung beim Einspielen von Updates oder einem Upgrade)
  • durch die Maintainer an das Debian-System angepasst
  • einfache Weitergabe und Verteilung auf mehreren Systemen

Grundlage bietet zunächst eine chroot-Umgebung, damit das System, auf dem Gearbeitet wird nicht “zugemüllt” wird durch diverse dev-Pakete. Das Anlegen eines chroots ist recht einfach und geschieht mit debootstrap (muss als root ausgeführt werden)

root@localhost:~# mkdir chroot_squeeze
root@localhost:~# debootstrap squeeze chroot_squeeze/ http://ftp.de.debian.org/debian
I: Retrieving Release
I: Retrieving Packages
....

Wenn debootstrap die Umgebung gebaut hat, kann mit chroot chroot_squeeze/ /bin/bash in das chroot gewechselt und ohne Gefahr gearbeitet werden. Weiterer großer Vorteil ist, dass wenn was schief geht und das System “zerschossen” wird, man den chroot-Ordner einfach löscht und neu anlegt.
In der chroot-Umgebung sollten zunächst die /etc/apt/sources.list angepasst und um die Source-Quellen erweitert werden. Empfehlenswert ist es zunächst ersteinmal komplett den stable-Zweig von Debian zu verwenden, um die Build-Dependencies von den Stable-Paketen zu installieren. Hintergrund ist, dass so schon einmal der Großteil der benötigten Pakete installiert wird und später schneller und gezielter die fehlenden Abhängigkeiten aufgelöst werden können.

root@localhost:~# chroot chroot_squeeze/ /bin/bash
root@localhost:/# cd ~
root@localhost:~# mkdir icinga ; cd icinga
root@localhost:~/icinga# apt-get build-dep icinga
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
....

Bei diesem Durchlauf sollten keine Fehler bzgl. Abhängigkeiten auftreten. Anschließend kann der Source-Eintrag in der /etc/apt/sources.list auf testing, unstable oder experimental geändert werden, je nachdem aus welcher Quelle man ein Paket benötigt. Anschließend erneut apt-get build-dep ausführen. Wenn hier Abhängigkeitsprobleme auftreten muss versucht werden diese Aufzulösen. In einigen Fällen kann es bedeuten, dass man zunächst andere Pakete backporten muss, damit die Abhängigkeiten der neuen Version stimmen. In unserem Beispiel von Icinga ist das jedoch nicht der Fall.
Es werden nun die Quellen mittels apt-get source icinga geholt und im Anschluss die Version mittels dch -v angepasst. Hierbei sollte man die Versionierung nehmen, wie sie auch beim Backports.org Projekt genutzt wird (paketname-1.0.2-2~xyz60+1 – genaueres ist aus backports.org zu entnehmen).

root@localhost:~/icinga# vi /etc/apt/sources.list
root@localhost:~/icinga# apt-get update
root@localhost:~/icinga# apt-get build-dep icinga
...
root@localhost:~/icinga# apt-get install devscripts #hier ist dch enthalten
root@localhost:~/icinga# cd icinga-1.4.1
root@localhost:~/icinga/icinga-1.4.1# dch --bpo

Nun öffnet sich ein Editor, der einem gleich die changelog Datei anbietet. Hier sollten noch Name und Email-Adresse angepasst werden und ggf. noch die Distribution (squeeze-backports, squeeze-backports-netways ..)
Nach dem Speichern kann das Paket mittels dpkg-buildpackage gebaut werden. Es kann sein, dass hier ebenfalls noch einmal Abhängigkeiten bemängelt werden, die man anschließend versuchen müsste aufzulösen, was jedoch aktuell und in unserem Beispiel nicht der Fall sein sollte.

root@localhost:~/icinga/icinga-1.4.1# dpkg-buildpackage
dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CPPFLAGS auf Standardwert:
dpkg-buildpackage: setze LDFLAGS auf Standardwert:
...

Ist der Build-Prozess erfolgreich durchgelaufen, liegen im übergeordneten Ordner die fertigen Debian-Pakete inklusive Quellpakete, welche dann in ein eigenes Repository hochgeladen werden können (bspw reprepro).
Ich möchte noch einmal darauf hinweisen, dass es unter unglücklichen Umständen (sehr große Versionssprünge und Abhängigkeitsprobleme) eine etwas umfangreicheres Unterfangen sein kann, ein Paket zurückzuportieren. Jedoch erntet man dafür die Vorteile und kann seine Ergebnisse mit anderen teilen.