Erfahrungen mit der OS-X-Server-App

Bei einem Kunden mit insgesamt 15 Computerarbeitsplätzen sollte eine Client/Server-Umgebung auf Apple-Basis geschaffen werden. Zu Beginn des Projektes fanden wir bei unserem Kunden eine reine Mac-Umgebung (Mac Mini, Macbook, iMac) vor. Die Daten wurden zentral auf einem QNAP NAS gespeichert. Die Benutzer waren in einer simplen Rechtestruktur lokal auf dem QNAP NAS angelegt.

Da der Kunde eine Client/Server Software benötigte deren Serverkomponente ein Apple-Betriebssystem voraussetzt, wurde hierfür ein Mac Pro (2014) angeschafft. Über einen weiteren Mac Pro sollte mit Hilfe der OS-X-Server-App für Mavericks eine Benutzerverwaltung sowie Netzlaufwerke mit einer Berechtigungsstruktur nachgerüstet werden. Die technischen Informationen rund um die OS-X-Server-App bestätigten alle Anforderungen. Als Datenspeicher wurde neben den beiden Mac Pro zudem ein 4-Bay Thunderbolt Storage System von Apple angeschafft.

In der Praxis stellte sich die Umstellung leider problematischer dar als zunächst erwartet. Konkret ergaben sich folgende Probleme:

  • Nach dem Anlegen der Benutzer konnten sich diese nicht authentifizieren/anmelden
  • Es war möglich Freigaben anzulegen, es konnte allerdings kein Benutzer darauf zugreifen
  • Berechtigungen auf die Freigaben konnten gesetzt werden, sie wurden aber nicht übernommen

Das einzige Feature, das zuverlässig funktionierte, war der DHCP-Server. Selbst der DNS-Server funktionierte nicht wie gewünscht.

Im Apple-Support-Forum fanden sich viele Beiträge zu dieser Problematik (https://discussions.apple.com/thread/5509703?tstart=0).

Auch der Support seitens Apple und die mehrmalige Neuinstallation des kompletten Mac Pro führten nicht dazu, die gewünschten Funktionen in Betrieb nehmen zu können.

Aufgrund der beschriebenen Fehlfunktionen, wurde letztendlich auf die OS-X-Server-App verzichtet. Es wurden alle Benutzer lokal auf dem Mac Pro mit dem angeschlossenen Storage-System angelegt und die Berechtigungen mit den lokalen Benutzern gesetzt. DNS und DHCP wurden auf dem Router eingerichtet.

In der Praxis zeigte sich in der Folgezeit bisher lediglich ein erwähnenswertes Problem: Berechtigungen können zwar über die GUI in OS X für die freigegebenen Ordner vergeben werden, sie werden allerdings nicht vererbt. Möchte man dies tun, muss man mittels dem Befehl

sudo chmod +a „user:USERNAME allow list, add_file, search, add_subdirectory, delete_child, readattr, writeattr, readextattr, writeextattr, readsecurity, file_inherit, directory_inherit“ /Volumes/PromiseRAID/Freigabe

die Berechtigungen über das Terminal für jede Freigabe / jeden Benutzer händisch setzen. Bei entsprechender Menge der vorhandenen User oder einer größeren Komplexität, handelt es sich hierbei um einen nicht zu unterschätzenden Aufwand.

V2V Konvertierung von Citrix XenServer zu VMware ESXi 5.5

Dieser Blogeintrag beschreibt die Vorgehensweise, wie virtuelle Maschinen (hauptsächlich Windows 2008 R2) auf Basis von Citrix XenServer zu VMware ESXi 5.5 migriert werden können.

Zunächst einmal besteht die Möglichkeit, den VMware Converter für die Konvertierung zu benutzen. Es zeigte sich jedoch, dass die virtuellen Festplatten nicht erkannt werden konnten. Wir haben verschiedene Versionen des Converters getestet, bei allen zeigte sich das gleiche Bild.

Da wir keine weiteren Software Produkte (zum Beispiel Acronis Universal Restore) kaufen wollten, haben wir uns letztlich dazu entschieden, das Windows-eigene Server Backup zu nutzen. Das erzeugte Backup speicherten wir auf ein NAS der Marke Synology mit LAN-Bonding zur Durchsatzerhöhung ab. Anschließend haben wir auf dem neuen Server mit VMware ESXi 5.5 jeweils neue virtuelle Maschinen mit ähnlichen Hardwareeigenschaften angelegt und diese von der Windows 2008 R2 DVD gebootet. Der nächste Schritt war die Wiederherstellung des Backups über die Computerreparaturoptionen.

Der erste Start des zu zurückgespielten Backups endete in einem Blue-Screen, da noch die falschen Festplattencontrollertreiber in der Registry aktiv waren. Die Behebung des Fehlers machte einen Eingriff in der Registry mittels Regedit im Computerreparaturmodus nötig. In unserem Fall mussten wir die LSI-SAS Treiber aktivieren, da VMware jene als Controllertreiber in virtuellen Maschinen verwendet (kann je nach Konfiguration jedoch variieren.)

Nach dem erfolgreichen Start der so konvertierten virtuellen Maschine haben wir uns mit dem lokalen Administrator angemeldet (kein Domänen-Account), die XenTools deinstalliert und die VMware Tools zur besseren Treiberunterstützung installiert. Abschließend empfiehlt sich noch die Umstellung der virtuellen Netzwerkkarten vom E1000 auf VMXNET3.

Für die komplette Konvertierung einer ca. 400GB großen virtuellen Maschine mit Windows 2008 R2 und MS SQL-Datenbank dauerte etwa zweieinhalb Stunden, was nicht zuletzt stark durch die Verwendung von LAN-Bonding (einer Bündelung der Netzwerkkarten mittels LACP) beschleunigt wurde.