Information and registration for MacSysAdmin 2016 is available:
http://macsysadmin.se/2016/Home.html
October 4-7, 2016 in Gothenburg, Sweden, MacSysAdmin continues to be a fantastic event for the Mac admin community. I highly recommend it!
Packaging
Flash Player 20 and Analytics
Flash Player was a frequent topic on this blog in the past. But Adobe has improved its packaging, and tools like AutoPkg have taken away much of the pain around deploying frequent Flash Player updates.
Yesterday, Adobe released Flash Player 20. A new addition is an executable at /Library/Application Support/Adobe/FPFeedbackService. Poking at this executable using strings makes it clear the tool reports analytics back to Adobe.
Some fine people on the MacAdmins Slack channel poked at it some more with Hopper and determined it can be turned off by adding DisableAnalytics=1 to a configuration file at /Library/Application Support/Macromedia/mms.cfg.
If you wish to disable Flash analytics in your fleet, then, one approach would be to install a properly configured mms.cfg file. The https://github.com/munki/munki-pkg-projects repo has a project you can use to build such a package: https://github.com/munki/munki-pkg-projects/tree/master/AdobeFlashConfiguration
The AdobeFlashConfiguration project is designed for use with the munki-pkg tool.
More info on Flash analytics here: https://osxbytes.wordpress.com/2015/12/09/flash-player-20-0-0-235-adds-phone-home-analytics/
Packaging Lab at MacTech Conference 2015
If you are planning on participating in the Packaging Lab this week at the MacTech Conference, you may want to download some materials in advance when you aren’t competing with all the other people for limited conference Wi-Fi bandwidth. Note — don’t install these items — just download their installers and keep them handy for the lab.
ExifTool pkg:
http://www.sno.phy.queensu.ca/~phil/exiftool/ExifTool-10.03.dmg
Adobe Reader 11 pkg:
http://ardownload.adobe.com/pub/adobe/reader/mac/11.x/11.0.10/en_US/AdbeRdr11010_en_US.dmg
Google Earth pkg:
http://dl.google.com/earth/client/advanced/current/GoogleEarthMacNoUpdate-Intel.dmg
Firefox dmg:
http://ftp.mozilla.org/pub/firefox/releases/latest/mac/en-US/Firefox%2042.0.dmg
Google Chrome dmg:
https://dl.google.com/chrome/mac/stable/GGRO/googlechrome.dmg
Some optional things:
Packages:
http://s.sudre.free.fr/Software/files/Packages.dmg
Suspicious Package:
http://www.mothersruin.com/software/SuspiciousPackage/download.html
Pacifist:
https://www.charlessoft.com
Using autopkg for “general purpose” packaging
A few days ago I made a simple tool for building packages available: munkipkg.
https://github.com/munki/munki-pkg
I got many comments and suggestions for additional features and all sorts of cool additions. Some have even been added to the tool already. But I would like to keep munkipkg a pretty simple, basic tool.
The Luggage (https://github.com/unixorn/luggage) has been around for a while; if munkipkg is too simple for your needs, please have look at that.
I also suggested to several people that if they had more complex needs than munkipkg could handle, it might make more sense to use autopkg, which supports very complex, customizable workflows.
I could tell by the awkward silence that my suggestion was confusing to some — that they had trouble grokking how to use autopkg to build packages “from scratch”, using files and scripts on the local disk.
So I created a GitHub repo demonstrating how to use autopkg in this manner. It’s here: https://github.com/gregneagle/autopkg-packaging-demo
munkipkg comes with three demo package projects. Two of the packages install files, the third is a “payload-free” package that simply runs a script when installed. The autopkg-packaging-demo duplicates these packages, but uses autopkg to build them instead of munkipkg.
(One could also imagine building these packages using either tool: the payload and scripts directories would be the same — in other words, you could have both a build-info.plist for munkipkg and a recipe for autopkg in the same package project directory.)
Assuming you have autopkg installed, you can `git clone` the repo, or download and expand the zip file, and run the autopkg recipes within.
I hope this clears up some confusion, and sparks some new ideas!
Introducing munkipkg
https://github.com/munki/munki-pkg
munkipkg is a simple tool for building packages in a consistent, repeatable manner from source files and scripts in a project directory.
Files, scripts, and metadata are stored in a way that is easy to track and manage using a version control system like git.
Another tool that solves a similar problem is Joe Block’s The Luggage (https://github.com/unixorn/luggage). If you are happily using The Luggage, you can probably safely ignore this tool.
Though this tool may eventually be added to the set of tools installed with the Munki command-line tools, it’s not currently tied to Munki and can be run completely standalone.
Learn more here.
Pseudo-“Payload-free” pkgs with pkgbuild
“Payload-free” packages — that is, Apple installer packages that do not have a file payload, but only run scripts, are a nice tool for OS X admins to have. They provide a convenient way to deliver and execute scripts as root. If you have a way to install packages on your managed machines, you can also run scripts as root by wrapping them in a “payload-free” package.
Rich Trouton has written up the basic procedure using the built-in `pkgbuild` tool: https://derflounder.wordpress.com/2012/08/15/creating-payload-free-packages-with-pkgbuild/
But payload-free packages built this way have a “feature” that can sometimes prove problematic. Flat packages built with pkgbuild using the --nopayload option do not leave receipts in the pkgutil database. This means it can be difficult to determine if a given payload-free package has already been installed on a given machine.
This is especially annoying with Munki: by default, when installing a package, Munki uses the package’s receipt(s) to determine whether or not the package has been installed. Without that receipt, and with no other information, Munki can’t tell if the package has been installed.
Fortunately, it’s trivial to make a pseudo-payload-free package that leaves a receipt. All we need to do is specify an empty payload!
Here’s how we make a “true” payload-free package (that does not leave a receipt):
pkgbuild --nopayload --scripts /path/to/scripts_dir --identifier org.example.payloadfree --version 1.0 MyGreatPayloadFree.pkg
and here’s a “pseudo” payload-free package that does leave a receipt:
mkdir empty
pkgbuild --root empty --scripts /path/to/scripts_dir --identifier org.example.payloadfree --version 1.0 MyGreatPayloadFree.pkg
That’s it! Instead of using the --nopayload option, we create an empty directory and point the --root option at it. The package is built with the empty payload, and when installed, the package leaves a receipt.
You Oughta Check Out AutoPkg: Links
If you attended my presentation on AutoPkg today, thanks! Here are the links:
AutoPkg:
http://autopkg.github.io/autopkg
https://github.com/autopkg/autopkg
https://github.com/autopkg/autopkg/releases
AutoPkg recipe repos:
http://github.com/autopkg
JSSImporter:
https://github.com/arubdesu/jss-autopkg-addon
AbsoluteManage Processor:
https://github.com/tburgin/autopkg/blob/master/Code/autopkglib/AbsoluteManageExport.py
AutoPkg Change Notifications script:
http://seankaiser.com/blog/2013/12/16/autopkg-change-notifications/
MacSysAdmin 2013 session:
http://docs.macsysadmin.se/2013/video/Day2Session4.mp4
Steve Yuroff’s AutoPkg and Jenkins notes:
http://swytechnotes.wordpress.com/2013/10/21/autopkg-and-jenkins-under-one-admin-account/
AutoPkg Wiki:
https://github.com/autopkg/autopkg/wiki
Mavericks day
10.8.3 supported platforms
A follow-up to yesterday’s post on 10.8.3.
I had hoped that the “SupportedModelProperties” list in the InstallESD.dmg’s /System/Library/CoreServices/PlatformSupport.plist would serve as a more-or-less human parseable list of supported models.
But it appears that there are some supported models that do not appear in the “SupportedModelProperties” list, but whose board-ids do appear in the “SupportedBoardIds” list in that same file.
In any case, the _real_ thing that causes the the installer to decide whether or not to proceed is this function in the OSInstall.mpkg’s Distribution file:
function isSupportedPlatform(){
if( isVirtualMachine() ){
return true;
}
var platformSupportValues=["Mac-F42D88C8","Mac-F2218EA9","Mac-F42D86A9","Mac-F22C8AC8","Mac-F22586C8","Mac-AFD8A9D944EA4843","Mac-F227BEC8","Mac-F226BEC8","Mac-7DF2A3B5E5D671ED","Mac-942B59F58194171B","Mac-2E6FAB96566FE58C","Mac-F42D89C8","Mac-00BE6ED71E35EB86","Mac-4B7AC7E43945597E","Mac-F22C89C8","Mac-942459F5819B171B","Mac-F42388C8","Mac-F223BEC8","Mac-F4238CC8","Mac-F222BEC8","Mac-4BC72D62AD45599E","Mac-F2268DC8","Mac-F2208EC8","Mac-66F35F19FE2A0D05","Mac-F4238BC8","Mac-F221BEC8","Mac-C08A6BB70A942AC2","Mac-8ED6AF5B48C039E1","Mac-F2238AC8","Mac-FC02E91DDD3FA6A4","Mac-6F01561E16C75D06","Mac-742912EFDBEE19B3","Mac-F22589C8","Mac-F22587A1","Mac-F22788AA","Mac-F42C86C8","Mac-942C5DF58193131B","Mac-F2238BAE","Mac-F22C86C8","Mac-F2268CC8","Mac-F2218FC8","Mac-7BA5B2794B2CDB12","Mac-F65AE981FFA204ED","Mac-031AEE4D24BFF0B1","Mac-F22587C8","Mac-F42D89A9","Mac-F2268AC8","Mac-F42C89C8","Mac-942452F5819B1C1B","Mac-F2218FA9","Mac-F221DCC8","Mac-94245B3640C91C81","Mac-F42D86C8","Mac-F2268EC8","Mac-F2268DAE","Mac-F42C88C8","Mac-94245A3940C91C80","Mac-F42386C8","Mac-C3EC7CD22292981F","Mac-942B5BF58194151B","Mac-F2218EC8"];
var boardID = system.ioregistry.fromPath('IOService:/')['board-id'];
if( !boardID || platformSupportValues.length == 0 ) {
return false
}
for( var i = 0; i < platformSupportValues.length; i++ ){
if( boardID == platformSupportValues[i] ){
return true;
}
}
return false;
}
Unfortunately, I have not found a reliable resource for mapping board-ids to models.
Disabled Java Plugins, XProtect Updater
Today Apple updated the XProtect.meta.plist file, which, among other things, causes XProtect to disable Java Plugins that don’t meet a minimum version.
The net effect was to disable the Java 6 plugin on all browsers, as well as Java 7 plugins older than 1.7.11.22.
If you need to continue to use the Java 6 plugin in your organization, you can revert the changes and disable the mechanism that updates the XProtect.meta.plist by installing this package:
https://dl.dropbox.com/u/8119814/DisableXProtectUpdater.pkg.zip
This is a payload-free package that runs this script as a postflight:
#!/bin/sh # don't check JavaWebComponentVersionMinimum XPROTECT_META_PLIST="$3/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist" /usr/libexec/PlistBuddy -c "Delete :JavaWebComponentVersionMinimum" "$XPROTECT_META_PLIST" # disable the xprotectupdater job LAUNCHD_JOB_PLIST="$3/System/Library/LaunchDaemons/com.apple.xprotectupdater.plist" /bin/launchctl unload -w "$LAUNCHD_JOB_PLIST"
I won’t tell you this is a smart thing to install; there are many reasons to leave things as they are. Apple disabled these plugins to protect from known exploits. By re-enabling them, you are opening up your managed machines to these exploits.
But if your org needs the Java 6 Web Plugin, this should get you running again. You should re-enable the XProtect updater as soon as you are able, though:
sudo /bin/launchctl load -w /System/Library/LaunchDaemons/com.apple.xprotectupdater.plist
NOTE: if you need to re-enable an older version of the Oracle Java 1.7 Plugin, you’ll need to edit the postflight script and add something like:
/usr/libexec/PlistBuddy -c "Set :PlugInBlacklist:10:com.oracle.java.JavaAppletPlugin:MinimumPlugInBundleVersion 1.7.10.19" "$XPROTECT_META_PLIST"
(Sadly, WordPress changes a colon followed by a P into a emoticon, even in pre-formatted text. Not helping…)
This sets the MinimumPlugInBundleVersion for the Oracle Java Web Plugin back to the value it was with the 10 Jan 2013 version of the XProtect.meta.plist. Again, if you do this, you are choosing to expose your machines to a known Java Web Plugin exploit. Do so at your own risk.
(Update 01 Feb 21013)
If you need to run the Oracle Java 1.7 Plugin (or are already running it and it’s been disabled) the best fix is to update the Java install. As of this writing, Java 7 Release 13 for OS X is available here. This installs a web plugin with BundleVersion 1.7.13.20.
(Update 02 Feb 2103)
Apple has released a Java 6 update for Snow Leopard. Installing this update will restore Java 6 web plugin functionality under Mac OS 10.6. This won’t help if you need to use the Java 6 web plugin under OS X 10.7 or later.
Managing OS X 