Archive

Archive for the ‘Mac administration’ Category

Deploying Sophos Enterprise Anti-Virus for Mac 9.2.x

February 26, 2015 5 comments

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.

Screen Shot 2015-02-25 at 7.48.51 PM

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.

Screen Shot 2015-02-25 at 7.50.06 PM

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.

Read more…

Oracle’s Java 8 Update 31 has been updated to …. Java 8 Update 31

February 13, 2015 8 comments

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 1.8.31.13 (aka Java 8 Update 31 build 13):

https://javadl-esd-secure.oracle.com/update/mac/au-1.8.0_31.xml

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 1.8.31.15 (aka Java 8 Update 31 build 15) is still the version being provided through the Java download site:

https://www.java.com/download

I checked the update feeds for Java 8 Update 20 and Java 8 Update 05 and both of those feeds are still providing 1.8.31.15 as well:

https://javadl-esd-secure.oracle.com/update/mac/au-1.8.0_05.xml

https://javadl-esd-secure.oracle.com/update/mac/au-1.8.0_20.xml

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.


java_8_update_31

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:

1.8.31.13

Screen Shot 2015-02-13 at 12.39.10 PM

If you have Java 8 Update 31 build 15, the following string will be returned:

1.8.31.15

Screen Shot 2015-02-13 at 12.30.22 PM

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

Screen Shot 2015-02-13 at 12.09.11 PM

Java Tester’s Java Version page: http://javatester.org/version.html

Screen Shot 2015-02-13 at 12.08.47 PM

In all three cases, the Java applets on those sites launched and worked without issue using Java 8 Update 31 build 15 (though the javatester.org applet needed to be whitelisted.)

Categories: Java, Mac administration

Certificate authority expiration and Apple software updates

February 10, 2015 2 comments

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:

  1. Reissuing installers signed with an updated certificate
  2. 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.

Read more…

Free tools for the budget-minded Mac admin

February 4, 2015 10 comments

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

Installer package building and development

FileVault 2 recovery key management

Mac management

NetBoot

OS installation and upgrades

Software management and deployment

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.

Installing the Xcode command line tools on 10.7.x and later

February 2, 2015 5 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.

Read more…

Managing Yosemite’s FileVault 2 with fdesetup

February 2, 2015 7 comments

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.

Read more…

FileVault 2 deferred enablement in Yosemite

January 31, 2015 Leave a comment

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.

Screen Shot 2015-01-31 at 12.33.03 PM

The property list file will be created as a root-only readable file and contain information similar to what’s show below.

Screen Shot 2015-01-31 at 12.30.24 PM

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

Screen Shot 2015-01-31 at 2.23.07 PM

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

Screen Shot 2015-01-31 at 2.24.49 PM

On logout, the user will be prompted to enter their account password.

Screen Shot 2015-01-31 at 10.57.19 AM

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.

Screen Shot 2015-01-31 at 10.57.20 AM

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:

  1. Enforce FileVault 2 enablement at logout
  2. Enforce FileVault 2 enablement at login
  3. Enforce FileVault 2 enablement at both login and logout

For more information, see below the jump.

Read more…

Follow

Get every new post delivered to your Inbox.

Join 191 other followers

%d bloggers like this: