Aktuelle Informationen


Eine Alternative zum Exchange-Server von Microsoft

Exchange Alternative 

Für Unternehmen gibt es eine günstige Alternative zum Exchange-Server von Microsoft. Bei gleichem Funktionsumfang können sowohl Outlook als auch Mobilgeäte angebunden werden.


Wenn der Steuerpruefer Zugang zu den Mails haben moechte

Mailarchivierung nach GdPdu 

Ab Januar 2017 ist die Übergangszeit fue die Einführung einer Mailarchivierungslösung abgelaufen. Ab jetzt drohen auch in Düsseldorf empfindliche Strafen.

Projektbeschreibung

RBlkSync - Synchronisireung der Inhalte von Blockdevices lokal oder über ein IP-Netzwerk

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.


Besuchen Sie uns auch bei Facebook

Entlasten Sie Ihre IT und entscheiden Sie sich für unsere Produkte und unseren Support. Wir machen uns stark für Ihren Erfolg.