With the release of Sophos Enterprise Anti-Virus 9.2.x, Sophos changed how their enterprise antivirus solution for Macs was installed. While previous versions of Sophos Enterprise used an Apple installer metapackage, Sophos has now switched to using an application to install their enterprise antivirus software.
This switch was a problem for Mac admins who wanted to deploy Sophos Enterprise Anti-Virus 9.2.x, as the previously-available installer package had simplified the task of deployment. The new Sophos Enterprise Anti-Virus 9.2.x install application added further complexity by storing many of the installer’s files and other components outside the application in a separate Sophos Installer Components directory.
However, after doing some research and testing, it looks like it is possible to repackage Sophos Enterprise 9.2.x for deployment. For more details, see below the jump.
Oracle has released a new update for Java 8, but this update has an interesting wrinkle. Oracle has put out a new build of Java 8, but didn’t bump the version number from Java 8 Update 31. So folks who had previously installed Java 8 Update 31 may receive a message to update to Java 8 Update 31 from their current version, which will also be Java 8 Update 31.
This may lead to some confusion.
Update 2-16-2015: It appears that the update feed for Java 8 Update 31 has been updated to reference 220.127.116.11 (aka Java 8 Update 31 build 13):
There’s no information available on why the change was made. My speculation is that Oracle decided that updating the Sparkle feed for Java 8 Update 31 so that it was no longer providing Java 8 Update 31 build 15 as an update for Java 8 Update 31 build 13 was the best way to help avoid future confusion over updates for Java 8 Update 31.
It looks like 18.104.22.168 (aka Java 8 Update 31 build 15) is still the version being provided through the Java download site:
I checked the update feeds for Java 8 Update 20 and Java 8 Update 05 and both of those feeds are still providing 22.214.171.124 as well:
Unfortunately, there is still no information available about Java 8 Update 31 build 15 and how it differs from Java 8 Update 31 build 13.
Build numbers for the two Java 8 Update 31 releases
January’s Java 8 Update 31 (released on January 20, 2015): Java 8 Update 31 build 13
February’s Java 8 Update 31 (released on February 10, 2015): Java 8 Update 31 build 15
If you have Java 8 Update 31 installed, you can find out which build you have by running the following command in Terminal:
defaults read /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist CFBundleVersion
If you have Java 8 Update 31 build 13, the following string will be returned:
If you have Java 8 Update 31 build 15, the following string will be returned:
Following installation of Java 8 Update 31 build 15, I tested on a 10.10.2 Mac against the following sites:
My work’s Juniper VPN
Oracle’s Java Test page: https://www.java.com/en/download/help/testvm.xml
Java Tester’s Java Version page: http://javatester.org/version.html
A while back, there was an issue when the certificate Apple used to digitally sign installers expired. This issue was handled by Apple in a couple of ways:
- Reissuing installers signed with an updated certificate
- Adding the -allowUntrusted function to the installer command line tool
In the past couple of weeks, Apple has released new versions of a number of updates, which are now available for download by folks running Apple’s Software Update service or third-party tools like Reposado. Most of these updates were for older OSs where Apple has since stopped providing new updates. When these updates were checked, there didn’t seem to be any difference between the “old” and “new” versions of the installers.
So why is Apple pushing new copies of the updates to Mac admins’ software update servers? The answer appears to be again in the digital signing of the updates. For more details, see below the jump.
In the ##osx-server IRC room, a question that comes up fairly often from new Mac admins is one similar to this:
I’m on a tight budget. Are there any free tools that I can use to help manage my Macs?
There are a lot of free tools available to Mac admins, a number of which are community-built open-source tools. Here’s a list of free tools to get started with:
Update 2-4-2015: Tom Bridge has put together a list of free or cheap Mac sysadmin tools.
Imaging and machine building
- AutoDMG – https://github.com/MagerValp/AutoDMG/wiki/Getting-Started
- Blast Image Config: http://clc.its.psu.edu/UnivServices/itadmins/mac/blastimageconfig
- Create Recovery Partition Installer.app – https://github.com/MagerValp/Create-Recovery-Partition-Installer
- DeployStudio – http://www.deploystudio.com
- FileWave Lightning – http://www.filewave.com/index.php/features/lightning
Installer package building and development
- Packages – http://s.sudre.free.fr/Software/Packages/about.html
- Payload-Free Package Creator.app – https://github.com/rtrouton/Payload-Free-Package-Creator
- Simple Package Creator.app – https://github.com/rtrouton/Simple-Package-Creator
- The Luggage – https://github.com/unixorn/luggage
FileVault 2 recovery key management
- Cauliflower Vest – https://github.com/google/cauliflowervest
- Crypt – https://github.com/grahamgilbert/Crypt
- CreateUserPkg – http://magervalp.github.io/CreateUserPkg/ (also available from the Mac App Store.)
- mcxToProfile – https://github.com/timsutton/mcxToProfile
- Make Profile Pkg – https://github.com/timsutton/make-profile-pkg
- Puppet – https://docs.puppetlabs.com/guides/install_puppet/install_osx.html
- Plan B – https://github.com/google/macops/tree/master/planb
OS installation and upgrades
- createOSXInstallPkg – https://github.com/munki/createOSXinstallPkg
- First Boot Package Install Generator.app – https://github.com/rtrouton/First_Boot_Package_Install_Generator
Software management and deployment
- aamporter – https://github.com/timsutton/aamporter
- AutoPkg – https://github.com/autopkg/autopkg/wiki/Getting-Started
- AutoPkgr – http://www.lindegroup.com/autopkgr/
- Munki – https://github.com/munki/munki/wiki
- MunkiAdmin – https://github.com/hjuutilainen/munkiadmin
- Munki-in-a-box – https://github.com/tbridge/munki-in-a-box
- munkireport-php – https://github.com/munkireport/munkireport-php
- Reposado – https://github.com/wdas/reposado
- Sal – https://github.com/salsoftware/sal
- Simian – https://github.com/google/simian
Know of any more free tools to help manage Macs? Got a favorite that you think is missing from the list? Let me know in the comments.
A number of Mac admins need to provide the Xcode Command Line Tools for the Macs in their environments, either as part of building machines or afterwards. To help with this task, I’ve developed a script that will download and install the Xcode Command Line Tools on Macs running 10.7.x and higher. See below the jump for more details.
With the release of Yosemite, Apple has continued to add functionality to fdesetup, a valuable command-line tool for enabling, administering and disabling Apple’s FileVault 2 encryption. This tool gives Mac administrators the following command-line abilities:
- Enable or disable FileVault 2 encryption on a particular Mac
- Use a personal recovery key, an institutional recovery key, or both kinds of recovery key.
- Enable one or multiple user accounts at the time of encryption
- Get a list of FileVault 2-enabled users on a particular machine
- Add additional users after FileVault has been enabled
- Remove users from the list of FileVault enabled accounts
- Add, change or remove individual and institutional recovery keys
- Report which recovery keys are in use
- Perform a one-time reboot that bypasses the FileVault pre-boot login
- Report on the status of FileVault 2 encryption or decryption
I’ll be taking you through all of the capabilities mentioned above, with a focus on showing exactly how they work. See below the jump for details.
One of the requirements when enabling an account for FileVault 2 is that the account’s own password must be provided in order for the account to be enabled. This is because the account’s password is used to generate a unique derived key via PBKDF2. This key is necessary for the account to unlock FileVault 2’s encryption, so the account’s password must be provided in order to enable an account.
Apple recognized that there would be situations where Mac admins would need to set up FileVault 2 for a person where the admin would not have the password for that person’s user account. To avoid the immediate need to enter a password, fdesetup has a -defer flag in Mountain Lion, Mavericks and Yosemite that can be used with fdesetup‘s enable verb to delay enabling FileVault 2 until after the current (or next) user logs out. With the -defer flag, the user will be prompted for their password at their next logout or restart. The recovery key information is not generated until the user password is obtained, so the -defer option requires a file location where this information will be written to as a plist file.
The property list file will be created as a root-only readable file and contain information similar to what’s show below.
Note: For security reasons, the plist file with the recovery key information should not stay on the encrypted system. Please copy it to a safe location and then securely delete this plist file from the encrypted system.
Run the following command with root privileges to defer enabling FileVault 2 and specify the account you want:
fdesetup enable -user username -defer /path/to/filename.plist
If there is no user account specified with the -user option, then the current logged-in user will be enabled for FileVault 2. If there is no user specified and no users are logged in when the command is run, then the next user that logs in will be chosen and enabled.
If you don’t want to specify the account, run the following command with root privileges:
fdesetup enable -defer /path/to/filename.plist
On logout, the user will be prompted to enter their account password.
Once entered, FileVault 2 will be enabled and the recovery information plist file will be created. Once the enabling process is complete, the Mac will restart.
An important thing to keep in mind about the –defer option is that it enables one single user account at the time of turning on FileVault 2 encryption. The –defer option does not enable multiple user accounts and cannot be used to enable accounts once FileVault 2 encryption has been turned on.
In Yosemite, Apple added new options for fdesetup‘s -defer flag. These new options now allow Mac admins to set a deferred enablement with the following options:
- Enforce FileVault 2 enablement at logout
- Enforce FileVault 2 enablement at login
- Enforce FileVault 2 enablement at both login and logout
For more information, see below the jump.