Xref: utzoo comp.graphics:17998 comp.sys.sgi:10078 comp.graphics.visualization:568
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!sgi!tarolli@westcoast.esd.sgi.com
From: tarolli@westcoast.esd.sgi.com (Gary Tarolli)
Newsgroups: comp.graphics,comp.sys.sgi,comp.graphics.visualization
Subject: Re: Distributed GL graphics via high speed networks...
Summary: userid problem
Message-ID: <103732@sgi.sgi.com>
Date: 14 May 91 14:51:54 GMT
References: <1991May13.191050.21842@eagle.lerc.nasa.gov>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 46

In article <1991May13.191050.21842@eagle.lerc.nasa.gov>, tttron@escher.lerc.nasa.gov (William Krauss) writes:
> I recently discovered a new "feature" of the SGI Distributed Graphics
> Library (DGL) daemon running under Irix 3.3.2 (resides on the server Iris). 
> It seems as though it doesn't recognize the userid from the CLIENT machine 
> when the userid's are DIFFERENT (such as CALVIN on a client Cray and HOBBES
> on the server Iris).  
> 
> The userid is typically specified with the environment variable REMOTEUSER on 
> the client side (e.g. setenv REMOTEUSER CALVIN).  The only way I remedied this 
> problem was to use the older version of the "dgld" (3.3.1).  By the way, 
> .rhosts, etc. are all set up correctly (all works fine with the OLD daemon). 
> 
> Any comments from the SGI think-tankers?
> 

The dgld daemon calls ruserok(3N) to validate the login request.  The userid
on the server side should not matter, as its out of the picture (unless you
run the dgld server manually).  Ruserok will allow the login if the
client userid can login without a password (see the man page for the gory
details).

Now, as for your problem, even though your .rhosts etc. files did not change,
other things may have.  For example, are you now running domains?  If so,
then perhaps the 3.3.1 server was linked with a different version of ruserok()
that treated domains differently.  If you are running with domains, try
placing the full domain name in your .rhosts file: eg. foo.esd.sgi.com.

To double check things, try logging into the client as CALVIN (su doesn't
always do the trick) and then "rsh server-machine data".  If this works,
then .rhosts is set up correctly.  The only other remaining user-error
problem could be that the DGL is not using the exact userid or hostname
that you think it is.  To verify this, do

setenv DGLDEBUG 1

on the client side, rerun the program, and read the info messages - they
display the full userid and hostnames being used.  If all this checks out
then it may be a bug in the dgl server.  However, my guess is that the
older 3.3.1 dgl server was more leanient in its networked permissions,
and that a simple "magical" change to some file like .rhosts may correct
the problem.



--------------------
	Gary Tarolli