Ausgangssituation:
- Altes MacBook mit FileVault
- Neues MacBook Pro mit Migration Assistant

Ich habe angefangen mit dem Weg, den die meisten gehen würden.

Also MacBook Pro ausgepackt und im Setup gesagt, das ich die Daten von meinem alten Mac übertragen möchte.
Dazu den Migration Assistant auf dem alten Mac gestartet und losgelegt.

Das kopieren ging über das GBit Netzwerk auch recht flott, trotz über 60 GB Daten

Nach ca. 1 1/2 Stunden war er fertig und ich habe schon mit dem Gedanken gespielt die alte Platte gleich mal zu wipen
Vorsichtshalber habe ich dann doch erst versucht mich auf dem neuen Mac anzumelden und das hat sich als rettend erwiesen…

Beim Login wurde mein Passwort akzeptiert, allerdings schlug der Login dann fehl mit einer Meldung, das mein FileVault derzeit nicht zur Verfügung steht.

Deswegen habe ich gleich mal die MacOS DVD reingeschmissen und mit dem Terminal das /Users Verzeichnis durchforstet.
Ein ls -la hat dann schnell gezeigt, das mein .$user Order nicht existiert, wo normalerweise das FileVault Image drinliegt.

Dafür hatte ich ein ganz normales $user Verzeichnis mit allen Daten – unverschlüsselt.

Über google habe ich gelesen, das die meisten User in diesem Fall empfehlen auf dem alten Mac erst FileVault zu deaktivieren und dann alles noch mal kopieren…
Aber mein ergeiz lies das nicht zu! Ich wollte herausfinden, woher mein Login weiß, das ich FileVault benutze. Irgendwo muss sich ja das Flag für FileVault finden lassen!

Dann ging sie suche los…

Nachdem die Apple Hotline nicht erreichbar war, habe ich mich erstmal selbst auf die Suche gemacht.
Nach diversen Fehlschlägen bin ich über das Tool dscl gestolpert mit dem man unter MacOS den DirectoryService mit den Usern verwalten kann. (Es gibt war z.B. eine /etc/passwd, aber die benutzt MacOS nicht…)

Von dscl war ich anfangs nicht überzeugt, da ich weder von der DVD aus, noch im Single User Mode irgendwas damit machen konnte.
Allerdings stand in der Help dazu, der Hinweis der das Problem letzendlich lösen würde – dort habe ich den Pfad gefunden zu den User Account plist Files!

Ich war die ganze Zeit auf der Suche nach dem Verzeichnis mit den User Account Infos von MacOS, die befinden sich aber weder unter /Library, noch unter /System!
Stattdessen sollte man mal unter /var nachsehen

Genauergesagt: /var/db/dslocal/nodes/Default

Wenn man eine root Shell hat (entweder von der DVD oder im Single User Mode), kann man in den Default Ordner rein.
Darin befindet sich ein Ordner users, der alle vorhandenen Benutzer beinhaltet.

Der neugier halber habe ich mir dann mal mein users/$user.plist File angeschaut – ist zum Glück XML

Darin befinden sich die ganzen Standard Infos wie Passwort, UID und so.
Außerdem 2 für mich sehr interessante Keys: home und home_loc (beispiel)

Bei einem Kollegen auf dem Mac habe ich dann kurz sein entsprechendes PList File angeschaut und da er FileVault disabled hat gibt es bei ihm nur den Key home.

Rein zum Testen habe ich dann den key home_loc gelöscht und mal einen Reboot gewart – hab ja nix zu verlieren
Und voila, schon kann ich mich wieder einloggen und in den System Preferences war FileVault ausgeschaltet.

Fassen wir mal zusammen:

Wenn man einen unverschlüsselten Home Ordner hat, aber der Mac darauf besteht das du ja FileVault hast mache folgendes:

- Gehe mit Apfel + S während dem Booten in den SingleUser Mode.
- vi /var/db/dslocal/nodes/Default/users/$user.plist
- lösche den key home_loc
- reboot

Und schon hat man FileVault disabled und man kann sich wieder einloggen!
In den System Preferences kann man es auch bequem wieder einschalten und er fängt an zu verschlüsseln

Viel Spaß damit!

Durch meinen (neuen) Job bei den lokalisten komme ich leider du nicht mehr viel. Deshalb und aufgrund fehlender Motivation ist hier so lange nichts mehr passiert und ich glaube auch nicht, das in nächster Zeit sehr viel mehr passieren wird.

Wer mitverfolgen will, was ich so treibe kann das über Twitter machen. Da gibts ziemlich oft Infos was ich so mach und was mich bewegt.

Tja, ansonsten hab ich dem WordPress mal ein neues Theme gegönnt und die Kategorien ein wenig aufgeräumt.
Ich räume jetzt noch ein wenig die Blogroll auf und ansonsten wars das schon wieder von mir.

Wie gesagt, aktuelles Zeug gibts auf Twitter.

Bis dann…

Durch Zufall bin ich eben durch Google auf eine sehr schöne Implementierung bei Javangelist gestoßen:

<!-- break arbeitet nur mit n -->
<xsl:template name="break">
<xsl:param name="text" select="."/>
<xsl:choose>
<xsl:when test="contains($text, '&#x0D;')">
<xsl:if test="string-length(substring-before($text, '&#x0D;')) > 0">
<xsl:value-of select="substring-before($text, '&#x0D;')"/>
</xsl:if>
<br/>
<xsl:call-template name="break">
<xsl:with-param name="text" select="substring-after($text,'&#x0D;')"/>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:if test="string-length($text) > 0">
<xsl:value-of select="$text"/>
</xsl:if>
</xsl:otherwise>
</xsl:choose>
</xsl:template>


Das kann man sehr schön steuern und verwenden:

<xsl:call-template name="break">
<xsl:with-param name="text" select="detail[@name = 'comment']" />
</xsl:call-template>


Und schon wirds schön formatiert wie mit nl2br

Edit: Irgendwie is beim Kopieren in WordPress was schief gelaufen, probierts lieber mit 
 statt ”

Das funktionierte komischerweise auch, allerdings nur mit 777 Rechten.
Während dem Schreiben von diesem Blog Eintrag ist mir dann aufgefallen das ich es noch nie mit php_admin_value upload_tmp_dir "/tmp" getestet hatte.
Dies funktionierte sogar, obwohl vorhergehenden Fehlermeldungen auf das Gegenteil hindeuteten: Unknown: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/var/kunden/webs/<kunde>/:/tmp/) in Unknown on line 0

Die Lösung ist also einfach folgende:
php_admin_value upload_tmp_dir "/tmp" im SysCP unter “Eigene vHost-Einstellungen” in den Eigenschaften einzelner Domains einzutragen.
Da dies unhandlich ist werd ich morgen mal probieren ob ich das in die php.ini eintragen kann, bzw ob es dann den gleichen Effekt hat.