Weekly News Summary for Admins — 2018-04-27

Today is Koningsdag (King’s Day) here in the Netherlands. So, because of the holiday, just a quick summary! Have a great week-end, everyone!

If you would rather get the weekly newsletter by email, you can subscribe to the Scripting OS X Weekly Newsletter here!! (Same content, delivered to your Inbox once a week.)

#! On Scripting OS X

📰News and Opinion

🐞Bugs and Security

🔨Support and HowTos

MacAdmins on Twitter

🤖Scripting and Automation

🍏Apple Support

♻Updates and Releases

📚Support

I do not have any ads on my webpage or this newsletter. However, if you want to support me and this website, then please consider buying one (or both) of my books. (Imagine it’s like a subscription fee, but you also get one or two useful books on top!)

If you have already bought and read the books, please leave a review on the iBooks Store. Reviews are important to help new potential readers make the purchase decision. Thank you (again)!

Demystifying `root` on macOS, Part 2 — The `sudo` Command

As mentioned before, the recommended way of gaining super user privileges from the command line in macOS is the sudo command. The name means ‘super user do’ and will perform the following command with root privileges after verifying the user running sudo has the permission to do so.

How sudo works

sudo allows a user to execute a command with super user privileges, without needing to authenticate as the super user. The user has to authenticate as themself, however, and the sudo will check whether the user is authorized to use sudo.

For example, you want to run a command that requires super user privileges:

$ systemsetup -getremotelogin
You need administrator access to run this tool... exiting!

You can then repeat the command with sudo to run it with temporary super user privileges.

$ sudo systemsetup -getremotelogin
Password:
Remote Login: On

On macOS, administator users are allowed to use sudo.

A few notes on sudo:

  • you can type sudo !! as a short cut for ‘repeat the last command with sudo’. More details on this in my post “On Bash History Substitution”.
  • the first time you run sudo with an account on a Mac it will show a longer dialog with a warning or ‘lecture’. (You can change the lecture.)
  • the system will prompt for your password when executing a command with sudo. However, there is a 5 minute (300 seconds) ‘grace period’ where the sudo system caches your credentials and you do not have to re-enter the password. This grace period is limited to a given shell session, so if you open a new Terminal window, you will have to re-enter the password.
  • on macOS sudo will not work if your administrator account’s password is empty: Using the sudo command in Terminal requires an administrator password
  • use of sudo is logged. You can find the log entries in the Console.app by searching for process:sudo:
armin : TTY=ttys000 ; PWD=/Users/armin ; USER=root ; COMMAND=/bin/echo "#iamroot"

sudo and the Environment

sudo runs the command in the current shell environment. The user (or effective user ID) the command is run as switches to root:

$ whoami
armin
$ sudo whoami
root

The sudo environment changes some of the variables, while some will be passed through from your shell. To show this, create a short script:

#!/bin/bash

echo $USER
echo $HOME
echo $EUID

and run it as yourself and then with sudo:

$ chmod +x printenvs.sh
$ ./printenvs.sh 
armin
/Users/armin
501
$ sudo ./printenvs.sh 
Password:
root
/Users/armin
0

Some tools might not read environment variables and determine the user environment through different means. This may lead to some tools writing data to root’s home directory instead of the current users when running with sudo.

The defaults command is one example:

$ sudo defaults write com.apple.loginwindow LoginHook /path/to/script
~ $ defaults read com.apple.loginwindow LoginHook
2018-04-16 15:09:00.378 defaults[69217:3291382] 
The domain/default pair of (com.apple.loginwindow, LoginHook) does not exist
~ $ sudo !!
sudo defaults read com.apple.loginwindow LoginHook
/path/to/script
~ $ sudo plutil -p /var/root/Library/Preferences/com.apple.loginwindow.plist
{
  "LoginHook" => "/path/to/script"
}

Note: This form of customizing login behavior in macOS is deprecated (but still works as of 10.13). LaunchAgents are the preferred method to run scripts or processes at login. (More info here.) If you find yourself building custom LaunchAgents and LaunchDaemons frequently, you need to check out outset.

You have to be aware that running commands with sudo results in a different environment than when you run them directly.

root Shells

In most cases running a single command with sudo is sufficient. However, sometimes it can be convenient to have an interactive shell that runs with super user privileges.

There are two ways of achieving this withsudo:

When you run sudo -s it will invoke a new shell, running as root. The shell that is run is the default shell of your account. So when you have bash set as your shell (the default on macOS) you will get a bash shell running as root. Most other environment settings will remain the same:

$ sudo -s
Password:
# whoami
root
# echo $HOME
/Users/armin
# echo $SHELL
/bin/bash
# exit
$ 

Usually, the Terminal prompt is set up to change from the $ prompt to # when you are running with super user privileges, to remind you of the power you have right now and the danger you are in.

Note: learn how to configure your shell prompt.

To leave the root shell, just type exit.

Alternatively you can use sudo -i to invoke a root shell. With the -i option, the shell will be chosen from the default shell set for root user (/bin/sh on macOS) and will be set up as if the root user were logging in, ignoring your settings, like profile files etc.

$ sudo -i
Mac:~ root# whoami
root
Mac:~ root# echo $HOME
/var/root
Mac:~ root# echo $SHELL
/bin/sh

Note that my custom minimal shell prompt changes when I switch to root with sudo -i since it creates the root shell with the root user’s environment.

In most cases sudo -s should serve well. However, when you want to avoid any customization you might have set in your user environment and work in more pristine environment then it is good to know sudo -i exists.

sudo vs su

There is a different command which allows you to change the user: su (short for ‘switch user’). The main difference between these tools is how they verify if you are authorized to switch.

su will ask for credentials of the user you are switching to. So if you run su bob you need to have Bob’s credentials.

When you run su without a username, it assumes root. But since logging in as root is disabled by default on macOS, it will fail.

$ su
Password:
su: Sorry

sudo, on the other hand, will check its configuration files to see if your account is authorized to run the command as the given user. It asks for your credentials to verify you. You do not need the credentials of the other user, whether it is root or a different user.

Since the root account login is usually disabled on macOS, you cannot use su root - or su - to get a root shell. Use sudo -s or sudo -i instead.

sudo and Scripting

sudo is very useful when working interactively in the shell. However, when you are scripting workflows then you don’t want to encounter the interactive prompt for authentication.

We will look at strategies for privilege escalation (and the opposite) in scripts in the next post.

Weekly News Summary for Admins — 2018-04-20

Still more articles (and bugs) from the 10.13.4 release coming in. Otherwise this has been a quieter week.

If you would rather get the weekly newsletter by email, you can subscribe to the Scripting OS X Weekly Newsletter here!! (Same content, delivered to your Inbox once a week.)

#! On Scripting OS X

📰News and Opinion

🐞Bugs and Security

🔨Support and HowTos

🤖Scripting and Automation

♻️Updates and Releases

🎧To Listen

📚Support

I do not have any ads on my webpage or this newsletter. However, if you want to support me and this website, then please consider buying one (or both) of my books. (Imagine it’s like a subscription fee, but you also get one or two useful books on top!)

If you have already bought and read the books, please leave a review on the iBooks Store. Reviews are important to help new potential readers make the purchase decision. Thank you (again)!

Converting Composer dmg ‘installers’ to pkg

Jamf Composer has always had two formats to build installers. The standard pkg and the seemlingly standard (but not) dmg. The pkg option will build a standard pkg installer file, which will install with any system that can install pkg files.

The dmg option will build a standard dmg disk image file, with the payload of the installer as contents. On its own, however, this dmg cannot do anything. The Jamf Pro management system how ever will understand what to do and how to install the files from the dmg to a system. There are certain features in Jamf Pro which can install and distribute files to user directories and templates (called ‘Fill User Templates’ FUT and ‘Fill Every User’ FEU) which only work with dmg installers in Jamf Pro.

However, Jamf themselves have been recommending to use the standard pkg format in favor of their proprietary use of dmg. Also the Composer application is 32-bit and its future is uncertain.

Luckily there are plenty of great other third-party tools to build installer packages. I cover many of them in my book: Packaging for Apple Administrators

In general, it is probably preferable to re-visit your imaging process and rebuild any installer you still may have in dmg format from scratch. However, in some cases that might not be possible or necessary.

Since the Composer generated dmgs contain all the files for the payload in the proper folder structure you can just use the entire mounted volume as your payload root for pkgbuild. You can easily convert a Composer generated installer dmg to a standard pkg with these commands:

1) mount the dmg:

$ hdiutil attach /path/to/Sample.dmg

this will output a bunch of info, the very last bit is the mount point of the dmg /Volumes/Sample (the name will depend on the dmg)

2) build a pkg with the contents of the mounted dmg as a payload:

$ pkgbuild --root /Volumes/Sample --version 1.0 --identifier com.example.sample --install-location / Sample-1.0.pkg

This will create Sample-1.0.pkg in your current working directory. (I like to include the version in the pkg file name, but that is entirely optional.)

3) cleanup: unmount the dmg

$ hdiutil detach /Volumes/Sample

Obviously this will not work well with other dmgs, such as Full System dmgs, or dmgs downloaded from the web, which contain an app that should be dragged to /Applications to install (use quickpkg for those dmgs).

Demystifying `root` on macOS, Part 1

As Mac Adminstrators, we often have to deal with user privileges for files and processes. While doing that we will use administrator privileges and sudo without as much as a second thought.

However, a proper understanding of what these privileges and processes actually do and mean, can help prevent many problems when managing Macs.

Some History

macOS is based on BSD Unix, which stems back to a time where large mainframes were so expensive they had to be shared among many users. Users and their access privileges control what any user can read, write, or change in the system. These rules prevent conflicts and data loss or theft. When managing these users and their access privileges, there had to be a first, ‘top’, or ‘super user’ which has access to anything.

In Unix and Unix-like systems this user account is traditionally called root. In macOS this user is often also called ‘System Administrator’.

Classic Mac OS, in contrast, had no concept of multiple users built-in to the system. Any person sitting down at a Mac (and any process launched on that Mac) could access and change anything on that system. There were some attempts at adding multi-user functionality to classic Mac OS, but they were ‘added on, not built-in’ and fairly easy to circumvent when a user knew what to do.

User and process management was one of the main benefits Apple touted for the various ‘next generation’ systems Apple introduced in the 90s to succeed classic Mac OS. When Apple bought NeXT and with it the NeXTStep operating system it inherited the unix model of doing so.

Even though the concept of sharing your computer is now relegated to some classroom labs and supercomputer clusters, this model still is present in every macOS and iOS device today. On iOS it is completly invisible to the user, unless a jailbreak is applied. On macOS, however, users and especially admins have to deal with it every day.

Users on macOS

To create a new user on macOS you have go to the ‘Users & Groups’ Preference Pane in System Preferences. Before you can add a new user, you have to unlock the preference pane by clicking the lock icon in the lower left corner. Then the system will prompt for an username and password with adminstrative privileges.

When the account you are logged in as has admin privileges, its name will be pre-filled. When the account is a standard user the username field will be empty and you can enter another user’s name and password.

Once the pane is unlocked, you can hit the ‘+’ icon under the user and will be offered four choices for a new user (from the popup menu next to ‘New Account’:

  • Administrator
  • Standard (the default)
  • Managed with Parental Controls
  • Sharing Only

There are three types of users not present in the popup list

  • Guest
  • System Administrator
  • system services users

The difference between Administrator and Standard accounts is that Administrator accounts are members of the ‘Administrators’ or admin group. This sound simple, but membership in this group bestows many additional benefits.

In day-to-day use Administrator accounts and Standard accounts behave the same. However, there are many situations and workflows on macOS which require authenticating as an Administrator account. As a general rule, a user can affect all the files (and applications) in their home directory and in /Users/Shared, but as soon as you want to change another user, another user’s files or settings that affect all users on a system you need to authenticate as an Administrator account.

The first user created on an unmanaged Mac out of the box will always be an Adminstrator user. Most Mac users use an Administrator account. Many of the workflows built-in to macOS assume an adminstrator account. One example is setting up a new printer.

With an Administrator account you can install third party software. You can also install malicious software. Often malicious software will trick users into installing by masquerading as or hiding in an installer for something useful.

Many consider it a ‘best practice’ to run your everyday work on your Mac with a standard account and only use an administrative account when you have to. However, since you get prompted to authenticate even with an administrative account, the better advice is to take these prompts very seriously and consider what confirming this prompt will really do or install.

The only difference you get when using a standard account is that you need to enter a different username and password in an authentication box instead of just the password. If this helps you pause and consider what you are actually doing, then great! Then this is the proper workflow for you.

However, I suspect that most users would be just as non-considerate of this dialog with a separate username and password as they would otherwise.

macOS Administrator Accounts

The only difference between Adminstrator accounts and Standard accounts is the membership of the admins group.

You can check whether a given user is a member of the admin group with the dseditgroup tool:

$ dseditgroup -o checkmember -u armin admin
yes armin is a member of admin

You can also use this tool to add or remove a user from the admin group:

$ dseditgroup -o edit -n . -a username -t user admin    # add username
$ dseditgroup -o edit -n . -d username -t user admin    # delete username

This membership comes with many privileges. Admin users can (after authentication):

  • unlock System Preferences and change system settings
  • install Apple and third party software and installer packages
  • create, change, and delete files owned by other users
  • change access privileges and ownership of files of folders in Finder
  • run and stop (kill) processes owned by other users
  • use sudo in Terminal

and many things more.

On macOS these privileges are controlled mainly by two mechanisms:

  • sudo and the sudoers file
  • the authorization database

sudo is used to gain root privileges in the shell (Terminal). The authorization database controls access privileges everywhere else.

What root can do

The ‘System Administrator’ or the root account controls the system. Mainly the root account can read, update, delete all local user accounts. It can control file and folder privileges and ownership. It can start system services running in the background and assign system network ports (with a port number lower than 1000). Most of this is managed by a process called launchd which is the first process to run on macOS.

Many commands require to be run as root or with elevated root privileges.

What root cannot do: System Integrity Protection (SIP)

On macOS, however, there are limits to what the root account can do. System Integrity Protection is a mechanism which protects important parts of the OS from mnodification, even with root permissions.

Only certain processes signed by Apple are allowed to modify these protected files and directories. Usually this means Apple signed installer pkgs for software and security updates.

Apple Support: About System Integrity Protection on your Mac

Apple lists a set of top-level directories that are protected. However, the list is a bit more detailed. You can use the -O (capital letter ‘O’, not a zero) to see if a file or directory is protected by SIP:

$ ls -lO /usr/
total 0
drwxr-xr-x  978 root  wheel  restricted 31296 Mar 30 18:21 bin
drwxr-xr-x  294 root  wheel  restricted  9408 Mar 30 18:21 lib
drwxr-xr-x  238 root  wheel  restricted  7616 Mar 30 18:21 libexec
drwxr-xr-x    8 root  wheel  sunlnk       256 Dec 28 13:48 local
drwxr-xr-x  248 root  wheel  restricted  7936 Mar 30 18:21 sbin
drwxr-xr-x   46 root  wheel  restricted  1472 Mar 30 18:21 share
drwxr-xr-x    5 root  wheel  restricted   160 Oct  3  2017 standalone

Files and Folders marked with restricted are protected by SIP. Sometimes folders inside a protected folder may not be protected, as the /usr/local/ directory in this example is.

SIP provides more protection than just certain parts of the file system, it also protects changing the boot volume and some other aspects of the OS.

While these limitations on even the root account can be annoying, they provide a level of security that parts of the OS have not been tampered with or changed by other software.

Enabling (and Disabling) root

On macOS the root account exists with a UID of ‘0’. However, it is set up so you cannot log in to a Mac as ‘System Administrator’ or root. (A terrible bug in early 10.13 provided a brief exeception to that rule.)

Note: login as root is disabled for security purposes. It is highly recommended that you leave the root account disabled on macOS and rely on sudo to gain temporary super user privileges when necessary.

If, for some reason, you do need to log in as root, then you can enable the root and provide it with a password. You can do so in either the ‘Directory Utility’ application. After unlocking with your administrator password, you choose ‘Enable Root User’ from the ‘Edit’ menu. You can also change the root account’s password here or disable it again later.

Apple Support: How to enable the root user on your Mac or change your root password

From the command line, you can also use the dsenableroot command:

$ dsenableroot

will enable and/or update the root account. It will interactively ask for admin credentials and for a new password for the root account. Read the command’s man page for details.

$ dsenableroot -d

will interactively disable the root account again.

Becoming root

Different environments and tools have different means of gaining super user or root privileges. While the sudo command should be the preferred means of gaining temporary super user privileges, it is important to know and understand the other options.

LaunchDaemons

Scripts and tools executed from LaunchDaemons run as root unless a different user is specified in the UserName key in launchd property list.

LaunchAgents on the other hand will be executed as the user logging in.

You can get details on how to set up and use LaunchDaemons here.

Run as root in ARD

When you prepare a ‘UNIX command’ to be sent to remote computers in Apple Remote Desktop, you have the option of running the command as the currently logged in user or as a specific user. When you specify root as the user, the script will execute with super user privileges. Since the ARD agent process runs as root on the client, no extra authentication or enabled root account is necessary.

Management Systems

The agent software of most management systems (Jamf, Munki, etc.) is installed to run with root privileges. Therefore, scripts executed by management systems run with root privileges as well.

Installation Scripts

Installation packages also perform their task with root privileges. They also require administrator authentication to start. Any installation scripts (pre-/postinstall scripts) will also run with root privileges.

set-UID bits

There is a special bit you can set on an executable’s mode (or privileges) which tells the system to run this script as the file owner, no matter who actually runs the executable. If the executable file is owned by root it will run with root privileges.

This flag is the “set-user-ID-on-execution bit”, also called the “Set-User-ID”-bit or just “s-bit”.

In the long ls format or with the stat command the set-user-ID bit is shown as an ‘s’ in place of the user’s x bit. One example is the ps command:

$ stat -l /bin/ps
-rwsr-xr-x 1 root wheel 51200 00:57 /bin/ps

Use chmod's u+s to set the set-user-ID bit and u-s to remove it:

$ chmod +x importantcommand [rwxr-xr-x]
$ chmod u+s importantcommand    [rwsr-xr-x]
$ chmod u-s importantcommand    [rwxr-xr-x]

Warning: Obviously it is very important that this executable is not modifiable by other users. They would be able to replace the command with their own code and execute anything with root privileges. Most system commands that have the s-bit set on macOS are protected with SIP.

The sudo command

As mentioned before, the recommended way of gaining super user privileges from the command line in macOS is the sudo command. The name means ‘super user do’ and will perform the following command with root privileges after verifying the user running sudo has the permission to do so.

We will look at the sudo command in detail in the next post.

Weekly News Summary for Admins — 2018-04-13

More ‘Spring Update Fallout’ this week. Users will now get warning when they launch a 32-bit app. Apple is updating older versions of OS X to install the High Sierra Installer app.

If you would rather get the weekly newsletter by email, you can subscribe to the Scripting OS X Weekly Newsletter here!! (Same content, delivered to your Inbox once a week.)

🎂Anniversary

I published the first “Weekly News Summary for Admins” a year ago on this blog. The email newsletter came later in June.

The summary now has a few hundred readers every week. They are split fairly evenly across the weblog and the email newsletter. I have gotten lots of friendly and grateful feedback both from reader and authors.

So, thank you, readers, for your attention, and thank you all the MacAdmin authors who are documenting and sharing their opinions and solutions for everyone!

If you enjoy the news summary, then you can do me a favor by recommending it to another Mac Admin, retweeting it on Twitter or sharing it on your favorite social media. Thank you!

(Now back to the normal program.)

📰News and Opinion

🐞Bugs and Security

🔨Support and HowTos

Krypted Server Migration Posts

Charles Edge is continuing his epic series of posts on how to replace macOS Server.

🤖Scripting and Automation

🍏Apple Support

♻️Updates and Releases

🎧To Listen

📚Support

I do not have any ads on my webpage or this newsletter. However, if you want to support me and this website, then please consider buying one (or both) of my books. (Imagine it’s like a subscription fee, but you also get one or two useful books on top!)

If you have already bought and read the books, please leave a review on the iBooks Store. Reviews are important to help new potential readers make the purchase decision. Thank you (again)!

Weekly News Summary for Admins — 2018-04-06

Lot’s of helpful posts by many admins to help with the 10.13.4 update. Thanks to all who share their experiences and knowledge.

There were two big Apple related news items. First Bloomberg had an article which states that Apple is planning to use the their own chips in Macs starting in 2020 (only two years from now). In an odd juxtapostition we also got an update on the progress of the new Mac Prowhich Apple now says will ship in 2019. (I can think of a few ways how this could work out. Some are good and some are… worrying… I may post on this at a later time.)

James Thomson (developer of PCalc (iOS, Mac and AppleTV!) illustrates this wonderfully in this tweet.

If you would rather get the weekly newsletter by email, you can subscribe to the Scripting OS X Weekly Newsletter here!! (Same content, delivered to your Inbox once a week.)

#! On Scripting OS X

📰News and Opinion

2020 Macs

Mac Pro

🔐Security

🐞Bugs

🔨Support and HowTos

macOS 10.13.4 posts:

Charles Edge has continued his series of posts on how to replace macOS Server services:

🤖Scripting and Automation

🍏Apple Support

♻️Updates and Releases

🎧To Listen

  • I have been hugely enjoying Brain McCullough’s ‘Techmeme Ride Home’ podcast which gives you a 15–20 minute summary of tech related news for the day for your, well, ride home, or to work, depending on your time zone

📚Support

I do not have any ads on my webpage or this newsletter. However, if you want to support me and this website, then please consider buying one (or both) of my books. (Imagine it’s like a subscription fee, but you also get one or two useful books on top!)

If you have already bought and read the books, please leave a review on the iBooks Store. Reviews are important to help new potential readers make the purchase decision. Thank you (again)!

macOS 10.13.4 Spring Update for Mac Admins

With the recent release of 10.13.4 (the ‘spring update’) a few things have changed for the deployment of macOS. The initial premise is still unchanged: Imaging is still dead.

(NetInstall got a bit of a life extension, though.)

I have written a book which expands on this topic and is regularly updated. Please check it out: “macOS Installation for Apple Administrators

Quick Recap

High Sierra came with many features for both users and admins. However, for Mac admins it brought the support article HT208020: “Upgrade macOS on a Mac at your institution”. In this article Apple lists the supported means of installing and upgrading macOS and explicitly states that ‘monolithic imaging’ is not recommended and will not ensure that the firmware of a Mac is of the correct version to run the OS image that was just laid down. (I posted an article on this back in October.)

Then, with the release of the iMac Pro in December, it became clear that NetBoot and NetInstall, will not be supported with the new hardware. The assumption is, that will also be true for all new Macs with the T2 or a newer system controller. (My post on that, from December.)

NetBoot and NetInstall are used by many administrators to provide a centralized workflow to (re-)deploy or re-purpose a Mac. Common tools are macOS Server’s NetInstall, DeployStudio, AutoCasperNBI, or Imagr.

On top of that some NetInstall features, such as automated installation and adding custom packages were broken in earlier releases of 10.13.

Also booting off external drives became much harder on the iMac Pro, since its default security prohibits external boot and you have to go through the entire installation process before you can re-enable it.

Also Apple announced that the macOS Server app will lose most features, including NetBoot/NetInstall in a future release later this year. (My post on that, from January.)

What changed in 10.13.4?

The ‘spring update’ macOS 10.13.4 brought a few welcome changes.

We got a glimpse of some of these in February when HT208020 was briefly updated with new information. Interestingly, now that 10.13.4 is released, HT208020 has not been updated.

However, we got new detailed information in this article:

Enterprise content:
 - No longer disables User Approved Kernel Extension Loading on MDM-enrolled devices. For devices with DEP-initiated or User Approved MDM enrollment, administrators can use the Kernel Extension Policy payload.
- Improves Spotlight search results for files stored on network mounts.
- Properly evaluates ACLs on SMB share points.
- Adds the --eraseinstall flag to the startosinstall command in the macOS Installer app at Contents/Resources/startosinstall. Use this flag to erase and install macOS on a disk. For details, run startosinstall with the --usage flag.
- Updates System Image Utility to allow creating NetInstall images that erase and install macOS to a named target volume.

Robert Hammen posted a great summary on Slack.

Not documented here, but 10.13.4 also fixes the bug that the defaults command deletes non-plist files.

UAKEL

The first one is really important. Apple introduced a new security feature called “User Approved Kernel Extensions” (UAKEL) in 10.13. This means that third party kernel extensions have to be approved by the user at the Mac (within 30 minutes after installing) before they can be loaded.

Prepare for changes to kernel extensions in macOS High Sierra – Apple Support

In 10.13.0–10.13.3 Apple simplified the life of Mac admins by disabling UAKEL on Macs which were enrolled with an MDM. In 10.13.4 Apple added a Kernel Extension Policy profile payload which allows Mac admins to whitelist certain Kernel Extensions centrally from the MDM.

This is a useful addition and allows Mac admins to manage Kernel Extensions before they are installed and without the necessity of user interaction.

However, 10.13.4 also changes the previous behavior for UAKEL on MDM managed Macs. Since admins now have a way of whitelisting Kernel Extensions, UAKEL will be enabled, even on MDM managed Macs.

If you were installing a Kernel Extension on a managed Mac from 10.13.0 to 10.13.3 it would work, since MDM disabled UAKEL. Once you upgrade that Mac to 10.13.4, UAKEL will turn active and it will block the Kernel Extension from loading, unless there is a profile whitelisting the extension!

When the extension was previously manually approved on 10.13 or grandfathered in when the Mac was upgraded from 10.12, then it will still run under 10.13.4. While all of this has some internal logic, it will lead to strange situations were Kernel Extensions will load on some clients and not load on others.

The best way to avoid the confusion is to have the Kernel Extension Policy profile ready and in place before your clients update to 10.13.4. In other words: now!

User Approved MDM

However, (yes, there is another ‘however’ here). The Kernel Extension Policy profile has to “be delivered via a user approved MDM server.” This is another level of security introduced to keep the user in the loop.

Apparently there is malware/trojans that tricks users into accepting MDM profiles to connect their iOS devices or Macs to malicious MDMs. I am not convinced these new measures will be effective against this kind of trickery, though.

Macs deployed with the Device Enrollment Program (DEP) are considered “user approved” by default. Otherwise the user has to approve the MDM profile when it is installed. Again, this cannot be automated or approved over remote control.

This can throw a wrench into non-DEP installation workflows (sometimes also called user-initiated enrollment). Some management systems will let the user download a pkg that installs the MDM profile and necessary certificates. Some solutions install the MDM through an agent software (which is still necessary for many tasks that the mdm client software cannot perform). Either of these workflows will require the user to go to the Security pane in system preferences within 30 minutes after installation.

Note: Jeremy Baker found a creative way that uses User-interface scripting to click the approve button. However, his script requires Accessibility access for the script, which also cannot be provided in an automated fashion. (The database in question is protected by SIP.)

However, in 10.13.4, when a User installs the MDM profile directly by double-clicking it, they will be prompted to approve the MDM as part of the profile installation dialogs, streamlining the process.

Rich Trouton has documented the new workflows for the user in these articles:

For Jamf you will need to upgrade your Jamf Pro server to version 10.3 to get the new workflow. Other management solutions may already implement this or also need to be on the latest version to work well with these new requirements.

startosinstall

The next interesting new feature is for startosinstall which gains a new --eraseinstall option.

Graham Pugh has already documented this very well:

Erase All Contents And Settings – erase and reinstall macOS in situ

This allows for automated workflows where you can wipe and re-install macOS, add a few custom packages to the installation process with --installpackage arguments, which configure your management system. Then after first boot your management system takes over and installs/configures the rest.

It is important to note that startosinstall uses some APFS volume creation trickery to make --eraseinstall work. This means that you cannot run --eraseinstall on a Mac with a HFS+ system volume. You have to already be on a 10.13 system with APFS to use this option.

Nevertheless,--eraseinstall is a welcome and necessary addition to startosinstall. However, what struck me most about this is that this is the first time Apple is even mentioning the startosinstall command in any documentation. Since this tool is central to many approaches to automate the installation process, I am happy it is finally getting recognized as ‘official’.

NetInstall

The last feature isn’t really new. Apple fixed a bug that has been around since 10.13.0. In previous versions of 10.13, when you built a NetInstall set with System Image Utility and chose the option for “Automated Erase Install” on a certain volume (by name), the installation would just stall at a grey screen. Now, this option works as expected, when you build the NetInstall set from 10.13.4.

The days of NetInstall are still numbered because the iMac Pro (and presumably future Macs with similar controllers) cannot NetBoot at all, and macOS Server is loosing NetInstall along with many other services. Nevertheless, this provides another Apple-supported workflow for automated erase and re-install which you can customize with your own packages.

NetInstall (with or with out the erase) is also a good workflow to upgrade Macs with older versions of macOS to 10.13. (In this case we don’t care that it doesn’t work for iMac Pros, since they already come with 10.13.)

Since, currently, in most deployments the iMacs Pro will be a significant minority (if present at all), this allows administrators to deploy a well known workflow (NetInstall) for the existing fleet this year, while figuring out new workflows (startosinstall + DEP?) for future Macs.

There are, however, still a few kinks left with NetInstall workflows:

More Options

There was no Spring Update resurrection: Imaging is still dead.

It is obvious, that while Apple may not be going in exactly the direction that we would like them to, they are listening to criticism and providing solutions, albeit slowly. The additions to startosinstall and the fix to NetInstall now allow for automated wipe and install workflows. These were not really possible before.

However, installation workflows, however you start them, are much slower than block copying a prepared image. This is an important consideration for education deployments, which usually re-image dozens, hundreds, or even thousands of Macs over the summer break.

But this update now provides a few useful options for High Sierra:

  • use NetInstall Automated Erase to wipe and upgrade existing Macs from earlier macOS versions to 10.13
  • use startosinstall to upgrade and update Macs (including iMac Pros) to the latest version of 10.13
  • use startosinstall with --eraseinstall to ‘wipe and install’ existing 10.13 Macs
    • this will only work with 10.13 SSD Macs with APFS. Since Fusion drives and HDs cannot get APFS yet, you will have to use NetInstall to convert/upgrade these Macs, when (if ever) they support APFS
    • iMac Pros cannot use automated NetInstall, however, since they definitely have APFS 10.13 already installed, you can use startosinstall --eraseinstall
  • if fast restore times are important (like a loaner MacBooks scenario, where devices need to get reset to a well-known state quickly), use any of the above to get the Macs up to the latest 10.13, then you can still use imaging to quickly lay down a ‘fresh’ image of the same macOS version
    • you will need to put in extra effort to keep the image system version in sync with the version installed (or upgraded) on the target Macs

Now is the time to start testing, testing, testing to get your workflows ready for the summer re-installation marathon and the 10.14 release in the fall. (And to give Apple another chance to fix the remaining issues in the next update.)

I have ignored the file share changes in this post. While these are certainly important, they don’t really have influence on deployment strategy.

Join the MacAdmins on the MacAdmins Slack to share experiences and solutions!

Apple’s new Upgrade/Update Strategy

There is another aspect of the Spring Update.

Apple switched to the yearly upgrade cycle for Mac OS X with 10.7. (Upgrade meaning a ‘major’ version change, i.e. 10.8 -> 10.9. Nevermind that Apple uses the second version number for the major version. More on macOS version numbers here.) Apple did summer releases for 10.7 and 10.8 and then switched to the Fall release schedule. Since 10.9 releases have been reliably in late September or October.

The rule used to be that upgrades would bring lots of new features, both visible to the user and under the hood and then Apple would release updates (the third number in the version) to fix bugs and issues. Sometimes new features would be introduced in updates, but those were rare exceptions and usually done to match with iOS or iCloud (dotMac, Mobile Me) features.

The rule of thumb was that the first two or three releases were for ‘early adopters’ only and it would be fairly safe to migrate to the new major version by the third or fourth update. Admins could join the developer program to get access to the developer releases of the next upgrade after WWDC, but getting your hand on early releases of the updates was more difficult.

iOS, on the other hand, has had a different pattern. Apple released iOS 4.2 in the spring with new features to support the then new iPad. Since the iPad and iPhone hardware releases rarely synced to the same time of year, iOS has had a pattern with a major new iOS release in the Fall (usually with a new iPhone) and a ‘Spring Update’ with new features to match with a new iPad.

Even though the Mac hardware follows yet other cycles. We now see this Fall Upgrade/Spring Update pattern with macOS as well.

Apple has added new features in 10.13.4. Some are visible to users (eGPU support, Business Chat, new privacy dialogs), some are for client management (UAMDM, UAKEL profiles, new configuration profile documentation).

We now also have a public beta program for iOS and macOS which covers not just the major upgrades, but ‘minor’ updates as well. The beta versions for iOS 11.4 and macOS 10.13.5 were released right after 11.3 and 10.13.4. And it looks like they will contain yet more new features (iMessages on iCloud and AirPlay 2).

The fact that Apple is willing to add new features or change existing fucntionality at any time during the update cycle is a win to users. It is also a reaction to competitors more-cloud based solutions that can be updated at any time.

However, for us admins this means change:

  • the notion of a ‘stable’ release is a thing of the past.

Features might be added or changed at any time during the upgrade cycle. Different parts of the deployment and workflow will be in different stages of ‘maturity’. Additionally, parts of the workflow (DEP, MDM, and VPP) exist in the cloud and might also change at any time (Apple School Manager was not introduced with a major iOS release and it looks like Apple Business Manager will not sync with a major iOS or macOS release, either).

macOS and iOS don’t stand alone. Apple (and third parties) are building networks of operating systems, software, devices and cloud-based services. Scheduling these releases in to a yearly major update cycle must be nearly impossible. It is also not necessary as distribution of software has become reliable, secure, and fast enough to push frequent updates.

In some ways Apple is reacting to their more cloud-based competitors, which can and will push incremental updates to their systems continually.

  • ‘permanent beta’ mode

The beta versions for iOS 11.4 and macOS 10.13.5 were released hours after the release 11.3 and 10.13.4. If you are concerned how the new updates will work (or not) in your environment, you have to be testing now.

This is being a pro-active adminstrator. Rather than waiting for problems to occur and trying to fix them, you are anticipating problems and trying to pre-empt them. The traditional release cycle of the past allowed us to switch between the two roles over the year. Now, we are either in permanent beta-test or in permanent break/fix.

I don’t think any one likes it, but it is the situation we have to deal with and I don’t see that changing any time soon. You will have to adapt your and your organization’s workflows to adapt to this new situation.

  • Apple is listening and communicating the changes

Provide feedback (bugreports) to Apple. Not all the issues you find will be fixed (some might be).

However, this gives you time to document issues for your users and allow you to implement management strategies to ameliorate them. (Even if all you can do is write knowledge base articles along the line of “we know this is broken” you are saving some people a lot of time and nerves.)

I find it very interesting and encouraging that we are learning about these changes in offical support articles. Also then changes to UAKEL and UAMDM were based on user feedback, mainly adminstrators who complained that the feature as it was initially implemented was unmanageable.

Of course there are many other challenges and issues which have not been fixed (yet). But it is encouraging to see this kind of feedback work.

I have written a book which expands on this topic and is regularly updated. Please check it out: “macOS Installation for Apple Administrators

Installing and Using Command Line Tools

There are many command line tools and scripts you can download and install that are very useful for Mac Admins.

(Just a representative list, certainly not complete.)

Some of these tools provide installer packages that deploy the tool in the proper directory – usually /usr/local/bin so that you and other users can use it. (/usr/local/bin is in the macOS default PATH.)

However, many of these tools, such as munkipkg or my own quickpkg just come as a git project folder, with no or few instructions to get it set up. The assumption is, that when you use these tools you are familiar enough with the shell to make them work.

There are actually several approaches to getting these tools to actually work for you, most with different upsides and downsides. This post will talk about a few of them.

Getting the Tool

Before you can choose a method to run the tool, you need to get it. Many admins share their scripts and tools through a hosted service like Github. My quickpkg tool, for example, is a python script hosted as an open Github repository.When you follow that link you will see the main project page. The page has a menu area up top, a file list in the middle and below an area where an introduction to the project (the ReadMe file) is shown. It is worth to read the ReadMe in case they have special installation instructions.

Download the Release

Git is a version management tool that lets you track changes throughout the coding process. Github is one popular service to host these projects online. Contributors of a project have the option of marking steps of the project as a ‘release.’ Releases are considered a tested and stable stop in between less reliable developmental steps.

Releases will be shown in the project’s ‘releases’ page (link in the middle of the page, above the file list). (quickpkg releases page

On the releases page you will see a list of releases with the newest on top. At the very least each release will have a snapshot of the project’s code as a zip or tar.gz archive. Some projects provide other archives or installers such as dmg or pkg as well.

Download the Current Project

Some projects do not manage releases. (You will see ‘0 releases’ in the tool bar.) Then you can still download the most recent version of the project. There is a large green ‘Clone or download’ button on the right area above the project’s file list for this. When you click that button it will expand to show some more options.

‘Download ZIP’ will simply download an archive of the current state of project, much like the release download would.

When you download the archives, either through the releases page or from the ‘Download ZIP’ button, the resulting project folder will not be connected with the Github project any more. If you just want to use the current version, then that is fine and will serve you well. If you want an updated version in the future you will simply download the newer version and replace the tool you already have.

If you rather use git to download and manage the code, then you can do that here, too. However, that is a topic for another post.

Using the Tool

However you get the project you will now have a directory with the tool and any supporting files. You can already change directory to this folder in Terminal (drag the folder on to the Terminal icon to open a new Terminal already changed to it) and run the tool directly:

$ cd ~/Projects/quickpkg/
$ ./quickpkg
usage: quickpkg [-h] [--scripts SCRIPTS] [--preinstall PREINSTALL]
                [--postinstall POSTINSTALL]
                [--ownership {recommended,preserve,preserve-other}]
                [--output OUTPUT] [--clean] [--no-clean] [--relocatable]
                [--no-relocatable] [--sign SIGN] [--keychain KEYCHAIN]
                [--cert CERT] [-v] [--version]
                item_path
quickpkg: error: too few arguments
This will do for tools that you use rarely. But for tools that you want to use frequently typing the path to the tool is quite cumbersome.

Put it in the PATH

The PATH environment variable lists the directories where the shell looks for commands. You could add the project directory of the tool you just added to the PATH, but that would be tedious to manage.

An easier solution is to copy the tool to /usr/local/bin. This is the designated directory for custom commands. /usr/local/bin is also in the default macOS PATH.

However, copying the tool has some downsides. When the tool get’s updated you will have to copy the newer version, as well. Also some tools may require additional resources or libraries that reside in its project directory.

Instead of moving the tool, you can create a symbolic link to the tool in /usr/local/bin.

I keep the project folders of tools in ~/Projects so I use the command:

$ sudo ln -s ~/Projects/quickpkg/quickpkg /usr/local/bin
$ ls -al /usr/local/bin/quickpkg 
lrwxr-xr-x  1 root  wheel /usr/local/bin/quickpkg -> /Users/armin/Projects/quickpkg/quickpkg
Since symbolic links use paths, this has the advantage that when you download a newer version of the project to the same location, the link will point to the new version.

Putting links to a tool in /usr/local/bin has a few downsides (or upsides, depending on your perspective):

  • you need to have administrator privileges to change /usr/local/binlinks/tools you add to /usr/local/bin affect all users on that Mac

Set your own PATH

When you want to have the tools only affect your shell environment you need to do a bit more work.

First you need to choose a location where you tools or links should live. I have created a directory ~/bin for that purpose.

$ mkdir ~/bin
When you don’t want anyone else on the Mac to see what you are doing in that directory, you can remove everyone else’s access to it:
$ chmod 700 ~/bin
If you want you can also hide the directory in the Finder:
$ chflags hidden ~/bin
(Use the same command with nohidden to make Finder show it again.)

(To test the following properly, you need to delete the symbolic link we created earlier in /usr/local/bin. If that still exists the shell will use that, since it comes earlier in the PATH.)

You can create a symbolic link to the in ~/bin with

$ ln -s ~/Projects/quickpkg/quickpkg ~/bin
However, these still will not work, since we need to add the ~/bin directory to your personal PATH.

To do that you need to add this line to your ~/.bash_profile or ~/.bashrc:

export PATH=$PATH:~/bin
(Read more about how to create a bash profile here and here. This assumes you are using bash, the default on macOS. Other shells will have other locations where you can change environment variables.)

Then open a new Terminal window or type source ~/.bash_profile so that the new profile is loaded in the current window and try running the command.

Success!

Weekly News Summary for Admins — 2018-03-30

What a week!

This would have been an interesting with many amazing articles and posts by fellow MacAdmins on different topics. But then there was Apple’s Education event and (finally) the spring updates (10.13.4, 11.3 etc.) dropped yesterday.

10.13.4 brings (yet again) many changes for macOS management, read the summaries and posts carefully.

PSU MacAdmins Conference 2018 registration is open!

If you would rather get the weekly newsletter by email, you can subscribe to the Scripting OS X Weekly Newsletter here!! (Same content, delivered to your Inbox once a week.)

Happy Easter! (Hope you get a long Easter week-end to catch up with the reading!)

#! On Scripting OS X

📰News and Opinion

Education Event

Spring Updates

🐞Bugs and Security

🔨Support and HowTos

For macOS 10.13.4

🤖Scripting and Automation

🍏Apple Support

Spring Updates

Security

♻️Updates and Releases

📺To Watch

🎧To Listen

📚Support

I do not have any ads on my webpage or this newsletter. However, if you want to support me and this website, then please consider buying one (or both) of my books. (Imagine it’s like a subscription fee, but you also get one or two useful books on top!)

If you have already bought and read the books, please leave a review on the iBooks Store. Reviews are important to help new potential readers make the purchase decision. Thank you (again)!