pixel
Seite wählen

NETWAYS Blog

Riesige Datenmengen transportieren – ein Ding der Unmöglichkeit?

Zugegeben, vor dem konkreten Problem, eine fast 2 TB große Datei von einem System zu transportieren, auf das man nur über mehrere Hops Zugriff hat, steht man nicht jeden Tag. Aber wenn doch, dann bietet eine ganze Sammlung an Tools eine gemeinsame Lösung an.

Mit “mehrere Hops” ist gemeint, dass es nicht möglich ist, mit den üblichen Bordmitteln wie scp oder rsync Daten zu kopieren. Ein Beispiel könnte ein Citrix-Zugang mit PuTTy sein, der zwar Shell-Zugriff erlaubt, aber kein Kopieren. Im konkreten Fall “durften” die Daten natürlich kopiert werden, es war schlicht nur technisch nicht “möglich”. Der Host, auf dem die Daten lagen, hatte Zugriff auf Websites im Internet durfte aber keine anderen Protokolle “nach draussen” benutzen.

Zerhacken und Zerteilen um riesige Datenmengen transportieren zu können

Zwar ist es heutzutage eigentlich problemlos möglich, auch riesige Datenmengen von A nach B zu kopieren. Da wir hier aber von einem nicht unerheblichen Zeitraum sprechen, den die Kopie braucht und ein kurzer Abbruch wertvolle Zeit gekostet hätte, war der Ansatz erstmal folgender:

  • Die Daten so klein komprimieren wie es sinnvoll ist (hier mit bzip2)
  • Die Daten klein hacken (mit split)
  • Die einzelnen Stücke dann hochladen
  • Beim Empfänger zusammensetzen und entpacken

Das lässt sich ganz gut per Shell realisieren.

nohup time tar cjvf testdb.tar.bz ../backups/full/ &
split -b5000000000 testdb.tar.bz

Die Datenbank bestand dabei aus einigen sehr kleinen Dateien und einigen, die etliche GB und teilweise sogar über 1 TB groß waren. Es zahlte sich also nicht aus, die Dateien einzeln zu kopieren.

  • nohup lässt den Befehl weiterlaufen, auch wenn die Verbindung abbricht und schreibt den Output nach nohup.out
  • time gibt ab, wie lang das Komprimieren braucht. Weil ich einfach ein neugieriger Mensch bin
  • tar mit -j komprimiert die Dateien mit bzip2 statt gzip was in vielen Fällen zwar länger dauert aber deutlich kleinere Dateien hervorbringt
  • split hackt eiskalt die Dateien in kleine Teile. In diesem Fall jeweils 5 GB groß. Dabei hat der Befehl noch einige Optionen um einem das Leben leichter zu machen. Es zahlt sich aus, da etwas mehr nachzustöbern als ich das damals gemacht hab

Somit hat man dann eine große Anzahl “ausreichend kleiner” Dateien. Mit tail -f nohup.out kann man beobachten, was sich gerade tut. Das geht auch, wenn disconnected wurde. Alternativ kann man auch screen oder tmux nehmen. Da diese Tools aber Probleme mit manchen remote Verbindungen machen und nicht immer zur Verfügung stehen, bleib’ ich persönlich lieber bei nohup.

Übrigens sollte man nicht unbedingt an die maximale Obergrenze des Uploads gehen. Beim ersten Versuch hab’ ich das getan und die Daten wurden teilweise von NextCloud verworfen. Warum, hab’ ich nicht mehr versucht herauszufinden, weil es bei der Methode eigentlich egal ist, ob man wenige große oder sehr viele sehr kleine Dateien nimmt. 5 GB haben aber gut funktioniert.

Der Transporter

Zugegeben, ich hatte den Vorteil, eine NextCloud Instanz nutzen zu können, die noch dazu genug Platz bot. Der Trick funktioniert bis hier her aber natürlich auch mit jedem anderen Übertragungsweg. Auch wenn man die Dateien ggf. kleiner hacken muss.

Für den weiteren Schritt baut man sich ein kleines Script.

#!/bin/bash
for i in $(ls x*)
do
  curl -T $i -u transportuser:$MYPASSWORD https://nextcloud.example.com/remote.php/webdav/testdb/$i
done

Auch dazu ein paar Erklärungen.

  • ls x* gibt alle Dateien aus, die split erstellt hat. Ohne weitere Optionen startet der Name aller zerlegten Dateien mit x
  • In der NextCloud wird im Home von User transportuser der Ordner testdb angelegt
  • curl nutzt WebDAV um die einzelnen Schnippsel hochzuladen
  • Der User transportuser wurde dafür extra angelegt und der Ordner testdb den eigentlichen Empfängern freigegeben. Das erleichtert das Management und vor allem das Passworthandling
  • Das Passwort kommt im nächsten Schritt

Tatsächlich riesige Datenmengen transportieren

Das Script hat noch eine Einschränkung. Da es auf einem “fremden” System liegt, möchte man darin natürlich nicht das Passwort eines NextCloud Users hinterlegen. Wir haben einige Möglichkeiten ausprobiert und dabei auch bedacht, dass man es evtl. aus der Shell-History oder der Prozessliste auslesen könnte. Das beste, das wir bisher gefunden haben ist eine Umgebungsvariable, die nicht in der History landet.

 export MYPASSWORD=mysupersecret
nohup time ./thetransporter.sh

Und wieder Erläuterungen.

  • Die erste Zeile ist um eine Stelle eingerückt. Das verhindert (üblicherweise!) dass sie in die Shell History aufgenommen wird. Bevor man sich darauf verlässt, sollte man das unbedingt testen!
  • Die zweite Zeile ruft schlicht das Script von oben auf, wo die Umgebungsvariable genutzt wird

Andere Lösungen, wie eine interaktive Angabe beissen sich sich mit nohup.

Ganz unabhängig davon, ob das Passwort hier sicher genug war oder nicht, schadet ein Wechsel des Passworts direkt im Anschluss sicher nicht. Hat man sich einen eigenen User für den Transport angelegt, kann man ihn auch einfach wieder entfernen.

Die Auflösung

Hat man die Daten so in die NextCloud gepushed, kann man sie einfach mit dem NextCloud Client auf ein eigenes Gerät synchronisieren lassen. Tip: Man kann im Client angeben, welche Ordner synchronisiert werden sollen und welche nicht, falls man mehrere Geräte angeschlossen hat.

Um die Daten wieder zusammenzubauen reicht ein schlichtes cat.

cat x* > testdb.tar.bz2
tar xvf testdb.tar.bz2

Und was? Ja, Erläuterungen.

  • split benennt die Dateien so, dass die alphabetische Sortierung von cat sie wieder richtig zusammenbaut
  • tar ist inzwischen so schlau, dass man die Kompressionsmethode nicht mehr angeben muss. Schadet zwar nicht, sieht aber irgendwie cooler aus so

Besonders charmant finde ich daran, dass es den Tools völlig wurscht ist, was in den Dateien drin ist. Ob das Klartext, binaries oder was auch immer sind. Sie tun ja nichts mit dem Inhalt, zerhacken sie nur und stückeln sie zusammen.

Wer uns gern an solchen Lösungen kiefeln und werkeln sehen möchte, schliesst am besten gleich einen Support-Vertrag bei uns ab.

Thomas Widhalm
Thomas Widhalm
Lead Senior Systems 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...

Icinga for Windows v1.6.0 – Einfacher. Zentraler. Sicherer.

Die Kollegen von Icinga haben letzte Woche Icinga for Windows in Version v1.6.0 veröffentlicht. Auch wenn diese Version keine neuen Plugins für die Überwachung bietet, hat sich im Bereich des Icinga PowerShell Frameworks einiges getan. Dadurch ist die Lösung nicht nur einfacher zu verwenden, sondern auch noch zentraler verwaltbar und sicherer.

Dürfen wir vorstellen: Die IMC

Die IMC (Icinga Management Console) wurde im Rahmen vergangener Icinga for Windows als experimental eingeführt. Ziel war es, ein einfaches Management zu schaffen, um die meisten Funktionalitäten über eine UI abbilden zu können. Dadurch ist es nicht mehr notwendig, sich alle Befehle von Icinga for Windows zu merken oder diese zu kennen – sondern die Konfiguration erfolgt direkt darüber.

Im Zuge der Einführung der IMC, wurde ebenfalls ein neuer Setup Wizard generiert, welcher nicht nur einfacher und intuitiver ist als der alte, sondern auch noch über eine Hilfe verfügt, welche einem erklärt, welche Eingaben im jeweiligen Bereich notwendig sind und was diese bedeuten. Die Konfiguration ist hierbei im nicht-advanced Modus auf die absoluten Grundlagen beschränkt, um schnell ans Ziel zu kommen. Die restlichen Einstellungen im advanced Teil, können simpel eingesehen und geändert werden, wurden jedoch so ausgewählt, dass man in vielen Umgebungen auf eine Änderung sogar verzichten könnte.

Zentrale Verwaltung mit Repositories

Einer der großen Kritikpunkte an Icinga for Windows war die Komponenten Installation. Bisher musste jede Komponente einzeln heruntergeladen und mit einem Pfad bei der Installation hinterlegt werden. Mit Icinga for Windows v1.6.0 wurde nun ein Repository-Management hinzugefügt. Hierdurch können direkt entweder die offiziellen Repositories von Icinga for Windows auf packages.icinga.com angebunden werden oder ein eigenes, zentrales. Icinga for Windows bietet dabei die Möglichkeit, vorhandene Repositories zu synchronisieren, um diese in seiner lokalen Umgebung zu spiegeln. Dadurch kann die Installation von Systemen, welche nicht in das Internet können, deutlich vereinfacht werden. Ein Beispiel wäre hier, die offiziellen Icinga Repositories auf seinen Icinga 2 Master zu synchronisieren, um dort ein Repository für alle Systeme bereitzustellen.

Im Falle von DMZ Systemen kann das Repository wiederum von zentralen Icinga 2 Master auf Icinga Satellitensysteme synchronisiert oder aber auf zentrale File-Shares abgelegt werden, um von dort die Komponenten zu installieren. Für das Update von Repositories gibt es ebenfalls Kommandos, die eine Aktualisierung ermöglichen.

Der Vorteil des Repositories liegt darin, dass direkt die aktuellen Versionen der jeweiligen Komponenten installiert oder mit einem simplen Befehl die gesamte Umgebung aktualisiert werden kann. Sollte es aus bestimmen Gründen notwendig sein, kann die Version von einzelnen Komponenten auch gelockt werden. Das bedeutet, sofern eine ältere Version installiert ist, wird bis zur gelockten Version aktualisiert. Ist bereits die gelockte Version installiert und eine neue verfügbar, wird diese übersprungen.

Weitere Details hierzu gibt es direkt in der Icinga for Windows Repository Dokumentation.

Mehr Sicherheit durch JEA

JEA steht für Just-Enough-Administration und ist eine Lösung von Microsoft für PowerShell. Durch JEA können einzelne Benutzer, welche keine Administratoren sind, Befehle mit erhöhten Rechten im System Kontext ausführen. Die Funktionalität ist dabei ähnlich wie sudo auf Linux.

In der Vergangenheit gab es des Öfteren Probleme, das diverse Überwachungsmöglichkeiten nicht genutzt werden können, da der Benutzer beispielsweise nicht in der Hyper-V Administrator Gruppe ist und deshalb den Status der virtuellen Maschinen nicht abfragen kann. Ein weiteres Problem ergibt sich auch, wenn man diverse Services oder Tasks überwachen möchte, welchen mit einem normalen Standardbenutzer nicht eingesehen werden können.

Durch ein JEA-Profil wird es erlaubt, dass ein bestimmter Benutzer diese Plugins nun im Systemkontext mit erhöhten Rechten ausführt. Dabei wird von Icinga for Windows ein Profil basierend auf allen installierten Komponenten erstellt. Dieses Profil deckt jedoch nur die notwendigen Befehle zum Ausführen von Plugins und Komponenten ab. Für Icinga for Windows notwendigen Befehle für das Management der Umgebung, werden dabei nicht berücksichtigt.

Um das ganze abzurunden und die Trennung perfekt zu machen, bietet Icinga for Windows die Möglichkeit an, einen Managed User mit dem Namen icinga anzulegen. Dieser Benutzer ist ein lokaler Benutzer auf dem System, ohne Berechtigungen sich lokal oder per RDP anzumelden. Der einzige Zweck ist, dass er als Service Benutzer fungiert und den Icinga Agent sowie den Icinga for Windows Dienst startet. Im Zusammenspiel mit dem von Icinga for Windows generierten JEA-Profil, kann dann das System vollständig überwacht werden. Die Verwaltung des Benutzers obliegt dabei vollständig Icinga for Windows und im Rahmen der Erstellung des Benutzers oder bei diversen Änderungen an den Services während der Icinga for Windows Installation oder Updates, wird jedes Mal ein neues, zufälliges 60-stelliges Password generiert und dem Benutzer zugewiesen. Dieses Password wird nach Ende der jeweiligen Installationsschritte intern wieder verworfen und wird nirgends abgelegt. Hierdurch wird eine Kompromittierung des Systems ohne bereits vorhandene Administratorrechte deutlich erschwert.

Weitere Details sowie Anforderungen, finden sich direkt in der Icinga for Windows JEA Dokumentation.

Performance Gewinn durch API-Check Forwarder

Ein weiteres Thema welches mit Icinga for Windows v1.6.0 von experimental als stabil gilt, ist der API-Check Forwarder, welcher in vergangenen Versionen eingeführt wurde. Hintergrund dieser Lösung ist, dass das Starten sowie die Ausführung von PowerShell Befehlen innerhalb der von Icinga 2 gestarteten Shells vor allem bei Systemen mit weniger Kernen eine erhöhte Systemlast verursachen. Durch den API-Check Forwarder wird zumindest der Ausführungsteil ausgelagert, da alle Befehle für die Plugin-Ausführung innerhalb des Icinga for Windows Dienstes durchgeführt und lediglich das Ergebnis an die lokale Shell weitergereicht wird.

Für diese Lösung werden zwei zusätzliche von Icinga bereitgestellte Komponenten benötigt, um eine REST-Api bereitzustellen sowie die Checks per API auszuführen. Beides kann direkt über die neuen Icinga Repositories installiert werden. Für eine sichere Verbindung werden direkt die Zertifikate des Icinga Agent verwendet. Nach Bedarf können jedoch auch eigene Zertifikate verwendet werden. Wichtig dabei ist, dass eine Erstellung des REST-Api Sockets ohne ein TLS Zertifikat nicht möglich ist.

In der zugehörigen Dokumentation zum API-Check Forwarder von Icinga for Windows gibt es weitere Details.

Was bringt die Zukunft?

Die nächste Version von Icinga for Windows v1.7.0 ist bereits zur diesjährigen OSMC eingeplant. Hier werden wir noch weiter den Schwerpunkt auf Performance sowie eine Vielzahl von Optimierungen für Entwickler legen, um es noch einfacher zu machen eigene Plugins und Komponenten zu entwickeln. Ein entsprechender Talk ist ebenfalls eingereicht.

Wir freuen uns auf eine rege Teilnahme und wünschen bis dahin alles Gute!

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

Icinga Plugins in Golang

Golang ist an sich noch eine relativ junge Programmiersprache, ist jedoch bei vielen Entwicklern und Firmen gut angekommen und ist die Basis von vielen modernen Software Tools, von Docker bis Kubernetes.

Für die Entwicklung von Icinga Plugins bringt die Sprache einige hilfreiche Konzepte mit. Golang baut fertige Binaries, Plugins können also zentral kompiliert und ohne große Abhängigkeiten verteilt werden. Alle Abhängigkeiten werden im Rahmen vom Bauprozess abgedeckt, die einzige Unterscheidung liegt in der Ziel Architektur, also Linux, Windows, Mac oder ähnliches, sowie ob 32 oder 64 bit.

Viele Funktionen und Packages (vergleichbar mit Libraries) kommen entweder direkt mit Golang mit oder können leicht aus der Open Source Community verwendet werden. Mit dem Package go-check von uns haben wir eine kleine Basis geschaffen, um leichter Plugins schreiben zu können, ohne sich zu sehr im Code wiederholen zu müssen.

Als ganz einfaches Go Plugin hier ein Beispiel eine “main.go” Datei:

package main

import (
	"github.com/NETWAYS/go-check"
)

func main() {
	config := check.NewConfig()
	config.Name = "check_test"
	config.Readme = `Test Plugin`
	config.Version = "1.0.0"

	_ = config.FlagSet.StringP("hostname", "H", "localhost", "Hostname to check")

	config.ParseArguments()

	// Some checking should be done here, when --help is not passed

	check.Exitf(check.OK, "Everything is fine - answer=%d", 42)
}

Alles was man noch tun muss, ist das Plugin zu kompilieren oder direkt auszuführen:

go build -o check_test main.go && ./check_test --help
go run main.go

Ein guter Einstieg in Go findet man über die Dokumentation, die Tour und vor allem in dem man sich umschaut, was die Community an Packages zu bieten hat.

Natürlich bleibt die Frage, wie überwache ich das Ding was mir wichtig ist, wofür es aber noch kein Plugin gibt. Gerade dort helfen wir von NETWAYS mit unseren Consulting und Entwicklungsleistungen.  Beispiele unserer Go Plugins findet man auf GitHub unter der NETWAYS Organisation.

 

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.

Standards vs. Apps

Apps

Eine haeufig gehoertes Thema fuer Absprachen dieser Tage ist gern mal
der Abgleich der Kommunikationsapps um eine gemeinsame Teilmenge zu
finden, die man dann in Zukunft verwenden koennte. Das Ergebnis ist dann,
abhaengig von der Gruppengroessee und der Interessenlage der Beteiligten
verschieden zufriedenstellend und kann durchaus zu der Installation
von Apps fuehren.

Chatapps

Man koennte sich natuerlich an der Stelle dann auch die Frage stellen,
warum es das braucht, warum ein Telegramm nicht mit einem Signal, iMessage,
Snapchat oder [beliebige Chatapp hier einfuegen] reden kann. Es waere ja irgendwo
schon gemuetlicher nur eine App zu haben. Von der Funktionalitaet sind
solche eher selten und in wenigen Punkten unterschiedlich.
Und die Antwort darauf kann schlechterdings eine technische
sein, Protokolle fuer solche Zwecke gibt es und eine “Uebersetzungs”-Schicht
einzubauen waere vermutlich ein vertretbarer Aufwand.
Es wuerden sicherlich ein paar Sachen nicht ueber verschiedene Dienste
hinweg funktionieren, aber 1:1-Chats und Gruppen waeren ja schon ausreichend.

Die naechste Option waere ja dann, wenn die Firmen hinter den Apps schon nicht miteinander
reden wollen, dass man auf seinem Geraet nur eine App installiert, die sich dann
mit allen diesen Diensten verbindet und das vermischt. Etwas frei zitiert:

“One App to rule them all, one app to bind them,…”
– Inschrift auf dem einen Ring, stark verfaelscht

Ein erstrebenswertes Ziel, wuerde es doch ebenefalls den Aufwand reduzieren (ganz zu schweigen
von Speicherplatz und Datenvolumen). Aber auch das ist nicht gaengig.

Angesichts der finanzstarken Lage vieler Betreiber solche Apps scheint es
mir unwahrscheinlich, dass solche Themen an einem “Koennen” scheitert.
Ein Erklaerungsansatz fuehrt diesen Zustand auf das Geschaeftsmodell zurueck,
das viele der Betreiber fahren.
So wird bei der Benutzung des Dienstes und durch die Apps oft das Verhalten
der Benutzer:innen ausgespaeht und dieser Datensatz direkt oder indirekt an die Kund:innen
verkauft. Der Kundenstamm rekrutiert sich dann aus den ueblichen Werbeleuten,
Quacksalbern, Propagandisten, Lobbyisten und Meinungsmachern (Mehrfachnennung moeglich,
Redundanz wahrscheinlich).
Interaktion fuer Leute ausserhalb des eigenen Systems zu erlauben wuerde
das Risiko der Reduktion der eigenen “Datenernte” beherbergen, da Personen
ausserhalb des Systems sich nicht die App installieren muessten, um mit einem Gegenueber innerhalb des Systems
zu kommunizieren und es wuerden vielleicht sogar welche die App entfernen.
Es waere also fundamental geschaeftsgefaehrdend, ein “offeneres” System zu bauen.

Videochats

Obwohl es schon vor 2020 diverse Videokommunikationssysteme gab, ist deren
Bedeutung stark angestiegen. Die Gruende dafuer sind offensichtlich, doch wie ist
denn der Zustand diese Oekosystems dieser Tage?
Das traurige Bild, dass sich einem bei der Betrachtung bietet, ist wiederum
das der verschiedenen Apps, die nicht miteinander interagieren.
Jetzt stellt sich bei verschiedenen Personenkreisen immer wieder die Frage,
ob man denn Zoom-, Teams-, Hangouts- oder sonst irgendein Meeting hat.
Dafuer gibt es dann jeweils eine dazugehoerige App oder man hofft, dass es noch
in einem von drei verschiedenen Browsern mit allen Funktionen laeuft.
Mit Glueck und am zweiten Vollmondtag in geradzahligen Monaten trifft das sogar zu.

Aber auch hier ist die gewuenschte Funktionalitaet sehr klar umrissen und wird von
allen abgedeckt. Es sollen n Teilnehmer 1 bis (n-1) Video- und Audiostreams bekommen
und auf der Seite ist ein Chatfenster.
Das klingt wiederrum technisch ueberschaubar, aber dennoch kann ich nicht mit
einem Teams-Client in ein Zoom-Meeting.
Das Szenario aehnelt somit in wesentlichen Punkten dem Zustand der Messenger,
der weiter oben beschrieben wurde.

Und damit kommt hier die rhetorische Frage, die zum naechsten Abschnitt ueberleitet:
Ginge das denn auch anders? Und wenn ja, wo?

Telefon

Als Gegenbeispiel kann hier die Telefonie dienen, ein Gespraech quer ueber den
Globus mit einer beliebigen Person ist recht leicht denkbar, soweit
diese auch ueber einen Telefonanschluss (oder heutzutage vielleicht eher einen Handyvertrag)
verfuegt. Dabei muss man nicht nach dem speziellen Dienstanbieter fragen, auch der Hersteller
des Geraetes interessiert wenig, wichtig ist einzig die Nummer.
Selbstverstaendlich gibt es da einige Einschraenkungen, wie etwa die Kosten und diverse
Altlasten, aber das ist in einem System, das deutlich aelter als die meisten Benutzer ist,
kaum verwunderlich. Verschiedenste Protokolle und Standards werden kombiniert um am
Ende das Gespraech zwischen zwei (oder mehr) Personen zu ermoeglichen.

Internet

Auch das Internet selbst ist ein Netzwerk von vielen verschieden Teilnehmern, die
ueber standardisierte Schnittstellen Daten austauschen und viele verschiedene Medien und
Uebertragungsvarianten kombinieren.
Es gibt kein Instagram-, kein Youtube- und kein TikTok-Internet, auch wenn es von
vielen hauptsaechlich dafuer verwendet wird.
Gemeinsame Standards schaffen eine Basis, die dies ermoeglicht.

Auch hier bietet es sich an, einen Blick auf das Geschaeftsmodel zu werfen,
Internet- und Telefonieanbieter verkaufen Zugaenge zu einem Netzwerk, beziehungsweise,
sie vermieten sie, da es meistens eher ein Abonnementmodel ist.
Es ist damit leicht vorstellbar, dass ein anbietendes Unternehmen dann ein gesteigertes Interesse daran
hat, den bestmoeglichen Zugriff auf das restliche Netzwerk zu bieten.
Soweit zumindest Theorie, in der Praxis ist das mit den Internetanbietern eine etwas
durchwachsenere Erfahrung.
So moechte sich etwa mindestens eine der groesseren Anbieter hierzulande den Zugang zu seinen
Kunden teuer bezahlen lassen und ist deshalb weniger auf gute Vernetzung bedacht als darauf
viel Geld dafuer einzustecken. Leidtragenden sind hierbei die Kleinkunden, die als
Verhandlungsmasse dienen. Dass das Geld dann auch nicht wirklich in das System reinvestiert
wird um zukunftsfaehige Verbindungen zu schaffen kommt dazu.
Aber das ist ein System von falschen Anreizen und hier nicht direkt Thema.

In Summe kann man heutzutage mit standardisierten Netzwerkprotokollen (UDP, TCP, HTTP, IMAP,…)
Daten zu fast beliebigen Punkten auf dem Globus schicken. Welches Programm ich dafuer verwende
ist dafuer (abgesehen natuerlich von der implementierten Funktionalitaet) irrelevant.

Standards

Es gibt viele verschiedene Formen von Standards, die ich hier, im Sinne des Artikels, in zwei
Gruppen teilen will.
Da sind zum einen Standards die eine oder mehre bestimmte Eigenschaften sicherstellen|definieren
um einen gewissen Zweck zu erreichen. Ungluecklicherweise ist diese Definition sehr vage,
deshalb moechte sie kurz ein wenig ausfuehren und Beispiele anbringen.
So gibt es etwa eine Klassifizierung fuer LASER (DIN EN 60825-1) die Laserquellen und -anlagen
nach ihrem Gefaehrdungspotential einteilen. Dann gibt es Richtlinien/Regularien, welche Klasse
in welcher Situation erlaubt ist und man kann beim Bau von entsprechenden Anlagen dann Massnahmen
oder Mechanismen einsetzen die zur Erreichung der geplanten Klasse dienlich sind (etwa Schutzvorrichten verbauen oder
Schutzkleidung vorschreiben).
Aehnliche Regelungen gibt es fuer alle moeglichen Arten von gesundheitlichen Gefahren, wie etwa im Brandschutz,
Laermbelastung, Luftverschmutzung, Arbeitszeiten und vielem mehr.

Die Art von Standards, um die es hier aber eigentlich geht, sind die Definitionen von Schnittstellen.
Sie stellen eine Art “passive Kommunikation” dar. Eine Schnittstellendefinition sagt mir, wie meine
Gegenseite in relevanten Punkten aussieht und zwar so, dass die genaue Implementierung nicht relevant
fuer meine Seite ist.
Ein greifbares Beispiel sind zum Beispiel metrische Gewinde (z.B. DIN ISO 1502:1996-12), ein M10er
Schraube wird immer in ein M10er Gewinde passen (solange beide innerhalb der Toleranzen sind), ohne,
dass sich der Hersteller der Schrauben und die Person, die das Gewinde bohrt, jemals persoenlich
absprechen muessten.
Diese Art von Standard gibt es, selbstverstaendlich, auch im Bereich der elektronischen Kommunikation oder Informationstechnik.
So sind etwa bei der IETF wichtige Protokolle standardisiert (IP, TCP, …) oder von der ITU die eher physikalischen
Schnittstellen normiert.

Diese Standards werden teilweise von mehr oder weniger offiziellen Stellen erstellt und betreut, teilweise von
von anderen Organisationen (etwa die Mediawiki-API von der Wikimedia-Gesellschaft, die Linux-API von der Linux Foundation oder
zahlreiche andere Projekte aus dem Bereich Open Source und der freien Software).
Dabei gibt es viele verschiedene Variante und Unterschiede, aber einer der wesentlichen ist, wie der Zugang zu dem
Standard geregelt ist. Waehrend etwa die RFCs frei und offen zugaenglich sind (also auch kostenfrei), sind DIN-Normen
zu erwerben, was ein gewisses Hindernis fuer Umsetzung darstellt.

Ein Standard erfordert natuerlich auch gewisse Zugestaendnisse, so ist etwa die Bereitstellung einer oeffentlichen
API bei einem Programm oder einem Dienst nicht wirklich nuetzlich, wenn sich diese API in kurzen Zeitraeumen
haeufig aendert. Das Erstellen von Drittanbietersoftware wird dadurch aufwaendiger und es erfordert haeufiger Updates
beim Benutzer. Eine Schnittstelle ist also auch ein zusaetzlicher Aufwand und eine Verantwortlichkeit gegenueber
Nutzern.
Dies hat natuerlich auch Nachteile, so koennen neue Features nicht leichtfertig eingebaut werden oder alte
Fehler nicht sofort oder auf beliebige Art und Weise behoben werden.
Ein Beispiel dafuer ist etwa Email, ein System, dass in einer anderen Zeit erdacht wurde und an vielen
Stellen Probleme hat. So waeren etwas Privatsphaere-foerdernde Verschluesselung, eine technisch
saubere und verifizierbare Signatur und andere Erweiterungen oder
Aenderungen durchaus technisch moeglich (moderne Messenger leben das ja teilweise vor), aber durch die Notwendigkeit
des Erhalts einer minimalen gemeinsamen Basis rottet das System auf einem Stand von vor fast 30 Jahren dahin.
Auf der positiven Seite kann man auch noch Mails schreiben indem man eine direkte Netzwerkverbindung zu einem
freundlichen Mailserver aufmacht (und schnell tippen kann).
Diese Problematik fuehrt teilweise zur Abkehr von offenen Standards, etwa beim Messenger “Signal”. Dort wird
auf ein zentralisiertes System gesetzt statt auf eine foerderiertes um den Stand aller
Teilnehmer einigermassen gleich zu halten und gleichzeitig neue Features implementieren zu koennen.

Der Punkt

Nach der langen Einleitung kommen wir nun endlich zum wirklichen Punkt des Artikels.
Im ersten Teil duerfte vermutlich das Wort App ins Auge gefallen sein.
Viele Dienste sind heutzutage mit einer eigenen App verbunden. Dies hat sich soweit
durchgesetzt, dass man bei irgendeinem neuen Dienst inzwischen sofort gefragt wird, was man
installieren muss.
Und dies oft ohne technische Notwendigkeit.

Man ist inzwischen daran gewoehnt, dass man sich fuer einen Dienst eine neue App installieren muss,
die dann froehlich das Addresbuch oder das Nutzungsverhalten irgendwo ins Internet laedt.
Daran ist man gewoehnt.
Der Hersteller der App jederzeit Einschraenkungen einfuehren, etwa Features entfernen, die Funktionalitaet
veraendern oder andere beliebige Masnahmen vornehmen.
So koennen etwa auch bestimmten Inhalte mehr oder weniger effektiv verboten werden.
Auch daran ist man gewoehnt.
Man ist nicht nur der Willkuerlichkeit ausgeliefert, es geht auch viel Potential verloren. So kann es innerhalb
einer Firma leicht zu einer gemeinsamen Perspektive kommen, die nicht unbedingt der der Nutzer entspricht.
Manchmal braucht es die Perspektive von Aussenstehenden um die Probleme zu identifizieren (und zu beheben).
Dies ist nicht moeglich, wenn sich Aussenstehende nicht mit den Moeglichkeiten auseinander setzen koennen
oder nicht duerfen.
Auch daran hat man sich mittlerweile gewoehnt.

Durch diese geschlossenen Oekosysteme entsteht auch gesamtgesellschaftlicher Schaden und neue Risiken.
So sind bereits einige Monopolisten entstanden, die man in bestimmten Bereichen fast nicht umgehen kann.
Ein Unternehmen oder eine Behoerde ohne Microsoft-Komponenten ist kaum denkbar, eine Kommunikation mit Menschen
ohne Whatsapp ist zumindest schwieriger.
Fuer viele proprietaere Softwareloesungen gibt es keine Dokumentation der Datenformate, so dass ein Wechsel
des Systems zwischen prohibitiv teuer und kaum moeglich rangiert.
Teilweise laesst sich auch ein altes System oder ein Teil davon nicht an ein Neues anbinden, weil keine Schnittstellen
existieren oder die vorhandenen nicht dokumentiert sind. Eine entsprechende Anekdote eine Systems, dass ausgemustert
werden musste, weil einige Teile davon veraltet waren, duerften die meisten inzwischen kennen.
Der entsprechende Mehraufwand schlaegt sich natuerlich in unnoetigen Kosten, Muell und verschwendeter Zeit nieder.
Auch aus dem Blickpunkt der Softwaresicherheit ist eine solche Monokultur durchaus bedenklich, wie die
Windows-Sicherheitsluecken der letzten Jahre gezeigt haben. Bei einer standardisierten Schnittstelle mit
verschiedenen Implementierungen gibt es zumindest eine gute Wahrscheinlichkeit, dass nur eine Implementierung
betroffen ist und damit der Schaden durch einen Angreifer reduziert wird.

Schluss

Meiner Meinung nach, brauchen wir fuer die Zukunft in unserer digitalen Welt wieder mehr
Standards (oder zumindest die staerkere Implementierung derselben) und mehr Fokus auf Protokolle, statt dem Fokus auf eine “App”.
Statt hunderte und tausende Male das gleiche neu und ein wenig anders zu implementieren und zwar meistens halbgar,
koennte festgelegt werden was da im Grunde passiert und es in Standards und Protokollbeschreibungen zusammenfassen.
Die Analyse und die Motivation fuer den Status Quo habe ich hier kaum bis gar nicht vorgenommen,
diese kommt vielleicht nochmal in einem weiteren Artikel, aber ich halte ihn, kurz gefasst, fuer ein Resultat
dieses Wirtschaftssystems.
In einer digitalen Welt, in der Konzerne auf eine Monopolstellung hinarbeiten und die meisten Gelder fuer
Konsumentensoftware und -dienste aus Werbeeinnahmen stammen, ist eine Verbesserung nicht so leicht denkbar.
Ganz allgemein ist ein Fokus auf Gewinnmaximierung vermutlich nicht die beste Zielsetzung aus Perspektive der
Softwareanwender.

Fuer die nachhaltigere, resilientere und vielfaeltigere Gesellschaft die fuer die Zukunft
gebraucht und teils gewollt wird, muss auch das digitale Oekosystem angepasst werden.
In dem jetzigen Zustand wirkt es eher unzureichend und zu stark auf Interessen Einzelner
fokussiert.

Ich habe versucht viel in diesen Text hineinzubringen, was vielleicht eher schlecht als recht dort
Platz gefunden hat. Ueber Kritik, Verbesserungen und vielleicht auch Gegenmeinungen wuerde ich mich
sehr freuen.
Fuer die Kuerze und die daraus folgenden Unvollstaendigkeiten moechte ich mich entschuldigen.

Wer sich fuer die hier angesprochenen Themengebiete interessiert, kann auch noch einen Blick auf folgende Themen werfen:

  • XMPP, ein vergleichsweise frueher Ansatz fuer einen sich fortentwickelnden Standard fuer allgemeine Chatdienste, nicht so haeufig zu sehen, aber vermutlich haben Sie es schon mal verwendet
  • Matrix, aehnlich zu XMPP aber juenger. Ebenfalls chatten in einem foerderierten Netzwerk
  • Fediverse, ein Ansatz fuer soziale Netzwerke, ebenfalls foerderiert, beinhaltet z.b. Mastodon (Microblogging wie Twitter), Peertube (Video-Plattform wie Youtube) und diverse andere Dienste und Protokolle
Lorenz Kästle
Lorenz Kästle
Consultant

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

Ansible – AWX|Tower State handling on Workflows

The Ansible Tower or its upstream AWX provides an easy to use GUI to handle Ansible tasks and schedules. Playbooks are configured as templates and as the name suggests, they can be modified to the needs, extended by variables, a survey or tags.

Furthermore those templates can be logically grouped, connected and visualised in Workflows.

The downside to those Workflows, all playbooks affected by this are executed separately and can’t access each others variables. On first glance we maybe only spot that we can define variables for the whole workflow but those are not changeable throughout the flow.

But there is a solution, which is the module set_stats. This module allows to save or accumulate variables and make them available for other playbooks within the workflow.

As an example we could use the monitoring environment when setting downtimes.

workflow

As a downtime is created before a maintenance and should be gone when the maintenance is done. This creates a dependency on the first task, which can be solved as we save the result of the first tasks with the set_stats module.


      - name: schedule downtimes
        icinga2_downtimes:
          state: "{{ downtime_icinga_state | default('present') }}"
          host: ***
          author: "{{ icinga2_downtimes_author | default('ansible_downtime') }}"
          comment: "{{ icinga2_downtimes_comment | default('Downtime scheduled by Ansible') }}"
          duration: "{{ icinga2_downtimes_duration | default(omit) }}"
        register: content
 
      - set_stats:
          data:
            downtime: "{{ content }}"

The content of the data will be now available to all playbooks included by the workflow. The variable is also shown as artefacts in the GUI.

artefacts

Keep in mind that the variable will be part of the extra variables for all other playbooks. As covered in the variable precedence it will overwrite any other variable named the same.

With this module you can reorganise your playbooks and connect them in workflows. This allows you to have a more flexible automation than before.

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening
Thilo Wening
Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.