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:
Remote-Job-Präferenzen im Wandel: Hacker News Jobs in der Analyse
Im Blog der Firma „SpatialChat“ findest du eine recht aktuelle Analyse der Hacker News Job Postings der letzten 5 Jahre.
Die Analayse ist ziemlich ausführlich, deshalb hier nur ein paar Highlights:
- 2018: 9801 Jobanzeigen, davon 23 % Remote Stellen
- 2019: 8684 Anzeigen, 29 % Remote
- 2020: mit 7364 noch weniger Anzeigen als in 2019, dafür schon mehr als die Hälfte Remote
- 2021, Höhepunkt der Pandemie, 10807 Anzeigen, knapp 80 % Remote
- 2022, diverse Layoffs, trotzdem noch 7930 Stellen, 80 % davon Remote
- 2023 (Januar bis Juni): nur noch 2420 Stellen, knapp 70 % davon Remote.
Interessanterweise sind die Anzahl der „Location-based-restrictions“, also in welchem Land Remote gearbeitet werden kann, von 16 % im Jahr 2018 auf 37 % im Jahre 2023 gestiegen. Der Trend geht also zur „Remote-Arbeit“, aber eben eingeschränkt.
In den USA seien vor allem Menschen aus den Ballungszentren San Francisco und New York weggezogen, um von „günstigeren“ Gegenden aus zu arbeiten – oder eben dort, wo man sich wohler fühlt.
Natürlich sind die Daten auf die Tech-Industrie gemünzt und daher mit Vorsicht zu genießen. Im Disclaimer des Artikels steht, dass von den 160 Millionen Arbeitnehmern in den USA nur rund 5 % in der Tech-Industrie arbeiten und eben die Grundlage dieser Analyse seien.
Tracking HackerNews‘ Shifting Preferences for Remote Jobs Over 5 Years
Microsoft: Master-Key in falschen Händen
Wie die Security Forscher von Wiz herausfanden, hat der öffentlich geratene MSA Key doch mehr Funktionen als ursprünglich kommuniziert. Dafür hatte Wiz den von Microsoft veröffentlichten Fingerprint genutzt, um im Internet, dem Internet-Archive und weiteren Stellen nach den Signaturen gesucht.
Initial hatte man kommuniziert, dass der Schlüssel nur für Exchange Online genutzt wurde, tatsächlich schloss er wohl aber auch viele Microsoft Azure Services ab.
Mithilfe des Keys war man bei Wiz in der Lage, Zugangstoken für diverse Cloud Services zu erstellen.
Wiz hat die Spur des Keys verfolgt und scheinbar bis zur chinesischen Hacker-Gruppe Storm-0558 verfolgt. Vermutlich ist der Outlook-Hack aus dem Juni 2023 dann auch auf den Master-Schlüssel zurückzuführen, dessen Verlust nun viel weitreichender war, als bisher bekannt.
Wiz listet hier eine Liste potenziell betroffener Applikationen – grundsätzlich können alle Services betroffen sein, die auf Microsofts OpenID v2.0 aufsetzen. Seit einiger Zeit können mit dem Schlüssel keine neuen Tokens mehr ausgestellt werden. Bereits ausgestellte Tokens können aber weiterhin für den Zugriff verwendet werden.
Die Forscher von Wiz zeigen im Blog Artikel, wie man Spuren und betroffene Tokens in seiner Umgebung finden kann. Zusätzlich sollte man das Azure SDK aktualisieren und Application Caches leeren, damit ältere Schlüssel nicht mehr gültig sind.
Golem fasst den Vorfall hier ebenfalls zusammen, falls du eine deutsche Quelle für die Nachrichten benötigst.
Compromised Microsoft Key: More Impactful Than We Thought
Sponsored
DevOps & SRE as a Service mit „We Manage“
Wir helfen Dir beim 24×7 Betrieb, bei Performance Problemen, bei Kostenoptimierung oder einfach beim Betrieb Deiner Web-Applikationen.
Betreibst Du Services wie GitLab, Zammad und Matomo selbst – hierbei unterstützten wir ebenfalls gerne – schau Dir einfach mal unsere Leistungen an.
Unsere Kunden kommen in unseren Case Studies zu Wort – wie beispielsweise everysize.com – eine Sneaker-Suchmaschine mit Preisvergleich und Community.
Interessiert? Lerne uns in einem 15 Minuten Video-Call kennen.
Appell zum Office Day
Im Gegensatz zur Analyse von oben findet sich im Blog der Karlsruher Agentur „Explain“ ein Artikel aus dem März zum Thema „Office Day“, der dir vielleicht bei der Entscheidung hilft, wieder einmal die Woche ins Büro zu gehen?
Im Home-Office haben wir Freiheiten und genießen die „Ruhe“, jedoch fehlen die Kollegen und spontante Meetings.
Es wird schnell nebenher die Wäsche gewaschen, das Mittagessen ist frisch gekocht, wir haben mehr Zeit für Sport oder anderen Ausgleich.
Sind effektiver, flexibler und konzentrierter.Trotzdem fehlt etwas. Denn bei allem sind wir relativ allein.
So beschreibt dies der Artikel – in der Regel reiht sich „Meeting an Meeting“ und kaum einer stellt einen „Spontaner Austausch“ als Termin ein. So trifft man sich bei „Explain“ nun alle 2 Wochen für einen Office Day, der mit einer Social Activity abschließt – finde ich jetzt cool, da es wieder mehr den Team-Gedanken in den Vordergrund stellt.
Vielleicht kann man so das Angenehme mit dem Nützlichen verbinden?
Habt ihr schon so eine Art Office-Day?
Plötzlich war da der Office Day
Linux: Auswirkungen von IO Wait im Detail erklärt
Im empfehlenswerten Percona Blog findet sich eine grundsätzliche Erklärung zum Thema IOWait auf Linux Systemen. Im Beispiel wird die Last mit Sysbench erzeugt und mit dem Percona eigenen Tool „Percona Monitoring and Management“ analysiert.
IOWait ist eigentlich CPU Idle Time, nur eben eine spezielle Idle Time. IOWait beschreibt den Prozentsatz, den eine CPU mit dem Warten auf das Beenden von Input/Output-Operationen verwendet. Mit anderen Worten, wenn eine CPU auf Daten von einer Festplatte oder einem anderen Speichergerät wartet, wird diese Zeit als IOWait bezeichnet.
IOWait ist somit ein wichtiger Faktor für die Leistung unserer Systeme. Wenn der IOWait hoch ist, kann dies darauf hindeuten, dass unsere Speichergeräte zu langsam sind oder dass es Engpässe in der Verarbeitung gibt. Möglichen Ursachen für erhöhten IOWait können beispielsweise eine hohe Festplattenauslastung, Überlastung des Dateisystems oder zu viele gleichzeitige Anforderungen an das Speichermedium sein. Es gibt verschiedene Wege, IOWait zu optimieren, schnellere Disks, Auslagerung / Verlagerung von I/O intensiven Tätigkeiten oder das Verwenden von In-Memory Caches.
Interessanterweise gibt es auf Multi-Core Maschinen einige Möglichkeiten, dass man nur geringe IOWait sieht, sie aber trotzdem das System verlangsamt. Dies kann sein, wenn das System andere CPU intensive ausführt, anstatt „nur“ zu idlen und auf I/O zu warten. Wie das passieren kann, wird hier ausführlicher beschrieben.
Bin froh, das der Artikel hier vmstat als Debugging Tool empfohlen hat, das ist grundsätzlich mein angewöhnter erster Blick auf ein System, und nicht top oder andere Themen. Bei vmstat siehst du I/O in den Spalten bi und bo. bi sind die Blöcke, die von Block Devices gelesen wurden und bo Blöcke, die an ein Block Device gesendet wurden.
Modern überwachen würde man beispielsweise mit Telegraf und dessen Plugins inputs.diskio und inputs.io.
Out-of-Memory (OoM) Killer-Ereignisse erkennen und lösen
Schlägt der Out-of-Memory (OoM) Killer des Linux Kernels zu, so bleibt davon nichts verschont.
Das es wichtig ist, dieses Thema auch für Cloud-native Anwendungen zu beachten, zeigt der verlinkte Artikel im Blog von RedPanda. Wichtig ist die Verwendung von cgroups, die in Linux die Ressourcenverwaltung für Prozessgruppen ermöglicht. Durch das Festlegen von Limits für Prozesse in cgroups können wir sicherstellen, dass jeder Prozess nur eine bestimmte Menge an Speicher und anderen Ressourcen verwenden kann.
RedPanda hat dies zwar verwendet, die konfigurierten Limits aber überschritten – der Linux Kernel nimmt sich dann diese Prozesse und räumt sie weg. In der Regel startet K8s diese neu, daher ist dies kein Problem – zu einer Interruption kann es natürlich trotzdem führen. Gerade in einer Cloud-native Welt wird häufig über provisioniert und „falsche“ oder zu defensive Limits können dann zu solchen Problemen führen.
Am einfachsten begegnet man den Themen erst mal mit mehr Memory, damit das System sich stabilisiert. Dann sollte man das eigentliche Problem beheben, die Limits anpassen oder die Prozesse besser auftrennen – in diesem Fall hat man all dies gemacht, aber halt nacheinander.
Solving challenges caused by Out Of Memory (OOM) Killer in Linux
Sicherheitslücke bei BunnyCDN
In dem Artikel auf httptoolkit.com wird eine kritische Sicherheitslücke im Caching-System von BunnyCDN aufgedeckt. BunnyCDN ist ein Content Delivery Network (CDN) aus Europa, welches durch Edge-Caching die Performance von Websites verbessert.
Die Lücke ermöglichte es Angreifern, auf geschützte und sensible Daten von anderen Websites zuzugreifen, die auf demselben BunnyCDN-Node gecached wurden. Die Schwachstelle ermöglichte es auch, den Cache zu manipulieren und gefälschte Inhalte an die Nutzer auszuliefern.
Autor Tim Perry beschreibt, wie er durch das Senden von speziell gestalteten HTTP-Anfragen an das BunnyCDN-System in der Lage war, verschiedene Websites im Cache zu umgehen und auf deren Inhalte zuzugreifen. Dies führte zu einem potenziellen Datenschutzverstoß und einer möglichen Auslieferung bösartiger Inhalte an die Endbenutzer.
Er selbst hat die Lücke gefunden, da eine seiner APIs nicht funktionierte, da eben der Authentication Header falsch gecached wurde.
Die Sicherheitslücke war auf eine unzureichende Validierung und Trennung der Cache-Keys zurückzuführen, die es einem Angreifer ermöglichte, auf Inhalte anderer Websites im selben Cache zuzugreifen. Tim informierte sofort das BunnyCDN-Team über die Sicherheitslücke, die sie dann schließlich behoben haben.
Mit der Timeline für den Fix kann man nicht so ganz zufrieden sein – laut einem Reddit Kommentar von Tim meldete er das Thema initial am 16. März 2023. Bunny hat den Bug dann am 18. März bestätigt – der Fix in Production erfolgte dann aber erst 2 Monate später – zwischen dem 19. und 31. Mai 2023.
Leaking secrets through caching with Bunny CDN
GitLab 16.2 released
Am 22. Juli 2023 wurde GitLab in Version 16.2 veröffentlicht. Im Release finden sich über 110 Verbesserungen von über 208 verschiedenen Contributoren.
Ein paar Auszüge aus der umfangreichen Feature-Release-Liste:
- Der neue Rich-Text Editor ist endlich in allen GitLab Versionen (SaaS und self-managed) für Issues, Epics, Merge Requests und im Wiki verfügbar.
Tabellen, Bilder, Listen – all das ist nun deutlich einfacher und zugänglicher geworden. - Die neue „Command Palette“ hilft bei der mouseless Bedienung von GitLab.
- Die Flux Integration (GitOps für Kubernetes) kann nun automatisch auf Manifest Änderungen reagieren.
- GitLab for Slack ist nun in allen self-managed Versionen verfügbar.
- In der Diff Ansicht eines Merge Requests können Vorschläge nun einfacher editiert werden – in Zukunft dann auch mit dem neuen Rich-Text Editor.
- PyPi Packages können in CI/CD Pipelines verwendet werden
- Und ganz wichtig: Mehr Emoji Reactions bei Design Uploads wie wireframes und mockups
Seit dem 25. Juli gibt es gar schon ein 16.2.1 Patch Release – über Omnibus bekommst du ja aber ohnehin immer das aktuellste Release.
Und wie immer gibt es bereits eine öffentliche Vorschau auf das nächste Release, 16.3.
GitLab 16.0 released with Value Streams Dashboards and improvements to AI-powered Code Suggestions
Schmunzelecke
Ist eigentlich Frontend oder Backend einfacher? Gefunden bei Twitter ähh X.
💡 Link Tipps aus der Open Source Welt
Iconbuddy – Open Source Icons
Bei Iconbuddy bekommst du über 100.000 kostenlose Icons – laut Suche aktuell 180.989 Verschiedene.
Die Icons sind in über 120 Icon-Sets organisiert, wie beispielsweise VSCode Icons, Weather Icons oder diverse Font Awesome Sets.
Du kannst die Icons anpassen und verändern und in verschiedenen Formaten herunterladen.
OpenSource „On-Boarding“ Bibliothek
Falls du eine „On-Boarding“ Bibliothek für deine Web-Applikation suchst, schau dir mal Driver.js an. Nicht nur ist es einfach zu nutzen und veränderbar, es kommt auch nur mit 5KB Overhead mit sich.
Driver.js gibt es eigentlich schon seit 2018, vor 3 Wochen gab es ein neues 1.x Release, welches als ein kompletter Rewrite mit TypeScript veröffentlicht wurde.
Die Website driver.js ist ebenfalls neu und enthält direkt eine „Demo Tour“.