Für das CMS Drupal ist vor ein paar Tagen eine extrem kritische Sicherheitslücke angekündigt (deutsche Quelle bei heise) worden. Gestern Abend wurden Details zur Lücke veröffentlicht und entsprechende Updates sowie Patches bereitgestellt.
cyon-Kunden können bereits aufatmen, wir haben die von der Community getaufte Lücke «Drupalgeddon2» in der vergangenen Nacht flächendeckend geschlossen. In Ihrem my.cyon-Konto unter «Sicherheit» -> «Sicherheitslücken & Malware» können Sie den Vorgang nachvollziehen, falls Sie eine Drupal-Installation auf Ihrem Webhosting betreiben:
my.cyon: Informationen zur Sicherheitslücke.
Sicherheitsrisiko «hochkritisch»
Die Sicherheitslücke Drupalgeddon2 macht eine sogenannte «Remote Code Execution» möglich. Angreifer können damit durch das Absetzen einer bestimmten Anfrage an die Drupal-Website beliebigen Code ausführen. Die Sicherheitslücke wurde vom Drupal-Security-Team deshalb als «hochkritisch» eingestuft. Betreiber von Drupal-Websites, deren Installationen nicht automatisch gegen die Sicherheitslücke gepatcht worden sind, sollten darum unverzüglich den von den Drupal-Entwicklern bereitgestellten Patch bzw. die gleichzeitig erschienene neue Version einspielen. Das Security-Team geht davon aus, dass die Sicherheitslücke in kürzester Zeit ausgenutzt wird.
Die PHP-Version 7.0 wird ab Dezember 2018 keine Sicherheitsupdates mehr erhalten. Die Nachfolgeversion PHP 7.1 wird deshalb ab Juli 2018 zur neuen Standardversion auf unseren Servern. Wir erklären, wie Sie Ihre Website für die Umstellung vorbereiten.
Muss ich etwas unternehmen?
Falls Sie für Ihre Website nicht ausdrücklich eine andere PHP-Version in Ihrem my.cyon-Konto ausgewählt haben, nutzen Sie die von uns vorgegebene PHP-Standardversion. Zurzeit ist das PHP 7.0.
Nach der Umstellung der Standardversion wird Ihre Website völlig automatisch mit PHP 7.1 ausgeliefert. Sie können bereits jetzt testen, ob Ihre Website auch mit PHP 7.1 wie gewohnt funktioniert. Und so geht’s:
Wie prüfe ich, ob meine Website auch mit PHP 7.1 funktioniert?
Die beliebtesten Content-Management-Systeme sind bereits seit längerem mit PHP 7.1 kompatibel. Um zu testen, ob auch Ihre Website mit PHP 7.1 problemlos funktioniert, gehen Sie bitte wie folgt vor:
Loggen Sie sich in Ihr my.cyon-Konto ein.
Wählen Sie den Menüpunkt «Erweitert > PHP-Versionsmanager».
Wählen Sie für das Stammverzeichnis «public_html» oder einen einzelnen Unterordner die PHP-Version 7.1.
Rufen Sie Ihre Website auf und prüfen Sie diese auf sichtbare Fehler oder fehlende Elemente.
Wann wird die PHP-Standardversion für mein Webhosting umgestellt?
Wir werden mit der Umstellung der PHP-Standardversion ab Juli 2018 beginnen. Um Ihnen bei allfälligen Problemen mit der Umstellung rasch zur Seite stehen zu können, werden wir die Umstellung auf verschiedenen Servern zu unterschiedlichen Zeitpunkten vornehmen. Den Umstellungszeitpunkt für den Server, auf dem Ihr Webhosting zu Hause ist, werden wir Ihnen dazu in den kommenden Wochen per E-Mail mitteilen. Sie finden den genauen Zeitplan ausserdem in unserem Supportcenter-Artikel zum Thema PHP-Versionen: Bis wann kann ich eine PHP-Version benutzen?
In der Regel sind bei Änderungen an der PHP-Version mit den Kernsystemen von WordPress, Joomla, TYPO3, Drupal, Contao und Co. also keine Probleme zu erwarten. Vielmehr sind es Plugins, Erweiterungen und Themes, die noch nicht mit modernen PHP-Versionen kompatibel sind. Legen Sie deshalb bei der Prüfung Ihrer Website mit PHP 7.1 ein besonderes Augenmerk darauf, ob eingesetzte Plugins und Themes Fehler generieren. In vielen Fällen genügt dann das Deaktivieren des Plugins oder der Wechsel auf ein moderneres Theme, um die eigene Website wieder fit für die kommenden Jahre zu machen.
Auch wir haben im Vorfeld bereits verschiedentlich über das neue Gesetz berichtet und fragten uns 2015, ob ein Überwachungsstaat drohe und bezeichneten 2016 das BÜPF als Gefahr für den Internetstandort Schweiz. Ein Referendum gegen die Gesetzesrevision kam mangels genügend Unterschriften nicht zustande.
Trotzdem wurde das Gesetz an verschiedenen Ecken nochmal überarbeitet und im Vergleich zu den ersten Entwürfen in Teilen etwas abgeschwächt. Mit den ab 1. März 2018 geltenden, neuen Gesetzesbestimmungen sollen Strafuntersucher nun zum Beispiel bei besonders schweren Straftaten neu sogenannte «Government Software» einsetzen dürfen. Ein solcher «Staatstrojaner» darf bei bestimmten, schweren Straftaten eingesetzt werden und bedarf der Genehmigung des zuständigen Zwangsmassnahmengerichts. Damit soll verhindert werden, dass Überwachungen präventiv stattfinden können.
Ebenfalls neu gibt es eine Pflicht zur Identifizierung der Nutzer von öffentlichen WLANs. Hier hat der Bund entgegen seinen ersten Entwürfen nachgegeben: Hat die Identifizierungspflicht in den ersten Versionen noch für alle Betreiber gegolten, so sieht das jetzt in Kraft tretende Gesetz nur noch vor, dass kommerzielle Anbieter die Nutzer Ihrer WiFi’s identifizieren müssen. Wer also sein WiFi zuhause, im Hotel, in Bars und Restaurants oder gar am Open-Air selbst betreibt und das nicht an einen Anbieter auslagert, muss die verbundenen Nutzer nicht identifizieren.
Und was bedeutet das neue BÜPF für unsere Kunden?
Für die Anbieter sogenannt abgeleiteter Kommunikationsdienste, unter welche auch wir als Webhosting-Provider fallen, ändert sich glücklicherweise nur wenig. Maximalforderungen, wie eine automatische Auskunftserteilung oder die Installation von Anlagen, die es erlaubt hätten, Überwachungsaufträge automatisiert zu starten, sind, zumindest für uns, vom Tisch.
Allerdings haben wir eine allfällige Überwachung zu «dulden». Im Falle eines Falles müssten wir also Randdaten zur Kommunikation einer überwachten Person herausgeben, beispielsweise die E-Mail-Adresse des Empfängers, dem die überwachte Person eine E-Mail schreibt, oder die IP-Adresse des empfangenden oder sendenden E-Mail-Servers aus unseren Logfiles. NICHT herausgeben müssen wir jedoch den Inhalt der E-Mail-Korrespondenz. Dazu wären wir aber sowieso nicht in der Lage, da wir diese Daten – selbstverständlich – auch gar nicht aufzeichnen.
Im Extremfall müssten wir zudem gemäss Art. 27 Abs. 1 BÜPF eine Überwachung betreffend der Daten, welche die überwachte Person unter Verwendung abgeleiteter Kommunikationsdienste übermittelt oder speichert, durch den Dienst ÜPF oder durch dessen Beauftragte dulden. Auf gut Deutsch: Wird eine Überwachung in Echtzeit angeordnet, müssen wir diese zwar nicht selbst durchführen, wären wir in einem solchen Fall aber verpflichtet, der Behörde entsprechend Zugang zu «Gebäuden, Geräten, Leitungen, Systemen, Netzen und Diensten» zu gewähren, wie es in der Verordnung über die Überwachung des Post- und Fernmeldeverkehrs (VÜPF) heisst. Wir werden über solche Auskunftsanfragen auch in Zukunft in unserem jährlich erscheinenden Transparenzbericht informieren.
Vor Kurzem hat Google bekanntgegeben, auch in den mobilen Suchresultaten die Geschwindigkeit einer Website zu einem Ranking-Faktor zu machen. Für Desktop-Suchen ist das bereits seit 2010 der Fall, an und für sich also nichts Neues aus dem Hause Google. Und wie auch schon 2010 stellt die Ankündigung die Suchmaschinen-Welt nicht auf den Kopf. Website-Betreiber können also weiterhin nicht erwarten, nur aufgrund einer schnellen Webpräsenz auf den vorderen Rängen in den Suchmaschinenresultaten zu landen.
Nichtsdestotrotz ist mit der neusten Ankündigung aber wieder einmal klar definiert worden: Speed ist wichtig. Aber wie prüfe ich überhaupt, ob meine Website schnell ist? Dazu liefert Google, nebst dem altbekannten (und mit Vorsicht zu geniessenden) PageSpeed Insights, seit einer Weile ein weiteres praktisches Tool: Lighthouse.
Was ist Google Lighthouse?
Ursprünglich als Audit-Werkzeug für sogenannte «Progressive Web Apps» (PWA) entwickelt, lassen sich mit Lighthouse auch «herkömmliche» Websites (wenn man denn überhaupt von so etwas sprechen kann) auf Herz und Nieren prüfen. Die Checks sind mit der aktuellen Version in 5 Gruppen unterteilt: «Progressive Web App», «Performance», «Accessibility», «Best Practices» und «SEO». Die Namen der Gruppierungen verraten denn auch schon, welche Tests sie beinhalten.
Wie gut ist meine Progressive Web App?
So wird die aufgerufene URL in der Gruppe «Progressive Web App» nach Merkmalen geprüft, die eine gute «Progressive Web App» oder eben PWA ausmachen: Meldet die Website einen Service Worker an? Funktioniert die Website auch ohne Internetverbindung? Oder ist die Website für einen Splash-Screen konfiguriert?
Wer seine Website nicht als PWA konzipiert, kann auf den Progressive-Web-App-Check getrost verzichten. Die einzelnen Checks lassen sich dazu je nach Bedarf ein- und ausschalten.
Performance: Der heilige Gral der Website-Tests
In der Gruppe «Performance» werden zurzeit 5 Merkmale geprüft, die eine objektive Aussage darüber machen, wie gut die geprüfte Website im Browser des Besuchers performt. Wer mit seiner Website in dieser Kategorie einen Wert über 75 erhält das Prädikat «Gut». Die Performance-Gruppe setzt sich aus den folgenden 5 Kennzahlen zusammen:
First meaningful paint Misst die Zeit, bis der Hauptinhalt der aufgerufenen Seite sichtbar ist.
First interactive Misst die Zeit, bis der Besucher zum ersten Mal mit der aufgerufenen Seite interagieren kann.
Consistently interactive Misst die Zeit, bis der Besucher vollständig mit der aufgerufenen Seite interagieren kann.
Perceptual speed index Misst die Zeit, wie schnell die Inhaltselemente der Seite sichtbar mit den Inhalten befüllt sind. Das Konzept Speed Index stammt von den Machern von webpagetest.org und wurde dort 2012 eingeführt.
Estimated input latency Schätzt die Zeit, bis die aufgerufene Seite auf eine Eingabe des Besuchers (Mausklick, Tastendruck, Tap, etc.) reagiert. Ab mehr als 50ms Reaktionszeit kann die Website vom Besucher als träge wahrgenommen werden.
Die Tests aus der Gruppe «Performance» sollten Sie unbedingt genauer unter die Lupe nehmen. Hier schlummert gegebenenfalls riesiges Potenzial, das Ihre Website verschenkt. Und das wirkt sich direkt auf die Nutzung Ihrer Website aus.
Accessibility: Geprüft barrierefrei
In der Gruppe Accessibility wird die Barrierefreiheit der geprüften Website analysiert. Im Gegensatz zur Gruppe Performance können die Accessibility-Tests entweder bestanden oder nicht bestanden werden. Die zurzeit 35 Prüfungen werden gewichtet und aus den Ergebnissen wird ein Durchschnitt berechnet.
Best Practices: Das sollten moderne Websites können
In der Gruppe Best Practices werden zurzeit 16 Tests durchgeführt, wobei wie in der Gruppe Accessibility ein Test entweder bestanden oder nicht bestanden ist. Im Gegensatz zu Accessibility sind die Tests nicht gewichtet und beinhalten Fragen wie «Wird HTTP/2 verwendet?», «wird HTTPS verwendet?» oder «ist Copy & Paste in Passwortfeldern möglich?».
SEO: So wird Ihre Website sicher gefunden
Erst seit Kurzem beinhaltet Lighthouse auch Checks, die eine Website auf deren Suchmaschinenfreundlichkeit prüfen. Zurzeit sind Tests noch sehr rudimentär, dürften sich in Zukunft aber noch weiterentwickeln. Falls die geprüfte Website in der Gruppe SEO keine volle Punktzahl erreicht, sollten Sie als Website-Betreiber dringend handeln. Die SEO-Checks prüfen Merkmale, die auf keiner Website fehlen dürfen.
So schneidet die Website pwa.rocks im Lighthouse-Test ab.
Wie nutze ich Lighthouse?
Google Lighthouse lässt sich auf verschiedene Arten nutzen. Allen Arten ist gemein, dass auf dem entsprechenden Rechner Google Chrome installiert sein muss. Die einfachste Variante ist der Weg über die sogenannten DevTools. Dort steht Lighthouse unter dem Tab «Audits» zur Verfügung.
Wer die immer neuste Version von Lighthouse nutzen möchte, installiert am besten das entsprechende Chrome-Plugin. So ist zum Beispiel die Testgruppe SEO vorerst nur im Plugin verfügbar und wird den Weg in die DevTools finden, sobald die Entwickler die Funktion auf «die grosse Masse» loslassen möchten.
Nebst den Audits direkt im Browser kann Lighthouse auch auf der Kommandozeile und damit programmatisch, zum Beispiel in Build-Tools, genutzt werden. Lighthouse steht dazu als Node-Modul zum Download.
Ende November 2017 erreichten wir einen Meilenstein: Wir haben unseren zentralen Datenspeicher und damit alle Websites unserer Kunden auf superschnelle SSD umgestellt. Die Benchmarks waren fantastisch. Die Kunden überglücklich. Wir auch.
Kurz nach dem Jahreswechsel standen dann ein paar Updates unseres Datenspeichers auf dem Programm. Guter Dinge haben wir also losgelegt. Doch da tauchte wie aus dem Nichts ein Problem auf: Die Performance unseres Datenspeichers war plötzlich im Keller.
Erste Kunden haben sich bei uns gemeldet. Wir waren ahnungslos. Und ziemlich frustriert.
Vor wenigen Tagen (bzw. Nächten) dann die grosse Erlösung: Wir haben das Problem gefunden. Die volle Performance ist zurück. Entsprechend gross die Erleichterung. Doch was war das Problem?
In diesem Blogpost nehmen wir Sie mit auf eine Reise hinter die Kulissen und in die Tiefen eines zentralen Datenspeichers. Und möglicherweise hilft dieser Beitrag irgendwann und irgendwo einem anderen verzweifelten Ceph-Administrator.
Die Ausgangslage: Ein Update steht an
Ein zentraler Datenspeicher besteht aus zwei Komponenten:
Der Hardware: Also aus den eigentlichen Festplatten. Diese Festplatten sind in Server eingebaut, was bei uns dann ungefähr so aussieht:
Der Software, welche die Hardware steuert. In unserem Fall ist das Ceph.
Für Ceph werden regelmässig neue Versionen veröffentlicht, welche Fehler beheben und neue Funktionen bringen. So gehört es also zu den Routineaufgaben eines Ceph-Administators, alle paar Monate ein solches Update einzuspielen.
Am 2. Januar 2018 haben wir mit den vorbereitenden Arbeiten begonnen:
Wir haben das Betriebssystem aller Ceph-Nodes von RHEL 7.3 auf RHEL 7.4 aktualisiert – damit einher gehen viele Treiber-Updates, ein neuer Kernel etc.
Selbiges haben wir auf den sogenannten Hypervisors gemacht, also unseren Servern, die wiederum die (virtuellen) Kundenserver beherbergen.
Zeitgleich wurden die Sicherheitslücken Meltdown und Spectre bekannt und wir haben flottenweit Patches eingespielt.
Während den Updates wurde uns ein Bug bekannt: Sind HDDs und SSDs in einem Server (in diesem Kontext auch Node genannt) gemischt, können Daten, die aus Gründen der Redundanz zwingend auf verschiedener Hardware abgelegt werden müssten, auf dem gleichen Node gespeichert werden. Fällt ein Node aus (z.B. bei einem Neustart nach einem Kernel-Update), schaltet Ceph die davon betroffenen Daten in den Nur-Lesen-Modus, weil die Konsistenz der Daten nicht mehr gewährleistet werden kann. Unseren Kundenservern gefällt das natürlich gar nicht, wenn sie plötzlich nicht mehr Daten schreiben können. Die vorläufige Lösung für das Problem: Von drei Kopien auf vier Kopien erhöhen. So konnten wir sicherstellen, dass immer ausreichend Kopien aller Daten auf unterschiedlicher Hardware gespeichert ist.
Am 8. Januar dann haben wir mit dem eigentlichen Update der Ceph-Software begonnen. Das Update wird Stück für Stück ausgerollt und tangiert mehrere Stellen: Sowohl die Nodes wie auch die Kundenserver.
Und während all diesen Updates merken wir: Die Performance ist nicht mehr, wie sie sein soll.
Die Performance bricht ein. Was ist nun schuld?
Das Problem: Wir haben in der Vorbereitung mindestens fünf umfangreiche Änderungen in relativ kurzer Zeit vollzogen, was die Fehlersuche entsprechend schwierig gestaltete.
Mit vereinten Kräften, Beihilfe des Herstellers Red Hat und in unzähligen, zusätzlichen Nachtschichten haben wir uns akribisch vorgearbeitet. Dabei galt es nach dem Ausschlussverfahren herauszufinden, an welcher Stelle es genau klemmt. War es das Update des Betriebssystems? Die vierte Kopie? Das eigentliche Update von Ceph? Eine Konfigurationseinstellung in Ceph, die nicht (mehr) ideal ist?
Um jeweils einen Vergleich zu haben, führten wir vor und nach jeder gemachten Änderung Benchmarks durch. So auch am 30. Januar, als ein paar Änderungen an den Kerneleinstellungen vorgenommen wurden.
Zwei anschliessend ausgeführte Benchmarks im Abstand von ungefähr 30 Sekunden zeigten etwas Auffälliges: Die Ergebnisse lagen um Faktor 10 massiv weit auseinander.
Was schwankt hier so?
Das liess aufhorchen: Eine solche Diskrepanz innert so kurzer Zeit und bei etwa gleichzeitiger Auslastung war mehr als auffällig.
Ebenfalls interessant: Auf einigen Festplatten traten sogenannte Slow Requests auf – also Anfragen an die Festplatten, die über 30 Sekunden benötigen, um beantwortet zu werden. Das war jenseits von gut und böse und im Normalbetrieb absolut nicht erklärbar.
Ein Blick auf die Auslastung einer einzelnen Festplatte zeigte während des Auftreten der Slow Requests auch einen plötzlichen Sprung:
Das muss soweit nicht aussergewöhnlich sein: Es ist durchaus denkbar, dass eine Festplatte plötzlich mehr zu tun hat und etwas abarbeiten muss.
Nur: Die Festplatte hatte während dieser Zeit gar nicht mehr Arbeit zu erledigen:
Die Anzahl Schreib- und Leseoperationen der Festplatte war in etwa konstant – ein plötzlicher Anstieg liess sich nirgends erkennen. Wie also konnte die Auslastung der Disk steigen, obwohl die anfallende Arbeit unverändert war?
In der Latenz, also der Reaktionszeit der Festplatte, war der Ausschlag dann wieder deutlich sichtbar:
Ein erstes Muster lässt sich erkennen
Das Spiel ging weiter. Betrachtete man die Auslastung der Festplatte über einen grösseren Zeitraum, zeigte sich dieses Bild:
Was auffiel: Die Sprünge in der Auslastung erfolgten mit verdächtiger Regelmässigkeit. Und das auf allen Festplatten in einem Node gleichzeitig. Dann wurde es ganz verrückt: Die Sprünge in der Auslastung waren nicht nur auf den Festplatten zu sehen, die in den zentralen Datenspeicher integriert sind, sondern auch auf den Festplatten, auf welchen das Betriebssystem der Nodes abgelegt ist und welche mit dem Rest überhaupt nichts am Hut haben.
Die heisse Spur: Ceph ist unschuldig
An dieser Stelle wurde klar: Das Problem hat gar nicht direkt mit Ceph zu tun.
Ein Blick zurück verriet dann auch, ab wann diese seltsamen Lastspitzen auftreten:
Am 15. Dezember. Da war doch unsere Weihnachtsfeier. Und ein Freitag. Auch ein Blick in unser internes Änderungsprotokoll zeigte nichts Verdächtiges:
Dann noch einen Blick in den internen Chat. Die brennende Frage: Was ist am 15. Dezember geschehen? Und da. In der Historie tauchte dieser Code-Schnipsel auf:
Die Puppen tanzen
Wir verwenden für das Management unserer Server das Tool Puppet. Alle 30 Minuten prüft Puppet die Konfiguration eines Servers und rollt ggf. Änderungen aus.
Für Puppet gibt es ein kleines Helferlein namens Facter, dass vor einem sogenannten Puppet-Run Informationen aufbereitet, die dann anschliessend von Puppet genutzt werden können. Solche Informationen können z.B. der verfügbare Arbeitsspeicher oder der verwendete Prozessor sein.
Und das Helferlein lässt sich auch erweitern. So ist es für uns z.B. wichtig, in einem Node die sogenannten Festplatten-IDs zu kennen. Damit können wir beispielsweise das Status-Lämpchen einer bestimmten Festplatte blinken lassen. Ist eine Festplatte defekt und muss ersetzt werden, lassen wir das Lämpchen blinken und der Mitarbeiter vor Ort hat eine zusätzliche Kontrolle, sicher die richtige Disk in den Fingern zu haben.
Jetzt taute es: Am 15. Dezember hatten wir das Tool «Facter» erweitert, damit es für uns fortan auch die Festplatten-IDs einsammelt. Eine winzige und unscheinbare Änderung, möchte man meinen.
Aber jetzt war der Fehler gefunden: Das Auslesen dieser Festplatten-Informationen führte dazu, dass alle Disks fehlerhafterweise für ungefähr 5 Sekunden nicht mehr reagieren. Das Auslesen geschieht über den RAID-Controller und, wie sich herausstellte, ist dieses Fehlverhalten ein Bug des RAID-Controllers. Ein Update der RAID-Controller-Firmware behebt das Problem.
Was also ist genau passiert? Aktuell haben wir 34 Nodes in Betrieb. Wenn alle 30 Minuten Puppet bzw. Facter durchläuft, gerät durchschnittlich etwa alle 53 Sekunden ein einzelner Node für etwa 5 Sekunden ins Stocken.
Das gibt dann über den ganzen Datenspeicher gesehen (und Daten werden immer über den ganzen Datenspeicher verteilt) ca. 48 Sekunden Normalbetrieb, dann wieder 5 Sekunden stockender Betrieb und so weiter. Womit auch die unterschiedlichen Benchmark-Ergebnisse erklärt wären.
Die grosse Erlösung
Flink wurde also das Einsammeln der Disk-Informationen vorläufig abgeschaltet und voilà: Ein Blick auf einen Server zeigte Folgendes:
Die Kurve ist wieder, wie sie sein soll: flach. Man sieht hier den sogenannten I/O-Wait, also die Zeit, welche ein Prozess auf dem Server auf Antwort des zentralen Datenspeichers warten muss.
Die Erleichterung ist riesig!
Besonders gemein an der Sache war, dass die Performance-Einbussen schon seit dem 15. Dezember bestanden hatten, in diesen Tagen aber niemandem etwas aufgefallen ist. Schliesslich war ja auch Weihnachten und generell herrschte weniger Betrieb als sonst.
Somit haben wir die Quelle des Übels am völlig falschen Ort vermutet: In den Änderungen, die ab dem 2. Januar durchgeführt wurden.
Inzwischen sind wir enorm erleichtert und glücklich darüber, das Problem gefunden zu haben. Wir gehen mit einem grossen Zuwachs an Erfahrung aus dieser nervenaufreibenden Zeit hervor.
Und natürlich tut es uns leid, dass die Performance-Probleme gerade bei datenbankintensiven Operationen auch auf Kundenseite zu spüren waren. Dafür und für die entstandenen Unannehmlichkeiten möchten wir uns bei Ihnen in aller Form entschuldigen.
