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.
Most of us who have setup a web server have also had to secure said server. If you’re anything like me, SSL is something that is easily understood superficially, but you just know there’s a lot going on down in the depths of the topic which are just waiting to bite you when you’re not looking. If only there were some tool to tell you just what you’re missing. What’s that GlobalSign? You say you’ve made such a tool and it’s free? Well, thank you very much!
Binding an OS X client to an LDAP server is pretty simple, but when it’s time to scale up, Apple wants us to use proxy servers and load balancers to offer failover and redundancy. This is by far the best approach, but sometimes setting up such a front-end for a cluster of servers is time or cost prohibitive depending on the scope of the project and the size of your fleet. In this case, it would be easier to simply have the OS X clients authenticate to a single server, using a list of trusted replica servers as a failover for when that primary server is unreachable for any reason. RFC4512 defines a LDAP attribute called
altServer, and we can use that attribute to configure exactly such a setup.
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…)
If you use LocalMCX to manage machines, this post by Greg Neagle is probably very familiar to you. In it, Greg outlines some of the changes that came with dscl in Mountain Lion and how those changes affect Local MCX management. Basically, the changes were such that you could no longer use dscl or Workgroup Manager to create or modify MCX settings and groups in your custom (non-“Default”) node.
It turns out, we can still use those tools to edit and manage our custom nodes. The problem isn’t a rewrite of dscl to specifically reject custom local MCX nodes, as many of us suspected. It’s sandboxing.
So what changed? Mountain Lion is all about Sandboxing (which is a very good thing). Apple’s goal with its App Sandbox is to split applications into collections of binaries so that each of those binaries can be assigned only the permissions and resources that it needs to do its job. When Apple sandboxed opendirectoryd, they rightly gave it read/write access to /var/db/dslocal/nodes/Default and nothing else. This is actually very good news for us because sandbox permissions can be modified, meaning we can get Workgroup Manager to edit users/groups/etc directly in our custom node. Here’s how:
/System/Library/Sandbox/Profiles/com.apple.opendirectoryd.sbin your favorite text editor
- Find the line referring to
/var/db/dslocal/nodes/Default, should be line 43 (notice how this is under the
- Insert a new line after that one with the following contents, making adjustments where needed for your local MCX path:
- Reload the daemon, effectively forcing sandboxd to reload the permissions:
Keep in mind, this only solves the problem of getting our favorite MCX editing tools back in our hands without the need to copy records back and forth between nodes, so it really wouldn’t make sense to push this out to all of your OS X client machines.
That’s it. You should now be able to use Workgroup Manager again to edit your local MCX settings, in place.
A few days ago I posted some notes about using iprntcmd to display some information about the print objects in your iPrint server. Today I’m going to talk about using iprntcmd to do a little sanity checking as well. If your institution is anything like mine, you’ve got pockets of Mac users and pockets of Windows users. They all need to print, and very seldom do they dare cross into each other’s realm. Generally this means that everyone is happy when it comes to printing. But from time to time, someone does cross into the opposing realm and discovers that they are unable to install a printer on their nice new Mac. (more…)
This one is for anyone out there using iPrint clients and servers from Novell to deliver print services. Did you know the iPrint client (at least as of iPrint v5.0.0 as best I can tell) includes a command line utility called iprntcmd? Well, it does. And it comes so close to being truly useful. It will allow you to add and remove printers given nothing more than an ipp:// url, but alas, there is no functionality baked in to allow modification of a printer once it’s installed. What modifications am I looking for you ask? Well, ideally I’d be able to use this tool to install a printer and turn on duplexing by default. I know, I know, this should be done in the PPD stored on the server, but it’s just nice to have some flexibility, you know? On to business: (more…)