Volume Number: 24 (2008)
Issue Number: 01
Column Tag: Mac in the Shell

Mac in the Shell: Mass Remote Management with dshell

Or, mass remote management without ARD

by Edward Marczak

Introduction

A feature article this month covers methods to manage an army of Macs post-deployment. In other words, after they've been imaged and rolled out to the masses. The products and methods listed there are certainly applicable and appropriate for many situations. I'm going to describe yet another method that comes in handy in other situations. dsh, the distributed shell, can run a command over groups of machines that you specify. It performs this magic over ssh, so, you can affect machines over LAN or WAN links, near or far. Since OS X and other machines have ssh in their base distribution, you can command across platforms. This article explains how you, too, can send out commands to all or a group of your Macs - simultaneously - with a single press of the return key.

While there are many nice apps in the base distribution of OS X, dsh is not one of them. dsh is an agentless controlling app, so fortunately, you only need to retrieve, compile and install on one host, or any admin station that you need. You'll need a compiler on some station to compile the program - typically meaning having Apple's developer tools installed.

Two downloads are needed to get us going. Visit this page:

http://www.netfort.gr.jp/~dancer/software/downloads/list.cgi

and retrieve the latest versions of dsh and libdshconfig. As of this writing, they are:

http://www.netfort.gr.jp/~dancer/software/downloads/dsh-0.25.9.tar.gz

http://www.netfort.gr.jp/~dancer/software/downloads/libdshconfig-0.20.9.tar.gz

It's easy to take care of everything while in terminal: just use curl to download the files needed (use "curl -O http://.."), tar to unpack (tar xzvf filename) and then it's simple to compile. Both pieces of code compile cleanly in OS X 10.4 and 10.5, and install in /usr/local by default. Enter the libdshconfig directory that you just unpacked, and simply enter the following commands (your entries in bold):

$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
[output snipped]
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands
$ make
make  all-am
[output snipped]
creating libdshconfig.la
(cd .libs && rm -f libdshconfig.la && ln -s ../libdshconfig.la libdshconfig.la)
$ sudo make install
Password:
/bin/sh ./mkinstalldirs /usr/local/lib
[output snipped]
 /usr/bin/install -c -m 644 libdshconfig.h /usr/local/include/libdshconfig.h

Next, we need to do the same for dsh itself. Change into the dsh directory you unpacked, and repeat the same process that you just went through for libdshconfig (configure, make, sudo make install). The entire process should take you less than 5 minutes. Literally.

While you can alter the install directory, I recommend that you leave the default values, and have the binaries and config files installed under /usr/local. I'll be referencing that as the install location throughout this article.

You can verify installation by typing "/usr/local/bin/dsh". You should be told, "dsh: no machine specified", and dsh would be right.

Now that we have dsh installed on our administrative machine, how do we use it? Fortunately, under Leopard, /usr/local is a 'blessed' location, and is already in our $MANPATH. If you're using 10.4, you'll need to add "/usr/local/share/man" to $MANPATH and export it, or re-source your init file. dsh comes with some short-but-useful man pages. First, we'll need to update the configuration file.

If you left each application take the default values during their configure stage, and I recommend that you do, you'll find the main config file at /usr/local/etc/dsh.conf. We need to make one change to this file. So, whip out your favorite text editor, and change the line that reads:

remoteshell =rsh

to read:

remoteshell =ssh

(If you're daring, this can be achieved in one line with sed: sudo sed -i .back s/rsh/ssh/ dsh.conf). You may also want to change the "waitshell" value from "1" to "0". With a setting of 1, dsh will block execution until the previous machine has returned. As I said, you may want to change this. It's really applicable for very large rollouts. There's a man page available for the configuration file accessible with "man dsh.conf".

Before we continue, we need to take a step back and plan things out a bit. We need to determine which machines we're going to be targeting. Since we've chosen ssh as the remote mechanism, each machine that we're going to want to control needs ssh enabled. Now a days, this is the default for most platforms and distributions. That said, unless we want to enter our password each time we make a dsh run, we're going to want to create a public key and install it on any machine that we want to administer. Also, we also need a list of computers for dsh. This list basically tells dsh, "hey - run this command on all of these machines."

ssh was covered extensively in this column in the October 2007 issue, but, as a quick refresher, here's the sequence of creating a public key for ssh's use:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/admin/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/admin/.ssh/id_rsa.
Your public key has been saved in /Users/admin/.ssh/id_rsa.pub.
The key fingerprint is:
6e:4b:ca:45:2d:c7:3d:14:d2:34:1e:ad:45:a5:fc:8e admin@machine-name.local

In this sequence, you simply press enter when asked for the passphrase and to verify. Notice that the output tells you that "your public key has been saved in...". Change directory to ~/.ssh. We need to copy the contents of the newly generated id_rsa.pub file to each machine that we're going to manage. Fortunately, this is a one-time step.

Easiest instructions to write: ssh to the machine you're going to target, using the admin-level account that you'll be running remote commands with:

ssh admin@remote.example.com

Once in, run this command:

ssh user@my.machine.com "cat ~/.ssh/id_rsa.pub" >> ~/.ssh/authorized_keys

where 'user' is the user account that you just had generate the key for, and "my.machine.com" is the machine where that user id resides - likely the machine you're on right now. Once done, type exit, and then try to ssh again. This time, you should not be asked for a password, but rather, simply receive a remote shell.

In the event that you cannot ssh back to your machine, you can always manually copy your key to the remote machine and add its contents to the ~/.ssh/authorized_keys file on the target account. For more about ssh, creating ssh keys and troubleshooting, see my ssh article in the October 200 issue of MacTech Magazine.

While you are accessing each remote machine, you need to keep a list of the account that you're accessing it with, and its fully qualified domain name (FQDN) or IP address. Once complete, take this list and enter it into /usr/local/etc/machines.list in this format:

/usr/local/etc/machines.list
nyadmin@ny.radiotope.com
caadmin@ca.radiotope.com
fladmin@fl.radiotope.com
azadmin@az.radiotope.com

Now comes the fun part!

Let's start with a easy one: viewing the uptime statistics on all of the machines we've identified. This is as easy as:

$ dsh -a uptime 16:38 up 14 days, 9:27, 2 users, load averages: 0.19 0.13 0.16 16:38 up 59 days, 7:09, 1 user, load averages: 0.02 0.02 0.00 13:42 up 93 days, 3:25, 2 users, load averages: 0.02 0.02 0.00 1:39PM up 213 days, 4:01, 0 users, load averages: 0.12, 0.08, 0.04

It's a complete coincidence that those are in order of uptime! However, that raises the question: what order are they in? The "-M" switch will prepend the machine name before its output. Let's see that in action:

$ dsh -M -a uptime
nyadmin@ny.radiotope.com: 16:41  up 14 days,  9:30, 2 users, load averages: 0.47 0.27 0.21
fladmin@fl.radiotope.com: 16:41  up 59 days,  7:12, 1 user, load averages: 0.00 0.00 0.00
azadmin@az.radiotope.com: 13:45  up 93 days,  3:28, 2 users, load averages: 0.01 0.02 0.00
caadmin@ca.radiotope.com:  1:42PM  up 213 days,  4:04, 0 users, load averages: 0.04, 0.07, 0.04

There, that's a little better. The "-a" switch tells dsh to run the command against all machines that we've defined.

If you opted to not use a waitshell - your config file still has the line "waitshell =1" - you can override this at runtime using the "-c" switch. Also, if there's a machine that you have not added to your machines.list file, but want to use it ad-hoc, use the "-m" switch. Combining all of these options would look like this:

$ dsh -M -c -m txadmin@tx.radiotope.com -a 'last | head -1'
fladmin@fl.radiotope.com: fladmin  ttyp0    192.168.70.108   Thu Nov 29 15:22 - 15:22  (00:00)
caadmin@caadmin.radiotope.com: caadmin  ttyp1    192.168.70.108   Thu Nov 29 15:09 - 15:09  (00:00)
nyadmin@ny.radiotope.com: nyadmin  ttyp2    192.168.70.108   Thu Nov 29 12:29 - 12:29  (00:00)
Password:
txadmin@tx.radiotope.com: root      ttys000  w1.z2.nyc-ny.example.net Thu Nov 29 09:29 - 09:35  (00:05)
fladmin@fl.radiotope.com: fladmin          ttyp0    10.0.2.3       Thu Nov 29 13:37 - 13:37  (00:00)

In one fell swoop, this runs the command "last | head -1" on all machine defined in our machines.list file and additionally on "tx.radiotope.com". You'll see the "Password:" prompt in the output above as tx.radiotope.com wasn't preconfigured and is using password authentication. Once the (correct) password is entered, it happily gives us the output we're looking for, just like the other machines.

dsh is useful enough already, but how can we make our lives even easier? First, you may not always want to run all commands on all machines. There are two ways around this. One way is to use a group file. Simply create a file using the same format as machines.list and store it in /usr/local/etc/group/groupname. So, let's say we wanted to target all of our West Coast servers. We could create /usr/local/etc/group/west_coast and add to it:

/usr/local/etc/group/west_coast
waadmin@wa.radiotope.com
caadmin@ca.radiotope.com
oradmin@or.radiotope.com

Now, we can run commands against just this group:

$ dsh -M -g west_coast w

This will give us "who" (w) information from each server in the "west_coast" group.

Also, you can specify full server lists in an ad-hoc fashion. Create a file using the machines.list format, and specify it with the "-f" switch.

Nicely, if a machine definition ends up in multiple files, specifying it multiple times will be reduced to a single invocation.

The real magic here is that all input to dsh are simple text files. Decisions can be made, results grabbed from a database, files created on the fly and commands send to appropriate groups of machines. Think about how you could group machines: by location, by service (web, directory services), by class (PPC, dual-proc), by use (administrative, development), etc.

In Conclusion...

Despite the subhead, I don't believe dsh is meant to replace ARD. However, for server management, it may fit into your workflow better and can reach out to machines that ARD can't touch (think Linux or BSD servers...even Windows, with the right software and mindset). This can give you some incredible control over armies of machines. You have all the power of a shell on the remote machine. You can be very creative and powerful with this!

Until I found dshell, I used to do something similar by using a for loop to execute commands across machines:

for i in `cat servers.txt`; do
ssh root@$i softwareupdate -i -a
done

However, dsh has been thought out much more than the "for-loop-solution" and is much more extendible.

Don't run dsh in your production environment until you read the man page, which details some other options for limiting how many remote machines are accessed at any given time. (Look for the -N and -F options, specifically).

Media of the month: Walt Whitman, The Complete Poems. Start the year off with some poetry - especially if it's not your usual fare. Walt Whitman doesn't do it for you? Check out James Joyce or Emily Dickenson - there are amazing gems in that timeless writing.

Happy New Year!

Ed Marczak is the owner of Radiotope, a technology solution provider. He is also a husband, father and avid wearer of pants. tail -f /dev/brain at http://www.radiotope.com/writing