Apple put out two advisories on August 29th about Java:

Java updates available for OS X on August 28, 2013

OS X: Java Web plug-in blocked 28 August 2013

The latter advisory is especially noteworthy to Mac admins, as that means that Apple’s XProtect was updated to block older versions of Java. That said, XProtect was not updated after the latest round of updates in June 2013, so those versions were not previously set in /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist as the minimum allowed versions. See below the jump for more details.

With the August 29th update, the following versions of the Java browser plug-in are now set as the minimum allowed versions:

For 10.6.x:

com.apple.java.JavaAppletPlugin – 13.9.7

com.apple.java.JavaPlugin2_NPAPI – 13.9.7

Click on the image below for comparisons of /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist from before and after the August 29 XProtect update.

For 10.7.x – 10.8.x

com.apple.java.JavaAppletPlugin – 14.8.0

com.apple.java.JavaPlugin2_NPAPI – 14.8.0

com.oracle.java.JavaAppletPlugin – 1.7.25.15

Click on the image below for comparisons of /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist from before and after the August 29 XProtect update.

These version numbers correspond to the following Java updates:

Java For Mac OSX 10.6 Update 16 – 13.9.7

Java for OS X 2013-004 – 14.8.0

Java 7 Update 25 – 1.7.25.15

If you’ve installed the Java updates above, you should be good. If you haven’t, install the latest Java updates and your Java browser plug-in should no longer be blocked by XProtect.

While I was working on a new laptop this afternoon, I noticed that the Profiles icon was missing from System Preferences.

This system was managed by our Casper server and we’re using both certificate-based communication and an APN certificate, so it should have been there. Moreover, when I ran profiles -P, I saw that no profiles were installed.

Running jamf mdm -verbose fixed the issue by installing the MDM certificate, but I wanted to ensure that any other machines with the same issue were found and then automatically fixed by Casper. After a little research, I have a process that does this. See below the jump for details.

JAMF provides three extension attributes with your Casper JSS server to help you identify machines with either problematic SSL certificates or missing MDM certificates.

JSS Certificate Validation

Verify Certificate Based Communication

Verify MDM Enrollment

All can be installed from the JAMF Software category of your JSS server’s Extension Attribute Templates.

From there, you can set up a Smart Group to look for machines that fit the following criteria:

JSS Certificate Validation – Success

Verify Certificate Based Communication – Enabled

Verify MDM Enrollment – Not Enrolled

It should also currently be scoped to look for Macs running 10.7.x or higher, as earlier OSs won’t be enrolled in MDM.

Here’s how the smart group I set up looks in Casper 8.x and 9.x:

Casper 8.x:

Casper 9.x:

From there, set up a policy that is scoped to run on members of that smart group. The policy I set up will run the jamf mdm -verbose command to install the MDM certificate on the Mac, then run a new inventory. The inventory update process should then allow the JSS to detect that the MDM certificate has been installed and take the machine out of the smart group.

Here’s how the policy I set up looks in Casper 8.x and 9.x:

Casper 8.x:

Casper 9.x:

An issue that I’ve been dealing with for a while has been that Oracle’s Java 7 did not run natively in VMware Fusion. VMware had created a patch for OS X VMs, but it was only designed to be run in OS X VMs running 10.8.x.

As of today, that issue has now been resolved. With the release of Java 7 Update 40, Java 7 now runs natively in VMware Fusion OS X VMs running 10.7.5 and 10.8.4. Thanks to the OpenJDK team, Oracle and VMware for their work in getting this fixed.

As part of my FileVault 2 testing, I do a lot of work with OS X VMs running in VMware Fusion. With 10.8.5′s release yesterday, I built a new OS X VM using this process. Once it was built, I tried enabling FileVault 2 and hit an odd issue. FileVault 2 was reporting that it was enabling, but on reboot I was not getting the FileVault 2 pre-boot login screen. Instead, I was passed onto the regular login window.

This is not the correct behavior for FileVault 2, so I was concerned that something in Fusion 6 had broken my ability to work with FileVault 2. After some work though, I was able to get FileVault 2 working again in VMware Fusion 6.0. See below the jump for details.

After looking at VMs that I had previously built in Fusion 5, then a new VM that I built in Fusion 6, I noticed one difference between my older VMs and the new VM. Fusion 6 introduced a virtual SATA bus and virtual disks for Fusion 6 OS X VMs are set up by default as as Bus type: SATA.

The Fusion 5 VMs were set up as Bus type: SCSI.

To see if the virtual disk type was the issue, I set up a new OS X VM in Fusion 6 that was otherwise identical to the one I was having trouble with. The only change I made was to switch the Bus type from Bus type: SATA to Bus type: SCSI. Using SCSI fixed my issue and I was able to encrypt my VM again with FileVault 2.

If this affects you, I recommend making this change when you’re first building the VM, before the OS is actually installed. That allows the OS to automatically use the new Bus type: from the start and avoid any compatibility issues that may come from trying to switch it later.

To make the switch from SATA to SCSI:

1. Go into the Hard Disk settings for your new VM

2. Click the arrow next to Advanced Options. This should allow the Bus type to be visible.

3. Click the Bus type: drop-down menu.

4. Switch Bus type: to SCSI. Once set, click the Apply button.

Your VM’s hard disk should now be listed as (SCSI). At this point, proceed with building your VM normally.

For those who wanted a copy of my FileVault 2 session slides from MacSysAdmin 2013, here are links to the slides in PDF and Keynote format.

PDF document link: http://tinyurl.com/MacSysAd2013PDF

Keynote slides link: http://tinyurl.com/MacSysAd2013key

Apple has released Xcode 5.0 through the Mac App Store for all Macs running 10.8.4 and higher. The command line tools can be installed separately through the Xcode preferences, in the Downloads section. You now need an Apple Developer Connection account to install the Xcode 5 command line tools via the Xcode preferences, though a free ADC membership is sufficient.

For my users who are developers, I wanted to include Xcode 5.0 in their new machine builds and also install the command line tools automatically without needing to enter an Apple ID. I also wanted to build this installer as a flat package, so I’m shifting from my previous method using Iceberg to using Packages to build the installer package. See below the jump for the details.

Download Xcode 5.0 from the Apple Developer site and drag the application into /Applications.

Download the latest Mountain Lion Command Line Tools for Xcode disk images from the Apple Developer site.

Verify that the permissions on the Xcode application in /Applications are correct by running the following command:

sudo chown -R root:wheel /Applications/Xcode.app

Set up a new Packages project and select Raw Package.

In this case, I’m naming the project Xcode 5.0.

Click on the Settings tab and set the following:

In the Post-Installation Behavior section, set On Success: to Do Nothing

In the Options section, check the box for Require admin password for installation.

Click on the Payload tab, then click on the Applications folder in the listing.

Go to the Hierarchy menu and select Add Files…

Select the Xcode application in /Applications

Verify that it’s now showing up under Applications in your Packages project.

Click on the Scripts tab in your Packages project.

Select the Mountain Lion Command Line Tools for Xcode disk image and drag it into the Additional Resources section of your Packages project.

The last pieces are removing any previous Xcode.app from /Applications and telling the Command Line Tools for Xcode installer to run.

To remove any previous Xcode.app from /Applications, I’m using the following preinstall script:

#!/bin/sh

# Remove existing /Applications/Xcode.app from machine

if [ -d /Applications/Xcode.app ]; then
  rm -rf /Applications/Xcode.app
fi

To install the command line tools, I’m using the following postinstall script:

#!/bin/bash

# Determine OS version
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

# Determine working directory

install_dir=`dirname $0`

if [[ ${osvers} -eq 8 ]]; then

#
# Installing the Xcode 5.0 10.8 Command Line Tools
#

# Create /tmp/Command Line Tools (Mountain Lion) mountpoint in /tmp

  /bin/mkdir "/tmp/Command Line Tools (Mountain Lion)"

# Mount the latest command line tools disk image as /tmp/Command Line Tools (Mountain Lion)

  /usr/bin/hdiutil attach "$install_dir/command_line_tools_os_x_mountain_lion_for_xcode__september_2013.dmg" -mountpoint "/tmp/Command Line Tools (Mountain Lion)" -nobrowse -noverify -noautoopen

# Install the Xcode command line tools

  /usr/sbin/installer -dumplog -verbose -pkg "/tmp/Command Line Tools (Mountain Lion)/Command Line Tools (Mountain Lion).mpkg" -target /

# Clean-up

# Unmount the command line tools disk image from /tmp/Command Line Tools (Mountain Lion)

  /usr/bin/hdiutil eject "/tmp/Command Line Tools (Mountain Lion)"

# Remove /tmp/Command Line Tools (Mountain Lion) from /tmp

  /bin/rm -rf "/tmp/Command Line Tools (Mountain Lion)"

fi

Once you’ve got the preflight and postflight script built, run the following commands to make the scripts executable:

sudo chmod a+x /path/to/preinstall
sudo chmod a+x /path/to/postinstall

Once completed, add the preinstall and postinstall scripts to your Packages project.

Last step, go ahead and build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Once the package has been built, test it by taking it to a test machine running 10.8.4 or 10.8.5 that doesn’t have Xcode 5.0 and install it. The end result should be that Xcode 5.0 installs along with the Xcode command line tools without requiring an Apple ID.

The documentation from MacSysAdmin 2013 is now available, with the session slides and videos being accessible from the link below:

http://documentation.macsysadmin.se

The video of my session is available for download from here:

http://docs.macsysadmin.se/2013/video/Day2Session5.mp4

I also like to thank Tycho Sjögren and Apoio AB again for inviting me to speak. I had a great time.

I recently had to roll my Casper test server back, as I had been testing Casper 9.x but needed to verify something worked in Casper 8.x. Since I hadn’t found a good knowledge base article on JAMF Nation for uninstalling Casper’s JSS from a Red Hat Enterprise Linux server, I asked JAMF Support how to do this. Here’s the procedure I used, based on their response:

Note: This procedure should only be used if you need to completely uninstall your Casper JSS. It removes all certificates, databases and anything else stored in your JSS.

1. SSH into the RHEL server as my user account.

2. su into the root account on the server by running the following command:

su root

3. Stop JAMF’s Tomcat by running the following command:

/etc/rc.d/init.d/jamf.tomcat7 stop

4. Delete the jss directory from /usr/local by running the following command:

rm -rf /usr/local/jss

Once /usr/local/jss was removed, I needed to remove the JSS’s MySQL database in order to complete the uninstall. Here’s the procedure I used:

5. Run the following command to get a MySQL prompt:

mysql

6. From the mysql> prompt, run the following command to remove the existing database:

mysql> drop database jamfsoftware;

7. Exit out of MySQL with the following command:

mysql> exit;

At this point, the JAMF-provided parts of the JSS were all removed. I hadn’t removed anything from my JSS’s file share, so all my installers and deployable scripts were intact. I then rebooted, just to make sure no stray processes remained before I tried reinstalling Casper 8.x.

Once the server was back up, I ran the following procedure to prepare the server for re-installing Casper 8.x.:

1. SSH into the RHEL server as my user account.

2. su into the root account on the server by running the following command:

su root

3. Run the following command to get a MySQL prompt:

mysql

4. From the mysql> prompt, run the following command to create a new empty jamfsoftware database for the JSS:

mysql> create database jamfsoftware;

5. Exit out of MySQL with the following command:

mysql> exit;

With the new jamfsoftware database created in MySQL on my test server, I was then ready to reinstall Casper 8.x.

For those folks using Keychain Minder to help your users update their keychain passwords, it continues to work as of 10.9.0.

To show it in operation, I’ve made a short video.

I’ve updated the FileVault 2 status check scripts so that they’re now able to correctly handle Macs running Mavericks. The scripts should now report accurately on the FileVault 2 status of Macs running 10.7.x – 10.9.x.

The changes are now available as part of my regular script. They have also been rolled into both the Casper Extension Attribute and the Absolute Manage Custom Info Item scripts. Use them in good health and please let me know if you find any problems with them.

One of the challenges that can crop up with deploying software packages can be repackaging packages and metapackages, especially packages that don’t have all of the installer data contained inside themselves. A good example of the latter is iLife ’11, where the installer package is small and instead acts as a master conductor to install other packages.

Another issue are applications that require multiple installs to get fully up to date. An example here would be Microsoft Office 2011, which has an installer that will install a full version of Office 2011 but then additional installer packages must be installed to get Office fully updated and patched.

To address this, you can use Packages‘ ability to add resources to a Packages-built package. See below the jump for an an example using an Office 2011 SP 3 installer package and the Office 2011 14.3.8 Update to build a unified Office 2011 SP 3 14.3.8 installer package.

1. Remove the Office 2011 installers’ application quit function.

2. Set up a new Packages project and select Raw Package.

3. In this case, I’m naming the project Microsoft Office 2011 SP 3 14.3.8

4. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)

In this example, I’m not changing any of the options from what is set by default.

5. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

In the Post-Installation Behavior section, set On Success: to Do Nothing
In the Options section, check the box for Require admin password for installation.

6. Click on the Scripts tab in your Packages project.

7. Select your installers and drag them into the Additional Resources section of your Packages project.

In the case of my example, I’m selecting the following installers:

Office 2011 14.3.0 with Service Pack 3 Installer.pkg
Office 2011 14.3.8 Update.pkg

8. The last piece is telling the installers to run. For this, you’ll need a postinstall script. Here’s the one I’m using:

#!/bin/bash
 
# Determine OS version
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')
 
# Determine working directory
 
install_dir=`dirname $0`
 
# Install Office 2011 using the specified installer packages in the working directory
 
/usr/sbin/installer -dumplog -verbose -pkg $install_dir/"Office 2011 14.3.0 with Service Pack 3 Installer.pkg" -target "$3"
/usr/sbin/installer -dumplog -verbose -pkg $install_dir/"Office 2011 14.3.8 Update.pkg" -target "$3"

Notice that $install_dir in the postinstall script refers to the path to the package’s working directory. That’s where Packages will be storing these installers, inside the Package-built installer’s embedded directory where it stores the items defined in the Additional Resources section.

The -target value is defined as “$3″ because some information is passed along by the Packages-built installer to its included scripts when those scripts are run by the installation process. (For more information, see the PackageMaker How-To available here and search on the page for $3)

In this case, -target being defined as “$3″ means that the postinstall script will install the two Office 2011 packages onto the desired drive.

The script also governs what order the installers run in, so the main Office 2011 installer runs first and the update runs next after the first job finishes. The -dumplog and -verbose flags are to help you track the progress of installation if you’re looking at the installer log.

9. Once you’ve got the postinstall script built, run the following command to make the script executable:

sudo chmod a+x /path/to/postinstall

10. Once completed, add the postinstall script to your Packages project.

11. Last step, go ahead and build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

An additional advantage of re-packaging using Packages is that Packages by default creates flat packages, which can be signed with a Developer ID. This will allow your packages to be accepted by Gatekeeper. Signing the Packages-built flat package provides a way to accommodate Gatekeeper if you have installer packages which otherwise aren’t signed or can’t be signed.

To sign your installers, you will need to have an Apple Developer Connection membership. If you’re an ADC member, you can obtain an Developer ID Installer certificate from Apple using Xcode.

Once you have your Developer ID Installer certificate installed, you can sign the Packages-built package with the following command:

productsign --sign "Developer ID Installer: FirstName LastName" /path/from/package_name.pkg /path/to/signedpackage_name.pkg

In the case of this example, I’m signing it with the following command:

productsign --sign "Developer ID Installer: Rich Trouton" "/path/from/Microsoft Office 2011 SP 3 14.3.8.pkg" "/path/to/Microsoft Office 2011 SP 3 14.3.8.pkg"

The signing process will create a duplicate of the Packages-built package and sign the copy with the Developer ID Installer certificate.

To verify that your package has been signed, check your installer package to verify that it has a lock icon in the top-right corner.

Next, click the lock icon to verify that the certificate is showing up as a valid Apple Developer ID Installer certificate.

For those who wanted a copy of my virtualization talk at MacTech Conference 2013, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/mt2013vmPDF

Keynote – http://tinyurl.com/mt2013vmkeynote

As part of preparing my Casper server for its eventual upgrade to Casper 9.x, I’m transitioning from using bundle-style packages to using flat packages wherever possible.

As part of that effort, I needed to repackage a few versions of Firefox that I have made available in my shop’s Self Service. I was able to do this with the help of AutoPkg’s Firefox receipe. See below the jump for details.

In my own shop, I usually have the following Firefox installers available in Self Service:

• The latest version of Firefox
• The just-previous version of Firefox (in case of an issue with the latest version)
• Firefox 16 (the latest version of Firefox that runs on Mac OS X 10.5.8.)

Needless to say, I built my Firefox 16 installer a while ago and it was a bundle-style package. I also wanted to automate building my Firefox installers.

AutoPkg came to the rescue; specifically AutoPkg recipe overrides. In this case, the overrides are functions built into the Mozilla Firefox recipes themselves that will help you build an installer package that installs the Firefox version you want.

You can specify which version of Firefox you want to use. For example, if you have AutoPkg installed and have the Firefox recipe, run the following command to build a Firefox 16.0.2 installer package:

autopkg run --key RELEASE=16.0.2 Firefox.pkg

If you want to build other versions, specify their version numbers when you run AutoPkg:

Firefox 22.0:

autopkg run --key RELEASE=22.0 Firefox.pkg

Firefox 24.0:

autopkg run --key RELEASE=24.0 Firefox.pkg

Firefox 25.0:

autopkg run --key RELEASE=25.0 Firefox.pkg

If you want to get the latest available without worrying about the version number, run the following command to build an installer package with the latest released version of Firefox:

autopkg run --key RELEASE=latest Firefox.pkg

If your shop uses Firefox ESR instead of the regular releases, run the following command to build an installer package with the latest ESR version of Firefox:

autopkg run --key RELEASE=latest-esr Firefox.pkg

The AutoPkg Firefox recipes are using http://download-origin.cdn.mozilla.net/pub/mozilla.org/firefox/releases/ as their source, so I recommend checking there if you need more information on which releases can be built with AutoPKG using the RELEASE key.

Apple officially announced on Monday, November 11th that the FIPS 140-2 validations for the cryptographic modules used by iOS 7 and OS X 10.9.x have now been completed. This is significant news for folks who want to use FileVault 2 in government and regulated industries (such as financial and health-care institutions.)

For folks who haven’t heard of it before, FIPS 140-2 is an information technology security accreditation program run jointly by the US and Canadian governments. This program is used by private sector vendors to have their cryptographic modules certified for use in US and Canadian government departments and private industries with regulatory requirements for security.

As part of today’s announcement, Apple has released KBase articles and guidance for security offices who deal with encryption:

OS X Mavericks: Apple FIPS Cryptographic Modules v4.0 – http://support.apple.com/kb/HT6051

Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Mavericks v10.9 – http://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT6051/APPLEFIPS_GUIDE_CO_OSX10.9.pdf

According to Apple, the OS X Mavericks Cryptographic Modules, Apple OS X CoreCrypto Module v4.0 and Apple OS X CoreCrypto Kernel Module v4.0, require no setup or configuration to be in “FIPS Mode” for FIPS 140-2 compliance on devices running OS X Mavericks v10.9.

FileVault 2 is listed as being FIPS 140-2 Compliant as part of the Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Mavericks v10.9 documentation, in the Compliant Applications and Services section.

With the release of 10.9, a number of Mac admins began seeing an Updating Managed Settings message appear at the login window.

When contacted, Apple said that this was new behavior and it was added for the following reasons:

Starting with 10.9, MCX will attempt to contact an AD/OD/MDM server during login, before the Finder is launched to ensure that all managed settings are applied before any user session applications run.

The dialog you are seeing comes up if this process takes more than a couple seconds.

The dialog does not add any time to the login process.

It’s just telling you why the login is taking extra time.

If your AD/OD/MDM server is responding slowly, then this is “normal” as the client just has to wait for the operations to complete.

In my own shop, this was going to be an issue. Our Casper server does not communicate with its clients over the Internet, so my users would see this message whenever they logged in while off of the office network. After working with Apple support, I now have a solution that works while a better one is hopefully being developed. See below the jump for the details.

It is possible to disable the MDM check that is causing both the login delay and the Updating Managed Settings message to appear. You can disable the check by running the following command with root privileges:

defaults write /Library/Preferences/com.apple.mdmclient BypassPreLoginCheck -bool YES

Here’s what /Library/Preferences/com.apple.mdmclient.plist looked like on my Mac once the command had been run:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>BypassPreLoginCheck</key>
	<true/>
</dict>
</plist>

Effects of disabling the login check

Disabling the login check causes any pending profiles that contain user-level managed preferences not to be applied until the following login. The point of the delay was to make sure that the MDM server had a chance to apply settings; bypassing the login check-in will affect that.

For my own shop, the solution above is an acceptable trade-off but different shops have different needs. Evaluate your own needs carefully.

Update – 11-13-2013: I’ve now built a script and payload-free package to disable the login check. Both are available here on my GitHub repo:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/bypass_mavericks_mdm_login_check

JAMF Software has posted the session video for my FileVault 2 session from JAMF Nation User Conference 2013.

For those interested, the JNUC session videos are available on YouTube. For convenience. I’ve linked my FileVault 2 session here:

Something I’ve always tried to include with Xcode installations are the Xcode command line tools. Starting in Xcode 4.3, Apple stopped bundling these tools by default and instead made them an optional install.

Since having these tools is useful, I re-packaged various versions of Xcode so that I could include these tools as part of the install. One of the ways I could tell that they were installed was by going into Xcode’s Downloads preferences panel and see if the Command Line Tools showed up with a checkbox entry.

Starting in Mavericks though, the Command Line Tools entry disappeared from Downloads.

Meanwhile, the Xcode command line tools themselves moved. In Mountain Lion, the Xcode 5.0.x command line tools are installed into /usr/bin and other system software directories.

In Mavericks, they are installed into /Library/Developer.

Why was this happening? After some digging and some collaborative work in the ##osx-server IRC room, an answer was found. See below the jump for details.

What was happening is that Apple had gone back to bundling the Xcode command line tools for Mavericks into Xcode 5.0.x.

However, they’ve continued to make the Xcode command line tools available as a separate install for those folks who don’t want to install Xcode.

Apple has also set up the Xcode command line tools so that they could be installed on demand via Software Update.

In many ways, this gives Mac admins the best of all possible worlds. If you need Xcode and the command line tools, all you need to install is Xcode.

Need the command line tools, but don’t want Xcode? No problem, just install the the Xcode command line tools by themselves.

Don’t want to install either Xcode or the Xcode command line tools on all of your machines, but you still need an easy way to install it on the machines that need it? Apple’s got you covered with the on-demand install via Software Update.

You can install both Xcode 5.0.x and the separate Xcode command line tools in Mavericks without a problem, but Mavericks will prefer to use the tools that are bundled in /Applications/Xcode.app and will ignore the tools installed into /Library/Developer unless Xcode.app is removed from the Mac.

Thanks to Allister, I ran across this NetSUS-related feature request at JAMF Nation. While the feature request makes sense in the context of the requester’s shop, it is possible to resize the NetSUS appliance to give it additional space.

The steps should be reasonably similar for each virtualization solution, but see below the jump for how to do this with VMware Fusion 6.x.

Pre-requisites:

The latest stable GParted Live iso file

JAMF’s NetSUS VM .ova file

In VMware Fusion 6.x:

1. Go to File: Import

2. Choose /path/to/NetSUS.ova in the Choose an Existing Virtual Machine window.

3. Save the new VM in a convenient location

4. The NetSUS .ova will import into the new VM

5. Once the import finishes, click the Customize settings button.

6. In the VM settings, click on the Hard Disk settings.

7. Resize the VM to the desired size and then click the Apply button.

8. The VM will then resize the disk.

9. Once the resize is successful, click the OK button.

10. Go back to the VM settings, and click on the CD/DVD settings.

11. Ensure that the CD/DVD drive is enabled.

12. Choose the GParted Live iso file.

13. Go back to the VM settings, and click on the Startup Disk settings.

14. In the Startup Disk settings, select CD/DVD.

15. Boot the VM.

While the VM is booted from the GParted Live iso file:

1. Select GParted Live (Default Settings)

2. When prompted, select Don’t touch keymap

3. Select your preferred language

4. When prompted for mode, enter 0.

5. In GParted, there should be a drive showing up with the amount of space you gave the VM. In this case, the drive ID is /dev/sda2 and the NetSUS partition is /dev/sda5

6. Right-click on /dev/sda2 and select Resize/Move.

7. Drag the slider so that /dev/sda2 is being allocated all of the available free space.

8. Once /dev/sda2 has been given all of the available space, click the Resize/Move button.

9. Click the Apply button in the toolbar.

10. At the warning window, click the Apply button.

11. Once operations are completed, click the Close button.

12. Right-click on /dev/sda5 and select Resize/Move.

13. Drag the slider so that /dev/sda5 is being allocated all of the available free space.

14. Once /dev/sda5 has been given all of the available space, click the Resize/Move button.

15. Click the Apply button in the toolbar.

16. At the warning window, click the Apply button.

17. Once operations are completed, click the Close button.

18. Go back to the VM settings, and click on the Startup Disk settings.

19. In the Startup Disk settings, select Hard Drive.

20. Shut down the VM.

1. Start up your NetSUS VM and hit the Enter key to get past the opening welcome screen

2. Log in as the shell user account

3. Run the following command to check the available disk space:

sudo fdisk -l

4. Run the following command to check the current filesystem setup and partition sizes:

df -h

The NetSUS partition is listed as /dev/mapper/NetSUS-root

5. To display the free space in the VM’s Linux Volume Manager, run the following command:

sudo vgdisplay

Note the free space in the NetSUS Volume Group which can now be assigned to a Logical Volume

6. Reassign the free space to /dev/mapper/NetSUS-root by running the following command:

sudo lvextend -l +100%FREE /dev/mapper/NetSUS-root

7. Run the following command to verify that the free space has been reassigned:

sudo vgdisplay

8. To perform a live resize of /dev/mapper/NetSUS-root, run the following command:

sudo resize2fs -p /dev/mapper/NetSUS-root

9. Run the following command to check the current filesystem setup and partition sizes:

df -h

/dev/mapper/NetSUS-root should now be listed with the additional space.

10. To make sure all changes have been committed, I recommend rebooting the NetSUS appliance at this point.

Apple has released Xcode 5.0.2 through the Mac App Store for all Macs running 10.8.4 and higher. While the command line tools for Mavericks are now included with Xcode, the command line tools for Mountain Lion can be installed separately through the Xcode preferences, in the Downloads section.

For my users who are developers, Xcode is part of their their new machine builds. I wanted to include Xcode 5.0.2 and also, where appropriate, install the command line tools automatically without needing to enter an Apple ID. With a little help from the Mac App Store, I was able to do this using Packages. See below the jump for the details.

I used the technique described here to capture a copy of the Xcode 5.0.2 installer from the App Store and then repackaged that installer with the Mountain Lion Xcode command line tools. Here’s the procedure I used.

Capture a copy of the Xcode 5.0.2 installer from the App Store

Download the latest Mountain Lion Command Line Tools for Xcode disk images from the Apple Developer site.

Set up a new Packages project and select Raw Package.

In this case, I’m naming the project Xcode 5.0.2.

Click on the Settings tab and set the following:

In the Post-Installation Behavior section, set On Success: to Do Nothing
In the Options section, check the box for Require admin password for installation.

Click on the Scripts tab in your Packages project.

Select the following and drag them into the Additional Resources section of your Packages project:

Xcode 5.0.2 installer
Mountain Lion Command Line Tools for Xcode disk image

The last pieces are removing any previous Xcode.app from /Applications and telling the Xcode installer and appropriate Command Line Tools for Xcode installer to run.

To remove any previous Xcode.app from /Applications, I’m using the following preinstall script:

#!/bin/sh

# Remove existing copy of Xcode.app from /Applications

if [ -d "$3/Applications/Xcode.app" ]; then
   rm -rf "$3/Applications/Xcode.app"
fi

To install Xcode and the command line tools, I’m using the following postinstall script:

#!/bin/bash

# Determine OS version
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

# Determine working directory

install_dir=`dirname $0`

# Install Xcode 5.0.2 using the specified installer package in the working directory

/usr/sbin/installer -dumplog -verbose -pkg $install_dir/"Xcode 5.0.2.pkg" -target "$3"


if [[ ${osvers} -eq 8 ]]; then

#
# Installing the Xcode 5.0.2 10.8 Command Line Tools
#

# Specify location of Xcode command-line tools disk image

  TOOLS=$install_dir/command_line_tools_os_x_mountain_lion_for_xcode__october_2013.dmg

# Specify a /tmp/commandlinetools.XXXX mountpoint for the disk image

  TMPMOUNT=`/usr/bin/mktemp -d /tmp/commandlinetools.XXXX`

# Mount the latest command line tools disk image to /tmp/commandlinetools.XXXX mountpoint

  hdiutil attach "$TOOLS" -mountpoint "$TMPMOUNT" -nobrowse -noverify -noautoopen

# Install the Xcode command line tools by searching the top directory of the
# mounted disk image and installing any installer package found. Only the
# Command Line Tools installer will be found by this search so it will be
# installed without having the specify the current installer package's name

  /usr/sbin/installer -dumplog -verbose -pkg "$(/usr/bin/find $TMPMOUNT -maxdepth 1 \( -iname \*\.pkg -o -iname \*\.mpkg \))" -target "$3"

# Clean-up

# Unmount the command line tools disk image from /tmp/commandlinetools.XXXX

  /usr/bin/hdiutil detach "$TMPMOUNT"

# Remove the /tmp/commandlinetools.XXXX mountpoint

  /bin/rm -rf "$TMPMOUNT"

fi

Once you’ve got the preinstall and postinstall script built, run the following commands to make the scripts executable:

sudo chmod a+x /path/to/preinstall

sudo chmod a+x /path/to/postinstall

Once completed, add the preinstall and postinstall scripts to your Packages project.

Last step, go ahead and build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Once the package has been built, test it by taking it to a test machine running 10.8.x and a separate test machine running 10.9 that do not have Xcode 5.0.2 and install it. The end result should be that Xcode 5.0.2 installs along with the correct Xcode command line tools for the installed OS without requiring an Apple ID.

In my travels, an issue I’ve occasionally dealt with has been moving Macs between directory services. In some cases, this meant between AD domains. In others, moving a Mac from an AD domain to an OpenLDAP server. In each case, as part of the process, the UID of the user’s account changed from the UID associated with the old directory service to the UID associated with the new directory service.

File and folder ownership on OS X is associated with UIDs, so files and folders that were created and saved by the old account may now be either inaccessible or read-only. You can update the ownership by using the Unix find command to locate files and folders owned by the old account’s UID and change the permissions so that the file or folder is now owned by the new account. For details, see below the jump.

This can be done a variety of ways, but one way is to run this command:

/usr/bin/find / -nouser -ls

This find command with the -nouser flag should display any files that have no associated user account that are on a filesystem associated with your Mac.

If you want to ensure that you’re only scanning drives that are using HFS or HFS+ filesystems, which would be the case for most direct attached storage, check to see which file systems are attached using the lsvfs command.

This tool shows you the filesystem modules that are loaded on your Mac, which tells you which filesystems are mounted. In the case of HFS+ filesystems, lsvfs displays them as hfs.

In this case, you can see that I have four hfs filesystems. This corresponds to the four hard drives that I have in this particular Mac.

Once you have the filesystems identified, you can use them with the find command. For example, to use the find command above only on disks using HFS+ for their filesystem, run the following command:

/usr/bin/find / -nouser \( -fstype hfs \) -ls

This will restrict your search and prevent it from trying to scan network storage.
Searching globally can take a while, depending on how much data needs to be checked. If you want to check a particular directory where you know the old user account stored files, run the following command:

/usr/bin/find /path/to/location -nouser -ls

As an example, you can run the following command to check /Library/WebServer/Documents:

/usr/bin/find /Library/WebServer/Documents -nouser -ls

The old UID should appear as a string of numbers in the ownership column of the affected file / folders.

Once you have the old account’s UID identified, run the following command:

sudo /usr/bin/find / -uid old_uid_number_here -exec chown username {} \;

This will search the Mac’s hard drive and update the ownership on all files and folders from the old account’s UID to the customer’s new account. For example, if the old account’s UID was 222214203 and the new username is troutont, you would run the following command:

sudo /usr/bin/find / -uid 222214203 -exec chown troutont {} \;

As noted previously, this search may take a while to run depending on how much data is stored on the machine.

NOTE: You may receive some Not a directory or Operation not permitted errors. Those errors can usually be ignored as it may not be possible to change the ownership on some special file types.

If you want to restrict the permissions update by filesystem, you can use the -fstype flag with find to specify only certain filesystems. If you wanted to update permissions on HFS+ filesystems, you can run the following command:

sudo /usr/bin/find / \( -fstype hfs \) -uid old_uid_number_here -exec chown username {} \;

You can verify that the permissions have been updated in a particular location by running the following command:

ls -al /path/to/location

The files and folders should now appear as being owned by the new account.