I ran into a problem today: Some programs (and nearly all games) in OS X do not run of a case sensitive filesystem.
Coming from Linux to Mac, this is incomprehensible to me. Thats why I formated all my stuff case sensitive. Keeping my moral high ground an not use Steam was sadly out of the question, so I needed a solution.
Introducing iPartition!
With this tool it took me 10 minutes to do the change. It can't change the type on the disk with the system folder, thats why I needed an USB to SATA Adapter to connect my disk to another Mac. But then it worked flawlessly.
Awesome! =D
Dienstag, 7. Mai 2013
Sonntag, 17. März 2013
Githubs Boxen
Github released their install system for MacOS 'Boxen'.
Its really awesome and I will try and brng it into our stack at Lusini.
http://boxen.github.com/
Mittwoch, 28. November 2012
Spotlight failing on 10.8.2 (and how to repair that)
After updating my MBP15 to 10.8.2 it started constantly running on 100% CPU. Who needs QA anyway, right Apple?
A quick look into top revealed constantly respawing 'mdworker' threads, process number where already close to 100k.
Console revealed that fact even more, with 50+ messages streaming by every second. 'mdworker' was crashing and immediately respawned by launchd. The crash reports cycled so fast, I needed to do a screen shot to read it:
Ok, the first thing I did is stop spotlight from indexing, and resetting the index:
In the terminal:
sudo mdutil -a -i off
sudo mdutil -E
I put the whole HDD in the privacy tab in the spotlight prefs for good measure. After rebooting the log storm was gone, but Spotlight obviously as well.
I didn't really know I had so much stuff in my application folder, being used to Spotlight. I found myself screaming in frustration, navigating hierarchically (wow, google spell checking rocks, I entered 'hirachicly' ^^;) though all this crap.
Anyway, I googled around, tried a few fixes and finally found a solution here. In post #60 phobox explains that the errors stemms from the ML sandbox (or failbox as it will come to be known) blocking mdworker from indexing.
The solution:
Append the following to /System/Library/Sandbox/Profiles/system.sb
;;; Spotlight fixes (allow mach-lookup (global-name "com.apple.ls.boxd")) (allow mach-lookup (local-name "com.apple.ls.boxd"))
And then did a safeboot to clean up permissions (hold shift key at startup, you will see a progress bar).
Huzza, my spotlight works again! I can again close the lid at the mess in the folders, and just start the app I want to start. ^___^
A quick look into top revealed constantly respawing 'mdworker' threads, process number where already close to 100k.
Console revealed that fact even more, with 50+ messages streaming by every second. 'mdworker' was crashing and immediately respawned by launchd. The crash reports cycled so fast, I needed to do a screen shot to read it:
Ok, the first thing I did is stop spotlight from indexing, and resetting the index:
In the terminal:
sudo mdutil -a -i off
sudo mdutil -E
I put the whole HDD in the privacy tab in the spotlight prefs for good measure. After rebooting the log storm was gone, but Spotlight obviously as well.
I didn't really know I had so much stuff in my application folder, being used to Spotlight. I found myself screaming in frustration, navigating hierarchically (wow, google spell checking rocks, I entered 'hirachicly' ^^;) though all this crap.
Anyway, I googled around, tried a few fixes and finally found a solution here. In post #60 phobox explains that the errors stemms from the ML sandbox (or failbox as it will come to be known) blocking mdworker from indexing.
The solution:
Append the following to /System/Library/Sandbox/Profiles/system.sb
;;; Spotlight fixes (allow mach-lookup (global-name "com.apple.ls.boxd")) (allow mach-lookup (local-name "com.apple.ls.boxd"))
Watch what your doing, by deleting, overwriting or generally messing in this file you can lock yourself out of the OS.
In true try-all-fixes-at-once-so-that-you-do-not-know-what-helped thoughtlessness, I cleaned my caching folder as well
sudo rm -r /System/Library/Caches/*
And then did a safeboot to clean up permissions (hold shift key at startup, you will see a progress bar).
Huzza, my spotlight works again! I can again close the lid at the mess in the folders, and just start the app I want to start. ^___^
Dienstag, 2. Oktober 2012
Numlock in Mac:Office 2011
Just a small hint for Excel 2011:
If your keypad does not work as number pad anymore (like, printing numbers when pressing keys), but moves your sheet around, try pressing Numlock.
There is no numlock in MacOS you say?
Right, but there is one in Mac Office! Press Shift + Clear (Thats the key between 7 and F16 on your keypad). You will get no reaction whatsoever, but you should now be able to enter numbers again. Thanks for consistency Microsoft.
If your keypad does not work as number pad anymore (like, printing numbers when pressing keys), but moves your sheet around, try pressing Numlock.
There is no numlock in MacOS you say?
Right, but there is one in Mac Office! Press Shift + Clear (Thats the key between 7 and F16 on your keypad). You will get no reaction whatsoever, but you should now be able to enter numbers again. Thanks for consistency Microsoft.
Montag, 1. Oktober 2012
A small truth about Open Directory passwords...
We had a problem today, which gave me some insight in the way OD handles its passwords.
I created a new user in OD and, being based in Munich, made an Oktoberfest induced error.
(At least that's my excuse...)
I deleted the value of "Authenticaton Authority" in the Inspector window in the user account. I tried to fix that by copying over that attribute from another user. Seems to work, everything fine.
After a while, the user from which I copied the attribute showed up and complained that his password suddenly seemed to be invalid. Hmm.
Maybe just a coincidence? I changed his password, seems to work, everything fine. Back the the headache.
Shortly after, the new user showed up, her password was broken now!
Ok, time for some research...
The open directory does not save the passwords in the ldap tree (as hash, hidden field, etc...) . Instead is utilises a secondary password service (kerberos) which holds and manages the password. The link to this password is established by the "Authentification Authority" field in the OD. It contains an ID that references the password in the service.
Copying the hash from one user to the next gave both users the same entry, and thus the same, linked password. The problem was solved as I deleted the complete entry "Authentification Authority" of the new user, and changed the password. The OD created a new entry in the ldap and the password service, and it really worked, finally everything fine.
...don't drink and root. ^_^
<edit>
A college found this on the web:
http://flylib.com/books/en/4.395.1.68/1/
It explains the relation beween LDAP, Kerberos and the Apple password service in detail. Interesting stuff.
It's from 2005 but seems to be correct in most regards. One thing that seems to be deprecated is the note that the change of a users password with kpasswd does not change the password in the Apple password service. Tried it, it does. (SL Server, ML Client)
________
Appendix:
Get the Last modification stamp of the users password (on the OD host):
sudo kadmin.local -q 'getprinc user@DOMAIN.COM'
I created a new user in OD and, being based in Munich, made an Oktoberfest induced error.
(At least that's my excuse...)
I deleted the value of "Authenticaton Authority" in the Inspector window in the user account. I tried to fix that by copying over that attribute from another user. Seems to work, everything fine.
After a while, the user from which I copied the attribute showed up and complained that his password suddenly seemed to be invalid. Hmm.
Maybe just a coincidence? I changed his password, seems to work, everything fine. Back the the headache.
Shortly after, the new user showed up, her password was broken now!
Ok, time for some research...
The open directory does not save the passwords in the ldap tree (as hash, hidden field, etc...) . Instead is utilises a secondary password service (kerberos) which holds and manages the password. The link to this password is established by the "Authentification Authority" field in the OD. It contains an ID that references the password in the service.
Copying the hash from one user to the next gave both users the same entry, and thus the same, linked password. The problem was solved as I deleted the complete entry "Authentification Authority" of the new user, and changed the password. The OD created a new entry in the ldap and the password service, and it really worked, finally everything fine.
...don't drink and root. ^_^
<edit>
A college found this on the web:
http://flylib.com/books/en/4.395.1.68/1/
It explains the relation beween LDAP, Kerberos and the Apple password service in detail. Interesting stuff.
It's from 2005 but seems to be correct in most regards. One thing that seems to be deprecated is the note that the change of a users password with kpasswd does not change the password in the Apple password service. Tried it, it does. (SL Server, ML Client)
________
Appendix:
Get the Last modification stamp of the users password (on the OD host):
sudo kadmin.local -q 'getprinc user@DOMAIN.COM'
Donnerstag, 2. August 2012
New shell commands in Mountain Lion
Just a quick link to a useful post from patrix:
http://apple.blogoverflow.com/2012/07/interesting-new-unix-commandsbinaries-in-os-x-mountain-lion/
There is some cool new stuff under the hood. =)
http://apple.blogoverflow.com/2012/07/interesting-new-unix-commandsbinaries-in-os-x-mountain-lion/
There is some cool new stuff under the hood. =)
Samstag, 28. Juli 2012
Recovering a locked down system with broken mobile user
Yesterday I set up a brand new MBA13''. Nice, but I prefer the MBPwRD for the same money.
As usual I created an local admin account to access the system if anything goes wrong. The user account was an mobile user for obvious reasons. Both users had access to the filevault2.
I gave the system to the user for data migration, task done.
Today I got it back with the trademark words "It Just Broke, I Did Nothing". First thing I noticed as I switched the thing on, no local admin account. And guest access was activated. Huh?
Logging in with the users password started the system, but dumped me to the normal login screen where only the guest user was visible and the "more..." button for other (normally network) accounts.
Trying to sign in with the "more..." button yielded nothing, so off to start from the recovery partition.
First bump: filevault2 encrypts the whole disk, how do I start the Recovery?
Quick Google: holding cmd-R works, even if the Recovery partition is not listed on the alt boot menue.
I still could enable the filevault2 partition with the old user password.
I tried to reset the password of the user with resetpassword (See blog post in Febuary) but it did not work. Well duh, it's a mobile user, of cause it does not work. The local admin stayed gone.
Well then, of to single user mode! (cmd-s at startup)
First, I fixed the file permissions like this:
> /sbin/fsck/ -fy
A look into the /Users directory showed the local admin account as deleted. Well, someone did something...
Ok, the user account was somehow borked, the local user was gone... what to do?
Easy:
(in single user mode)
> mount -uw /
> rm /var/db/.AppleSetupDone
> reboot
After the reboot, the fresh installation assistent greets you, wants to register your device, show you how to natural scroll and creates a user with admin rights!
I took a gamble and gave it the same name and credentials als the deleted local admin account, and it worked like a charm.
Ok, after the system was accessible, the thing that caused all this was obvious:
The "Allow network users to log in at login window" login option was deactivated. Well durr, good lock signing in Mr Mobile User. Together with the deleted local admin account this was, well, stupid.
At least I can now be sure that the local admin stayes on the system, that my colleges got a good laugh and I a blog post out of it. =)
As usual I created an local admin account to access the system if anything goes wrong. The user account was an mobile user for obvious reasons. Both users had access to the filevault2.
I gave the system to the user for data migration, task done.
Today I got it back with the trademark words "It Just Broke, I Did Nothing". First thing I noticed as I switched the thing on, no local admin account. And guest access was activated. Huh?
Logging in with the users password started the system, but dumped me to the normal login screen where only the guest user was visible and the "more..." button for other (normally network) accounts.
Trying to sign in with the "more..." button yielded nothing, so off to start from the recovery partition.
First bump: filevault2 encrypts the whole disk, how do I start the Recovery?
Quick Google: holding cmd-R works, even if the Recovery partition is not listed on the alt boot menue.
I still could enable the filevault2 partition with the old user password.
I tried to reset the password of the user with resetpassword (See blog post in Febuary) but it did not work. Well duh, it's a mobile user, of cause it does not work. The local admin stayed gone.
Well then, of to single user mode! (cmd-s at startup)
First, I fixed the file permissions like this:
> /sbin/fsck/ -fy
A look into the /Users directory showed the local admin account as deleted. Well, someone did something...
Ok, the user account was somehow borked, the local user was gone... what to do?
Easy:
(in single user mode)
> mount -uw /
> rm /var/db/.AppleSetupDone
> reboot
After the reboot, the fresh installation assistent greets you, wants to register your device, show you how to natural scroll and creates a user with admin rights!
I took a gamble and gave it the same name and credentials als the deleted local admin account, and it worked like a charm.
Ok, after the system was accessible, the thing that caused all this was obvious:
The "Allow network users to log in at login window" login option was deactivated. Well durr, good lock signing in Mr Mobile User. Together with the deleted local admin account this was, well, stupid.
At least I can now be sure that the local admin stayes on the system, that my colleges got a good laugh and I a blog post out of it. =)
Abonnieren
Posts (Atom)