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.

Nun, man will Dinge ja richtig machen. Sauber, ordentlich, betreuungsarm. Dazu gehört zum Beispiel, wie man denn mit europäischen Umsatzsteuer-IDs umgehen möchte. Die muss man nämlich validieren, bevor man ihnen trauen darf. Dafür gibt es VIES, das “VAT Information Exchange System”. Und, kaum zu glauben: Es gibt sogar einen Webservice zur USt-ID-Validierung, auch wenn es ein wenig nach Glückssache aussieht, zu welcher Uhrzeit man denn nun die USt-IDs welchen Landes gerade validieren kann und wann nicht. Deutschland stellt in puncto Verfügbarkeit den Bodensatz der Liste dar: Die API ist täglich geöffnet von 5 bis 23 Uhr. Das bedeutet also eine Erreichbarkeit von gerade mal 75% - das kann sich ja mal jeder auf der Zunge zergehen lassen, der es gewohnt ist, schon nur noch nach der Zahl der Neunen hinterm Komma zu fragen.

An den Weihnachtsfeiertagen ist Ruby 2.2.0 erschienen, und das haben wir dann auch mal direkt bei uns verteilt. Vom Handling her, was z.B. Gem-Installationen mit --user-install angeht, dürften keine Überraschungen zu erwarten sein. Wie üblich sind die Gems für MySQL, FastCGI und SQLite3 bereits vorinstalliert, wobei wir die Gelegenheit genutzt haben, das SQLite3 in /package auf die aktuelle Version 3.8.7.4 hochzubringen. Viel Spaß mit der neuen Version, und bei Problemen bitte melden!