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.
VMware recently released a Virtual Machine Remote Console (VMRC) application for OS X users. This application is designed to complement the browser-based console for vSphere users by providing a native application for launching a remote console session with a vSphere-hosted virtual machine.
A nice bonus is that the VMRC application can also connect to an ESXi server which is using VMware’s free license for ESXi. This provides a way for users of free ESXi to access ESXi-hosted VMs via a remote console session without needing to run either the Windows vSphere client or VMware Fusion Professional. For more details, see below the jump.
Following the release of OS X 10.10.3, I noticed in my testing that I was no longer able to create Active Directory mobile user accounts using the /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount tool.
The process of using the createmobileaccount tool usually works like this:
- Open Terminal or run a script
- Run the following command with root privileges:
/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n network_account_username_goes_here
What normally happens is a new mobile account and home folder are then set up on the Mac for the network_account_username_goes_here account. On 10.10.3, I’m receiving an error indicating that the mobile account could not be created.
To try to narrow down if it was an issue specific to Active Directory account, I tested against both my shop’s Active Directory domain and OpenLDAP domain. In both cases, I received similar errors.
Active Directory on OS X 10.10.3
OpenLDAP on OS X 10.10.3
To verify that this was a 10.10.3-specific issue, I re-ran my tests in a 10.10.2 VM. On 10.10.2, my results were what I expected: A new mobile account and home folder were created on the VM.
Mobile account creation on OS X 10.10.2
Mobile account creation via the OS loginwindow
One piece of good news is that this does not appear to affect the creation of mobile accounts via the loginwindow. In my testing against my Active Directory domain, automatic mobile account creation via the loginwindow appears to work fine.
The process I used in my testing looked like this:
- Bind test Mac running OS X 10.10.3 to my shop’s Active Directory domain, with mobile account creation enabled in the Apple Active Directory plug-in’s settings.
- Verify that the test account was not present as a mobile account on the Mac
- Log in with the test account’s credentials at the loginwindow
The results were what I expected: A new mobile account and home folder were created on the test Mac.
To help get this issue fixed, I’ve filed a bug report. For those interested in duping it, it’s bug ID 20482382.
Update 4-10-2015: My bug report has been closed as a duplicate of bug ID 20295898. If you want to file a bug report that dupes mine, please use the following bug ID to do so:
Bug ID 20295898
For those interested in the details, I’ve also posted the bug report to Open Radar:
Starting in Mac OS X 10.7.x, Apple started hiding the Library directory stored inside an account’s home folder. I’ve written a script to un-hide it on my own Macs, but I recently came across a couple of Apple-supported ways to access and unhide the ~/Library directory. For more details, see below the jump.
Oracle has released a new update for Java 8, but has continued their recent trend of not bumping the version number. Oracle has put out a new build of Java 8 but didn’t bump the version number from Java 8 Update 40, which makes this the third release of Java 8 Update 40.
At this point, it appears that Oracle is now providing the install application across the board. When you update an existing Java installation on OS X via Oracle’s Java update mechanism, you will receive Oracle’s install application for Java along with the selected option to install the Ask.com browser add-ons. If you download an installer from Java.com, you will also receive this install application.
While the Oracle install application is not a standard installer package, it appears that Oracle had stored an installer package for Java 8 within the install application at the following location:
The JavaAppletPlugin installer package is digitally-signed and does not include the Ask.com browser add-ons.
The difference between the three Java 8 Update 40 releases
Early March’s Java 8 Update 40 (released on March 4, 2015): Java 8 Update 40 build 25 (188.8.131.52)
Mid-March’s Java 8 Update 40 (released on March 13, 2015): Java 8 Update 40 build 26 (184.108.40.206)
Just-Past-Mid-March’s Java 8 Update 40 (released on March 16, 2015): Java 8 Update 40 build 27 (220.127.116.11)
If you have Java 8 Update 40 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 40 build 25, the following string will be returned:
If you have Java 8 Update 40 build 26, the following string will be returned:
If you have Java 8 Update 40 build 27, the following string will be returned:
For more details, see below the jump.