[Bug 384] OpenSSH should store an SSH_SERVER variable for cluster hosts
bugzilla-daemon at mindrot.org
bugzilla-daemon at mindrot.org
Wed Aug 21 09:19:10 EST 2002
http://bugzilla.mindrot.org/show_bug.cgi?id=384
------- Additional Comments From thomas+openssh at stromberg.org 2002-08-21 09:19 -------
Yes, this patch may seem a bit unusual until you take cluster's into account.This extra
environment, SSH_SERVER is used by /etc/profile. Let me give you a real life example:
Sun 4800 Cluster Node "dirac" has several versions of oracle application server running
on it. Each instance has it's own IP, so it can fail over to other nodes as needed. For
instance, if the load on "dirac" is getting too high, the development instance moves to
"curie". Here are some of the instances on "dirac" in this test case:
OADEV 192.168.100.41
OAPRD 192.168.100.42
OATST 192.168.100.43
TADEV 192.168.100.44
BOPRD 192.168.100.45
When a user SSH's to the hostname "OATST", he lands onto "dirac", because that's the
node where the instance currently is. The /etc/profile script needs to know what IP they
ssh'd into, so it knows how to handle the case. It then processes SSH_SERVER:
if [ "$SSH_SERVER" ]; then
ip=`echo $SSH_SERVER | cut -d" " -f1`
target=$ip
else
and then runs through a case statement (if $target matches 192.168.100.43, we want
OATST's environment) to setup the environment correctly for the OATST instance... to
make it less confusing for the end user, you make the prompt say the instance name
OATST instead of the node name, dirac.
When the user then ssh's to OAPRD in another PuTTY window, they end up on dirac
again, but they don't know that. The environment magically becomes OAPRD, and so
does their prompt.
We've got about 30 cluster instances, of various products, on four Sun 4800 nodes. This
small patch was the only clean way I could figure to discover the IP of the connecting
host. I had thought about a complex loop of lsof's, but it would incur a significant login
delay (at least 15 seconds), and would hang should any nfs resources be unavailable.
I just figured since there is an SSH_CLIENT variable, there should be a matching
SSH_SERVER variable, especially for us folks relying on OpenSSH in HA environments.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the openssh-unix-dev
mailing list