Etherpad-lite anderswo framen? klar. Eine Content-Security-Policy setzen, obwohl die App kein Feature dazu hat? sicher. Den X-Xss-Protection-Header ausmachen? ohje, bitte nicht (geht aber auch). Jetzt frisch auf deinem Uberspace. tl;dr: You can now change outgoing HTTP headers using uberspace web header. Have a look at the Manual for more details in English. Für die kurz angebundenen: uberspace web header set / X-Frame-Options ALLOW - so einfach geht das ab heute. Details dazu gibt es, wie immer, im Manual.

Beim Update von MariaDB gab’s Probleme und Ausfälle. Wir erklären euch, was passiert ist.

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. Welche Features machen die Beta schon heute besser als U6? vollautomatisches HTTPS-Handling mit Let’s Encrypt für alle Domains HTTP wird grundsätzlich auf HTTPS umgeleitet Diverse Security-Header werden als Default gesetzt wir unterstützen nun HTTP/2 OCSP Stapling PHP ohne Startverzögerungen (eigene PHP-FPM-Instanz pro User) user.

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.

Lange haben wir in Sachen Uberspace 7 nichts von uns hören lassen, zu lange. Nicht um künstlich die Spannung zu steigern oder irgendwie Geheimniskrämerei zu betreiben, sondern einfach weil viele kleine und große andere Dinge an unseren Ressourcen nagten und der Blog dabei leider etwas hinten runterfiel. Auch haben wir bei der Einführung agiler Entwicklungsmethoden immer wieder erkennen müssen, dass Dinge die man richtig, sauber und nachhaltig bauen möchte einfach immer etwas mehr Zeit in Anspruch nehmen, als vorher kalkuliert.

Update 18.01.2017 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. Wir tauschen unser HTTPS-Frontend aus 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.

Wie ihr sicherlich schon auf Hackernews oder anders wo gelesen habt, kursiert gerade eine “neue” Lücke für diverse GCI-Applikationen im Netz: httpoxy. Konkret geht es darum, dass der Proxy-HTTP-Header des Clients aufgrund der CGI-Spezifikation in der Umgebungsvariable $HTTP_PROXY landet. Diese wird von unzähligen Applikationen dazu benutzt, Verbindungen nach außen aufzubauen. Somit hätte ein potentieller Angreifer die volle Kontrolle über diese Aufrufe, die zum Beispiel die API eines Zahlungsanbieters als Ziel haben können.

In Uberspace 7 - Episode 2 haben wir das Thema Tests angerissen: Nachdem Features definiert wurden sollte man anfangen, Tests zu schreiben und damit die Anforderungen an die Features genau definieren. Aber wie sieht so ein Test eigentlich aus? Beispiel: Jeder User bekommt mit seinem Account eine Mailbox, die er mit seinem SSH-Kennwort abrufen kann. Ein Test dafür würde folgendermaßen aussehen: Einen User auf dem Server anlegen Ein SSH-Passwort setzen Eine Mail an User schicken Der User loggt sich per IMAP ein User holt Mail 1 per IMAP ab (Es kann nur eine Mail da sein, der User ist ganz frisch angelegt und das Postfach war vor der Testmail leer) Wir überprüfen den Inhalt der Mail auf einen bestimmten String Profit!

Vielleicht fragt ihr euch, wie man so ein System denn überhaupt entwirft, was die einzelnen Phasen der Entwicklung sind und wie unsere Arbeitsweise so aussieht. Mit herzlichen Grüßen aus dem Bergwerk folgt hier ein kleiner Einblick in unsere tägliche Arbeit und den aktuellen Stand der Dinge. Die Phasen der Entwicklung … und was wir anders machen würden, wenn wir nochmal von vorne anfangen würden. Features definieren Im ersten Schritt haben wir uns Gedanken darüber gemacht, was ein Uberspace eigentlich ist: Was unsere User erwarten, was wir selbst erwarten und was wir davon zuverlässig liefern können.