Projektbeschreibung

Unser RBlkSync wird ein Kommandozeilentool für Unix-ähnliche Betriebssysteme (programmiert auf und für Linux), mit dem der Anwender die Inhalte von Blockdevices auf einem Rechner, oder über ein IP-Netzwerk auf einen entfernten Rechner kopieren kann. Dabei kann die Quelle, wie auch das Ziel, aus einem Blockdevice oder einer Datei bestehen. Wenn das Ziel (Blockdevice oder Datei im Ziel) bereits existiert, sollen nur geänderte Blöcke kopiert werden. In einem solchen Fall nennen wir den Kopiervorgang synchronisieren, wofür das "Sync" im Namen steht.

Sind Quelle und Ziel unterschiedliche Systeme, so wird über ein IP-Netzwerk kopiert. In einem solchen Fall muss dafür Sorge getragen werden, dass die Kommunikation über das Netzwerk verschlüsselt wird. Hierzu soll RBlkSync zwei verschiedene Modi zur Verfügung stellen.

Im Server-Modus wird das lokale RBlkSync seine Daten an die Standard-Ausgabe senden - auf dem Zielserver RBlkSync im Servermodus gestartet, liest eingehende Datenströme von der Standard-Eingabe und verarbeitet diese. Antworten sendet die Serverseite von RBlkSync an seine Standard-Ausgabe, welche von dem lokalen RBlkSync an der Standard-Eingabe empfangen werden. So können die beiden Teile von RBlkSync miteinander über Standardein- und -augabe kommunizieren. Werden die beiden Teile von RBlkSync auf verschiedenen Rechnern gestartet und nutzt man zum Starten SSH, so erfolgt die Kommunikation dank SSH über das Netzwerk und wird verschlüsselt.

Im Daemon-Modus wird RBlkSync intern dafür Sorge tragen, dass die Netzwerkkommunikation verschlüsselt ist. Aus Performance-Gründen habe ich mich für eine synchrone Verschlüsselung entschieden, die Schlüssel dazu sollen über ein Public-Key-Verfahren ausgetauscht werden. Die Verschlüsselung soll per Default aktiv sein - bei einer Synchronisation im LAN aber abgeschaltet werden können. Gerne würde ich für die reine Nutzdatenübertragung UDP verwenden, um den TCP-Overhead einzusparen. Für die ersten Versionen werde ich allerdings TCP nutzen und später, sollten eingehende Tests mit UDP positiv verlaufen, die Datenübertragung per UDP als Option anbieten. Ich werde verschiedene Kompressionsverfahren für die Datenblöcke anbieten. Die Kompression der zu übertragenden Datenblöcke kann per Option abgeschaltet oder auch festgelegt werden. Bei der automatischen Kompression wird der "Sender" (die Quelle) anhand seiner Netzwerkwarteschlangen bestimmen, welches Kompressionsverfahren eingestzt wird. Je länger die Warteschlange für das Senden über das Netzwerk, je höher (und damit zeitaufwändiger) wird das Kompressionsverfahren gewählt.

Die Projektbeschreibung ist nicht final. Sollten uns während der Projektdurchführung weitere nützliche Features und Optionen einfallen, wird die Projektbeschreibung geändert.

Roadmap

• KW18-19/2023: Aufsetzen einer Programmier- und Testumgebung
• KW19-20/2023: Übertragen der Inhalte von Blockdevices, wenn Quelle und Ziel auf einem Rechner sind.
• KW20-21/2023: Berechnen von Hashes der Blöcke im Quell- und Zieldevice. Erstellen einer Queue zum Vergleichen der Hashes inkl. Entscheidung, ob kopiert werden soll/muss und Kopiervorgang auf dem lokalen Rechner.
• KW21-22/2023: Ausführliche und intensive Tests des bisherigen Stands der Software RBlkSync
• KW23/2023: Ausführliche und intensive Tests des bisherigen Stands der Software RBlkSync. Erstellen einer Beschreibung zur Installation und einer Dokumentation zur Anwendung, inkl. Manpage.
• KW24/2023: Bereitstellung einer Downloadmöglichkeit für die Alpha-Version.
• KW25-27/2023: Einführung von Multithreading (simultane Nutzung mehrere CPUs/Cores/Threads).
• KW28/2023: Erweiterung der Testumgebung auf zwei Rechner, damit ein Debugging unabhängig und simultan auf dem Quell- und Zielrechner durchgeführt werden kann.
• KW29-31/2023: Programmierung des Grundgerüsts des Servers, der auch als Daemon genutzt werden kann, für den Zielrechner. Erste Versuche, Informationen zu dem Zielblockdevice vom Zielserver zu erhalten.
• KW31-32/2023: Übertragung von (modifizierten) Blöcken vom Quell- auf den Zielrechner im LAN (ohne Verschlüsselung).
• KW32-33/2023: Erstellen eine Schlüsselpaars und Übertragung des Public Keys an den Zielrechner. Erstellen eines Internet Key Exchange-Verfahrens (IKE) zur Übermittlung des Schlüssels für die synchrone Verschlüsselung.
• Weitere Schritte folgen...

Hinweis

Die Roadmap ist eine grobe Zeitplanung und nicht final. Durch erhöhtes Arbeitsaufkommen kann sich die für solche Projekte zur Verfügung stehende Arbeitszeit vermindern. In einem solchen Fall müssen wir die Roadmap anpassen.

Live-Projektfortschritt

• 01. Mai 2023: Die Programmier- und Testumgebung ist fertig. Ich habe einen neuen Linux-Server in einem Rechenzentrum aufgesetzt, tightvncserver, xfce, java und eclipse-cdt installiert, um C-Programme unter Eclipse erstellen zu können. Nach der Installation eines verschlüsselten Tunnels auf den neuen Rechner (VNC kommuniziert unverschlüsselt) konnte ich mit einem TightVNC-Viewer sicher auf den XServer zugreifen. Ich habe ein neues Projekt "rblksync" angelegt und das Grundgerüst erstellt. Für Blockdevices werde ich Dateien, anlegen, z.B. mit
  dd if=/dev/zero of=/home/vnc/quelle1G bs=1G count=1
  und dann mit
  losetup -f /home/vnc/quelle1G
  zu einem Blockdevice "/dev/loop0" machen. Das muss ich als "root" machen und dem Benutzer, unter dem ich mit meinem VNC-Client angemeldet bin, noch Lese- und Schreibrechte auf das Blockdevice geben:
  chmod a+rw /dev/loop0

---

• 02. Mai 2023: Heute konnte ich mich mit "getopt" und "getopt_long" beschäftigen und "getopt_long" in der "main()-Funktion" von rblksync einsetzen, um Optionen und deren Parameter abzufragen. "getopt" und "getopt_long" sind Funktionen, die die C-Bibliothek zur Verfügung stellt und die argc und argv auswerten, die beim Start eine Linux-Programms an main() übergeben werden. Eine Beschreibung zur Verwendung von "getopt_long" in einem C-Programm folgt hier im Projekt kurzfristig.
• 12. Mai 2023: Die Funktion, um mit RBlkSync den Inhalt eines Blockdevices auf ein anderes Blockdevice auf dem gleichen Rechner zu kopieren/synchronisieren ist fertig. RBlkSync kann nun so eingesetzt werden, wie "dd" und zusätzlich nur "veränderte" Blöcke im Quelldevice auf das Zieldevice kopieren.
  Ob das ein Vorteil gegenüber "dd" ist, muss noch herausgefunden werden. "dd" kopiert jeden Block - ob er verändert ist, oder nicht. RBlkSync bildet Hashes um festzustellen, ob ein Block verändert wurde. Dazu muss der Quellblock und der Zielblock gelesen werden und jeweils ein Hash gebildet werden. Das kostet (Rechen-)Zeit und diese Zeit könnte länger sein, als den Block ohne Überprüfung auf Veränderung ins Ziel zu schreiben. Die Zeitmessung wird in den nächsten Tagen implementiert - dann gibt es Klarheit, ob RBlkSync einen Vorteil beim Kopieren von lokalen Blockdevices hat.