Wer mag kann es sich gerne herunterladen. Viel Spaß damit!

Ich habe beschlossen, die Tips und Tricks zum Thema Apple Hard- und Software in ein eigenes Blog auszulagern und dieses zukünftig mit meinen Kollegen am RRZE gemeinsam zu betreiben.

Mehr Köpfe hinter einem Blog bedeutet mehr Inhalte und hoffentlich öfters und regelmäßiger Beiträge als bisher. Mein Blog wird sich weiterhin um persönliche Gedanken von mir und den einen oder anderen sysadmin Tip drehen und wird somit auch weiterhin bestehen bleiben.

Hier der Link auf das FAUmac Blog

Mit 10.6 Snow Leopard hat das AD Domain Trusting recht gut funktioniert: der Snow Leopard Client wird an eine AD Domain gebunden und bekommt alle Authentifizierungsinformationen (Benutzer, Gruppen, Computer) aus allen Domains denen der AD Zweig traut. Alles was dazu gemacht werden muss ist das Häkchen Authentifizierung aus jeder Domain in der Gesamtstruktur ermöglichen zu setzen:

Der Suchpfad für Authentifizierung und Kontakte sollte automatisch auf All Domains gesetzt sein. Falls dies nicht der Fall ist, einfach einen neuen Suchpfad einfügen

Das hat, wie bereits erwähnt, ganz gut Funktioniert. Bis Lion.

Mit Lion hat Apple, was Authentifizierung und Verzeichnisdienste betrifft, eine ganze Menge umgebaut - leider mit einigen Fehlern die bis dato (OS X 10.7.4) immer noch nicht behoben sind. AD Authentifizierung gegen eine Single-Domain AD klappt nach wie vor, bei Multi Domains mit Trusts gibt's Probleme. Das manifestiert sich u.A. dadurch, dass bei einem Login das Login Fenster einfach stehen bleibt und sich nichts mehr tut. In den Logs stehen dann Einträge die darauf hindeuten, dass der Benutzer bzw. dessen UID nicht gefunden/gematcht werden können: getpwuid("20707") failed

Abhilfe schafft (zumindest unter 10.7.4) das oben genannte Häkchen bei Authentifizierung aus jeder Domain in der Gesamtstruktur ermöglichen zu löschen und im Suchpfad die jeweils benötigte Teildomäne(n) hinzufügen. Wichtig ist, dass der Eintrag "All Domains" gelöscht wird. Dann funktioniert die Authentifizierung gegen eine Multi-Domain AD wieder wie unter Snow Leopard. Zu diesem Thema gibt es auch Diskussionsbeiträge  in den Apple Foren.

Bei der aktuellen Beta Version von Mountain Lion (10.8) tritt dieses Problem nicht auf. Hier scheint Apple offensichtlich nachgebessert zu haben. Allerdings kann sich bis zum finalen Release von Mountain Lion noch einiges ändern.

Als erstes montiert man das (Netz)Laufwerk auf dem das Time Machine Image liegt. Dort findet sich eine Datei RECHNERNAME.sparsebundle. Das ist das Backup Image.

Man muss nun alle "immutable flags", also jene Dateieigenschaft die es verhindert, dass Dateien (auch von root) verändert werden können. Je nach Größe der Time Machine Sicherung kann das ziemlich lange dauern. Das macht man mit dem folgenden Befehl:

chflags -R nouchg /Volumes/NETZFREIGABE/RECHNERNAME.sparsebundle

Als nächstes montiert man die Netzfreigabe auf der das Image liegt - meistens ein AFP Export eines Servers. Im Anschluss wird das Image (eigentlich ein Sparse Bundle) importiert - ohne es wirklich zu montieren:

hdiutil attach -nomount -noverify -noautofsck /Volumes/NETZFREIGABE/RECHNERNAME.sparsebundle

Das kann eine Zeit dauern, im Anschluss sollte die Liste der Partitionen des Images ausgegeben werden die in etwa folgendermaßen aussieht:

/dev/disk4 Apple_partition_scheme

/dev/disk4s1 Apple_partition_map

/dev/disk4s2 Apple_HFSX

Die für die Prozedur interessante Partition - also die mit den Daten - ist die Partition 2.

Als nächstes wird der eigentliche Dateisystem Check gemacht:

fsck_hfs -drfy /dev/disk4s2

Bitte hier wieder daran denken die Platte zu verwenden die weiter oben ausgegeben wurde. Die verwendeten Optionen sind: -d für Debug Output (damit wir sehen was der Check gerade macht), -Rc den Katalogbaum neu aufbauen (-r würde an dieser Stelle dasselbe tun), -f um den check zu forcieren auch wenn das Programm der Meinung ist, dass das Dateisystem in Ordnung wäre, -y um automatisch alle Fragen mit "ja" (yes) zu beantworten.

Auch dieser Prozess kann eine ganze Weile dauern. Als nächstes wird das - jetzt hoffentlich reparierte - Image (nicht die Netzfreigabe!) vom System abgemeldet:

hdiutil detach /dev/disk4s2

Theoretisch sollte das Image nun wieder für Time Machine verwendbar sein. Allerdings führt Time Machine selbst Buch über Probleme und behauptet deshalb meistens immer noch, dass das Image defekt sein (ohne es nochmal überprüft zu haben). Deshalb muss man das entspr. Flag in einer plist korrigieren. Dazu wechselt man in das RECHNERNAME.sparsebundle Verzeichnis und sucht die Datei com.apple.TimeMachine.MachineID.plist . Da es keine binäre plist Datei ist kann man sie mit vi oder einem anderen Editor bearbeiten ohne einen plist-Editor verwenden zu müssen.

Folgendes sucht man in der Datei:

<key>VerificationState</key><integer>2</integer>

Falls der Wert nicht auf "0" steht muss dieser angepasst werden:

<key>VerificationState</key><integer>0</integer>

Datei speichern und - fertig.

Beim nächsten Backup macht Time Machine einen Check das Images der diesmal ohne Fehler durchlaufen sollte. Und dann sollte auch den gewohnten Time Machine Sicherungen nichts mehr im Weg stehen.

Außer den anfänglichen Problemen - etwa unter iOS 3.0 - konnte das iPhone ab iOS Version 3.1 mit diesen Doppel-Karten ganz gut umgehen. Seit dem iPhone 4S und iOS 5 gibt es wieder Probleme: auf die Eingabe der PIN für die SIM Karte reagiert das iPhone nicht und die Abfrage bleibt hängen. Mit der Telekom TwinBill Karte war die Lösung relativ einfach - man musste die SIM Karte in ein nicht-iOS 5 Gerät stecken und die PIN Abfrage deaktivieren. Das dient zwar nicht der Sicherheit, man kann aber das Telefon immer noch durch die systemeigene Passwortabfrage schützen.

Bei Vodafones DuoBill sieht es leider etwas anders aus: offensichtlich lässt sich die PIN Eingabe nicht deaktivieren. So wie es aber aussieht besteht das Problem mit der PIN Eingabe der DuoBill Karte nur beim erstmaligen aktivieren des Geräts. Man muss also das Gerät mit einer beliebigen nicht Duo-Karte erstmalig aktivieren und danach kann man die DuoBill Karte einsetzen. Auch nach mehrmaligen Neustarts hat die PIN Eingabe dann immer geklappt - egal ob in die Business- oder private Seite.

Das Problem besteht im Übrigen nicht nur auf iOS Geräten - auch manche Android Handys haben Probleme mit diesen Karten. Laut Recherche im Web gilt auch hier: wenn es geht die PIN Abfrage in einem anderen Gerät deaktivieren.

Übrigens, als Tip: bei TwinBill (Telekom) wird eine 1 (geschäftlich) oder 2 (privat) der PIN voran gestellt (also etwa 11234 oder 21234), bei DuoBill (Vodafone) wird jeweils eine 01 oder 02 an die PIN angehängt (123401 bzw. 123402).

Aber wie dem auch sei, manchmal reicht ein Mac Mini Server. Den bekommt man auch - wie es sich für einen Server gehört - brav mit zwei Platten und vorinstalliertem OS X. Nur: die Platten sind nicht gespiegelt. Ich sehe ein, dass Apple es da keiner der beiden Fraktionen (unbedingt gespiegelte Platten auf einem Server vs, mehr Platz, mehr Platz) recht machen kann und deshalb halte ich mich mit dem Maulen zurück und gebe stattdessen einen Tip. Um mit OS X ein Software RAID1 zu erstellen muss man die auf der Boot Platte vorhandenen Daten gar nicht löschen.

Seit OS X 10.7 geht es sogar noch viel einfacher, da es die Recovery Boot Option gibt. Also erstmal den Mini (oder Pro) in die Recovery Instanz booten (CMD + R beim Einschalten). Dann das Terminal öffnen und sich einen Überblick verschaffen wie die Platten für das System sichtbar sind:

diskutil list

In der Regel sollte /dev/disk0 die Platte sein von der gebotet wurde bzw. die das bereits vorinstallierte OS enthält. Mit dieser Platte (Achtung, es muss nicht diese sein, siehe diskutil)

diskutil appleRAID enable mirror disk0s2

Man erzeugt also einen Mirror auf Platte 0 Slice 2 (auch hier: siehe diskutil list). Dies geht relativ flott. Man könnte jetzt auch gleich die zweite Platte dranhängen, aber da dieser Vorgang sehr lange dauert ist es empfehlenswerter den Server neu zu booten und ganz normal hoch fahren zu lassen. Man kann die zweite Platte auch im laufenden Betrieb an das RAID hängen. Also wie gesagt, reboot und dann im Terminal

diskutil checkRAID

Damit sieht man die Platten-ID die man zum weiteren Vorgehen benötigt (es ginge auch ohne die PlattenID, diese ist jedoch eindeutig und man macht keinen Fehler indem man eine falsche Platte erwischt)

diskutil listdiskutil appleRAID add member disk2 8125AD43-011E-4CB0-AA13-67462F57FC7C 

Mit dem diskutil list sucht man die Platte die noch nicht im RAID ist (im obigen Beispiel disk2) und fügt die dem Mirror hinzu. An dieser Stelle sei erwähnt, dass man die Platte als Ganzes angibt (also disk2 und nicht disk2s2). Der resultierende Mirror erstreckt sich dann auch über die Recovery Partition und nicht nur über die vom OS X verwendete Betriebssystem Partition.

Der Vorgang bei dem die zweite Platte gemirrored wird sollte nach Möglichkeit nicht unterbrochen werden. Das System selbst ist aber - von Geschwindigkeitseinbußen mal abgesehen - benutzbar und man kann damit arbeiten.

BTW: ich finde es immer wieder erstaunlich (und für mich angenehm) wie nah OS X an Solaris ist. Linux Admins tun sich an manchen Stellen vmtl. etwas schwerer.

Oracle hat ja (leider) ganz schön viel umgestellt, eingestellt und verschlimmbessert was die Informationen rund um Solaris betrifft. Als altgedienter Solaris Administrator wurde es zunehmend schwerer Informationen zu finden.

Eine meiner liebsten Anlaufstellen war sunsolve.sun.com - von hier kam man auf alle möglichen Informationen rund um Solaris und Sun Hardware. Diese gibt es in dieser Form nicht mehr. Und das Flash Gelump welches jetzt die Oracle Support Seite darstellt kann man wirklich keinem antun.

Mittlerweile gibt es aber von der doch immer noch regen Solaris Community Seite eine Anlaufstelle. Auf We Sun Solve versucht man so viele Informationen wie möglich zusammenzutragen und erste Anlaufstelle für den Solaris Sysadmin zu sein.

Eigentlich schade, wenn Oracle das nicht selbst auf die Reihe bekommt. Aber offensichtlich ist das bei Oracle ja Programm.

Das Problem tritt nur auf wenn der OpenDirectory Server anonyme binds verweigert bzw. wenn man authentifiziertes binding verwendet. Wenn ich das richtig verstanden habe versucht sich ein Lion Client immer per GSSAPI (und Kerberos) zu binden wenn der Server dies unterstützt. Beim klassischen Magic Triangle ist der OD Server selbst keine Kerberos Instanz und kann selbst nur (gegen die OD) Passwort authentifizierung (etwa CRAM-MD5). Man muss dem Server also abgewöhnen die GSSAPI zu verwenden.

Die Lösung ist ein Hack, der aber von Apple selbst so vorgeschlagen wird. Laut Apples Support Dokument TS3861 genügt es die Links auf die libgssapi zu löschen und den LDAP Server neu zu starten:

sudo rm /usr/lib/sasl2/openldap/libgssapiv2.2.sosudo rm /usr/lib/sasl2/openldap/libgssapiv2.la

Wie das Ganze mit 10.7 Server funktioniert konnte ich bisher noch nicht ausprobieren. So wie ich das aber sehe ist ein Lion Server immer auch Kerberos Server.

bzr:

in /usr/local/bin/bzr die erste Zeile von

#!/usr/bin/python

in

#!/usr/bin/python2.6

abändern

hg:

in /usr/local/bin/hg die Zeile

libdir = '../../platlib/Library/Python/2.6/site-packages/'

in

libdir = '/Library/Python/2.6/site-packages/'

abändern.

Git hingegen kann "einfach so" installiert werden.