Every so often, it’s necessary to resize the boot drive of an existing virtual machine. The process of resizing the VM’s boot disk from outside the VM is usually pretty straightforward:
1. Shut down the VM
2. Go into the VM’s drive settings
3. Resize it to the desired size
4. Power on the VM.
However, when the VM boots up, the disk space used by the OS won’t have changed.
However, the OS can detect that there is available unallocated disk space that it isn’t using.
Fortunately, this is a correctable condition and the fix can be applied without needing to shut down the VM or boot from another drive. For more details, see below the jump.
One of the practices that has historically helped Macs fit better into enterprise environments has been to bind Macs to Active Directory (AD) domains and use AD mobile accounts, using either Apple’s own AD directory service plug-in or a third-party product like Centrify. However, this practice has meant that the password for the mobile account is being controlled by a service located outside of the AD-bound Mac. This has led to problems in the following areas:
With the recent availability of tools like Apple’s Enterprise Connect and NoMAD, it’s now possible to provide the advantages of being connected to Active Directory to your Mac without actually having to bind your Mac to an AD domain. This has led to more environments not binding their Macs to AD and using either Enterprise Connect or NoMAD with local accounts.
With local accounts, all password management is done on the individual Mac. This means that problems with keychain and FileVault password synchronization are vastly reduced because the password change mechanism for a local account includes updating both the keychain and FileVault 2 automatically with the new authentication credentials.
For those shops that have been binding their Macs and using mobile accounts, but want to switch to the new local accounts + Enterprise Connect / NoMAD model, there is an account-related challenge to overcome:
How to transition from an AD mobile account, where the password is managed by AD, to a local account, where the password is managed by the individual Mac, with the least amount of disruption for your users?
To assist with this process, I’ve developed a script that can take an existing AD mobile account and migrate it to being a local account with the same username, password, UID, and GID. For more details, see below the jump.
In my shop, we’re not currently using Apple’s VPP program for purchasing applications from the Mac App Store (MAS). However, we do want to make it convenient for our users to be able to access and install some commonly used applications which are available from the App Store. Casper 9.4 and later natively supports providing access to MAS applications, but this approach is more focused on VPP-purchased applications. In my shop’s case, our customers are more likely to purchase apps from the MAS using Apple’s consumer payment model and then get reimbursed.
To help with this, I originally used a process similar to this one developed by Bryson Tyrell. I wanted to make the process more modular though, where I only needed to supply a URL from the MAS and have a scripted solution handle the rest. For more details, see below the jump.
As previously discussed, a number of folks in my shop use Clarivate Analytics’s EndNote bibliography software. Clarivate Analytics provides EndNote X8 with an installer application, but I need an installer package in order to easily deploy it to my customers. EndNote X8 was initially problematic in that regard, but I was able to write AutoPkg recipes for EndNote X8 to handle converting Clarivate Analytics’s installer application into a deployable installer package, including a recipe that would automate uploading the latest EndNote installers to my Casper server.
Once AutoPkg was able to provide an EndNote X8 installer package for deployment, the remaining hurdle was that the EndNote X8 installer from AutoPkg installs an unlicensed copy of EndNote and I needed to have installed copies of EndNote automatically use my shop’s EndNote site license.
Fortunately, EndNote X8’s volume license can be deployed just like EndNote X7’s volume license. The volume license is stored in as an invisible file named .license.dat in /Applications/EndNote X8 and it has a format that looks like this:
Company Name 1234567890 V2ZMQT6556P8WMH38MTQ6YSM8UXCCRYQ5MDS4WJGLKMP7RGSWECBCMT77556P8WCE8KMTQ6YSMNXJCCRYQ59MD9WJGLKMCSESSWECBCMB76556P8WCU3NMTQ6YSMLUYCCRYQ5MET8WJGLKMPSMJSWECBCM57F556P8WCU3CMTQ6YSM9DECCRYQ59XSCWJGLKMPNE9SWECBCMB79556P8WCH8KMTQ6YSMDXECCRYQ5MTSMWJGLKMPYRMSWECBCB7W7556P8W
Note: The Company Name part may show up twice in your .license.dat file.
With some additional testing, I found that I could remove an existing .license.dat file (if one was present) and replace it with my shop’s site license’s .license.dat file. That allowed me to use the EndNote X8 installer produced by AutoPkg by having Casper install it, then apply our site license file as a post-installation action. For more details, see below the jump.
It’s often useful to provide a way for everyone in your shop to be able to look up commonly used websites. Methods I’ve seen of doing this include:
- Wiki pages
- Bookmarks deployed to browsers
- Browser extensions
Another method is to use Casper’s Self Service plug-ins feature.
This makes it easy to set up website bookmarks, which then appear in a sidebar of Self Service.
The main drawback to this method is you can’t scope these bookmarks to appear only to certain users or computers. These will appear on on all managed computers and to all users. If you need to have one set of bookmarks available to Group A in your organization, and a different set of bookmarks appearing to Group B, the Self Service plug-ins feature may not be the best solution.
Fortunately, you can solve this scoping issue using Casper policies and Self Service. For more details, see below the jump.
Recently, I was alerted by Todd Houle that his infosec folks had identified an vulnerability with CasperCheck that should be addressed.
CasperCheck downloads a QuickAdd installer from a web server inside a .zip file and initially stores it in the /tmp directory. All users on the system have access to /tmp, so it was possible for an malicious unprivileged user to leverage a race condition to replace the downloaded .zip file with another .zip file with the same name.
Assuming that the replaced .zip file was valid and passed the check for being a valid .zip file, CasperCheck would then expand the contents of the replaced .zip file into the /var/root/quickadd directory. Assuming that the malicious unprivileged user had their own installer package stored inside the replaced .zip file, the next time that CasperCheck would determine that it needs to install the Casper agent via its cached QuickAdd installer, it would instead install that installer package in place of the expected QuickAdd package.
The vulnerability assumes that the QuickAdd package is being downloaded to a place where an unprivileged user can access it, so the implemented fix to this problem is to download it to a place where only root has access. Todd fixed the issue by changing the designated download location to the following:
To: $quickadd_dir/quickadd.zip, where the value of $quickadd_dir is /var/root/quickadd
Moving the download location to /var/root/quickadd means that the download is going to a location inside the root account’s home directory. Only root has write access to its home directory, which stops an account which doesn’t have root privileges from being able to swap out the .zip file.
Changes to CasperCheck:
Fortunately, the changes needed to implement this fix are minor and are in two places:
The quickadd_zip variable has changed:
To: $quickadd_dir/quickadd.zip, where the value of $quickadd_dir is /var/root/quickadd
The update_quickadd function has been updated, to move the following actions to be first:
- The creation of the /var/root/quickadd directory, if that directory is not already present
- The removal of existing files from the /var/root/quickadd directory
I’ve posted an updated CasperCheck script with the described changes to the following location:
If you’re a CasperCheck user, I recommend updating to the latest version at your earliest convenience.
The changes to the script can be seen here:
Hat tip: Thanks to Todd to alerting me to this issue and providing help to fix it.
To go along with a previous post about automating Oracle Java 8 updates, I’ve now posted a script to download and install the latest Java 8 Java Development Kit (JDK) from Oracle. Oracle has been releasing two separate versions of Java 8 simultaneously, so this script is designed to allow the user to set which version they want to install: the CPU release or the PSU release.
The difference between CPU and PSU releases is as follows:
- Critical Patch Update (CPU): contains both fixes to security vulnerabilities and critical bug fixes.
- Patch Set Update (PSU): contains all the fixes in the corresponding CPU, plus additional fixes to non-critical problems.
For more details on the differences between CPU and PSU updates, please see the link below:
For more information, see below the jump.