Clay, Pepjin, Marcus, Tom, and I talk Macs at Google. Those guys are all great. I’m there for comedic relief. Not intentionally mind you…
krypted December 20th, 2016
Posted In: public speaking
MacDevOps 2016: f you’re interested in the scripting side of the Apple world and can make it from June 20th to 21st, this might just be the conference for you. At MacDevOps, you’ll see “Speakers from across North America and Europe will be presenting on a number of topics related to Mac administration and deployment.” This would be things like contributing to open source projects, packaging Django web apps to look like native Mac apps, osquery, Munki security, imagr, autopkg, ansible, git, and jenkins. Basically, automating the things: DevOps. And for Macs. Or Appley things. For now.
And… Lots of fun people will be there. including the convergence of friends from other industries who don’t know that each other know me (nor would they likely care – other than to trade stories about how I made them drink something-or-other), which is kinda’ cool. Anyway, Mathieu’s awesome. You should check this out.
krypted April 3rd, 2016
As promised, here’s the presentation I gave this morning at the MacAD UK Conference in London. It is incredibly well put together and all the presentations thus far have just been fantastic. Congrats to the entire team at Amsys and the speakers for such a great show!
krypted February 9th, 2016
Posted In: public speaking
The latest and greatest of the Enterprise Mac Admin’s Guide is now available for Pre-Order at http://www.amazon.com/Enterprise-Mac-Administrators-Guide-Second/dp/1484217055/ref=sr_1_1?s=books&ie=UTF8&qid=1445529968. This is an interesting update. If you happened to see the previous edition, I’d described more about Casper than most of the other third party products on the market.
In this edition, there’s still an equal amount of information on Casper, but now there’s also more information on FileWave, and a whole chapter on the open source toolchain of products, including Munki and AutoPKG. The main reason I decided to update this title was actually the change from focusing on directory services (which still has plenty of page count) to focusing on profile management.
The most substantial update to the book was Bill Smith though. Bringing him in as a co-author provided a lot of new insight, new content, and a good bit of cleaned up text. He’s been great to work with!
This was a pretty big update, so hope you enjoy!
krypted October 22nd, 2015
There’s another new conference in town! Well, not my town, but Vancouver. MacDev Ops is a hot topic. One that will only increase in the coming years. Thanks to Mat X and Brian Warsing for bringing about a brilliant conference.
The conference will be held on June 19, 2015 and is an easy $99 if you sign up soon. Also, submit a talk if DevOps is your thing. They’re looking to bring the following topics to the table:
This is sure to be a good one. Check it out here!
krypted March 23rd, 2015
(Guest post by Allister Banks)
Working with modern tools in the ‘auto'(dmg/pkg) suite, it sure reinforces the old chestnut, ‘it’s
turtles XML all the way down.’ The thing that struck me when first diving into using autopkg was that different product recipes could potentially have a good amount of similarities when they share common processors. One example is drag-drop apps that can be discovered with an ‘appcast’ URL, which, in my recollection, became common as the Sparkle framework gained popularity.
This commonality is exactly the type of thing sysadmins like myself seek to automate, so I built a few helper scripts to 1. discover what apps have appcast URLs, 2. generate the base download recipe, and further, the 3. pkg-building recipe that can use the download recipe as a ‘parent’, and the 4. munki or JSS recipes which can nest the pkg recipe in it. Recursivity is the new black.
Please do take a look if you feel you’ve got apps that folks haven’t built recipes for yet, and laugh at/use/fork my code as you see fit!
Allister Banks April 3rd, 2014
Posted In: Uncategorized
(Guest Post by Allister Banks)
As Venn diagram circles go, many folks in our community are getting into autopkg, and there’s even more that already use the JAMF Casper Suite. Over on the 318.com blog there’s an announcement for a new ‘processor’ add-on that can be installed with autopkg, that therefore can leverage the JSS API to fulfill many of the functions which up until present only Munki enjoyed. Please do read the release notes and give it a try!
Allister Banks January 6th, 2014
(Allister Banks Guest Post:)
As part of my presentations at LOPSA-East(the pdf slides of this one is here) earlier this year, I wanted to demonstrate how quickly you can get a proof-of-concept of Munki running on a recent Mac OS without Server. I had always used Greg Neagle’s awesome intro articles for MacTech(especially part 2,) which were created back in 10.6 days(simpler times, amirite?) This video takes you through the setup of a Munki repo, and goes on to demonstrate not only basic Munki interaction and functionality, but if you setup MunkiWebAdmin and the reporting scripts on your clients in addition, it does a quick tour of that interface.
Pardon the length, lack of sound and meme’s sprinkled throughout, but I hope it’s of use to someone!
Tweet to @sacrilicious
Allister Banks November 4th, 2013
Posted In: Mac OS X
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 “email@example.com” 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/MacOSfirstname.lastname@example.org ]; then ln -s /Library/Application Support/FirefoxCCKemail@example.com /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/FirefoxCCKfirstname.lastname@example.org</string> <key>type</key> <string>file</string> </dict> <dict> <key>md5checksum</key> <string>8c994a5e24ebee8f8227f5d2e37b97dc</string> <key>path</key> <string>/Library/Application Support/FirefoxCCKemail@example.com/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