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:
Jonas und ich waren in der letzten Woche in Prag, um die Write the Docs Europe zu besuchen. Es war für uns beide die erste Write the Docs und, um das schonmal vorwegzunehmen, sicher nicht die letzte!
Wir wollen unsere Dokumentation verbessern. Nicht, dass sie schlecht wäre, wirklich gut ist sie aber eben auch nur bedingt. Ich weiß, viele von euch mögen sie sehr und ich auch, aber unsere wachsende Popularität stellt uns da gleich vor mehrere Herausforderungen:
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.
Bei Uberspace habt ihr die Möglichkeit, eure eigenen Domains aufzuschalten, Ports in der Firewall zu öffnen und Zertifikate einzutragen. Bei all diesen Aktionen interagiert ihr mit Konfigurationsdateien, auf die ihr eigentlich keinen Zugriff habt - mit dem Webserver, unserem HTTPS-Frontend und der Firewall.
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:
Diesen Test haben wir mit Ansible realisiert. Und jetzt mal Butter bei die Fische, so sieht das in Code aus: Die Variablen testuser und dummypassword haben wir bereits an anderer Stelle definiert, in ansible_fqdn steht der Hostname des Servers. <{{ testuser }}@{{ ansible_fqdn }}> ist also die E-Mail-Adresse des Testusers.
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.
… und was wir anders machen würden, wenn wir nochmal von vorne anfangen würden.