Unboxing Uberspace8
Seit einiger Zeit geht ein Gespenst um bei Uberspace - über das wir bisher nur in gehauchter Erwähnung sprechen, aber jetzt endlich beim Schopfe packen und in die Details gehen wollen: unser aktuelles Uberspace7 steht schon mit einem halben Bein im Ruhestand während wir beim Nachfolger noch an der Werkbank stehen und Codeblöcke zurechtschneiden, also, wie sieht es denn damit aus? Was wird sich ändern? Warum soll sich überhaupt etwas ändern? Und vor allem: Wann?
Let’s talk about Uberspace8 !
Ein kleiner Rundumschlag erstmal - breaking the ice
Bisher war unser Informationsfluss nicht so, wie wir uns das normalerweise wünschen. Eigentlich hätten wir schon viel früher mehr Details zu unseren neuen Planungen und Entwicklungen veröffentlichen wollen und euch als Nutzer:innen des Produkts mehr daran teilhaben lassen. Tatsächlich merken wir aber sogar innerhalb unseres Teams, dass es schwierig ist, alle am sehr dynamischen Informationsflow unserer Großbaustelle teilhaben zu lassen und die verschiedenen Interessen und Perspektiven zu bedienen.
Zum Beispiel: wenn wir im Dev-Team endlich die CI-Pipelines gebändigt haben, die uns täglich eine neue U8 Test VM aufsetzen sollen, dort mit einem Base-Installer ein frisches OS bauen und einspielen, das Core Playbook dagegen deployen, frisch gebaute Python Packages installieren und dann sogar noch automatisierte Tests dagegen laufen lassen, dann haben wir aus unserer Entwickler:innen-Perspektive einen großen Meilenstein erreicht und gefühlt einen Drachen mit mindestens 7 Köpfen erlegt. Andere aber verleitet das möglicherweise nur zu einem müden: “Aha, da ist jetzt ein blanker Host, auf dem ich mich per SSH einloggen kann?”. Ok ja, fair enough.
Außerdem ist es in der IT ja eh immer ein bisschen schwierig etwas “vorzeigbares” zu produzieren, vor allem wenn wir, wie bei U8, an vielen einzelnen Komponenten für eine neue Infrastruktur bauen, die erst ihre Wirkung entfalten, wenn wir sie zusammenkoppeln können. In den letzten Wochen haben wir hier aber ein paar elektronische Schäfchen ins trockene gebracht: der selbst gebaute Pacman Mirror ist aktiv, unser Marvin hat seine gröbsten Umstrukturierungen hinter sich, die Testinfrastruktur flutscht und wir haben Web und Mail!
Damit sind wir jetzt in der besten Zeit angekommen einen Einblick in die U8 Baustelle zu geben und starten hier erstmal mit einem Übersichtsartikel zu den einzelnen Komponenten, um später in weiteren Blogposts in die Details gehen zu können (ok, das ist natürlich etwas gefährlich, hier weitere Texte anzukündigen die noch nicht geschrieben sind, aber hey, no pressure 🤞).
So wird Uberspace8
Marvin
Auf U7 ermöglicht der Paternoster, dass User in ihrem Userspace commands ausführen können, zu denen sie eigentlich keine Berechtigung haben. Und auch wenn das eigentlich erstmal gut tut, ist es nicht mehr wirklich schön, da wir hier sämtliche Userfacts dezentral in Dateien verteilt auf rund 250 Hosts herumliegen haben. Diese einzusammeln führt dann zu den typischen Wartezeiten beim uberspace command. Trotz aller Nostalgie für den Paternoster, bei U8 war schon lange klar, dass wir das anders machen müssen, in einer zentralisierten Datenbank mit einer klar definierten API, und das ist Marvin.
\|/ _\/_ \|/
@~/ Oo \~@
/_( \__/ )_\
\__U_/ goe
Marvin ist die zentrale Komponente unseres U8 Setups, mit der alle anderen Teile interagieren. Dabei unterscheiden wir zwischen Clients, wie dem Dashboard, das Einträge in Marvin ändert, also z.B. eine Domain hinzufügt oder einen SSH key anpasst. Auf der anderen Seite sind die Generatoren, die genau solche Änderungen bei Marvin abonnieren und diese dann umsetzen, indem sie auf dem Host eine neue Webserver Konfiguration schreiben oder die Datei ~/.ssh/authorized_keys_uberspace auf dem entsprechenden Asteroid anpassen.
Die Clients und Generatoren sprechen natürlich über eine genau definierte API mit Marvin, so auch das zukünftige uberspace command. Und ja, wir denken auch daran zukünftig eine externe Schnittstelle anzubieten, damit ihr eure eigenen Clients bauen könnt.
Arch und der Pacman Mirror
Soviel haben wir ja schon an anderen Stellen fallen lassen: U7 war CentOS, U8 wird Arch. In Sachen OS Platform gehen wir also ganz andere Wege. Das mag nun nicht allen etwas sagen, aber bei der einen oder dem anderen vielleicht doch für ein kleines Stirnrunzeln sorgen. Denn während wir bei CentOS noch auf eine typische Server-Distribution gesetzt haben mit stabilen, gut abgehangenen Paketen, ist Arch mit seiner sehr fluiden Packaging Struktur und einem Rolling Release “on the Bleeding Edge” so ziemlich das Gegenteil davon. Das bedeutet für uns weniger eigene Pakete bauen aber dafür auch mit ständigen Updates umgehen können.
Wie wir das mit einem eigenen Package Mirror vorhaben umzusetzen hat Bokan ja bereits letztes Jahr in einem Blogpost beschrieben. Jetzt konnten wir das Projekt Anfang des Monats endlich in einer ersten Version finalisieren und U8 bekommt die Pakete inzwischen aus unserer eigenen Quelle, die uns vor allzu überraschenden Änderungen bewahrt. Damit haben wir einen großen Schritt gemacht und vor allem auch wieder mehr Kapazitäten für andere Baustellen gewonnen.
Mail aber nicht qmail
Seien wir ehrlich, Mail ist nicht ganz unumstritten bei uns im Team. Einerseits ist es ein zentrales Feature, das trotz allen Unkenrufen noch immer rege benutzt wird und unverzichtbar in vielen Bereichen ist. Andererseits merkt man wohl wenigen Technologien derart deutlich an, wie sie dynamisch mit dem Internet mitgewachsen sind und aus einem Flickwerk verschiedenster Technologien bestehen.
Eine Besonderheit bei Uberspace war über lange Zeit die Verwendung von qmail, aber wie wir schon lange ankündigen ist diese Komponente auch bei uns ein Auslaufmodell und auf U8 wird es definitiv kein qmail mehr geben, kein vmailmgr und auch kein Haraka. All das wird auf U8 mit einem inzwischen gut bewährtem Postfix ersetzt. Wie das alles im Detail aussieht, werden wir noch im Detail aufschreiben. Jedenfalls hat das Ops Team uns ein recht raffiniertes “zentral-dezentralisiertes” System gebaut. Es wird auf jeden Fall zuverlässiger, stabiler, simpler und wir geben Acht, dass eine Migration die bisherigen Uberspace Besonderheiten möglichst wenig tangiert.
Ein paar Zöpfe werden aber auf der Strecke bleiben, vor allem jene, die wir noch aus U6 mitgeschleppt haben. Darüber haben wir euch schon im Einzelnen per Mail informiert, aber hier nochmal der kleine Hinweis nebenbei: Inwieweit ihr bei euch selbst etwas werdet anpassen müssen, findet ihr mit dem Command uberspace migration qmail status heraus.
Caddy statt Nginx
Eigentlich ist es schon eine ziemliche Neuerung, dass wir eine so zentrale Komponente, den Webserver, einfach durch ein anderes Tool ersetzen. Bisher hat uns das aber noch nicht wirklich viel beschäftigt, denn: Caddy tut einfach was es soll. Noch haben wir nicht wirklich tief an den Konfigurationen gekratzt und wir haben mit Backends, PHP etc. noch ein paar Dinge auf der Liste. Aber bisher gefällt uns das alles schon ziemlich gut. Vor allem, dass wir nach einem manuellen Setup in U6 und dem automatischen “HTTPS-by-default” auf U7 nun nochmal einen Schritt weiter in völlig natives TLS Zertifikats Handling gehen und das Caddy einfach machen lassen können.
Web Backends und Network Namespaces
Eine sehr beliebtes Feature bei Uberspace sind die Web Backends über die ihr beliebige Ports innerhalb eures eigenen Asteroids von außen zugänglich machen und dann darauf beliebige Services wie ein Django, Etherpad oder Grafana lauschen lassen könnt. Damit auch mehrere User z.B. einen Port 8000 nutzen können, bekommt jeder Asteroid seinen eigenen Network Namespace. Das bisherige Setup auf U7 hat zwar dafür gut funktioniert, aber wir wollten es schneller und stabiler machen und haben das ganze darum in Rust neu schreiben lassen. Das Ergebnis ist Open Source und könnt ihr auf Github einsehen, in U8 werden wir das pam_isolate das erste mal einbauen.
Shellinspector
Der Shellinspector ist eigentlich keine wirkliche U8 Komponente, sondern bereits jetzt ein Open Source Projekt von uns, das ihr euch ebenfalls auf Github anschauen und selbst verwenden könnt. Wir setzen es schon aktiv beim Testen von U8 ein und es macht wirklich Spaß(!) damit Tests zu schreiben. Statt abstrakte Definitionen zu coden, können wir hier einfach normale Shell Commands automatisieren. Und was passt besser zu Uberspace als die Möglichkeit, Dinge auf der Shell machen zu können.
Maintenance U7
Wie oben bereits einmal angesprochen: Ja, CentOS7 ist End of Life, aber nein, U7 ist nicht unsicher. Seit dem Ende des offiziellen Supports durch RedHat kaufen wir Extended Support von anderer Seite ein. Außerdem bauen wir ja inzwischen eh viele Pakete selbst, zuletzt sogar PHP 8.4 mit einem ziemlichen Aufwand durch Jonas, der sich ein paar Tage durch den Abhängigkeits-Dschungel geschlagen hat. Trotzdem ist es natürlich ärgerlich, dass die Maintenance dadurch nicht weniger wird und uns diese Zeit bei U8 fehlt, ganz zu schweigen von den Kosten durch den Extended Support. Zudem kommen bei einem produktiven Live System natürlich auch immer neue Herausforderungen von außen, wie beispielsweise die Bot Crawler, die uns im Oncall beschäftigen und gegen die wir dann neue Maßnahmen in eine altes System einbauen müssen. Darum nehmt es uns nicht übel, wenn wir an manchen Stellen im Support inzwischen leider sagen müssen, dass es eine Lösung für manche Probleme erst bei U8 geben wird.
Schön Schön, und wann jetzt?
Nochmal ein ehrliches Wort zur Zeit: Wir sind jetzt ungefähr da wo wir uns eigentlich vor einem Jahr gewünscht hätten. Das hat natürlich viele Gründe, nicht zuletzt auch schlecht planbare Dinge wie langfristige Erkrankungen, die uns mehrfach erwischt haben. Aber wahrscheinlich auch eine Unterschätzung wieviel Zeit u.a. die saubere (Neu-)Strukturierung unserer Codebase kosten wird. Wir arbeiten in unseren Repos jetzt zum Beispiel viel mit Copier Templates, über die wir einen einheitlichen Prozess für das Schreiben von Changelogs, Dev Environment, Deployment etc. etabliert haben. Das spart im Nachhinein viel Zeit und macht vieles klarer und transparenter, kostet allerdings auch erstmal einiges an Aufwand, um alles geradezuziehen. Wir mussten neue Strukturen für die Zusammenarbeit zwischen Ops und Dev Team etablieren, damit wir unser Testing auf dynamisch erstellten Test VMs stabil zum laufen kriegen. Wir mussten Designentscheidungen für die Struktur unserer Kern Komponente Marvin planen und dann doch in der Realität mehrfach umwerfen und neu adaptieren. Und ja, Arch hält dann doch die ein oder andere Überraschung parat die wir anfangs noch nicht auf dem Zettel hatten.
Und dann läuft man trotz besseren Wissens doch immer wieder in das Pareto-Prinzip hinein. Darum bleiben wir auch jetzt dabei und wollen keine konkrete ETA herausgeben, euch aber doch auch nicht im Regen stehen lassen.
Also sagen wir erstmal unmutig: Dieses Jahr wird es irgendwann ein öffentliches U8 geben.
Und behaupten ein bisschen mutiger: Im nächsten halben Jahr wird es eine öffentliche Beta geben und davor eine semi-öffentliche Alpha. Konkreteres dazu werden wir wahrscheinlich um den Mai herum verlautbaren.
Wenn absehbar wird, dass es ganz anders kommt, melden wir uns schon vorher dazu, aber ansonsten in rund zwei Monaten, wie es zeitlich mit Alpha/Beta aussieht.
AUA
Wenn euch bei euch jetzt noch akute Fragen aufbranden sind wir sind als Dev-Team ja eh auf Mastodon ansprechbar, aber wollen euch dort am liebsten zu einem “Ask-Us-Anything” Format für einen Tag einladen:
Zeit: 18.03.2025 12-17 Uhr
Dann haben wir mehr Fokus auf Ort und Zeit (auch so ein Learning für einen guten Arbeitsmodus) und ihr vielleicht mehr Anreiz uns mit irgendwelchen Fragen zu konfrontieren.
Titelbild von der British Library auf Unsplash