Mobile Informationen - WebDAV

Hintergrund

Bei den meisten Rechneranwendungen werden Informationen erzeugt, verarbeitet oder verändert. In der vom Rechenzentrum der TU Chemnitz betriebenen Infrastruktur ist es für die Nutzer schon seit langem selbstverständlich, an verschiedenen Arbeitsplätzen mit denselben (veränderlichen) Informationen arbeiten zu können (Home- und Projektverzeichnisse ... ).

Das Ziel dieser Infrastruktur ist ein Datenzugriff zu jeder Zeit und von jedem Ort aus, wobei hier nicht nur lesende Zugriffe sondern auch Schreiben, Umordnen usw. gemeint sind. Eine neue Schwierigkeit ist die Forderung nach einer Arbeitsmöglichkeit auch ohne ständige Netzverbindung. Das ist einmal für die "mobile" Arbeit erforderlich (drahtlose Netze sind noch sehr kostenaufwendig), aber auch zur Erhöhung der Verfügbarkeit beim "normalen" Endanwender.

Die heutige Praxis bedient sich bereits einiger Technologien, mit denen die obigen Forderungen zumindest partiell erfüllt werden:

Netzwerk-Filesysteme sind die traditionellen Mittel für den genannten Zweck. Bei den etablierten Technologien auf diesem Gebiet (NFS, SMB, AFS ...) gab es allerdings in den letzten Jahren kaum grundsätzliche Weiterentwicklungen, trotz vieler bekannter Probleme und Mängel. Ein Hoffnungsschimmer sind die Entwicklungen CODA und NFS 4.
Auch HTTP- bzw. FTP-Server kommen als arbeitsplatzunabhängiger Speicherort für Informationen in Frage, vor allem wenn die Information ohnehin primär zur Verbreitung per WWW vorgesehen ist. Um die Informationen auf einen WWW-Server zu bringen, bedient man sich heute des FTP-Protokolls oder eines Netzwerk-Filesystems. Seltener werden die HTTP-Operation PUT oder spezielle Werkzeuge wie mirror, rsync verwendet.
Eigentlich möchte man beim Ablegen von Informationen auch eine Hilfe bei der Verwaltung von Versionen und Konfigurationen, von Hand ist dies aufwendig und fehlerträchtig. An dieser Stelle haben Systeme wie CVS eine gewisse Verbreitung erfahren.

In diesem Beitrag soll ein neuer Ansatz zum Erreichen der eingangs genannten Ziele vorgestellt werden.

WWW Distributed Authoring and Versioning

Von einer IETF-Arbeitsgruppe wird die Idee verfolgt, das HTTP-Protokoll um einige Operationen zu erweitern, die eine Nutzung der WWW-Technologie als universeller Informationsspeicher ermöglichen soll. Ein erster Standardentwurf liegt vor:

RFC 2518: HTTP Extensions for Distributed Authoring Als Abkürzungen sind WebDAV oder kurz DAV gebräuchlich. Der Standardentwurf führt eine Reihe neuer Konzepte ein:

Bearbeiter können Dokumente "blockieren", um Kollisionen bei der Bearbeitung zu verhindern (Locking). Dabei sieht man "persistente Locks" vor, die keine ständige Netzverbindung erfordern.
Dokumenten können Eigenschaften (Properties) zugeordnet werden. Das sind beliebige Metadaten, die Syntax nutzt dabei XML.
Oft will man nicht nur einzelne Dokumente manipulieren, sondern ganze Verzeichnishierarchien bzw. Namensräume (Namespace management). Das dazugehörige Konzept sind die Collections. Sie enthalten nur relative URIs und bilden eine Hierarchie (die Parent-Collection ist "/"). Weiterhin haben sie Eigenschaften (Locks, Metadaten usw.).

Die meisten DAV-Operationen sind nur sinnvoll, wenn der Nutzer bekannt ist (d.h. mit Authentifizierung).
Eine Reihe von vorgesehenen Erweiterungen ist noch in Diskussion. Dazu gehören Advanced Collections, eine Versionsverwaltung (Versioning) und eine Zugriffssteuerung (Access Control).

Gegenüber der heute verbreiteten Nutzung von FTP zum "Füllen" von Web-Servern erwartet man von DAV einige Vorteile. So kann HTTP mit SSL/TLS, Proxies und Caching betrieben werden. Nicht so deutlich sind die Vorteile gegenüber ssh/scp. In Zukunft könnte vielleicht auch CVS eine Konkurrenz bekommen. Eine weitere Perspektive ist der Mail-Zugriff per HTTP, die heute noch vorhandenen Einschränkungen gegenüber POP/IMAP können so überwunden werden.

Im folgenden Bild sind die DAV-Operationen aufgeführt:

Die schrittweise Einführung wird dadurch begünstigt, daß "alte" Klienten natürlich die bisherigen HTTP-Möglichkeiten nutzen können.
Einen ersten Eindruck des (leider) recht komplexen Protokolls erhält man durch die Beispiele aus RFC 2518 (http://www.tu-chemnitz.de/~huebner/webdfs/bsp.htm ).

Implementierungen

Auf der Klientenseite sei hier das Programm sitecopy genannt, das eine autorenseitige Aktualisierung von Web-Servern realisiert. Es nutzt dazu wahlweise FTP oder eben WebDAV:

http://www.lyra.org/sitecopy/

Als weitere Klienten werden MSIE 5 und MS Office 2000 genannt.

Auf der Serverseite gibt es ebenfalls schon eine Reihe von Implementierungen:

Modul mod_dav für Apache:
Dieses Modul erweitert Apache zu einem "Class 1 DAV Server", d.h. die Manipulation von Ressourcen (Files) und Properties ist realisiert. Es fehlen (noch) die LOCK/UNLOCK- und die SEARCH-Operationen. Letztere gehören zur Entwicklung DAV Searching and Locating (DASL), die hier nicht näher betrachtet werden soll:
Zope ist eine "Web Application Platform", implementiert in Python und C. Zope ist als Apache-CGI (ZAP) benutzbar, einen WebDAV-Testserver findet man unter
IIS 5 im MS Windows 2000 Server
PyDAV

Um erste Erfahrungen mit DAV sammeln zu können, wurde ein Apache-Server mit mod_dav ergänzt. In der Konfigurierung des WWW-Servers ist ein neuer Abschnitt für DAV anzugeben, hier das zum Test benutzte Beispiel:

<Location /davtest>
  DAV On
  AllowOverride None
  Options None
  <Limit PUT DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
    AuthType Basic
    AuthName davtest
    AuthUserFile /apache/conf/AuthUserFile
    Require user uh
  </Limit>
</Location>

Nun kann man mit telnet als Klient neue Operationen erproben (Eingaben sind fett gedruckt):

PROPFIND /davtest HTTP/1.1
Host: localhost.hrz.tu-chemnitz.de

HTTP/1.1 207 Multi-Status
Date: Mon, 12 Apr 1999 12:58:24 GMT
Server: Apache/1.3.6 (Unix) DAV/0.9.8
Transfer-Encoding: chunked
Content-Type: text/xml; charset="utf-8"

2d8
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/davtest/dtest.html</D:href>
<D:propstat>
<D:prop>
<D:creationdate>1999-04-12T12:36:32Z</D:creationdate>
<D:getcontentlength>364</D:getcontentlength>
<D:getlastmodified>Mon, 12 Apr 1999 12:36:32 GMT</D:getlastmodified>
<D:resourcetype/></D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/davtest/</D:href>                        
<D:propstat>
<D:prop>
<D:creationdate>1999-04-12T12:36:32Z</D:creationdate>
<D:getlastmodified>Mon, 12 Apr 1999 12:36:32 GMT</D:getlastmodified>
<D:resourcetype><D:collection/></D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>

Komplexere Operationen sind so nur sehr umständlich möglich, daher wenden wir uns nun dem oben schon erwähnten Klienten sitecopy zu. Zunächst müssen wir auf der Klientenseite eine Konfigurierungsdatei anlegen, die wir testrc nennen:

site mysite
  server myk.hrz.tu-chemnitz.de
  port 8080
  protocol http
  username uh
  password cPOwu23c
  local /home/uh/sctest/
  remote /davtest/sctest/

Die Angabe von Klartext-Paßwörtern ist nicht so ganz ideal. Nun können wir das Programm mit den Optionen Update, HTTP-Protokollanzeige und der Konfigurierungsdatei testrc aufrufen:

 % sitecopy -u -d 8 -r testrc mysite

Im lokalen Verzeichnis sctest hatten wir die Datei f2.htm abgelegt, damit ergeben sich folgende HTTP-Operationen:

  PUT /davtest/sctest/f2.htm HTTP/1.1
  Host: myk.hrz.tu-chemnitz.de:8080
  User-Agent: sitecopy/0.5.1
  Authorization: Basic dWg6ZGF2    
  Content-Length: 323
  Date: Mon, 12 Apr 1999 14:09:24 GMT
  Expect: 100-continue
  
  HTTP/1.1 100 Continue
  .. sending body now..
  
  HTTP/1.1 201 Created

beim Klienten benennen wir f2.htm in file2.htm und rufen sitecopy erneut auf. Dabei werden diese HTTP-Operationen ausgeführt (die Erwiderungen sind hier nicht dargestellt):

  DELETE /davtest/sctest/f2.htm HTTP/1.1
  PUT /davtest/sctest/file2.htm HTTP/1.1

Es ist nicht ganz klar, warum hier nicht das schnellere MOVE genutzt wurde.
Nun legen wir ein neues Verzeichnis mit einer neuen Datei newdir/f3.htm an:

  MKCOL /davtest/sctest/newdir/ HTTP/1.1
  PUT /davtest/sctest/newdir/f3.htm HTTP/1.1

Sitecopy prüft nicht die Existenz von Dokumenten auf dem Server, sondern konsultiert nur eine lokale Zustandsdatei (~/.sitecopy/mysite ), die Pfadnamen, Änderungsdatum und Länge enthält. Hier ein Beispieleintrag daraus:

  /newdir/f3.htm  923926653       6

Bisher hat keiner unserer Testklienten die komplexen semantischen Möglichkeiten genutzt, die bei DAV durch Kommandospezifikationen in XML zugänglich werden. Dies ist aber interessant, weil nur so herauszufinden ist, ob der DAV-Server solche XML-Vorgaben korrekt analysieren und ausführen kann. Mit Hilfe eines speziellen Testklienten davtest.tcl wollen wir nun Eigenschaften (Properties) definieren, im Beispiel einen status=FINAL und eine PGP-Signatur:

PROPPATCH /davtest/dtest.html HTTP/1.1
...
<?xml version="1.0" encoding="utf-8" ?>
   <D:propertyupdate xmlns:D="DAV:">
     <D:set>
          <D:prop>
             <status>FINAL</status>
             <signature>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBNxSCO9kyac0/Z4OpAQGsNgP+Ix2EtIv16EbyDbmO2vHG1VHXcEqH7wra ...
-----END PGP SIGNATURE-----
          </signature>                                            
          </D:prop>
     </D:set>
   </D:propertyupdate>

HTTP/1.1 207 Multi-Status
Date: Wed, 14 Apr 1999 10:44:43 GMT
Server: Apache/1.3.6 (Unix) DAV/0.9.8
Transfer-Encoding: chunked
Content-Type: text/xml; charset="utf-8"

13a
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:ns1="http://www.w3.com/standards/z39.50/" xmlns:ns0="DAV:">
<D:response>
<D:href>/davtest/dtest.html</D:href>
<D:propstat>
<D:prop>
...
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>                               
</D:response>
</D:multistatus>

Nun können wir nachsehen, wie der Server diese Properties seinerseits realisiert. Man findet eine sdbm-Datenbasis pro Dokument (ähnlich dbm, gdmb). Von deren Inhalt können wir uns einen Eindruck verschaffen:

% strings .DAV/dtest.html.pag

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBNxSCO9kyac0/Z4OpAQGsNgP+Ix2EtIv16EbyDbmO2vHG1VHXcEqH7wra ...
-----END PGP SIGNATURE-----

:signature
FINAL
:status
DAV:
http://www.w3.com/standards/z39.50/
...

Informationen

Mehr zu DAV findet man u.a. hier:

http://www.ics.uci.edu/pub/ietf/webdav/

DAV Frequently Asked Questions
http://www.webdav.org/other/faq.html

Ein weiterer Ansatz für "mobile Informationen" ist eine "intelligente Spiegelung". Er unterscheidet sich in der Zielstellung etwas von der WebDAV-Richtung. Ein Nutzer möchte an unterschiedlichen Orten mit denselben Datenbeständen arbeiten (z.B. PC am Arbeitsplatz und Laptop unterwegs). Die Datenbestände sind dabei mehrfach vorhanden (repliziert). Änderungen an einem beliebigen Replikat sollen bei "nächster Gelegenheit" (d.h. wenn das betreffende Replikat wieder am Netz zugänglich ist) überall konsistent ausgeführt werden. Eine ausführlichere Beschreibung dieses Konzepts und des dazugehörigen Werkzeugs finden Sie hier:

http://www.tu-chemnitz.de/~huebner/imir/