These instructions are unofficial. OLPC does not support them.
THESE INSTRUCTIONS ARE EXPERIMENTAL.
FOLLOWING THEM MAY DAMAGE YOUR MACHINE.
By following them, you take responsibility for this risk.
(from the dsh homepage): dsh is an implementation of a wrapper for executing multiple remote shell (rsh/remsh/ssh) commands. rsh/remsh/ssh are wrappers for executing shell (ksh/bash/zsh/tcsh/sh .. etc... ) on remote hosts.
The community testing group is experimenting with using dsh to:
- Manage large testbeds with many XOs together in 1 room (100 XOs in an office or a school, etc.)
- Create impromptu distributed large testbeds from multiple small XO pools
- Use an XS to monitor the XOs connected to it
How to use for XO testing
- The instructions below will use the term supervisor to refer to the computer you are running the commands from (and on which dsh is installed), and the term XO to refer generically to any XOs in the testbed you are remotely managing.
- Unless otherwise stated, all instructions are intended to be executed by/on the supervisor machine.
- You must have terminal access to the supervisor machine.
- These instructions have only been tested with Linux (Debian/Ubuntu). Help testing and writing instructions for Mac OS X, Windows, and other operating systems is welcomed.
- Follow the instructions on the dsh homepage to install dsh.
- Generate an SSH keypair. Instructions on how to do this can be found here (Linux, concise), here (Linux, detailed), and here (Windows). You should end up with these two files in the .ssh folder in your home directory: id_rsa and id_rsa.pub.
- For each XO in your testbed (follow these instructions on your XOs):
- Connect to the network.
- Copy the id_rsa.pub file you just generated into a new line on your supervisor machine into the
/home/olpc/.ssh/authorized_keysfile of each XO (use a thumbdrive, or upload to the web and use wget). (The
/home/olpc/.ssh/authorized_keysfile will not exist on most XOs; you may have to create it.)
- Run the
ifconfigcommand (or use the Analyze Activity) to get the IP address of your XO.
- Add this IP address to a new line in the
/etc/dsh/machines.listfile on your supervisor machine, with the text
olpc@before it (you may need root on the supervisor machine to edit this file).
- You should now have an
/etc/dsh/machines.listfile on your supervisor machine that looks something like this:
firstname.lastname@example.org email@example.com firstname.lastname@example.org
This concludes the dsh setup instructions for XO testing.
On your supervisor machine, run the following command in a terminal:
dsh -Mac <command you want to run>
- The -M option prepends the IP address of the XO before the terminal output it sends.
- The -a option runs it on all the machines in your
- The -c option runs the command concurrently on all machines. If some machines are unreachable (have disconnected from the network etc.), dsh will give output for the XOs it is able to talk to and then continue to attempt to connect to the remaining machines. (For this reason, you may want to terminate the command after several minutes if it is still running.)
For example, to run the
mchua@tumtum-tree:~$ dsh -Ma ps email@example.com: PID TTY TIME CMD firstname.lastname@example.org: 1166 ? 00:00:00 startx email@example.com: 1185 ? 00:00:00 xinit firstname.lastname@example.org: 1211 ? 00:00:02 ck-xinit-sessio email@example.com: 1240 ? 00:00:40 python firstname.lastname@example.org: 1244 ? 00:00:00 dbus-launch <...more entries from 18.104.22.168 go here> email@example.com: PID TTY TIME CMD firstname.lastname@example.org: 1549 ? 00:00:00 startx email@example.com: 1566 ? 00:00:00 xinit firstname.lastname@example.org: 1577 ? 00:01:31 python email@example.com: 1585 ? 00:00:16 dbus-daemon <...more entries from 22.214.171.124 go here>
Read the dsh manpage (
man dsh) for further options.
Using an XS as the supervisor machine
Using dsh, it is possible to use an XS as a supervisor machine to control/monitor all the XOs that are connected to it.
This also provides a level of security, as by default an XO connected to an XS is only accessible by machines on that subnet, so only machines on the XS ssid with the correct private key will be able to control those XOs via dsh. (Machines outside the subnet will not be able to remotely access those XOs at all.) Another suggestion for even more security is to use a weekly cron job to create a new key pair on the XS and have the XOs run a similar cronjob to pull that new publickey.
Since it is impossible to predict the IP addresses of specific XOs connected to an XS, you will want to include all possible addresses on the subnet in your
/etc/dsh/machines.list file. Since XS subnets use a 23 bit mask, there are 512 possible addresses: 172.18.0.X and 172.18.1.Y, where X and Y are numbers between 1 and 254 inclusive.
/etc/dsh/machines.list file will look something like this:
firstname.lastname@example.org email@example.com firstname.lastname@example.org ... email@example.com firstname.lastname@example.org email@example.com ... firstname.lastname@example.org email@example.com firstname.lastname@example.org ... email@example.com firstname.lastname@example.org email@example.com
You can then run commands via dsh on the XS as in the normal usage instructions, above.
- It would be great if someone could test/develop/write instructions on how to use dsh with supervisor machines running Mac OS X and/or Windows.
- I did try Dsh, but didn't see the point of another custom install, all its features are already doable from a command line out the box. There's a range of simple examples that work on OSX, XO and standard linux distros. I see the main challenge as not remote access automation, but the actual gathering and logging of useful data in an accessible way (some examples already on above page). --Garycmartin 15:29, 14 November 2008 (UTC)