NETWAYS Webinare – Jetzt mit OpenStack !

Wieder einmal mehr haben wir an unserem Webinar Kalender geschraubt – diesmal möchten wir euch etwas über OpenStack erzählen.

OpenStack: Infrastructure Hosting by NETWAYS
Dort wollen wir unsere neue OpenStack IaaS Plattform vorstellen und die Vorteile, welche sich hieraus ergeben. Dadurch gewähren wir unseren Kunden maximale Transparenz, Flexibilität und eigenes Management der IT-Umgebungen.

Als Termin ist der 17. Oktober 2018 um 10:30 Uhr angesetzt.
 

Die Anmeldung zum Webinar ist hier möglich.
Darüber hinaus möchte ich eine weitere Änderung in unserem Webinar Kalender ankündigen: Das Webinar Icinga 2: Monitoring für Windows musste leider verschoben werden und zwar auf den 05. Dezember 2018 um 10:30 Uhr. Eine Mitteilung an alle Teilnehmer ging heute morgen bereits raus.

Anbei gibt es hier einmal die aktuelle Webinar Liste im Überblick:

Selbstverständlich werden wieder alle Webinare aufgezeichnet und auf unserem YouTube Channel veröffentlicht.

Ich freue mich wie immer auf eine rege Teilnahme und die 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".

Ein paar vim tricks

Ich benutze in meiner täglichen Arbeit vim als Editor. Im Laufe der Zeit habe ich dabei ein paar Dinge gelernt, die mir das Leben einfacher machen. Ein paar dieser “Tricks” möchte ich euch heute einmal zeigen.

Autovervollständigung

Mit vim kann man seine Texte und Scripte autovervollständigen lassen. Das funktoniert mit normalen Wörtern, die schon einmal im Text vorgekommen sind STRG + n, mit ganzen Zeilen STRG + x + l oder mit Dateien und Ordnern im Filesystem.

Einfügen auf mehreren Zeilen

Es ist zwar nicht intuitiv, aber man kann relativ einfach viel Text auf einmal einfügen. Man kann entweder vor der Curserposition, z.B. am Anfang der Zeile, oder am Ende der Zeile Zusätzliche Zeichen hinzufügen.

In jedem Fall muss man erstmal mit STRG + v die Zeilen markieren, die bearbeitet werden sollen.
Das # am Anfang der Zeilen fügt man jetzt mit SHIFT + i (instert mode), gefolgt von #, gefolgt von ESC ein.
Der . am Ende der Zeilen funktioniert ähnlich. Aber statt SHIFT + i kommt $A zum Einsatz. Wieder gefolgt von dem Zeichen . und einem ESC.

History im vim

Lange zeit dachte ich, wenn ich zweimal dd benutze ist dar erste Inhalt weg. Genauso wie bei Word’s “auschneiden/einfügen”. Das ist allerdings nicht wahr. mit :reg kommt man in die History vom vim. Möchte man z.B. den dritten eintrag einfügen, geht das mit “3p.

json, jq und vim

In vergangen Blogposts wurde ja schon über die Macht von API, json und jq geschrieben. Das lässt sich wunderbar auch im vim kombinieren. Wenn ich mir Beispielsweise die Services einer icinga2 API ausgeben lasse, schaut das erstmal im vim recht unleserlich aus.

curl -k -u root:icinga 'https://127.0.0.1:5665/v1/objects/services' |vim -

Erst durch ein :%!jq ‘.results[].attrs | select(.active==true) | {__name, display_name, enable_perfdata}’ wird daraus etwas schönes.
Jetzt wird nur noch Name, display_name und enable_perfdata angezeigt. Und das nur von Services, die “active” sind.

Christoph Niemann

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Monthly Snap September – NETWAYS News | Tips & Tricks | DevOps | Conferences & Trainings

Hellooooo Huuumans!!! 🙂

Autumn is here & I came to think of the most famous GOT quote “Winter is coming!!“. Well, Let’s move back to the current season – “Autumn”. Did you also have the feeling, that this was a very quick month? #Vacayisover

What happened in the NETWAYS Shop?

The New of AKCP: Battery Temp Sensor (BTTS) Time to celebrate! Our NETWAYS MonitorSilke. The brand new software version 3.32 of SMS Eagle is here! Callback URL, Autoreply, SMS forwarding, and more. Silke shared her best autumn- tips: “Wir haben aufgeräumt und aufgestockt! Neues Gude Sortiment steht im Shop zur Verfügung” (We have lots of new products from Gude in our online shop!)

What are they up to now? #Developers

#Monitoring: everything is regulated. But!! What Thomas said???  Jennifer reports on DevOpsDays Berlin 2018,  “Warum ist das jetzt wichtig und was hat das mit IT zu tun?“ Weg mit dem Schrott: Müll im Weltraum – says Marius. (Store the garbage in space?).  Michael released GitLab training v2.3.0 which includes bug fixes and new features. He also updated the material and tagged v2.3.0 .  Aleksander (our new trainee) has got some news on “Ubuntu 18.04 LTS“. Michael told us about the days away with his fellow developers at the “Franconian Alps” #DEV Retreat 2018 Recap 

How do they do this all the time? #superactive | The most awaited conference is coming soon! #OSMC 

Julia claimed that the workshops are the best place to learn and get inspired. #OSMC workshops (FYI: Prometheus and Icinga 2 / Puppet workshops are sold out. Get your Graylog and Ansible workshops tickets quickly, before it`s too late!). Preparing for the OSMC? A perfect way to get in the mood for the OSMC 2018 is by watching the recap from 2017!  Julia wrote about a great opportunity at this- years` #OSMCGoing to the OSMC? Join the OSCAMP #Puppet! Check out the speakers and their talks“.

 

Stay tuned for many more upcoming NETWAYS voices!! 🙂
Keya Kher

Autor: Keya Kher

Keya hat im Oktober 2017 ihr Praktikum im Marketing bei NETWAYS gestartet. Seitdem lernt sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat viele Erfahrungen im Social Media Marketing und ist auf dem Weg, ein Grafikdesign-Profi zu werden. Wenn sie sich gerade nicht kreativ auslebt, entdeckt sie die Stadt oder schmökert im ein oder anderen Buch. Ihr Favorit ist “The Shiva Trilogy”.

Canonical schließt Lücken in Ubuntu 18.04 LTS

Common Vulnerabilities and Exposures (CVE) ist ein Industriestandard, dessen Ziel die Einführung einer einheitlichen Namenskonvention für Sicherheitslücken und andere Schwachstellen in Computersystemen ist. Mehrfachbenennung gleicher Gefahren durch verschiedene Unternehmen und Institutionen werden um eine laufende Nummer ergänzt, um eine eindeutige Identifizierung der Schwachstelle zu gewährleisten. Dadurch ist ein reibungsloser Informationsaustausch zwischen den verschiedenen Datenbanken einzelner Hersteller möglich.

Canonical hat ein neues Kernel-Update für Ubuntu 18.04 LTS veröffentlicht, indem Lücken, die im VirtIO-Subsystem und dem ACPI Kernel stecken, gepatcht werden. Eine Lücke in der Speicherinitialisierung (CVE-2018-1118) im VirtIO-Subsystem des Kernels, die nicht immer funktionierte, wurde entfernt. Hier konnte ein Angreifer über einen lokalen Zugriff vertrauliche Informationen erhalten. Die zweite Lücke betrifft das ACPI (Advanced Configuration and Power Interface) des Kernels wodurch auch ein lokaler Angriff Erfolg hätte.

Außerdem gab es mehrere Schwachstellen in der PHP-Komponente FPM und EXIF bei denen Angreifer auch lokal mit speziell präpariertem PHP-Skripten die Vorbereitung von verschiedenen DoS-Angriffen ausführen konnten. Später dann auch aus der Ferne steuerbar. Die Schwachstellen CVE-2018-14851 und CVE-2018-14883 lassen den Angreifer beliebigen Programmcode ausführen. CVE-2015-9253 lassen sich aus der Ferne für DoS-Angriffe auf geteilte PHP-Server ausführen.

Die Updates stehen seit längerem für Ubuntu 18.04 LTS, 16.04 LTS und 14.04 LTS bereit.

Aleksander Arsenovic

Autor: Aleksander Arsenovic

Aleksander macht eine Ausbildung zum Fachinformatiker für Systemintegration in unserem Professional Service. Wenn er nicht bei NETWAYS ist, schraubt er an seinem Desktop-PC rum und übertaktet seine Hardware. Er ist immer für eine gute Konversation zu haben.

Icinga2 GitLab Health Check

GitLab

Neulich hatten wir bei einigen GitLab Updates auf die neueste Version das Problem, dass die Dienste nach dem Update zwar korrekt alle wieder gestartet wurden und daher unser alter Monitoring Check “Service: gitlab” den Status “Gitlab OK: All services are running!” zurückgeliefert hat, auch der Check “Service: http git.netways.de” “HTTP OK: HTTP/1.1 200 OK” geliefert hat, und daher hat ohne manuelle Prüfung niemand vermutet, dass im Hintergrund doch etwas schief gelaufen war (z.B. die Datenbank Migration während einem Update, oder ein vergessenes skip-XXX File im /etc/gitlab Verzeichnis).

Auch wenn man das Update direkt auf der command line ausgeführt hat, konnte man in der abschliessenden Meldung nicht sehen, ob noch alles o.k. ist.

Festgestellt hat man das dann erst, wenn man sich in der GitLab Admin Area unter “Health Check” den Status angesehen hat.

Unten ein Beispiel wie es aussieht, wenn alles i.O. ist (Zur Info: Die Beispiel URL und Token gibt es nicht):

GitLab Status

D.h. ein neuer Check musste her, und den gibt es auch direkt bei GitLab zum Downloaden unter:

https://gitlab.com/6uellerBpanda/check_gitlab/blob/master/check_gitlab.rb

Der alte Check lief dabei direkt auf den einzelnen GitLab Hosts. Das war mit dem neuen Check allerdings ein Problem, weil er als Voraussetzung Ruby >2.3 hat, und wir z.B. noch einige Hosts unter Ubuntu Trusty betreiben.

Deshalb wird der neue Check direkt auf dem Monitoring Server (auch Ubuntu Trusty) ausgeführt, der zu diesem Zweck zusätzlich per rvm mit einem z.Zt. neuen Ruby 2.5.1 ausgestattet wurde, wobei im Ruby Skript das Shebang leider hardcoded eingetragen werden musste, weil es (zumindest unter Trusty) nicht anders funktioniert hatte (ohne grösseren Aufwand und vielen Änderungen an anderen Systemdateien):

#!/usr/local/rvm/rubies/ruby-2.5.1/bin/ruby

Nachdem die Token zum Zugriff im Bild oben seit einigen GitLab Versionen deprecated sind zugunsten einer IP Whitelist, hat das den Deploy des Checks zusätzlich erleichtert.

Der Aufruf des Checks sieht dann z.B. so aus:

root@icinga2-server:~# check_gitlab.rb -m health -s https://gitlab.netways.de -k
OK - Gitlab probes are in healthy state

Damit das dann auch funktioniert, muss auf der entfernten GitLab Instanz noch die IP Whitelist unter /etc/gitlab/gitlab.rb eingetragen werden:

gitlab_rails['monitoring_whitelist'] = ['127.0.0.1/8','10.XX.XX.XX/24']

Am besten checkt man natürlich nur über ein internes Netz, wie oben im Beispiel angegeben.

Das ganze kann man auch über ein GitLab Puppet Modul realisieren, indem man die Whitelist über Hiera oder Foreman verteilt:

Beispiel Hierarchie im Foreman:

gitlab:
    gitlab_rails:
      monitoring_whitelist:
      - 127.0.0.1/8
      - 10.XX.XX.XX/24  
Stefan Gundel

Autor: Stefan Gundel

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

SNMP Netzwerk Monitoring

Huhu!

Heute möchte ich euch ein wenig in die Welt von SNMP Monitoring mit Icinga 2 entführen. Da man leider nicht immer einen Switch mit SNMP zur Hand hat, verwende ich eine GNS3 Netzwerk Umgebung sowie eine CentOS 7 Maschine für Icinga 2.

Doch was ist den dieses SNMP überhaupt, was kann das? Zunächst SNMP steht für Simple Network Message Protocol (RFC 1157) und wurde mit dem Gedanken entwickelt Netzwerkgeräte wie Drucker, Router, Switche und vermutlich irgendwann auch Toaster per IoT von einem Zentralen Punkt im Netzwerk aus überwachen bzw. steuern zu können. SNMP an sich besitzt nicht wirklich viel Magie es beschreibt im Endeffekt wie Datenpakete aussehen können. Damit Icinga 2 (Managmentstation) den Switch (Agent) fragen kann, wie es ihm den heute so geht. Die eigentliche Magie ist die sogenannten Managment Information Base, umgangssprachlich auch MIB genannt.

Die MIB kann man sich wie einen großen Baum vorstellen, dessen Äste und Blätter mit Hilfe von eindeutigen OIDs gebildet werden. Die Blätter die an unseren Ästen hängen sind Objekte wie ein Lüfter, oder eine Festplatte und können als als OID so aussehen: 1.3.6.1.4.1.1.4.

Nach viel Techbabbel kommt nun wenig Kaboom (Practical Examples). An Hand des Beispiel möchte ich euch ein Grundgerüst an die Hand geben, wie man bequem und ohne Geräte spezifisches Plugin ein SNMP Monitoring unter Icinga 2 einfach realisieren kann.

Im ersten Schritt holen wir uns alle OIDs samt Beschreibung vom Gerät, in meinem Fall von einem VyOS Router:

snmpwalk -Os -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_desc
snmpwalk -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_oid

Für das Beispiel wähle ich drei OIDs aus:

.1.3.6.1.2.1.2.2.1.2.1
.1.3.6.1.2.1.2.2.1.2.2
.1.3.6.1.2.1.2.2.1.2.3

Mit dem Director hab ich ein Template und Service angelegt, welches auf das Check_Plugin/Kommando check_snmp zurückgreift. Die ausgewälten OIDs werden Kommasepariert per Costume Attribut “snmp_oid” mitgegeben:

template Service "snmp" {
    check_command = "snmp"
    max_check_attempts = "3"
    check_interval = 1m
    retry_interval = 20s
}
object Service "Interfaces" {
    host_name = "vyos"
    import "snmp"
    vars.snmp_label = "Interfaces"
    vars.snmp_oid = ".1.3.6.1.2.1.2.2.1.2.1,.1.3.6.1.2.1.2.2.1.2.2,.1.3.6.1.2.1.2.2.1.2.3"
}

Nach dem ausbringen der Konfiguration sollte das ganze folgendermaßen aussehen:

 

Tipp am Rande:
Falls euer Gerät nicht auf Öffentlichen MIBs aufbauen sollte, wie hier im Beispiel, bekommt ihr die im Regelfall vom Hersteller bereitgestellt. Die MIB wird einfach zu den bereits existierenden hinzugefügt und dann ist alles wie gehabt! 🙂

Damit verabschiede ich mich und wünsche wie immer viel Spass beim Implementieren!

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.