Archiv des Autors: David Scherfgen

Wenn wget versagt: PhantomJS

Aus einem gewissen Grund brauche ich regelmäßig die aktuellen IP-Ranges von Amazon EC2 (ein Produkt für Cloud Computing). Zum Glück gibt es im entsprechenden Amazon-Forum einen Thread, in dem immer die aktuellen IP-Ranges aufgelistet sind. Bis vor einiger Zeit konnte ich diesen Thread problemlos wie folgt herunterladen, um ihn dann mit einem regulären Ausdruck nach IP-Ranges zu durchsuchen:

wget -O amazon_ec2.txt https://forums.aws.amazon.com/ann.jspa?annID=1701

Nun geht das nicht mehr — man erhält nur eine Fehlermeldung, dass der Browser JavaScript unterstützen muss. Das Forum arbeitet jetzt scheinbar Client-seitig mit JavaScript, und wget kann kein JavaScript ausführen.

Doch zum Glück gibt es PhantomJS! Dabei handelt es sich um ein Tool, das sozusagen einen Browser simuliert und mit JavaScript gesteuert werden kann. Mit folgendem Skript kann ich die Seite laden und ihren HTML-Quellcode ausgeben, womit das Problem gelöst ist:

var page = require("webpage").create();
page.open("https://forums.aws.amazon.com/ann.jspa?annID=1701",
 function(status) {
  var f = function() {
   var html = page.evaluate(function() { return document.documentElement.innerHTML; });
   console.log(html);
   phantom.exit();
  };
  setTimeout(f, 10000);
 }
);

Die Verzögerung von 10 Sekunden sorgt dafür, dass alle Umleitungen (mit hoher Wahrscheinlichkeit) abgeschlossen sind, bevor der HTML-Quellcode ausgegeben wird. Es geht wahrscheinlich auch eleganter, aber es erfüllt seinen Zweck.

Bislang habe ich für solche Zwecke übrigens Awesomium benutzt, was auch ganz nett ist, aber hier gibt es schon seit Ewigkeiten keine 64-Bit-Version mehr für Linux (eigentlich ein Unding). Vielleicht werde ich meine schon existierenden Anwendungen, die auf Awesomium basieren, auf PhantomJS portieren.

Nachtrag (1. Oktober 2016): Dieser umständliche Weg ist für den konkreten Anwendungsfall nicht mehr nötig, da Amazon die IP-Ranges nun als JSON-Datei bereitstellt.

Expedition ins schwarze Loch

… so hieß eine Dokumentation, die ich gerade auf N24 gesehen habe. Es handelte sich dabei um eine Folge von Sci Fi Science: Physics of the Impossible. Was einem da geboten wurde, war absolut haarsträubender Unfug, der aber so präsentiert wurde, als ob es sich dabei um wissenschaftliche Fakten handeln würde.

Laut Michio Kaku, dem Moderator der Sendung, sollte es möglich sein mit einem Raumschiff in ein schwarzes Loch zu fliegen. Es gibt da nur ein Problem, das er Spaghettisierung nennt: Das Raumschiff wird zu einem Punkt zerdrückt bzw. unendlich in die Länge gezogen. Aber das ist ja nicht so schlimm, dann nähern wir uns dem schwarzen Loch einfach von oben(!), wo sein Gravitationsring nicht so stark ist. Dort ist es ganz ruhig, wie im Auge eines Wirbelsturms, so dass wir bis zur Öffnung des „Wurmlochs“ vordringen können. Aber so ein Wurmloch ist sehr instabil, wir müssen es offen halten. Dazu brauchen wir die seltenste Substanz des Universums: negative Materie. Die gibt es in Form von negativen Asteroiden am Rand des Universums. Wir schicken also ein paar Drohnen zum Rand des Universums, um sie einzusammeln. Habe ich schon erwähnt, dass negative Materie Antigravitation erzeugt? Damit können wir das Wurmloch stabil halten und hinein fliegen. Natürlich ergibt sich all das aus den Gleichungen von Albert Einstein! Die Leute, die der Moderator fragte (es handelte sich sinnvollerweise um betrunkene Besucher einer Diskothek), hielten die Vorgehensweise jedenfalls für eine gute Idee und würden sich sofort mit Michio Kaku ins Raumschiff setzen.

N24 ist mit dieser Sendung in ein schwarzes Loch der Fernsehqualität eingetaucht. Ich habe mir die ganze Zeit überlegt, was Harald Lesch wohl dazu sagen würde. Wahrscheinlich würde er tot umfallen.

NVIDIA-Treiber müllen Systempartition voll

Wer unter Windows regelmäßig seine NVIDIA-Grafikkartentreiber aktualisiert oder gar ständig die neuesten Betaversionen installiert, dem könnte bereits aufgefallen sein, dass nach jeder solchen Aktion etwas weniger freier Speicher auf der Systempartition übrig bleibt. Gerade bei einer SSD ist das ärgerlich, da diese für gewöhnlich nicht so groß ausfallen wie normale Festplatten.

Der Grund für den Platzschwund liegt darin, dass der Installer immer noch eine Kopie der gesamten Treiberkomponenten aufbewahrt, und zwar für jede Version, die man jemals installiert hat!

Um diesem hirnrissigen Spuk ein Ende zu bereiten, kann man ganz einfach alle Unterverzeichnisse aus folgendem Verzeichnis löschen:

C:\Program Files\NVIDIA Corporation\Installer2

Natürlich sollte man auch nicht vergessen, den temporären Ordner zu löschen, in den der Installer extrahiert wird. Standardmäßig ist das C:\NVIDIA. Auch hier fällt gerne nochmal ein halbes Gigabyte an Müll an.

Nachtrag (4. April 2016): NVIDIA empfiehlt, vor der Installation einer neuen Treiberversion zunächst den vorhandenen Treiber zu deinstallieren. Alternativ kann man während der Installation die Option „Perform Clean Install“ auswählen, die das automatisch erledigt. So hält sich der Ballast in Zukunft hoffentlich in Grenzen.

TFT-Bildschirm flimmert nach Schachbrett-Testmuster

Für meine Master-Arbeit muss ich mit einer Kamera einen (TFT-)Bildschirm abfilmen. Um zu bestimmen, wie lange es dauert, bis sich ein anzuzeigendes Bild auf dem Bildschirm „stabilisiert“ hat, habe ich ein kleines Testvideo erzeugt, das ein Schachbrettmuster darstellt. Die Felder des Schachbretts ändern in jedem Frame ihre Farbe von Weiß zu Schwarz bzw. umgekehrt, und das 60-mal pro Sekunde.

Ich dachte zuerst, dass meine Augen mich täuschen, als ich auch nach Beenden des Testvideos noch ein Flimmern auf dem Bildschirm sehen konnte. Tatsächlich oszillieren die Pixel, auf denen zuvor das Schachbrettmuster zu sehen war, jetzt bereits seit einer halben Stunde weiter! Besonders vor grauem Hintergrund kann man das Schachbrettmuster auch jetzt noch sehr gut erkennen. Ein- und Ausschalten des Bildschirms (auch am Netzschalter und durch Herausziehen des Stromkabels) hat nichts gebracht — die Pixel flimmern immer noch fröhlich weiter!

Es ist mir ein Rätsel, und ich hoffe, dass es irgendwann wieder aufhört zu flimmern …

Server-Backups im laufenden Betrieb mit LVM und ionice

LVM-Snapshots für konsistente Backups im laufenden Betrieb

Wie ich schon einmal erzählt habe, läuft mein Webserver als (bislang einzige) virtuelle Maschine auf meinem dedizierten Server. Die virtuelle Festplatte ist dabei in einem 200 GiB großen Logical Volume untergebracht. Logical Volumes werden mit dem Logical Volume Manager (LVM) erzeugt und sind sozusagen die moderne Version von Partitionen.

Ein Feature von LVM finde ich dabei besonders beeindruckend und extrem hilfreich, nämlich das Anfertigen von Snapshots von Logical Volumes. Ein Snapshot ist eine Momentaufnahme des kompletten Inhalts eines Logical Volumes. Einen Snapshot anzufertigen ist eine Angelegenheit von maximal ein paar Sekunden, es muss dabei nämlich nichts kopiert werden. Erst wenn im Original-Volume ein Datenblock geschrieben wird, muss dessen vorheriger Inhalt gesichert werden, damit er für den Snapshot noch verfügbar ist. Solch ein Verfahren nennt sich Copy-On-Write. Beim Erzeugen des Snapshots muss man bereits angeben, wie viele Daten sich höchstens ändern dürfen, während der Snapshot existiert.

Das Snapshot-Feature ist wie geschaffen für regelmäßige Backups eines Servers im laufenden Betrieb. Hierbei ist es nämlich wichtig, dass man den Inhalt sämtlicher Dateien quasi gleichzeitig sichert. Kopiert man einfach nur alle Dateien nacheinander, dann kommt es zwangsläufig zu Inkonsistenzen, wenn sich während des Backups etwas verändert (und das lässt sich kaum vermeiden, wenn der Server während des Backups benutzbar bleiben soll).

Also geht man wie folgt vor:

  1. Warten, bis alle Cronjobs abgeschlossen sind, denn wir möchten diese nicht unterbrechen. Danach am besten auch den Cron-Daemon anhalten.
  2. Apache und MySQL anhalten, um einen konsistenten Zustand der Datenbanken zu gewährleisten, ggf. noch weitere Dienste.
  3. Mittels lvcreate --snapshot einen Snapshot des Logical Volumes anfertigen, das man sichern möchte. Dabei muss man auch die Größe des Snapshots angeben, also wie viele Daten sich während seiner Existenz ändern dürfen. Ein oft empfohlener Wert ist 10% bis 20% der Größe des Logical Volumes, aber das hängt natürlich von der konkreten Situation ab.
  4. Jetzt, da der Snapshot erzeugt ist, können sämtliche Dienste wieder gestartet werden (Cron, MySQL, Apache, …). Die Downtime des Servers ist somit auf wenige Sekunden begrenzt.
  5. Nun kann der Snapshot „in Ruhe“ irgendwohin gesichert werden, z. B. via FTP. Ich bin dabei, meine eigene Backup-Lösung zu entwickeln, mit der die komplette virtuelle Festplatte blockweise gesichert wird (nicht auf der Ebene des Dateisystems, denn da gibt es immer Schwierigkeiten mit Besitzern, Rechten, Hardlinks, Softlinks usw.). Mehr dazu in einem späteren Beitrag.
  6. Sobald die Sicherung abgeschlossen ist, entfernt man den Snapshot wieder mit lvremove.

Mit nice und ionice die Reaktionszeit des Servers während des Backups verbessern

Das Sichern eines Snapshots beansprucht die Festplatte des Servers stark. Wenn man nicht aufpasst, reagieren Webseiten und andere Anwendungen, die auf dem Server laufen, während des Backups extrem langsam und träge.

Was viele nicht wissen: Unter Linux kann man nicht nur die CPU-Priorität von Prozessen ändern (mit nice), sondern auch ihre I/O-Priorität. Das funktioniert mit dem Befehl ionice, zu dem man diesen netten Artikel finden kann. nice und ionice lassen sich auch kombinieren. Somit kann man dafür sorgen, dass ein laufendes Backup die übrigen Prozesse weder in Sachen CPU noch in Sachen Festplatte zu sehr ausbremst.

Folgender Befehl startet das Skript backup.sh mit minimaler CPU- und I/O-Priorität:

nice -n 19 ionice -c 3 ./backup.sh

Nachtrag: Nach meinen ersten Erfahrungen kommt es auch bei der Verwendung der niedrigsten I/O-Priorität teilweise zu großen Beeinträchtigungen des Serverbetriebs. Abhilfe kann das Tool pv schaffen, mit dem man u. a. den Durchsatz einer UNIX-Pipe begrenzen kann. Somit kann man beispielsweise ein laufendes Backup auf eine Leserate von höchstens 60 MiB pro Sekunde drosseln. Eure Besucher werden es euch danken!

Noch ein Nachtrag: ZFS mit seinen ZVOLs ist nun meiner Meinung nach gegenüber LVM zu bevorzugen. ZFS bietet ebenfalls die Möglichkeit der Anfertigung von Snapshots, darüber hinaus wird die Integrität der Daten jedoch mit Prüfsummen sichergestellt. ZFS ersetzt auch MD (Software-RAID).