home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / sgi / 13401 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.6 KB

  1. Path: sparky!uunet!sun-barr!olivea!sgigate!odin!fido!mutt.asd.sgi.com!shui
  2. From: shui@mutt.asd.sgi.com (Simon Hui)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: DGL refuses connection from SPARCStation
  5. Keywords: DGL Sun
  6. Message-ID: <pk5pcrk@fido.asd.sgi.com>
  7. Date: 9 Sep 92 02:56:24 GMT
  8. References: <myers.715552750@haydn>
  9. Sender: news@fido.asd.sgi.com (Usenet News Admin)
  10. Organization: Silicon Graphics, Inc.
  11. Lines: 51
  12.  
  13. >We recently ran into a perplexing problem after I upgraded our
  14. >4D/30 to 4.0.1.
  15. >
  16. >A user on a SPARCStation 2 had previously been able to do a remote
  17. >shell to the SGI to run some graphics programs. Now his TCP connection
  18. >is refused.  The error can be replicated by trying to a "rsh blanktime 0"
  19. >from the command line. The most interesting part of this problem is that
  20. >the command CAN be executed from another SGI machine. It seems to be a
  21. >Sun/SGI problem. (Yes, both the Sun and the second SGI are in the .rhosts
  22. >file). Rsh's to do such things as execute the date command work fine.
  23. >
  24. >From Sun(bette) to SGI(kate):
  25. >
  26. >  %rsh kate blanktime 0
  27. >  (long pause)
  28. >  %dgl error (TCP connect): Connection refused
  29. >  %dgl error (default init): default dglopen(brackett@bette,4) returned -127 
  30. >
  31. >From SGI(hermes)to SGI(kate):
  32. >
  33. >   %rsh kate blanktime 0
  34. >   %
  35.  
  36. My guess is that the SGI is trying to display a GL program (blanktime) on a non-SGI
  37. machine (the Sun), causing the DGL error.  (In this case, blanktime doesn't really
  38. display anything, but it uses GL to affect a screen.  The same idea applies to GL
  39. programs that actually do display graphics.)  This would happen if, in your remote shell on kate, either of the environment variables DISPLAY or REMOTEHOST pointed at
  40. bette rather than kate.  Do this to make sure that neither of them points to bette:
  41.  
  42.     %rsh kate
  43.     kate% printenv DISPLAY
  44.     kate% printenv REMOTEHOST
  45.  
  46. I'd guess that DISPLAY is not being set to anything, and that REMOTEHOST points to
  47. bette.  When DISPLAY is not set, the GL sees if REMOTEHOST is set and uses that as the
  48. host to display to.  You can put a hack such as this in your .login on kate to make
  49. sure DISPLAY points to kate when you are logging in from bette:
  50.     
  51.     if ($?DISPLAY == 0 && $REMOTEHOST == "bette") then
  52.             setenv DISPLAY ":0"
  53.     endif
  54.  
  55. There are probably more creative and cleaner solutions to this problem, but this is 
  56. all I've come up with right now.
  57.  
  58. You ran into this problem while upgrading to 4.0.1 because, as of 4.0, the GL gained
  59. the ability to display on remote machines.  Before, the GL always displayed to the
  60. local machine, so you never had a problem with blanktime trying to display on the Sun.
  61.  
  62. Simon Hui
  63. -- 
  64.