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:
- Create a temporary user with a randomly generated password
- Give the temporary user admin privileges
- Run the initial setup and configuration of OS X Server’s services.
- 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.
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:
You can get Oracle’s Java 8 Update 66 from the link below:
For more details on Java 8 Update 66, see below the jump.
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.
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.
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.
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.
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:
defaults write NSGlobalDomain _HIHideMenuBar -bool true
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: