NETWAYS Blog

OSMC 2021 | Recap Day 3

von Lorenz Kästle | Nov 11, 2021 | OSMC

The third and last day of the OSMC 2021 concludes the event for the year and, appropriatly, it is rather calm. Where the other days were full of talks, today only two events took place. Due to the smaller number of participants these take place in the NETWAYS / Icinga office space and bring back some life to rooms, which were rather empty in the last year.

Hackathon

In the container ecosystem, Kubernetes is an important player and worth taking a look at. Deploying, scaling and maintaining large systems is never an easy task and this is true for container-based environments, too. While Kubernetes may provide the tools and possibilites, it is a complex tool and must be administrated with care and knowledge. Often the time, the space or the helpful tutor is lacking, when one wants to experiment with a new „thing“ and, for this reason, the OSMC Hackathon provides all of the aforementioned circumstances.

The participants can just get accustomed to the Kubernetes environment, try a small example application under helpful supervision or try to apply some freshly learned knowledge, gained at the conference, to this environment. In my experience the first and one of the biggest hurdle for a new tool/language/environment is to get accustomed to wording, the semantics of all the specific terms. While the underlying technologies are often similar to a certain degree, often each project is its own world. Trying to get accustomed to to a new world without a stepping stone to help one to map unknown parts to a known equivalend and understand the intersections and purpose of the component is a huge and difficult task. In the OSMC Hackathon Sebastian Saemann, Head of NETWAYS Web Services and Kubernetes expert, helped with getting into that system easier, explained the basics and the common pitfalls.

Different groups chose different paths to use this time. One group decided to setup a small container environment which hosts GitLab as an application, with the usual components, proxy, load balancer, storage and CI runners. The setup in itself might not surprise or astonish Kubernetes veterans. But the for the beginner, it is difficult to interact with the environment. For example just connecting directly to a single container requires one to know the proper commands. The Kubernets setup does add a lot of complexity to setup initially, but it might pay off, if the application need be scaled up for higher loads/more traffic. Another group worked on integrating Jaeger in a Kubernetes setup with a simple web application. Inspired was this scenario probably by some of the talks on the conference, especially this one.

Workshop

The OSMC Workshop centered around a, in comparison to the previous topic, rather convential theme: the integration of a directory with user data, which speaks LDAP, (for most people: Windows AD) into the Icinga ecosystem. If you are the lonely admin watching over the monitoring, creating credentials for yourself might be enough (is the login name ‚icingaadmin‘? ;-)). But maybe your colleagues want to have a look at that fancy interfaces too, to see if their machines are still running. While this might be all good and proper, some of them might get the idea to try their luck with the Director and might, completely by accident of course, delete some of the services, change some intervalls or ruin the proper order of things in one way or the other. So, roles need to be created, permissions applied and users mapped to some groups, to preserve the integrity of the system.

Instead of taking the hard way to their destination, with all the pitfalls and easily made errors, the participants were here in the heartful care of NETWAYS Senior Consultant and Icinga expert Lennart Betz, who happily provided them with the knowledge from his rich experience in the Icinga environment.

Goodbye

For me, it was a really nice event and I hope that this was also true for the other participants. The OSMC might be over for this year and until we can hopefully meet up again next year, we wish you all a safe passage homeward and stay warm and healthy.

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.

Lies mehr von Lorenz und triff unser Team

OSMC 2021 | Recap Day 1

von Lorenz Kästle | Nov 9, 2021 | OSMC

It’s time for OSMC again and contrary to recent event experiences, it is in presence with real people! And it is nice for a change! A full program offers much input to the visitors and showcases the things people created or changed since the last OSMC. After the cordial greeting by Bernd, the talks started. A small selection of these I will mention here.

On the bleeding edge of…

„On the bleeding edge of Open Telemetry“ was the topic of Philipp Krenns talk. The growing complexity of current application deployments and the resulting difficulties in detecting and analysing errors in distributed systems are a growing problem for developers and conventional methods are reaching their boundaries. A request/action/… that passes through such a system might result in an error at one stage, but the cause might lie at an earlier stage and without that context from the earlier stage, it might be very hard to find the actual cause.

To provide this context is the obvious idea, but not one which is easy to realize. Messages have to be „tagged“, logged and the resulting data put togehter. This presents a lot of problems, components must be able to work with those messages while keeping the context together. Tracing produces a lot of overhead, so it should probably only be done with samples, which causes the next problem of finding a representative sample. Of course several systems/software pieces were built to provide this functionality and, of course, they won’t talk to each other. In the best tradition of this XKCD comic the solution should be a unifying open standard to make it possible for different systems to interact in the task of tracing. Several implementations of OTel (Open Telemetry) in different languages exist to this date and should allow integration in other applications.

At the end of the presentation Philipp provided a live demonstration of tracing in a demo system with the Elastic Stack with nice graphes and a lot of information about single queries with all the context added by the different parts of the system.

Marius Oehler deepened the topic then with a talk about „inspectIT Ocelot: Dynamic OpenTelemetry Instrumentation at Runtime“ where the specific task of generating telemetry data in Java applications was further investigated. Especially interesting is the approach, which requires none or minimal changes to the code of the application itself.

On contributions and databases

Our very own Feu Mourek gave a helpful overview about contributing to free and open software projects with „Contributing to Open Source with the example of Icinga„, hopefully inspiring people to give something back.

For all the people who suffer performance problems with their databases Peter Zaitsev showed a way to analyse the setup, the queries and several metrics from database setups. Very detailed and heavily customized Grafana dashboards and a monitoring agent to collect and process the interesting data points allow detailed and meaningful insights into the processes, only complete with powerful filters to find the needles in the haystack of a massive amount of data. If one is interested in optimizing the database setup it could be worth investigating the tools of Percona.

Gamification of observability

Bram Vogelaar did not only talk a little bit about his story down the rabbit hole of overengineering his personal website (he reaches Docker in the first half!), but also shared his thoughts about the profession of the monitoring admin itself in „Gamification of Observability„. Compared to other professions (doctors, fireman and plane pilots) the IT world commonly lacks the structured approach that those professions have developed. For most operations people, there is no training for disasters and the recovery process, no analytical, structured approach to problems and no checklists to avoid human failures caused by repetitive and boring tasks. While many people might agree with this criticism and might be willing to implement such approaches and develop these technics, he sadly forgot to mention where administrators should find the time and personel. 🙂

The last presentation of the day was Bernd’s talk about the „Current State of Icinga„. He talked about new features, planned releases, upcoming events and the new Icinga brand. He presented the changes directly in an almost frictionless live demo.

This is only a small representation of the first day and it should by no means give the impression, that the other talks might be less significant or interesting. For me today there is neither the time nor the space here to fully reflect on all of them, so we might leave it at that. Watch them in our archives, coming soon after the conference!

Lorenz Kästle

Consultant

Lies mehr von Lorenz und triff unser Team

Standards vs. Apps

von Lorenz Kästle | Jul 8, 2021 | NETWAYS, Technology, Soziales, Design

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

Consultant

Lies mehr von Lorenz und triff unser Team

Administrators Toolbox: Die Zsh

von Lorenz Kästle | Feb 5, 2021 | Linux, Technology

Einfuehrung

Zu jeder stereotypischen Hacking-Szene in einem Film oder einer Serie gehoert das Terminal in dem kryptische Ausdruecke, Befehle oder Programmcode ueber den Bildschirm huschen. Je nach Ausfuehrung ist das unterschiedlich laecherlich, aber nichtsdestotrotz ist das Terminal seit seiner Einfuehrung als Nutzerinterface eine der wichtigsten Schnittstellen zwischen Mensch und Maschine geblieben. Entstanden aus dem Wunsch und der Notwendigkeit mit einem Programm zur Laufzeit zu interagieren, war es ein langer Weg von den umfunktionierten elektrischen Schreibmaschinen (Teletype) ueber 80×25 Zeichen Monochrom-Roehrenmonitore (wahlweise in gruen oder orange) bis hin zu einem Terminal-Emulator als ein weiteres Fenster in der graphischen Oberflaeche.

Dialogisch mit dem System zu interagieren und mit vergleichsweise kleinen Anforderungen beliebig komplexe Prozesse anzustossen eroeffnen einem viele Moeglichkeiten und, nach Meinung des Autors, sind in vielen Anwendungen noch keine Alternativen in Sicht, die es besser machen wuerden. Mit Text als menschenverstaendliche Schnittstelle dient dienen Shell als eine Abstraktionshuelle fuer das Betriebssystem und andere Anwendungen, die einem zumindest auf Unix-aehnlichen Systemen noch sehr haeufig begegnet.

Der haeufig anzutreffende Platzhirsch in dem Feld der Shells ist die bash, die Bourne again shell, zumindest auf vielen gaengigen Linux-Distributionen und ist als solides und maechtiges Werkzeug bekannt. An manchen Stellen lassen sich jedoch ein paar Schwaechen finden und manchmal ein gewisser Komfort vermissen, gerade bei der Interaktion mit dem eigenen Desktop-System, deshalb wird hier eine Alternative thematisiert, die Z shell (kurz zsh). Die Geschichte, der Code und tiefere technische Details sollen hier nicht im Zentrum stehen, eher die konkrete Nutzung und einzelne Features.

Installation

Wie die Installation auf dem jeweiligen System verlaeuft haeng natuerlich von der Umgebung ab, auf Linux duerfte der jeweilige Packetmanager diesem Zweck dienen, hier reicht ein apt-get install zsh, aber your mileage may vary. Im Zweifelsfall kann man die entsprechenden Dateien auf der offiziellen Seite finden.

Konfiguration

Der wichtigste Teil an der Benutzung der zsh duerfte die Konfiguration sein, da sich eine Unmenge von Parametern veraendern lassen und viele der Features aktiviert/konfiguriert werden muessen. Fuer die Ungeduldigen gibt es eine Beispielkonfiguration, die im Folgenden Schritt fuer Schritt nachvollzogen wird. Ansonsten kann die zsh auch ohne Konfiguration gestartet werden, sie wird den Benutzer auf diesen Fakt hinweisen und Empfehlungen bezueglich des weiteren Vorgehens liefern. Auch liefern Distribution typischerweise eine Basiskonfiguration mit und die Suchmaschine der persoenlichen Wahl duerfte schnell ein Vielzahl von weiteren Beispielen und Anleitungen bieten. Am Ende dieses Beitrags sind auch noch einige Links als Startpunkt beigefuegt. Natuerlich sind auch die man-pages ein sinnvoller Anlaufpunkt.

Keybindings/Tastenkombination

# Use Vi(m) style key bindings. bindkey -v

Die ist eine sehr minimale Konfiguration und weist die zsh an, vim-artige Tastenkombination zu verwenden. Dies ist eher minimal, Aktionen zur Navigation innerhalb der Eingabezeile und vieles mehr koennten hier konfiguriert werden.

Prompt

Die Prompt (also der Text, der vor jeder Eingabezeile steht) kann gut zur Darstellung von nuetzlichen Informationen genuetzt werden oder sollte mindestens huebsch sein.

[[ "$COLORTERM" == (24bit|truecolor) || "${terminfo[colors]}" -eq '16777216' ]] || zmodload zsh/nearcolor autoload -Uz colors && colors
Zuerst wird versucht die Faehigkeiten des Terminal bezueglich der Darstellung von Farben zu bestimmen und die entsprechenden Module geladen

autoload -Uz promptsubst autoload -Uz promptinit && promptinit autoload -Uz vcs_info

Einige weitere Module, die die Personalisierung der Prompt ermoeglichen.

# Define the theme prompt_mytheme_setup() { local user if [[ $USER == "root" ]] then user="%F{9}%n" else user="%F{12}%n" fi if [[ ! -z $SSH_CLIENT ]] then user="%F{3}SSH -> $user" fi
Hier wird ein eigenes Theme begonnen, dass einen normalen Nutzer in einer Farbe darstellt und den Nutzer „root“ in einer anderen.
Zusaetzlich wird angezeigt, ob man ueber SSH verbunden ist.

# Information about version control systems zstyle ':vcs_info:*' enable git zstyle ':vcs_info:*' check-for-changes yes zstyle ':vcs_info:*' use-prompt-escapes yes zstyle ':vcs_info:*' formats "%s - (%r|%b)" "%u%c" local prefix="%(?..[%?%1v] )" local vcs="%(2v.%U%2v%u.)" PROMPT="%K{0}%F{9}$prefix%f%B$user@%M%f %F{7}%/%b%f%k %B#%b %E" RPROMPT="%K{0}%F{9}$vcs%f%k" add-zsh-hook precmd prompt_mytheme_precmd }
Die Prompt wird zusammengesetzt und um Information ueber git-Repositories ergaenzt, falls das aktuelle Arbeitsverzeichnis sich in einem solchen befindet.

prompt_mytheme_precmd () { setopt noxtrace noksharrays localoptions local exitstatus=$? local git_dir git_ref psvar=() [[ $exitstatus -ge 128 ]] && psvar[1]=" $signals[$exitstatus-127]" || psvar[1]="" vcs_info [[ -n $vcs_info_msg_0_ ]] && psvar[2]="$vcs_info_msg_0_" }
Vor jeder Promptdarstellung wird der EXITSTATUS des vorherigen Programms ueberprueft und angezeigt, falls dieser !=0 (Fehler) ist.

# Add the theme to promptsys prompt_themes+=( mytheme ) # Load the theme prompt mytheme
Die Prompt wird geladen.

Noch einige Optionen

setopt nobeep
Deaktiviere die Terminal-„Glocke“.

setopt autocd
Die Eingabe eines Verzeichnisnamens wird als „cd $VERZEICHNIS“ interpretiert.

# Prevent overwriting existing files with '> filename', use '>| filename' # (or >!) instead. setopt noclobber
Verhindere versehentliches Ueberschreiben von Dateien durch Redirection.

# Enable zsh's extended glob abilities. setopt extendedglob
Erweitertes globbing.

setopt longlistjobs
Bei der Ausgabe von jobs wird die PID mit angezeigt

Autovervollstaendigung

## Initialize completion autoload -Uz compinit && compinit

# Automatically list choices on an ambiguous completion. setopt autolist ## show list of tab-completing options zstyle ':completion:*:default' list-prompt '%p' ## cache completion for re-use (path must exist) zstyle ':completion:*' use-cache yes; zstyle ':completion:*' cache-path ## _complete -> completiong ## _expand -> expand variables ## _prefix -> ignore everything behind cursor ## _approximate -> fuzzy completion ## _ignore -> ignore some matches (i.e. directories when doing cd) zstyle ':completion:::::' completer _expand _complete _prefix _ignored _approximate ## one wrong character every X characters is corrected ## X = 5 is a reasonable default zstyle -e ':completion:*:approximate:*' max-errors 'reply=( $(( ($#PREFIX + $#SUFFIX) / 5 )) )' ## correct lowercase to uppercase zstyle ':completion:*:(^approximate):*' matcher-list 'm:{a-z}={A-Z}' # Kleinschreibung automatisch zu Grossschreibung korrigieren. ## keep magic prefixes like '~' when expanding zstyle ':completion:*:expand:*' keep-prefix yes ## compelte a/b/c zu abc/bcd/coo zstyle ':completion:*' list-suffixes yes ## colors in completion menu ## zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS} # allow autocomplete-navigation with arrowkeys zstyle ':completion:*' menu select #enable a menu which can be browsed with arrow keys # tab completion after pressing tab once (default is twice) setopt nolistambiguous # allow in word completion setopt completeinword

Diverse Einstellungen zur Autovervollstaendigung, unter anderem die Darstellung der validen Optionen und Vervollstaendigung in Woertern.

History/Geschichte

Gerade bei der Historie ist der Nutzen der zsh am deutlichsten, so koennen Befehle ohne grosse Umwege direkt nach Eingabe in die Historie geschrieben werden, ohne dass grosse Umwege beschrieben werden wie es bei der bash normalerweise noetig waeren.

# write command to historyfile imediatelly setopt appendhistory setopt incappendhistory ## max size and location of history-savefile STSIZE=20000 SAVEHIST=20000 if [[ ! -a ~/logs ]] { mkdir ~/logs } HISTFILE=~/logs/zshhistory.log ## no duplicated commands setopt histignoredups ## no emptylines setopt histignorespace # Fancy search for history. Install peco if ! [ -x "$(command -v peco)" ]; then bindkey '^R' history-incremental-pattern-search-backward else ## bind peco to ctrl-R as a better reverse search than the buitin if it is available reverse_search(){print -z "$(tac ${HISTFILE} | peco)"} zle -N rs_peco reverse_search bindkey "^R" rs_peco PECO=/usr/bin/ fi

Zusaetzlich wird hier das Programm peco fuer die Suche in der Historie verwendet (falls vorhanden). Dies stellt die passenden Eintraege sehr schnell und sichbar dar.

Gemischtes

umask 077
Stellt die umask sehr restriktiv ein. Dateien muessen dann erst fuer andere lesbar gemacht werden.

LS_COLORS=$LS_COLORS:'di=0;35:'; export LS_COLORS
Farbschemata fuer ls.

if [[ -f ~/.config/zsh/aliases ]]; then source ~/.config/zsh/aliases fi
Lese Aliase aus der Datei ~/.config/zsh/aliases, falls vorhanden.

export EDITOR=nvim
Setze neovim als Standart-Editor fuer die Umgebung.

if [[ -d ~/scripts ]] { export PATH=$PATH:~/scripts }
In ~/scripts sind selbst erstellte Skripte des Nutzers und werden hiermit direkt nutzbar.

man() { env \ LESS_TERMCAP_mb=$(printf "\e[1;31m") \ LESS_TERMCAP_md=$(printf "\e[1;31m") \ LESS_TERMCAP_me=$(printf "\e[0m") \ LESS_TERMCAP_se=$(printf "\e[0m") \ LESS_TERMCAP_so=$(printf "\e[1;44;33m") \ LESS_TERMCAP_ue=$(printf "\e[0m") \ LESS_TERMCAP_us=$(printf "\e[1;32m") \ man "$@" }
Dies faerbt man-pages ein und macht sie dadurch leichter lesbar.

Aliase

Aliase sind frei konfigurierbare „Pseudokommandos“ die durch die zsh ausgewertet und durch die richtigen Kommandos ersetzt werden. Dies bietet sich meistens fuer haeufig gebrauchtet Kommandos an.
alias ll="ls -llh --color=auto" ist ein gutes (und haeufiges) Beispiel dafuer.
Damit kann die detailierte Ansicht von ls direkt und ohne Tippen der Optionen benutzt werden. Beispiele fuer nuetzliche Aliases sind vielerlei zu finden, aber ein guter Ansatz ist immer die Frage, welche Kommands haeufig benoetigt werden und die daher sinnvoll abgehkuerzt werden koennten.

Fuer Tippfaule bietet es sich an, haeufige Befehle stark abzukuerzen, etwa alias v="vim" oder alias g="git".

Noch mehr „Features“

zsh kann nativ sockets und TCP-Verbindung oeffnen, man kann also ohne weiteres (simple) Netzwerkkommunikation damit (warum auch immer) (zsocket bzw. ztcp)
Auch FTP ist nativ vorhanden, falls man nur kurz einen FTP-Client braucht (zftp)
Auch eingebauter Kalender ist ist vorhanden (cal)

Abschluss und Weiterfuehrendes

Alles hier ist nur ein kleiner Einblick in die Moeglichkeiten und Konfigurationen und erhebt auf keinen Fall einen Anspruch auf Vollstaendigkeit. Falls weitergehendes Interesse besteht, sind noch ein paar Links angehaengt, die mindestsens mal als Einstieg dienen. Natuerlich sind Korrekturen und Vorschlaege hier erwuenscht und koennen gerne in den Kommentaren oder auf anderem Weg uebermittelt werden. Damit bleibt fuers Erste nur noch der Leserin Spass beim Experimentieren zu wuenschen und vielen engagierten Bastlern zu danken, die zum Einen das Alles gebaut haben, aber auch Beispiele und Dokumentation bereitstellen.

Froehliches Shell-Hacken 🙂