On OS X 10.10.x and later, disabling Gatekeeper does not mean it is permanently off. After a set amount of time (currently 30 days), Gatekeeper will automatically re-enable itself with the Allow apps downloaded from: Mac App Store and identified developers setting.
I was able to track down which part of the OS this was coming from and it looks like it’s defined as part of syspolicyd:
After doing some research, it looks like Gatekeeper’s automatic re-enablement function can be disabled by running the following command with root privileges:
defaults write /Library/Preferences/com.apple.security GKAutoRearm -bool false
This would allow Gatekeeper to be set to Allow apps downloaded from: Anywhere and have it stay that way.
For those who want to set this with a management profile, I’ve created a .mobileconfig file and posted it here on Github:
Update – 7-31-2015: My colleague Tom Burgin points out that this may not be manageable via a profile after all, due to the way Apple has set the value that it’s reading:
If a management profile isn’t being respected, the defaults command listed above is the way to apply this to machines.
I’ve filed a bug report about this. For those interested in duping this bug, the bug report ID is 22094327. I’ve also cross-posted it to OpenRadar:
I do a lot of my application testing in VMs, so when Firefox 39.0 came out, it went into my test environment and I built a new VM to check it out.
Firefox 39.0 looked like this when I launched it in my test VM.
As part of my testing workflow, I also installed Firefox 39.0 onto a couple of actual Macs.
Firefox 39.0 looked like this when I launched it on those machines.
As you can see, two very different results were discovered as part of my testing. After a few rounds of “It’s broken in the VM, retest, it’s still broken, retest on my laptop, no problem, repeat,” I finally tracked down a Mozilla bug report that indicated that the issue was not specific to my environment and gave me the potential scope of the issue. For more information, see below the jump.
I recently learned that there are hidden text editing options for the Casper JSS’s script editor. To access these options, do the following:
1. Log into your JSS
2. Go to Computer Management: Scripts
3. Bring up the script editor in your browser
4. Click inside the text entry area of the script editor
5. Press Command + comma (⌘ + ,)
6. The JAMF script editor’s text editing options will appear.
There are some issues to be aware of:
- Changes made are global and will affect all currently logged-in users
- The settings changes are not persistent across sessions. If you log out or are logged out, you will need to re-setup your settings.
Ideally, changes made to the text editing preferences would be:
A. Per-user instead of affecting all users
B. Persistent, so that changes to these settings would not be lost on logout.
There’s an existing feature request on JAMF Nation which requests these changes. If you agree that this would be beneficial, please vote it up.
I had previously written about deploying Sophos Enterprise Anti-Virus for Mac 9.2.x, but I was recently notified that the method I had been using would stop working in a future release of Sophos.
Sophos has a KBase article about pre-configuring their installer application with the AutoUpdate settings, but I also wanted to be able to deploy Sophos using an installer package. Using the information from the KBase article, I was able to update my existing method for building an installer package for deploying Sophos Enterprise Anti-Virus for Mac 9.2.x. For the details, see below the jump.
When Yosemite was released in October 2014, one of the changes it introduced was including a new FileVault 2 enablement option in Apple’s Setup Assistant. This option encouraged new users of Yosemite to enable FileVault 2 encryption and had the choice to enable FileVault 2 selected by default.
When the encryption process began, a significant issue then appeared for a number of users where the Mac would report Encryption paused during the encryption process, then never resume the encryption process.
This produced a situation where the Mac could not complete encryption, but would not decrypt either because the encryption process had not completed. The only fix appeared to be deleting the existing CoreStorage volume, which addressed the issue at the cost of deleting everything stored on the boot drive.
Fortunately, OS X 10.10.3 includes a fix that should stop this issue from occurring on OS X 10.10.3 and later. There is also now a procedure that should fix Macs still affected by this problem. For more details, see below the jump.
I use screensharing quite a bit, both at home and at work, to connect to machines. As part of this, my process for connection has looked something like this:
1. Verify I’m on the right network.
2. On the Mac I’m connecting from, under the Go menu, select Connect to Server…
3. In the Server Address: line, enter the address of the Mac which I want to remotely connect to:
4. Logging in by entering my authentication credentials into the screensharing login window’s username and password blanks.
5. Assuming username and password are accepted, the remote Mac’s screen is displayed.
As with any task I perform frequently, I wanted to shave some time off of this process but I didn’t want to save the screensharing authentication info to my keychain (personal preference).
Fortunately, there’s an easy way to pre-define the username for the screensharing login window by adding username@ to the vnc:// address:
The username should now be filled in when the screensharing login window appears.
Since you can also make bookmarks in the Connect to Server window, my next step was saving a bookmark for the updated screensharing address.
It’s simple enough to do, but not having to manually enter the username will save me at least a few seconds every time I connect to a remote machine’s screen.
IT disasters are unpleasant, and can take many forms. However overwhelming the idea of a possible disaster may be, it is crucial to have a well-formed plan in place. Many IT professionals don’t have a good grasp on how to write disaster recovery documentation, which can lead to confusion and problems when disaster strikes.
To give an idea of how good disaster recovery documentation can save the day, I’d like to share a story of how good documentation not only saved the day, but also saved my vacation.
A few years ago, I was riding the airport shuttle on my way to a cruise ship vacation. While en-route, I got a call from my workplace where the person calling said that they had a power outage at our main datacenter. I was gone, my alternate was stuck in traffic, what should they do? I said “Can you find the Mac server rack?” Yes, they found it. “Do you see the packet marked Emergency Server Startup and Shutdown Procedures?” Yes, they did. “OK, open that and start reading. It’ll walk you through the process.” I talked with them for a few more minutes to make sure that they were OK, then I said goodbye, ended the call and prepared to board my plane.
Without that packet attached to the front of the server rack, which I had made sure was updated the day before with the latest information, I might have been trying to talk someone through the shutdown procedure for about fifteen servers and twelve RAID arrays over the phone up until the moment that the flight attendant yanked my phone out of my hand because the plane needed to take off.
There are a few lessons to take from this story.
Q: Where was I when the disaster occurred?
A: Off-site and without access to either a computer or a way to connect back to the work network.
Q: Where was the other person who had been trained on our disaster recovery process?
A: Off-site and unavailable.
Q: Who was the person on the phone?
A: Someone who wasn’t trained in our disaster recovery process.
Q: What allowed the person on the phone to successfully bring down my servers?
A: Accurate and easily-understood documentation that was placed for ready access.
Q: What was not affected by this disaster?
A: My vacation.
With these lessons in mind, see below the jump for my advice on how to write disaster recovery documentation.