You’ve got a script. Maybe you wrote it or maybe you found it online, but it handily solves a problem your users face or does a task you typically spend several minutes on with a single command many times a day. With any RMM platform, it would normally be a simple matter of deploying the script to those devices, setting the schedule for it to run, then sitting back and sipping your beverage of choice. Unless you’re in the server room—no food or drink in the server room.
But what if the problem you’re solving is that Mac that can’t connect to the server? Or that its configuration is somehow corrupted and it won’t stay connected? Or, for that matter, the user is remote and you don’t have a remote management platform yet and need to install one.
You’ve wandered into a classic catch-22: in order to install or fix remote management, you need working remote management.
You could email the script to the user with instructions for running it in the Terminal, but that way lies madness. Terminal is scary. Nobody reads the instructions. And even when they do, there’s no way to anticipate every question you’ll get: “Do I include the quotation marks around my password? What is my password?”
No. You need to deliver something that any average user can double-click on and be reasonably confident it will run without a hitch.
Installing your new app
Aside from the occasional custom installer app, there are two primary ways in which a user installs applications on their Mac. The first is dragging the new app’s icon into the Applications folder. The second is launching the macOS Installer.app by double-clicking on a PKG file. The package format includes the ability to run scripts before and/or after the installation process. You can use this to your advantage even if you’re not actually installing anything. While building a full drag-and-drop application requires learning Xcode and Swift, all you need to create your own PKG installer is a Mac and your script.
I write most of my automations in Bash, or to be more precise these days, zsh. I still call them “Bash scripts” because I like to believe it makes me sound like I’m swinging a battle axe (“Script, bash!”). But a script deployed via PKG can be in any language the target Mac understands. AppleScript, Python, Ruby, PowerShell—if you are confident that a compatible interpreter is installed, use your weapon of choice. Just be sure to include the proper “shebang” line at the beginning (#!/bin/bash for example).
Once your script is tested and working, rename it to “postinstall” and put it into a folder called “scripts”.
Avoiding Terminal terror
The rest is done in Terminal. Do not be afraid. There are utilities that will do this part for you and add in some optional bells and whistles but, for our purposes, it requires just two commands.
Navigate to your scripts folder, the one with “postinstall” in it. That will need to be executable so it will run as part of the installation. Like so:
chmod a+x postinstall
Then, the magic incantation to create the package:
Replace “your.unique.identifier” with a string that will identify you as the author in case someone examines the PKG. These are usually in the form of a “reverse domain name” like “com.example.installer” but really, it could be anything that’s unique. Also, fill in the paths for the scripts folder and where you want the PKG file to appear.
If you’ve done it right, you should end up with a file you can send to any user and have them double-click and install. The script will run, hidden behind the friendly façade of the system installer, with no need for them to launch Terminal or type in commands. They will need to remember their password though.
[Challenge for advanced students: Write your own script that automates this process!]
Talk to me
As I continue to dive into all things Mac-admin related, I’d like to hear from you. Are you new to managing Macs? Do you still have a binder of installers on 3.5” floppy disks? Ask your questions or share your favorite tips for the newbies—or a good dad joke. Email me at [email protected].