Der Verwendungszweck von Überweisungen ist ein täglicher Quell der Überraschung: Entgegen unserer Bitte, einfach nur “Uberspace Username” in den Verwendungszweck zu packen, erhalten wir täglich ein Bündel Überweisungen mit so schönen Angaben wie “Für meine Internetseite”, “für 6 Monate, vielen Dank”, “Verwendungszweck” (!) oder allen möglichen Schreibweisen, die teilweise plausibel auf kreative Handschrifterkennung der Bank hinweisen. In erster Linie ist das zum Nachteil des Accountinhabers, denn während Buchungen, deren Verwendungszweck dem vorgegebenen Schema entspricht, automatisiert eingebucht werden, landet alles andere in einer manuellen Nachkontrolle, wird also ggf. erst etwas später gutgeschrieben oder landet im schlechtesten Fall in den offenen Buchungen, wenn wir keinen passenden Account ermitteln können.

Wir haben haben das erste Release von PHP 7 (also die 7.0.0) auf alle unsere Hosts verteilt. Aktiviert werden kann es wie gewohnt:

$ echo PHPVERSION=7.0 > ~/etc/phpversion
$ killall php-cgi

Wichtig: Wer sich eine eigene php.ini angelegt hat, sollte jene durch eine frisch angelegte Version auf Basis der zentralen php.ini ersetzen und ggf. vorgenommene Erweiterungen dort erneut vornehmen, ansonsten dürfte insbesondere der opcache-Support, für den ein Modul über die php.ini geladen wird, nicht funktional sein. Wer eigene PECL-Module kompiliert hat, muss jene für PHP 7 neu bauen, da sich die API-Version geändert hat (von 20131226 auf 20151012).

Achtung! Dieser Blogpost ist die Ankündigung unseres Let’s Encrypt-Supports. Leider haben sich seitdem einige Details wie z.B. der lesencrypt-renewer geändert, sodass die Informationen hier nicht mehr sonderlich aktuell sind. Stattdessen bitten wir dich, einen Blick auf den zugehörigen Wiki-Artikel zu werfen, welchen wir stets auf dem neuesten Stand halten.

Das Wichtigste in Kürze.

Let’s Encrypt?

Für alle, die in den letzten Wochen unter einem Stein gelebt haben: Let’s Encrypt ist eine Initiative, die kostenlos und automatisiert Zertifikate ausstellt, die z.B. für HTTPS nutzbar sind.

Derzeit schlagen im Support vermehrt Fragen zum Support von Let’s Encrypt auf, nicht zuletzt seit das Projekt vermelden konnte, nun seine Cross-Root-Signatur von IdenTrust erhalten zu haben, was nicht Wenige damit verwechselt haben, dass es da jetzt produktiv losgeht. Deshalb erstmal die wichtigsten Punkte vorab:

• Let’s Encrypt ist weiterhin noch nicht allgemein verfügbar; es gibt lediglich eine Closed Beta. Der Verfügbarkeitstermin ist nach deren aktueller Roadmap der 16. November wohl doch erst der 3. Dezember.
• Let’s Encrypt ist eine Zertifizierungsstelle, aus der letztlich ganz genauso Zertifikate rausfallen wie aus jeder anderen Zertifizierungsstelle - Zertifikate, die wir also ganz genauso wie jedes andere Zertifikat kostenlos bei uns einbinden können - heute schon.
• User, die das Glück haben, am Beta-Programm von Let’s Encrypt teilnehmen zu können, tun das auch bereits.
• Ja, wir haben vor, Let’s Encrypt bei uns zu unterstützen, und um diesen Aspekt dreht sich dieser Blogpost.

Wenn davon die Rede ist, dass wir Let’s Encrypt bei uns unterstützen wollen, dann meint das weniger, dass wir deren Zertifikate unterstützen, denn in dieser Hinsicht unterscheidet sich Let’s Encrypt ja nicht von jeder anderen CA. Es bedeutet vielmehr, dass wir deren Validierungsprozess bei uns einbinden möchten, mit dem Ziel, dass User im Prinzip nur noch sowas wie uberspace-letsencrypt (oder sowas in der Richtung) eingeben müssen, und wir kümmern uns darum, ihnen automatisiert einen Account bei Let’s Encrypt zu verschaffen, die Challenges für die Validierung zu erledigen, Key und CSR zu erstellen und das Zertifikat bei uns einzubinden. Soweit der Plan, und wir arbeiten bereits seit einiger Zeit daran, das umzusetzen; ist aber noch nicht fertig. Das macht aber ja nichts, denn Let’s Encrypt selbst ist ja auch noch nicht fertig, d.h. die Zertifikate, die man derzeit von deren Staging-API beziehen kann, tragen ohnehin noch keine Signatur, der Browser vertrauen würden (das ist nur bei den Zertifikaten des Beta-Programms der Fall).

Kurz zwischendurch: Wir stellen nun auch die Ruby-Version 2.2.2 bei uns bereit, die einen Fix für CVE-2015-1855 beinhaltet. Wer als Pfad zum Ruby-Interpreter den /package/host/localhost/ruby-2.2-Symlink verwendet, braucht nichts weiter zu tun; jener zeigt bereits auf die neueste Version. Wer als Pfad die konkrete Versionsangabe /package/host/localhost/ruby-2.2.0 verwendet, sollte seine .bash_profile entsprechend auf die Version 2.2.2 (oder noch besser auf den 2.2-Symlink) anpassen.

Wir machen ja bekanntlich durchaus ernst damit, keine persönlichen Daten zu erheben und damit auch keine E-Mail-Adresse. Es liegt aber auf der Hand, dass wir User durchaus auch mal initiativ kontaktieren müssen: Um sie zu informieren, wenn sie ihr Konto aufladen müssen, oder wenn ihr Speicherplatz knapp wird, oder wenn wir z.B. einen ihrer Mailaccounts oder auch ihre Website wegen einer Kompromittierung sperren müssen - ganz besonders aber dann, wenn User keinen Zugang mehr zum Dashboard haben und einen Passwort-Wiederherstellungslink brauchen. Unser Konzept war (und ist weiterhin) das der “primären E-Mail-Adresse” in der Form user@host.uberspace.de, die man sich zwar an eine externe Mailadresse weiterleiten lassen kann, aber eben auch via IMAP abrufen kann, ohne uns dazu irgendwelche Daten von sich bereitzustellen. User, die keine externe Mailadresse hinterlegt haben, haben wir bisher im Dashboard unter dem Punkt “Wichtig” mit dem Titel “Wir erreichen dich noch nicht!” darauf hingewiesen, dass sie ihre primäre Mailadresse abrufen sollten (der Hinweis verschwindet automatisch, wenn die Mailbox in den letzten 30 Tagen einmal abgerufen wurde). Dennoch gibt es im Support leider immer wieder Fälle, wo User ihren Zugang zum Dashboard verloren haben und dann konsterniert feststellen, dass wir tatsächlich keine hellseherischen Fähigkeiten haben und eben wirklich nicht überprüfen können, wem ein Account gehört - eben eine der unpraktischeren Seiten der Datensparsamkeit: Wer keine Daten angibt, was ja legitim ist, sollte dann eben auch wirklich, wirklich sein Passwort nicht vergessen.

Um die Privatsphäre unserer User zu verbessern, setzen wir bei uns schon seit längerer Zeit die mount-Option hidepid ein, die dafür sorgt, dass User nur ihre eigenen Prozesse sehen können, aber nicht die Prozesse anderer User. Die entsprechende Funktionalität ist zwar erst ab dem Linux-Kernel 3.2+ verfügbar; Red Hat hat sie aber in die Kernelversionen 2.6.18 bzw. 2.6.32 zurückportiert, die bei Red Hat Enterprise Linux und damit auch bei CentOS 5 und 6 zum Einsatz kommen. So weit, so gut.