Automating the setup of OS X Server on El Capitan and Yosemite

As part of the development of Mac OS X, Apple has also developed Mac OS X Server as a way to provide access to both additional services on OS X and the management tools needed to administrate those services. While Mac OS X and Mac OS X Server used to be separate operating systems, Apple combined them into one release re-branded as OS X and moved the server-specific services and management tools into an OS X Server application available from the Mac App Store.

As part of the move to an application-based installation process, there was a capability removed from OS X Server: The ability to automate its setup entirely from the command line.

In order to run the initial setup of OS X Server, the following manually-run process was needed:

1. Log into the Mac using an account with administrator rights
2. Launch /Applications/Server.app

3. Agree to the OS X Server license

4. Provide administrator authorization when prompted.

5. The initial setup of OS X Server would then proceed.

 

For Mac sysadmins who needed to set up multiple instances of OS X Server, having this manual step involved slowed the setup process down considerably. To find out why this part needed to run manually, while at WWDC 2015 I asked the relevant Apple engineer why this was the case. The response was that the OS X Server license needed to be agreed to, to which I mentioned that Xcode had a similar requirement but that there was a way to agree to the license from the command line. The Apple engineer in question took that feedback and said it was a valid point.

At this point, the story skips forward to Brad Chapman discovering a new and undocumented way to agree to the license from the command line in OS X Server 5.0.x. Charles Edge built on that discovery and created an expect script to handle agreeing to the license and providing admin authorization. Charles’s method incorporated the use of an existing admin user’s username and password in the script, so in turn I’ve built on Charles’s work to create a completely automated setup script which does the following:

1. Create a temporary user with a randomly generated password
2. Give the temporary user admin privileges
3. Run the initial setup and configuration of OS X Server’s services.
4. Delete the temporary user

As part of the initial setup process:

• Agree to the license
• Authorize the setup process using the temporary user’s username and password

For more details, see below the jump.

Oracle’s Java 8 Update 66

Following closely on the heels of Oracle’s release of Java 8 Update 65, Oracle has released Java 8 Update 66. This update is also using Oracle’s install application.

What’s the difference between Update 65 and Update 66? Update 65 is a Critical Patch Update (CPU), which contains both fixes to security vulnerabilities and critical bug fixes. Update 66 is a Patch Set Update (PSU), which means it 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

So the short version is that Update 65 has “critical bug fixes” and Update 66 has “Update 65’s bug fixes, plus more bug fixes.”

You can get Oracle’s Java 8 Update 66 from the link below:

http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

For more details on Java 8 Update 66, see below the jump.

Oracle’s Java 8 Update 65 – The return of the Java install application

For the past couple of releases, Oracle has used a standard installer package to install Java 8. With the release of Java 8 Update 65 though, Oracle returned to using an application to install Java.

This switch away from using installer packages is a problem for Mac admins who need to deploy Oracle’s Java 8 in their own environment. However, after doing some research, it looks like it is still possible to deploy Oracle’s Java 8 Update 65 using a standard installer package. For more details, see below the jump.

create_vmware_osx_install_dmg script updated with El Capitan support

I’ve updated the create_vmware_osx_install_dmg.sh script that I had previously posted about here. The script now includes support for El Capitan, so the script can now be run on 10.7 – 10.11 to create custom OS X 10.7.x, 10.8.x, 10.9.x, 10.10.x and 10.11.x installers for VMware Fusion and VMware ESXi. See below the jump for the details.

Taking screenshots of the login window on OS X El Capitan

@clburlison has discovered that you can take screenshots of the OS X login window on OS X El Capitan using OS X’s keyboard shortcuts for making screenshots.

You can take screenshots at the loginwindow and when you login they will show up on your Desktop. Didn't know that was a thing.

— Clayton Burlison (@clburlison) October 15, 2015

This appears to be a new feature of El Capitan, as I was unable to reproduce this behavior on OS X Yosemite.

In my testing, I’ve verified that using the following commands work:

• Take a screenshot of the entire login window: Command+Shift+3
• Take a screenshot of a user-selected area of the login window: Command+Shift+4

The screenshot file(s) will then appear on the desktop of the next user to log in.

To distinguish these login window screenshots from screenshots taken while logged in, the login window screenshots’ filenames begin with LW.

Slides from the “OS X Security – Defense in Depth” Session at JAMF Nation User Conference 2015

For those who wanted a copy of my security talk at JAMF Nation User Conference 2015, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/JNUC2015SecurityPDF

Keynote – http://tinyurl.com/JNUC2015SecurityKeynote

Programmatically hiding and unhiding the menubar in El Capitan

As my colleague @quovadimus82 has previously documented, OS X El Capitan includes a new option for showing and hiding the menubar.

This option is available in System Preferences, in the General preferences.

 

It is also possible to use the defaults command to set the menubar’s behavior. Here’s how you can set the menubar to be hidden and unhidden using defaults:

To hide:

defaults write NSGlobalDomain _HIHideMenuBar -bool true

 

To show:

defaults write NSGlobalDomain _HIHideMenuBar -bool false

 

Once run, logout and log back in to see the change in behavior. Alternatively, you can run the following command as the logged-in user to restart Finder and show the changes:

killall Finder

Configuring System Integrity Protection without booting to Recovery HD

One interesting part of Apple’s developer documentation for System Integrity Protection (SIP) is the note shown below, indicating that it’s possible to configure SIP for environments that can’t access Recovery.

When I followed up with Apple about this, I was told that this meant I could configure it using NetBoot, using a NetBoot set that included the needed Recovery environment.

The example used was leveraging a new option in System Image Utility to create a package-only installation NetBoot set.

This new type of NetBoot set is is designed to install only scripts, configuration profiles and packages as opposed to installing an OS. For more details, see below the jump.

Enabling an IPv6-only network using Internet Sharing on El Capitan

One of the hidden features of OS X El Capitan is the ability to enable Internet Sharing to provide only IPv6 addresses. This feature was added to El Capitan to help developers ensure their apps are ready to work with IPv6. It uses NAT64, which facilitates communication between IPv6 and IPv4 hosts by using a form of NAT.

For those interested in having the ability to set up an IPv6-only network, see below the jump for the procedure.

System Integrity Protection – Adding another layer to Apple’s security model

As part of the release of OS X El Capitan, Apple has added a new layer named System Integrity Protection (SIP) to its security model. To understand how System Integrity Protection fits in, let’s first take a look at Apple’s security model as it existed as of OS X Yosemite.

 

Gatekeeper

Gatekeeper is one of the outer lines of defense. It allows users to restrict which sources they can install applications from, with the general idea being that malware will not be from an allowed source.

 

Sandboxing

OS X also uses sandboxing extensively. A sandbox typically provides a tightly controlled set of resources for programs to run in. Network access, the ability to inspect the host system, or reading from input devices is usually disallowed or heavily restricted.

 

POSIX permissions

OS X uses the Unix permissions model as defined by POSIX, which governs which users and groups can access which files and directories. If a particular user account requests access to a particular file or directory and does not have the necessary rights, that account is refused access.

 

Keychains

The innermost layer of defense are keychains. Keychains are very specialized databases which are designed for the storing of secrets, like passwords, private keys, PIN numbers, and then controlling access to those secrets. To help protect these secrets, keychains are encrypted.

 

There’s an issue with this model though and it’s been there for decades. It pre-exists OS X and even pre-exists Apple as a company. That issue is found in the POSIX permissions layer.

Root

 

Root is the superuser for a Unix system and the Unix permissions model is designed around the assumption that root has access to everything. Apple has not ignored this issue and has put some controls in place to limit the actual root user. These controls include disabling the root user account, discouraging its use, and providing ways to access elevated or root privileges using other means.

However, the root user account is still present and still can do anything on the system.

 

System Integrity Protection

To limit what the superuser can do and add another layer to OS X’s security model, Apple has developed SIP and deployed it as part of OS X El Capitan. SIP is designed to limit the power of root and to protect the system even from the superuser. For more details, see below the jump.