For the past few major releases, Sophos used a standard installer package to install both their free and paid antivirus solution. With the release of Sophos Anti-Virus 9.x though, Sophos changed how their antivirus solution for Macs was installed. Sophos has now switched to using an application to install their antivirus. However, for their customers using Sophos Enterprise Console, Sophos still provides an installer metapackage. This is good news for Mac admins, but the configuration and login credentials that used to be stored in /Library/Preferences/com.sophos.sau.plist in Sophos 8.x has been overhauled in Sophos 9.x. /Library/Preferences/com.sophos.sau.plist in Sophos 9.x now no longer contains login information, only server locations.
The login credentials no longer being available in /Library/Preferences/com.sophos.sau.plist meant that the Sophos Anti-Virus client was not able to connect back to the Sophos enterprise console and receive either management or updates. Since those login credentials were working in my shop for machines in Active Directory OUs that the Sophos enterprise console was managing, that meant that those credentials were available somewhere on the system. After working on the problem in his own shop, Tim Kimpton figured out that both of the following files were needed:
Once I had this information and understood what was going on, I was able to build and deploy a Sophos Enterprise Anti-Virus for Mac OS X 9.x installer that was able to install a pre-configured set of auto-update settings. For more details, see below the jump.
While working recently on First Boot Package Install.pkg, I decided to implement a way to automatically install all available Apple software updates along with enabling other packages to be installed at first boot. After some work and testing, I’m happy to announce the release of First Boot Package Install With Automated Apple Software Update.pkg.
The main difference between First Boot Package Install.pkg and First Boot Package Install With Automated Apple Software Update.pkg is that before installing the user-selected packages, all available Apple software updates are downloaded and installed. By design, the First Boot Package Install With Automated Apple Software Update.pkg script will use Apple’s softwareupdate tool to check for and install available updates, then reboot the Mac automatically until all available updates have been installed.
As not all shops that may want to use First Boot Package Install.pkg will find this functionality to be needed or desirable, I’ve set up a new repo on Github for First Boot Package Install With Automated Apple Software Update.pkg. That way, Mac admins will be able to choose which one they want to use.
All First Boot Package Install With Automated Apple Software Update.pkg components and scripts are available at my GitHub repo:
Please see the README available at the repo for how to use First Boot Package Install With Automated Apple Software Update.pkg. The Iceberg project files are also available via the link above if you want to build a customized First Boot Package Install With Automated Apple Software Update.pkg for your own environment.
Following up on a pull request by Matthew Kweskin, I’ve updated First Boot Package Install so that it now reports whether an installation has succeeded or failed. This error reporting is in addition to the error logging recorded by OS X’s installer tool to /var/log/install.log.
For those interested, here are the changes to First Boot Package Install‘s firstbootpackageinstall.sh script.
I’ve updated the First Boot Package Install GitHub repo with the new First Boot Package Install installer package, along with updating the posted firstbootpackageinstall.sh script and the Iceberg project files with the changes.
To go along with my use of AutoPkg, I’ve started relying on AutoPkgr to automate running AutoPkg and notifying me when I had new updates. While I was checking over my current list of AutoPkg receipes today, I went to look for a recipe for AutoPkgr. To my surprise, no such recipe appeared to exist.
Thanks in large part to Tim Sutton‘s GitHubReleasesInfoProvider for AutoPkg, I’ve now been able to post download and package recipes for AutoPkgr. The recipes and support files are available from here on my GitHub repo:
Over the weekend, Rasmus Sten posted to Twitter about an interesting uninstall command line utility that he had found while testing 10.10.
On investigation, it became apparent that this uninstall utility was not new and was available starting in 10.7.x and later. It also appears to be undocumented and has neither a man page or help pages available.
To use the uninstall tool:
1. Log into the Mac in question
2. Verify that your application was installed by the App Store
3. Open Terminal
4. Run the following command with root privileges:
5. You will be prompted to authenticate with an administrator’s username and password
6. The application should then be uninstalled.
After working with this tool, it does have some limitations. For more details, see below the jump.
To go along with my earlier post about automating Oracle Java 7 updates, I’ve also posted a script to download and install the latest Java 8 update from Oracle. The method is identical, with the exception of referring to Java 8’s SUFeedURL value in Java 8’s /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist file.
For more information, see below the jump.
Something I’ve wanted to do for a while was to write a script to download and install the latest Java 7 update from Oracle. I’ve been using AutoPkg to download the latest Java 7 updates using AutoPkg’s OracleJava7 recipes, but I wanted to develop a script that would do the following:
- Download the latest Java 7 installer from Oracle’s website
- Install the latest Java 7 update
- Clean up after itself
Oracle didn’t make this an easy task, as the download URL seems to change on a per-update version. AutoPkg handles its update task by scraping Oracle’s manual download page for the current correct URL to use.
Oracle does provide a Sparkle-based update mechanism for Java 7 on OS X, so I wanted to see if there was a way to leverage that to pull down updates. The only address I could find in that regard was the SUFeedURL value included in Java 7’s /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist file. I checked that value using the following command:
defaults read "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info" SUFeedURL
The output I received for Java 7 Update 67 was the following:
I decided to see what output would come back from Oracle’s site when accessed, so I used the following curl command to see what was returned:
/usr/bin/curl --silent https://javadl-esd-secure.oracle.com/update/mac/au-1.7.0_67.xml
The following XML was returned and I was gratified to see that it contained a download link to a Java 7 Update 67 disk image.
One of the important things I was able to establish is that the XML address embedded with Java 7 Update 67 is not special in this regard. As part of my testing, I verified that using the SUFeedURL value for Java 7 Update 15 and 65 will also work to pull the address of the latest Oracle Java 7 installer disk image.
Using this information, I was able to build a script that can download and install the latest Java 7 update. See below the jump for details.