ClusterSSH on OSX

Apple

If you aren’t familiar with ClusterSSH, here’s the official tag line from SourceForge:

“ClusterSSH controls a number of xterm windows via a single graphical console window to allow commands to be interactively run on multiple servers over an ssh connection.”

This is extremely handy if you’re editing files, running commands, or tailing logs on multiple servers. Once you get used to use using it you’ll feel the pain of losing it once Apple comes out with another update.

And if you’re a regular user of ClusterSSH and OSX you might have noticed that Leopard (10.5) changes how X operates. The old method was to set the DISPLAY variable to localhost:0 (done automatically), start X11 from the Utilities folder, then run the x command from the xterm window that gets started. The new method automatically sets the DISPLAY variable to something like /tmp/launch-JQhO33/:0 and removes the need to start X11 manually.

ClusterSSH doesn’t recognize /tmp/launch-JQhO33/:0 as a valid display and fails. Here are a couple workarounds.

For pre-10.5.4 the following works:

  • Save this file in /usr/local/bin/
  • Make sure you aren’t setting the DISPLAY variable in your profile
  • Change /usr/local/bin/cssh in the cs file to wherever you have ClusterSSH installed

Step-by-step here’s what’s going on:

xterm -e logout&

The cs wrapper starts an xterm window and executes the “logout” command. This causes X11 to start. DO NOT MANUALLY START X11.

export DISPLAY=localhost:0

The DISPLAY variable is set to localhost:0 for ClusterSSH.

/usr/local/bin/cssh $* &

Executes ClusterSSH with the arguments passed to cs and backgrounds it to free up the terminal (for convenience only).

osascript << END
tell application “X11″
activate
end tell
END

Finally it calls on AppleScript to bring X11 to the front (again, for convenience only).

I’ve found that using this method sometimes fails and requires a reboot before it will work again. Also keep an eye out for runaway xterm processes and kill them.

For 10.5.5 and later:

  • sudo vi /etc/sshd_config and change X11Forwarding to yes
  • Restart sshd (either by rebooting or the command “SystemStarter -v restart SSH”)
  • ssh -Y localhost
  • Use ClusterSSH as normal

This method forwards X over ssh and ssh sets the DISPLAY variable to a value ClusterSSH can handle. To verify this:

$ echo $DISPLAY
localhost:10.0

Note: This value may vary but should always start with “localhost.”

If you want to get really fancy, set up keys so ssh won’t prompt for a password.

I hope this helps. I spent way too much time fighting with it before I came across a solution. I admit it’s not the best, but it works.

Update:

I’ve come across a better solution. Since X11 is looking for a valid display, change line 1716 of cssh to the following:

$xdisplay = X11::Protocol->new(“unix:0″);

Also replace the cs wrapper file with the new one. You’ll see some errors, but it’ll work and is much cleaner than the previous solution.

Update 2:

Version 3.26 of ClusterSSH requires changing line 1994 of cssh to:

$xdisplay = X11::Protocol->new(“unix:0″);

1 Comment »

on October 28th 2008 in Apple

One Response to “ClusterSSH on OSX”

  1. Gavin Brock responded on 07 Apr 2009 at 11:02 am #

    I recently created csshX which might be an interesting alternative to cssh for OS-X: http://code.google.com/p/csshx/

    .. Gavin

Trackback URI | Comments RSS

Leave a Reply