WordPress vs. WP Engine, S3 von Hetzner und GPU Server, RCE in Linux, Friction Logs, PostgreSQL 17, Cloudflare AI Marktplatz und mehr – allesnurgecloud #159

Willkommen zu allesnurgecloud.com – Ausgabe #159

Die letzte Woche war ein wenig hektisch – die mit CVE 9,9 angekündigte Linux RCE Lücke war dann zum Glück doch nicht so relevant für die meisten Anbieter. Dennoch spannend, wie das Ganze abgelaufen und vorab geleaked wurde.
Ich hoffe, du hattest dadurch nicht all zu viel Streß im Büro.

Happy Bootstrapping Podcast

Im Podcast habe ich diese Woche passend zum WordPress Drama mit Vjeko Keskic von FC Bayern München Blog fcbinside.de gesprochen. Das Blog basiert auf WordPress und hat mit 6-7 Millionen Besuchern pro Monat mehr Besucher als viele Fußball Clubs.
Vjeko ist mit seinen Portalen Kunde in meiner Firma und vieles habe ich so noch gar nicht gekannt. Interessant fand ich seine Vorgehensweise beim Switch vom Nebenjob zum Hauptjob – hör doch gerne mal rein.

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:

526 Abonnenten sind schon dabei - Vielen Dank!

Please enter a valid email address
Diese E-Mail ist bereits registriert.
The security code entered was incorrect
Vielen Dank für Deine Anmeldung - bitte den Opt-In bestätigen.

WordPress vs. WP Engine Drama

In der letzten Woche ist ein Streit zwischen WordPress und dem bekannten WordPress Hoster WP-Engine eskaliert.

Was war passiert?

Angefangen hat es mit einem Vortrag von WordPress Gründer und CEP Matt Mullenweg auf der jährlichen WordCamp Konferenz. Matt hat WP Engine und der Führungsmannschaft der private Equity Firma hinter WP Engine vorgeworfen, die WordPress Community und Automattic (Firma von Matt, die hinter WordPress steht) auszunutzen:

  • Die Entwickler und Supporter von Auttomattic steuern 3.915 Stunden pro Woche zum Projekt bei
  • WP Engine jedoch nur 40 Stunden pro Woche

WP Engine mache mit WordPress Hosting $500 Millionen pro Jahr und das passe dann einfach nicht zusammen (Automattic macht ungefähr den gleichen Umsatz).

Zusätzlich sei die von WP Engine verwendete WordPress Variante technisch eingeschränkt – beispielsweise gibt es keine „Revisionen“ von Artikeln, die in WordPress als einzelne Entwürfe in der DB gespeichert werden, was natürlich die Datenbank etwas aufbläht. Kostet natürlich RAM, CPU und Speicherplatz auf den Systemen und erhöht die Marge, wenn man es deaktiviert. Über den Support kann es aktiviert werden – per Default ist es jedenfalls deaktiviert, und es kann maximal 5 Revisions pro Artikel geben. Matt fasst den initialen Aufschlag in „WP Engine is not WordPress“ zusammen.

Es folgte die nächste Eskalation durch WP Engine – man schickte eine Unterlassungserklärung gegen die Anschuldigungen von Matt Mullenweg, dieser habe unter anderem „WP Engine is a cancer to WordPress“ und andere „harmful and disparaging statements“ gegen WP Engine vorgebracht, dies sei zu unterlassen (siehe TechCrunch).

Automattic holte zum Gegenschlag aus und verbietet WP Engine die Nutzung der Brands „WordPress“ und „WooCommerce“. Man habe über Jahre versucht, WP Engine zum Erwerb einer kommerziellen Lizenz und zu mehr Beteiligung an der Entwicklung und dem Support des WordPress Ökosystems zu bewegen – ohne Erfolg (Unterlassungserklärung als PDF).

Kurz darauf unterband WordPress den Zugriff von WP Engine auf sämtliche WordPress Ressourcen, wie den Zugriff auf WordPress.org. Damit konnten WP Engine Nutzer das komplette Ökosystem nicht mehr nutzen – Plugins installieren, Update Server, Community, Theme Directory und vieles mehr. WordPress stelle dies allen umsonst zur Verfügung, warum solle man das bei dem Verhalten von WP Engine weiterhin so machen?
Man merkt die Eskalation in diesem Zitat von Matt Mullenweg:

WP Engine is free to offer their hacked up, bastardized simulacra of WordPress’s GPL code to their customers, and they can experience WordPress as WP Engine envisions it, with them getting all of the profits and providing all of the services.

Das ganze Drama kann man in diesem Incident Report von WP Engine nachlesen.

Was folgte war ein Aufschrei der Community, die ja keine Updates und Plugin Updates mehr durchführen konnte – WordPress hob darauf die Einschränkungen temporär auf und kündigte eine dauerhafte Sperrung zum 1. Oktober 2024 an.

Matt fasst den ganzen Vorgang im hier verlinkten Artikel nochmals zusammen.

Warum ich das Thema hier an so prominenter Stelle habe? Es gibt Stand September 2024 über 478 Millionen Webseiten, die mit WordPress betrieben werden – das sind 43,5 % aller Internetseiten. Im CMS Markt hat WordPress sogar einen Anteil von 62,6 %.
WordPress selbst ist eigentlich Open Source und unter der GPL lizensiert – und man sieht auch an diesem Beispiel, wie das Produkt Ansicht monetarisiert werden kann, ohne sich selbst am Produkt zu beteiligen.

Ironischerweise hat Automattic selbst in WP Engine strategisch investiert – im November 2011 – ist also schon eine Weile her.

WPE & Trademarks


Hetzner mit Object Storage und neuem GPU Server

Hetzner hat in der letzten Woche den „Hetzner Summit“ veranstaltet und dort unter anderem den lang erwarteten Object Storage in einer Beta Version gestartet. Aktuell muss man sich für die kostenlose Beta Version bewerben. Ab dem 1.11.2024 soll der Service dann weiterhin „Beta“ bleiben, aber nicht mehr kostenlos sein.

Was kostet also der Object Storage bei Hetzner?

  • 0,0096 €/Stunde für doe „Object Storage Runtime“
  • pro Stunde erhält man dann 1 TB Storage und 1,5 GB Traffic
  • Hast du also 1 TB im Monat an Storage gebucht, so hat man 1100 GB Traffic mit inklusive, wenn ich das richtig verstehe
  • Alle „Object Storages“ werden kumuliert abgerechnet
  • kostenlos ist: Ingress Traffic, Interner Traffic innerhalb eu-central & alle S3 API Calls wie PUT, GET und DELETE

Folgende Limitierungen gibt es:

  • bis zu 10 TB pro Objekt
  • bis zu 1 GBit/s Bandbreite pro Bucket
  • bis zu 1024 operations/s pro Bucket
  • bis zu 100 TB pro Bucket
  • bis zu 100.000.000 Objekten pro Bucket
  • bis zu 100 S3 Credentials über alle Projekte
  • maximal 10 Buckets über alle Projekte

Als Bucket-Domain nutzt Hetzner „fsn1.your-objectstorage.com“ – bisher gibt es den Object Storage nur in Falkenstein. Wie auch bei den Volumes und Backups verwendet Hetzner hierunter Dell Hardware Server und nicht wie bei den Root-Servern „Commodity Hardware“.
Alle Infos zur Beta Version findest du in den Docs, direkt bewerben können sich Hetzner Kunden über diesen Link.

Neben dem Object Storage gibt es auch noch einen neuen GPU Root Server GEX130 mit einer RTX-6000 Ada Grafikkarte mit 48 GB GDDR6 ECC Grafikspeicher. Der Server selbst hat dann eine Intel Xeon Gold 5412U CPU mit 24 Cores, 128 GB DDR5 RAM und 2*1,92 TB Gen4 NVMe SSDs. Das Ganze gibt es dann für 997,22 €/Monat zuzüglich Setup Gebühr von 94,01€ (beides inkl. Mwst.)
Für Hetzner ein unüblich hoher Preis, man muss aber bedenken, dass die RTX-6000 alleine schon aktuell um die 8000€ kostet.

Hetzner Object Storage Overwiew


Sponsored

Checkly sucht Engineers – Full Remote!

In einer der letzten Ausgaben hatte ich bereits über die 20 Millionen Finanzierungsrunde von Checkly berichtet.

Das Team von Checkly sucht nun folgende neue Kolleg:innen zur Unterstützung:

Bei Checkly arbeitest du remote-first, flexibel und asynchron – Meetings werden so gut es geht vermieden. Mit der Kultur ist Checkly sehr transparent – viele Infos dazu findest du auf dieser Notion Page. Passend dazu ist das „Employee Handbook“ für alle verfügbar – inklusive Informationen zur Bezahlung der Mitarbeitenden.

Falls du Checkly nicht kennst – Checkly bietet eine synthetische Monitoring Lösung an, die eure APIs und Applikationen von der ganzen Welt aus überwacht. Das besondere? Checkly ist Code-first und bietet wirkliches „Monitoring as Code“ über einen eigenen Terraform Provider, eine Pulumi Integration und die hauseigene CLI an.

Join the Checkly Team


Linux Remote-Code Execution in Cups

Am kommenden Montag hätte es eigentlich einen Release eines „Unauthenticated RCEs“ in allen GNU/Linux Distributionen geben sollen. Laut Stand vom 23. September arbeitete der Security Researcher 3 Wochen seines Sabbaticals Vollzeit am Thema und der Koordination mit den Linux Distributionsanbietern (RedHat und Canonical).

Sowohl RedHat und Canonical hatten die Kritikalität ursprünglich mit einem CVS Score von 9.9 eingestuft. Anscheinend wurden mehrere Probleme gefunden, der Sicherheitsforscher spricht von mindestens 3 CVE-Nummern, die die verschiedenen Probleme eigentlich erhalten müssten.

Der eigentliche Disclosure Plan sah so aus:

  • September 30: Initial disclosure to the Openwall security mailing list.
  • October 6: Full public disclosure of the vulnerability details.

Zwischenzeitlich hatte der Researcher sogar seinen Account limitiert, da er zu viele Anfragen erhalten hatte. Dummerweise ist der Security Report aus dem stark eingeschränkten Vince Report System, in dem solche Lücken herstellerübergreifend koordiniert werdengeleaked worden und in einem Hacker Forum aufgetaucht.

Die Veröffentlichung wurde deshalb kurzfristig auf Donnerstag Abend, 20:00 UTC vorgezogen und im Blog des Researchers Simone Margaritelli vorgestellt. Das Writeup ist eine faszinierende Geschichte und vor allem das wie bestürzt – denn Simone kündigt an, dass dies sein letzter Versuch war, Open-Source sicherer zu machen.

Betroffen sind sämtliche Client Systeme, die einen lokalen CUPS Dienst mit aktiviertem cups-browsed Daemon laufen haben. In der Regel sind das Clients, oder auch Server-Systeme, die mit grafischer Oberfläche installiert sind. Initial wurde der Bug im Vince System mit einem CVE von 9,9 bewertet – nicht vom Researcher selbst, der sich dadurch in den sozialen Medien ein paar Vorwürfe eingefangen hat – auch wenn er nichts dafür konnte.

Unter „Personal Considerations“ erklärt Simone im Artikel, dass das finden und niederschreiben der Findings der einfache Part der Aktion gewesen sei. Er habe sich in über 50 Seiten rechtfertigen müssen, sei unschönen Argumenten und Vorwürfen begegnet, in die die Projekt Maintainer lieber die Energie gesteckt haben, als in das Fixen der Findings. Deshalb sei das Ganze dann auch etwas öffentlich eskaliert, da er dies irgendwann so nicht mehr ertragen konnte:

Two days for the research, 249 lines of text for the fully working exploit.

Twenty-two days of arguments, condescension, several gaslighting attempts (the things i’ve read these days … you have no idea), more or less subtle personal attacks, dozens of emails and messages, more than 100 pages of text in total. Hours and hours and hours and hours and fucking hours.

Kann man dann irgendwie auch nachvollziehen und hört sich stark einem ineffizienten System an.

Ach, der Blog Artikel heisst übrigens „Part 1“, denn es soll bald noch einen „Part 2“ geben, in dem es um macOS geht – hier laufe aber der Disclosure Prozess noch.

Attacking UNIX Systems via CUPS, Part I


Produkt Verbesserungen mit Friction Logs bei Stripe

In dieser Woche gab es spannenden Input zum Thema „Produktverbesserung“ durch Engineers und Developer. Wer kennt das nicht, man nutzt das eigene Produkt, stolpert über ein „Problem“ oder eine umständliche User-Experience, regt sich darüber auf, schreibt eine Chat-Nachricht oder Jira Ticket dazu – aber es passiert nichts?

Stripe hat daraus gelernt und einen formalen Prozess eingeführt – die Friction Logs.

Ein Friction Log hat mehrere Elemente:

  1. Den Context – Was hast du versucht zu machen und warum? Was wolltest du erreichen? Im Marketing spricht man hier von „Personas“, vielleicht hilft das zum Ausfüllen des Context
  2. Pros und Cons – Beschreibe die Vorteile aus deiner Sicht und auch die Nachteile von dem, wie du es aus deiner Sicht erlebt hast
  3. Detaillierte Experience – in diesem Bereich beschreibst du genau, wie die Nutzung des Produkts erlebt hast – ohne Struktur, am besten anhand der zeitlichen Reihenfolge. In diesem Teil können Screenshots, Videos und GIFs verwendet werden, die das Erlebnis für andere Nachvollziehbar machen

Im Beispiel des verlinkten Blog-Artikels wird das Thema „Friction Logging“ anhand eines Drucker-Set-ups erklärt. Das beginnt beim Auspacken, Dokumentation prüfen, aufstellen – etc. Ich denke, das macht das Thema gut verständlich.

Im Header des Friction Logs wird neben dem Autor und dem Daum noch der Aufwand, der beim Lesen und Nachvollziehen des Friction Log Eintrags entsteht, in einer T-Shirt Size ergänzt. Der Eintrag gibt noch weitere Tipps zum Friction Log – man soll beispielsweise auch Gefühle wie Glück oder Frustration erwähnen, dabei aber emotional intelligent vorgehen – das kennt man ja schon vom Postmorten.

Ein spannender Satz aus dem Artikel ist dieser hier:

Giving feedback is hard; receiving it is even harder

Das kann ich so unterschreiben – man vergisst teilweise auf beiden Seiten, dass man ja nur das Beste für die Firma / das Produkt möchte.

Für den schnellen Start zum Thema „Friction Log“ hat der zuständige Stripe Mitarbeitende ein Friction-Logging Toolkit auf GitHub veröffentlicht – dazu gibt es mit frictionlog.com eine Landingpage inklusive Podcast.

Ich kannte das Thema bisher nicht und finde es eine spannende Idee, um Produktverbesserungen oder „Feedback“ zum Userflow strukturiert und nachvollziehbar niederzuschreiben. Wie machst du das bisher?

How we use friction logs to improve products at Stripe


PostgreSQL 17 released

Während ich einige Applikationen noch auf PostgreSQL 12 und 13 sehe, manche nun auf 16 aktualisieren haut PostgreSQL mit Version 17 schon die nächste Version an den Markt.

In Version 17 hat man massiv an der Performance geschraubt und auch die Memory Struktur des „Vacuum“ Prozesses umgebaut – dieser soll nun 20 mal weniger RAM (nicht 20 %, 20 mal) benötigen und damit auch drastisch schneller sein.

Da Write-Ahead Log (WAL) soll dank Verbesserungen im I/O Layer bis zu 2 mal schneller sein.

Queries mit IN Clause werden dank Änderungen im B-Tree Index ebenfalls beschleunigt. PostgreSQL Experte Tobias Petry berichtet auf Twitter von 20-30 % Performance Verbesserungen in Benchmarks.

Dazu gibt es weitere Verbesserungen bei der Replikation und bei „High Availability“, sowie Verbesserungen bei Security und Operations.
Alle Änderungen findest du im verlinkten Release Artikel.

PostgreSQL 17 hat nun 5 Jahre Support bis zum 8. November 2029 – der Support für PostgreSQL 12 endet im November 2024.

PostgreSQL 17 Released!


Cloudflare baut AI Scraping Marktplatz

Cloudflare baut aktuell an einem Marktplatz für Content-Anbieter, auf dem man selbst ausgewählten AI-Scraping-Bots Zugriff erteilen und auch Geld verdienen kann. Sprich, du kannst in Zukunft einstellen, welche Bots von welchem Anbieter auf deine Seite dürfen und welche nicht.

Seit letzten Montag können Cloudflare Kunden im AI Audit Dashboard Bot Besuche analysieren und prüfen, welcher Bot von welcher Firma wieviele Requests auf die eigene Seite abfeuert. Manche machen nämlich ganz schön viele Requests – habe ich selber neulich einen Fall bearbeitet, bei dem 2 Bots 60 % des Traffics ausgemacht haben.

Schlimm wird es, wenn die Bots sich nicht an die Anweisungen der Robots.txt halten und diese eher als Empfehlung verstehen oder gar ignorieren. Cloudflare CTO John Graham-Cumming hat nun auf Twitter auf die Ignoranz des Amazonbot hingewiesen, der auf seiner eigenen Homepage die Robots.txt einfach ignoriert hat.

Wie genau die Monetarisierung später ablaufen soll ist aktuell noch unklar und Cloudflare CEO Matthew Prince bleibt dazu im Announcement vage. Fest steht nur, dass es in Zukunft eine Möglichkeit geben soll, wie die Content Creatoren für ihre Werke entlohnt werden sollen.
Schließlich könne der einzelne Creator keinen Deal mit einem AI Model Provider verhandeln – ggf. kann man auch einfach den gewünschten Preis einstellen und der AI Provider kann diesen dann akzeptieren oder nicht.

Falls man möchte, kann man sich hier für einen Test des neuen „AI Value Tool“ bewerben – es gibt eine Waitlist und eine Demo soll bald erfolgen.

Cloudflare’s new marketplace will let websites charge AI bots for scraping


Feedback zu Return-to-Office bei Amazon

Zu meinem „Return-to-Office“ Artikel aus der letzten Woche habe ich ein wenig Feedback erhalten – vielen Dank dafür!

Wolfgang und Andy vom Engineering Kiosk Podcast hatten in Folge 142 den IFO Wissenschaftler Jean-Victor Alipour zu Gast. Im Podcast beschrieb Jean-Victor dann, dass nur 4% der Unternehmen darüber nachdenken, Home Office wieder abzuschaffen. Hör dir gerne mal die Folge an, im Artikel zum Podcast sind auch viele Quellen verlinkt – unter anderem vom IFO Institut selbst.

Jean-Victor Alipour hatte dann bei mir in LinkedIn zum Newsletter kommentiert, da mich interessiert hat, ob dies nur in Deutschland so sei. In den USA ist das ähnlich und Amazon sei erstmal ein Ausreisser. Er verwies mich auf eine LinkedIn Analyse der Änderung bei Amazon, die unter anderem eine Fluktuation von 30 % berechnet.

Der Autor der Analyse ist Stanford Professor Nick Bloom und laut seiner Meinung könnten viele Startups dem Beispiel Amazons folgen, wie es schon häufig passiert sei. Zusätzlich zitiert er aber eine Statistik, die keine Änderung bei der „Work from Home“ Zahl erkennen lässt.
Wir lesen immer nur von Firmen, die die Leute zurück ins Büro schicken, dabei sei es auch völlig normal, dass Firmen andersrum agieren – dazu gebe es dann aber keine Presseartikel.

Return to Office und Bürokratieabbau bei Amazon


Raycast sammelt $30 Millionen ein

Die beliebte Mac „productivity“ App Raycast, die in meinem Alltag gar nicht mehr wegzudenken ist, raised $30 Millionen in einer Series-B-Runde. Raycast gibt es als Open Source, oder als bezahlten Pro-Account mit zusätzlichen Features wie Sync, custom Search und vor allem „Raycast AI“, einem Helfer inkl. Suche und mehr.

Ich habe das bisher nicht benötigt; mir genügt die kostenlose Variante, die auch Zugriff auf die unzähligen Extensions im Marketplace von Raycast hat. Da ist etwa Microsoft TeamsSlack oder auch GitLab Integration dabei. Vor allem nutze ich es aber für das Verschieben meiner Tabs auf dem Screen und für die Suche in der Zwischenablage (Clipboard History).

Als Engineer nutzt man ja ohnehin viel das Keyboard – die Shortcuts für häufig genutzte Funktionen sind mit Raycast viel schneller erreichbar. Kurzum, die App ist sehr beliebt – deshalb sollen nun auch Windows und iOS-Nutzer in den Genuss von Raycast kommen – hierfür soll das viele Geld nämlich verwendet werden.

Ich hoffe, dass die App ansonsten bleibt, wie sie ist – mit dem offenen Marktplatz und allem Drum und Dran. Das Team von Raycast sitzt übrigens in London und mittlerweile arbeiten 30 Menschen dort.

Raycast raises $30M to bring its Mac productivity app to Windows and iOS


Schmunzelecke

Der Source Code des legendären MP3 Players Winamp ist nun auf GitHub verfügbar. Winamp wurde 1997 released – schon ein Weilchen her.
Es gibt schon über 1000 Issues im GitHub Projekt – da sieht man dann aber mal wieder, warum sowas nicht ganz so einfach ist.


💡 Link Tipps aus der Open Source Welt

00 – E-Mail Service Alternative zu Sendgrid, Postmark & Co.

Mit 00 – Double Zero – kommt ein Open Source E-Mail Service, welcher transaktionale E-Mails, deren Tracking, WYSIWYG Editor und vieles mehr anbietet. Double Zero setzt einen AWS Account voraus, da es im Hintergrund SES für den Versand und SNS & SQS verwendet.

Dann kannst du Double Zero verwenden, um Templates anzulegen, E-Mails zu designen und zu versenden. Double Zero stellt auch den Zustellstatus vernünftig dar – etwas, was in AWS immer etwas Pain war.

Das Tool selbst gibt es in der Basis Version Open Source – und es gibt aktuell eine Pre-Order der Pro Version für 175 $ als Lifetime Deal – hier bekommst du dann aktuell noch Kontakte, den Editor und später Teams, den Feed, einen SMTP Endpoint und Automatisierungen als Features.

Damit hast du dann eine tolle Alternative zu den ansonsten doch recht gut „finanziell skalierenden“ SaaS Angeboten.

https://github.com/technomancy-dev/00

STU – Open Source S3 Terminal UI

STU ist ein Open Source Terminal UI für S3. Mit STU kannst du S3 Buckets browsen, sortieren, filtern, Dateien und Bilder ansehen und direkt herunterladen. Damit ist eigentlich schon alles gesagt – in diesem GIF Video siehst du in Kürze, wie das funktioniert.

STU wird über Optionen gesteuert und kann neben AWS S3 auch mit anderen S3 kompatiblem Storages arbeiten, beispielsweise mit Minio. Auf dem Mac kannst du STU einfach mit $ brew install lusingander/tap/stu installieren – ansonsten geht es auch via cargo oder paru für Arch Linux.

https://github.com/lusingander/stu


❓ 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:

526 Abonnenten sind schon dabei - Vielen Dank!

Please enter a valid email address
Diese E-Mail ist bereits registriert.
The security code entered was incorrect
Vielen Dank für Deine Anmeldung - bitte den Opt-In bestätigen.


  • Neueste Beiträge

  • Neueste Kommentare


  • Share

    By About
    Abonnieren
    Benachrichtige mich bei
    guest

    0 Comments
    Oldest
    Newest Most Voted
    Inline Feedbacks
    View all comments

    allesnurgecloud.com

    © 2024 allesnurgecloud.com
    0
    Would love your thoughts, please comment.x