zurück zum Artikel

Teamwork mit OS X 10.8 Server

Artikel

Apples OS X Server ist zwar leicht zu bedienen, aber bei den Gruppenfunktionen wie Kalender, Adressen und Wiki hat er Defizite. Mit ein paar Kniffen lässt er sich trotzdem zu einer brauchbaren Lösung für Arbeitsgruppen machen.

Artikel aus c't 9/13

Apple bewirbt OS X Server [1] als einfache aber potente Möglichkeit, Arbeitsgruppen die Zusammenarbeit zu erleichtern, ohne dass großartiger Konfigurationsaufwand anfällt. In Sachen Einrichtung kann Apple sein Versprechen durchaus halten: Die meisten Dienste lassen sich ganz leicht aktivieren und danach umgehend nutzen. Dennoch gibt es einige Stolpersteine, denn die Dokumentation ist eher rudimentär. Sie verspricht manchmal zu viel und verschweigt an anderer Stelle interessante Fähigkeiten.

Zwar lässt sich etwa ein persönlicher Kalender spielend einfach auf den Server verlagern, aber sobald mehrere Benutzer gemeinsam Termine koordinieren oder bearbeiten müssen, wird es schnell unübersichtlich. Und wenn ein freigegebener Kalender auf der Gegenseite einfach nicht auftauchen möchte, muss man zu undokumentierten Mitteln greifen, um versprochene Funktionen nutzen zu können. Auch der Kontakte-Dienst und das Wiki verhalten sich in der Praxis teils anders, als es Apples Produkt-Webseite suggeriert.

Herausragend sind die bequeme Konfiguration über Server.app und die praktischen Push-Benachrichtigungen, die etwa den Kalender stets auf dem neuesten Stand halten. Und Administratoren, die Macs und iOS-Geräte fernwarten [2] wollen, kommen an Apples Serverprodukt kaum vorbei.

Installation in wenigen Schritten

Um OS X Server einsetzen zu können, ist zunächst ein Mac notwendig, auf dem eine Client-Version von OS X läuft. Dieser lässt sich zum Server erheben, indem man für 19 Euro im App Store „OS X Server [3]“ erwirbt. Anschließend findet man die Server.app im Programme-Ordner. Sie dient als zentrales Konfigurationswerkzeug, über das nahezu alles verwaltet werden kann. Nach dem ersten Start des Programms öffnet sich ein simpel gehaltener Einrichtungsassistent, der die wichtigsten Informationen abfragt.

Um alle Funktionen von OS X Server ausreizen zu können, ist ein voll qualifizierter Domain-Name sinnvoll: Einerseits sind dann alle angebotenen Dienste auch über das Internet verfügbar und andererseits lassen sich nur so Push-Benachrichtigungen nutzen, die Änderungen am Kalender oder im Adressbuch nahezu in Echtzeit an die verbundenen Geräte schicken. Man muss aber nicht unbedingt einen Domain-Namen kaufen – will man einfach nur mal reinschnuppern oder Geld sparen, tut es auch einer der kostenlosen DynDNS-Dienste, etwa noip.com [4]. Betreibt man den Server hinter einer Firewall oder einem Router, dann sind entsprechende Port-Weiterleitungen [5] notwendig.

Der Assistent fragt bei der Erstkonfigura­tion nach einer Apple-ID, die für den Push-Dienst benötigt wird. Apple empfiehlt, eine ID zu verwenden, die nicht zum Kauf von Apps oder Musik benutzt wird. Im Falle eines Missbrauchs lässt sich eine solche ID ohne angehängte Kaufinformationen unproblematischer sperren. Entscheidet man sich zunächst gegen Push, kann man die Benachrichtigungen später jederzeit in den Einstellungen via Server.app aktivieren. Diese sind etwa dann notwendig, wenn man gemeinsam Termine im Kalender verwaltet und Änderungen ohne Zutun des Benutzers sofort sichtbar sein sollen.

Der Rest der Einrichtung erfolgt weitgehend automatisch, wobei der Assistent auch gleich selbst signierte SSL-Zertifikate erstellt, die man zur verschlüsselten Kommunikation mit dem Server benötigt. Unternehmen sollten im Produktivbetrieb aber lieber offiziell signierte Zertifikate verwenden, die sich jederzeit über die Zertifikatsverwaltung in Server.app importieren lassen.

Benutzerverwaltung

Vor dem Aktivieren von Diensten sollte man zunächst die Frage klären, wie man am besten die Benutzerkonten anlegt. Zwar können lokale Konten verwendet werden, wie es auch die Client-Variante von OS X handhabt. Um den vollen Leistungsumfang von OS X Server ausschöpfen zu können, empfiehlt es sich aber, den mitgelieferten Open-Directory-Verzeichnisdienst zu verwenden und seine Benutzer dort abzulegen. Sind diese im Verzeichnis erfasst und mit Informationen wie zum Beispiel der Raumnummer versehen, lassen sie sich über einen CardDAV-Client abrufen.

Open Directory ist in wenigen Schritten eingerichtet: Zunächst fragt der Einrichtungsassistent, ob man eine neue Open-Directory-Domain anlegen möchte, ob also der Server als Open-Directory-Master dienen soll. Damit erhebt man den Server zum zentralen Anlaufpunkt im Netzwerk, wenn es um Benutzerkonten geht. Betreibt man bereits einen solchen, kann man den neuen Server auch als Replik des bereits vorhandenen Benutzerverzeichnisses konfigurieren, um die Ausfallsicherheit zu erhöhen. Danach legt man einen Verzeichnis-Administrator an, trägt den Namen der Organisation und eine Mail-Adresse ein und startet die Konfiguration des Dienstes.

Administratoren sollten Benutzern den Zugriff nur auf die Dienste gestatten, die sie auch wirklich benötigen.

Alle ab diesem Zeitpunkt neu erstellten Benutzer und Gruppen werden als „Lokale Netzwerkbenutzer“ im Open Directory abgelegt und können alle angebotenen Dienste nutzen, etwa den Kalender. Sollte das nicht gewünscht sein, kann man einzelnen Benutzern oder Gruppen den Zugriff auf bestimmte Dienste entziehen – ein reiner Wiki-Benutzer muss ja nicht unbedingt die Möglichkeit haben, sich über VPN ins LAN zu verbinden.

Adressbuch synchronisieren

Der Kontakte-Dienst bietet die wenigsten Konfigurationsmöglichkeiten und lässt sich deshalb am einfachsten einrichten. Er bedient sich des offenen CardDAV-Protokolls und speichert die einzelnen Kontakte als vCards. In Server.app als Kontakte betitelt, lässt sich der Dienst lediglich einschalten; die einzige darüber hinausreichende Option ist, das Open-Directory-Verzeichnis durchsuchbar zu machen.

Das bedeutet, dass alle in Open Directory abgelegten Benutzer über Client-Software wie Kontakte.app, die bei OS X mitgeliefert wird, abrufbar sind. Das Verzeichnis lässt sich allerdings nur durchsuchen – Schreibzugriff für Clients ist nicht vorgesehen, ebenso wenig eine Übersicht aller verfügbaren Kontakte. Man muss also schon den Namen oder die Mail-Adresse eines Benutzers kennen, um an die restlichen Informationen zu gelangen.

Gibt es eine Visitenkarte in mehreren Accounts, rührt sie das OS-X-Adressbuch zu einem Kontakt zusammen. Mittels Klick auf einen der „Cards“-Einträge lässt sich herausfinden, welche Information wo herkommt.

Jeder Benutzer mit einem Server-Account und Zugriff auf den Kontakte-Dienst kann nun sein lokales Adressbuch auf den Server auslagern, indem er ausgewählte – oder gleich alle – Visitenkarten per Drag & Drop auf den Server-Account zieht. Was fehlt, ist eine Möglichkeit, sein Adressbuch gemeinsam mit anderen zu nutzen.

Um die fehlenden Gruppenfunktionen nachzubilden, kann der Administrator einen eigenen Benutzer für das gesamte Team anlegen. Diesen Account richtet dann jeder Mitarbeiter in seiner Client-Software als zusätzlichen CardDAV-Account ein. Entsprechende Unterstützung ist in der Kontakte.app von OS X eingebaut. Für Clients wie Thunderbird oder MS Outlook gibt es separate Plug-ins, die CardDAV-Unterstützung nachliefern.

Einen geteilten Benutzer anzulegen und ins eigene Adressbuch einzubinden ist also nicht allzu schwer. Ärgerlich sind jedoch die Implikationen: Verlässt etwa ein Mitarbeiter das Unternehmen, muss man daran denken, das Passwort des gemeinsamen Accounts zu ändern, und die verbliebenen Benutzer müssen entsprechend nachziehen. Ebenso wenig ist man vor Irrtümern oder Fehlern geschützt, denn ein rein lesender Zugriff auf den Datenbestand ist nicht möglich. Löscht einer der Benutzer einen Kontakt, verschwindet dieser für alle anderen ebenfalls, ohne dass eine Benachrichtigung erfolgt. Halbwegs ruhig schläft also nur, wer ein möglichst aktuelles Backup hat.

Termine, Termine, Termine

Der Kalender-Dienst ist deutlich ausgereifter und bringt nicht nur separate Kalender für jeden Benutzer mit, die er an andere Benutzer delegieren und von diesen bearbeiten lassen kann, sondern auch Gruppenkalender, die ausschließlich über das mitgelieferte Wiki selbst eingerichtet werden können.

Apple setzt auch hier auf ein offenes Protokoll, in diesem Fall ist es CalDAV. Über Server.app lassen sich nur wenige Einstellungen vornehmen. Aktiviert man Einladungen über E-Mail, können auch Benutzer, die außerhalb des eigenen Open-Directory-Verzeichnisses leben, eingeladen werden. Ferner kann der Administrator über die grafische Bedienoberfläche Orte und Ressourcen anlegen, etwa Besprechungsräume und Beamer.

Das Auslagern des eigenen Kalenders auf den Server ist spielend leicht eingerichtet, dazu benötigt man lediglich einen CalDAV-tauglichen Client; unter OS X ist das Kalender.app, für Windows oder Linux gibt es Plug-ins, die die Funktion nachrüsten. Es reicht, als Protokoll CalDAV auszuwählen, den Benutzernamen, Passwort und den Servernamen einzutragen und schon taucht in der linken Seitenleiste der Kalender auf dem Server auf.

Kollegen einladen

Benutzer, die einen Open-Directory-Account haben, lassen sich über das „Teilnehmer“-Feld zu einem Termin einladen. Dabei reicht es, die ersten Buchstaben des Namens oder des Kürzels einzugeben – der Server vervollständigt den Rest und bietet gegebenenfalls eine Auswahl an. Die Benachrichtigung erfolgt über Push und damit nahezu in Echtzeit. Termine können angenommen, abgelehnt oder mit „Vielleicht“ quittiert werden. Gibt es Terminprobleme, kann die Ansicht „Verfügbarkeit“ automatisch den nächstmöglichen Termin, zu dem alle Teilnehmer Zeit haben, ermitteln. Das gilt auch für Orte und Ressourcen. Erstere trägt man in das gleichnamige Feld ein, letztere wie gewöhnliche Benutzer in die Teilnehmerliste. Orte und Ressourcen nehmen Einladungen automatisch an. Es ist jedoch auch möglich, deren Verfügbarkeit erst von einem Stellvertreter absegnen zu lassen. Ein Stellvertreter kann in diesem Fall über Server.app definiert werden.

Ist ein Teilnehmer, ein Raum oder eine Ressource nicht verfügbar, kann man über die Verfügbarkeitsansicht den nächstmöglichen Zeitpunkt ermitteln, an dem alle Zeit haben.

Einladungen an externe Benutzer sind ebenfalls möglich, dazu ist aber ein laufender Mail-Dienst auf dem Server notwendig. In der Regel reicht es, den Schalter auf „Ein“ zu stellen, und schon ist der Mail-Server betriebsbereit – wie man Mails in einer eher exotischen Umgebung, etwa über einen privaten DSL-Anschluss, verschickt und empfängt, haben wir bereits anhand von Mac OS X Lion durchexerziert [6].

Externe Teilnehmer benachrichtigt der Server über E-Mail und schickt eine Standard-konforme ics-Datei zu, die Sie in ihren Client übernehmen können. Klicken Sie auf „Annehmen“ (oder „Ablehnen“, je nachdem), wird eine Mail an den bei der Einrichtung erstellten Kalender-Account geschickt, der das Ereignis entsprechend aktualisiert und die restlichen Teilnehmer benachrichtigt.

Kalender freigeben

Im Unterschied zum Kontakte-Dienst kann man Kalender freigeben, ohne einen gemeinsamen Account einzurichten, auch wenn das manchmal nicht ohne Klimmzüge geht. Denn Apple hat die Konfiguration beinahe vollständig an die Clients ausgelagert, was einerseits Verwirrung stiften kann und andererseits nicht immer einwandfrei funktioniert, wenn man sich an Apples Vorgaben hält.

Um einen Kalender freizugeben, sind mit Kalender.app einige Klicks notwendig: In den Programmeinstellungen steigt man in die Accounts ein, markiert den entsprechenden, klickt auf Stellvertretung, dann auf Bearbeiten. Hier fügt man mit dem Plus-Symbol Benutzer hinzu, denen man auf den eigenen Kalender Zugriff gestattet – auf Wunsch auch mit Schreibrechten. Die Gegenstelle sieht den Kalender anschließend in der Stellvertretungsliste und muss ein Häkchen setzen, um ihn anzuzeigen.

Will der Administrator seine Benutzer davor bewahren, selbst mit Freigaben zu hantieren, so hilft ihm der Kommandozeilenbefehl calendarserver_manage_principals, mit dem er Stellvertretungen direkt auf dem Server erstellen und verwalten kann. Ein Beispiel aus der Praxis: Die Gruppe „sekretariat“ möchte die Termine des Benutzers „chefe“ verwalten. Um dieser Gruppe Schreibzugriff auf den Kalender zu geben, gibt man folgenden Befehl ein:

sudo calendarserver_manage_principals --add-write-proxy groups:sekretariat --list-proxies users:chefe

Benutzer, die der Gruppe „sekretariat“ angehören, haben zwei Möglichkeiten, diesen Account in ihren Kalender-Client hinzuzufügen. In Kalender.app steigt man in die Einstellungen ein, klickt auf Accounts, dann auf Stellvertretung. Dort taucht der freigegebene Kalenderbenutzer auf, mit der Option, sich diesen anzeigen zu lassen. Anschließend sollten die Kalender in der linken Seitenleiste unter „Stellvertretungen“ auswählbar sein.

Leider funktioniert das aber nicht immer zuverlässig: Der Benutzer wird zwar angezeigt, die freigegebenen Kalender aber nicht. In dem Fall bindet man den Kalender über eine URL ein, die folgende Syntax hat, wobei Server- und User-Name entsprechend angepasst werden müssen:

https://$Servername/principals/users/$Username/

Man erstellt also in Kalender.app einen neuen CalDAV-Account und gibt als Serveradresse https://MeinOSXServer.de/principals/users/chefe/ ein, wobei die restlichen Anmeldedaten einem Benutzer gehören, der Mitglied der „sekretariat“-Gruppe ist. Der Kalender wird dann nicht als Stellvertretung angezeigt, sondern taucht als eigenständiger Eintrag auf, der sich in der Handhabung von anderen Konten nicht unterscheidet.

Gruppenkalender im Wiki

Eine weitere Möglichkeit, gemeinsam Kalender zu bearbeiten, sind Gruppenkalender, die über das Wiki angelegt werden. Dazu meldet sich der Eigentümer des Wiki über das Web-Interface an, navigiert in die Wiki-Einstellungen und aktiviert unter „Allgemein“ den Kalender. Unter „Rechte“ stellt er ein, welche Benutzer beziehungsweise Gruppen welche Berechtigungen haben. So ist es zum Beispiel möglich, einer bestimmten Gruppe Lese- und Schreibrechte zu gewähren, während eine andere Gruppe ausschließlich lesend auf den Kalender zugreifen kann. Diese Rechte gelten im Übrigen für das gesamte Wiki und nicht bloß für den Kalender.

Es gibt nun zwei Möglichkeiten, diesen Gruppenkalender in ein Client-Programm einzubinden: Ist man bereits am Web-Interface angemeldet, reicht es, die Kalender-Seite zu besuchen, die Kalendereinstellungen aufzurufen, indem man den Mauszeiger über den gewünschten Kalender hält und auf das aufpoppende „i“ klickt. Hier kann man ihn „Zu meinem Kalender“ hinzufügen. Das bedeutet in der Praxis, dass am Server der Gruppenkalender dem angemeldeten Benutzer zugeordnet wird und am Client unter der üblichen Kalenderliste des Benutzers auftaucht. Da diese Zuordnung am Server passiert, wird die Einstellung auf alle Geräte übertragen, mit denen der Benutzer seinen persönlichen Kalender verwaltet.

Verwenden die Wiki-Benutzer allerdings ausschließlich iOS-Geräte, auf denen die Kalenderansicht über den Browser nicht zur Verfügung steht, muss man wieder zu einer URL greifen, um den Kalender auf seinem Client einzubinden. Für Gruppenkalender lautet diese

https://$Servername/principals/__uids__/wiki-$Wikiname/

In der Praxis wäre das etwa https://Mein­OSXServer.de/principals/__uids__/wiki-sekretariat/ und die übliche Kombination aus Benutzername und Passwort. Zu beachten sind die zwei Unterstriche vor und nach „uids”.

Der Nachteil am Gruppenkalender ist, dass nicht ersichtlich ist, welches Mitglied der Gruppe einen Termin erstellt hat, was unter Umständen zu Verwirrung führen kann. Ferner kann ein über das Wiki eingerichteter Gruppenkalender weder Teilnehmer einladen noch Ressourcen oder Orte buchen. In der Praxis sind das ärgerliche Limitierungen, die einen solchen Gruppenkalender nur bedingt einsatzfähig machen. Will man Kalender gemeinsam nutzen, fährt man mit der Stellvertreter-Variante deutlich besser.

Mehr als nur ein Wiki

Das Wiki von OS X Server bietet abgesehen von klassischer Wiki-Funktionalität, also dem gemeinsamen Bearbeiten und Verknüpfen von Webseiten, einen eigenen Bereich, in dem eingetragene Nutzer ihre Dokumente hochladen, ein herkömmliches Blog anlegen und auf ihren Kalender zugreifen können. Aktiviert wird das Wiki wie üblich über Server.app, wobei der Administrator definieren kann, ob alle oder bloß ausgewählte Benutzer oder Gruppen Wikis anlegen können. Ferner kann er, zusätzlich zum Zugriff über das Web-Interface, WebDAV-Zugriff auf Wiki-Dokumente zulassen. Das können Dateien beliebiger Art sein, die Benutzer unabhängig von „normalen“ Wiki-Seiten ins Wiki hochladen können.

Der Rest der Verwaltung erfolgt über das Web-Interface, das eine eigene Rechte-Vergabe für diesen Bereich mitbringt. Benutzer können jedoch immer ihre persönliche Seite anlegen und dort etwa ein Blog erstellen, egal welche Rechte sie sonst haben. Ebenso ist der Zugriff auf den eigenen und gegebenenfalls freigegebene Kalender jederzeit möglich.

Hat ein Benutzer die Berechtigung, Wikis anzulegen, kann er theoretisch unbegrenzt viele davon erstellen. Startet er ein neues Wiki, ist er automatisch der Eigentümer und kann zusätzlich ein Wiki-Blog und den bereits beschriebenen Wiki- beziehungsweise Gruppenkalender aktivieren. So kann für jedes (Unter-)Thema ein eigener Bereich am Server angelegt werden, für den alle genannten Funktionen getrennt zur Verfügung stehen.

Nicht alle dürfen alles

Der Eigentümer eines Wiki kann weitere zusätzliche Benutzer oder Gruppen zu Mit­eigentümern machen und ihnen Lese- und/oder Schreibrechte geben. Genauso kann er allen nicht angemeldeten Benutzern die Leserechte entziehen: Ist einem Benutzer der Zugriff auf das Wiki nicht erlaubt, taucht es nicht mehr in der Übersichtsliste des Benutzers auf. Versucht er direkt über die URL darauf zuzugreifen, bekommt er eine entsprechende Fehlermeldung angezeigt. So lassen sich abgeschlossene Bereiche definieren und sensible Informationen vor unerwünschten Besuchern schützen.

Jede Wiki-Seite lässt, unabhängig vom eigentlichen Inhalt, Kommentare zu. Auch hier kann der Eigentümer festlegen, wer Kommentare hinterlassen kann, und ob diese erst einer Freischaltung durch den Eigentümer bedürfen.

Wiki-Stolpersteine

In Probleme läuft man, wenn zwei Benutzer eine Seite gleichzeitig bearbeiten. Zwar wird man beim Speichern darauf aufmerksam gemacht, dass jemand anderes inzwischen eine neue Version erstellt hat. Man hat aber lediglich die Möglichkeit, die Änderungen des anderen Benutzers zu überschreiben oder die eigenen zu verwerfen. Entscheidet man sich für die eigene Variante, so sieht man nach einem Aktualisieren der Seite zwar die Änderungen des vorherigen Bearbeiters im Verlauf, die konkurrierenden Dokument-Versionen muss man jedoch von Hand mit Hilfe von Copy und Paste zusammenführen. Und dabei hoffen, dass die Wiki-Seite nicht wieder in Bearbeitung ist – eine ausgeklügelte Versionskontrolle oder zumindest eine Sperre, sobald jemand eine Seite bearbeitet, sucht man leider vergebens.

Wiki-Seiten lassen sich durchaus gut gemeinsam bearbeiten, mit Dokumenten klappt das leider nicht ganz so gut.

Ebenfalls nicht zu Ende gedacht ist der Dokument-Upload. Zwar können beliebige Dokumente in Wikis oder in den Benutzerbereich geladen werden, über das Web-Interface ist aber bloß eine Voransicht beziehungsweise ein Download möglich, direktes Bearbeiten jedoch nicht. Selbiges gilt für den Zugriff via WebDAV, sofern dieser über ein Desktop-Betriebssystem erfolgt. Einzig iOS-Nutzer können mit Pages oder Numbers Dokumente bearbeiten und anschließend wieder hochladen, auch wenn dieser Prozess mühsamer ausfällt als notwendig. Denn die Programme merken sich den Pfad nicht, unter dem die Datei abgelegt war, und so muss man sich nach jeder Änderung neu zum Server verbinden, sich durchs Dateisystem hangeln und anschließend die vorhandene Datei überschreiben. iCloud-Dokumente sind da deutlich einfacher in der Handhabung, da jede Änderung automatisch übertragen wird und der Benutzer sich um nichts kümmern muss. Überschreibt man mit einem iOS-Client eine Datei im Wiki, taucht aber zumindest das Dokument unter der gleichen URL wieder auf, und über den Verlauf lässt sich auch nachvollziehen, wann was von wem geändert wurde.


URL dieses Artikels:
http://www.heise.de/-1845731

Links in diesem Artikel:
[1] http://www.heise.de/artikel-archiv/mi/2013/09/070_Ein-Mac-fuer-alle-Faelle
[2] http://www.heise.de/artikel-archiv/ct/2011/23/180_Ausweitung-der-Konfigurationszone
[3] https://itunes.apple.com/de/app/os-x-server/id537441259?mt=12
[4] http://www.noip.com/
[5] http://support.apple.com/kb/TS1629?viewlocale=de_DE
[6] http://www.heise.de/mac-and-i/artikel/Instant-Post-1371972.html