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:

1. Suppress Apple’s Setup Assistant during the time when I wanted the LoginLog application to appear.
2. Avoid interfering with an otherwise desired launch of the Apple Setup Assistant.

For more details, see below the jump.

To accomplish both tasks, I added functionality to the firstboot script to check to see if the /var/db/.AppleSetupDone file is present on the boot drive when the Mac starts up. The reason this check has been added is that when the /var/db/.AppleSetupDone file is present at startup time, Apple’s Setup Assistant is prevented from running. Based on the results of the check, the following actions are performed:

• If the /var/db/.AppleSetupDone file is already present, nothing needs to be done and the script proceeds.
• If the /var/db/.AppleSetupDone file is not present, the script will add add the /var/db/.AppleSetupDone file and an additional /var/db/.firstboot.delete.AppleSetupDone file:

https://github.com/rtrouton/First_Boot_Package_Install_Generator/blob/master/application_source_components_and_graphics/firstboot_scripts/firstbootpackageinstall_noswupdates.sh#L20-L22

Once both the /var/db/.AppleSetupDone and /var/db/.firstboot.delete.AppleSetupDone files have been added, the Mac will reboot so that the presence of the /var/db/.AppleSetupDone file can be detected by the OS:

https://github.com/rtrouton/First_Boot_Package_Install_Generator/blob/master/application_source_components_and_graphics/firstboot_scripts/firstbootpackageinstall_noswupdates.sh#L28

In turn, the functionality to add both the /var/db/.AppleSetupDone and /var/db/.firstboot.delete.AppleSetupDone files is triggered only when the script detects the presence of the directory which stores the installer packages which are being installed at startup.

https://github.com/rtrouton/First_Boot_Package_Install_Generator/blob/master/application_source_components_and_graphics/firstboot_scripts/firstbootpackageinstall_noswupdates.sh#L101-L106

The reason that the /var/db/.firstboot.delete.AppleSetupDone file is added is to provide verification that the firstboot script added the /var/db/.AppleSetupDone file to suppress the Apple Setup Assistant, which in turn allows the LoginLog application to launch and display the log over the login window.

If both the /var/db/.firstboot.delete.AppleSetupDone and /var/db/.AppleSetupDone files are present, both files are later removed by the script to avoid interfering with an otherwise desired launch of the Apple Setup Assistant. If only the /var/db/.AppleSetupDone file is present, no action is taken to delete it:

https://github.com/rtrouton/First_Boot_Package_Install_Generator/blob/master/application_source_components_and_graphics/firstboot_scripts/firstbootpackageinstall_noswupdates.sh#L157-L168

To help Mac admins verify that the status of the /var/db/.AppleSetupDone file is what they expect, an Apple Setup Assistant status check has also been added to the log displayed by LoginLog.

If the /var/db/.AppleSetupDone file is not present after all the packages have been installed, a message is displayed that the Apple Setup Assistant will appear at the next reboot.

If the /var/db/.AppleSetupDone file is present after all the packages have been installed, a message is displayed that the Apple Setup Assistant is set to be skipped and will not appear after the next reboot.

For more information, please see the release notes for First Boot Package Install Generator 1.5:

https://github.com/rtrouton/First_Boot_Package_Install_Generator/releases/tag/1.5

For the latest version of First Boot Package Install Generator.app, please see the link below:

https://github.com/rtrouton/First_Boot_Package_Install_Generator/releases/latest

For those who want to build a customized First Boot Package Install Generator.app for their own use, the components and scripts are available on my Github repo.

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:

iOS:

OS X:

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.

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:

killall Finder

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.

Using Show or Hide Desktop Icons.app

1. If needed, download the Show_and_Hide_Desktop_Icons zip file from the installer directory in my GitHub repo.

2. Once downloaded and installed, double-click on the Show or Hide Desktop Icons application in /Applications.

3. Depending on if your icons are visible or hidden, the following actions take place:

Visible icons:

1. The defaults command to hide the icons is applied.
2. The Finder process is restarted.
3. A dialog window notifies you that the desktop icons are now hidden.

Hidden icons:

1. The defaults command to make the icons visible is applied.
2. The Finder process is restarted.
3. A dialog window notifies you that the desktop icons are now visible.

How Show or Hide Desktop Icons.app works

Show or Hide Desktop Icons.app is an Automator application that uses shell scripting behind the scenes to run the needed commands. When the application is launched, the following process takes place:

The script inside the Automator application determines if the desktop icons are set to be hidden or visible by checking for the following conditions:

Condition:

The CreateDesktop value in the user’s ~/Library/Preferences/com.apple.finder.plist file is either not explicitly set or set with a boolean value of true.

Action:

1. The defaults command to hide the icons is applied.
2. The Finder process is restarted.
3. A dialog window notifies you that the desktop icons are now hidden.
4. The script exits.

Condition:

The CreateDesktop value in the user’s ~/Library/Preferences/com.apple.finder.plist file is set with a boolean value of false.

Action:

1. The defaults command to make the icons visible is applied.
2. The Finder process is restarted.
3. A dialog window notifies you that the desktop icons are now visible.
4. The script exits.

The shell script inside looks like this:

The total workflow looks like this:

For those interested, all Show or Hide Desktop Icons.app components and scripts are available via the GitHub repo linked below:

https://github.com/rtrouton/Show-or-Hide-Desktop-Icons

For those who wanted a copy of my security talk at X World 2016, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/XWorld2016SecurityPDF

Keynote – http://tinyurl.com/XWorld2016SecurityKeynote

One of the features of Apple’s QuickTime is that it allows a video recording to be made of your screen. This allows whatever you’re doing on the screen to be captured in a video and played back later.

To use QuickTime Player on OS X El Capitan to make a screen recording, use the procedure described below:

1. Launch QuickTime Player

2. In the File menu, select New Screen Recording.

3. In the Screen Recording window, click on the arrow drop-down menu and select the desired options.

4. Set up the conditions that you want to capture then click the Record button.

5. Select the desired option for recording either a portion of the screen, or the whole screen.

6. When you’re ready to stop recording, click the Stop button in the menubar.

Note: You can also press Command-Control-Escape on the keyboard to stop the recording.

By default, this procedure will work to record your Mac’s primary display but you can also use it to record an alternate display. For more details, see below the jump.

To create a screen recording of an alternate display, do the following:

1. Follow steps 1 – 4 of the procedure described above.

2. Move your mouse to the alternate display. You should see the recording options notification message appear on the alternate display.

3. Select the desired option for recording either a portion of the alternate display’s screen, or the whole screen.

4. When you’re ready to stop recording, locate and click on the Stop button in the menubar.

Note: Be aware that the Stop button may be in the menubar of the Mac’s primary display.

As part of some research which I’m doing on Mac filesystems, I wanted to see if it was possible to get Apple’s System 1 running on OS X El Capitan. The reason that I am specifically interested in System 1 is that this OS used Apple’s shortest-lived filesystem: Macintosh File System.

After discussing the issue, my colleague @mikeymikey pointed me in the direction of using the Mini vMac emulator application to accomplish this. He also pointed me towards the correct places where I could download a System 1 disk image and the needed Mac ROM file.

With this information, I was able to get System 1 up and running inside of the Mini vMac emulator. For the details, see below the jump.

1. Download Mini vMac, the System 1 disk image, and the Mac ROM file.

2. Uncompress the System 1 disk image and ROM file.

The System 1 disk image and ROM file are compressed using a Stuffit archive format which OS X’s built-in decompression utility is unable to open. I recommend using The Unarchiver to uncompress these files.

3. Put Mini vMac, the System 1 disk image and the ROM file together in one directory.

Note: Having all three in the same directory is necessary so that the ROM file is automatically detected when Mini vMac launches the OS from the System 1 disk image.

4. Launch Mini vMac. By default, no startup disk option is selected so a window will open and display a floppy disk icon with a blinking question mark.

5. To select a startup disk, click on the File menu and select Open Disk Image…

6. Select the System 1 disk image and click the Open button.

7. System 1 should boot within the Mini vMac window.

For those who wanted a copy of my documentation talk at at X World 2016, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/XWorld2016DocPDF

Keynote – http://tinyurl.com/XWorld2016DocKeynote

In some environments, it may be desirable to give users admin rights while restricting those users from being able to run commands with root privileges while using the command line.

A way to achieve this “admin user in the GUI, standard user on the command line” method is to edit the /etc/sudoers file. This is the configuration file referenced by the sudo command line tool, which allows a user with the correct sudo rights to execute a command with root privileges, or using another user account’s privileges.

By default, all user accounts with admin rights on both OS X and macOS have full rights to use the sudo tool. By removing those accounts’ rights for sudo from the /etc/sudoers file, user accounts with admin rights will not be able to run commands with root privileges using the sudo tool. For more details, see below the jump.

Editing /etc/sudoers

To edit the /etc/sudoers file safely, make sure to use the visudo utility. This application will do a sanity check on your changes to /etc/sudoers before putting them into production.

By default, visudo uses vi as its text editor. If you want to use an alternative text editor, this can be achieved by setting the EDITOR environment variable to an alternate value, then launching visudo.

For example, if you want to use TextWrangler to edit the /etc/sudoers file, make sure you have TextWrangler’s command line tools installed and then run the following command with root privileges:

EDITOR=edit visudo

Alternatively, if you want to use the nano editor (also known as pico), run the following command with root privileges:

EDITOR=nano visudo

Removing the admin group’s entry from the /etc/sudoers file

To remove the sudo rights for all users with admin privileges, use the procedure below:

1. Use visudo to access the /etc/sudoers file
2. Navigate to the User privilege specification section.

In that section, you should see a line like this:

%admins      ALL=(ALL) ALL

The % symbol indicates that a group is being referenced; in this case the group named admin. Members of the admin group are the ones granted admin rights, so commenting out or removing this entry means that members of that group will no longer have rights to use the sudo tool.

3. To remove the entry for the admin group, you can take either of the following actions:

A. Comment out that line

B. Delete the line

Note: Make sure to leave the following entry intact and unedited:

root      ALL=(ALL) ALL

Deleting that entry would mean that not even the root user would be able to use the sudo tool.

Adding entries to the /etc/sudoers file

After removing the entry for the admin group from the /etc/sudoers file, you may want to add additional entries for specific users or groups. For example, you may not want to grant sudo rights to all admin users but you do want to grant them to the local admin account and the primary user of the Mac in question. In this case, we’re assuming that the local admin and the primary user have the following accounts:

Local admin account: admin
Primary user’s account: username

Adding the following entries to the /etc/sudoers file would allow you to give full sudo rights to the admin and username accounts:

admin      ALL=(ALL) ALL
username      ALL=(ALL) ALL

Once the desired edits have been made, save the changes.

The new permissions will take effect immediately after the changes have been saved.

For more information on configuring sudo, I recommend referencing the sudo manpage or Apple’s documentation for sudo.

While working with different versions of Mac OS X and macOS, it’s often been useful to me to be able to export the contents of a particular command line utility’s Unix man page to a plain text file. Man pages are the built-in documentation method available in Unix-based systems, so Apple documents how to use the various command line tools used by the operating system using this documentation method.

Exporting to a plain text file allows me to compare macOS Sierra’s man page for a particular command line utilty to a exported copy of the same utility’s man page from OS X El Capitan and see where changes to the man page have been made. This comparison is made by using diff, or other file comparison tools like Kaleidoscope, which helps me quickly spot where Apple has made changes to their documentation.

To export man pages to a plain text file, I use the col command line utility to read the contents of the man page in using stdin, then export out to a plain text file using stdout As an example, here’s how to use col to export the diskutil man page to a new plain text file named diskutil.txt:

man diskutil | col -bx > /path/to/diskutil.txt

In this case, col‘s -b and -x functions are used to make sure that the formatting for the diskutil man page remains intact when exported to the plain text file.

As part of the process of deploying Macs, it is occasionally necessary to image or re-image them with a disk image containing the latest version of OS X or macOS. When I need to create disk images for use in my shop, I use an application named AutoDMG to generate them. AutoDMG is an open-source tool written by Per Olofsson which enables the creation of never-booted OS X or macOS images for deployment.

Why is creating a never-booted disk image important? When you boot a Mac for the first time, the OS will create a number of system-specific settings, temporary files and other associated system-specific data. Because this data is specific to an individual Mac, it doesn’t always transfer well to other Macs and may cause some quirky issues. By creating a never-booted disk image, you avoid the issue entirely because those files aren’t created as part of the image building process and consequently do not get transferred to Macs which are set up using the disk image.

When building an image using AutoDMG, the best approach is to build an image containing just the operating system and available updates included in the image. While you can also choose to include other software installers in your image build process, a lot of software installers won’t apply correctly to the image because the affected installers use scripts and other functionality which do not run properly when run as part of AutoDMG’s image creation process.

Because of this behavior, I recommend planning to install software as a post-imaging task as opposed to including it in your AutoDMG-generated disk image. For those interested, additional information on this topic is available from the Getting Started section of the AutoDMG wiki.

For more details on how AutoDMG can be used to build images, please see below the jump.

Before building a disk image using AutoDMG, you should prepare a convenient Mac or a virtual machine to act as an AutoDMG build machine. To accomplish this task:

a. Make sure the Mac or virtual machine is running the same version of OS X or macOS that you want to build a disk image of. If you want to build a disk image for OS X 10.11.6, your build Mac must be running 10.11.6.

b. Download and install the latest version of AutoDMG onto the Mac in question.

c. Download the installer for the relevant OS version onto the Mac in question.

Once you have completed the necessary preparations, see below for the process of building a disk image containing just the operating system and all of the currently available software updates.

1. Launch the AutoDMG application.

2. Drag and drop the relevant OS installer into AutoDMG’s source box.

AutoDMG may offer OS software updates to install as part of the image build process. At this point, you have the following options:

To skip including the available software updates in your image:

a. Uncheck the Apply Updates box.

To have the available software updates included in your image:

a. Check the Apply Updates box.

b. Click the Download button

c. Wait for all of the available updates to completely download.

d. Once all the available updates are downloaded, the Download button will appear as grayed-out.

For the purposes of this example, the available software updates are being included in the disk image.

3. Once the decision to include or not include updates has been made, click the Build button.

4. AutoDMG will suggest a name for your image based on the OS version and build number. Change the name as desired, as well as choosing a convenient location to save the disk image.

Note: By default, AutoDMG will include as part of the filename the correct file extension (.hfs.dmg) for DeployStudio.

5. When prompted, authenticate with an admin account to start the build.

6. AutoDMG will create a disk image and install the desired operating system on it.

Note: Even on a fast machine, this build process will take at least 10-15 minutes.

7. Once the image has been completed, a notification message will appear.

If needed, click the Reveal button to show the location of the newly-created disk image.

The complete process should look similar to what is shown below.

Note: The video has been edited to artificially reduce the amount of time it took to build a disk image. Run time of the pre-edited video was twenty-one minutes, forty seconds.

As part of the process of deploying Macs in my shop, it is occasionally necessary to image or re-image them with a disk image containing the latest version of OS X or macOS. To assist with making sure that the Mac’s recovery partition is correctly applied as part of the imaging process, an installer package which installs or repairs recovery partitions is installed as part of the imaging process.

When I need to create recovery partition installers, I use an application named Create Recovery Partition Installer.app to generate them. Create Recovery Partition Installer.app is an open-source tool written by Per Olofsson that lets you create an installer package that creates and updates recovery partitions on boot drives for both OS X and macOS.

For more details on how Create Recovery Partition Installer.app can be used to build recovery partition installers, please see below the jump.

Before building a disk image using Create Recovery Partition Installer.app, you should prepare a convenient Mac or a virtual machine to act as an Create Recovery Partition Installer.app build machine. To accomplish this task:

a. Download and install the latest version of Create Recovery Partition Installer.app on the Mac in question.

b. Download the installer for the relevant OS version for the recovery partition installer.

c. Launch Create Recovery Partition Installer.app. The reason to do this is that when Create Recovery Partition Installer.app launches for the first time, it downloads new copies of software components which it then uses as part of the build process for recovery partition installer packages.

Once you have completed the necessary preparations, see below for the process of building a recovery partition installer. As an example, the process shown is building a recovery partition installer for OS X 10.11.6.

1. Launch Create Recovery Partition Installer.app.

2. Drag and drop the relevant OS installer into the source box.

3. Create Recovery Partition Installer.app will suggest a name based on the OS version for the installer package.

Change the name as desired, as well as choosing a convenient location to save the installer package to, then click the Save button.

4. Create Recovery Partition Installer.app will create a recovery partition installer and store it in the requested location.

5. Once the recovery partition installer build process has been completed, click the Quit button.

The complete process should look similar to what is shown below.

The good folks behind X World have now posted the session videos from X World 2016. All are accessible from the X World 2016 YouTube playlist page, which is available via the link below:

https://www.youtube.com/playlist?list=PLUzsToqd-eE8-yMclT6qzh2lUP-XI0uvD

As all the session videos have been posted to YouTube, I’ve linked my OS X Security: Defense in Depth session here:

The Documentation – Why All The Cool Kids Are Doing It session is linked here:

An issue that can pop up for new Mac admins is whether or not to enable the root account on the Macs in your environment. By default, the root account on OS X and macOS is a disabled account with the following settings:

Display name: System Administrator
Account name: root
UID: 0
Home directory: /var/root
User shell: /bin/sh

The root account is the superuser for a Unix-style operating system like OS X and macOS and Unix is designed to let the root account have total access to everything. When asking what root can do on a system, it may be better to ask what root cannot do because that list is very, very short. Because the root account has enormous power on a Unix system, you may believe that enabling the root account and using it for your system administration tasks is a no-brainer.

In fact, the opposite is the case: It’s better to leave the root account disabled and not use it for system administration.

Why should you avoid logging into the root account and running tasks from there?

• Mistakes happen – When logged in as the root account, you have total access to the system and anything you run while logged in as root will just happen. That also means you can do a lot of damage if you make a mistake.
• Malware and software bugs – Being logged in as the root account means that all the applications you’re using are running with the root account’s privileges. That means every vulnerability and bug in those applications can potentially cause havoc on your system because anything that’s executing an undesired behavior or exploiting a vulnerability in a particular application is doing so using the root account’s rights to go anywhere and do anything on your system.
• Auditing: If multiple people are logging into the root account and using it for system administration, that means that the account in question isn’t necessarily tied to a single person and actions taken while logged into the root account aren’t necessarily logged. That makes it harder to figure out after the fact who did what if there’s a problem.
• It’s not necessary: The sudo command line tool is available and installed by default on both OS X and macOS. sudo is a Unix program which allows a user with the correct sudo rights to execute a command using the security privileges of another user account, with the root account’s security privileges being used by default.

Using sudo is safer than using the root account for the following reasons:

• Nobody needs to know the root account’s password – sudo prompts for the current user’s password and will check to see if the user which is trying to use sudo has the necessary rights for sudo to run the requested commands with root privileges.
• The granting of root privileges is temporary – By default, sudo will time out after fifteen minutes and will require re-authentication before running commands again.
• Only those commands run via sudo are using root privileges – Only the commands run using sudo will be run with root privileges. Meanwhile, commands run without sudo are being run without root privileges, which reduces the potential for damage from making a mistake.
• sudo use is logged – When a command is executed using sudo, the command and the account which used sudo to run it are logged. Likewise, unsuccessful attempts to run commands with sudo are also logged. This provides an easy way to look up which commands were run and who ran them.

For more information on using sudo, see below the jump.

By default, all user accounts with admin rights on both OS X and macOS have full rights to use the sudo tool. What this means is that any user with admin rights can run commands using the root account’s security privileges without needing to be logged in as the root user. To run commands with the root account’s privileges while logged in as a user with admin rights on OS X or macOS, you would add sudo before the rest of your command in Terminal.

For example, you can use the procedure shown below if you want to check the current date by running the date command with root privileges:

1. Open Terminal

2. Run the command shown below:

sudo date

3. Authenticate with your account’s password when prompted.

Once the account’s password has been provided and sudo has verified that the account in question has the necessary sudo rights, the command should run.

If this is the first time that sudo has been run for this account, you will receive a warning similar to that shown below in addition to being prompted for your password.

If sudo checks and finds that an account does not have the necessary rights, the user is notified that the attempt will be reported and the command is not run.

To check to see which commands have been run with sudo, you can check the relevant log. On OS X El Capitan, successful and unsuccessful use of sudo is logged to the following location:

/var/log/system.log

This log can viewed in the Console application, available in /Applications/Utilities.

Please see below for examples of successful and unsuccessful sudo use being logged.

Successful:

Unsuccessful:

System Integrity Protection and the root account:

One other issue to be aware of is that on OS X El Capitan and later, the root account itself has had its power limited by Apple’s System Integrity Protection (SIP). SIP is an overall security policy with the goal of preventing system files and processes from being modified by third parties. Among other goals, it is designed to limit the power of root and to protect the system even from the superuser. For more information about SIP and how it works, please see the link below:

https://derflounder.wordpress.com/2015/10/01/system-integrity-protection-adding-another-layer-to-apples-security-model/

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:

http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html

For more information, see below the jump.

The script below will download a disk image containing the latest version of the Java 8 JDK from Oracle and install the JDK using the installer package stored inside the downloaded disk image.

How the script works:

1. Uses curl to download a disk image containing the latest Java 8 JDK installer from Oracle’s web site
2. Renames the downloaded disk image to java_eight_jdk.dmg and stores it in /tmp
3. Mounts the disk image silently in /tmp. The mounted disk image will not be visible to any logged-in user.
4. Installs the latest Java 8 JDK using the installer package stored inside the disk image.
5. After installation, unmounts the disk image and removes it from the Mac in question.

I’ve posted the script to my GitHub repo at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/install_latest_oracle_java_8_jdk

This script is also available as two separate payload-free installer packages, compressed and stored as .zip files inside the payload_free_installer directory:

• payload_free_installer/install_latest_oracle_java_jdk_8_cpu_version – Installs the latest Oracle Java JDK 8 CPU version
• payload_free_installer/install_latest_oracle_java_jdk_8_psu_version – Installs the latest Oracle Java JDK 8 PSU version

One of my customers reported an unusual problem today with their keyboard, mouse and trackpad. When they tried to to use Apple’s Mail or Messages applications on OS X El Capitan, both Mail and Messages were unresponsive to either keyboard, trackpad or mouse input.

However, when they selected another non-Apple application like Firefox or Google Chrome, their keyboard, trackpad and mouse behaved normally. Other Apple-installed applications like Safari were also responsive to keyboard, trackpad and mouse input.

When I checked the logs, the main clue I could find was that when I clicked on Mail or Messages, I would see an entry like this appear in /var/log/system.log:

09:02:06.100 sandboxd[701]: ([458]) Mail (458) deny hid-control

hid in this instance refers to something which Apple classifies as a Human Interface Device, which include the following devices:

• Keyboards and pointing devices such as mice, trackballs, and joysticks
• Front-panel controls such as knobs, switches, sliders, and buttons (for example, controls on non-Apple displays)
• Controls that might be found on games or simulation devices such as data gloves, throttles, and steering wheels

So for some reason the sandboxd process was denying access to Messages and Mail for the mouse, keyboard and trackpad. Why? For more details, please see below the jump.

After some additional digging, I found an Apple discussion forums thread that explained the issue. If a graphics tablet has ever been connected, or if third-party software has been installed to allow a trackpad to emulate a tablet, the Mac may only be allowing input from that tablet for the affected applications.

The affected customer in this case was using a Wacom tablet and had hard powered-off their Mac right before the problem started. My working theory is the hard shutdown and subsequent restart caused the Mac to incorrectly set the Wacom tablet as the only allowed input device for Mail and Messages.

If you’re affected by this issue, please see below for how to fix this.

1. Open System Preferences

2. In System Preferences, select the Ink preferences.

3. In the Ink preference pane, verify if the following setting is checked:

Allow me to Ink in any application

4. If the Allow me to Ink in any application setting is checked, uncheck it.

5. Close System Preferences

6. Restart your Mac (optional)

Once the Allow me to Ink in any application setting has been unchecked, the affected applications should now respond to the keyboard, trackpad and mouse.

As part of setting up Casper policies, you need to set which Macs will be receiving these policies by setting the scope. The scope defines which Macs or users will be receiving these policies.

When preparing to set the scope for a policy, I will often build and use smart groups. These are a special kind of group, where the members are defined based on one or more attributes (like the Mac’s operating system version, IP address, Mac model, etc.) and therefore the group’s membership is dynamically growing and shrinking based on the numbers of Macs with the specified attributes.

Once the smart group has been set up with the desired attributes, I then set the smart group and its membership to be specified as the scope’s Target Computers.

For many software deployment policies, the software in question often has system requirements that cover a range of operating systems instead of just one version of Apple’s OS. For example, Google Chrome 52.0.2743.116 has the following system requirements:

OS X Mavericks 10.9 or later

Update 8-5-2016: Casper 9.93 and later includes new smart group functionality which can entirely replace the technique described in this post. For more details, please see the post linked below:

https://derflounder.wordpress.com/2016/08/05/new-operating-system-version-smart-group-operators-available-in-casper-9-93/

To deploy Chrome via Casper, the smart group should be set up with attributes that include Macs running 10.9.x. and later. To accomplish this, I had previously set up a smart group that looked like this:

Note: The trailing period after the last number is used by Casper to include all relevant matches. So “10.10.” will also pull in Macs running the following versions of OS X:

• 10.10.0
• 10.10.1
• 10.10.2
• 10.10.3
• 10.10.4
• 10.10.5

However, I was finding that I later needed to go back on an annual basis to those smart groups and add new entries. For macOS Sierra, the smart group would need to be edited to look like this:

An discussion with my colleague Jeremy Reichman provided me with a solution to this issue. I had been setting up my smart groups to include those machines which has the OSs I wanted by setting the smart group attributes to say “I want these OS versions.”

A better answer is to say “I don’t want these OS versions,” and then specify the OS versions that are NOT wanted in your smart group. The result is that your smart group is then populated with whatever is left after excluding the unwanted versions. For example, to get all Macs running 10.9.x or later, you can set up a smart group that looks like this:

Note: It’s unlikely to have 10.1.x through 10.4.x in a modern Mac environment but they’ve been included for completeness’ sake.

The resulting smart group membership should include all the machines that aren’t running the specified OS versions, which may include Macs running 10.9.0 through 10.999.999.

This makes the job of scoping a Chrome software deployment policy easier because the smart group membership will now automatically match the specifications of Google Chrome’s system requirements of OS X 10.9 or later.

As a follow up to yesterday’s post about setting up smart groups which automatically include a specified operating system and later, my colleague Erik Gomez sent me a heads-up about a new feature in Casper 9.93:

As part of Casper 9.93, JAMF has included new smart group operators as part of supporting its new patch reporting feature. The Operating System Version is one criteria which was updated and it now has the following operators available:

• Is
• Is Not
• Like
• Not Like
• Greater Than
• Less Than
• Greater Than or Equal
• Less Than or Equal

The new Greater Than and Less Than operators can completely replace the technique I’ve been using, as they make it straightforward to specify an operating system version number and then set the appropriate operator to automatically include all Macs whose OS version numbers are greater or less than the specified version number. For more details, see below the jump.

Looking at an example from my previous post, I had set up a smart group for Macs running 10.9.x and later by excluding Macs running 10.1.x – 10.8.x:

With Casper 9.93’s new Operating System Version criteria for smart groups, I can replace all the exclusions entirely and replace it with the following criteria:

It’s also straightforward to set up a smart group for 10.8.x and earlier, using the following criteria:

To access the new operators, the Operating System Version criteria is available via the Show Advanced Criteria button when creating or editing a smart group.

As part of the process of upgrading my Casper server, I generally create a new installer for the Casper agent in the form of a QuickAdd installer package. This process usually looks like this:

1. Update the Casper Suite applications on the Mac where I’m generating the new QuickAdd installer package.

2. Open Casper Recon.

3. Sign into Casper Recon.

4. Select QuickAdd Package from the Recon sidebar.

5. Set up the desired options for the QuickAdd installer package.

6. Click the Create button.

7. Choose a name for the new QuickAdd installer package.

8. Wait for Recon to create the QuickAdd installer package.

9. Take the newly-created QuickAdd package and use it to replace the existing QuickAdd packages used by CasperCheck and my deployment workflows.

The reason I use this process is that Casper’s Recon application is able to generate a QuickAdd installer package with an unlimited enrollment invitation. With an unlimited enrollment invitation, I can use the same QuickAdd installer package multiple times to enroll multiple machines. This is in contrast the user-based enrollment process via the JSS, which by default generates a QuickAdd installer package with a one-time-use enrollment invitation.

I have this Recon-based process documented, but it’s always been something I’ve wanted to automate at least somewhat. Recently, as part of a discussion with my colleague Tom Larkin, I learned that a Casper JSS server which is configured to send out emails is capable of generating enrollment invitation emails, which include a link to download a JSS-generated QuickAdd. That invitation can be set to link to a QuickAdd with an unlimited enrollment invitation and an expiration date many years in the future, which effectively gives me the ability to generate the QuickAdd installer packages I want without the need to use Casper’s Recon application. For more details, see below the jump.

Pre-requisites:

• Casper server configured to send emails
• Casper server configured to allow user-initiated enrollment of computers

Once the pre-requisites have been put in place, verify that your JSS account has the needed account privileges in order to be able to generate and send enrollment invitations via email.

If you want the user account to generate new invitations, here are the necessary JSS Objects privileges:

Under JSS Objects:

Computer Enrollment Invitations: Create, Read, Update
Computers: Read
Mobile Device Enrollment Invitations: Create, Read, Update
Mobile Devices: Read

If you want the user account to also be able to delete existing invitations, here are the necessary JSS Objects privileges:

Computer Enrollment Invitations: Create, Read, Update, Delete
Computers: Read
Mobile Device Enrollment Invitations: Create, Read, Update, Delete
Mobile Devices: Read

In both cases, here are the necessary JSS Actions privileges:

Send Email to End Users via JSS: selected

In my testing, no other account privileges were required. Next, verify that your user-initiated computer enrollment is set up with the desired settings.

Once your account privileges are set and user-initiated computer enrollment is configured, here’s how to generate and send enrollment invitation via email.

1. Log into the JSS
2. Select Enrollment Invitations

3. Click the New button to start the invitation process.

4. In the Specify Recipients window, enter the desired email address for the invitation then click the Next button.

5. In the Configure the Invitation Message window, set up the invitation message as desired then click the Next button.

6. In the Configure Invitation Security window, do the following:

A. Set the expiration date as far in the future as desired. As an example, I’ve set the expiration date to December 31st, 2030 at 11:59 PM, which is as far in the future as is currently possible.

B. Check the Allow multiple uses checkbox.

Once both the expiration date and Allow multiple uses settings are configured as desired, click the Next button.

7. In the Complete window, click the Done button.

Once the invitation has been generated and sent, check the email address in question. There should be an email from the Casper server with a link similar to the one shown below.

Once you’ve clicked the link, you should be walked through the process of downloading the newly-created QuickAdd package.

Testing:

Once the package has been built, test it by taking the QuickAdd installer package to at least two test machines which do not have Casper installed and install it. The end result should be that the Casper agent installs on the test machines and enrolls them successfully with the Casper server. The reason to install on more than one machine is to verify that the multiple uses invitation was set up properly.

Additional notes:

1. Once created, the enrollment invitation will be listed in the Casper server’s Enrollment Invitations section. If you delete the listing for the enrollment invitation, you also remove the enrollment invitation embedded in the QuickAdd package. The result is that the QuickAdd will no longer be able to enroll Macs with the Casper server and a new QuickAdd installer package will need to be created.

2. As part of the QuickAdd creation process, the Casper server does a lookup of the email address via LDAP to see if it can identify who is associated with the email address. It then adds that information to the computer inventory as part of the enrollment process, via a postinstall script in the QuickAdd installer package.

For the most part, this is harmless and may just mean that your JSS initially has the wrong user information for a particular machine. If desired, you can use pkgutil to expand the QuickAdd package, edit the postinstall script, then re-flatten the QuickAdd package. Expanding and re-flattening removes any package signing, so re-signing the package may be needed.

As part of a discussion of security issues with some colleagues this morning, the question of how to disable Bonjour advertisement came up on OS X El Capitan and later came up. Bonjour advertisement is how your Mac sends out an “I’m here and this is a list of the services I have available” message via Bonjour. In certain environments, this is undesired behavior and the advertisement service needs to be disabled.

The reason why the question came up is that, on OS X Yosemite and earlier, the process of disabling Bonjour advertisement looked like this:

1. Run the following command with root privileges to unload the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file:

launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

2. Run the following command with root privileges to edit the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file:

defaults write /System/Library/LaunchDaemons/com.apple.mDNSResponder ProgramArguments -array-add "-NoMulticastAdvertisements"

3. Run the following command with root privileges to load the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file:

launchctl load /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

As of OS X 10.11.x though, System Integrity Protection blocks the editing of the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file because of the file’s location inside of the SIP-protected /System directory.

To accommodate this change, Apple made a change to mDNSResponder on OS X El Capitan and later to allow it to pick up settings from the following file:

/Library/Preferences/com.apple.mDNSResponder.plist

The ability to disable Bonjour advertisement is among the settings which can be applied to the new /Library/Preferences/com.apple.mDNSResponder.plist file. To disable Bonjour advertisement in OS X El Capitan and later, use the following procedure:

1. Run the following command with root privileges:

defaults write /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements -bool YES

2. Restart the Mac

3. Once the Mac has restarted, Bonjour advertisement should be disabled.

For those who want to disable Bonjour advertisement using a management profile, I’ve created a .mobileconfig file and posted it here on Github:

https://github.com/rtrouton/profiles/tree/master/DisableBonjourAdvertisement

I’ve filed a bug report about this. For those interested in duping this bug, the bug report ID is 27952362. I’ve also cross-posted it to OpenRadar:

https://openradar.appspot.com/27952362

As part of the process of deploying Macs, Mac admins may want to add one or more local user accounts with a pre-determined password. The reasons for this may include the following:

• Setting up a local administrator account.
• Setting up a “loaner” user account for a pool of loaner laptops.
• Setting up a local user account that automatically logs in at startup for a Mac used as a kiosk.
• Setting up a generic “student” account for use in a school’s computer lab.

These accounts can be set up using a script, but that usually means having the password for the local account stored in the script in a way that anyone with access to the script can easily read the password. An alternative to this approach is to use CreateUserPkg.app, a open source utility written by Per Olofsson. CreateUserPkg.app generates installer packages which can be used on Mac OS X 10.5.x and later to create local user accounts and securely set the associated account’s password. For more information, see below the jump.

Using CreateUserPkg.app

1. Install CreateUserPkg.app from one of the following sources:

GitHub: http://magervalp.github.io/CreateUserPkg/

Mac App Store: https://itunes.apple.com/us/app/createuserpkg/id540673598?mt=12

2. Launch CreateUserPkg.app

3. Set up the local account information as desired. Once all the desired settings are chosen, click the Save Package button.

Note: The User ID number should be set to a numeric value not used by any other account’s UID on the Mac at the time of installation.

5. Choose where to save the package and click the Save button.

Testing CreateUserPkg-generated installers

Once the package has been built, test it by taking the CreateUserPkg-generated installer package and install it on a Mac which does not have the local account set up on it. The end result should be that the local account is set up on the Mac with the desired password and configured with the specified settings and account rights.

How CreateUserPkg.app works

CreateUserPkg.app creates two files for the local user account, which allows the account information to work on Mac OS X 10.5.x and later. The local account’s information is written to a plist file named with the account’s username and stored in the directory listed below:

/private/var/db/dslocal/nodes/Default/users

An example account plist is shown below:

For compatibility with Mac OS X 10.5.x and 10.6.x, the account’s password is stored in encrypted format in files named with the Generated UID of the account. These files are then stored in the directory listed below:

/private/var/db/shadow/hash

Note: These files were only needed for Mac OS X 10.5.x and 10.6.x; on later versions of OS X and macOS, the passwords were stored in the account’s plist file in /private/var/db/dslocal/nodes/Default/users. On Mac OS X 10.7.x and later, the password information is automatically converted to the proper format when the user account is logged into for the first time.

Once the two files are generated by CreateUserPkg.app, the utility then generates an installer package and post-installation script to install the two files into their proper places. Once the CreateUserPkg-generated package is installed, the account’s files are put into the necessary places and the installer’s postinstall script handles any necessary granting of admin rights or auto-login settings.

An example postinstall script from a CreateUserPkg-generated installer package is shown below: