Eigentliche Intention war es, mal eben ein paar Dateien von einem Server a.D. zu kopieren und zu entschlüsseln. Entschlüsseln deshalb, weil sich an einer Freigabe des Systems ein Trojaner zu schaffen gemacht hatte, der im Namen der GEMA Geld verlangte, um die privaten Daten wieder zu entschlüsseln.
Wäre nicht da zumindest noch ein kleines Bisschen wirksamer Gesetzgebung, würde ich der GEMA solche Beugehaft durchaus zutrauen. Noch nimmt sie sich Derartiges zum Glück nicht heraus und so konnte ich davon ausgehen, dass es sich hier wirklich um Abzocke handelte. Diese Geschichte ist eigentlich auch schon ein alter Hut aus der nicht so fernen Vergangenheit, als es diesen Blog nicht gab. Sie sei hierdurch dennoch kurz angerissen, um die Ausgangslage zu erklären.
Ein Großteil der Daten hatte ich ohnehin schon Anfang des Jahres auf ein aktuelleres System mit größeren Platten gespiegelt, so das der Verlust nur den Zeitraum nach der Spiegelung, bis zu der überstürzten Inbetriebname des neuen Systems betroffen hätte. Glücklicherweise war der Trojaner und sein Wirken inzwischen im Netz bekannt und ein freundlicher Mensch Namens Mathias die Mühe gemacht, dafür einen Decrypter zu schreiben. Dieser war zwar in Java geschrieben, was aber auf dem betroffenen System tatsächlich installiert war.
Der einzige Schönheitsfehler an dem Tool war es, dass es über ein GUI gesteuert wird und damit nur remote auszuführen ist, wenn auf dem ausführenden zumindest die notwendigen Teile des X Window Systems installiert sind. Letzteres ist aber nicht der Fall, da der Server weder Bildschirm noch Tastatur hat und nur per WebUI, bzw. für die ganz harten Fälle auch von mir per ssh administriert werden soll.
Da ich nicht nur für das Entschlüsseln der Daten ein extra eine grafische Oberfläche aufsetzen wollte, blieb also nichts übrig, als dafür den selben Weg zu wählen, den auch der Trojaner genommen hatte: Indem das ganze Dateisystem von irgendwo auf einem anderen Rechner eingehängt wird. Der Versuch dies remote durchzuführen scheiterte an der Masse der Daten, einem 500kb/s Upstream und meiner Ungeduld.
Bestens vorbereitet, mit einem Skript, welches bereits im Vorfeld abgeglichen hatte, welcher Teil der betroffenen Daten noch nicht auf dem neuen System gespiegelt war, setze ich mich also vor Ort hin und decodierte Ordner für Ordner per Hand, bzw. per GUI. Damit dachte ich, ich wäre fertig.
Letzte Woche musste ich dann erfahren, dass immer noch Daten fehlen. Dies hatte zweierlei Ursachen. Zunächst hatte der Trojaner, warum auch immer, sein eigenes renaming Schema nicht eingehalten, so dass mein Skript einige Dateinamen nicht auf die (jetzt) Originale auf dem Spielgelserver mappen konnte. Viel schöner war aber noch die zweite Ursache. Anscheinend hatte jemand einen Wettbewerb ausgeschrieben, möglichst schlecht zu verarbeitende Dateinamen zu verwenden. An die Abart Dateinamen mit Leerzeichen zu verseuchen, damit jeder primitive Tokenizer daran verzweifelt, war ich ja schon gewöhnt, aber es mussten natürlich auch noch alle möglichen Sorten von Sonderzeichen mit in die Dateinamen und wenn das nicht schon genug wäre, wurden diese dem Server auch noch in verschiedenen Charsets übermittelt, während dieser ganz brav UTF8 erwartete.
Mein Skript, welches ganz normal den Systemzeichensatz verwendet, konnte damit natürlich nichts anfangen, insbesondere sed weigert sich, kryptische Sonderzeichen mit regulären Ausdrücken zu matchen. Erst recht nicht, wenn nicht mal ich (mit vertretbarem Aufwand) herausbekomme, was das ursprüngliche Charset gewesen ist, derer wurden mindestens vier verschiedene verwendet. Dass dies Niemandem auffiel und falls doch, warum niemand daraus die Konsequenz zog, Sonderzeichen in Dateinamen nicht zu verwenden, ist mir unbegreiflich. Selbst beim Kopieren von Fensterrechner zu Fensterrechner hätte das auffallen müssen.
Womit wir jetzt endlich wieder in der Gegenwart angekommen wären. Kurzer Hand ließ ich mich darüber in Kenntnis setzen, welche Dateien denn nun noch fehlten und schnappte mit den alten Server, den in der Zwischenzeit komischerweise wieder Jemand in Betrieb genommen hatte, um auf beiden Systemen parallel und verteilt zu arbeiten, vermutlich um jeden Rest dessen, was man hätte synchron nennen können zu beseitigen.
So riss ich den Rechner vor ein paar Stunden auf, um mich an dem Anblick eines Systems zu erfreuen, dass ohne jegliche Wartung, seit etwa 2005 24h am Tag durchgelaufen war. Spielerisch tippte ich gegen die Lüfter, eigentlich in der Erwartung, damit ein paar lustige Staubwölkchen hervorzurufen. Doch weit gefehlt. Der Prozessorlüfter und auch einer der Plattenlüfter hatten, zu einem nicht mehr zu ermittelnden Zeitpunkt, ihre Kugellager jeweils zu einer starren Masse vereinigt.
Moment?
Der Prozessorlüfter? Aha, das System hatte also mindestens einen Sommer, bei brütenden Temperaturen an seinem Standort, ohne aktive Kühlung überlebt. Der gut alte Arctic Copper Silent stand so lange still, dass er nicht einmal groß verstaubt war. An dieser Stelle ein großes Lob an das CPU Powermanagement der Kernel, welches höchstwahrscheinlich die AMD Sempron CPU vor dem Hitzetot gerettet hat.
Also endlich zur Platte. Der extra montierte Lüfter der Systemplatte war natürlich ebenso starr. Das Backup auf der zweiten Platte, war längst vollgelaufen, da ich eine COW Stragie verwendete, um sicher zu gehen, dass versehentliches Löschen oder Modifikationen auch durch Backup geschützt wurden. Es hatte eine Menge Überzeugungsarbeit gekostet, glaubhaft zu machen, dass eine übergelaufene Backupplatte zu einem Problem werden kann. Die konnte ich jetzt also auch nicht mehr verwenden. Demzufolge schloss ich heute Nachmittag die Systemplatte an ein externes Netzteil und es passierte - nichts. Nach dem dritten Startversuch war sie dann so nett, endlich, wenn auch unter Protest, anzudrehen. Erfreulicherweise erhielt ich, nach etwa zehn Minuten Überprüfung, die Bestätigung. Das Dateisystem ist noch intakt, die Daten nicht beschädigt - wenn man mal von der Verschlüsselung absieht.
Mir war allerdings, nachdem die Platte schon beim Start die Kooperation verweigerte, nicht ganz wohl bei dem Gedanken, mit dieser Platte noch weiter zu Arbeiten, geschweige denn sie noch einmal abzuschalten. So bin ich nun seit einigen Stunden damit beschäftigt, die Daten, als erste Maßnahme, zunächst auf ein frisches Dateisystem auf der bis jetzt nutzlosen Backupplatte zu kopieren. Diese erfreut sich noch bester Gesundheit, da sie nur einmal täglich des Nachts anlief, um sich zu synchronisieren. Sogar ihr Plattenlüfter funktionierte noch.
Aber das Alles wäre natürlich keine Herausforderung, wenn nicht hier auch irgendwas nicht so funktionieren würde, wie es soll. Aus spontaner Unlust, die beiden Platten in ein bestehendes System einzubauen, habe ich einen IDE->SATA->USB2 Adpter gebastelt, denn ich hatte keinen zweiten IDE Adapter. Und genauso selbstverständlich hat dieser jetzt natürlich einen Wackelkontakt, der den Kopiervorgang schon zwei mal unterbrochen hat. Unter Verwendung von rsync hat dies zum Glück keine negativen folgen, wenn vor dem erneuten Anschluss der Platte das Dateisystem überprüft wurde (rsync überprüft bestehende Daten auf Integrität und kopiert diese Notfalls neu). So werde ich den Spaß wohl so lange laufen lassen, bis ich die Bestätigung habe, dass alle Daten synchron sind.
Das gibt mir immerhin Zeit, einen elendig langen Blogbeitrag zu schreiben.
Achso, hatte ich erwähnt, dass es um nur etwa hundert kleine Dateien geht, die vermisst werden, von denen aber wahrscheinlich sogar irgendwo auf Desktoprechnern noch Kopien liegen? Die einzige Motivation für diesen Vorgang ist, dass ich dazu aktiv fast nichts tun muss und sicher stellen kann, dass am Ende keine fehlt.
fröhliches tldr