Every mac user knows dashboard.
'Isn't that the stupid nearly empty page with the weather on top that comes up when I switch workspaces the wrong way round?'
Yes avatar of all annoying users, it is.
'Disable it!'
No, it can not be done.
...
Mavericks: But it can!
On the shell:
'defaults write com.apple.dashboard mcx-disabled -boolean true'
Restart & done!
'Thank you, now make my battery last 20 hours!'
Dienstag, 12. November 2013
Donnerstag, 7. November 2013
Kerberos Auth broken AGAIN (and works again)!
Long time no post, but with Mavericks, new challenges arise.
Obviously two users installed it even before I got a chance to read what had changed - Apple's gotta love the adoption rate (Mavericks being free and all). But it went fine, nothing big broke.
Our kerberos enabled Mercurial broke because the installer empties the whole python 2.7 site-packages folder (why ever! I belive this will produce lots of 'fun' for admins), but that was easily fixed and only hampered the devs (which now use git anyway).
The other fallout was the breaking of the Authentification Server Whitelist of Chrome. So none of our internal Web pages were accessible over chrome, forcing users to use the shiny new Safari. This happend before. And I fixed it before. And I fixed it again. =)
Interestingly, I just needed to reverse the changes made the last time it broke, namely reintegrating MCX setting into the main user group. It seems MCX inheritance over groups is now broken.
Huzza Apple, once again your own enterprise features are the least tested features!
Why not be consequent and kick out this token open directory once and for all? At least I would be finally forced to migrate to Active Directory and could stop wondering if this other, MS flavoured pain would be nicer than the bleak, dead landscape of mac server with its layers of broken bones of cats past, yellowed documentation printed on papyrus and fading ghosts of forgotten visions.
Obviously two users installed it even before I got a chance to read what had changed - Apple's gotta love the adoption rate (Mavericks being free and all). But it went fine, nothing big broke.
Our kerberos enabled Mercurial broke because the installer empties the whole python 2.7 site-packages folder (why ever! I belive this will produce lots of 'fun' for admins), but that was easily fixed and only hampered the devs (which now use git anyway).
The other fallout was the breaking of the Authentification Server Whitelist of Chrome. So none of our internal Web pages were accessible over chrome, forcing users to use the shiny new Safari. This happend before. And I fixed it before. And I fixed it again. =)
Interestingly, I just needed to reverse the changes made the last time it broke, namely reintegrating MCX setting into the main user group. It seems MCX inheritance over groups is now broken.
Huzza Apple, once again your own enterprise features are the least tested features!
Why not be consequent and kick out this token open directory once and for all? At least I would be finally forced to migrate to Active Directory and could stop wondering if this other, MS flavoured pain would be nicer than the bleak, dead landscape of mac server with its layers of broken bones of cats past, yellowed documentation printed on papyrus and fading ghosts of forgotten visions.
Dienstag, 7. Mai 2013
Turning insensitive.
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 and 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
Coming from Linux to Mac, this is incomprehensible to me. Thats why I formated all my stuff case sensitive. Keeping my moral high ground and 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
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'
Abonnieren
Posts (Atom)