Willkommen zu allesnurgecloud.com – Ausgabe #131!

Mal schauen, ob ich den Montag als Versanddatum beibehalte – die Öffnungsrate war letzte Woche 10 % geringer als üblicherweise am Sonntag.
Findest du Montag oder Sonntag besser? Antwort gerne per Mail, Kommentar oder auf LinkedIn.

In meinem Podcast „Happy Bootstrapping“ war in Folge #55 in der letzten Woche Johannes Mansbart vom WhatsApp CRM Chatarmin.com zu Gast. Es gibt interessante Insights zum Thema WhatsApp Marketing für E-Commerce Shops, einen Einblick in sein LinkedIn Content-Marketing und eine Übersicht in die Herausforderungen eines bootstrapped SaaS Produkts.

allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.

Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:

Microsoft: Details zur Attacke von „Midnight Blizzard“

Microsoft hat am 19. Januar 2024 Details zu einer Hacker-Attacke von „Midnight Blizzard“ vom 12. Januar 2024 veröffentlicht. Das insoweit bemerkenswert, da man kurzfristig mit Details an die Öffentlichkeit gegangen ist. „Midnight Blizzard“ ist auch unter dem Namen „Nobelium“ bekannt – die Hacker Gruppe wird vom russischen Staat unterstützt.

Die Angreifer führten im November 2023 eine „Password Spray Attacke“ gegen einen „legacy non-production“ Account durch und konnten über diesen Account dann auf eine kleinere Anzahl an Corporate E-Mail-Accounts zugreifen:

Beginning in late November 2023, the threat actor used a password spray attack to compromise a legacy non-production test tenant account and gain a foothold, and then used the account’s permissions to access a very small percentage of Microsoft corporate email accounts, including members of our senior leadership team and employees in our cybersecurity, legal, and other functions, and exfiltrated some emails and attached documents

Eine „Password Spray Attacke“ ist ein automatisierter Angriff mit einer Liste gängiger Passwörter wie „password1“ oder „12345678“.
Laut Aussagen von Microsoft gibt es, Stand heute, keine Hinweise darauf, dass weitere Systeme oder Umgebungen von Kunden kompromittiert wurden.

Microsoft führt eine umfassende Analyse seiner Systeme durch und verspricht, seine aktuellen Sicherheitsstandards schnellst möglichst auf alle „legacy Systeme“ anzuwenden, auch wenn dies zu Einschränkungen im Betrieb führen könnte:

We will act immediately to apply our current security standards to Microsoft-owned legacy systems and internal business processes, even when these changes might cause disruption to existing business processes.

Der Vorgang hört sich so an, als seien mittlerweile gängige Technologien wie Multi-Faktor Authentication bisher nicht auf alle älteren und internen Systeme ausgerollt.
Das widerspiegelt vermutlich den gängigen Stand in vielen Firmen und Konzernen, die zwar solche Technologien beschafft und ausgerollt haben, aber noch diverse „technische Schulden“ bei Systemen ohne MFA, SAML und Co. Support offen haben.
Bei Systemen, die so offen im Internet stehen, kann man sich mit Reverse Proxy Lösungen wie beispielsweise Caddy + LDAP/SAML IdP oder auch Authentik behelfen, die dann als Absicherung in solchen Fällen schnell und einfach helfen können.

Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard

---

Framework für technische Schulden

Dass das Thema „Technische Schulden“ ein wiederkehrendes Thema bei allesnurgecloud ist, hat der regelmäßige Leser sicherlich schon mitbekommen. Das Thema von Microsoft zeigt, dass viele Firmen diesem Thema häufig erst eine hohe Priorität einräumen, wenn es einen (Sicherheits-) Vorfall gab.

Dass das Thema wichtig ist, zeigt auch der Artikel Stop saying “technical debt“ aus dem StackOverflow Blog. Ich hatte im März 2023 in Ausgabe 96 auf ihn hingewiesen, Stack Overflow veröffentlicht ihn nun erneut, da der Artikel einer der beliebtesten aus dem Jahr 2023 war.

Ein wichtiger Einstieg in die Behebung der „technischen Schulden“ ist erst einmal, dass man sie transparent macht. Im unten verlinkten Artikel beschreibt Start-up Veteran Max Countryman, wie man mithilfe eines Frameworks technische Schulden strukturiert beheben kann:

1. Analyse der existierenden Systeme und wie sie miteinander agieren – Max beschreibt dies als „Landscape Map“
2. Impact der technischen Schulden bestimmen – die „Interest Rate“, das kennen wir vom Häusle bauen
3. Solvent bleiben und nicht „Insolvent“ gehen

Max warnt am Ende davor, nur die „Items mit der hohen Zinslast“ zu beheben – auf Dauer können auch die kleinen Themen zu Biestern werden (das ist dann der Zinseszins Effekt).

A Framework for Prioritizing Tech Debt

---

GitHub: Details zum MySQL 8 Upgrade

GitHub speichert viele seiner relationalen Daten in einer größeren MySQL Datenbank Flotte. Vor 15 Jahren startete alles mit einer Single Instanzen, heute bilden über 1200 Datenbank Hosts den DBMS Core von GitHub ab.

In einem sehr ausführlichen Blog-Post im GitHub Engineering Blog erfahren wir nun ein paar Details über die Hintergründe der Migration der Flotte von MySQL 5.7 auf MySQL 8.0.
Wir erfahren zunächst ein paar Zahlen und Fakten zur Flotte:

• 1200+ Hosts für MySQL – Azure Virtual Machines und „Bare Metal“ Hosts im eigenen Datacenter
• 300TB an MySQL Daten – mit 5,5 Millionen QPS (Queries per Second), die aus 50+ Clustern ausgeliefert werden
• MySQL Cluster sind hochverfügbar – gebaut mit Orchestrator und Hashicorp Consul (Details in einem alteren Blog-Artikel)
• Die Daten sind partitioniert – teilweise werden auch Vitess Cluster verwendet

Dazu entwickelt man in-house eigene Open-Source Komponenten, die den Betrieb supporten:

• GitHub Online-Schema-Migration Tool gh-ost – https://github.com/github/gh-ost
• Orchestrator – für die Administration der Replication Topologie – https://github.com/openark/orchestrator
• freno – ein Service, der Writes gegen eine Datenbank automatisch reduzieren kann – https://github.com/github/freno

Vorab wurde ausführlich geplant, kommuniziert und Transparenz über die geplante Migration hergestellt.
Danach wurde die Migration durchgeführt:

1. Umstellung der Replicas – Step by Step wurden Read-Only Replicas migriert, mit Live-Traffic versorgt und kontinuierlich überwacht. Es wurden genug 5.7. Instanzen als „Fallback“ auf standby gestellt, aber von diesen erstmal kein Traffic mehr ausgeliefert
2. Migration der Replizierungs-Topologie: Der MySQL Orchestrator erlaubt eine mehrstufige Replizierung – so konnte GitHub einen 5.7 Master gegen einen 8.0 Replica replizieren, der selbst wiederum diverse 8.0 und 5.7 Cluster mit Replizierungsinformationen versorgt hat – also selbst die Quelle war. Somit konnte man das Verhalten testen, ohne dass der 8.0 gleich ein „Write-Primary“ wurde.
3. MySQL 8.0 Primary Promotion: Im letzten Schritt konnte der in 2) beschriebene Replica MySQL 8.0 Host zum Primary Host werden, der eben auch den Write-Traffic verarbeitet hat.
4. Anschließend wurden die 5.7 Instanzen für Traffic gesperrt und ein Failover verhindert, interne Instanzen umgestellt und dann später die alten Instanzen abgebaut

Natürlich gab es während der Migration diverse Herausforderungen. Unter anderem gab es einen Bug in der MySQL Replikation für Versionen < 8.0.28. Da musste man also sicherstellen, eine neuere Version zu verwenden. Außerdem hat der Optimizer sich bezüglich der WHERE IN Queries geändert, teilweise stürzten 8.0 Instanzen bei größeren WHERE IN Queries ab.
In der Zusammenfassung zur Migration fällt noch ein wichtiges Detail auf – die Planung und Durchführung der Migration dauerte über 1 Jahr, obwohl mehrere Teams bei GitHub daran beteiligt waren. Beim letzten Upgrade der MySQL Version war man „nur“ mit 5 DB-Clustern unterwegs, heute sind es über 50 Cluster, verteilt auf die oben genannten Maschinen.
Zur Vereinfachung solcher Migrationen möchte GitHub in Zukunft seinen Automatisierungsgrad weiter erhöhen und neue Tools entwickeln und einführen.
In Summe ein super interessanter Einblick in den GitHub Maschinenraum, oder?

Upgrading GitHub.com to MySQL 8.0

---

HelloFresh muss Strafe für Spam-Mails und SMS bezahlen

Im vereinigten Königreich hat das „Information Commissioner’s Office“ (ICO), das ist die Datenschutzbehörde in UK, HelloFresh zur Zahlung einer Strafe von £140,000 verdonnert.

HelloFresh hat in einer 7-monatigen Kampagne 79 Millionen Spam E-Mails und 1 Million SMS an Kunden verschickt. Nach einer Untersuchung des ICO stellte dieses fest, dass die Kunden im Unklaren gelassen wurden, wofür ihre privaten Informationen verwendet wurden. HelloFresh habe damit das Vertrauen der Kunden missbraucht und muss deshalb nun die Strafe bezahlen. Außerdem war es Kunden teilweise nicht mal möglich, die unfreiwillige Teilnahme an der Kampagne zu beenden:

Customers weren’t told exactly what they’d be opting into, nor was it clear how to opt out. From there, they were hit with a barrage of marketing texts they didn’t want or expect, and in some cases, even when they told HelloFresh to stop, the deluge continued.

Die Kampagne wurde zwischen dem August 2021 und Februar 2022 verschickt. Die Untersuchung des ICO wurde im März 2022 gestartet und kam nun Anfang Januar 2024 zu einem Abschluss. Das ICO gibt an, seit dem April 2023 schon Strafen in Höhe von 2,2 Millionen Pfund verhängt zu haben.
Weitere Details kannst du im verlinkten Artikel oder im PDF Urteil nachlesen.

Was meinst du?
Für die Anzahl der Nachrichten erscheint mir die Strafe als zu gering an, oder?
Aufgerundet sind, dass gerade mal £0,002 pro Nachricht – ob das vom Spamversand abschreckt, wage ich zu bezweifeln.

ICO fines HelloFresh £140,000 for spam texts and emails

---

Vergleich von Service Verfügbarkeit in AWS Regionen

Das unten verlinkte Region Comparison Tool kann dir bei der Architektur deiner AWS Services behilflich sein.
Und es zeigt außerdem, dass nicht alle 200+ AWS Services in allen Regionen verfügbar sind – das Gegenteil ist üblicherweise der Fall.
Hier kannst du unter anderem den Vergleich zwischen eu-central-1 (Frankfurt) und eu-central-2 (Zürich) sehen – die vielen roten Kreise zeigen an, dass die Services nur in eu-central-1 verfügbar sind.
Besser sieht es aus, wenn man ältere Regionen vergleicht, zum Beispiel eu-central-1 und us-east-1 (Virginia) – allerdings gibt es auch hier einige Services, die es bisher nur in us-east-1 gibt.

Region Comparison Tool

---

Podman als Docker Alternative

Die Docker Alternative Podman gibt es schon länger, so richtig durchgesetzt hat sie sich gefühlt noch nicht – der Mensch ist einfach ein Gewohnheitstier?

Dabei bietet Podman gegenüber „normalem“ Docker diverse Vorteile, beispielsweise benötigt Podman keinen Daemon, um einen Container zu starten. Zur Orchestrierung von Containern verwendet Podman einfach Systemd. Und docker-compose gibt es auch nicht, dafür unterstützt Podman Kubernetes Manifest Files. Verwendet man also K8s in der produktiven Umgebung, so ist man lokal mit einem Podman Setup etwas näher dran als mit Docker selbst.
Abschließend sind diverse Security Features (rootless Container, User Namesapces, seccomp Profile) in Podman per Default aktiviert, in Docker nicht.

Im unten verlinkten Artikel bei Betterstack findest du den ausführlichen Vergleich zu Docker und Podman, sowie ein Beispiel einer WordPress Installation, die lokal mit mehreren Containern arbeitet.

Exploring Podman: A More Secure Docker Alternative

---

DevDocs – zentrale Developer Dokumentation

Das Open-Source-Projekt DevDocs kombiniert diverse öffentliche Entwickler Dokumentationen in einer schicken Web-UI. Dabei sind die DevDocs einfach und schnell durchsuchbar, es gibt einen Offline Support, eine Mobile Version, Keyboard Shortcuts und natürlich einen Dark Mode.
Diverse gängige Dokumentationen sind per Default aktiviert, beispielsweise für CSS, JavaScript, Web APIs, HTTP und HTML – andere müssen erst kurz „aktiviert“ werden.
Die Dokumentation des Ansible Moduls zu Podman findest du hier, die von PostgreSQL 14 dann hier oder auch die gesamte nginx Dokumentation mit sämtlichen Modulen dann hier.
Ich habe mir das erst einmal in die Lesezeichenleiste gepackt, damit man sich auch daran gewöhnt, es zu verwenden. Alleine die schnelle Suche und leichte Erreichbarkeit der HTTP RFCs, z.b. RFC 9111: HTTP Caching, ist echt Gold wert.

API Documentation Browser

---

Release von GitLab 16.8 mit GCP Secrets Manager Support

In der letzten Woche hatte ich erst GitLab 16.7 als News, nun gibt es schon die Version 16.8 von GitLab – praktisch, so eine kleine Winterpause.
Das Release ist nicht so voll wie sonst, vermutlich auch wegen den Ferien in den USA.

Features von GitLab 16.8 in der Übersicht:

• Secrets des GCP Secret Managers können nun direkt in GitLab CI/CD Jobs verwendet werden (ab Premium)
• Die GitLab Workspaces sind nun GA – eigene Entwicklungsumgebungen auf Basis der Web IDE (ab Premium)
• Bei self-hosted Instanzen wird 2FA für Admins nun verpflichtend aktiviert
• Für Maven Repositories gibt es nun einen Dependency Proxy (ab Premium)
• In Merge Requests kann nun mit vorab definierten Variablen gearbeitet werden
• Neben dem GitLab Runner in Version 16.8 gibt es nun Support für Windows 2022 bei den SaaS runners
• Kubernetes 1.28 ist nun supported (Das war schoin im August 2023 released worden, hier gibt es also ein kleines Delay)
• die „git blame“ Informationen sind nun leichter zugänglich

Es gibt insgesamt über 25 Verbesserungen in Release 16.8 und wie immer gibt es schon die ersten Informationen zu 16.9 auf der „Upcoming Releases“ Page bei GitLab.

Interessant ist auch, dass mal wieder ein GitLab MVP von der Deutschen Telekom gibt. Man ist nicht nur öffentlich bekennender GitLab User (siehe Case Study), sondern trägt auch zur Weiterentwicklung des Produktes bei.

GitLab 16.8 released with GCP Secret Manager support and the ability to speed up your builds with the Maven dependency proxy

---

Schmunzelecke

Auf IoT fahren wir ITler ja grundsätzlich ab – teilweise ist unser Umgang damit vielleicht etwas naiv?
Ein Twitter User hat nun festgestellt, dass seine LG Waschmaschine 3,7 GB an Daten nach Hause sendet – in einem Follow-Up Post meinte @Johnie dann, dass es vielleicht auch ein Problem in der Router Software seines Asus Routers sein könnte.

---

💡 Link Tipps aus der Open Source Welt

ugrep – schneller und mehr Features als „grep“

Ugrep ist ein drop-in replacement für das bekannte legacy grep.
Dabei kommt das Tool mit 2 Binarieres: ug als interaktive Alternative und eben ugrep für die Nutzung in automatisierten Shell und batch Prozessen.
Auch hilfreich: ugrep mached automatisch auf mehrere Vorkommnisse eines Strings, ganz ohne Option – und es funktioniert automatisch für UTF-8, UTF-16 und UTF-32 codierte Files. Ugrep kann zudem über ein .ugrep File konfiguriert werden.
Installieren kannst du das Tool über Brew, Choco, apt, dnf, zypper… wie du siehst, ist es schon recht verbreitet.

https://github.com/Genivia/ugrep

---

Vanna – AI für deine Datenbank

Wie wir alle wissen, sprießen viele AI Projekte gerade wie Pilze aus dem Boden.

Über Vanna AI bin ich irgendwie gestolpert, da ich es ganz interessant fand. Mit Vanna kannst du mit deiner Datenbank chatten. Vanna ist ein Open-Source Python RAG (Retrieval-Augment Generation) Framework für SQL. Du trainierst Vanna gegen deine Daten und kannst Vanna dann Fragen zu deinen Daten stellen.

Vanna erstellt dann die passenden SQL Queries, die du in deinem Data Warehouse dann automatisieren kannst.

https://github.com/vanna-ai/vanna

---

❓ Feedback & Newsletter Abo

Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.

Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!

Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: