Manage Recent Places In OS X

There are two defaults keys that can be used to manage the recent places options in the OS X Finder. Both are in the .GlobalPreferences. The first is NSNavRecentPlaces and the second is NSNavRecentPlacesLimit. The NSNavRecentPlacesLimit key limits the number of items that are stored in the list. To increase the default to, let’s say, 20, use the defaults command to set the NSNavRecentPlacesLimit key to an integer of 20: defaults write .GlobalPreferences NSNavRecentPlacesLimit -int 20 Then use defaults to read the setting: defaults read NSNavRecentPlacesLimit You’ll need to “killall Finder” in order to see this in a Finder Save dialog. You can also inject items into the RecentPlaces array, called NSNavRecentPlaces, or delete the objects in the array. The array appears as follows: NSNavRecentPlaces =     ( "~/Desktop", "/Users", "~/Desktop/Work", "~/Documents", "~/Desktop/Daneel" ); You can set these using defaults write as well, writing the NSNavRecentPlaces as a list of quoted and comma separated values (note the ‘): defaults write NSNavRecentPlaces = '("/test","/test2","/test3")'; Or, if you only want to clear the recent places list, delete the key: defaults delete .GlobalPreferences NSNavRecentPlaces

Restrict Access To Sites On iOS Devices Using Apple Configurator 2

One of the more common requests we get for iOS devices is to restrict what sites on the web that a device can access. This can be done in a number of ways. One is using the content filter option in Apple Configurator 2. The second is using a Global HTTP Proxy. We’ll cover both here, using custom profiles. Both require the device be Supervised. Use the Content Filter To enable the Content Filter, open Apple Configurator and click on the New menu. From there, click on Content Filter in the sidebar. You have three ways you can use the Content Filter. These include:
  • Built-in: Limit Adult Content: A basic profile that allows you to specifically whitelist and blacklist sites. This gives you very basic control of sites. Here, use the plus sign to enter a URL, as you can see here.
Screen Shot 2015-10-26 at 3.43.56 PM
  • Built-in: Specific Websites Only: This option only allows certain sites, and creates a badge for each in the bookmarks list of Safari.
Screen Shot 2015-10-26 at 3.52.40 PM
  • Plug-in: Allows you to install third party plug-ins on iOS devices. If using this, you would likely have instructions for building the profile from the vendor.
Screen Shot 2015-10-26 at 3.54.06 PM The Content Filter is a pretty straight forward profile, except when using the plug-ins. Close the screen to save the profile. Screen Shot 2015-10-26 at 3.56.37 PM Once saved, you can use the filter profile in blueprints, via an MDM solution, or install manually through Configurator. Use the Global HTTP Proxy In Apple Configurator 2 there’s an option for a Global HTTP Proxy for Supervised devices. This allows you to have a proxy for HTTP traffic that is persistent across apps, and to have that proxy applicable when users go home or if they’re in the office/school. If you have a PAC file, you can deploy the global proxy using that, by selecting Auto as your deployment option. Screen Shot 2015-10-26 at 4.01.47 PM If you don’t use a PAC file, you can also manually define settings to access your proxy. Here, we specify the proxy server address and port, as well as an optional username and password. Additionally, new in Apple Configurator 2, we have the option to bypass the proxy for captive portals, which you’ll want to use if you require joining a network via a captive portal. Screen Shot 2015-10-26 at 3.59.37 PM Each Wi-Fi network that you push to devices also has the ability to have a proxy associated as well. This is supported by pretty much every MDM solution, with screens similar to the following, which is how you do it in Apple Configurator. Screen Shot 2015-10-26 at 4.03.59 PM I am all about layered defense, though. Or if a proxy is not an option then having an alternative is a great call. Another way to disable access to certain sites is to outright disable Safari and use another browser. This can be done with most MDM solutions as well as using a profile. To see what this would look like using Apple Configurator 2, see the below profile. Screen Shot 2015-10-26 at 4.05.50 PM Now, once Safari has been disabled, you then need to provide a different browser. There are a number of third party browsers available on the App Store. Some provide enhanced features such as Flash integration while others remove features or restrict site access. In this example we’re using the K9 Web Protection Browser. This browser is going to just block sites based on what the K9 folks deem appropriate. Other browsers of this type include X3watchMobicip (which can be centrally managed and has a ton of pretty awesome features), bSecure (which ties in with their online offerings for reporting, etc) and others. While this type of thing isn’t likely to be implemented at a lot of companies, it is common in education environments and even on kiosk types of devices. There are a number of reasons I’m a strong proponent of a layered approach to policy management for iOS. By leveraging proxies, application restrictions, reporting and when possible Mobile Device Management, it becomes very possible to control the user experience to an iOS device in such a way that you can limit access to web sites matching a certain criteria.

Delete nvram

A nifty little new option that came in OS X 10.9 Mavericks and stays in Yosemite is the ability to delete all of the firmware variables you’ve created. This can get helpful if you’ve got a bunch of things that you’ve done to a system and want to remove them all. If you run nvkram followed by a -p option you’ll see all of the configured firmware variables: nvram -p If you run it with a -d you’ll delete the given variables that you define (e.g. boot-args): nvram -d boot-args But, if you run the -c you’ll wipe them all: nvram -c

Chapter 3 Of My Next Book Available

The next chapter of my next book is again available free for TidBits readers at http://tidbits.com/article/14799:
This article is a pre-release chapter in the upcoming “Take Control of OS X Server,” by Charles Edge, scheduled for public release later in 2014. Apart from “Chapter 1: Introducing OS X Server,” and “Chapter 2: Choosing Server Hardware,” these chapters are available only to TidBITS members; see “‘Take Control of OS X Server’ Streaming in TidBITS” for details.
Hope you enjoy! And thanks again to Adam and Tanya for their awesome editorial!

MacSysAdmin 2014!

Well, it’s that time of the year when one of my favorite conferences opens up registration! Come one, come all to MacSysAdmin for good times, good people and lots of fun Macinnerdiness! I hope to see you there! The official page is up at http://www.macsysadmin.se. Screen Shot 2014-04-13 at 8.02.49 PM

Apple ID Bulk Importer

Some iOS and/or OS X deployments require us to create a boatload of Apple IDs. This could be to redeem VPP codes, to do iOS backups, to configure Messages, now giving the ability for OS X Server users to password reset for themselves, etc. I have sat and manually created Apple IDs for a number of clients. I’ve created dozens at a single sitting and there are some serious annoyances and challenges with doing so manually. For example, you’re gonna’ fat finger something. If you type 10 things in for 50 accounts then it’s hard to imagine you’re not gonna’ mess something up in one of those 500 fields. It’s also time consuming and well, just annoying. AppIcon Then, along came a script. That script allowed us to create loads of IDs on the fly. Now, we have a very nice GUI tool called the Apple ID Automation Builder that can be used to batch create a number of Apple IDs on the fly. Brought to us by Greg Moore and hosted by enterpriseios.com, this is one of those rare finds that is a serious time saver and very valuable when you need it in your bat belt. Great little tool, well worth the money and I look forward to providing Greg with plenty of accolades should we ever meet!

JAMF Nation User Conference 2012

JAMF has announced the 2012 rendition of their National User Conference. Having been to two of these, I can say that if you use any JAMF products that it is a great event to attend. It is a lot of very specific information about integrating, mass deploying, mass managing, mass document distributing and mass 3rd partying for Apple products. The National User Conference will be held October 23-25 2012, 8:00 am – 5:00 pm in beautiful Minneapolis, Minnesota (where all the cool kids live). The venue is one of the best conference spots I’ve seen in the Guthrie theater, overlooking the stone arch bridge. In previous years, there have been announcements, new versions, people discussing their specific integrations, etc. I would also think that if you use another product that you might find the conference helpful, as you get to see whether the grass really is greener on the other side! Anyway, I recommend coming out to Minneapolis for this one if you can. And if you do, let me know!

Deploying and Managing Firefox Part 2: Working with Munki

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 “test-sacredsf-cck@extensions.sacredsf.org” as in my last post. There are a few pieces to this we need to incorporate:
  1. A postinstall script for Firefox that guarantees the establishment of the symbolic link between the CCK location and the internal Firefox bundles directory.
  2. A package for the CCK itself that drops the items in the location you want, with the appropriate installs key to ensure it reinstalls if deleted.
  3. The CCK package should also establish a symbolic link to itself if one does not already exist.
  4. A guaranteed reinstall of Firefox, should it be deleted, that also incorporates the re-establishment of the symbolic link.
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/MacOS/distribution/bundles/test-sacredsf-cck@extensions.sacredsf.org ];
then
 ln -s /Library/Application Support/FirefoxCCK/test-sacredsf-cck@extensions.sacredsf.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/FirefoxCCK/test-sacredsf-cck@extensions.sacredsf.org</string>
 <key>type</key>
 <string>file</string>
 </dict>
 <dict>
 <key>md5checksum</key>
 <string>8c994a5e24ebee8f8227f5d2e37b97dc</string>
 <key>path</key>
 <string>/Library/Application Support/FirefoxCCK/test-sacredsf-cck@extensions.sacredsf.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).