Wir betreiben immer mehr unserer Webservices mit docker. Bis anhin haben wir für Kunden die Filezugriff brauchen apache webdav eingesetzt. Webdav Shares können von macOS und Windows einfach mit Finder oder Explorer gemounted werden.

Serverseitig kann Webdav Hosting problematisch sein, insbesondere wenn der Webserver auch andere Dinge macht.

Durch .htaccess files, rewrite rules oder anderen Konfigurationen im Webserver oder z.b. einem vorgeschalteten nginx proxy, kann es zu Komplikationen kommen.

Das Problem ist das man zwei völlig gegensätzliche Dinge von dem gleichem Server will. Bei einen php file, soll einerseits das file von mod_php prozessiert werden, andererseits soll im webdav Fall nichts prozessiert werden.

Dotfiles wie „.htaccess“ sollen wiederum im normalen Fall nicht vom User einsehbar sein, via webdav aber schon. Nginx als vorgeschalteter Proxy kann einem auch dazwischenfunken da dort z.B. auch eine Rule existieren kann die access denied für Dotfiles zurückliefert.

Dies führt dann zu mehr und komplizierter apache/nginx config um alle Fälle richtig zu handhaben.

ftps, sftp

Ursprünglich war es die Idee ftps einzusetzen. Die Hauptanforderung ist das wir ein sicheres file sharing für Kunden zur Verfügung stellen können, welches Serverseitig und Kundenseitig möglichst unkompliziert verwendet werden kann. Idealerweise wird dieses direkt vom Betriebssystem unterstützt (macOS oder Windows).

Als erstes ist mir da ftps in den Sinn gekommen. Das Protokoll ist nur für Filedatentranfer zuständig und muss nicht noch zusätzlich normalen Webtraffic abarbeiten. Es braucht zudem keine shell user wie sftp.

ABER leider musst ich mit erschrecken feststellen das macOS High Sierra KEIN ftp command line client mehr besitzt. Im Finder kann man zudem nur ftp (nicht ftps) readonly mounten.

Ok, also doch webdav

Nach dem ftps Intermezzo wieder zurück zu webdav. Mir ist leider kein anderes Filetransfer Protokoll bekannt, für macOS und Windows, das ohne zusätzliche Tools funktioniert. Sftp kann in macOS nur in der shell benutzt werden. Unter Windows ist das unix sftp nicht ohne zusätzliche Tools verfügbar.

Der webdav Server im docker container sollte nur für webdav zuständig sein und nicht für das ausliefern normaler Webseiten.

Es müsste auch nicht unbedingt der apache server sein, ein etwas schlankerer Server mit weniger Speicherverbrauch würde reichen.

lighttpd

Für lighttpd gibt es ein webdav Modul. Im Gegensatz zum standard nginx Modul ist dieses auch für vollen read/write Zugriff gedacht.

Mit macOS High Sierra arbeitet das lighttpd webdav Modul nicht gut zusammen. Es kommt zu dem Fehler chunked data Error. Lighttpd unterstützt leider keine http 1.1 „chunked transfer encoding“. Dateien werden erzeugt auf dem Server, aber diese haben immer eine länge von 0.

nginx

Nächster Versuch nginx. Das standard Modul für nginx reicht für read/write nicht aus, man braucht noch zusätzlich noch das Modul nginx-dav-ext-module . Es gibt nur wenig Docu zu dem Modul. Nach einem Test geht dies auch nicht mit macOS. Das nginx webdav Module unstützt keine Locks siehe issue 8 in Github.

wsgidav

Als nächstes teste ich kurz wsgidav dies ist ein reiner python webdav server. Die Konfiguration erlaubt sehr viele Möglichkeiten, fast zuviele. Es funktioniert tadellos aber bei grösseren Dateien scheint es mir langsam.

Apache webdav

Back to the roots, Apache webdav ist und bleibt der Goldstandard für webdav. Wahrscheinlich testen alle OS Hersteller hauptsächlich ihre Webdav Clients mit Apache webdav.

docker image

Unter alpine-apache2-webdav habe ich eine minimales docker image erstellt (17 MB), welches alpine linux verwendet. Es beinhaltet nur das nötigste damit apache mit webdav funktioniert. Es ist für mehrer Shares konzipiert und kann/solllte mit SSL betrieben werden. Es sollte möglichst ohne zwischengeschalteten proxy verwendet werden um Probleme zu vermeiden. Mehr Infos auch hier https://github.com/taywa/docker-alpine-apache2-webdav.

Finally, schlankes file sharing mit docker for macOS & Windows! Ohne gedöns!

Wieder mit apache webdav, don’t change a running system. Hätte nicht gedacht das dies immer noch die beste Lösung ist!