Willkommen zu allesnurgecloud.com – Ausgabe #257
Dass die Midterms die politische Lage „etwas“ geändert haben, hast du ja sicher mitbekommen. Sicherlich auch, dass die Börse dann einen kleinen Kursturz erlebt hat. Aber wusstest du auch, dass die Wähler in 41 Abstimmungen zusätzlich zum weiteren Datacenter Ausbau befragt wurden? In 40 Fällen haben die Wähler gegen eine Ansiedlung eines Datacenters in ihrem Wahlgebiet gestimmt. Nur in Harwood, North Dakota stimmte man dafür (mehr bei CNBC).
Zusätzlich ist unklar, ob Anthropic zum gewünschten Preis an die Börse gehen kann – ich würde jetzt gerade nicht drauf wetten. Es kam nun raus, dass Clode Caude beim Browsing auf Websites die Account E-Mail im User-Agent mitgeschickt hat – das passiert dann halt, denn die KI mit KI weiterentwickelt wird – leider ist der Bug noch nicht zu.
Auch in dieser Woche ist die Security Ecke nicht zur Ruhe gekommen – diverse Supermärkte hatten Probleme und Kühltruhen versagten oder wurden zum „Heizen“ überredet. Die Binance Hacking Story wird in mancher HR Abteilung sicherlich für Erschrecken gesorgt haben – hat man nicht den Engineers in einem Fake-Job-Interview mit einer Fake Firma einen tollen neuen Job angeboten, inklusive Termin mit Fake CEO. Blöderweise hat man dann die Coding Challenge auf den Arbeitsrechner installiert, und der Rest ist Geschichte (mehr bei Reuters und the Register).
Dann berichtet Golem von über 11.000 gefährdeten GitLab-Instanzen – Leute, das kann doch nicht unser Ernst sein? Man muss das doch am gleichen Tag, besser zur gleichen Stunde patchen?
Und noch einmal der kurze Hinweis auf meinen Gastauftritt bei Hannes Zwetschke im Podcast ZWETSCHKE +1 (YouTube, Spotify, Apple) – bei YouTube braucht der noch paar Views, damit ich vor den Promis und Schauspielern lande. 🙂 Vielen Dank an alle, die sich das schon hereingezogen und mir Feedback geschickt haben.
So, und nu – viel Spaß mit der Ausgabe.
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 196 habe ich mit Christian Häfner von Rechnungskit aus Flensburg gesprochen. Seinen Kaffee-Abo-Shop Happy Coffee betreibt er seit Jahren fast vollautomatisch und ohne Mitarbeiter. Mit KI hat er programmieren gelernt, das Shopsystem neu gebaut und aus der eigenen Buchhaltung eine Software für E-Rechnungen gemacht. Über die laufen inzwischen mehr als 3 Millionen Euro an Zahlungen, und das ganz ohne Team und ohne Investoren. Wir reden darüber, wie er 1.000 Abos migriert hat und warum alle Kunden bisher über LinkedIn kamen. Gerne kannst du die Folge auf YouTube schauen oder wie immer bei Spotify, Apple und allen anderen Playern anhören.
Wenn dir die Podcastfolgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).
So, nun endlich die News der Woche in der Übersicht:
- Revolut hostet GLM selbst und spart (angeblich) 90 %
- 15.579 infizierte Websites – bloß wie erreicht man die Inhaber?
- Bloddy Oktober und das neue Normal
- Slack und GitHub: Was Skalierung wirklich kostet
- MacBooks im Rechenzentrum: Mac at any Scale
- sshole in Alpine Linux: SSH-Login mit „einfachem“ Passwort
- Railway-Breach: 100.000 Workspaces betroffen
- Endurain: Von Codeberg zurück zu GitHub
Support the Newsletter
Übrigens kannst Du meine Arbeit nun auf Patreon supporten, mir ein Bier ausgeben oder mal auf meiner Amazon-Wunschliste vorbeischauen – Danke! Falls du Interesse hast, im Newsletter oder Podcast Werbung zu buchen, kannst du das auf passionfroot machen oder mir einfach ne E-Mail als Antwort auf den NL schicken.
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:
Revolut hostet GLM selbst und spart (angeblich) 90 %
Du hast es vermutlich schon bei LinkedIn gelesen – da ist ein wöchentlicher Newsletter einfach spät dran. Wollte es trotzdem in der Ausgabe haben: Rund 2.000 Engineers bei Revolut arbeiten inzwischen standardmäßig mit einem selbst gehosteten GLM-Modell von Z.ai statt mit Claude Code oder Codex. Die Rechnung liege bei etwa einem Zehntel, berichtet Trending Topics vom Vortrag von David Abitbol auf der AI Engineer in New York.
Das Setup: ein MoE-Modell mit rund 800 Milliarden Parametern auf 56 Nvidia B200. Bei FP16 bräuchte allein das Modell etwa 1,6 TB VRAM, mit FP8 rund 800 GB und mit 4-Bit-Quantisierung etwa 400 GB. Die 56 GPUs reichen also für mehrere Replikas. Revolut nennt 30 Cent pro Million Tokens. Die Time to First Token sank nach dem Tuning von über 10 auf 1,6 Sekunden. Der Kontext ist auf 256.000 Tokens gedeckelt.
Mehr sagt mir die Zahl daneben: Die Lead Time fiel um 70 Prozent, die reine Coding-Zeit um 60. Der Engpass liegt offenbar eher bei Jira, Confluence und dem Postfach als beim Tippen.
Die 90 Prozent enthalten allerdings weder Hardware noch Personal oder Monitoring. 56 B200 kosten je nach Rechnung 1,7 bis 3,5 Millionen Dollar, bevor auch nur Strom fließt. Gehostet wird übrigens in den USA.
Wer das ohne eigenen GPU-Park testen will: Melious aus Saarbrücken bietet GLM 5.3 nach eigenen Angaben aus europäischen Rechenzentren an. Das kostet 1 Euro Input und 3 Euro Output pro Million Tokens, als Abo gibt es das ab 49 Euro im Monat. Wie man Claude Code auf solche Endpoints umbiegt, steht in Ausgabe 233.
Revolut Cuts A.I. Coding Costs 90% With a Chinese Open-Weight Model
15.579 infizierte Websites – bloß wie erreicht man die Inhaber?
Rund 15.579 Websites liefern gerade nachweislich Schadcode per JavaScript aus. Zusammen kommen sie nach konservativer Schätzung auf 135 Millionen Besuche im Monat. Das Problem beschreibt Scott Helme in seinem Blog: Sein Dienst Report URI findet die Infektionen inzwischen schneller, als das Team die Betreiber benachrichtigen kann.
Gefunden werden Kreditkarten-Skimmer im Magecart-Stil und ClickFix-Seiten mit falschem „Beweise, dass du ein Mensch bist“. Dazu kommen Exploits gegen bestimmte iOS-Versionen und Redirects auf Phishing-Seiten. Auf die Seiten gelangt der Code über kompromittierte WordPress-Installationen, infizierte Third-Party-Skripte, klassisches XSS und über „DeadTag“. So nennt Report URI eine Gruppe, die abgelaufene Domains kauft, von denen Seiten noch Skripte nachladen. Das Muster kennst du von Polyfill aus Ausgabe 148.
Betroffen sind vor allem regional starke Seiten, auffällig viele davon unter .de, .fr und .es. Die direkte Ansprache skaliert nicht: Kaum jemand hat eine security.txt (siehe Ausgabe 224), und die meisten Mails bleiben unbeantwortet. Helme bittet deshalb europäische CERTs, sich zu melden. Gleichzeitig wirbt er für den kommerziellen Zugriff auf seine Threat-Intel-Feeds. Das sollte man beim Lesen im Hinterkopf behalten.
Für die eigenen Seiten heißt das: externe Skripte inventarisieren, wo möglich selbst hosten, eine Content Security Policy setzen und Subresource Integrity nutzen – siehe auch letzte Woche den Polymarket-Angriff via DebugBear. Außerdem regelmäßig prüfen, ob die eingebundenen Domains überhaupt noch dem ursprünglichen Anbieter gehören. Ich ziehe übrigens meine Domains von Domainfactory zu UnitedDomains um, da gibt es jedenfalls 2FA.
Für das Problem von Scott Helme wäre aus Hoster-Sicht der Weg über die Abuse-Kontakte der Provider naheliegend. Die stehen im Whois der IP-Adresse und reagieren meist schneller als ein Website-Betreiber, der seine Mails nicht liest.
We Know 15,579 Websites Are Infected. How Do We Tell Them?
Anzeige
In eigener Sache: Statuswerk, die Statusseite aus Europa
Wenn etwas ausfällt, wollen deine Kunden zuerst wissen, ob ihr es schon merkt. Mit Statuswerk informierst du sie, bevor das Support-Postfach überläuft. Gehostet wird bei unabhängigen Anbietern in Deutschland, E-Mail und SMS laufen über EU-Dienste. Eine US-Cloud ist nicht im Spiel.
Was drin ist:
- Störungen und Wartungen veröffentlichen, mit Updates und Uptime-Historie pro Komponente
- HTTP-Monitoring aus 6 Regionen bei Hetzner und UpCloud: Ein Ausfall zählt erst, wenn eine zweite Region ihn bestätigt. Während einer geplanten Wartung bleibt der Check natürlich still
- Abonnenten bekommen eine E-Mail oder SMS, dein Team die Meldung in Slack, Teams, Discord oder Google Chat
- Vier-Augen-Freigabe und Audit-Log: Auf Wunsch geht eine Incident oder Maintenance-Meldung erst raus, wenn eine zweite Person sie freigegeben hat
- REST-API, Webhooks und MCP, damit Incidents direkt aus Grafana, Prometheus oder deiner CI/CD entstehen
- Eigene Domain mit Auto-SSL, White Label und private Statusseiten hinter Passwort oder IP-Filter
Jetzt auf die Warteliste: Die geschlossene Beta läuft, die ersten Einladungen gehen gerade raus.
Beta-Teams nutzen Statuswerk 6 Monate kostenlos und reden bei der Roadmap mit.
Bloddy Oktober und das neue Normal
Zwei RCEs in PHP, eine Zertifizierungsstelle mit dem Private Key „4“, entschlüsselte Env-Variablen bei Railway, zwei CVSS-10-Lücken in GitLab, ein erneut kompromittiertes LiteLLM-Paket auf PyPI und Kernel-Lücken auf der falschen Mailingliste. All das passierte in rund einer Woche im Oktober. Drew Silcock hat die Vorfälle gesammelt und fragt, ob das jetzt normal ist.
Bei PHP2Shell fanden zwei Teams die Lücken mit Frontier-Modellen. Eine davon stand schon in einem Audit von 2024, nur konnte damals niemand einen Exploit bauen. Nach Leaks und verfrühten Fixes wurde die Lücke angeblich schon vor dem Patch ausgenutzt. Silcocks Schluss: Ab der Ankündigung eines Security-Patches sollte man davon ausgehen, dass ein Exploit existiert. LLMs lesen den Diff schneller als Admins die Advisory.
Bei den Gegenmitteln bleibt er skeptisch, auch bei einer Minimum Release Age, weil sie dringende Fixes verzögert. Gegen gekaperte Pakete hilft sie trotzdem. Composer 2.11 bringt dafür eine Cooldown-Periode mit: Über config.policy.cooldown.period, etwa mit „1 day“, landen frisch veröffentlichte Versionen erst nach Ablauf dieser Frist in einem composer update. Laut Packagist kamen die meisten Schadversionen zuletzt von Angreifern, die kurz einen legitimen Account übernommen hatten. Malware-Scanner schlagen oft schon nach Minuten an. Für einen dringenden Fix setzt man gezielt –no-cooldown, die übrigen Policies bleiben aktiv. Standardmäßig ist die Cooldown-Periode aus – finde ich ne sehr coole Option und die sollte es wohl in jedem Framework geben.
Für den Betrieb heißt das: Neue Abhängigkeiten dürfen etwas warten, Security-Patches nicht. Zwischen Advisory und Exploit liegen inzwischen eher Stunden als Tage.
Slack und GitHub: Was Skalierung wirklich kostet
Warum erlaubt Slack pro Nachricht eigentlich nur 23 verschiedene Custom-Emojis als Reaktion? Die Erklärung liefert Maude Lemaire im Podcast The Pragmatic Engineer bei Gergely Orosz. Sie hat bei Slack fast acht Jahre das Backend-Performance-Team geführt. Danach war sie bei GitHub für die Datenbank-Skalierung zuständig und hat zuletzt bei Cursor an der Performance gearbeitet.
Das Limit verhindert Thundering Herds. Postet der CEO in einem Channel mit 100.000 Mitgliedern, dass Freitag frei ist, muss jede Emoji-Reaktion an alle Clients raus. Bei 100 Custom-Emojis sind das 10 Millionen Fan-outs. Das 24. Emoji vermisst in der Praxis sowieso niemand.
Für einen Neukunden mit 500.000 Usern brauchte Slack einen Lasttest. Mit Headless-Chrome-Instanzen hätte ein Durchlauf rund 150.000 Dollar gekostet. Ihr Team baute stattdessen Koi Pond, ein Go-Tool, dessen abgespeckte Clients nur WebSocket-Verbindungen aufbauen und API-Calls schicken.
Bei GitHub war dann Active Record das Problem. Die Startseite löste regelmäßig rund 100 SQL-Queries über drei Datenbank-Cluster aus, viele davon ohne Sharding-Key. Solche Scatter Queries laufen über alle Shards und werden mit jedem weiteren langsamer. Bei 16 Shards war deshalb Schluss. Wie groß die MySQL-Flotte dahinter ist, stand in Ausgabe 131.
Ihre Trennung bei der KI-Nutzung gefällt mir: Bei Plattform-Arbeit prüft sie jede LLM-Ausgabe selbst, beim Rest darf es lockerer zugehen. Und die bequeme ORM-Abstraktion stellt ihre Rechnung eben woanders aus, nämlich bei den Leuten, die die Datenbank betreiben.
Scaling Slack and GitHub with Maude Lemaire
MacBooks im Rechenzentrum: Mac at any Scale
Hunderte MacBook Pros im Rack, jedes mit IP-KVM, externer 10G-NIC und vier Kabeln. Klingt nach Schnapsidee. Kirill Nikolaev beschreibt es im Blog von Namespace, das genau diese Mac-Instanzen verkauft, aber als nüchterne Lieferketten-Entscheidung: Die bestellten Mac Minis kamen erst nach sechs Monaten, und das aktuelle M-Modell gab es zuerst im Laptop. Wer iOS-Apps bauen will, braucht nun mal einen Mac. Auf Twitter gibt es ein Unboxing Video aus dem August – fast 29 Millionen Views bisher.
Die Probleme kamen von unerwarteter Stelle. Am unzuverlässigsten war nicht MagSafe, sondern das HDMI-Kabel. Namespace hat nach eigenen Angaben den kompletten Bestand eines passenden Modells bei Amazon aufgekauft. Nach einem ungeplanten Reboot wartet FileVault auf das Passwort, und der Prompt verschwindet nach fünf Minuten, auch beim Entsperren per SSH. Dann bleibt nur der physische Knopf. Für geplante Reboots hilft fdesetup authrestart.
Technisch interessanter ist die Virtualisierung. Apple erlaubt nur zwei macOS-VMs pro Mac, ein 14-Core-Mini wird deshalb in 2, 6 und 6 Kerne aufgeteilt. Das Netzwerk läuft über den Userspace-TCP-Stack aus gVisor und schafft rund 4 Gbit/s. Die VM-Images wachsen mit iOS-Runtimes schnell auf 500 GB. Namespace speichert sie deshalb als Sparse-Layer in einer OCI-Registry, verteilt sie per BitTorrent-ähnlichem P2P über die Flotte und legt sie per APFS-Clonefile platzsparend ab.
Auf Hacker News hält willmeyers vor allem Apples Limit von zwei VMs für Verschwendung. Wie AWS das mit Mac Minis per Thunderbolt löst, stand in Ausgabe 123.
Mich würde noch interessieren, was der Brandschutz zu hunderten Lithium-Akkus im Rack sagt. Dazu schweigt der Artikel. Oder es läuft da einfach anders
sshole in Alpine Linux: SSH-Login mit „einfachem“ Passwort
Ein Passwort aus 300 Mal „A“ reicht, und man ist drin. Betroffen ist OpenSSH auf musl ohne PAM, also vor allem Alpine. Özgün Kültekin von Wakefield hat die Lücke gefunden und die Geschichte dahinter sehr unterhaltsam aufgeschrieben. Mit dabei waren Agent-Schwärme, die rund 17.600 seltsame Logins gegen 12 sshd-Builds gefeuert haben.
Die Ursache ist eine Kette aus vernünftigen Einzelentscheidungen. Seit 1980 steht ein Stern im Passwortfeld für „hier passt kein Passwort“. musl lässt crypt() seit 2012 bei Fehlern statt NULL ebenfalls einen Stern zurückgeben und lehnt aus DoS-Gründen Passwörter über 256 Bytes ab. sshd wiederum hasht seit 2016 auch bei Accounts ohne Hash mit dem Salt eines anderen Users, als Schutz gegen Timing-Angriffe. Das Ergebnis: Stern trifft Stern, Login erfolgreich.
Laut Alpine-Advisory braucht es dafür einen Account mit Stern im Passwortfeld (root seit Alpine 3.16, Key-only-User, LDAP-User) und mindestens einen weiteren mit $5$- oder $6$-Hash. Betroffen sind Alpine 3.16 bis 3.24 und edge. Bei den offiziellen tiny-cloud-Images hat der User alpine passwortloses doas, damit ist man root. Die Lücke läuft als CVE-2026-123158 mit CVSS 8.1.
Zum Fix: apk upgrade -U -a und danach rc-service sshd restart, ein Reboot ist nicht nötig. Das Paket-Update allein ersetzt den laufenden Daemon aber nicht. Wer nicht sofort patchen kann, setzt PasswordAuthentication no. Container ohne sshd, Setups mit UsePAM yes und Cloud-Images mit cloud-init sind nicht betroffen. Prüfen lohnt sich trotzdem: In /var/log/messages nach „Accepted password“ für Accounts ohne Passwort suchen.
Nach regreSSHion aus Ausgabe 149 ist das wieder eine Lücke, die jahrelang offen lag. PasswordAuthentication no gehört für mich ohnehin in jede Baseline. Ach, und die APT‑Lücke nicht vergessen (CVE-2026-109518) – irgendwie patchen wir also doch bald täglich…
Security advisory: openssh-server password authentication bypass
Railway-Breach: 100.000 Workspaces betroffen
Im Preliminary Report zum Railway Breach von letzter Wocheschreiben die Gründer, ein Angreifer sei vom 20. Oktober, 13:58 UTC bis zum 22. Oktober, 03:32 UTC in internen Systemen unterwegs gewesen. Ziel sollen API-Keys von KI-Anbietern gewesen sein, um damit Distillation zu betreiben, also fremde Modelle über deren Outputs nachzutrainieren.
Der Weg dorthin: Privilege Escalation in der Build-Infrastruktur, dann Credentials aus der CI-Umgebung, mit denen sich Artefakte und schließlich ein Teil der envelope-verschlüsselten Environment Variables entschlüsseln ließen. Betroffen seien höchstens 1,85 % der Workspaces, rund 100.000. Bei GitHub, OpenAI, Anthropic und Co. ließ Railway vorsorglich Keys sperren, teils einfach alle. Im HN-Thread berichtet MattIPv4 von Discord-Nutzern, deren Secrets bereits von Dritten verwendet wurden.
Laut Bericht habe der Angreifer Zugriff auf „abliterated models“ und viel Compute gehabt. Gemeint sind offene Modelle, aus deren Gewichten die Verweigerungslogik herausgerechnet wurde. Das klingt nach neuer Bedrohungsklasse und lenkt elegant von der Frage ab, warum eine CI-Umgebung Schlüssel bereithält, mit denen sich Kundensecrets entschlüsseln lassen. Die Single-Tenant-Builder waren übrigens ohnehin für die Woche darauf geplant.
Wer Railway nutzt, rotiert alle vor dem 21. Oktober hinterlegten Variablen, nimmt Datenbanken aus dem öffentlichen Netz und prüft die Audit-Logs bei GitHub und in der Registry. Nach dem Volume-Fiasko aus Ausgabe 234, bei dem die Backups im selben Volume lagen, ist das der zweite Vorfall in diesem Jahr, bei dem Railways eigene Architektur das Problem ist
Preliminary Report: Oct 21st Security Incident
Endurain: Von Codeberg zurück zu GitHub
Nach dem Umzug zu Codeberg zieht der selbst gehostete Fitness-Tracker Endurain wieder zurück zu GitHub. Maintainer João Vitória Silva nennt im aktuellen Projekt-Update gleich mehrere Gründe.
Zuerst die Verfügbarkeit: SSH-Zugriffe und Commits schlugen wiederholt fehl, Codeberg war zeitweise ganz weg. Für ARM64-Images musste das Team einen eigenen Forgejo Runner betreiben, und auch der lief nicht stabil. Der Android-Build klappte mal, mal nicht.
Gewichtiger ist der zweite Grund. Im Juli haben die Mitglieder von Codeberg e.V. mit 358 zu 144 Stimmen die Nutzungsbedingungen geändert. Projekte, die überwiegend mit LLMs geschrieben und gepflegt werden, sind dort seitdem nicht mehr erwünscht. Endurain nutzt KI-Tools und nimmt KI-gestützte PRs an. Ob das unter „überwiegend“ fällt, weiß niemand so genau, und diese Unschärfe war dem Team zu riskant. Auf HN fragte KingOfCoders damals, ob schon IDE-Refactoring als KI-Code zählt.
Ironischerweise ist Silva selbst Codeberg-Mitglied und findet die Mission gut. Auch GitHub sei nicht fehlerfrei, sein Account war drei Wochen ohne Begründung gesperrt. Eine eigene Forgejo-Instanz hat das Team bewusst verworfen, weil schon der eine Runner genug Zeit gefressen hat.
Ich selbst bleibe bei GitLab und Forgejo im Eigenbetrieb, nicht zuletzt wegen GitHub-Ausfällen wie dem in Ausgabe 250. Für ein Freizeitprojekt ist der Wartungsaufwand aber ein echtes Argument dagegen.
Schmunzelecke
„A bash script that emails Sam Altman once a day to report the RAM he missed.“ gibt bei ram-altman.lol – lol!
Für alle Kinderzimmer ein Must-have – der „Stringman“ Roboter, der im Zimmer alles aufräumt. Ob das in der Praxis funktioniert?
💡 Link Tipps aus der Open Source Welt
SuperPlane – Open-Source-„Factory“: Backlog-Issues werden per AI Agent fertige Pull Requests
SuperPlane will Routinearbeit wie kleine Bugs, Test-Fixes oder Doku-Updates komplett an Coding Agents abgeben (Siehe schicke website). Das Tool bewertet die Issues im Backlog, sucht sich die heraus, die ein Agent mit hoher Wahrscheinlichkeit lösen kann, und steuert Implementierung, CI, Review und Freigaben in einem gemeinsamen Ablauf. Am Ende steht ein geprüfter Pull Request, über den ein Mensch entscheidet.
Key Features:
- Factory Board: Kanban mit Backlog, Implement, Verify und Done, auf dem jeder Agent-Lauf nachvollziehbar ist
- Task Refinement: Issues werden vorab analysiert und zu einem Plan verfeinert, offene Entscheidungen gehen vor der Umsetzung an das Team
- Verifikation: Fehlgeschlagene Checks gehen mit Kontext zurück an den Agent, ein Agent Review schätzt danach die Merge Confidence ein
- Workflow-Bausteine: Auf Events aus anderen Tools warten, Agents aufrufen oder Approvals von Menschen einholen
- Model-Wahl: Modelle frei wählbar, unter anderem über OpenRouter
- Forges: GitHub inklusive Enterprise Cloud und Bitbucket, auch mit Tasks über mehrere Repos
Geschrieben in Go mit TypeScript-Frontend. Läuft als SaaS oder self-hosted per Docker Compose auf einer Linux-VM bzw. per Helm auf Kubernetes (AWS, Azure, GCP).
Passend zum Octoverse-Report, laut dem schon über 40 Prozent der Pull Requests mit einem Agent starten, setzt SuperPlane den nächsten Schritt um: Statt einzelne Agent-Sessions zu betreuen, laufen die Issues durch eine Pipeline. Mit 8.800 Stars, 83 Contributors und 81 Releases ist das Projekt aktiv, die vielen Commits von cursoragent und superplaneagent zeigen, dass es selbst so gebaut wird. Apache 2.0 gilt allerdings nur für die „Engine“. Custom Roles und Gruppen stecken im Enterprise-Verzeichnis hinter einer Lizenz, es ist also klassisches Open Core.
https://github.com/superplanehq/superplane
Forklift – VMs von VMware, Hyper-V und Co. nach KubeVirt migrieren
Forklift migriert virtuelle Maschinen in großer Zahl nach KubeVirt, also auf Kubernetes. Du hinterlegst die Zugangsdaten für Quelle und Ziel, mappst Netzwerke und Storage, baust daraus einen Migrationsplan und führst ihn aus. Das Projekt läuft als Operator im Cluster und ist das Upstream-Projekt hinter Red Hats Migration Toolkit for Virtualization (MTV) für OpenShift Virtualization.
Key Features:
- Viele Quellen: VMware, oVirt, OpenStack, Nutanix, Hyper-V und KubeVirt, laut Projektbeschreibung außerdem OVA, EC2 und Azure
- Warm Migration: Für VMware und oVirt über Change Block Tracking bzw. Incremental Backup, das hält die Downtime klein
- Offload Copy: Bei VMware kopiert das Storage-Array die Disks direkt, inzwischen auch für VMs auf NFS
- Guest-Konvertierung: virt-v2v installiert die virtio-Treiber und passt das Gastsystem an QEMU/KVM an
- Cluster-übergreifend: Live-Migration zwischen KubeVirt-Clustern über die Export API, Steuerung entfernter Cluster aus einer Installation
- Validierung: Prüft den Migrationsplan vorab auf Probleme, die Regeln sind in Open Policy Agent (Rego) geschrieben
Geschrieben in Go, lizenziert unter Apache 2.0. Builds gibt es für AMD64 und ARM64.
Wer nach der Broadcom-Übernahme raus aus VMware will und sowieso schon Kubernetes betreibt, findet hier eines der wenigen ausgereiften Open-Source-Tools für den Umzug. Die 213 Stars und das eine GitHub-Release führen etwas in die Irre: Das Projekt ist sechs Jahre alt, hat 71 Contributors und wird von Red Hat täglich weiterentwickelt. Wie bei vielen Red-Hat-Upstreams ist es aber spürbar auf OpenShift zugeschnitten. Auf einem Vanilla-Kubernetes musst du beim Deployment mehr selbst erledigen, und die Doku setzt einiges an KubeVirt-Wissen voraus.
https://github.com/kubev2v/forklift
❓ 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: