Extracting tarballs is something that most unix/linux admins do autonomously. We work like that with most of our cli tools because it makes us more efficient when we think more about what we’re doing than how we want to make the tool(s) do it. But when we want to have the tool do something that isn’t habit, it feels a bit like Windows users feel when they try to close an app on OS X by moving their mouse over the top-right corner of the window only to realize the close button isn’t there.
No, it’s actually not a file, it’s a directory. At least it’s supposed to be. But, multiple reports from multiple lab maintainers had been coming in that included error messages from applications which were trying and failing to access the user’s keychain store. I started troubleshooting by repairing the keychain with /Applications/Utilities/Keychain Access.app, but that did nothing aside from provide more of the same error messages. I suspected keychain corruption or possibly mucked up permissions, so I opened Terminal to take a look. ~/Library/Keychains was a file!
It took me a while to figure this one out, and now that I know what it was, I’m admittedly a little embarrassed. This is one for #macadminshame. For the machines I maintain directly, I manage the user environment with Local MCX. That’s not a technology that my lab maintainers are comfortable with; they’d much rather login using a special account, make their changes, and then rest comfortably knowing that those changes would be present for everyone who logged into their lab machines. I get that – we all have better things to do than learn about complex technologies that we’ll use less than 3 times annually. So I wrote a logout hook for them that ran when this special account logged out. The script empties the trash, clears caches and logs; generally cleans up the home directory for that account. Once cleaned, it bundles that home directory up in an installer package which I then import into Munki and deploy to the rest of their lab machines for them.
Of all the cleanup tasks that I had been doing, one very important one had slipped right by; ~/Library/Containers/. If you happen to update your Non_localized.lproj, English.lproj, .lproj directory like this (which isn’t recommended), please be sure to purge the contents of ~/Library/Containers.
I didn’t bother trying to figure out which container was touching ~/Library/Keychains because once I realized my error, I knew everything in there needed to go anyway. Moral of the story: Profiles/MCX is the way to go, but if you can’t, make sure you’re not putting anything in /System/Library/User\ Template/.lproj/Library/Containers/.
Also, if you find yourself already in this scenario (hopefully I’m the only one who will), you can fix existing home directories by deleting ~/Library/Keychains (as long as it’s a file, not a directory!) before the user’s next login.
Updated Nov 18, 2013 – updated for Ubuntu 13.10 and Apache 2.4; including suggestions from Brandon Kerns, submitted in the comments. Thanks Brandon!
Lots of web apps are starting to switch from PHP to Python for the backend, and with good reason, but one thing that’s always bothered me is how many people don’t run their Python apps in Apache. Most people find it easier to run these web apps using a development-grade server such as the stand-alone WSGI server commonly used in Django or Flask projects. Generally, this comes with the follow-up task of making sure the web app’s WSGI instance will automatically launch on boot. Then of course there’s the fact that these server stacks were designed to make development easy; they were never meant to run in production. For that, there’s mod_wsgi. (more…)
A few days ago, I was prompted to publicly release a project that I’ve been using internally to add a bit of Munki-awareness to my DeployStudio workflows. So, once I caught my breath at work, I added the Munki Manifest Selector project to github. Since the documentation is severely lacking, I thought I might post something a little less README-ish in hopes of helping folks along with the installation process. (more…)
About 2 years ago, Edward Marczak created screenrez. The goal was simply to offer a tool to OS X admins that would run on a remote client machine and report the screen resolution in use. Pretty handy, especially in scenarios where a projector is attached to the Mac in question.
The original version only supported one screen, which meant you were in good shape if the client machine’s displays were mirrored. I’ve just forked the project and added multiple screen support along with a little more detailed information, such as the screen’s device name.