Vor langer Zeit wurde es gefordert und hier ist es: eine Anleitung inklusive Erklärung wie man mit netcat einen Proxy für eine TCP-Verbindung baut, der bei Bedarf auch den Traffic anzeigt oder speichert.
Zunächst einmal benötigt man einen Server zu dem der Client sich normalerweise direkt verbinden würde. Wer live mittesten will, kann sich mit netcat einen basteln:
nc -l -p 1220
Nun wollen wir aber einen Proxy. Hierfür lauschen wir mit einem weiteren netcat-Prozess auf einem anderen Port. Der Client soll sich dann mit dem Proxy verbinden, und der Proxy soll den Traffic an den Server (Port 1220) senden. Bevor wir zur kompletten Lösung für bidirektionale Traffic-Weiterleitung kommen, hier erstmal der einfache Fall nur für eine Richtung.
nc -l -o 1221 | nc localhost 1220
Mit einer einfachen Pipe wird die Ausgabe des Proxies, also die Daten, die der Client sendet, zu dem Server gesendet. Alles was der Server sendet, wird jedoch vom netcat-Prozess, der den Proxy mit dem Server verbindet (nc localhost 1220), auf stdout ausgegeben. Was also fehlt ist, dass die Ausgabe dieses Prozesses als Eingabe für den Proxy dient. Und dafür benutzen wir eine Named Pipe (FIFO).
Eine normale Pipe besteht nur aus zwei Filedeskriptoren und kann daher nur an Kindprozesse weitergegeben werden. Eine FIFO hingegen wird im Dateisystem abgebildet und jeder Prozess kann auf diese zugreifen. Erstellen können wir eine FIFO mit dem Befehl mkfifo.
mkfifo fifo
Dann erweitern wir den Befehl für den Proxy noch so, dass der Proxy-Prozess seine Eingabe aus der FIFO bezieht und der zweite netcat-Prozess seine Ausgabe in die FIFO schreibt.
nc -l -o 1221 < fifo | nc localhost 1220 > fifo
Jetzt wird der ganze Traffic in beide Richtungen weitergereicht, wir wollen ihn jedoch noch im Terminal anzeigen lassen oder loggen. Hierfür verwenden wir das Tool tee, welches seine Eingabe auf stdout ausgibt und sie zusätzlich noch in eine Datei schreibt. Damit können wir jetzt z.B. den Traffic in zwei separaten Dateien loggen:
nc -l -p 1221 < fifo | tee client.log | nc localhost 1220 | tee server.log > fifo
Den Traffic im Terminal anzeigen kann man, in dem man /dev/tty zur Hilfe nimmt. Dieses ist ein spezielles Device, was für das Terminal des aktuellen Prozesses steht. Daten, die wir in /dev/tty reinschreiben, werden im Terminal ausgegeben.
nc -l -p 1221 < fifo | tee /dev/tty | nc localhost 1220 | tee fifo
Eine weitere Möglichkeit ist, den Traffic in eine weitere FIFO zu schreiben. Aus dieser kann man in einem anderen Terminal dann mit cat oder einem anderen Programm den Traffic live mitlesen.
mkfifo traffic
nc -l -p 1221 < fifo | tee traffic | nc localhost 1220 | tee traffic > fifo
Beachten muss man dabei jedoch, dass man erst aus der traffic-FIFO liest, bevor Daten übertragen werden, da das Öffnen einer FIFO blockiert, bis das andere Ende geöffnet wird. Solange also die traffic-FIFO nicht geöffnet wird, blockieren die tee-Prozesse, was das ganze Konstrukt aufhält.
Mal wieder Mist in Mercurial committed? Kein Problem. Mit der Strip Extension können Changesets entfernt werden. Praktischerweise ist diese auch standardmäßig bei Mercurial dabei und muss nur noch aktiviert werden. Hierfür muss in der .hgrc-Datei des Repositories folgendes eingefügt werden:
[extensions]
strip =
Danach kann ein Changeset und alle seine Nachfolger mit dem strip Befehl entfernt werden:
hg strip <rev>
Falls Änderungen schon auf einen Server gepusht wurden, kann man dies auch dort erledigen, falls man Shell-Zugriff hat.
Dieser Artikel ist ein Step-by-step Howto für die Einrichtung von dav-sync mit aktivierter Verschlüsselung.
1. Repository konfigurieren
Zuerst erstellen wir ein Repository mit Hilfe des add-repository Befehls von dav. Wichtig ist, dass wir dabei auch Benutzername und Passwort angeben, da dav-sync Authentifizierungsinformationen benötigt und diese nicht zur Laufzeit vom Benutzer abfragt.
$ dav add-repository
Each repository must have an unique name.
name: myfirstrepo
Specify the repository base url.
url: https://mynas.local/webdav
User for HTTP authentication.
user (optional): mywebuser
password (optional):
2. Key erstellen und konfigurieren
Als nächstes benötigt man einen AES-Key. Diesen erstellen wir aus zufälligen Daten mit Hilfe von dd:
mkdir -p ~/.dav/keys
dd if=/dev/random of=~.dav/keys/mykey bs=32 count=1
Dann muss in der Datei $HOME/.dav/config.xml nur noch ein Eintrag für den Key hinzugefügt werden.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
...
<key>
<name>mykey</name>
<type>aes256</type>
<file>keys/mykey</file>
</key>
</configuration>
3. Verschlüsselung für das Repository aktivieren
Wärend man mit dem Tool dav die Verschlüsselung per Kommandozeilenoption an- und abschalten kann, benutzt dav-sync immer die Default-Einstellungen des Repositories. Daher muss für das Repository die Verschlüsselung standardmäßig aktiviert sein und ein Default-Key muss angegeben werden. Hierfür fügt man innerhalb des <repository>-Elements das <full-encryption> und <default-key>-Element hinzu:
<repository>
...
<full-encryption>true</full-encryption>
<default-key>mykey</default-key>
</repository>
3. Sync-Directory erstellen
Letztendlich benötigt man noch die eigentliche Konfiguriation für dav-sync. Mit dem Befehl add-directory von dav-sync erstellen wir die Konfiguration für ein Sync-Directory. Dabei gibt man dann das Repository mit aktivierter Verschlüsselung an:
$ dav-sync add-directory
Each sync directory must have an unique name.
name: mysyncdir
Enter local directory path.
path: $HOME/important_files
Specify webdav repository.
0) myfirstrepo
1) anotherrepo
repository: 0
Enter collection relative to the repository base url.
collection (default: /): /important_files
Fertig. Für den Benutzer ändert sich an der Bedienung von dav-sync dann nichts. Man kann ganz wie gewohnt mit pull/push seine Dateien synchronisieren, nur dass sie dann verschlüsselt auf dem Server liegen.
Teil des dav Pakets ist das separate Tool dav-sync, das lokale Verzeichnisse mit WebDAV-Collections synchronisieren kann.
Features
- Verwendet die selbe Repository-Konfiguration von dav, womit Dinge wie Verschlüsselung oder Proxies zur Verfügung stehen
- Separate Befehle um die Änderungen vom Servers zu downloaden und um die lokalen Änderungen auf den Server zu übertragen
- Konflikterkennung
- Trash-Verzeichnis, in dem Dateien, die gelöscht oder überschrieben werden sollen, abgelegt werden können
- Regex-Filter, um bestimmte Dateien einzubeziehen und/oder auszuschließen
Funktionsweise
Jedes Sync-Directory hat eine Datenbank (in Wahrheit nur eine billige XML-Datei), in der Zustandsinformationen jeder Datei gespeichert sind. Im Detail sind das der Etag, die Dateigröße und das Datum der letzten Änderung. Diese Informationen werden genutzt um Änderungen zu erkennen. Um Änderungen auf dem Server zu erkennen, wird der Etag jeder Datei verglichen und um lokale Änderungen zu erkennen wird das Änderungsdatum und die Dateigröße mit den Werten in der Datenbank verglichen.
Konfiguration
Zunächst einmal muss ein Repository für den Server konfiguriert werden. Am einfachsten geht dies mit dem Befehl dav add-repository. Siehe meinen Artikel zu dem Thema.
Als nächstes muss noch das lokale Verzeichnis in der Datei $HOME/.dav/sync.xml konfiguriert werden. Eine einfache Basiskonfiguration kann mit dem Befehl dav-sync add-directory angelegt werden.
Dies fragt zuerst nach einem frei wählbaren Identifier für das Verzeichnis, der dann auch mit den anderen dav-sync Befehlen genutzt wird. Danach muss der lokale Pfad angegeben werden, wobei man im Pfad auch Umgebungsvariablen wie $HOME verwenden kann. Danach folgt noch das Repository und die Collection des Repositories, in welche die Dateien dann synchronisiert werden sollen. Die volle URL ist der angegebene Collection-Pfad angehängt an die Basis-URL des Repositories.
$ dav-sync add-directory
Each sync directory must have an unique name.
name: mysyncdir
Enter local directory path.
path: $HOME/important_files
Specify webdav repository.
0) myfirstrepo
1) anotherrepo
repository: 0
Enter collection relative to the repository base url.
collection (default: /): /important_files
Danach kann man seine Daten mit den Befehlen pull und push synchronisieren. Es werden von dav-sync alle Einstellungen des Repositories verwendet, also Authentication-Informationen, TLS-Einstellungen und AES-Verschlüsslung. Zu beachten ist auch, dass dav-sync keinen Authentication-Prompt anzeigt, daher müssen Authentication-Daten im Repository konfiguriert sein.
Anwendung
Für die Synchronisation gibt es primär zwei Befehle: pull, um Dateien, die auf dem Server geändert wurden, zu downloaden und push, um lokale Änderungen auf den Server zu uploaden. Man gibt dabei nur den Identifier des Verzeichnisses an, z.B. um Änderungen zu downloaden:
dav-sync pull mysyncdir
Änderungen uploaden geht mit:
dav-sync push mysyncdir
Wer komplett das Verzeichnis mit dem Server synchronisieren will, damit sie den gleichen Zustand haben, sollte zunächst pull und danach push aufrufen:
$ dav-sync pull mysyncdir
...
$ dav-sync push mysyncdir
...
Im besten Fall werden dabei einfach nur Dateien gedownloadet bzw geuploadet. Wenn jedoch Dateien lokal und auf dem Server geändert wurden, führt dies zu einem Konflikt. Der push-Befehl ignoriert solche Dateien einfach. Beim pull-Befehl wird die entsprechende Datei umbenannt und die Version des Servers wird unter dem originalen Namen gespeichert. Der Anwender muss dann selber die Dateien vergleichen und entscheiden welche er behalten will. Die umbenannten Dateien der Form orig.$number.$name werden im übrigen von push ignoriert, da sie als Konflikt markiert sind. Wer sie trotzdem uploaden will, kann sie einfach umbenennen oder mit dav-sync resolve-conflicts <syncdir> die Konfliktmarkierung entfernen, wonach sie für dav-sync ganz normale Dateien sind. Mit dav-sync delete-conflicts <syncdir> können auch alle diese Dateien entfernt werden.
Gelöschte und überschriebene Dateien wiederherstellen
Wie anfangs erwähnt unterstützt dav-sync ein Trash-Verzeichnis, in das es alle Dateien verschiebt, anstatt sie zu löschen. Wenn mit dav-sync add-directory das Sync-Directory angelegt wurde, ist das Trash-Verzeichnis auch standardmäßig aktiviert und ist das .trash Unterverzeichnis des Sync-Directory.
Wann immer pull also eine Datei löschen will, wird diese dann in das Trash-Verzeichnis verschoben. Das schützt schon mal vor unbeabsichtigten Löschen. Es gibt zusätzlich noch die Möglichkeit, dass auch Dateien, bevor sie durch den pull-Befehl überschrieben werden, in das Trash-Verzeichnis verschoben werden. Hierfür muss in der sync.xml innerhalb des entsprechenden <directory>-Elements folgendes eingefügt werden:
<directory>
...
<backup-on-pull>true</backup-on-pull>
</directory>
Diese Datensicherheit hat natürlich den Preis, dass viele Kopien einer Datei irgendwann rumliegen. Mit dav-sync trash-info <directory> erhält man einen Überblick darüber, wie viele Dateien im Trash sind, und wie viel Platz sie verbrauchen. Wer das Trash-Verzeichnis leeren will, kann hierfür dav-sync empty-trash <directory> benutzen.
Es ist an der Zeit für ein dav Minor-Update. Dieses beinhalt hauptsächlich kleine neue Features sowie ein paar Detailänderungen und einen kritischen Bugfix.
Neu bei dav-sync ist, dass der Synchronisationsvorgang mit SIGINT (Ctrl+C) sauber abgebrochen werden kann. Die aktuelle Datei wird noch zuende gedownloadet bzw geuploadet und danach das Programm beendet. Beim nächsten pull/push wird dann der Rest synchronisiert.
Desweiteren gibt es jetzt für dav-sync das archive Kommando, was nur geänderte oder neue Dateien auf den Server uploadet, jedoch keine Dateien auf dem Server löscht.
Neu bei dav ist das remove-property Kommando. Um den Umgang mit Properties zu erleichtern können nun auch XML-Namespaces in der config.xml Datei mit dem neuen <namespace>-Element konfiguriert werden, so dass man bei den Befehlen nur noch einen benutzerdefinierten Prefix angeben muss.
Sowohl dav als auch dav-sync können jetzt auch WebDAV-Locks mit Timeout erstellen.
Eine vollstände Liste der Änderung gibt es in der CHANGELOG-Datei.
Downloads gibt es hier oder auf Sourceforge. Die Dokumentation liegt dem Quellcode bei und ist auch online verfügbar.
Kommentare
dev | Artikel: Datei ver- und entschlüsseln mit openssl - kompatibel mit dav
Andreas | Artikel: Datenanalyse in der Shell Teil 1: Basis-Tools
Einfach und cool!
Danke Andreas
Rudi | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Damit wird Nedit durch XNedit ersetzt.
Danke!
Olaf | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Anti-Aliasing hängt von der Schriftart ab. Mit einem bitmap font sollte die Schrift klassisch wie in nedit aussehen.
Einfach unter Preferences -> Default Settings -> Text Fonts nach einer passenden Schriftart suchen.
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Mettigel | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ich hatte gedacht, dass der GX-415 im s920 deutlich mehr Dampf hat als der Raspi4.
Mein Thinclient verbraucht mit 16 GB RAM ~11 W idle, das ist das Dreifache vom RP4. Das muss man dem kleinen echt lassen... Sparsam ist er.
Olaf | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ergebnisse von der Ultra 80 wären natürlich interessant, insbesondere im Vergleich mit dem rpi1.