Nach dieser Vorgabe  versuche ich nach besten Wissen und Gewissen auch meine Tochter zu einem eigenständig denkenden, intelligenten Menschen zu erziehen. Dazu gehört auch der Umstand ihr keinen Glauben aufzubürden für den sie sich nicht selbst aktiv und bewusst entscheiden konnte.

Und hier ergeben sich, zumindest im meinem persönlichen Umfeld, einige kleine Widerstände. So ist es für manche Familienmitglieder unverständlich das Kind nicht zur Kommunion zu schicken. Immerhin macht man das ja so, ohne fehlt ja irgendwas ohne das mir jemand sagen könnte was das wäre. Ja manche sprechen sogar davon das das Kind darunter leiden würde da alle anderen Kinder ja zur Kommunion gehen würde nur sie nicht.

Wie man sieht habe ich den ersten Fehler schon damit begonnen das Kind Taufen zu lassen und ihr die Römische Katholische Konfession eintragen zu lassen. Obwohl ich mich damals schon nicht der Katholischen Glaubensansicht zugeschrieben habe war sie eingetragene Konfession bei mir wie auch der bei Mutter. Wir beide bekamen sie von unseren Eltern wie diese von ihren Eltern usw. Diesen Kreislauf will ich durchbrechen. Als ich Alt und Reif genug war mir wirklich darüber Gedanken zu machen ob ich Gläubiger Katholik sein will entschied ich mich nicht an der Konfirmation teilzunehmen und schließlich im Erwachsenenalter auch aktiv aus der Glaubensgemeinschaft auszutreten.

Wenn mein Nachwuchs sich wirklich dazu entscheiden sollte, nachdem ich sie mit aufgeklärter Humanistischer Art und Weise aufgezogen habe, sie bräuchte eine Religion um ein besseres Leben zu leben soll sie unvorbelastet und bitte schön auch mit grösster Wahlfreiheit sich für eine Glaubensrichtung jeglicher Art entscheiden können. Aber bleiben wir Realistisch; wer er eine offene und aufgeklärte Erziehung genießt wird mit an grösster Sicherheit grenzender Wahrscheinlichkeit nichts in seinem Leben oder Gedankenwelt vermissen was ihm irgendeine Religion bieten könnte.

Mit der Version 2 brachte VMware dann ihren Mac Pendant Fusion mit offiziellen Support für die Virtualisierung von OS X 10.5 Server heraus. Jedoch beschränkt sich die Unterstützung auch lediglich auf die Server Variante, der Versuch die Client Version zu installieren wird nach einer Überprüfung abgebrochen.

Leopard Server ist ohne Frage ein wirklich tolles Betriebssystem aber für den Einsatz als Testumgebung innerhalb einer VM absolut überdimensioniert und mit dem Preisen ab 458,99 € für 10 Benutzer bis 929,00 € für eine unlimitierte Benutzerzahl für diesen Anwendungszweck auch nicht gerade günstig. Wer allerdings bereit ist die Apple Lizenz nicht ganz wörtlich zu nehmen kann mit ein paar Handgriffen dennoch die Client Version in Fusion installieren. Um zu wissen wie man das anstellt ist es ganz nützlich ein paar technische Details hierzu zu erfahren.

Als erstes interessiert uns natürlich die Art und Weise wie Fusion prüft ob das zur Installation benutze Medium eine Server oder Client Variante beherbergt. Hierzu schaut das Programm sowohl auf der Installations DVD als auch unter der späteren installierten Version nach ob die Datei ServerVersion.plist unter /System/Library/CoreServices/ existiert. Größe und Inhalt spielen dabei keine Rolle. Also können wir einfach von unserer Leopard DVD ein ISO Abbild erzeugen und selbiges mounten.

Mit dem Befehl touch “/Volumes/Mac OS X Install DVD/System/Library/CoreServices/ServerVersion.plist” erzeugen wir die benötigte Datei da wo sie hingehört. Nun das Image wieder unmounten und in Fusion als Installationsmedium angeben.

Jetzt müsste die Installation ohne Probleme durch schnurren, bevor wir jedoch in die frische Leopard Version booten können werden wir nochmals in das Installationsmedium booten und dort das Terminal ausführen. Hier erstellen wir die gleiche Datei auf dem eben installierte OS X: touch “/Volumes/Macintosh HD/System/Library/CoreServices/ServerVersion.plist” (Macintosh HD ggf. durch Name der Festplatte korrigieren)

Nun können wir uns über ein frisch installiertes Leopard freuen werden aber recht bald ein merkwürdiges Detail bemerken. Nicht nur Fusion denkt nun das er eine Server Variante ausführt sondern auch der Apple Software Updater. Er bietet nun die passenden Updates für diese Variante an mit denen wir natürlich nichts anfangen können. Dieses Fehlverhalten lässt sich zwar beheben indem wir die ServerVersion.plist löschen aber dann haben wir wieder den Salat mit dem Start der VM. Wir brauchen also die Datei bevor wir booten wollen sie aber löschen bevor wir uns einloggen. Ein Ausweg aus diesem Dilemma wäre es einen Daemon für launchd zu schreiben der uns diese Arbeit automatisiert abnimmt.

Erstellen wir also eine neue XML unter dem Pfad /Library/LaunchDaemons/me.giz.vmware.plist mit folgendem Inhalt:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN”
“http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>Label</key>
<string>com.rectalogic.vmware</string>
<key>ProgramArguments</key>
<array>
<string>/bin/bash</string>
<string>-c</string>
<string>/bin/rm -f /System/Library/CoreServices/ServerVersion.plist; trap “/usr/bin/touch /System/Library/CoreServices/ServerVersion.plist; exit” SIGINT SIGTERM SIGHUP; sleep 999999 &amp;amp; wait $!</string>
</array>
<key>KeepAlive</key>
<true/>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>

Mit sudo launchctl load /Library/LaunchDaemons/me.giz.vmware.plist registrieren wir die PLIST im LaunchDeamon. So wird nun dafür gesorgt das die Datei automatisch beim Login gelöscht und bei einem shutdown oder reboot neu angelegt wird. Ein wenig gefrickelt mag das schon wirken aber ich habe mir sagen lassen das dieses Vorgehen auch unter Parallels funktioniert.

Wer dem eigentlichen übel auf den Grund gehen will, nämlich der Überprüfung der Datei durch Fusion, dem zeige ich einen zweiten, etwas eleganteren Weg zum Ziel. Da sich ein Mac beim bootet vor allem durch ein EFI von den BIOS betriebenen PC’s unterscheidet setzt VMware, wenn es erkennt es soll ein OS X starten, einen speziellen Bootloader auf der Basis von Darwin ein. Mit der gleichen Methodik wie schon die Hacker vom OSX86project bzw. Insanelymac vorgehen wird hier dem Kernel die benötigten Informationen die normalerweise das EFI bereitstellt untergejubelt. Zusätzlich bindet VMware über eine RAM-Disk zwei Kernel Extensions ein die dafür sorgen das sich OS X in der virtuellen Umgebung wohl fühlt.

Dieser Bootloader befindet sich im Verzeichnis /Library/Application Support/VMware Fusion/isoimages/

Dumm ist nur das die ISO digital signiert ist, was bedeutet das jede Änderung sofort auffällt. Genial wiederum ist das die zur Überprüfung verwendete Signierung im selben Verzeichnis liegt. Das bedeutet das wir nachdem wir den Bootloader gepatcht haben einfach unser eigenes Zertifikat erstellen und sich VMware nicht beschweren kann. Unser Ziel ist nun die Überprüfung der ServerVersion.plist auf SystemVersion.plist ab zu ändern da diese Datei auf beiden Versionen vorkommt.

Mit den folgenden Befehlen sichern wir erst die Originaldateien, ersetzen die Vorkommen von ServerVersion.plist durch SystemVersion.plist und signieren die gepatche ISO mit unserem eigenen Schlüssel:

sudo bash
cd "/Library/Application Support/VMware Fusion/isoimages"
mkdir original
mv darwin.iso tools-key.pub *.sig original
perl -n -p -e "s/ServerVersion.plist/SystemVersion.plist/g"< original/darwin.iso > darwin.iso
openssl genrsa -out tools-priv.pem 2048
openssl rsa -in tools-priv.pem -pubout -out tools-key.pub
openssl dgst -sha1 -sign tools-priv.pem < darwin.iso > darwin.iso.sig
for A in *.iso ; do openssl dgst -sha1 -sign tools-priv.pem < $A > $A.sig ; done
exit

Nun sollte Fusion auch eine Leopard Client DVD installieren können ohne das man irgendwelche zusätzlichen Hacks anwendet. Hierbei muss man aber noch beachten das sich nur eine separat gekaufte Leopard Retail DVD eignet da die mitgelieferten Versionen speziell auf das beiliegende Gerät zugeschnitten sind und nicht mit der virtuellen Hardware zurecht kommt. VMware bezeichnet außerdem die Unterstützung von OS X als experimentell, so funktioniert z. B. die Soundausgabe nicht und auch der Versuch Dateien per Drag’n'Drop auszutauschen scheitert. Hier muss man auf die Gemeinsamen Ordner zurück greifen die man in Fusion aktivieren kann. Wer die Energiesparoptionen komplett ausschaltet vermeidet die Gefahr das das Gast-OS X gelegentlich einfrieren könnte.

Ansonsten verhält sich der Leopard vorzüglich in seinem virtuellen Käfig. Das Netzwerk funktioniert einwandfrei und Systemanimation laufen flüssig ab, selbst die offiziellen Updates werden tadellos eingespielt. Wer sein Fusion updatet und feststellt das OS X nicht mehr bootet muss eventuell den Patch erneut anwenden da unter Umständen der gepatchte Bootloader überschrieben wird.

Richtige Männer administrieren ihre IT doch komplett über einen Kommandozeileninterpreter. Sagt man doch so oder? Windows oder OS X sind doch nur Klicki-Bunti-Betriebssysteme, auch das hört man öfters. Okay die armen Windows User können einen mit ihrer schäbigen cmd.exe auch wirklich leid tun, darüber zu flamen käme dem Verhalten gleich einen umgekippten Rollstuhlfahrer mit ausgestrecktem Zeigefinger auszulachen und zusätzlich in die Seite zu treten. Bei OS X verhält man sich da schon ein wenig vorsichtiger, immerhin soll sich ja irgendwo unter der Aqua Oberfläche, ganz heimtückisch versteckt, ein UNIX befinden. Und das ist doch jetzt DAS Ding für echte Männer oder? Nun ja lassen wir das mal bei Seite, ein standardisierter Betriebssystemunterbau inklusive bewährten Shells/CLI/Kommandozeileninterpreter ist nicht die Glückseligkeit alleine. Selbst wenn sich jetzt im Falle eines OS X z. B. alle Aspekte des Betriebssystems über die Terminal.app bedienen lassen ist man dennoch darauf angewiesen das die Hersteller vom Fremdapplikationen ihre Programme komplett darauf auslegen über eine Shell bedienbar zu sein. Um zu verdeutlichen was ich damit meine werde ich in dem folgenden Abschnitt zeigen wie man ein Gastbetriebssystem in VirtualBox über eine entfernte SSH Verbindung einrichtet um es anschließend per RDP über den lokalen Bildschirm zu installieren.

Nehmen wir also mal an wir haben ein entfernten OS X Rechner auf dem wir VirtualBox installieren wollen. Nehmen wir weiter an das auf dem entfernten Rechner der SSH Server läuft, ansonsten hat jemand verpennt unter den Systemeinstellungen/Sharing/Entfernte Anmeldung das Häkchen zu setzen. Nehmen wir auch an das wir das passende DMG schon auf unserer lokalen Platte liegen haben. Kopieren wir es also von unserem lokalen Rechner auf den entfernten. Um das zu schaffen muss man nichtmal ein richtiger Kerl sein sondern nur entscheiden wie man(n)s macht.

Per SCP z. B.: scp VirtualBox-2-1.0.4-38406-OSX_x86.dmg username@adresse_remote:/path/to/woauchimmer
Oder wie wäre es mit Kanonen auf Spatzen zu schiessen und die knappen 40MB per rsync rüber zu schaufeln, dann können wir im Falle eines Netzwerk Interrupts den abgebrochenen Transfer wieder aufnehmen und haben eine schicke menschenlesbare Progressanzeige: rsync -Ph VirtualBox-2-1.0.4-38406-OSX_x86.dmg username@adresse_remote:/path/to/woauchimmer

Loggen wir uns nun per SSH auf den entfernten Rechner ein: ssh username@adresse_remote und mounten das DMG Image. Dabei hat man(n) schon wieder Möglichkeiten wie er es anstellen könnte z. B. hdiutil mount VirtualBox-2-1.0.4-38406-OSX_x86.dmg oder ein schlichtes open VirtualBox-2-1.0.4-38406-OSX_x86.dmg.

In den meisten Fällen sind OS X Applikationen so genannte Bundles die man nur ins Applikationsverzeichnis kopieren muss um sie zu installieren, VirtualBox ist jedoch eine Software die in gewissen Stellen des Betriebssystems Änderungen vornehmen muss um zu funktionieren, daher kommt es mit einem spezielleren Paket welches über einen Installer ins System integriert werden muss. Unter dem Pfad /Volumes/VirtualBox/ finden wir dieses VirtualBox.mpkg Paket welches wir mit sudo installer -pkg /Volumes/VirtualBox/VirtualBox.mpkg/ -target / wirklich schnell und unkompliziert installiert haben. Die Virtualisierungssoftware hätten wir nun, Ordnungsfetischisten unmounten bestimmt nun die DMG sofort wieder und wissen das hdiutil unmount /Volumes/VirtualBox/ genau jenes bewirkt. Brauchen wir also nur noch ein Betriebsystem das wir in diese VM installieren wollen. Da wir ja uns schon drauf geeinigt haben das UNIX genau das richtige für das starke Geschlecht ist hab ich mich für das neben Darwin einzige Open Source UNIX entschieden – OpenSolaris. Darwin läuft ja schon auf dem Hostbetriebssystem, Matryoshka Puppen sind da nicht so mein Ding, und im Falle von OpenSolaris und VirtualBox kommt sogar beides aus dem gleichen Hause, Sun. Beschaffen wir uns also ein ISO Abbild der OpenSolaris Distribution: curl -O http://www.genunix.org/distributions/indiana/osol-0811-100a.iso z. B. bannt eine zum Zeitpunkt der Erstellung dieses Textes brandaktuelle Pre-Release Version der 2008.11er Version auf die Platte.

Nachdem wir diese Vorbereitungen abgeschlossen haben können wir endlich zum Grundthema zurück kommen und uns freuen das die meisten grossen Virtualisierungsspezialisten trotz einer schicken klickbaren Oberfläche nicht vergessen haben Kommandozeilentools mitzuliefern. Legen wir eine neue virtuelle Maschine an und registrieren sie:
VBoxManage createvm -name “OpenSolaris” -register

Passen wir ein paar Parameter für das Gastsystem an:
VBoxManage modifyvm “OpenSolaris” -memory “512MB” -acpi on -boot1 dvd -nic1 nat

Dann legen wir eine virtuelle Festplatte an:
VBoxManage createvdi -filename “osol.vdi” -size 8000 -register

Und definieren sie als erste virtuelle Festplatte:
VBoxManage modifyvm “OpenSolaris” -hda “osol.vdi”

Danach werden wir das eben heruntergelade ISO File registrieren:
VBoxManage registerimage dvd /Path/to/osol-0811-100a.iso

Und als Boot Medium konfigurieren:
VBoxManage modifyvm “OpenSolaris” -dvd /Path/to/osol-0811-100a.iso

Damit wir nun von unserem lokalen Rechner aus die Installation starten und überwachen können nutzen wir aus das VirtualBox einen eingebauten RDP Server besitzt und starten die virtuelle Maschine mit VBoxVRDP -startvm “OpenSolaris”. Ab diesen Augenblick kann man mit einem beliebigen RDP Client auf die Adresse des Remote Rechners zugreifen und das machen was Männer halt so machen. Zum Beispiel neben der OpenSolaris Installation die Dokumentation der VirtualBox lesen um heraus zu finden wie man verflixt noch mal ein Kennwort für den RDP Server setzt weil man sich schon gewundert hat das man(n) ohne Anmeldungsdaten drauf verbinden konnte.

• XNU – Kernel von OS X
• launchd – Ersatz für cron.d, init.d, inet.d uvm.
• MacPorts – Paketmanager
• Webkit – HTML-Render-Bibliothek

Eine Liste über die sonstigen Open Source Komponenten von OS X 10.5 findet ihr auf Darwin Source Code.