Archive
Simple Package Creator.app
One task that has always seemed to me to take more time than it should is the process of packaging applications like Firefox, Google Chrome or other applications which are self-contained and can be copied as-is into /Applications. While tools like AutoPkg have helped a good deal by automating the download and packaging of various self-contained applications, this approach still requires some setup work and requires a recipe to be written to handle the application.
To help make this task easier, I’ve developed Simple Package Creator.app, an Automator application that will allow the selection of a self-contained application and creates an installer package that enables the installation of the application with pre-set permissions into /Applications. For more details, see below the jump.
Unlocking or decrypting a FileVault 2-encrypted Fusion Drive from the command line
Unlocking or decrypting a FileVault 2-encrypted Fusion drive from the command line can be a little different from how you would handle a non-Fusion drive. This is because Apple has created Fusion drives by using the Core Storage volume manager that they first introduced in OS X 10.7.x. Normally when you enable FileVault 2, there is not an existing Core Storage volume on the drive being encrypted and the FileVault 2 process creates it. When a drive is decrypted using the diskutil cs revert command, that CoreStorage volume is then removed as part of the process.
However, with Fusion drives, not only is there an existing CoreStorage volume present before encryption, you want to make sure it’s not being removed as part of the decryption process. Doing so would destroy the Fusion drive setup and potentially result in the loss of all data stored on the Fusion drive.
There’s two tools that you can use to safely decrypt a Fusion drive on OS X Mavericks:
CasperCheck – an auto-repair process for Casper agents
One of the issues that I occasionally run into in my shop is that sometimes the Casper agent on individual Macs stops working properly. They stop checking in with the Casper server, or check in but can’t run policies anymore. I’ve set up smart groups on my Casper server to help me identify these machines, but actually fixing them has not been an automated process.
While at the JAMF Nation User Conference in October 2013, I was fortunate enough to hear Mike Dodge and Ajay Chand talk about the challenges they faced at Facebook with keeping Casper agents working in an environment where users are encouraged to break down any obstacle that gets in their way (sometimes, the obstacles in question were perceived to include the Casper agent.) As part of their talk, they mentioned they had a scripted way to verify that the Casper agent was running properly and automatically fix it if it wasn’t. This was a capability that I wanted to include in my own environment, so I asked them if this was going to be available at some point. They said it would be, so I waited to see what would be released.
At this point, the story fast forwards to March 2014, where the Facebook team was able to release their code to GitHub and I was able to take a look and see what they had done. I saw that I could adapt some of their work, but I would need to do additional work on my end to develop a solution that not only worked in my environment, but would be relatively straightforward to adapt to work in others’.
After a lot of work and testing, I’m happy to announce the release of CasperCheck. This is a script-driven solution that will do the following:
A. Check to see if a Casper-managed Mac’s network connection is live
B. If the network is working, check to see if the machine is on a network where the Mac’s Casper JSS is accessible.
C. If both of the conditions above are true, check to see if the Casper agent on the machine can contact the JSS and run a policy.
D. If the Casper agent on the machine cannot run a policy, the appropriate functions run and repair the Casper agent on the machine.
For more details, see below the jump.
First Boot Package Install Revisited
As covered previously, Greg Neagle’s createOSXinstallPkg is a useful tool for installing or upgrading Mac OS X in a variety of situations. One of the nicer features is that you can edit the OS X installer to install additional packages.
However, the limitations of the OS X install environment mean that there are a number of installers that won’t install correctly. In particular, packages that rely on pre- or postflight scripts to perform important tasks may fail to run properly in the OS X install environment.
To help work around this limitation, I developed First Boot Package Install.pkg, an installer package that enables other packages to be installed at first boot. It’s designed for use with createOSXinstallPkg with the goal of allowing installer packages that can’t run in the OS X Install environment to be incorporated into a createOSXinstallPkg-using deployment workflow.
The first version of First Boot Package Install.pkg had some limitations though, with the biggest one probably being that you couldn’t tell what it was doing when it was running. Instead, all that was displayed was the gray Apple loading screen.
I tried various approaches of booting into verbose mode and writing log entries to the console, but none of the approaches were good enough to introduce into production. Fortunately, Per Olofsson developed exactly what I was looking for with his LoginLog tool.
Using LoginLog.app as a way to display updates to the user, I’ve been able to update First Boot Package Install.pkg with improved visual feedback. I’ve also now incorporated another piece of feedback I’ve received, which is to add a network check. This new check makes sure that the Mac has a network address other than 127.0.0.1 or 0.0.0.0 before it proceeds to install any packages. For more details, see below the jump.
Repackaging the Microsoft Lync 14.0.8 installer
Microsoft has released Microsoft Lync 14.0.8, which included compatibility with Mavericks. Since we have several folks using both Lync and Mavericks, I wanted to get this into our Casper server’s Self Service as soon as possible.
To test installing it, I downloaded the installer on a disk image from Microsoft’s site, then renamed the package from Lync Installer.pkg to Lync 14.0.8 Installer.pkg. After renaming it, I set up an installation policy for Self Service, scoped the policy so that only my test machine could see it, then ran the installation.
Failed.
I go check the logs and see this entry:
/usr/sbin/jamf is version 8.73 Executing Policy Microsoft Lync... [STEP 1 of 2] Downloading BOM for Lync 14.0.8 Installer.pkg... This Apple Package did not have a valid index.bom file. Assuming it is a flat file package. Downloading http://casper.server.here/repo_name/Packages//Lync 14.0.8 Installer.pkg... Error: The package could not be found on the server. [STEP 2 of 2] Running Recon... Displaying message to end user...
OK, maybe I did that wrong. Deleted the package and this time uploaded the installer to my Casper server without changing the name from Lync Installer.pkg.
/usr/sbin/jamf is version 8.73 Executing Policy Microsoft Lync... [STEP 1 of 2] Downloading BOM for Lync Installer.pkg... This Apple Package did not have a valid index.bom file. Assuming it is a flat file package. Downloading http://casper.server.here/repo_name/Packages//Lync Installer.pkg... Error: The package could not be found on the server. [STEP 2 of 2] Running Recon... Displaying message to end user...
Failed again. Meanwhile, /var/log/install.log on my test Mac only showed that installd was starting and then stopping. In short, Casper’s logs were right; the installation process was starting but couldn’t then find a package.
At that point, I started thinking. How would the developer have installed this package? How did Q&A likely test installing it, however minimally?
Developer – Would have double-clicked on the package to install it, followed by typing in an admin password.
Q&A – Same process as the developer, except they would have tested installing it from the mounted disk image.
Creating an Office 2011 SP 4 14.4.1 installer
One of the issues I worked on this week was building a new Office 2011 installer after Microsoft released the Office 2011 14.4.1 update. I have an existing process to build a combined Office 2011 installer using Packages, which I’ve used successfully for a while.
This time though, I hit a problem. When I installed the combined Office 2011 installer with DeployStudio, then logged in, I was asked to enter a product key. Since my work has a volume license, this isn’t a screen I should ever see.
This is a problem that’s been seen with previous Microsoft Office 2011 installers and usually involves the volume license file not being applied when it should be. This behavior may be seen with the 14.4.1 update in the following cases:
1. Office 2011 is installed and then updated to 14.4.1 while nobody is logged in
2. Office 2011 is installed and then updated to 14.4.1 without any Office applications being launched between the initial installation and the update.
These two scenarios will likely apply if you’re building a new machine using an automated deployment tool, but likely will not if you’re a home user.
With luck, this will only be an issue for 14.4.1 and Microsoft will fix this issue in the next 14.4.x update. In the meantime, the easiest fix I’ve found in my testing this week is to get the necessary volume license file from a machine that has Office 14.3.x installed on it and put it back on an as-needed basis.
The needed file is /Library/Preferences/com.microsoft.office.licensing.plist. If you have a volume-licensed version of Office 2011 installed on your Mac, you should have this file.
To address the issue of installing 14.4.1 without losing your volume license, you can use Packages‘ ability to add resources to a Packages-built package. See below the jump for how you can use an Office 2011 SP 3 installer package, the Office 2011 14.4.1 Update, and the com.microsoft.office.licensing.plist license file to build a unified Office 2011 SP 4 14.4.1 installer package that does not prompt for a product key.
Using /etc/auto_home on Mavericks to mount shares under /home
One of my users at work asked me recently about symlinking his network home folder to /home on his Mac running 10.9.2 and wanted to check to see if it was safe to do so.
In this case, the person in question works on both Fedora Linux, where his network home directory was mounted as /home/username, and on OS X. His network home directory was available via SMB on his Mac as smb://servername/home$/username. He wanted to be able to mount smb://servername/home$/username to /home/username on his Mac, so that it matched the mountpoint of his network home on his Fedora box.
At the time, here’s what I knew about /home:
1. Nothing appears to be stored in it by default
2. It’s listed in /etc/auto_master as a mountpoint
Der Flounder 
Recent Comments