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″);

There are a number of documents out there that show how to create a Solaris zone (container) with resource memory capping. I’ll only show that quickly here, what this goes into more is how to change the resources on the fly without rebooting the zone.

First you have to have created a zone with memory capping enabled. This would be done during the zonecfg setup:

zonecfg:my-zone> add capped-memory
zonecfg:zone:capped-memory> set physical=50m
zonecfg:zone:capped-memory> set swap=100m
zonecfg:zone:capped-memory> set locked=30m
zonecfg:zone:capped-memory> end

Once you zone is configured installed and running, you can view the resources of a zone:

# /bin/prctl -n zone.max-swap `pgrep -z <zone> init`

process: 999: /sbin/init
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
zone.max-swap
        privileged      100.0MB      -   deny                                -
        system          16.0EB     max   deny                                -

# /bin/prctl -n zone.max-locked-memory `pgrep -z <zone> init`

process: 999: /sbin/init
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
zone.max-locked-memory
        privileged      30.0MB      -   deny                                 -
        system          16.0EB    max   deny                                 -

# rcapstat -z 1 1

id zone            nproc    vm   rss   cap    at avgat    pg avgpg
2 <zone>            -      48M   36M   50M    0K    0K    0K    0K

To change the max-swap resource do the following:

# prctl -n zone.max-swap -r -v 200M `pgrep -z  <zone> init`

To change the max-locked-memory resource do the following:

# prctl -n zone.max-locked-memory -r -v 100M `pgrep -z  <zone> init`

Changing the physical memory capping is a little different, you’ll need to use the rcapadm command:

# rcapadm -z <zone> -m 100M

Then to view all the resources again, you should see the changes:

# /bin/prctl -n zone.max-swap `pgrep -z <zone> init`

process: 999: /sbin/init
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
zone.max-swap
       privileged      200.0MB      -   deny                                 -
       system          16.0EB     max   deny                                 -

# /bin/prctl -n zone.max-locked-memory `pgrep -z <zone> init`

process: 999: /sbin/init
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
zone.max-locked-memory
        privileged      100.0MB     -   deny                                 -
        system          16.0EB    max   deny                                 -

# rcapstat -z 1 1

id zone            nproc    vm   rss   cap    at avgat    pg avgpg
2 <zone>            -      48M   36M   100M   0K    0K    0K    0K

That’s it. To make the changes permanent, you’ll need to go into zonecfg and adjust the resources that way.

# zonecfg -z <zone>

zonecfg:my-zone> select capped-memory
zonecfg:zone:capped-memory> set physical=100m
zonecfg:zone:capped-memory> set swap=200m
zonecfg:zone:capped-memory> set locked=100m
zonecfg:zone:capped-memory> end
zonecfg:zone:> commit

This will save the zone configuration file so the next time the zone boots the memory limit will be set, otherwise the changes are only temporary.