the sophtwearteam

Reparaturarbeiten

Aus ungeklärter Ursache konnte ich keine vernünftige Datensicherung auf meiner Debian VM mehr durchführen. Arbeiten am System waren stark eingeschränkt, weil sich z. B. die Bash-History nicht mehr verhielt, wie ich es gewohnt war. Auch das mounten entfernter Dateisysteme mit sshfs war nicht mehr möglich. Ich habe mehrere Anläufe gebraucht, bis ich heute endlich erfolgreich war.

Zuerst hatte ich auf der .bash_history keinerlei Rechte mehr. Das hab ich mal eben geändert. Aufgrund entsprechender Fehlermeldungen in meinem Backup-Report hatte ich offenbar auch weniger oder keine Rechte an gewissen Log-Dateien, die ich aber als Benutzer haben sollte. Auch das hab ich jetzt geändert. Dann habe ich mit dem mount-Befehl die gemounteten Dateisysteme anzeigen lassen und mit Erstaunen festgestellt, dass mein sshfs-mount wohl doch erfolgreich war, denn das entfernte Dateisystem war wohl mehrfach eingehängt, obwohl mit df nichts angezeigt wurde und der normalerweise problemlose Zugriff auf das Verzeichnis nicht mehr sinnvoll möglich war.

Der Mountpoint für das sshfs war zwar noch sichtbar, aber Rechte, Eigentümer und Gruppe waren jeweils mit zahlreichen Fragezeichen angezeigt worden. Nachdem ich also die Rechte erfolgreich geändert hatte und auch wieder Zugriff auf die Bash-History hatte, hab ich das System neu gestartet. Danach ging der sshfs-mount zuerst nicht. Ein rdiff-backup-Prozess hatte sich gleich nach dem Neustart den Mountpoint geschnappt und ihn mit Daten zugemüllt. Den Prozess konnte ich mit priviligierten Rechten (sudo) abbrechen, die Daten mit rm löschen und das sshfs nun erfolgreich mounten. Nun sieht es wieder so aus, wie ich es gewohnt bin.

Das Ganze hat sich schon seit etwa drei oder vier Wochen hingezogen. Ich bin noch nicht dahintergekommen, was hier schief gelaufen ist. Jetzt bin ich gespannt, ob mein Backup nun wieder funktioniert.

Die Lehren, die ich daraus ziehe

(Lessons learned)
Log-Dateien sollte man immer aufmerksam lesen, insbesondere, wenn Fehler auftreten oder Unregelmäßigkeiten. Wenn ich das beherzigt hätte, wäre ich vermutlich früher auf die Lösungen gekommen, die ich nun angewendet habe. Die Hinweise in den Logs hätten mich auf die richtige Spur bringen können - haben sie ja nun auch.

c’t sucks

Wieder einmal habe ich einen interessanten Artikel in der aktuellen Ausgabe (Nr. 17/2021) der c’t gefunden. Und wieder wurde ich enttäuscht, wie schon so oft in der Vergangenheit. Es ging auf Seite 162 darum, wie man entfernte verschlüsselte Linux-Systeme per ssh entsperrt. Das wäre für mich ein super Mittel gewesen, meinen Acer AC100 Mini-Server mit Fedora 34 Server Edition nach einem Neustart zu entsperren. Ich kann das ganze System bequem über eine Weboberfläche verwalten, Updates einspielen und so weiter. Aber wenn nach einem Update ein Neustart fällig ist, muss ich immer an den Rechner rennen und das Passwort für die Dateisystementschlüsselung eingeben. Das nervt und hilft mir nicht bei meiner geplanten Privatcloud-Lösung.

Deshalb hatte ich Hoffnung geschöpft, als ich den Artikel in der c’t fand. Aber wieder einmal große Enttäuschung, denn die dort vorgestellte Lösung gilt nur für auf Debian oder Ubuntu basierte Systeme. Mit Fedora und anderen funktioniert das so leider nicht. Es gäbe wohl aber andere Möglichkeiten, wie eine kurze Recherche im Internet ergeben hat. Ich kann das ganze mit einem aufwändigen Schlüsselverfahren und einem USB-Stick bewerkstelligen. Das muss ich mir aber noch mal bei Gegenheit mit viel Muße ansehen und probieren. Dann komme ich vielleicht mal an den Punkt, wo das dann für mich funktioniert und auch Sinn macht.