Home > Apple Remote Desktop, Mac OS X > Script-only installer packages

Script-only installer packages

Back when Apple Remote Desktop 1.2 (ARD) was the main tool I used to administer my Macs remotely, I wanted to be able to run Unix commands remotely but needed a delivery vehicle so that I could send them over ARD. The way I found was to use script-only installer packages. Installer packages are Apple’s preferred way to install software, and what their applications show up in. Since Apple also builds ARD, they built in the ability to install software on remote machines using the Install Packages function. The neat thing about packages is that you can have them run a Unix shell script before or after the package is installed. You can even set up a number of scripts and have them run in the order you want them to. Best of all, you can build a script-only installer package where the only payload inside the package is these scripts, with no software to be installed. So, when I needed to run a Unix command on one or more of my OS X boxes, I’d normally build a script-only package and use the Install Packages function to push it out over ARD. 
Now, with ARD 2, Apple listened to the piteous cries of its users and built a Send Unix function. This gives you the ability to send a Unix command and get the feedback from the remote machine, without the extra work of building a script-only installer package. This is a Good Thing, but I’m still more a fan of script-only installer packages. Here’s why: 
Using an install package to do what you need to do, vs. using ARD’s send Unix command, gives you a couple of advantages: 
1. You only need to build it once – I have a couple of packages to 
handle turning SSH on or off on ARD-managed Macs. I distributed them for 
use by my team. I didn’t need to tell them the command, and I don’t need to remember myself. I just need to push the package called “SSH_On” to turn SSH on, then push the package called “SSH_Off” to turn SSH back off when I’m done. I have a number of packages like that, but that’s the general idea. 
2. Shell script packages – Using script-only install packages, I can write 
an entire shell script which doesn’t need to stay resident on the target 
Mac. For example, I have a Software Update script-only install package. It 
does 4 things: 
1. Repairs permissions 
2. Use the command line softwareupdate tool to get all updates from Apple for that Mac. 
3. Repairs permissions again. 
4. Restart. 
I can run all of those tasks separately via Send Unix, but doing it with a package means each machine can run it at their own speed and I don’t have to wait on the B&W G3 to finish while the G5’s been waiting for 10 minutes for my next command. I can push once and be done with it.  
3. Send Unix doesn’t doesn’t allow for shell scripting, unless the shell script is already resident on the target Mac – This for me, is the killer advantage script-only installer packages have over Send Unix. You can kick off a previously copied shell script via Send Unix, but you can’t use it without the shell script already being there on the remote Mac. With a script-only installer package, the script is along for the ride. 
Send Unix has its place, and I use it frequently. For some ARD functions, however, you can’t beat knowing how to make and deploy a script-only installer package. 

  1. gkjapan
    September 23, 2009 at 3:12 am

    I’m trying to send out a unix command via ARD 3.3 using the task server so I don’t have to have the targets online. Have you found a better way to send out Unix commands via ARD or are payload-free packages still the way to go?

    I’ve also noticed that the Welcome.txt in your packages contain the text, “payload-free package created by PFPackage”. Is PFPackage an application that helps make the process simpler? If so, can you let me know where to find it?


    • October 1, 2009 at 1:03 am

      I still think payload-free packages are better than sending Unix commands via ARD, but your mileage may vary. The exception is if you’re trying to run an actual script, as opposed to individual Unix commands. In a case like that, a payload-free package is usually the better way to go.

      PFPackage was an AppleScript Studio application I was given a copy of back in the 10.3.x days by an Apple engineer that was doing some work at my site, but it was with the understanding that it wasn’t for general release.

  2. gkjapan
    October 1, 2009 at 5:56 am

    Thanks for the reply. I think I still want to use payload-free packages, but I just wish I had something simple like PFPackage to do the work for me. 🙂 I guess I’ll just have to do it the hard way.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: