Stand: 30.01.2004

WebDAV mit Mac OS X

Inhalt

Einleitung

Dies ist eine Anleitung für die Aktivierung und Konfiguration eines WebDAV-Servers unter Verwendung des WebDAV-Moduls, das bei der Auslieferung des Apache-Servers von Mac OS X enthalten ist. Von der Länge des Dokuments sollte man sich nicht erschrecken lassen, denn das Eigentliche, was zu tun ist, ist wirklich sehr wenig. Der Text enthält lediglich einige ergänzende Informationen. Wen diese aber nicht interessieren, der findet am Ende des Dokuments einen kurzgefaßten Abschnitt, der sich auf's Wesentliche konzentriert.

Sollten trotz sorgfältiger Prüfung Fehler oder Lücken vorhanden sein, bitte ich darum, mir diese mitzuteilen. Um Weiterverbreitung des Dokuments wird ebenfalls gebeten.

Details zum Thema WebDAV an sich findet man hier, auf der WebDAV-Homepage.

Genug der Vorworte, zur Tat geschritten.

Moment, eines dennoch vorweg: Im großen und ganzen ist die Aktivierung des WebDAV-Servers kein Hexenwerk und auch nicht sonderlich viel Aufwand. Es kann aber auch bei den kleinen Dingen des Lebens immer etwas schief gehen und, noch wichtiger, nichts auf dieser Welt ist trivial. Soll heißen: Mir sollte bitte keiner an den Karren fahren, wenn aufgrund der Durchführung bestimmter Tätigkeiten am eigenen System unter Berufung auf dieses Dokument Einstellungen derart verballert werden, daß nichts mehr so ist wie vorher und vielleicht sogar auch nichts (mehr) richtig funktioniert. Diese Anleitung soll eine Hilfestellung sein. Eine gewisse Grundkenntnis im Umgang mit dem Dienstprogramm Terminal sind mindestens wünschenswert.

Erreichbar für jegliches Feedback bin ich unter der E-Mail-Adresse maki(at)powermaki(dot)de (entschuldigt bitte diese unbequeme Schreibweise und das Entfernen des Links, aber die Erfahrungen mit Spam-Mails haben mich gelehrt, daß das besser so ist - irgendwann werde ich vielleicht ein Formular zum E-Mail-Versand einrichten).

So, jetzt geht's aber wirklich los:

Schritt 1: Aktivieren des WebDAV-Moduls

Um das WebDAV-Modul des Apachen zu aktivieren ist ein kleiner Eingriff in die Konfigurationsdatei notwendig. Diese Datei befindet sich in dem Verzeichnis /etc/httpd/ und heißt httpd.conf. Mittels eines geeigneten Editors (ich bevorzuge "pico", kann aber nicht wirklich begründen, wieso) werden lediglich zwei Zeilen darin "entkommentiert", d.h. am Anfang der Zeilen das "#"-Zeichen entfernt. Die Zeilen lauten

Die Konfigurationsdatei kann nur mit root-Berechtigung bearbeitet werden. Deswegen ist der Zusatz "sudo" beim Aufrufen des Editors notwendig, der einen dazu auffordert, die folgende Aktion durch die Eingabe des Administratorpassworts (also nicht das des root-Benutzers) zu legitimieren, damit sie mit root-Rechten ausgeführt werden kann. "Sudo" steht für Super-User-Do. Es ist stets äußerste Vorsicht bei diesem Befehl geboten, da man damit einfach alles kaputt machen kann. Und mit einfach alles ist wirklich alles gemeint.

Die Zeile im Terminal zum Aufrufen des Editors sieht also so aus:

Mit Ctrl+W kann man im pico auch einen Suchbegriff eingeben. Wir suchen also mit diesem Tastaturbefehl den Begriff "dav", der in zwei Zeilen vorkommt und entkommentieren diese beiden Zeilen.

Das gleiche, also Suchen und Zeilen Entkommentieren, machen wir mit dem Begriff "digest", der ebenfalls in zwei Zeilen auftaucht.

Damit sind alle Änderungen in dieser Datei vorgenommen, die wir für unsere Aufgabe benötigen. Sichern wir also alles mit dem Tastaturbefehl Ctrl+O (für Output) und verlassen den Editor mit dem Tastaturbefehl Ctrl+X (für Exit).

Schritt 2: Anlegen eines WebDAV-Ordners

Ein WebDAV-Ordner ist ein Ordner, der die Dateien enthält, die mittels des WebDAV-Protokolls über das Internet zur Verfügung gestellt werden sollen, also gewissermaßen das eigentliche corpus delicti, der tatsächliche Inhalt des WebDAV-Ordners. Der Begriff DAV bezeichnet im übrigen exakt das gleiche wie WebDAV, und da er kürzer ist, verwende ich ihn ab hier nur noch. DAV-Ordner kann es theoretisch beliebig viele auf einem Webserver geben. Wir legen aber nur einen an, für alle weiteren läuft es nach dem gleichen Schema ab.

Ein DAV-Ordner ist am einfachsten direkt in der sogenannten "Document-Root" unterzubringen, also dem Ordner, der den Inhalt sämtlicher Webserver-Dokumente enthält, etwa HTML-, PHP- und andere Dateien sowie die gesamte Ordnerstruktur, die alle die eigentliche Web-Site des Webservers ausmachen. Diese Document-Root ist standardmäßig bei OS X auf das Verzeichnis /Library/WebServer/Documents/ eingestellt. Erstellen wir in diesem Verzeichnis also einen Ordner, den wir einfach "dav" nennen wollen. Diese Aktion können wir natürlich auch im Finder durchführen.

Wenn der Ordner existiert, versehen wir ihn noch mit den passenden Rechten, die abhängig davon sind, was wir den Benutzern hier anbieten wollen: Reine Download-DAVs brauchen lediglich Read-Rechte, solche, bei denen die Benutzer auch etwas verändern oder hochladen können sollen, benötigen zusätzlich auch die Write-Berechtigung.

Empfehlenswert ist hier, daß der eigentliche DAV-Ordner reine Leseberechtigungen aufweist, bestimmte Unterordner aber auch Änderungs- bzw. Schreibberechtigungen bieten. So wäre eine eigens dafür vorgesehener Upload-Ordner denkbar, in den die Benutzer neue Dokumente einstellen dürfen. Oder aber ein Ordner pro Benutzer, um eine gewisse Einteilung zu erreichen. Hier sind dem Machbaren nur Grenzen durch die eigene Phantasie und Unix-Kenntnis gesetzt. Die Struktur des DAV-Ordners selbst bestimmen durch diese Vorgehensweise wir - so, wie es sein soll.

Unix unterscheidet bei der Rechtevergabe drei verschiedene Parteien von Benutzern. Es gibt einerseits Besitzer von Dateien und Ordnern, andererseits Benutzer, die einer bestimmten Gruppe zugeordnet sind, und dann noch den Rest, der einfach "World" genannt wird. Besitzer sind meist die Benutzer, die ein Objekt angelegt haben. Das Objekt erhält automatisch auch die Gruppe, die dem Besitzer zugeordnet ist. Beides läßt sich aber ändern, ab OS X 10.2 sogar direkt im Informationsfenster des Finder, ganz ohne Terminal. Und genau davon machen wir nun Gebrauch. Vorher müssen wir noch wissen, daß sämtliche Requests des Apache-Webservers, also alle Zugriffe aus dem Internet unter dem Benutzer www laufen, der der Gruppe www angehört.

Um im DAV-Ordner im Finder weiterhin alles machen zu können, wonach uns der Sinn steht, also etwa weitere Ordner oder Dokumente anlegen, vorhandene ändern, löschen oder verschieben, sollten wir der Besitzer des Ordners sein. Mitglieder der Gruppe www sollen andere Rechte erhalten, damit wir den Zugriff aus dem Internet auf diesen Ordner entsprechend einschränken können.

Den korrekten Besitzer hat der Ordner ja schon, da wir ihn selbst über den Finder angelegt haben. Fehlt also nur noch die richtige Zuordnung zur Gruppe www. Das geht im Terminal so:

Im Finder ab OS X der Version 10.2 kann man auch, wie gesagt, den DAV-Ordner markieren und Befehl+I drücken, um das Informationsfenster zu öffnen. Dort die Abteilung "Eigentümer & Zugriffsrechte" aufklappen und, falls zugeschlossen, auf das Schloss klicken, um Änderungen vornehmen zu dürfen. Dann bei "Gruppe" den Eintrag "www" auswählen.

Verpassen wir dem Ordner nun noch die nötigen Rechte. Ich habe ja als empfohlenes Beispiel genannt, den eigentlichen DAV-Ordner nur mit Lesezugriffen auszustatten und einen speziellen Upload-Ordner darin anzulegen. Nehmen wir an, dieser Ordner soll sprechenderweise "upload" heißen. Im Finder legen wir also im DAV-Ordner einen neuen Ordner namens "upload" an, ordnen ihm ebenfalls die Gruppe www zu

und vergeben dann die Rechte auf folgende Weise:

"u" steht in diesem Fall für User, womit der Eigentümer des betroffenen Objekts gemeint ist, "g" steht für Group und "o" für Others. Mit dem ersten chmod-Befehl vergeben wir dem Eigentümer (also uns) die uneingeschränkte Handlungsmacht, nämlich lesen (read), schreiben (write) und öffnen (execute, was eigentlich "ausführen" heißt, bei Verzeichnissen "öffnen" aber mehr Sinn macht). Die Mitglieder der Gruppe, hier also www, dürfen den Ordner lediglich öffnen und darin lesen, aber keine Dateien ändern und keine neuen Dateien hineinschreiben. Mit dem zweiten chmod-Befehl vergeben wir wieder uns, aber diesmal auch den Mitgliedern der Gruppe www alle Rechte. Demnach darf auch der Benutzer www, der ja dieser Gruppe angehört, im Ordner "upload" z.B. neue Dateien anlegen. Somit dürfen das schlußendlich auch die Requests des Webservers, die eben unter dem Benutzer www laufen.

In beiden Fällen darf der Rest der Welt mit diesen Ordnern gar nichts machen, nicht einmal öffnen.

Schritt 3: Definieren von zulässigen Benutzern

Eine wichtige Maßnahme für die Sicherheit unseres DAV-Servers ist es, nur bestimmten Benutzern den Zugriff darauf zu gewähren. Leider haben die Benutzer, die OS X kennt, die man also in den Systemeinstellungen anlegen und verwalten kann, nichts mit den Benutzern zu tun, die sich im Internet über den Webserver anmelden können. Solche "Web-Benutzer" müssen eigens definiert werden, was leider nur im Terminal geht. Es hat Vor- und Nachteile, daß man andere Benutzer für den Web-Gebrauch anlegen kann, die kein Pendant in den Systemeinstellungen haben. Ein Vorteil etwa ist, daß man unabhängig von Systembenutzern so etwas wie eine Online-Registrierungen anbieten kann und die Benutzerdaten in Datenbanken wie MySQL ablegt. Ein Nachteil ist, daß man nicht mit einem einzigen Klick einen Systembenutzer in den Systemeinstellungen als Web-Benutzer markieren kann und wir uns nicht die in diesem Schritt beschriebene "Arbeit" ersparen können, selbst wenn wir nur einen DAV-Zugang für Benutzer bereiten wollen, die wir auch als Systembenutzer angelegt haben. Vielleicht entwickelt Apple ja mal eine Möglichkeit, die Systembenutzer auch gleichzeitig als Web-Benutzer zu definieren...

Um Passwörter, die ein Web-Benutzer zur Anmeldung an unseren DAV-Server eingibt, möglichst nicht im Klartext zu übertragen, verwenden wir eine Variante der Authentifizierung, die sich Digest nennt. Dadurch werden Passwörter verschlüsselt übertragen. Leider geht dies, wie bereits erwähnt, nur über das Terminal.

Die Web-Benutzer selbst und die verschlüsselten Passwörter werden dabei in eine Datei geschrieben, auf die der Webserver Zugriff haben muß. Es ist alles andere als ratsam, eine solche Datei mit Benutzern und Passwörtern so abzulegen, daß man von außen, also vom Internet, darauf zugreifen kann. Es ist für frei erhältliche Tools ein Leichtes, die mittels der hier verwendeten einfachen Methode verschlüsselten Passwörter zu knacken. Daher sollte man eine solche Datei niemals unterhalb der Document-Root legen, sondern darüber. Entscheiden wir uns also taktischerweise für das Verzeichnis /Library/WebServer.

Der Befehl, mit dem wir diese Datei anlegen und verwalten können, lautet htdigest. Zusätzlich zum eigentlichen Benutzernamen und dazugehörigem Passwort braucht der Befehl noch einen so genannten Realm, einen Bereich. Realms werden vom Webserver definiert, zum Wie kommen wir später noch, beim Anpassen der Apache-Konfiguration. Es handelt sich schlicht um die Benamsung eines Bereiches, auf den Websurfer, also unsere Web-Benutzer, zugreifen können. Vereinfacht gesagt handelt es sich bei einem Realm um einen Ordner. Unser DAV-Ordner könnte also ein solcher Realm sein. Ein Realm besteht nur aus seinem Namen, er ist nichts "Handgreifliches". Also denken wir uns einen pfiffigen Namen für unseren DAV-Ordner aus: "DAV4Everyone".

Da die Datei, in der wir die Benutzer ablegen wollen, noch nicht existiert, müssen wir sie zunächst anlegen. Dies geschieht, indem wir bei dem htdigest-Befehl vor dem eigentlichen Dateinamen "-c" für create schreiben. Der Dateiname selbst spielt nicht wirklich eine Rolle. Ich empfehle aber, die Datei wie den Befehl, also "htdigest" zu nennen, damit beim bloßen Ansehen dieser Datei auch der Befehl zum Bearbeiten der darin enthaltenen Benutzer ins Gedächtnis gerufen wird. Ich konnte mir das anfangs jedenfalls mit dieser Eselsbrücke recht gut merken, und wenn man den Befehl dann ohne weitere Zusätze im Terminal eingibt, klärt einen die folgende Ausgabe brav darüber auf, wie man ihn richtig zu verwenden hat. Der Punkt vor dem Dateinamen gibt an, daß es sich um eine unsichtbare Datei handelt. Auch das ist empfehlenswert, aber nicht nötig. Mit dem obigen Befehl legen wir also die Benutzerdatei an und erzeugen einen Web-Benutzer namens "maki" im Bereich (=Realm) "DAV4Everyone". Danach muß ein Passwort zweimal eingegeben werden und der erste Web-Benutzer ist fertig definiert.

Nun können weitere folgen, immer nach dem folgenden Muster:

Noch einmal: Web-Benutzer haben NICHTS mit den Systembenutzern in den Systemeinstellungen zu tun.

Schritt 4: Anpassen der Apache-Konfiguration

Damit unser DAV-Server erwartungsgemäß funktioniert, müssen noch einige Einstellungen in der Apache-Konfigurationsdatei vorgenommen werden. Ich empfehle allerdings. solcherlei Einstellungen nicht direkt in der bereits in Schritt 1 editierten Hauptkonfigurationsdatei httpd.conf vorzunehmen, da es nicht selten vorkommt, daß Apple mit einem Systemupdate auch diese Datei überschreibt und alle eigenen Einstellungen darin somit auch (so geschehen zum Beispiel beim Update auf 10.2.4). Aus diesem Grund nehme ich alle meine Einstellungen für Apache, die vom Apple-Auslieferungs-Standard abweichen, in einer persönlichen Konfigurationsdatei vor, was Apple selbst wohl auch so vorgesehen hat, denn im Verzeichnis /etc/httpd/users/ gibt es für jeden Benutzer, der im System angelegt wurde, eine eigene Konfigurationsdatei, die alle am Ende der Hauptkonfigurationsdatei eingebunden werden. In meinem Fall ist also meine "persönliche Konfigurationsdatei" die maki.conf, da maki der Name meines verwendeten Systembenutzers ist.

Damit öffnen wir diese Datei im vom ersten Schritt bereits bekannten Editor pico. Das sudo davor benötigen wir, weil alle Apache-Konfigurationsdateien dem Benutzer root gehören und nur von diesem (oder mit dessen Rechten) geändert werden dürfen.

Darin sind folgende Zeilen einzufügen, am Besten gleich als erste Zeilen:

Mit der ersten <Directory>-Passage wird für alle Ordner der Document-Root einheitlich festgelegt, daß immer die gleiche Web-Benutzerdatei zu verwenden ist. Ich habe beispielsweise auf meiner Homepage mehrere voneinander unabhängige Bereiche, die passwortgeschützt sind. Jeder dieser Bereiche stellt einen Realm dar, wie im vorhergehenden Schritt beschrieben. Für alle Bereiche gilt die gleiche Web-Benutzerdatei. Damit ich nicht für jeden dieser Bereiche immer wieder die gleiche Zeile mit der Angabe über die zu verwendende Web-Benutzerdatei aufführen muß, habe ich in meiner Konfigurationsdatei diese Vorgehensweise gewählt. Eigentlich könnte diese erste <Directory>-Passage auch entfallen und stattdessen die Angabe AuthDigestFile in der zweiten <Directory>-Passage z.B. unter der AuthType-Zeile stehen.

Mit der Anweisung DAVLockDB definieren wir eine Ablage für den DAV-Server, wo er temporäre Daten ablegen kann, etwa, welcher Benutzer gerade mit welcher Datei arbeitet und welche Dokumente deswegen gerade für den Zugriff anderer Benutzer gesperrt sind. Das hier angegebene Verzeichnis "DAVLockDB" legen wir im nächsten und zugleich letzten Schritt an.

Die zweite <Directory>-Passage beinhaltet die eigentliche Definition des Realms, für den wir uns im vorherigen Schritt den Namen "DAV4Everyone" ausgedacht haben. Zunächst wird das DAV-Protokoll für den Ordner /Library/WebServer/Documents/dav aktiviert, dann verbieten wir, daß so genannte Zugriffsteuerungsdateien auf unserem DAV-Server irgendweche Zugriffsrechte verändern dürfen, denn schließlich haben wir einen Upload-Ordner, in den jeder alles hochladen darf, also im böswilligen Fall eben auch eine solche Zugriffssteuerungsdatei, die es dann nur noch ausschließlich dem Übeltäter erlaubt, auf diesen Ordner über das Internet zuzugreifen - auf die Möglichkeiten, die wir im Finder haben, hat das allerdings keinerlei Auswirkung. Trotzdem: Sicher ist sicher. Mit AuthName entsteht nun endlich der eigentliche Realm. Wie bereits gesagt besteht ein solcher Realm eigentlich nur aus seinem Namen. Und hier wird er vergeben. Somit ist der DAV-Ordner nun der Realm "DAV4Everyone". Da wir ja die sicherere Übertragung der Passwörter gewählt haben, geben wir noch als Authentifizierungsart Digest an.

Gesichert wird das Ganze, wie schon bei Schritt 1, mit den Tastenkombinationen Ctrl+O und Ctrl+X.

Schritt 5: Die DAV-Sperrtabelle

Wie im vorherigen Schritt bereits erwähnt, benötigt der DAV-Server die Möglichkeit, temporär Daten abzulegen, die vorwiegend dazu dienen zu erkennen, welche Dokumente derzeit durch einen Benutzer gesperrt sind und daher nicht von einem anderen Benutzer verändert oder gelöscht werden dürfen. Wo er diese Daten ablegen kann, haben wir ihm ja bereits in unserer Konfigurationsdatei bei der Definition unseres DAV-Realms mitgeteilt. Nun müssen wir auch dafür sorgen, daß der genannte Ordner auch physisch vorhanden ist. Legen wir also einen neuen Ordner namens "DAVLockDB" im Verzeichnis /Library/WebServer an. Dann feuern wir die üblichen Terminalbefehle darauf ab:

Dadurch können wir selbst, aber auch die Webserver-Requests, lesend und schreibend auf diesen Ordner zugreifen, alle anderen haben für diesen Ordner keinerlei Rechte.

Das Anzünden der Lunte...

Nun nur noch den Webserver starten, also in den Systemeinstellungen Web Sharing aktivieren bzw., falls es bereits aktiv war, erst noch einmal ausschalten und dann wieder einschalten, damit der Webserver die neuen Konfigurationen mitbekommt, die er immer nur beim Starten liest. Damit ist WebDAV aktiviert. Die meiste Arbeit dabei war das Lesen dieses Dokuments. ;-)

Ein kleiner Test

Ob DAV nun auch wirklich das tut, was es (oder man sich selbst davon) verspricht, kann mit dem Finder getestet werden. Einfach die Tastenkombination Befehl+K für "Mit Server verbinden..." im "Gehe zu"-Menü drücken und dort

eingeben, wobei <ip-adresse> die eigene vom Internet-Provider zugeteilte IP-Adresse ist, die man am einfachsten im Programm Internet-Verbindung sehen kann.

Es sollte dann die Abfrage nach Benutzer und Passwort erscheinen, wobei im Dialogtext der Bereich bzw. Realm auftauchen sollte, bei dem man sich gerade anmeldet, den wir ja als "DAV4Everyone" definiert haben.

Nach der korrekten Eingabe der Anmeldedaten müßte nun ein Netzwerk-Volume gemountet werden, das so heißt wie der DAV-Ordner, also "dav". Beim Öffnen sollte darin mindestens der Ordner "upload" erscheinen, in den wir auch Dateien aus einem anderen Finderfenster kopieren können. Das sollten probehalber erst einmal Kleinstdateien sein, damit der Upload nicht zu lange dauert. Einfachst-Textdateien mit einem einzigen Wort darin bieten sich hier an. Das Bewegen einer Datei auf das DAV-Volume direkt sollte dagegen mit einer Fehlermeldung quittiert werden.

Auch das Veröffentlichen von iCal-Kalendern ist mit diesen Einstellungen möglich. Da wir aber für den eigentlichen DAV-Ordner keine Schreibberechtigung vergeben haben, wäre bei der Eingabe der Webserver-URL während der Veröffentlichung durch iCal folgendes einzugeben:

Natürlich macht es aber wenig Sinn, in einen Upload-Ordner, in dem jeder der angemeldeten Web-Benutzer alles darf, einen Kalender zu veröffentlichen. Geschickter ist es da schon, einen extra Kalender-Ordner zu machen, in dem man die gewünschten iCal-Kalender sammelt. Dieser Ordner sollte dann so eingerichtet sein, daß nur der eigene Web-Benutzer darauf schreibend zugreifen kann, alle anderen lesend. Wie die Beschränkung des Zugriffs auf einzelne Web-Benutzer funktioniert, ist im nächsten Abschnitt beschrieben.

Wenn etwas bei diesen Tests nicht klappt, hilft es zumeist, noch einmal zu prüfen, ob alles exakt wie hier beschrieben durchgeführt wurde, wenn das der Fall ist und es trotzdem nicht klappt, das DAV-Volume auszuwerfen und den Webserver noch einmal neu zu starten.

Zugriffsbeschränkung auf bestimmte Web-Benutzer

Wenn man einen Ordner einrichtet, der nur für den eigenen Web-Benutzer Schreibberechtigung haben soll, für alle anderen aber höchstens Lesen zuläßt, wie etwa um eigene iCal-Kalender zu veröffentlichen oder remote Dokumente einstellen zu können, dann ist das glücklicherweise eine recht einfach einzustellende Angelegenheit.

Zunächst legt man den gewünschten Ordner im Finder an und verpaßt ihm, wie bereits gewohnt, die nötige Gruppe www sowie die korrekten Rechte. Nennen wir den Ordner beispielsweise "kalender", weil wir iCal-Kalender darin veröffentlichen wollen. Dann geben wir dies hier im Terminal ein:

Wir müssen auch den Mitgliedern der Gruppe www alle Rechte geben, da wir ja, wie bereits mehrfach erwähnt, vom Internet aus tatsächlich mit dem Benutzer www zugreifen, der der Gruppe www zugeordnet ist. Von den im Webserver gültigen Web-Benutzern weiß die durch chmod vergebene Zugriffsberechtigung überhaupt nichts, denn, nochmals zur Erinnerung: Web-Benutzer haben nichts mit den Systembenutzern zu tun.

Um die Beschränkung auf einen oder mehrere bestimmte Web-Benutzer vorzunehmen, müssen wir also die Einstellungen des Webservers bemühen. Dazu öffnen wir unsere persönliche Konfigurationsdatei des Webservers und fügen nach der Definition des DAV-Realms eine weitere <Directory>-Passage hinzu.

Damit haben wir eingestellt, daß für unseren neuen Kalender-Ordner nur der Web-Benutzer maki vom Internet aus schreibenden Zugriff hat. Alle anderen können lesend darauf zugreifen. Kurzgefaßte Erklärung: Zum Lesen des Inhalts eines Ordners über das Internet werden die HTTP-Zugriffsmethoden GET und PROPFIND verwendet. Alle Zugriffsmethoden für Änderungen, also das Schreiben in diesen Ordner, limitieren wir mit der <Limit>-Passage auf den Web-Benutzer maki.

Nun noch Sichern (Ctrl+O), den Editor verlassen (Ctrl+X) und den Webserver, sprich: das Web Sharing in den Systemeinstellungen neu starten, und schon können wir z.B. in iCal unsere Kalender auf dem eigenen DAV-Server veröffentlichen, ohne befürchten zu müssen, daß jemand anderer sie überschreibt oder gar löscht.

Mehr Informationen zu <Limit> und quasi dem Gegenteil dazu, <LimitExcept>, sind unter den hinterlegten Links zu finden.

Kurzanleitung

Dies ist ein Schnelldurchlauf zum Erreichen des Ziels, einen DAV-Server unter OS X einzurichten, der einen beschreibbaren Upload-Ordner und einen auf den eigenen Web-Benutzer eingeschränkt beschreibbaren Kalender-Ordner zum Veröffentlichen von iCal-Kalendern aufweist. Wer die obige Anleitung bereits durchgeführt hat, braucht diese direkte Form nicht durchzuführen. Hier geschieht alles im Terminal.

Der Webserver muß in den Systemeinstellungen bei Sharing in diesem Fall nicht (neu) gestartet werden, da der letzte Terminal-Befehl dies schon erledigt hat.

Tipps & Tricks

• WebDAV-Server hinter Firewalls - besser als FTP

  Prinzipiell läßt sich ein WebDAV-Server genauso einsetzen wie ein FTP-Server. Es wird dafür sogar, anders als bei FTP, nicht einmal ein weiterer offener Port in einer Firewall benötigt, da WebDAV direkt über den HTTP-Standardport 80 kommuniziert. Denn WebDAV ist nichts anderes als eine Erweiterung des HTTP-Protokolls. Wo HTTP durchkommt, da kommt auch WebDAV durch. Wer in seiner Firma durch die üblicherweise mit strengen Einstellungen versehene Firewall mit seinem privaten Rechner Daten austauschen möchte, dem könnte eben ein WebDAV-Server helfen. Dabei sollte man aber auch die zu übertragene Datenmenge im Auge behalten und die ganze Sache nicht "heimlich" betreiben, sondern sie unbedingt zuvor mit den zuständigen firmeninternen Instanzen ausführlich abstimmen, da das sonst böse Folgen haben kann.

  Ein weiterer Vorteil von WebDAV gegenüber FTP ist, daß keine spezielle Client-Software benötigt wird, um Daten auszutauschen. Und das weder auf dem Mac, noch in Windows (siehe nächster Punkt).

• Windows und WebDAV

  Das, was Mac OS X mittels "Mit Server verbinden..." im Finder kann, nämlich mit einem WebDAV-Ordner Verbindung aufnehmen, daß kann Windows mindestens seit der Version Windows 98 auch. Allerdings, erwartungsgemäß, etwas anders, und mit einem eigens dafür erfundenem Namen: Web-Folder. Diese befinden sich entweder direkt unter "Mein Computer" (z.B. Win 98) oder in "Netzwerkumgebung". Wer allerdings versucht, mit den hier vorgenommen Einstellungen für unseren DAV-Server von Windows aus Kontakt aufzunehmen, wird darüber (mehr oder weniger) erstaunt sein, daß es nicht funktionieren wird. Der Grund ist so einfach wie unverständlich: Wir haben uns für die sichere Variante der Passwortübetragung entschieden, die Digest-Methode. Die macht allerdings Windows derart Probleme, daß es nicht bereit ist, damit etwas anzufangen. Um Windows den Zugang zu gewähren, ist es nötig, statt der Digest-Methode die Basic-Methode zu verwenden, in der Passwörter stets im Klartext übertragen werden. Überall dort, wo wir in unserer Apache-Konfigurationsdatei die Zeile

  AuthType Digest

  stehen haben, müssen wir deshalb diese durch

  AuthType Basic

  ersetzen. Da sich die beiden Authentifizierungsarten jedoch deutlich in ihrer Handhabung durch den Webserver unterscheiden, ist es leider ebenfalls nötig, die Web-Benutzerdatei mit einem anderen Befehl als dem in Schritt 3 kennengelernten htdigest anzulegen und zu pflegen, nämlich mit htpasswd. Der kennt allerdings so etwas wie Realms, also Bereiche, nicht. Für diese Art der Web-Benutzerdefinition ist die Einteilung der Site in unabhängige passwortgeschützte Bereiche unerheblich. Der Befehl zum Anlegen der Datei und gleichzeitig des ersten Web-Benutzers sieht so aus:

  htpasswd -c /Library/WebServer/.htpasswd <Web-Benutzername>

  Anschließend muß ein Passwort für den Web-Benutzer vergeben werden. Weitere Web-Benutzer werden mit dem gleichen Befehl hinzugefügt, allerdings dann ohne das "-c", da das nur zum Erstellen der Datei benötigt wird. Und zusätzlich muß diese Datei in der Konfiguration des Webservers ebenfalls auf eine andere Weise angegeben werden. Dazu wird die Zeile

  AuthDigestFile /Library/WebServer/.htdigest

  durch

  AuthUserFile /Library/WebServer/.htpasswd

  ersetzt. Nach dem Neustart des Webservers kann dann auch Windows etwas mit dem (nun leider etwas unsichereren) Passwortschutz anfangen.

  Wenn neben dem DAV-Bereich noch andere passwortgeschützte Bereiche auf der Site existieren und in der Konfigurationsdatei definiert sind, können diese zwar natürlich weiterhin mit der Digest-Methode bei der Authentifizierung arbeiten, aber sobald von einem Windows-Rechner mit Internet-Explorer-Technologie darauf zugegriffen werden können soll (was durch die enge Verknüpfung mit dem Betriebssystem bei systemeigenen Methoden grundsätzlich der Fall ist), muß diese in der Apache-Konfiguration auf die gleiche Weise durch die Basic-Methode ersetzt werden. Andere Browser für Windows als der Internet-Explorer von Microsoft, etwa der Netscape Navigator oder andere Mozilla-Derivate, haben mit der Digest-Authentifizierung keinerlei Probleme. Das Lesen und Herunterladen von Dokumenten vom DAV-Server ist demnach mit solchen Browsern auch mit der sicheren Passwortübertragung möglich; allerdings können dann über diese Verbindung keine neuen Dokumente auf den DAV-Server aufgespielt werden, da Browser grundsätzlich nur lesen.

  Interessant an dieser Stelle ist noch, daß der Internet Explorer 5.x für den Mac die Probleme bei diesem Thema nicht mit seinem Windows-Bruder teilt, hier funktioniert das Anmelden über die sichere Methode bestens.

• Einrichten eines "Quasi"-Team-Kalenders

  Leider unterstützt iCal in seiner derzeitigen Version nicht die Möglichkeit, mehrere Benutzer zur gleichen Zeit an ein und denselbem Kalender arbeiten zu lassen. Wenn man also vorhat, in einem Intranet einen Team-Kalender einzurichten, könnte man sich mit dem folgenden Szenario vielleicht aushelfen:

  Einer im Team, etwa der Gruppenleiter (oder wie auch immer man heute dazu sagt), wird zum Verwalter des Team-Kalenders erkoren. Dieser legt in seinem iCal einen gewöhnlichen Kalender an, der treffend benannt wird. Ich nenne ihn der Einfachheit halber schlicht "Team-Kalender". Diesen Kalender veröffentlicht der Gruppenleiter nun auf dem DAV-Server mit der Option, daß Änderungen automatisch veröffentlicht werden. Der DAV-Server muß nicht notwendigerweise auch der Rechner des Gruppenleiters sein. Alle anderen Team-Mitglieder abonnieren diesen Kalender. Sie können zwar keine Änderungen an diesem Kalender vornehmen, aber sie haben Einsicht in alle das Team betreffenden Termine, ohne Rücksicht auf ihre eigene Beteiligung an diesen Terminen.

  Der Gruppenleiter kann diesen Kalender nun pflegen und muß sich nicht mehr weiter um deren Verteilung kümmern. Geschieht alles "elektrisch".

  Sollte ein Team-Mitglied nun einen Terminvorschlag haben, trägt er diesen in seinen eigenen privaten Kalender ein, verschickt ihn an die betroffenen Team-Mitglieder und stets an den Gruppenleiter, der nach vorheriger Prüfung den Termin in seinen Kalender übernimmt und auf den Team-Kalender zieht. Schon kann jeder im Team sehen, welche Team-Mitglieder wann in welchem Meeting sitzen oder beim Kunden unterwegs sind, auch, wer nicht direkt betroffen ist.

  Zugegeben, der Weg ist etwas umständlicher, als es nötig wäre, aber immerhin erreicht man so eine recht passable Lösung, um Teams die Möglichkeit zu geben, team-bezogene Termine zentral zu verwalten.

  Wichtig:

  Änderungen an Team-Terminen sollten in diesem Fall nur vom Gruppenleiter bzw. dem Team-Kalenderverwalter (wow!, was für ein Wort) vorgenommen werden. Der Team-Kalender sollte als der einzig verbindliche angesehen werden.

  Ich bin mir bewußt, daß diese Lösung alles andere als optimal ist, aber solange iCal keine bessere Alternative bietet und man nicht auf eine anderes Werkzeug zurückgreifen möchte, bleibt einem leider derzeit kaum etwas anderes übrig. :-(

  Verbesserungsvorschlöge hierfür nehme ich sehr gerne entgegen...