As part of preparing for a presentation, it’s often handy to be able to hide the icons on your desktop so that folks viewing the presentation aren’t distracted by what you have stored on your desktop.
To aid with this, there are defaults commands which can be run to hide or (if hidden) show the icons on your desktop.
To hide your desktop’s icons, run the command shown below:
defaults write com.apple.finder CreateDesktop -bool false
To show your desktop’s icons, run the command shown below:
defaults write com.apple.finder CreateDesktop -bool true
After running the appropriate command to either show or hide the desktop’s icons, the Finder needs to be restarted so that it can display the changes. You can do this one of two ways:
1. Log out, then log back in
2. Run the following command:
Since I usually remember only at the last minute that I should hide my desktop icons, I’ve also built an Automator application named Show or Hide Desktop Icons.app to assist me with showing or hiding my own desktop’s icons. For more details, see below the jump.
Starting in OS X El Capitan and iOS 9, people trying to set up a PPTP VPN connection on their iOS device or on their Mac would get a warning that looked like this:
The reason for these warnings is that a number of security vulnerabilities have been found in this VPN communications protocol. These warnings have been Apple’s way of encouraging their customers to stop using PPTP for their VPN connections and move on to other more secure VPN protocols.
As part of preparing for the release of macOS Sierra and iOS 10, Apple has publicly announced they’re moving from warning folks about PPTP to removing PPTP support altogether from Apple’s built-in VPN client. In place of PPTP, Apple is again recommending the use of other VPN communications protocols that are more secure.
For those who will still need to access PPTP VPNs, you may be able to use a third-party client to do so on macOS Sierra. A couple of third-party VPN clients I’m aware of which currently support PPTP on OS X El Capitan are Shimo and VPN Tracker.
A while back, I built an Automator application named First Boot Package Install Generator.app. It’s designed to generate installer packages, where the generated packages in turn serve as a delivery mechanism to enable other installer packages to be installed when a Mac boots up.
As part of the process of installing the other installer packages, an application named LoginLog is supposed to open over the login window and display a log of what actions are taking place, what is being installed and whether that particular installation succeeded or not.
For the most part, this process of launching LoginLog and displaying the log works as designed but it was brought to my attention that there was one scenario where LoginLog did not appear as expected. When a firstboot package created by First Boot Package Install Generator.app was installed onto a new installation of OS X El Capitan, LoginLog did not appear over the Setup Assistant.
The reason it didn’t appear is because the LaunchAgent for LoginLog is triggered by the Mac being at the login window.
However, Apple’s Setup Assistant on El Capitan no longer runs over in the context of the login window. Instead, it runs in the context of an account named Setup User.
In order to have LoginLog appear again in this scenario, I needed to develop a method which could accomplish two tasks:
- Suppress Apple’s Setup Assistant during the time when I wanted the LoginLog application to appear.
- Avoid interfering with an otherwise desired launch of the Apple Setup Assistant.
For more details, see below the jump.
This week, I’m out in San Francisco as an attendee of Apple’s WWDC 2016 conference. As part of this, I’m taking notes during the labs and sessions. Due to wanting to stay on the right side of Apple’s NDA, I’ve been posting my notes to Apple’s developer forums rather than to here.
To make it easier for Mac admins to access them, I’ve set up a post in the forums where I’ve linking the various forum posts with my notes. It’s available via the link below:
As part of making sure my customers have the latest version of their applications available, I use AutoPkg, JSSImporter, and AutoPkgr to ensure that as new software updates are released, they are automatically uploaded to my shop’s Casper server.
In the case of certain applications, the process of packaging can change an application which is fine when installed via a drag-and-drop installation method to one which is broken when installed via an installer package. This is due to Apple’s pkgbuild tool erroneously stripping certain metadata used by the application’s code signing. If an application is set to check for that metadata as part of its code signature verification process, this can result in the application reporting that it’s been damaged and not launching.
An example of this which I’ve run across is Labtiva’s Papers.app, a reference library application designed to collect, organize and enable citation of scientific journal articles and other reference materials. The Papers.app installation method provided by Labtiva is a drag-and-drop install, where the customer is supposed to copy the application from a disk image and into a convenient location (like /Applications.)
When the application is installed by copying it into place, there are no problems with the application and it launches normally.
When Papers.app is packaged, then installed via an installer package, an error message will appear at first launch to report that the application is damaged.
Why the difference? In the case of Papers.app, the verification of the application’s code signing appears to include verification of certain metadata which pkgbuild appears to remove as part of the packaging process. For more details, see below the jump.
An issue that I see occasionally on new Macs is that they’re set to use a language different than mine when I take them out of the box. In my case, the alternate language is most often set to French (for unknown reasons), rather than being set to US English like I’m expecting.
OS X normally handles this issue as part of the installation process, by asking which language is preferred and using that for the OS.
However, when I set up new machines, I’m past the point of selecting the language that way. Fortunately, there are alternate ways to change the language used at the login screen. For more details, see below the jump.
One of the challenges Mac admins have to deal with are Mac application installers which don’t follow one of the following models:
In many cases, these alternate installers take the form of applications which may or may not have options for installing via command line. For those that do not have the option of command line installation, the only real option is to install the application in question, then re-package it as either a drag-and-drop install or an installer package.
However, for those installer applications that do support command line installation, this opens up the option of embedding the installer application inside an installer package and using a postinstall script to run the necessary commands for the installer application to install its files onto the Mac. I’ve used this workflow several times in the past, with some examples linked below:
- Creating a DNAStar Lasergene 13.x installer
- Revisiting Sophos Enterprise Anti-Virus for Mac 9.2.x deployment
- Deploying Sophos Anti-Virus Home Edition for Mac 9.2.x for personal use
These examples have been manually built by me on an as-needed basis as new versions are released, but wherever possible, I want to automate this process using AutoPkg. Thanks to being able to study a recently-built .pkg recipe for AccuBarcodePro created by @foigus, I was able to build recipes for AutoPkg which handle downloading and packaging the following installer applications:
For more details, see below the jump.