Grok Debugger

So kurz vor dem Wochenende möchte ich euch eine Webseite vorstellen die mir schon einige Tage Lebenszeit gespart hat: Der Grok Debugger!

Da ich immer wieder mit erstaunen feststellen muss das nur sehr wenige diese Seite kennen, sei sie hiermit auf unserem Blog verewigt 🙂

Solltet ihr nicht wissen welche tollen Sachen man mit Grok anstellen kann müsst ihr unbedingt mal in unserem Elastic Stack Training vorbei schauen 😉

 

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.

kostenfreie TLS-Zertifikate mit Let’s Encrypt

Let’s Encrypt hat seit gut einem Jahr die Testphase verlassen und verteilt fleißig Zertifikate – kostenfrei versteht sich. Wo anfangs in der Testphase “nur” wenige Millionen Zertifikate ausgegeben wurden, ist diese Zahl inzwischen kräftig gewachsen – Tendenz steigend. WordPress und andere Dienste setzen Let’s Encrypt in breitem Maße ein um das Internet ein bisschen besser (sicherer) zu machen.

Neben der reinen Absicherung der Verbindung hilft ein Zertifikat noch beim Ranking und dem lästigen Wegklicken von Sicherheitswarnungen bei selbstsignierten Zertifikaten, beispielsweise bei Testumgebungen. Chrome bemängelt seit der Version 39 auch die Sicherheit von normalen HTTP-Verbindungen und kennzeichnet diese als “nicht sicher”.

Die Zertifikate von Let’s Encrypt sind nicht besser oder schlechter als andere Zertifikate – nur kosten sie nichts und sind nicht so lange gültig – durch Automatismen zur Erneuerung eher ein Vorteil als ein Nachteil. Bei Let’s Encrypt gibt es keine Wildcard- oder EV-Zertifikate, wenn der Wunsch nach diesen besteht, greift man lieber zu kommerziellen Produkten. Auch wenn die Validierung mehr Sicherheiten bringen soll, als eine Domain-Validierung (hier wird ein Hash in einem vhost hinterlegt und von Let’s Encrypt geprüft), wird einem ein kommerzielles Produkt nahe gelegt.

Also eignen sich die Zertifikate für folgende Anwendungsfälle: Basisabsicherung von Diensten, wo sonst keine Verschlüsselung unbedingt notwendig wäre (z. B. WordPress-Blog), Absicherung von Staging-Systemen, Absicherung als kostenfreie Zugabe des Hosters, Absicherung von internen Diensten und zur Absicherung von privaten Websiten.

Aber wie kommt man nun zu den Zertifikaten?

Hier gibt es verschiedene Wege, allerdings gehe ich nur kurz auf die Command-Line basierte Beantragung ein. Dafür wird von Let’s Encrypt selbst der Certbot empfohlen, der bringt alles mit.

Nach dem Download / der Installation des Certbots (hier kommt es auf die Distribution an) kann dieser mittels dem einfachen Aufrufs

./certbot-auto

starten. Jetzt werden die weiteren Abhängigkeiten noch aus dem jeweiligen Paketmanager nachinstalliert. Ein Wizard startet und fragt welche Domains abgesichert werden sollen und ob ein automatischer (sicherer) redirect von HTTP auf HTTPS erfolgen soll (Hierzu werden Rewrite-Rules in der VHost-Config angelegt). Der Rest geht von alleine, eine CSR wird erstellt, ein vhost für die Domain-Validierung wird angelegt, es wird von extern gecheckt, ob der String im vhost erreichbar ist, Zertifikat wird ausgeteilt und gleich eingerichtet.

Achtung, nachdem der Wizard angestoßen wurde, wird mehrfach der Webserver neugestartet und Configfiles verändert. Für eine alternative Beantragung mit mehr Eigenverantwortung bitte die Hinweise zu certonly und webroot lesen.

Zertifikat nur 90 Tage gültig – was tun?

Die TLS-Zertifikate von Let’s Encrypt sind nur 90 Tage gültig. Die Beweggründe hierfür sind unterschiedlich. Aber aus meiner Sicht ist dies ein wesentlicher Sicherheitsvorteil. Damit es zu keinen Zertifikatsfehlern kommt, heißt es hier im richtigen Moment die Erneuerung der Zertifikate anzustoßen. Denn ein neues Zertifikat bekommt man erst kurz vor Ablauf des alten Zertifikates. An dieser Stelle komme ich an die vormals angesprochenen Automatismen zurück. So reicht es eigentlich täglich 1-2x einen Cron laufen zu lassen:

./certbot-auto renew

Durch dieses Kommando schaut der Certbot beim jeweiligen Lauf des Crons, ob das Zertifikat in Kürze abläuft. Wenn ja, wird ein neues Zertifikat beantragt und hinterlegt, wenn nicht meldet sich der Certbot nur mit einer kurzen Meldung im Log:

INFO:certbot.renewal:Cert not yet due for renewal

Auch hier sicherheitshalber nochmal der Hinweis, dass alle Abhängigkeiten beim renew aktualisiert werden (zu vermeiden mit dem –no-self-upgrade Flag). Desweiteren wird auch wieder ein vhost angelegt und der Webserver-Dienst durchgestartet.

Auch unsere Kunden mit komplexen Setups hinter Loadbalancern und HA-Clustern können von Let’s Encrypt profitieren – wir bauen hierzu die passende Lösung.

Freuen wir uns auf die nächsten Jahre, der wichtigste Schritt wurde bereits gemacht. Wer bei uns Kunde ist, kann schon heute von diesem tollen Service profitieren.

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.

Platz da LConf, der Director kommt!

Lange Zeit war das von NETWAYS entwickelte Tool LConf das Mittel der Wahl wenn ein grafisches Konfigurationsfrontend für Icinga gesucht wurde. Mit Icinga 2 und dem damit einhergehenden geänderten Konfigurationsformat litt jedoch die Kompatibilität, außerdem ist das ursprüngliche Konzept von LConf mit der Zuweisung von Services über Vererbungen eines OpenLDAP-Baumes spätestens mit den vielen Möglichkeiten der Apply Rules von Icinga 2 überholt.

Als eigenes Modul in Icinga Web 2 integriert, ist der Director das einzige Konfigurationstool das eine vollständige Unterstützung für Icinga 2 bietet. Die Kommunikation erfolgt dabei direkt mit der API des Icinga 2 Cores (seit Icinga 2.4). Daher stellt sich also die Frage: Wie lässt sich die Icinga Konfiguration von LConf am Besten auf den Director, respektive von Icinga 1.x auf Icinga 2.x migrieren?

Icinga Web 2 bietet bereits nativ eine Unterstützung für LDAP, diese steht auch den Modulen zur Verfügung. Um LConf nun als Import Source im Director zu verwenden, muss dafür in Web 2 noch eine entsprechende Resource eingerichtet werden.

Host in LConf

Bei der Import Source reicht es dann i.d.R. aus die Objektklasse auf lconfHost einzuschränken, denn mehr als nur Hosts zu importieren, macht in den wenigsten Fällen sind. Services sollten aufgrund von CheckCommands aus der Icinga Template Library (= ITL) sowieso neu gemacht und in dem Zuge auch gleich überdacht werden. Durch die Apply Rules liegt der Fokus auf Host Eigenschaften anhand deren später Services zugewiesen werden können. Neben Standardattributen stehen hier auch sog. Custom Attribute oder Custom Variablen (CustomVars) zur Verfügung, mit denen weitere individuelle Informationen wie beispielsweise Betriebssystem, Rolle oder Standort hinterlegt werden können.

Normalerweise ist es bei Hosts ausreichend cn, lconfAddress, lconfAlias und lconfHostCustomvar zu importieren. Da CustomVars in LConf mit Unterstrich vorm Bezeichner und einem Leerzeichen vor dem eigentlichen Wert angegeben werden müssen, sieht das in der Vorschau der Import Source beispielhaft so aus:

[

“_operatingsystem Linux”,

“_role Webserver”,

“_rack Rack01”

]

Diese Syntax kann vom Director nur schwer weiter verarbeitet werden, daher gibt es dort seit kurzem den Modifier “Transform LConf CustomVars to Hash“, mit dem das Ganze wie folgt transformiert wird:

{

operatingsystem: “Linux”,

rack: “Rack01”,

role: “Webserver”

}

Host im Director

Bei der darauf aufbauenden Sync Rule können dann alle CustomVars mit “All custom variables (vars)” automatisch umgesetzt werden, dabei spielt es keine Rolle ob die Hosts eine, keine oder mehrere Custom Attribute definiert haben.

Damit ist es sehr einfach die Hosts aus dem bestehenden LConf-Baum bereits im Produktivbetrieb schon auf die künftige Verwendung mit Icinga 2 vorzubereiten und sie dann mit dem Director einmalig oder regelmäßig zu importieren, sodass zumindest ein paar Andenken an den “geliebten” LConf bleiben…

Wer hier oder auch bei anderen Aufgaben mit Icinga und dem Director noch Unterstützung benötigt, kann aber natürlich auch gerne auf uns zukommen.

Markus WaldmĂŒller

Autor: Markus WaldmĂŒller

Markus war bereits mehrere Jahre als Systemadministrator in Neumarkt i.d.OPf. und Regensburg tÀtig. Nach Technikerschule und SelbstÀndigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. In seiner Freizeit ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Icinga 2 – Multi-Zonen Notifications

Komplexe Monitoring Umgebungen mit Icinga 2 kennt man ja schon und auch was sich alles mit den Satelliten und zus. Zonen-Mastern anstellen lässt. Aber wisst ihr auch, dass sich gezielte Benachrichtigungen für einzelne Zonen definieren lassen? Die meisten nutzen wahrscheinlich schlicht nur die Haupt/Master Zone für Notifications; aber gehen wir doch von einem nicht unüblichen Beispiel aus : Der externen Überwachung des eigenen Monitorings.

Wir wollen, dass der externer Satellit uns autark kontaktiert sobald das Monitoring ausfällt und im Sinne des Directors, ebenso wenig eine manuell Konfiguration pflegen. Jetzt muss er die Benachrichtigung nur irgend wie zu uns bekommen. Das Wissen über die Objekte sollte bei solchen Setups vorhanden sein, daher werde ich keine Screens oder Config-Auszüge einfügen, sondern nur das Vorgehen beschreiben.

Wie einfach das Ganze mit Zonen-Verzeichnissen und einem Parameter realisiert werden kann, zeigt sich wie folgt. Wir generieren das entsprechende Notification-Command für den Satelliten und stellen sicher, das er es, sowie die betreffenden Kontakte, in seiner Zone finden kann. Anschließend folgt auch schon das Notification Objekt, welches a.) einfach mit in das Zonen-Verzeichnis des Satelliten geschoben, oder b.) global um den Parameter “zone” erweitert wird. Und schon kann es los gehen.

All das lässt sich übrigens auch wunderbar in einem NWS Satelliten abbilden. Probiert es einfach mal aus.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem ĂŒblichen Admin-Cliche, gehört Fitness zu einer seiner LieblingsfreizeitbeschĂ€ftigung.

Netways auf der Elastic{ON}17

Wie letztes Jahr hatten einige von uns die grossartige Gelegenheit, die Elastic{ON} in San Francisco besuchen. Dort stellt Elastic sämtliche kommenden Neuerungen am Elastic Stack vor. Daneben haben auch einige Kunden und Partner die Möglichkeit, ihre Use-cases oder Services zu präsentieren sowie ihr eigenes Setup und dessen Herausforderungen zu zeigen.

Die Neuigkeiten im Stack zeigen vor allem drei Schwerpunkte: Graphische Bedienung, mehr Visualisierungen in Kibana und noch mehr Stabilität. So sind eine graphische Aufbereitung und wohl auch eine teilweise graphische Konfiguration von Logstash Pipelines via Kibana geplant.

In Kibana selbst tut sich sehr viel. Da kommen neue Visualisierungen, insb. für Geolocation und ein “Visualisation Builder”, mit dem man deutlich ausgefallenere Graphen als bisher erstellen kann. In einer one-on-one Test Session konnte ich dieses Feature schon mal bestaunen, bin aber, ehrlich gesagt, etwas an der Komplexität und der ungewohnten Bedienung gescheitert. Entweder hat da noch der Jet-Lag zugeschlagen oder Elastic sollte noch etwas an der Bedienung feilen, die ja sonst doch sehr eingängig ist.

An der Stabilität wird insbesondere bei Elasticsearch gearbeitet. Dabei ist wohl eine Art “Transaction Log” geplant, das endlich schnelle Neustarts von Clusterknoten ohne vorherigen “Flushed Sync” ermöglicht und auch sonst sehr zur Stabilität beitragen soll.

Es wäre nicht Elastic, wenn nicht auch eine Menge Livedemos vorgeführt werden würden, was wir sehr schätzen, da sie doch auch einen wirklich sehr konkreten Nutzen für die Teilnehmer haben. Da heben sich die Elastic Mitarbeiter wirklich von vielen anderen Sprechern auf, insbesondere amerikanischen, Konferenzen positiv ab. Eine besonders beeindruckende Demo war der Auftakt der Konferenz mit einer Tänzerin, deren Bewegungen und Herzschlag live in Kibana visualisiert wurden. Das schien tatsächlich live zu sein, da Kibana durchaus auch mal den ambivalenten Smiley zeigte, der angibt, dass aktuell keine Datensätze gefunden wurden.

Es ist noch etwas zu früh, um alle Änderungen sichten und bewerten zu können, aber es sieht jedenfalls so aus, als hätte Elastic etliches in petto, das uns als Elastic Stack Usern das Leben deutlich einfacher und vor allem bunter machen würde. Wie immer schwebt das Damoklesschwert “kommt dieses Feature in X-Pack oder bleibt es frei” über jeder angekündigten Neuerung, aber das scheint teilweise noch gar nicht entschieden zu sein. Ziemlich sicher wird “Machine Learning” ein Kibana Feature, das aus “Prelert” entstanden ist, nur für Nutzer von X-Pack erhältlich sein. Ob “Canvas”, ein Feature, mit dem Reports und Präsentationen aus Kibana heraus erstellt werden können, frei verfügbar sein wird, wird noch entschieden. Auf jeden Fall würde das vielen Usern sehr weiterhelfen, nach dem, was wir an Nachfragen erhalten.

Viele der Features wurden für “kommende Releases” angekündigt. Einige davon kommen in 5.3, andere erst in 6.0.

Auf jeden Fall war die Konferenz wieder die Reise wert und ich kann es kaum erwarten, mit den neuen Features zu experimentieren und sie umzusetzen.

Ganz abgesehen von der Konferenz ist San Francisco natürlich auch für sich genommen eine wunderbare Stadt und wir alle sind sehr froh, dass die Reise so gefallen ist, dass wir uns auch noch etwas die Stadt ansehen konnten.

Wer noch keinen Kontakt zum Elastic Stack hatte, sollte sich einmal unsere Schulungen zum Thema ansehen. Die kurz und knackig und bieten alles, was man für einen Start in die Welt des Logmanagement braucht.

Dass der Blogpost etwas später als gewohnt erscheint liegt an der Zeitverschiebung und dem einen oder anderen wunderbaren IPA, das es hier zu probieren gab.

Die Talks gibt es sicherlich demnächst im Archiv nachzusehen.

Thomas Widhalm

Autor: Thomas Widhalm

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 Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool.

Der Icinga Buildserver, Version 3

Letztes verbliebene Bild des alten Icinga Jenkins

Der Icinga-Buildserver, erreichbar unter https://build.icinga.com, läuft in dieser Form jetzt etwa ein Jahr. Doch gibt es noch immer ein paar Probleme die mit diesem Setup bestehen: So ist das Hinzufügen neuer Jobs noch etwas umständlich, das provisionieren dauert länger als uns lieb ist und besonders übersichtlich ist die Konfiguration auch nicht. Um diese Probleme anzugehen haben wir uns noch einmal mit Puppet und Jenkins auseinandergesetzt.

Wie vorher verwenden wir ein jenkins puppet-modul, nur diesmal haben wir es mit einem speziellen icinga-jenkins Modul erweitert. Dieses Modul erlaubt es uns spezielle pipeline-jobs mit geringem Konfigurationsaufwand zu erstellen. So ist das unterstehende Beispiel alles was zu konfigurieren ist um eine komplette Pipeline zu erstellen. Selbst der spezielle Umgang mir RPM und Deb ist zu großen Teilen vereinheitlicht und funktioniert für alle Projekte gleich.

icinga_build::pipeline:
  icinga2-snapshot:
    control_repo: https://github.com/Icinga/icinga-packaging.git
    control_branch: snapshot
    matrix_deb:
      'debian-jessie': {}

Die Pipeline erstellt dabei nicht nur einen, sondern gleich vier Jobs: “source”, “binary”, “test” und “publish”. Diese verarbeiten die specfiles, bauen das Paket, testen es und veröffentlichen es auf https://packages.icinga.com

In Produktion ist unser Modul noch nicht, aber um den testen und konfigurieren zu können haben wir Vagrant Boxen gebaut. Mit Hilfe derer bauen wir zur Zeit das icinga-jenkins Modul weiter aus um den bestehenden Buildserver komplett mit den neuen Pipelinejobs abbilden zu können. Wir hoffen unseren Buildprozess damit noch einfacher für Entwickler zu machen und dank der neuen Testsphase für Pakete Problemen in Zukunft besser vorzubeugen zu können

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 in seiner Ausbildung im Development gleich die kniffligsten Aufgaben vor.