Vom Konzept her ist ein Uberspace dazu gedacht, ein Projekt darauf zu hosten. Dafür wird /var/www/virtual/<user>/html als DocumentRoot angeboten. Schon ziemlich in der Anfangszeit trafen Fragen bei uns ein, ob man da nicht die Möglichkeit schaffen könnten, für kleinere Sachen einfach separate Verzeichnisse anzulegen, um keinen separaten Uberspace dafür anzulegen - “das lohnt doch gar nicht”. Wir waren mit Uberspace gerade erst gestartet, voller Tatendrang, ein wenig blauäugig vielleicht auch, und dachten uns: Klar, basteln wir doch schnell eine RewriteRule, und schon war das Feature geboren: User konnten ab sofort in /var/www/virtual/<user> einfach weitere Verzeichnisse ablegen, die so hießen wie Hostnamen, und schon wurden Anfragen nach jenen Hostnamen aus diesem Verzeichnis bedient (vorausgesetzt, der Hostname wurde auf den Uberspace aufgeschaltet). So weit, so gut - oder besser gesagt: So weit, so okay.
Sagt Hallo zu biela, brorsen, encke, faye, finlay, halley, olbers, tempel, tuttle und wolf! Wir haben mehrere Terabyte Plattenplatz, mehrere Dutzend CPU-Kerne und mehrere hundert GB RAM springen lassen und zehn Hosting-Systeme für euch gebaut, damit nach den 50 Usern, die unsere Closed Beta testen konnten, nun alle anderen, die schon auf U7 neugierig sind, ebenfalls loslegen können.
Auf https://uberspace.de/register?u7=1 bekommst du eine Checkbox angeboten, mit der einen Account auf U7 statt auf der derzeit stabilen Version U6 anlegen kannst.
Moin zusammen! Gehen wir gleich ans Eingemachte. Im letzten Blogartikel schreiben wir:
Zwar ist Uberspace 7 nicht feature complete, aber so gut wie „fertig“ genug, um es endlich für Euch aufzumachen. Das heißt, wir spucken nun nochmal ordentlich in die Hände, gehen Montag in den letzten, zweiwöchigen Sprint und dann… machen wir erst nochmal Urlaub und erholen uns ordentlich. 🌴😎
Die Entwickler unter euch werden wissen: Der letzte Sprint ist nie der letzte und so mussten wir natürlich auch hier (was ETAs angeht hätten wir eigentlich aus der Vergangenheit lernen müssen…) noch mal das Skalpell ansetzen und aus einem Sprint mehrere machen.
Der erste Server ist (voll automatisch) aufgesetzt, alle Kollegen haben einen Account, schauen sich um und finden (und beheben) gerade die ersten Bugs. Die letzten grundlegenden Funktionen sind (oder werden gerade) implementiert und in ein paar Tagen trauen wir uns, die ersten User auf das System zu lassen. Wir haben bereits eine Hand voll Tester rekrutiert und werden diese Gruppe langsam vergrößern. Auch hier wird dann zu gegebener Zeit ein Update erfolgen, in dem wir euch die Möglichkeit geben, einen Account zu testen.
Es geht [gut voran] 1, mit unserer neuen Arbeitsweise sind wir inzwischen gut vertraut und sie ist uns in Mark und Bein übergegangen. Wir wollen euch nun mal kurz unsere Bürotür öffnen und euch zeigen, woran wir gerade arbeiten und wie die nähere Zukunft aussieht.
Inzwischen ist es spruchreif: Wir tauschen unser HTTPS-Frontend aus. Bisher haben wir auf [Pound] 3 gesetzt, mit Uberspace 7 setzen wir auf [nginx] 4. Das bringt folgende Vorteile:
Wie ihr im aktuellen Blogpost der Uberspace-7-Reihe lesen könnt, ändert sich im Bereich unserer Shellscripts gerade eine ganze Menge. Aus Config-Dateien werden Ansible-Facts, aus Bash werden Playbooks oder Python-Skripte. Um all diese Teile wieder unter einen Hut zu bekommen, müssten wir einen Ausflug in die Softwareentwicklung machen.
Viele unserer Features - wie das allseits beliebte uberspace-add-domain - erfordern, dass wir euch mehr Rechte einräumen, als ihr eigentlich haben dürft. Auf diesem Weg könnt ihr beispielsweise mit uberspace-add-domain auf die Konfiguration unseres Webservers oder mit uberspace-add-port auf das iptables-Ruleset in engen Grenzen und indirekt, aber dennoch schreibend, zugreifen.