rsync und was dann?

Diese Woche hatte ich die zweifelhafte Ehre die mit 1,6TB schon etwas größere MySQL-Datenbank (MariaDB) eines Kunden auf den zweiten Datenbankknoten zu spielen. Dabei war die Herausforderung das die ganze Show außerhalb der Geschäftszeiten von 17:30 Uhr bis max. 5:00 Uhr stattfindet. Ein Dump der Datenbank dauert erfahrungsgemäß zu lange um das Wartungsfenster einzuhalten. Kein Problem dachte ich mir, dann halt rsync auf Dateiebene. Also die Datenbankzugriffe pünktlich zu Beginn des Wartungsfensters unterbunden, die Datenbank gestoppt und den rsync vom Zielsystem aus wie folgt gestartet:

# rsync -avPz --exclude 'ib_logfile*' root@a.b.c.d:/var/lib/mysql/ /var/lib/mysql/

Eine kurze Erklärung der gesetzten Parameter:

  • a – kopiert rekursiv unter Beibehaltung der Dateiberechtigungen
  • v – sorgt für eine ausführlichere Ausgabe (verbose)
  • P – zeigt eine Fortschrittsanzeige (progress) und setzt den Transfer bei einem evtl. Abbruch fort (partial)
  • z – aktiviert die Komprimierung, meistens bei einer Übertragung via Netzwerk sinnvoll

Die beiden InnoDB Logfiles (ib_logfile0 und ib_logfile1) mit jeweils 11GB wurden für eine schnellere Übertragung ausgeschlossen, da sie beim Anstarten eh wieder neu erstellt werden.

Leider hat sich relativ schnell herausgestellt dass das nicht der Weisheit letzter Schluss war, da die Übertragung mit ca. 15MB/s an die 32 Stunden gedauert und damit das Wartungsfenster überschritten hätte. Auch eine Anpassung der Parameter und der Synchronisationsvorgang auf ein schnelleres Storage mit max. 40MB/s und damit fast 15 Stunden wären zu lange gewesen.

Nach einer kurzen Internetrecherche bin ich auf eine mögliche Lösung mit mbuffer gestossen. Der “measuring buffer” steht bereits als kleines Paket für die gängigen Linux-Distributionen zur Verfügung und sorgt dafür das es durch einen Puffer nie zu einem Leerlauf des Datenstroms kommt und die Verbindung somit nicht abreißen kann. Mit Komprimierungsfunktionalität und etwas “Bash-Magic” außenrum kann das dann so aussehen:

# tar cf - * | mbuffer -m 1024M | ssh a.b.c.d '(cd /var/lib/mysql; tar xf -)'

Dem zuzusehen war schon fast eine Freude, hätte nur noch eine Tüte Chips und vielleicht ein passendes Kaltgetränk gefehlt. Mit Transferraten von bis zu 350MB/s hat der Kopiervorgang so gerade mal über 2 Stunden gedauert (Durchschnitt 216MB/s) und die Umgebung bis zum Ende des Wartungsfensters längst wieder im Normalzustand. Das in vielen Fällen schon hilfreiche rsync kommt v.a. bei sehr vielen oder sehr großen Dateien durch die Checksummenberechnung an seine Grenzen, sodass mbuffer hier durchaus mehr als nur eine Alternative sein kann.

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin 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. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Facebook: Endlich Ruhe

Auch wenn sich Facebook – zumindest in meinem Umfeld – auf dem absteigenden Ast bewegt, kommt man trotzdem nicht daran vorbei. Manchmal passiert wohl was wichtiges, dann “muss” man doch mal etwas posten oder eine ganz besondere Nachricht verfassen. Bevor man aber soweit ist, wird man erstmal vom Facebook News Feed erschlagen

Der News Feed war mal eine ganz tolle Geschichte. Aber irgendwann hat Facebook damit begonnen mehr Werbung drauf zu packen und bei Posts eine seltsame Gewichtung vorzunehmen. Das Ergebnis ist meterweise Blödsinn, den kein Mensch dieser Welt braucht 😉

Zur Lösung des Problems gibt es für Chrome eine Extension namens News Feed Eradicator for Facebook. Dieses Tool entfernt den News Feed vollständig und zeigt stattdessen ein mehr oder weniger sinnvolles Zitat eines wichtigen Menschen an z.B. von Laozi (einer dieser weißhaarigen alten Männer die für jede Lebenslage einen äußerst bedeutungsschwangeren Spruch bereithalten).

Na also, Facebook, geht doch! Gleich viel besser 😉 – Danke dafür!

Als Bonus obendrauf ist der Eradicator eine Vorzeigeextension für den Browser. Zugriff nur auf Facebook URL’s, keine Permissions um die komplette Historie auszulesen (obwohl man eigentlich nur einen Farbwert berechnen wollte) und die Quotes sind Offline in der Extension hinterlegt. Ein absolut fettes datenschutzrechtliches Brett in Zeiten von Cambridge Analytica.

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Graphite-API für Grafana und Icinga Web 2

Ziel dieses Posts ist es, am Ende die Metriken über die Graphite-API als Backend für Grafana und das Icinga-Web-2-Module graphite betreiben zu können.

Grafana übernimmt hierbei optional die Visualisierung über eigene Dashboards, was ansonsten Graphite-Web leistet. Für Icinga Web 2 ist Grafana nur erforderlich, falls nicht das Module graphite zum Einsatz kommen soll, sondern stattdessen grafana zur Darstellung im Icinga Web 2 verwendet werden sollte.

Die Graphite-API ist in Python implementiert und soll hierbei via HTTPS angesprochen werden. Zusätzlich ist der Zugriff via Basis-Authentifizierung zu beschränken. Dies alles überlassen wir dem Apache, auch die API lassen wir mittels WSGI im Apache laufen.

Der Vorteil gegenüber dem Graphite-Web liegt darin, die ganzen Django-Bibliotheken nicht zu benötigen und auch kein DB-Backend a la SQLite, MySQL oder PostgreSQL. Nachteil ist, das Projekt Graphite-API wird nicht vom Graphite-Team betrieben, somit ist die Pflege und Aktualität nicht sichergestellt.
(more…)

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Azubiprojektwoche 2019

Wie jedes Jahr findet bei NETWAYS eine Azubiprojektwoche statt. In dieser sollen alle Azubis abteilungsübergreifend ein Projekt umsetzen. Dieses Jahr waren wir zu neunt und wenn man der Resonanz der Kollegen glauben schenken darf, dann war das Projekt ein voller Erfolg.

Alles begann am Morgen mit einem Brainwriting bei dem auch ordentlich Ideen gesammelt worden sind. Wer weiß, vielleicht gibt es die ein oder andere in den nächsten Jahren ja noch zu sehen.


Die Entscheidung fiel dann auf ein Projekt das sich um einen 3D-Drucker herum entwickeln soll. Ziel der Projektwoche ist immerhin, sowohl Spaß zu haben, als auch mal etwas Anderes zu machen als man sonst machen würde. Dazu kommt noch, dass man bestenfalls etwas kreiert was für NETWAYS einen Nutzen hat und nicht nur das uns gegebene Budget restlos aufbraucht. Bestimmt wird eines Tages mit dem 3D-Drucker ein Ersatzteil für unsere Kaffee-Maschine gedruckt und bis dahin könnten damit Goodies für unsere Schulungen oder ähnliches gedruckt werden. Vorwand – Check

Damit war auch schonmal ein Aufgabenbereich geschaffen, ein Team das sich mit dem Drucker auseinandersetzt, der dazugehörigen Software und bestenfalls auch selbst einige Dinge modelliert. (Wir haben dazu Blender genutzt)

Natürlich wäre Hallo wir haben einen 3D-Drucker gekauft und uns zu neunt damit beschäftigt ein etwas einfacher Weg sich aus der Affäre zu ziehen, deswegen gab es gleichzeitig noch einen Teil mit persönlicheren Beweggründen für alle Nerds und die es werden wollen.

Ein Gaming-Table, also ein Tisch der für mitunter für Tabletop-Games genutzt werden kann, aber natürlich war auch hier der Zukunftsgedanke gegeben.
Das ein odere andere Meeting-Thema mag sich anbieten an solch einen Tisch zu führen. Außerdem ist es sehr angenehm, dass sich nicht ein jeder zu einer Leinwand oder einem Fernseher wenden muss und nicht in den leeren Raum gesprochen wird.

Dadurch wurde natürlich ein zweites Squad geboren, weil der Fernseher lässt sich nicht von alleine in die MDF-Platte, die Tischbeine schrauben sich nicht von Selbst an, die Stichsäge schneidet nicht von alleine und der Überzug kommt auch nicht von irgendwo.

Wir haben uns in jeden Fall nicht zu wenig vorgenommen für fünf Tage und das ganze hat auch nur so gut funktioniert, weil jeder an einem Strang gezogen hat und man sich gegenseitig geholfen hat. Unsere Arbeitsstruktur hat sichergestellt das jeder über den Stand des jeweils anderen Bescheid wusste und entsprechend helfen konnte wenn eine Gruppen hinter den Zeitplan fällt. Am letzten Tag, dann noch ein paar Mal gemeinsam Proben, damit die Triple-Moderation nicht in die Hose geht, kurz bevor die Präsentation ansteht und natürlich ging alles gut.

Ein paar von uns werden bis zum nächsten Azubiprojekt keine Azubis mehr sein, sondern ausgelernt, während Andere versuchen werden das diesjährige Projekt zu toppen. Wir freuen uns drauf.

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

Temperatur und Feuchtigkeit in Telegram vom RaspberryPI

Ich möchte hier beschreiben, wie man mit einem RaspberryPI die Temperatur und Feuchtigkeitswerte sich aufs Handy per Telegram schickt.
Verraussetzung ist ein RaspberryPI 3 b+ und ein Temperatur / Feuchtigkeitssensor, ich habe folgendes verwendet:

  • DSD TECH DHT22 AM2302 Temperatur und Luftfeuchtigkeit Sensor Modul für Arduino Raspberry Pi
  • RaspberryPI 3 B+

Anleitung wie man den Sensor an den RaspberryPI ansteckt, findet man reichlich im Netz z.B. Sensor-Einbau RaspberryPI/
Da in diesem Artikel auch schon beschrieben wird, wie man mit dem Tool Adafruit die Werte Temperatur und Feuchtigkeit ausliest, werde ich hier nicht genauer darauf eingehen.
Soviel, Ich lasse das Skript per cronjob zu bestimmten Zeiten ausführen und erhalte dann die Werte via Telegram auf mein Handy weitergeleitet.

Nur wie kann man sich die Werte auf das eigene Handy per Telegram senden lassen? Das werde ich hier kurz beschreiben.

Voraussetzung:

  • Handy mit der App Telegram (Apple IOs oder Android)

Als erstes müssen wir uns in Telegram einen eigenen Bot erstellen,  den wir später per API erreichen können,

wie das funktioniert, wird auch in vielen Webseiten bereits erklärt z.B. Telegram Bot erstellen

So, da der Bot jetzt bereit ist um per API Nachrichten zu empfangen, brauchen wir einen API-Aufruf der so aussehen kann:

curl -X POST 'https://api.telegram.org/botid:token/sendMessage?chat_id=id&text='$(/usr/local/sbin/AdafruitDHT.py 2302 4)'' > /dev/null 2>&1

Ich habe die Ausgaben die auf der Shell kommen nach /dev/null geleitet, denn die brauchen wir nicht, wenn es funktioniert.

Für die ersten Tests würde ich die Ausgabe schon sichtbar lassen, um den JSON-Output mal gesehen zu haben und gegebenenfalls Fehlermeldungen zu sehen.

curl -X POST 'https://api.telegram.org/botid:token/sendMessage?chat_id=id&text='$(/usr/local/sbin/AdafruitDHT.py 2302 4)'' | python -m json.tool

{
"ok": true,
"result": {
"chat": {
"first_name": "Johannes",
"id": 400269857,
"last_name": "Carraro",
"type": "private",
"username": "xxxx"
},
"date": 1563270619, <-- UNIXTIMESTAMP
"from": {
"first_name": "Raspberry",
"id": xxxxxx,
"is_bot": true,
"username": "xxxxx"
},
"message_id": 265,
"text": "Temp=20.8C::Humidity=75.8%"
}
}

Wie wir sehen war die Ausgabe erfolgreich und wir sollten auf dem Handy im Telegram eine neue Nachricht mit der Temperatur und Feuchtigkeit bekommen haben.

Man kann sich über den RaspberryPI mit verschiedenen Sensoren deren Werte so auf das Handy per Telegram schicken lassen, eine coole Sache.
Anwendungsbeispiel: Zimmergewächshaus, Zimmertemperatur, Außentemperatur etc.

Jetzt wünsche ich viel Erfolg beim nach basteln!

Natürlich kann ich jedem unsere Trainings nahelegen rundum OpenSource-Themen

Johannes Carraro
Johannes Carraro
Support Engineer

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.

Automatisierte Updates mit Foreman Distributed Lock Manager

Foreman Logo

Wer kennt das nicht am besten soll alle nervige, wiederkehrende Arbeit automatisiert werden, damit man mehr Zeit für spaßige, neue Projekte hat? Es gibt nach Backups wohl kein Thema, mit dem man so wenig Ruhm ernten kann, wie Updates, oder? Also ein klarer Fall für Automatisierung! Oder doch nicht weil zu viel schief gehen kann? Nun ja, diese Entscheidung kann ich euch nicht abnehmen. Aber zumindest für eine häufige Fehlerquelle kann ich eine Lösung anbieten und zwar das zeitgleiche Update eines Clusters, was dann doch wieder zum Ausfall des eigentlich hochverfügbaren Service führt.

Bevor ich aber nun zu der von mir vorgeschlagen Lösung komme, will ich kurz erklären wo die Inspiration hierfür herkommt, denn Foreman DLM (Distributed Lock Manager) wurde stark vom Updatemechanismus von CoreOS inspiriert. Hierbei bilden CoreOS-Systeme einen Cluster und über eine Policy wird eingestellt wie viele gleichzeitig ein Update durchführen dürfen. Sobald nun ein neues Update verfügbar ist, beginnt ein System mit dem Download und schreibt in einen zentralen Speicher ein Lock. Dieses Lock wird dann nach erfolgreichem Update wieder freigegeben. Sollte allerdings ein weitere System ein Lock anfordern um sich upzudaten und die maximalen gleichzeitigen Locks werden bereits von anderen Systemen gehalten, wird kein Update zu dem Zeitpunkt durchgeführt sondern später erneut angefragt. So wird sichergestellt, dass die Container-Plattform immer mit genug Ressourcen läuft. CoreOS hat dazu dann noch weitere Mechnismen wie einen einfachen Rollback auf den Stand vor dem Update und verschiedene Channel zum Testen der Software, welche so einfach nicht auf Linux zur Verfügung stehen. Aber einen Locking-Mechanismus zur Verfügung zu stellen sollte machbar sein, dachte sich dmTech. Dass die Wahl auf die Entwicklung als ein Foreman-Plugin fiel lässt sich leicht erklären, denn dieser dient dort als das zentrale Tool für die Administration.

Wie sieht nun die Lösung aus? Mit der Installation des Plugins bekommt Foreman einen neuen API-Endpunkt über den Locks geprüft, bezogen und auch wieder freigegeben werden können. Zur Authentifizierung werden die Puppet-Zertifikate (oder im Fall von Katello die des Subscription-Managers) genutzt, die verschiedenen HTTP-Methoden stehen für eine Abfrage (GET), Beziehen (PUT) oder Freigaben (DELETE) des Lock und die Antwort besteht aus einem HTTP-Status-Code und einem JSON-Body. Der Status-Code 200 OK für erfolgreiche Aktionen und 412 Precondition Failed wenn Beziehen und Freigeben des Locks nicht möglich ist sowie der Body können dann im eigenen Update-Skript ausgewertet werden. Ein einfaches Beispiel findet sich hierbei direkt im Quelltext-Repository. Ein etwas umfangreicheres Skript bzw. quasi ein Framework wurde von einem Nutzer in Python entwickelt und ebenfalls frei zur Verfügung gestellt.
(more…)

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman 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 wie nun bei NETWAYS.