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.
Dieser Artikel soll einen kleinen Überblick über den WebDAV-Kommandozeilen-Client dav geben.
Features
Alle WebDAV-Methoden des Basisprotokolls sind implementiert und es stehen Subcommands dafür bereit, wobei diese die WebDAV-Methoden mehr oder weniger abstrahieren.
Im Detail unterstützt dav:
- Auflisten aller Kind-Ressourcen einer Collection. Sowohl nur die direkten als auch der komplette Baum aller darunter liegender Ressourcen können angezeigt werden.
- Download/Upload von einzelnen Dateien und Verzeichnissen
- Erstellen von WebDAV-Collections
- Löschen von Ressourcen und Collections
- Kopieren und Verschieben von Ressourcen
- Lese- und Schreibzugriff auf WebDAV-Properties
- Locking (exclusive lock)
- Proxy-Support
- AES-Verschlüsselung um Dateien und Dateinamen on-the-fly zu ver- und entschlüsseln
- Konfigurationsdatei für Repositories, Proxies und Verschlüsselung
URL
Alle Befehle von dav erwarten als Argument eine URL. Die URL kann eine normale http/https-URL sein, man kann aber auch nur den Hostnamen und Pfad angeben. Da dav intern libcurl verwendet, können wie bei curl auch der Benutzername und das Passwort mit der URL angegeben werden.
Um den Inhalt von http://example.com/webdav/ anzuzeigen geht also:
dav list http://example.com/webdav/
dav list example.com/webdav/
dav list user@example.com/webdav/
dav list user:pw@example.com/webdav/
Es ist jedoch auch möglich, Repositories für seine Lieblingsserver zu konfigurieren. In der dav Konfigurationsdatei muss für den Server der Repository-Name und die Basis-URL konfiguriert sein. Statt der ganzen URL reicht es dann nur den Repositorynamen und optional noch einen Pfad anzugeben.
Für unseren Beispielserver könnte die Konfigurationsdatei $HOME/.dav/config.xml dann so aussehen:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<repository>
<name>myserver</name>
<url>http://example.com/webdav/</url>
<!-- optional: username -->
<user>user</user>
<!-- optional: base64 encoded password -->
<password>MTIzNDU2Nzg=</password>
</repository>
</configuration>
Den Inhalt der Basis-URL anzuzeigen geht dann mit:
dav list myserver
Auf beliebige Ressourcen unterhalb der Basis-URL kann man zugreifen, in dem man an den Repositorynamen einen Pfad anhängt:
dav list myserver/collection/
Dies würde dann den Inhalt von http://example.com/webdav/collection/ anzeigen.
Anstatt das Repository per Hand in der config.xml Datei zu konfigurieren kann man auch den dav Befehl add-repository verwenden. Dieser startet einen kleinen Assistenten der den Namen des Repositories, die Basis-URL, den Benutzername und das Passwort abfragt und die Konfiguration dafür dann anlegt.
Befehle
list
Den list Befehl haben wir schon gesehen. Dieser zeigt alle Kind-Ressourcen (Dateien) einer Collection (Verzeichnis) an. Dieser funktioniert ähnlich wie das Unix-Tool ls (statt dav list kann man auch dav ls schreiben). Ohne Optionen werden nur die Namen der Member angezeigt:
$ dav list myserver
collection
file1
file2
file3
Wie bei ls gibt es auch die -l Option, mit der zusätzliche Informationen pro Ressource angezeigt werden:
$ dav list -l myserver
d- Feb 08 13:13 collection
-- 4.2 KiB Oct 11 2016 file1
-- 95 bytes Oct 11 2015 file2
-- 5.7 MiB May 24 21:13 file3
Das kleine d in der ersten Spalte zeigt an, dass die Ressource eine Collection ist.
get
Mit get können einzelne Ressourcen oder ganze Collections gedownloadet werden.
Eine einzelne Ressource downloaden geht mit:
dav get myserver/file1
Um eine Collection zu downloaden muss man die -R Option angeben. Es werden dabei die Member der Collection direkt in das aktuelle Arbeitsverzeichnis gedownloadet.
dav get -R myserver/collection
put
Mit put können Dateien und Verzeichnisse geuploadet werden. Das erste Argument ist die Ziel-URL, das zweite die zu uploadende Datei.
Ist das Ziel eine Collection wird dort eine neue Ressource mit dem Namen der Datei erstellt:
dav put myserver localfile.txt
Man kann beim Uploaden auch den Namen der Ziel-Ressource angeben:
dav put myserver/newfilename.txt localfile.txt
Auch alle Dateien eines lokalen Verzeichnisses können geuploadet werden:
dav put -R myserver/newdir/ localdir
andere Befehle
Mit mkdir können WebDAV-Collections erstellt werden:
dav mkdir myserver/newcol/
Ressourcen und Collections können mit remove entfernt werden:
dav remove myserver/file1
Eine komplette Übersicht über alle Befehle gibt es hier.
Nach langer Entwicklungszeit kann ich jetzt endlich dav 1.0 veröffentlichen. Dabei handelt es sich um einen Kommandozeilen-WebDAV-Client. Mit dabei ist auch das Tool dav-sync, welches lokale Verzeichnisse mit WebDAV-Server synchronisieren kann.
Neben der Grundfunktionalität wie Dateien up- und downloaden, Collections zu durchsuchen und was man sonst noch so mit WebDAV anstellen kann, bietet dav zwei besondere Features.
Das erste ist, dass man in einer Konfigurationsdatei die Zugriffsinformationen für seine WebDAV-Server, auf die man oft zugreifen will, hinterlegen kann. Das klingt zwar trivial, ich wollte es allerdings erwähnen, da es einem das Leben deutlich vereinfacht. Statt langen URLs muss man dann nur noch den Server-Alias und optional einen Pfad angeben.
Das eigentliche Killer-Feature ist jedoch die integrierte clientseitige AES-Verschlüsselung. Dateien können on-the-fly beim uploaden verschlüsselt werden und beim downloaden werden diese Dateien auch automatisch entschlüsselt. Neben den Dateiinhalten kann auch der Dateiname verschlüsselt werden. Die Benutzung von dav mit aktivierter Verschlüsselung unterscheidet sich dabei kaum.
Das zweite Programm ist dav-sync, für bidirektionale Dateisynchronisation. Ein häufiges Problem von Synctools ist Datenverlust, daher lag mein Fokus darauf genau das zu verhindern. Falls Dateien auf beiden Seiten verändert wurden, wird dies selbstverständlich beim Synchronisieren erkannt. Für zusätzliche Sicherheit sorgt aber ein Trash-Verzeichnis. Wann immer dav-sync Dateien löschen möchte, werden diese dann in dieses Verzeichnis verschoben. Optional können auch Dateien, bevor sie mit einer Version vom Server überschrieben werden, dorthin verschoben werden.
Genau wie dav unterstützt auch dav-sync clientseitige Verschlüsselung. Dateisynchronisierung über einen fremden Cloud-Server ist somit sicher.
Beide Programme kommen in einem Paket und können hier oder auf SourceForge gedownloadet werden. Auf SourceForge gibt es auch Windows Binaries.
Die Dokumentation liegt dem Quellcode bei und ist auch online verfügbar.
Software, die das GNU-Buildsystem verwendet, lässt sich mit ./configure gefolgt von make und make install kompilieren und installieren. Mit diesem Artikel möchte ich auf ein paar Features dieses Buildsystems hinweisen.
Build-Verzeichnis
Anstatt das configure-Script im Root-Verzeichnis der Software auszuführen, geht dies auch von einem anderen aus. Dies hat den Vorteil, dass alle erstellten Dateien in einem anderen Verzeichnis landen, also z.B.:
mkdir build
cd build
../configure
make
Nicht nur alle von configure erstellten Dateien landen dann im build-Verzeichnis, sondern auch alle Objekt-Dateien und was sonst noch so durch make erstellt wird.
config.site
Ein weiteres interessante Feature ist, dass das configure-Script am Anfang die Datei prefix/share/config.site lädt. Diese kann normale Shell-Kommandos enthalten. Anstatt also immer per Hand die gewünschten Umgebungsvariablen zu setzen, oder Dinge wie das libdir anzupassen, kann man diese Einstellungen über die config.site erledigen. Siehe Setting Site Defaults.
Make Targets
Alle kompilierten und andere durch make erstellte Dateien entfernt man mit make clean. Mit make distclean kann man auch alle durch configure erstellte Dateien löschen. Desweiteren gibt es noch make maintainer-clean, das alle reproduzierbaren Dateien löscht, bis auf das configure script und andere Dateien, die für configure erforderlich sind. Auch interessant ist make check, was Tests für die Software ausführt (falls welche vorhanden sind).
Desweiteren möchte ich noch mal meinen Artikel über den DESTDIR-Parameter bei make install erwähnen.
In Solaris sind Extended Attributes keine Key/Value-Paare, sondern werden als Dateien repräsentiert. Hinter jeder Datei im Dateisystem steckt eine weitere Datei-Hierarchie, die jedoch auf normale Dateien beschränkt ist, also keine Unterverzeichnisse oder Links erlaubt. Attribute sind somit nur Dateien, für die die selben Limits für die Dateigröße oder Namen gelten. Außerdem haben sie eigene Zugriffsrechte. Nur einen absoluten Pfad haben sie nicht.
Für den Zugriff auf Attribute über die Shell gibt es das runat Tool. Dieses macht nichts weiter als das Working-Directory auf das versteckte Attributverzeichnis zu setzen und dann ein gewünschtes Kommando auszuführen. Man kann auch einfach eine Shell für dieses Verzeichnis starten. Um die Attribute dann zu lesen, schreiben oder aufzulisten können prinzipiell alle Programme verwendet werden.
$ touch test.txt
$ runat test.txt sh
$ echo "xattr test string" > testattribute
$ echo "text/plain" > mime_type
$ ls
mime_type SUNWattr_ro SUNWattr_rw testattribute
$ cat testattribute
xattr test string
$ exit
Kommen wir zu der Unterstützung für Extended Attributes in den Standard-Unix-Tools.
-
mv erhält immer alle Attribute. Wenn mv eine Datei auf ein anderes Dateisystem verschieben will, und dort die Extended Attributes nicht repliziert werden können, wird die Operation abgebrochen und die Quelldatei wird nicht gelöscht.
-
ls zeigt mit der -@ Option ein @-Zeichen nach den Zugriffsrechten an, wenn eine Datei Extended Attributes besitzt.
-
cp und tar ignorieren standardmäßig Extended Attributes, auch hier hilft die -@ Option.
Dateisysteme werden nicht nur ZFS und UFS unterstützt, sondern auch NFS. Und betreibt man einen Solaris smb-Server werden die Extended Attributes dort auch über smb als NTFS Alternate Data Stream zur Verfügung gestellt.
Siehe auch: fsattr(5)