Mit der Version 2.2 des Mountain Lion Server hat Apple dankenswerterweise einen neuen Service ausgeliefert: den CachingServer.
Ist ein Caching Server im lokalen Netz installiert, wird dieser vom App Store Programm erkannt und als Proxy für den Download der Programme und Updates aus dem Appstore genutzt. Angesichts des ständig steigenden Datenvolumens für die laufende Softwareaktualisierung und die zunehmende Anzahl von iOS und OSX Devices ist dies prinzipiell eine gute Idee, um die stagnierenden DSL Bandbreiten zu schonen.
Für die ersten Tests habe ich die einzig erkennbaren Rückmeldungen genutzt, die mir der Caching Server liefert. Im Verzeichnis /Library/Server/CachingServer/Logs/ ist eine Datei Debug.log vorhanden. In dieser Datei werden die Aktivitäten des Serverprozesses protokolliert. Zudem existiert auch ein Datenverzeichnis, in das die geladenen Artefakte geschrieben werden.
Für die ersten Tests habe ich ein Programm aus dem Appstore heruntergeladen. Beobachtet man den Datenverkehr zwischen Rechner und den Apple Servern, werden für jeden Download erst einmal Daten zwischen Apple und dem App Store Programm ausgetauscht. Dort finden sich wahrscheinlich die für den Betrieb notwendigen Receipts und Keys für die Entschlüsselung der Daten. Damit ist - verständlicherweise - auch beim Einsatz des CachingServer ein Off-Line Betrieb unmöglich.
Der Transfer der Programmdaten wird aber dann über den CachingServer abgewickelt. Dabei werden anscheinend auch Teilfragmente des Downloads bereits gecacht. Insbesondere bei Updates werden gegebenenfalls auch nur die geänderten Bestandteile des Auslieferungspakets benötigt. Der jeweilige Stand der Downloads wird in einer unverschlüsselten SQLite3 Datenbank hinterlegt, so kann man mit dem sqlite3 Befehl einen Blick in diese Daten wagen.
Sind die Daten erst einmal im CachingServer gespeichert, nutzen andere Rechner die lokal vorliegenden Daten und der Download der Aktualisierung damit angenehm beschleunigt. Wenn sich also Client und Server finden, wird die regelmäßige Pflege der betreuten OSX Systeme in der Familie zu einer angenehmen Pflicht.
Um den unter OSX laufenden Rechnern die Möglichkeit zu bieten, den für sie vorgesehenen Server im lokalen Netz zu finden setzt Apple (leider) nicht auf die bewährte Technik Bonjour. Stattdessen ermittelt der Server seine public-IP Adresse und registriert sich unter dieser bei den Update Servern im Apple Rechenzentrum. Auch die Clients scheinen die jeweilige public-IP Adresse zu bestimmen und erhalten dann einen passenden Download-URL zugewiesen.
Dieser Mechanismus jedoch scheint nicht immer sauber zu funktionieren. Wo hier die Ursache liegen mag, kann leider nur vermutet werden. Eine Möglichkeit ist, dass die fortwährende Änderung der Netzwerkkonfiguration eines DSL Anschlusses irgendwann dazu führt, dass die Apple Server nicht in der Lage sind, dem Client den korrekten CachingServer zuzuweisen. Ich kann mir aber ebenso vorstellen, dass in dem mir von der Telekom zugewiesenen IP-Netz - von dem ich nur eine von vielen IP-Adressen nutzen darf - irgendwo ein weiterer Server installiert ist. Der von Apple implementierte Mechanismus scheint ja auf Basis der IP-Adressen die Netzwerktopologie zu rekonstruieren um einen “naheliegenden” Server zu finden. Vielleicht werden die Clients dann auf einen Server verwiesen, der irgendwo hier von einem anderen Enthusiasten aufgebaut wurde…
Für den Xcode Update mit etwa 1,6 GByte hat der CachingServer leider nicht funktioniert. Der erste Download wurde zwar über den Server abgewickelt, alle nachfolgend gestarteten Clients jedoch haben das Update geladen ohne auf den Cache zurück zu greifen. Schade!
Die Idee ist gut, aber in der Umsetzung muss noch einiges nachgebessert werden.