Grobator's Bloggomat

…gibt’s u.a. auch schon mit Bordmitteln (wenn auch ohne GUI).

Hier gehts zu den Artikeln:

• http://www.wlanbook.com/mac-os-x-wifi-wireless-scanner/
• http://www.wlanbook.com/netstumbler-mac-os-x/

Puuh, Sch*** gehabt.
In letzter Verzweifelung wurde der Login mit “root” versucht, und mit diesem hat die lokale Anmeldung geklappt.
Daher hier die Warnung an alle…. Finger weg von dieser Option, es könnte sonst das letzte sein, was ihr von der grafischen Oberfläche zu sehen bekommt.

Also rechtzeitig den root-User aktivieren:

• http://www.macfix.de/index.php?mode=thread&id=147274

Kommandozeile im Terminal

/System/Library/CoreServices/Directory\ Utility.app/Contents/MacOS/Directory\ Utility

Beim Finetuning eines Mac OS X Server 10.6 (Snow Leopard) ist mir ein Lapsus unterlaufen. Bei der Einrichtung der User im Open Directory mir offensichtlich ein Missgeschick passiert.

Nach einem Reboot ist es nun nicht mehr möglich sich lokal anzumelden.

Login via SSH funktioniert jedoch problemlos.

Die Standard Services funktionieren ebenso.

• Apache
• WebDAV
• etc.

Lediglich beim Versuch sich lokal anzumelden wird in “/var/log/sercue.log” wie folgt quittiert:

Dec 12 11:28:22 macserver SecurityAgent[180]: Could not get the user record for 'xyz' from Directory Services
Dec 12 11:28:22 macserver SecurityAgent[180]: User info context values set for xyz
Dec 12 11:28:22 macserver SecurityAgent[180]: unknown-user (xyz) login attempt PASSED for auditing

Kennt irgend jemand den Grund für diesen Effekt, bzw. eine Möglichkeit, die lokale Anmeldung wiederherzustellen?

Trotz tagelanger Suchen und Recherchen bin ich bislang noch nicht fündig geworden.

Der Server schüttelt sich beim Versuch sich lokal anzumelden.

In dem Artikel habe ich ausführlich beschrieben, wie man vorhandenen freien Plattenplatz im LAN zum TimeMachine-Backup nutzen kann. Mit dem Snow Leopard Update auf 10.6.2 Build 10C540 funktionierte dieses Verfahren plötzlich nicht mehr. Durch Gespräche mit anderen Mapple-Usern erfuhr ich, dass dieses flächendeckend auftritt. Ein Zugriff auf das Sparsebundle klappt nicht mehr, nach ewig langen Verbindungsversuchen erschienen die freundliche Meldung: “…konnte nicht erstellt werden (Fehler 45)”.

Was war geschehen?

Durch Bugfixes an der TimeMachine Software und aber auch an der Schlüsselbundverwaltung ist es offensichtlich zu einer Inkompatibilität gekommen, weshalb das Mounten des Sparsebundles fehlschlägt.

Wie bin ich der Sache auf den Grund gekommen?

• Die TimeMachine Aktivität via Terminal verfolgt mit:

   tail -f /var/log/system.log

• Ein neues Sparsebundle erstellt, wie ich es hier beschrieben habe.
• Alle TimeMachine Schlüssel in der Schlüsselbundverwaltung gelöscht.
• Das Sparsebundle auf das NAS kopieren und einfach alles jungfräulich aufsetzen
• Evtl. besteht auch die Möglichkeit, das Backups.db Verzeichnis des alten Sparsebundles in das neue zu kopieren.
  Darauf habe ich jedoch verzichtet, und mich lieber von den Altlasten getrennt.

Weiterführende Infos zu TimeMachine Troubleshooting:

• http://discussions.apple.com/thread.jspa?threadID=2057525

Zu den Zeichen, die am Computer am besten eine komplett eigene Taste verdienen, gehört eindeutig der Backslash ” \ “. Aus mir unbekannten Gründen werden dieses Zeichen in der “normalen” Mac Oberfläche nicht nur mit einer 2-fachen, sondern sogar mit einer 3-fachen Tastenkombination versteckt.

 < shift >  +  < alt > + < 7 >

In der VMFusion (also im Windows) ist der Backslash erreichbar mit:

< alt > + < ? >

(Hier empfiehlt sich die rechte Alt-Taste, weil sie “näher dran” ist)

Durch Zufall habe ich gerade herausgefunden, dass der Terminal für den Backslash zusätzlich zur erstgenannten Kombination die bislang komfortabelste Kombinaton kann:

< alt > + < y >

(Empfehlung hier: linke Alt-Taste)
Warum geht das nicht durchgängig auf dem Mac (inklusive VMFusion)  so?