Providing new installs of macOS, or upgrading to newer versions, can be a challenge in many Mac environments. Apple’s OS distribution model is focused around the Mac App Store (MAS), which may not be an option for a number of managed Mac environments. The MAS-distributed OS installer also does not include the option of adding additional third-party packages to the OS installation process; it only installs the software that Apple itself includes in the OS installer.
To address these needs, an open-source tool named createOSXinstallPkg is available. createOSXinstallPkg allows you to create an Apple installer package from an “Install macOS.app”. You can use this package for the following:
- Installing OS X or macOS onto an empty drive
- Upgrading existing OS X or macOS installations to a newer version of the operating system
The advantage of using this tool is that a number of system deployment tools for Macs can deploy the installers created by this tool, allowing OS installations or upgrades to be performed by the system management tool already in use by a particular IT shop. One great thing about using this tool is that createOSXinstallPkg will create an installer package that either installs a stock copy of either OS X or macOS, or you can add additional packages to the stock OS install.
When adding packages, there are a couple of guidelines to keep in mind:
- There is about 350 megabytes of free space available in the OS installer. This is sufficient space for configuration or bootstrapping packages, but it’s not a good idea to add Microsoft Office or similar large installers.
- The limitations of the OS install environment mean that there are a number of installers that won’t install correctly.
In particular, packages that use pre-installation or post-installation scripts may fail to run properly when those packages are run as part of the OS installation process. To help work around this limitation, I’ve developed a solution which I’ll be discussing later in the post. For more details, see below the jump.
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.
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
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.
MacAdmin 101: Building a recovery partition installer package using Create Recovery Partition Installer.app
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.
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.