[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