Kurz und schmerzlos: PHP 7

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).


Let's Encrypt rollt an - auch bei uns

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.


Automatisierter Zertifikatsimport

Ihr könnt (und sollt!) bei uns ja nun schon lange eigene TLS-Zertifikate für den Webserver benutzen, jedoch war das bisher immer mit einer Mail an den Support verbunden, nach der wir das Zertifikat dann einbinden. Wir haben das bisher nicht etwa so gehandhabt, weil wir zu faul waren, uns etwas anderes zu überlegen oder weil wir euch ärgern wollten, das hatte schlicht sicherheitstechnische Hintergründe: Die Zertifikate werden in unser HTTPS-Frontend Pound eingepflegt und das betrachten wir als außerordentlich kritische Infrastruktur, bei der wir so wenig Angriffsvektoren wie möglich öffnen wollen. Da es ja nun aber doch so aussieht, als ob die freie Verfügbarkeit von TLS-Zertifikaten für jeden direkt vor der Tür steht und wir dies soweit wie möglich automatisieren wollen, haben wir uns mal ein paar Gedanken gemacht, wie das mit dem Zertifikatsimport (so weit wie möglich) ohne unser Zutun ablaufen kann.


Node.js 4.2.2 LTS und 5.1.0

Nur kurz zur Info: Node.js 4.2.2 LTS und 5.1.0 Stable sind erschienen und nun auch bei uns verfügbar.

Unter den Symlinks unter /package/host/localhost ist hinzugekommen:

nodejs-5 -> nodejs-5.1.0

Angepasst haben wir:

nodejs-4 -> nodejs-4.2.2

Das Spiel kennt ihr: Wenn ihr nodejs-4 oder nodejs-5 in eueren Scripten benutzt reicht es, den Dienst einfach neu zu starten.

Der Default bleibt bis auf weiteres node-0.10 da wohl noch einige Zeit ins Land gehen muss, bis die meisten Projekte Support für Node.js (4|5) eingebaut haben…


Reisebericht: Velocity Conf Amsterdam

Daniel und Mic haben bereits in der vorletzten Woche Amsterdam besucht, um an der Velocity Conference teilzunehmen. Der Verlag O’Reilly organisiert an mehreren Orten auf der Welt regelmäßig dieses Event, bei dem es um Web Performance und DevOps geht. Thematisch war das für uns super interessant und es gab viele erfrischende Eindrücke.

Amsterdam ist eine großartige Stadt gerade für Geeks wie uns, die Straßenverkehr und Infrastruktur besonders interessant finden. Es ist ein tolles Gefühl, durch die Straßen zu gehen und Myriaden von Fahrrädern zu begegnen. Das Fahrrad-Netz in Amsterdam stellt eine mit bedacht entwickelte Verkehrslösung dar und vermag uns ebenso begeistern, wie es das Metro-Netz in Tokyo vor ein paar Monaten konnte.


Das Kapital und die Spezialdienste

TL;DR

  1. Die Telekom baut auf veralteter Infrastruktur, statt Glasfaser
  2. Ihre Peers bittet sie übermäßig zur Kasse
  3. Pakete gehen verloren, die Kunden erhalten zu wenig Leistung
  4. Content-Anbieter konkurrieren um die wenige Bandbreite
  5. Nun sollen wir extra bezahlen, um nicht benachteiligt zu werden
Die verdammte Politik

Das “Netz der Zukunft” ist bei 100 MBit/s nicht gerade zukunftsfähig. Die Glasfaserleitungen könnte man auch endlich in die Häuser verlegen und ohne große Zusatzkosten Gigabit liefern. 100 MBit/s auch im Upload? Nicht mit der Telekom.


Geplante Obsoleszenz oder Fehlkonstruktion?

Vor einigen Wochen ist uns in unserem Rechenzentrum eine über das Netz schaltbare Steckdosenleiste abgeraucht und hat dabei 24 Server abgeschaltet. Die Folgen waren: Downtime der Server für mehrere Stunden (wobei ein Großteil Server mit Failover-Partner waren), 4 kaputte Festplatten und der damit verbundene Ärger und zu guter Letzt der Nachteinsatz mehrerer Kollegen, und das alles nur weil eine Steckdosenleiste von jetzt auf gleich den Betrieb einstellen wollte.

Alleine den Ausfall der Steckdose halte ich persönlich für eine Unding - es handelt sich schließlich um ein 1000-Euro-Gerät einer namenhaften Firma. Hier würde ich erwarten, dass ein Defekt im Gerät nicht die Funktion der gesamten Leiste zum Erliegen bringt. Einzelne Ports vielleicht oder der Verlust der Schaltbarkeit würde ich ja noch akzeptieren, aber dass das Ding einfach ausgeht: Nun ja. Nicht weiter darüber aufregen.


Zum Stand von Let's Encrypt

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).


Überarbeitung des Prozesskillers

Uberspace ist eine Shared Hosting-Umgebung, bei der alle nach gewissen Spielregeln spielen müssen. Es liegt in der Natur der Sache: Ressourcen auf unseren Servern sind - wie überall - begrenzt (wenn auch sehr großzügig dimensioniert) und ab und zu müssen wir der Fairness wegen eingreifen. Das gilt zum Beispiel, wenn ein einzelner Prozess überproportional viel RAM belegt - hier kommt unser Prozesskiller ins Spiel.

Der Prozesskiller. Döm döm döm…

Den Prozesskiller gibt es schon lange. Anfangs werkelte er stillschweigend bei uns im Hinterzimmer, seit einiger Zeit verschicken wir auch Mails, wenn wir einen Prozess beenden. Bisher gab es bei 500MB RAM-Belegung eine Warnmail, dass wir den Prozess bald beenden werden, und bei 600MB RAM-Belegung den Abschuss und eine entsprechende Nachricht im Posteingang. Jeder, der schon einmal eine Mail mit einem ähnlichen Betreff wie


Node.js 4.2.0

Zwei mal drei macht vier,

widewidewitt und drei macht neune,

ich mach mir die Welt,

widewide wie sie mir gefällt.

Vielleicht haben die Macher von Node.js zu viel Pippi Langstrumpf gelesen, vielleicht aber auch nicht, wer weiß das schon. Fest steht: rechnen können sie nicht. Nach Node.js 0.10 und 0.12 kommt nun also Version 4. Und weil 4.0 auch schon wieder veraltet ist, gibt’s bei uns nun Node.js 4.2.0.

Unter den Symlinks unter /package/host/localhost ist hinzugekommen: