pixel
Seite wählen

NETWAYS Blog

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.

Music Home-Recording unter Linux

Heute möchte ich ein Thema aufgreifen, das für alle diejenigen ist, die ein Instrument spielen und Musik machen. Meine Wenigkeit spielt E-Gitarre (Heavy Metal) und wie oft kommt es vor, man spielt mit dem Drumcomputer mit und plötzlich hat man eine super klasse Akkord-Folge (Riff-Folge) die man in Schleife spielt. Man denkt sich, Mensch die muss ich aufnehmen, aber wie?

Falls man sich mit der Thematik “Home-Recording” unter Linux noch nicht beschäftigt hat, steht man da jetzt wie der “Ochs vorm Berg”. Da das Thema riesengroß ist, werde ich nur etwas den Einstieg beleuchten, wie ABNAHME, LATENZ, SOFTWARE.

Abnahme Instrument

Hiermit ist gemeint, wie ich das Instrument z.B. E-Gitarre mit meinen Computer verbinde und was brauche ich dazu. Am einfachsten man besorgt sich ein sogenanntes Audio-USB-Interface, das normalerweise Eingänge für Klinkenstecker oder Mikrofon hat, um das Instrument anzuschließen. Der Vorteil von dem Interface ist, das man das Eingangssignal einstellen (auspegeln) kann und je nach Ausstattung einen Kopfhörer-Ausgang beziehungsweise weitere Features hat. Ich kann für Linux-User folgendes Interface empfehlen, welches ich auch verwende: Behringer U-Phoria UMC204HD. Dieses Gerät wird per USB an den Computer angeschlossen und sollte vom Linux-Kernel erkannt werden.

Bei Instrumenten die nicht per Kabel direkt ans Interface angesteckt werden können, müssen per Mikrofon abgenommen und das ans Interface angeschlossen werden z.B. Saxophon.

Früher hatte ich auch Verstärker-Preamp-Out direkt mit dem Mic-Eingang der Soundkarte verbunden, was aber nicht sehr flexibel ist, da ich das Eingangsignal immer im Computer anpassen musste und man eine gute Soundkarte braucht, die speziell für Audio-Aufnahmen sein sollte, was diese nicht war.

Bei mir:

  • Audio-USB-Interface via USB am Computer
  • Preamp-Out Verstärker per Klinken-Kabel mit dem Eingang Audio-USB-Interface verbunden
  • Alternative E-Gitarre direkt ins Audio-USB-Interface und auf Instrument schalten sonst ist es Line-In.

Latenz

Um es simpel zu beschreiben, ist die Verzögerungszeit vom praktisch gespielten Ton (Instrument) bis zum hörbaren Ton aus dem Computer-Lautsprecher. Der Computer muß das In -und Output-Signal verarbeiten und das am besten in Realtime. Dafür braucht man unter Linux einen Realtime-Kernel, der bei manchen Linux-Distributionen (z.B. openSUSE-Leap, Ubuntu-Studio) bereits als RT-Kernel Paket zum installieren in den Repositories vorhanden ist. Was auch noch wichtig ist, das die Desktop-Oberfläche schlank ist und nicht wertvollen Arbeitsspeicher im Betrieb verbraucht (z.B. XFCE, LXDE, Enlightenment)

Diese Latenz lässt sich mit der Software JACK (JACK Audio Connection Kit) einstellen um das gewünschte Ergebnis zur erhalten, dazu könnte man schon alleine einen Blogbeitrag füllen. Die Standard-Einstellung sollte für die ersten Versuche ausreichend sein.

Software

Mittlerweile gibt es einiges an Open Source Software unter Linux, die auch von diversen Distributionen über Repositories installiert werden kann, hier mal eine kleine Auswahl:

Für Einsteiger würde ich die ALL-in-One Lösung Qtractor wählen, da diese einfacher und verständlicher zu bedienen ist, JACK braucht jeder um die Eingänge und Ausgänge zu steuern. Wer jetzt schon mit MIDI herum experimentiert, kann sich Rosegarden anschauen, Nachteil Audiospuren editieren, hier muss eine passende Software in den Einstellungen wie z.B.  Audacity mit verknüpft werden.

Je nachdem was man jetzt für eine Software zum Recording verwendet, braucht man eine gewisse Zeit bis man sich in diese eingearbeitet hat und da gehen schon Stunden ins Land. Deswegen würde ich jetzt nicht ins Detail gehen das würde hier den Rahmen sprengen, aber im Netz findet man jede Menge HowTo’s zu der jeweiligen Software, die die tiefere Anwendung beschreiben.

So jetzt wünsche ich jedem viel Erfolg bei seiner ersten Aufnahme und falls diese Schrott wird, keine Bange ich weiß schon gar nicht mehr wie viel Schrott ich am Anfang produziert habe, hier gilt die Devise, einfach weitermachen, es ist noch kein Meister vom Himmel gefallen.:-)

Johannes Carraro
Johannes Carraro
Senior Systems 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.

Neues von den Influxdays EMEA 2021

Auf den influxdays kündigt Paul Dix, CTO von InfluxData, einen neuen Core names iOx für influxDB an. Dieser Schritt löst spontan Unsicherheit aus. Hier ein paar Fakten um die Gemüter zu beruhigen:

InfluxDB 2.x Open Source wird, so wie es jetzt existiert, parallel mit regelmäßigen Point-Releases weiterentwickelt.
InfluxDB IOx wird SQL, InfluxQL und Flux unterstützen.
InfluxDB IOx wird in einem zukünftigen Release ein optionales Speicher-Backend für InfluxDB werden.
Die Implementierung durch Rust und Apache Arrow soll eine höhere Sicherheit erreichen. Auf Grund verschiedener Optimierungen am Speicherverhalten soll die Datenmenge verringert und gleichzeitig die Abfragegeschwindigkeit erhöht werden.
InfluxDB Enterprise-Kunden werden in der zweiten Hälfte des Jahres 2021 über eine kommerziell unterstützte Version von InfluxDB IOx und InfluxDB Enterprise verfügen.

Das war nicht das einzige Thema auf der online abgehaltenen Konferenz.
In dem ausgewogenen Programm konnte man sich anschauen, wie man mittels Telegraf Daten in Richtung influxDB schreibt. In einem anderen Vortrag ging es um Dashboards, Alerts und Tasks.

Ein Highlight war für mich der Talk von Aengus Rooney, der zwar trotz des Titels “What’s New with Grafana and InfluxDB” erstaunlich wenig Neuerungen gezeigt hat, jedoch mit einem längeren Hands-On die Möglichkeiten von Grafana anhand eines selbst erstellten Handels Terminals für Kraken/Bitcoin demonstriert hat.

Alle Aufzeichnungen der Konferenz werden ab 31. Mai veröffentlicht. Man findet sie, wie auch die Videos vergangener Konferenzen, auf den Seiten der influxdays und auf youtube.

Wer mehr über influx und die Möglichkeiten erfahren möchte kann sich auch bei NETWAYS im Rahmen eines zweitägigen Trainings informieren.

Christoph Niemann
Christoph Niemann
Senior Consultant

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.

Einsamkeit im Home Office. Ein Ansatz dagegen

“Man kann keine sozialen Probleme mit technischen Mitteln lösen” hört man manchmal. Naja, als IT-Nerds können wir’s wenigstens mal versuchen. Ich werd’ Dir jetzt nicht erzählen, dass wir gerade mitten in einer Pandemie stecken und man sich am besten von anderen Menschen fernhält. Falls Du das nicht glaubst, bist Du hier eh falsch. Da NETWAYS die Lage ernst nimmt und möglichst umfassendes Home Office ermöglicht bzw. fördert, sitzen viele von uns jetzt noch mehr zu Hause als sonst auch schon. Schon recht bald haben wir akzeptiert, dass das noch länger so bleiben wird und die Einsamkeit im Home Office uns einholen wird. Also haben wir begonnen, nach Lösungen zu suchen.

Eine kurze Vorgeschichte

Dass die NETWAYS Family großen Wert auf Zusammenhalt legt, sollte allen, die uns kennen klar sein. Deshalb gibt’s auch regelmäßig die “Startup-Days”. Davon wurde hier schon berichtet, deshalb nur die Kurzfassung: Alle können Vorschläge für Projekte einreichen und aus der ganzen Gruppe finden sich Teams zusammen, die daran arbeiten. So ergibt es sich, dass man mal mit Leuten gemeinsam eine Aufgabe angehen kann, mit denen man sonst nur selten Berührung hat. Ganz nebenbei fallen dabei auch immer einige Projekte raus, die weiterverfolgt werden und unser aller Leben bereichern

Aus gegebenem Anlass hab’ ich dann vorgeschlagen, wir könnten doch nach Ansätzen suchen, um die Einsamkeit im Home Office möglichst zu minimieren. Dabei ist der Begriff “Einsamkeit” so weit wie möglich gefasst. Damit ist nicht nur gemeint, dass man all jenen hilft, die alleine wohnen und so gar niemand zum Unterhalten außerhalb vom Job haben. Auch einfach um zu verhindern, dass man die anderen lieben Leute von NETWAYS zu sehr vermisst oder neu hinzu Gekommenen den Einstieg zu erleichtern, sollte die Lösung beitragen.

Außerhalb von Pandemie-Zeiten gab’s am Montag immer ein umfassendes Standup, bei dem alle sich im Kreis aufgestellt und der Reihe nach einen kurzen Überblick über die Pläne für die aktuelle Woche gegeben haben. Weil unser Bernd ein optimistischer Mensch ist, hat er den Termin auch gleich mal im Kalender von allen gelassen – nur wurde der eben nicht mehr wahrgenommen. Der Termin, nicht der Bernd.

Arbeitsgruppe gegen Einsamkeit im Home Office

Der Vorschlag, da etwas zu unternehmen, fand einigen Anklang und bald war auch eine kleine Gruppe beisammen, um sich auf die Suche nach der Lösung zu machen. Wie’s so ist mit weltumfassenden Problemen, dafür braucht sogar ein Spezialist:innenteam der NETWAYS mehr als 2 Tage, weshalb wir die Ziele bald mal etwas reduziert haben. Nach einem umfassenden Gehirnstürmen haben wir uns entschieden, erstmal mit einem Chatbot für unseren Rocket.Chat anzufangen, der die Einsamkeit im Home Office bekämpfen soll. Chatbot – echt jetzt? Ja, Chatbot.

Warum jetzt echt ein Chatbot? Weil wir etwas ausnutzen wollten, das man häufig erlebt, wenn gute Menschen unter Belastung stehen: Alle wissen, dass es Dinge gibt, die man tun könnte, die helfen könnten, viele planen, sie auch umzusetzen und fast alle sind dann doch zu eingespannt oder zu erschöpft um neben Arbeit und Alltag auch noch Gutes für sich und andere zu tun. Wenn aber jemand kommt und diese Menschen anstubst, dann raffen sich doch einige auf und gehen’s an. Es wird immer die geben, die sagen “Jo, eh” und es dann einfach lassen, aber das muss auch mal ok sein. Das Ziel war nicht, alle zu etwas zu zwingen, sondern einfach das bisserl mehr Antrieb zu liefern, um es dann doch mal anzugehen.

Eine der ersten Funktionen des Chatbot war dann auch, in zufälligen Abständen zufällige Menschen in der Firma anzuschreiben und einen Vorschlag für eine gute Tat gegen Einsamkeit im Home Office zu unterbreiten. Explizit ohne Auswertung, ohne Fingerzeigen, ohne Zwang. Wer kann, macht, wer nicht, schafft’s vielleicht beim nächsten Mal. Das können so Dinge sein wie “Schlag doch mal ein kleines soziales Projekt vor” (Yeah, Singularität in sozialen Projekten), “Schreib eine handschriftliche Grußkarte an $KOLLEG”, “Frag doch mal $KOLLEG wie’s gerade so läuft”. Um es kurz zu machen: Diese Funktionalität ist aktuell nicht aktiv. Aktuell wird nämlich eine andere verfeinert. Dazu gleich mehr.

Standup für alle aber nur mit wenigen

Was tun wir jetzt konkret? Der Chatbot generiert zu dem Zeitpunkt, an dem üblicherweise das NETWAYS weite Standup stattfindet einige Meetingräume im Jitsi, würfelt dann genau so viele Gruppen von Leuten zusammen und schickt allen den jeweiligen Link. So sind immer ein paar Leute gemeinsam in einer Jitsi-Session. Egal aus welchem Bereich von NETWAYS (oder Icinga). Da es immer nur eine handvoll Menschen sind, bleibt für alle genug Zeit, mal ein bissl was zu erzählen. So sieht man sich wieder, kann mal ein paar Worte wechseln und verliert sich nicht ganz aus den Augen.

Um den Vorschlag von vorhin wieder aufzugreifen schickt der Bot manchmal einzelnen Teilnehmer:innen einen Vorschlag mit, worüber man reden könnte. z.B. “Erzähl von dem, was Du diese Woche vorhast” oder “Schlag ein kleines soziales Projekt vor”.

Wo viele Menschen zusammenkommen, menschelt’s und was zu erwarten war, ist gleich mal eingetreten. Die ersten waren zu beschäftigt oder was auch immer, um sich vom Chatbot ablenken zu lassen. Deshalb wurde auch gleich mal eine Blockliste eingeführt, auf dass manche nicht mehr behelligt werden. Der Bernd in seiner Weisheit weiß allerdings, dass es manchmal doch möglich und nötig ist, jemandem zum Glück zu zwingen und hat die wieder entfernen lassen. (Die Blocklist, um Missverständnissen vorzubeugen) In der Zwischenzeit hört man nix negatives mehr und ich geh mal davon aus, dass jetzt alle doch ganz froh sind, dass sie mal wieder mit den anderen Kontakt haben. Ok, als der Bot die Zeitumstellung verpennt hat, gab’s ein paar Sticheleien. Aber hey, so merkt man wenigstens, dass alle schon drauf warten, in die Standup-Runde eingeladen zu werden, um etwas weniger Einsamkeit im Home Office zu erleben.

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

ZFS Cheat Sheet

Wenn man sich mit einem eigenen Linux Storage Servers beschäftigt hat man sicher schon davon gehört: ZFS. Ich beschäftige mich schon seit längerem mit ZFS und bin an einem Punkt an dem ich mir die Menge der Kommandos nicht mehr merken kann. Zu ZFS findet man zwar schon sehr viel im Internet, die Themen Snapshots oder verschlüsselte ZFS-Datasets fehlt aber leider meistens oder die Informationen sind nicht gesammelt an einer Stelle zu finden. Damit ich in Zukunft nicht immer suchen muss und Ihr auch etwas davon habt, schreibe ich hier alles zusammen.

Installation von ZFS unter Debian / Ubuntu
Die Installation wurde unter Debian 10 (Buster) und Ubuntu Server 20.10 (Groovy Gorilla) durchgeführt. Das Einbinden des Backports Repos ist für Ubuntu Server 20.10 nicht notwendig.
# apt-get update
# apt-get upgrade

# vi /etc/apt/sources.list.d/buster-backports.list
deb http://deb.debian.org/debian buster-backports main contrib
deb-src http://deb.debian.org/debian buster-backports main contrib

# vi /etc/apt/preferences.d/90_zfs
Package: libnvpair1linux libuutil1linux libzfs2linux libzpool2linux spl-dkms zfs-dkms zfs-test zfsutils-linux zfsutils-linux-dev zfs-zed
Pin: release n=buster-backports
Pin-Priority: 990

# apt-get update
# apt-get upgrade

--> Reboot (falls es ein Kernelupgrade gab)

# apt install dpkg-dev linux-headers-$(uname -r) linux-image-amd64
# apt install zfs-dkms zfsutils-linux

Erstellen eines einfachen ZFS Storage Pools
Mit folgendem Kommando wird ein ZFS Storage Pool namens “data” erstellt. Dank “raidz1” wird eine Redundanz aufgebaut und eine Festplatte kann ohne Probleme ausfallen. Es ist unter anderem auch möglich “raidz2” oder “raidz3” zu definieren.
# zpool create data raidz1 sdb sdc sdd
# zpool status

Erstellen eines ZFS Storage Pools mit Partition UUIDs
# ls -la /dev/disk/by-partuuid/
# zpool create data raidz1 00b85ce9-a0d5-9340-b347-cd0bcc714dc0 04c20b90-5678-4b88-af49-21db76427eda 0c35cb57-5bc6-7c49-929f-466102c22d05

Erstellen eines ZFS Datasets
# zfs create data/playground

Erstellen eines verschlüsselten ZFS Datasets
# zfs create -o encryption=aes-256-gcm -o keyformat=passphrase data/playground
# zfs get encryption

Erstellen eines ZFS Snapshots
# zfs snapshot data/playground@`date +%Y-%m-%d_%H-%M-%S`

Löschen eines ZFS Snapshots:
# zfs destroy data/playground@2020-09-12_17-25-42

Durchsuchen von Snapshots (z. B. zum Restore einzelner Daten)
# cd /data/playground/.zfs/snapshot/2020-09-12_17-25-42
# ls -la

Hinzufügen eines SSD-Caches
Erzeugen des Dateisystems auf der Partition:
# zpool create -f log  /dev/sde1
# zpool create -f cache  /dev/sde2

Löschen des Dateisystems:
# zpool destroy log1
# zpool destroy cache1

Hinzufügen von Cache und Log zum ZFS Pool:
# zpool add data log /dev/sde1
# zpool add data cache /dev/sde2

Vorsicht: In diesem Beispiel ist der Cache nicht gespiegelt / abgesichert! Beim Ausfall der SSD wären die Daten im Cache verloren!

Anzeigen der Speicherbelegung über den ganzen ZFS Pool inkl. Snapshots
# zpool set listsnapshots=on data
# zfs list -o space -r data

Tobias Redel
Tobias Redel
Head of Professional Services

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.