I’ve long been a supporter of building tools in self service portals such as those provided by JAMF and Munki to provide users who don’t have administrative permissions to perform tasks that wouldn’t typically otherwise be destructive. One such example is a simple repair permissions. An administrator can simply open Disk Utility, select their disk and then click Repair Disk Permissions
But if you want to do this as a user who doesn’t have administrative privileges you would need to elevate your privileges before doing so. In a larger environment this would be incredibly annoying for dozens, hundreds, thousands or even tens of thousands of users to bring their computer to an administrator just to type in a password. But, if you have a patch management solution that has some kind of a self service portal, users could do this themselves. Typically, you would create a very small payload free package. This package might just contain a single script that might even be as short as a one-liner. For example, the following command would actually run a repairPermissions.
diskutil repairPermissions /
You could also send some environmental variables from your patch management tool for the boot volume, but in this simple instance we’re just going to run it, with the following type of output:
Started verify/repair permissions on disk0s2 Macintosh HD
Permissions differ on "Library/Application Support"; should be drwxr-xr-x ; they are drwxrwxr-x
Repaired "Library/Application Support"
Group differs on "Library/Printers/InstalledPrinters.plist"; should be 80; group is 0
Permissions differ on "Library/Printers/InstalledPrinters.plist"; should be -rw-rw-rw- ; they are -rw-r--r--
[ \ 0%..10%..20%..30%..40%..50%..60%..70%................ ] 74% 0:00:34
Finished verify/repair permissions on disk0s2 Macintosh HD
You could get much more complicated, writing the output to syslog or even a syslog server. You can also have metapackages that just do a bunch of tasks and call them things like “Try to fix my computer.” Provided you have a patch management tool, you could also just scope some devices and push some of these things out en masse; however, for the most part, I’m a fan of self service, so that’s the example I’m using this for.
krypted October 28th, 2013
Posted In: Mac OS X
A special thanks to Nick McSpadden for his third submission to krypted.com. With all the new changes in OS X/Server I haven’t even had time to write as many in such a span!!!
This is a follow up post to the Firefox Management guide.
Knowing how to use the CCK to manage Firefox, the next big question is: how do we get this into Munki? It’s unfortunately not as cut and paste as we’d hope, because, with all things, Firefox tends to make us do a bit of work to get what we want from it.
Importing Firefox 10.0.10 ESR (current version as of writing time) into Munki is easy. You can add whatever other stuff you need to the pkginfo, but it tends to take care of itself.
Importing the CCK into Firefox is where this gets fun. Luckily, some very smart people have figured this out, thanks to the MacEnterprise mailing list. See the conversation here: https://groups.google.com/d/topic/macenterprise/YUqrm96QSFo/discussion. Credit goes to Nate Walck for the script and Greg Neagle for the advice.
If you are deploying the CCK into the internal Firefox application distribution directory, then you may notice that a vanilla install of Firefox does not have the Firefox.app/Contents/MacOS/distribution/bundles/ directories. We’ll have to create them as part of the install process.
If you want to put the Firefox CCK files somewhere other than inside Firefox, you’d need to change the add-on scopes for Firefox to load it. This isn’t really ideal either, because it requires micromanaging the Firefox install, which means that every time you import a new Firefox update, you have to do a lot of manual labor to make sure all these preferences get included.
One solution is to repackage Firefox with the CCK itself and deploy that as one. It works just fine, but it’s a lot of work – especially with Firefox’s release schedule. You’d have to rebundle it for Munki every six weeks. Pox on that, I say. But editing Firefox preferences is also undesirable for the extra work it generates.
Greg’s suggestion: a symlink! Throw the CCK anywhere, such as /Library/Application Support/FirefoxCCK/, and then create a symlink into Firefox’s bundles directory. In this post, I’ll be using the example CCK configuration named “firstname.lastname@example.org” as in my last post.
There are a few pieces to this we need to incorporate:
We can accomplish part of this in a postinstall script for Firefox in Munki:
#!/bin/bash mkdir -p -m 755 /Applications/Firefox.app/Contents/MacOS/distribution/bundles/ mkdir -p -m 755 /Library/Application Support/FirefoxCCK/ if [ ! -L /Applications/Firefox.app/Contents/MacOSemail@example.com ]; then ln -s /Library/Application Support/FirefoxCCKfirstname.lastname@example.org /Applications/Firefox.app/Contents/MacOS/distribution/bundles/ fi
The if statement above is potentially unnecessary, since it’s unlikely there would be a situation in which Firefox would install but somehow the internal contents of /Contents/MacOS/distribution/bundles/ is preserved, but I figure the extra check won’t hurt.
You can also set this same script to be a postinstall_script for the CCK package, so that if you ever have to add more addons to Firefox, you can guarantee that the symbolic link will be established.
To guarantee the sanctity of our CCK, we’d have to add an installs item to check that the unpacked CCK exists. We check the CCK’s path, and that the CCK’s md5 matches the expected one (so that we can guarantee it hasn’t been changed). The CCK’s existence and its md5 should be installs keys for the CCK itself. In this case, I do not explicitly call for an installs check on the symlink itself, on the basis that it’s extremely unlikely someone will delete the symbolic link but not Firefox.app. Unless the user has administrative privilege, they can’t delete either of them anyway. If your users have administrative privileges, then it doesn’t really make sense to manage Firefox for them.
The installs keys for Firefox:
<key>installs</key> <array> <dict> <key>CFBundleIdentifier</key> <string>org.mozilla.firefox</string> <key>CFBundleName</key> <string>Firefox</string> <key>CFBundleShortVersionString</key> <string>10.0.10</string> <key>minosversion</key> <string>10.5</string> <key>path</key> <string>/Applications/Firefox.app</string> <key>type</key> <string>application</string> </dict> </array>
The installs keys for the CCK package (obviously you’ll need to change your checksum accordingly):
<key>installs</key> <array> <dict> <key>path</key> <string>/Library/Application Support/FirefoxCCKemail@example.com</string> <key>type</key> <string>file</string> </dict> <dict> <key>md5checksum</key> <string>8c994a5e24ebee8f8227f5d2e37b97dc</string> <key>path</key> <string>/Library/Application Support/FirefoxCCKfirstname.lastname@example.org/cck.config</string> <key>type</key> <string>file</string> </dict> </array>
We do it this way to guarantee that the CCK is always linked to the correct place in Firefox, even if Firefox is updated, or installed separately. Since Firefox always creates the symlink as part of its install, we don’t have to worry about it breaking if the user deletes Firefox, or Firefox gets updated to a new version (which won’t have the directories or symlink inside it by default).
The CCK will only get reinstalled if it’s missing from the /Library/Application Support/ folder (or wherever you initially stashed it).
This way, as long as the CCK is listed as an update-for for Firefox, you’ll always guarantee that the correct Firefox management is installed. The only thing you need to remember to do is copy the postinstall_scripts to each new version of the Firefox and CCK pkginfos (although the CCK pkginfo will need a new checksum if you make changes).
krypted June 5th, 2012
Posted In: Mass Deployment
Don’t let the theft of the Paternoville sign fool ya’, State College is as safe as ever. That is, until a bunch of Mac guys descend on the Nittany Lion Shrine. Yes, it’s that time of the year again when Mac guys from around the world (and yes, all of the speakers are male) descend upon Pennsylvania State University from throughout the Big 10 and beyond to discuss the Penn State mascot, the Nittany Lion. Actually, it’s a mountain lion, so we can’t discuss it quite yet at that point, but we can talk about a slightly bigger cat: Lion.
Lion deployment, scripted tools, Munki, InstaDMG, Puppet, migrations, “postPC,” PSU Blast, Dual Boot, NetBoot, reboot (just threw that in there because it sounded like it fit, but I’m sure much rebooting will be done anyway) and even iOS. Oh, and don’t forget lecture capture, launchd, monitoring, scripting, Boot Camp via BitTorrent (wait, what?), Damn Logs, Subversion (long live git), IPv6 (long live IPv4), DeployStudio (long live the French), Reposado (long live the mouse), Luggage, Casper (long live Minnesota!), ARD (long live the friggin’ App Store), troubleshooting, FileVault (long live Howard Hughes’ legacy), Tivoli (long live that 1984 video), Munki (crap, I already said that) and even iPad (which runs iOS I think).
Overall, the lineup is superb and looking at it, I am honored to be giving a session on Lion Server amidst all the cool stuff going on around me. I’m very impressed with the number and level of speakers and very excited to be a part of it. I’m also excited to be participating with Allister Banks, a cohort from 318, who will be giving talks on InstaDMG and Munki. Overall, it is sure to be a great conference and I look forward to hopefully seeing you all there if I don’t get arrested at the airport for wearing University of Minnesota socks.
Speaking of the Big 10. Did you know there are 12 teams in the Big 10? Did you know the Big East now has teams in Idaho and California? Did you know that the Big 12 has 10 teams? Did you know that the Pac 12 has 4 teams in 3 states that don’t touch the Pacific ocean? What does all this mean? No, it does not mean that we will discuss basic arithmetic and geography at the conference; however, we might show off some apps that can help the math professors at the member institutions of these higher education conferences teach these basic subjects a bit better. Disclaimer: I went to the University of Georgia and am required by having done so to poke fun at other conferences whenever it is possible. Having said that: how many Georgia programmers does it take to change a light bulb?
They can’t, it’s a hardware problem! OK, terrible joke. So here’s a picture of the Georgia mascot chomping down on an opposing (Auburn) player.
Seems like I’m going through football season withdrawals all of a sudden… Point of all this, go to the conference. It’s sure to be a hoot, and I’m sure there will be plenty of talk about football, er, I mean Mountain Lions, er, wait, I mean Mac OS X and iOS!
krypted March 7th, 2012
Tags: " PSU Blast, "postPC, ARD, BitTorrent, Boot Camp, Casper, DeployStudio, Dual Boot, instadmg, ios, Lion, Lion deployment, logs, Luggage, Mac OS X, migrations, Munki, NetBoot, os x, Puppet, reboot, Reposado, scripted tools, Subversion, Tivoli