UNIXwork

Über die Datei $HOME/.dav/config.xml kann dav konfiguriert werden. Auf diese Weise können Server-Verbindungsinformationen, Proxy-Einstellungen und die AES-Verschlüsselung konfiguriert werden, wobei letzteres Thema eines anderen Artikels ist.

Die config.xml Datei wird sowohl von dav als auch dav-sync verwendet, es funktioniert jedoch nur dav auch komplett ohne Konfigurationsdatei. Es sind dann jedoch nicht alle Funktionen nutzbar.

Repository

Das Wichtigste, was konfiguriert werden kann, sind Repositories. Ein Repository ist ein WebDAV-Verzeichnis, dem man einen eindeutigen und vorzugsweise kurzen Namen gibt. Über diesen Namen kann man dann darauf einfach zugreifen, wobei dann alle Repository-Einstellungen verwendet werden.

Die minimalen Einstellungen, die ein Repository benötigt, sind der Name und die URL. Am einfachsten legt man die Konfiguration mit dem Befehl dav add-repository an. Dies startet einen kleinen Assistenten, der das Nötige abfragt. Es können dabei optional auch der Benutzername und das Passwort für die Authentifizierung angegeben werden.

$ 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): 

Die config.xml Datei sieht dann so aus:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<repository>
		<name>myfirstrepo</name>
		<url>https://mynas.local/webdav</url>
		<user>mywebuser</user>
		<password>MTIzNDU2Nzg=</password>
	</repository>
</configuration>

Wenn kein Benutzer für das Repository konfiguriert ist, fragt dav den Benutzer und das Passwort beim Zugriff ab. Wenn ein Benutzer angegeben ist, jedoch kein Passwort, dann wird nur nach dem Passwort gefragt. Das Passwort muss base64-kodiert in der Datei gespeichert sein.

Desweiteren können für ein Repository noch die HTTP-Authentifizierungsmethoden und TLS konfiguriert werden.

Für die Authentifizierungsmethoden gibt es das Element <authmethods>, welches innerhalb des <repository>-Elements angegeben werden kann. Standardmäßig verwendet dav nur HTTP Basic Authentication. Es können jedoch auch weitere von libcurl unterstützte Authentifizierungsmethoden verwendet werden. Man gibt bei dem <authmethods>-Element einfach eine mit Space getrennte Liste der Methoden an. Mögliche Werte sind: basic, digest, negotiate, ntlm, any, none

Eine Beispielkonfiguration wäre dann:

<repository>
	...
	<authmethods>basic digest ntlm</authmethods>
</repository>

Für die TLS-Konfiguration gibt es Elemente um Zertifikate einzubinden, bestimmte TLS-Versionen zu forcieren und die Verifikation von Zertifikaten zu deaktivieren.

Zertifikate angeben kann man mit dem <cert>-Element. Als Wert gibt man einen Pfad zu einer *.pem Datei an. Die dort enthaltenden Zertifikate werden dann verwendet, um die TLS-Verbindung zum Server des Repositories zu verifizieren.

Beispiel:

<repository>
	...
	<cert>/etc/certs/cabundle.pem</cert>
</repository>

Die TLS-Version kann mit dem Element <ssl-version> ausgewählt werden. Mögliche Werte sind: TLSv1, TLSv1.0, TLSv1.1, TLSv1.2, SSLv2, SSLv3. Per default verwendet dav die TLS-Version, die auch standardmäßig von libcurl verwendet wird. Je nachdem, wie aktuell libcurl ist, ist SSLv2 und SSLv3 deaktiviert und müsste daher mit dem Element erst aktiviert werden, falls es benötigt wird.

Beispiel:

<repository>
	...
	<ssl-version>TLSv1.2</ssl-version>
</repository>	

Die Verifizierung von TLS-Zertifikaten kann mit dem <verification>-Element deaktiviert werden. Bei dav gibt es dafür auch die -i Option. Es versteht sich von selbst, dass dies keine empfohlene Einstellung ist.

Beispiel:

<repository>
	...
	<verification>false</verification>
</repository>

Proxy

Wer dav durch einen Proxy verwenden will, kann dafür entweder die HTTP_PROXY bzw HTTPS_PROXY Umgebungsvariable verwenden, oder den Proxy in der config.xml Datei konfigurieren. Innerhalb des XML-Root-Elements fügt man dafür ein <http-proxy> oder <https-proxy> Element ein.

Ein Proxy benötigt mindestens eine URL. Diese gibt man mit dem <url>-Element an.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<http-proxy>
		<url>http://proxyserver/</url>
	</http-proxy>
	
	...
</configuration>

Benötigt der Proxy Authentifizierungsinformationen, müssen diese mit den <user> und <password> Elementen angegeben werden. Das Passwort muss auch hier base64-kodiert sein.

<http-proxy>
	<url>http://proxyserver/</url>
	<user>myproxyuser</user>
	<password>MTIzNDU2Nzg=</password>
</http-proxy>

Des weiteren können auch Hosts angegeben werden, für die kein Proxy verwendet werden soll. Hierfür verwendet man das <no> Element.

<http-proxy>
	<url>http://proxyserver/</url>
	<user>myproxyuser</user>
	<password>MTIzNDU2Nzg=</password>
	<no>host1, host2, host3</no>
</http-proxy>

WebDAV-Properties sind Metadaten, die jede Resource haben kann. Da WebDAV XML-basiert ist, hat der Name einer Property immer einen XML-Namespace, und der Inhalt kann beliebige XML-Daten enthalten. Man unterscheidet zwischen Live-Properties, die vom Server berechnet werden oder eine vorgeschriebene Syntax haben, und Dead-Properties, die beliebige Daten enthalten können. Beispiele für Live-Properties sind der Etag (getetag) oder das Änderungsdatum (getlastmodified).

Nicht alle Server unterstützen das Speichern von Dead-Properties. Mit Apache funktioniert es jedoch problemlos. Auch OwnCloud bzw NextCloud unterstützen es und lighttpd auch, falls das entsprechende Feature mitkompiliert wurde.

Für den Zugriff auf Properties hat dav mehrere Befehle. Mit dav info können alle Properties einer Resource aufgelistet werden.

$ dav info myserver/file.txt
name: file.txt
path: /file.txt
url:  https://myserver/file.txt
type: resource
size: 72 KiB

namespace: DAV:
  creationdate: 2015-10-11T16:22:09Z
  getcontentlength: 73921
  getcontenttype: text/plain
  getetag: "120c1-521d69d4d6397"
  getlastmodified: Sun, 11 Oct 2015 16:22:09 GMT
  supportedlock: 

namespace: http://apache.org/dav/props/
  executable: F

namespace: http://example.com/ns
  myprop: Hello World

Für den Zugriff auf einzelne Properties gibt es die Befehle get-property, um den Inhalt einer Property anzuzeigen, und set-property, um den Inhalt zu ändern.

set-property verlangt als Argumente eine URL, den Property-Namen. Als drittes Argument kann auch der Wert angegeben werden, der dieser Property zugewiesen werden soll. Wird jedoch keiner angegeben, liest dav diesen von stdin. Desweiteren sollte auch mit der -n Option ein Namespace-URI angegeben werden, falls nicht der Default-Namespace DAV: verwendet werden soll.

Das folgende Beispiel setzt für eine Resource die Property myprop im Namespace http://example.com/ns mit dem Value Hello World.

$ dav set-property -n http://example.com/ns myserver/file.txt myprop "Hello World!"

Den Inhalt anzeigen kann man dann mit get-property. Die Argumente sind genau wie bei set-property, nur dass kein Value angegeben wird.

$ dav get-property -n http://example.com/ns myserver/file.txt myprop
Hello World

Aktuell hat dav noch die Limitierung, dass keine XML-Values bei Properties unterstützt werden. Sollte also eine Property nicht nur einfachen Text, sondern XML-Daten enthalten, wird der Inhalt nicht angezeigt.

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.

2013 stellte Apple den kontrovers diskutierten neuen Mac Pro vor. Statt einer klassischen Workstation war dieser deutlich kleiner, hatte nur einen CPU-Sockel, keine wechselbaren Grafikkarten und keine Slots für herkömmliches Storage. Für Erweiterungen waren nur mehrere Thunderbolt-Ports vorgesehen. Dieses radikal neue Konzept löste bei einigen wenigen vielleicht Begeisterung aus, die Mehrheit war dem eher abgeneigt. Nicht nur war die CPU- und GPU-Power stark begrenzt, wer PCIe- oder Storage-Erweiterungen braucht, muss dies extern realisieren, was nicht nur deutlich teurer ist, sondern auch mehr Platz verbraucht und umständliche und hässliche Verkabelungen zur Folge hat.

Zusätzlich dazu hielt es Apple auch nicht für nötig, den Mac Pro zu updaten, obwohl Intel fleißig neue CPU-Generationen gebracht hat. Damit ist der Mac Pro mitlerweile völlig zum Witz geworden. Überteuert war er schon 2013 (im Vergleich mit anderen Workstations versteht sich), im Jahr 2017 hingegen ist es nur noch lächerlich, wenn man den alten Preis noch für veraltete Hardware zahlen muss.

Das hat nun auch Apple eingesehen. Zum einen haben sie geringfügig die Preise für das aktuelle Modell angepasst (natürlich immer noch lächerlich überteuert), zum anderen angekündigt, dass sie den Mac Pro komplett überdenken. Sie geben zu, dass das aktuelle Modell für viele Pro-User ungeeignet ist. In Zukunft soll der Mac Pro wieder ein modulares Design haben, so dass es auch für Apple deutlich einfacher ist, Upgrades zu liefern.

Interessant ist auch, dass laut Apple das Kühlungssystem, was das eigentlich Innovative am aktuellen Mac Pro sein sollte, nicht ordentlich funktioniert. Damit ist eigentlich auch der letzte Vorteil, den Fans der Apfel-Tonne immer betont haben, widerlegt.

Jetzt muss man natürlich warten, was Apple letztendlich entwickelt. Es besteht natürlich immer die Möglichkeit, dass sie eine noch schlechtere Idee haben.