I do a lot of work with payload-free packages and while I have a process for creating them as I needed them with pkgbuild, this approach requires some setup work. To help make the package creation process more convenient, I developed Payload-Free Package Creator.app, an Automator application that will allow to select an existing script and create a payload-free package that runs the selected script.
However, this tool has used pkgbuild‘s –nopayload function, which creates a package which doesn’t leave an installer receipt behind. This is intended behavior according to Apple, but not leaving a receipt behind can make it hard to determine whether an installer package has been run on a particular machine. This is especially problematic for Munki, which uses receipts along with other methods to track installation status.
While I don’t use Munki, I’ve heard from a number of folks who do and who had run into the no-receipt problem when they tried to use payload-free packages generated by Payload-Free Package Creator.app with Munki.
So the problem was this:
- I wanted to create payload-free packages which only run scripts and do not install files.
- I wanted to have an installer receipt.
- Apple’s built-in method for generating payload-free packages with pkgbuild didn’t provide receipts.
- I thought I needed to provide a payload to pkgbuild in order to generate a package which would provide receipts.
- Providing a payload meant I was installing files, which is what I didn’t want to do.
The matter had rested there for a while and I didn’t see a good way to fix it.
Fortunately, I was wrong about point 4. Greg Neagle recently documented that you can make a package with pkgbuild that, while not technically payload-free, will act just like one. The key is to create an empty directory and set pkgbuild‘s –root option to look there for files. pkgbuild‘s –root option is used to tell pkgbuild which files to package, but since there will be no files in an empty directory, the package will install no files on the destination Mac.
That’s where I had gone wrong on point 4 – I thought I had to give pkgbuild something to install in order to build a package with a receipt, but it turns out that pkgbuild will successfully build a package while using an empty payload directory. This information allowed me to reconcile points 1 and 2, which resolved the problem.
With this new information, I was able to update Payload-Free Package Creator.app and I’m happy to announce it has two new features:
- Version numbering
- Packages generated by Payload-Free Package Creator.app will leave receipts behind after installation.
For more details, see below the jump.
When the Office 2011 14.5.0 update was released, it was initially noteworthy for the fact that in certain circumstances it removed Office’s license. Shortly thereafter, Outlook 14.5.0 became noteworthy for the fact that Outlook’s main window (which displays the mailboxes, list of emails, calendars and other functions) was now invisible.
Another thing that was curious was that this problem did not affect everyone. It seemed to affect only those who met both of the following conditions:
- Macs running 10.10.x
- Accounts that had mailbox subfolders and had those mailbox subfolders expanded at the time of quitting Outlook.
Update – 5-22-2015: Microsoft has released Microsoft Office for Mac 2011 14.5.1 Update to address this issue. As of 5-22-2015 at 11:37 AM UTC, the 14.5.1 update is not yet available in Microsoft’s update feed for Office 2011, so it will need to be manually downloaded from Microsoft’s website. It’s available from the link below:
With this update, the procedure to fix should now be this:
1. Quit all open Office applications
2. Install the Office 2011 for Mac 14.5.1 update.
3. Once the 14.5.1 update has been installed, launch Outlook
Outlook’s main window should be visible again and work normally.
For better or for worse, I have a large number of mailbox subfolders so I could pretty much reproduce this issue (which I quickly dubbed Inbox Invisible) on demand.
A number of suggested fixes included the following:
- Removing the Outlook preferences from ~/Library/Preferences
- Rebuilding the Outlook identity
- Deleting cache files
- Some combination of all of the above
In my testing, those fixes would work for one time. I’d launch Outlook, the main window would be there, I’d quit Outlook and re-launch it and be confronted again with Inbox Invisible.
What ultimately fixed it for both myself and those in my shop affected by this issue was the following:
- Quitting all Office applications
- Uninstalling Office 2011
- Restarting the Mac
- Reinstall Office 14.4.9 following the restart.
Outlook started working again once rolled back to 14.4.9. The weird thing was that uninstalling Office and reinstalling it fixed the issue, without needing to change anything else. This is one of the very few times I can recall when uninstalling Office 2011 and reinstalling it actually addressed a serious problem. Normally, problems with Outlook are caused by something amiss on the user account or email account level. However, it looks like there may be an explanation. For more details, see below the jump.
I’d previously written a post about Yosemite’s FileVault 2 pre-boot recovery options and how they can be accessed via the FileVault 2 pre-boot login screen. This process uses a Reset Password wizard to help users recover from login problems at the FileVault 2 pre-boot login screen.
I recently learned that the FileVault 2 Reset Password wizard can also be manually launched while booted from the Recovery partition. For more details, see below the jump.
As part of working with OS X VMs in VMware Fusion and ESXi, I’ve regularly installed the VMware Tools and have even found ways to incorporate their installation into my build process. However, getting the latest VMware Tools installer into my VM building workflow has usually involved at least one manual step or having a system management tool handle the installation for me. I wanted something that was completely automated without needing to also install a system management client. My end goal was that I didn’t have to worry about doing anything; the latest VMware Tools for my OS X VM would just be installed into the VM as part of the build process.
After doing some research and testing, I have a solution that looks like it does just that. For more details, see below the jump.
At JAMF Nation User 2014, JAMF Software took the wraps off of a new product: Bushel. Bushel is a cloud-based MDM solution for managing Apple Macs, iPhones, iPads and iPod devices. It’s designed to be simple to use, so that a business can get their Apple devices managed without needing to invest in a complex solution which needs a specialized skill set.
Since Bushel’s current pricing model allows for up to three devices free, I was able to take Bushel for a test drive and document what the process of setting it up and working with it looks like. For more details, see below the jump.
As part of working with open source software on OS X, it’s often convenient to use a package manager to install open source packages. Good package managers are useful because they handle downloading the open source software you want, make sure that any related software dependencies get handled, and make it easy to keep the software you installed up to date.
The ones that I’ve worked with in the past have been the following:
pkgsrc has the following strengths:
- Easy to install
- Works on multiple Unix-based platforms
- Installs its software all within one dedicated location (/usr/pkg)
- Does not require the creation of dedicated local user accounts
- Installs software with root privileges
That last point was important to me because Homebrew doesn’t do that. Instead, Homebrew installs software with the ownership set to be the user who ran the installation command.
That characteristic of Homebrew has always made me crazy, but I freely admit that’s my own personal peeve. As with many things, I’m not going to tell folks what package manager to use if their choice is working well for them.
To aid with the installation of pkgsrc on OS X, I’ve written a script. For more details, see below the jump.
Apple has updated its Using the USB-C port and adapters on your MacBook (Retina, 12-inch, Early 2015) KBase article to provide more detail about USB Target Mode. One piece of information that jumped out at me was this section:
For reference, a USB-A connector looks like this.
Based on my reading of the KBase article, you will not be able to connect a 2015 MacBook in USB Target Disk Mode to a Mac with USB 2.0 or 3.0 ports and expect to be able to transfer data via Setup Assistant or Migration Assistant to the USB 2.0/3.0-equipped Mac.
There are a couple of workarounds for this limitation:
- Cloning the MacBook’s drive to an external drive and plugging that external drive into the USB 2.0/3.0-equipped Mac.
- Creating a Time Machine backup of the MacBook’s drive and accessing the Time Machine backup on the USB 2.0/3.0-equipped Mac.
Both of these workarounds should allow the MacBook’s data to be accessible by Setup Assistant or Migration Assistant.