From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 29-JAN-1991 06:00:34.78 To: MRGATE::"ARISIA::EVERHART" CC: Subj: VMS Server and SUN Client Received: by crdgw1.ge.com (5.57/GE 1.80) id AA04724; Tue, 29 Jan 91 05:51:04 EST Received: From SECS.UCSC.EDU by CRVAX.SRI.COM with TCP; Mon, 28 JAN 91 18:55:46 PST Date: Mon, 28 Jan 1991 15:44:07 PST From: wipke@SECS.UCSC.EDU (W. Todd Wipke) To: info-vax@sri.com Message-Id: <0094363f.66e99240.7167@SECS.UCSC.EDU> Subject: VMS Server and SUN Client SUMMARY FOR NETWORK ORIGINAL QUERY: >I am attempting via a VAXstation 3100 running VMS DECwindows >server to have a SUN client (program=ico) display window on the >VS 3100. I have setenv DISPLAY vaxnodename:0 and xhost >+vaxnodename on the SUN and on the vax session manager customized >security for CMU sunnode for user *, and for good measure also >TCPIP sunnode *. This should authorize the sunnode to put a >window on the vax as far as I know. I have no problem with other >vms vaxen putting windows up on this VS. When on the SUN I give >the command "ico -display vaxnode:0 the response is "access >denied by server". It clearly sounds like the security access >permission by the vax is not working. As further evidence, if I >run a small program on the vax that calls the X function, >XDisableAccessControl(display), and then run ico on the SUN, it >displays as it should on the Vax! > >Our transport is CMU tcpip, which works fine between vaxen and >with vax client on sun server. It is only sun client - vax >server that is causing the problem. Knowing DEC's passion for >security, it is hard to believe that they intend for one to have >to disable access control to enable putting up a window. The SUN >has X11R4 installed, DECwindows is X11R3 (vms5.3-1). > >Is there a site that has successfully had SUN clients display on >a VMS vax server? What is the secret? What am I doing >incorrectly? RESPONSES: ---------------------------------------------------------------------------- I usually specify hostname user * so that *all* transports work... example: alpha.sunquest.com gavron * vesta.sunquest.com gavron * vesta.sunquest.com system * Ehud | Ehud Gavron, Systems analyst | gavron@vesta.sunquest.com (Internet) | ----------------------------------------------------------------------------- X11R4 vs R3 makes no difference (security-wise; fonts might be another issue). We use MultiNet rather than CMU, and the username wildcard has to be "?" instead of "*" in the session manager's security database. Another possibility, and probably a more likely one, is that you need to specify the fully qualified hostname (ie, foobar.site.domain instead if just foobar) in the security database. A third possibility is case sensitivity in the host name, but I think that problem would be more likely for vms client -> UN*X server. Pat Rankin, rankin@eql.caltech.edu ----------------------------------------------------------------------------- Sounds like a name resolution problem to me. Are you running a resolver on both machines? Are they both listed in the named database of your server at the correct address? If both of these are true, enable resolver logging on the vax or put a monitor on your network and watch the packet exchange. Try registering the machines using the FULLY QUALIFIED domain name instead of just the cname (there is a cname record in the database for your hosts, right?) Without actually watching the exchange, this is mostly speculation. I have seen similar problems dozens of times though, and it always turns out to be security on the server side (vax in your case, the server is the one displaying the window) trying to do a reverse name lookup on the ip address of the requesting host. Oh, that is another thing! Does your named host service reverse (PTR) lookups? From: lotto%lamia@das.harvard.edu (Jerry Lotto) ----------------------------------------------------------------------------- Check the server log file (SYS$MANAGER:DECW$SERVER_0_ERROR.LOG). It'll tell you the the connection data that was supplied and why it was rejected. You might have the case wrong, or something similar. [THIS WAS MOST HELPFUL] -Rick From: murphy@burfle.dco.dec.com (Rick Murphy) ----------------------------------------------------------------------------- The proper authorization to give to the session manager is a username of "?", not "*". Also, you might need the FQDN. And, finally, there must be host table or DNS entries to allow the VAXstation to translate the IP address into a FQDN. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 ----------------------------------------------------------------------------- > CMU sunnode *. ^^^^^^^ Here is your problem, the vax session manager cant use the namresolver you have to put the internet number there! And you can't put a user name there either, you have to use an * /Mats Mats Akerberg (mats@efd.lth.se) on INTERNET ----------------------------------------------------------------------------- The problem you are running into (I think) is case sensitivity between Unix and VMS. Notice that when you enable access control on the 3100 the node name you enter is capitalized. On the Unix side this will matter unless your node name is in caps. The only way I've gotten around the problem is to use an `*' for the node name on the VMS side. By the way, using xhost +vaxnodename on the Sun doesn't do anything but give the 3100 access to the X server on the Sun. Hope this helps. John Phelps, jbp@ngss1.jhuapl.edu Johns Hopkins University Applied Physics Laboratory, Laurel, Md. ----------------------------------------------------------------------------- I'm guessing your VAX is not converting the incoming IP address to a name. (before checking security). Enter the IP address (192.x.y.z or whatever) in your customize security window instead of the name and see if that works. Use transport CMU. From: "Craig R. Watkins" ----------------------------------------------------------------------------- From the description, it is definately a confusion problem on the VAX with regards to security. If calling DisableAccessControl solves the problem, it's definately security. What I find usually works is to do the following: 1) Telnet/Rlogin from the Sun to the VAX. 2) Issue whatever command (in MultiNet a show process or finger will do it) to figure out what the VAX thinks the nodename is. 3) Enter that name exactly in the VMS security database. Depending on the transport module capabilities, domain name expansion may not work correctly (e.g. XYZ may not equal XYZ.UCSC.EDU in DECwindows eyes). # The SUN has X11R4 installed, DECwindows is X11R3 (vms5.3-1). TGV is running in this configuration, although we are at VMS 5.4-1A. It is working for us... subject to the usual silly font problems. John 'Fast-Eddie' McMahon : MCMAHON@TGV.COM ----------------------------------------------------------------------------- CONCLUSIONS: One should look in the SYS$MANAGER:DECW$SERVER_0_ERROR.LOG: 28-JAN-1991 10:07:22.9 Invalid access from transport: CMU node: 128.114.141.62 user: * it shows the numeric address is being sent from the SUN and when one enables CMU 128.114.141.62 * on the Vaxstation, access is granted. However, I noted in observing the log that occassionally one does see the symbolic address get passed to the server: 28-JAN-1991 10:05:09.0 Invalid access from transport: CMU node: HELIUM.UCSC.EDU user: * This occasional symbolic appearance may be related to CMU and NAMSRV lookup, or lookup on the SUN. It seems to try symbolic once and then thereafter the numeric, and the next day again tries the symbolic once. Thus to be sure it always works, put BOTH symbolic and numeric address entries in workstation security list. The complete address is needed. PROCEDURE TO RUN ICO WITH SUN CLIENT ON VAX VMS SERVER 1. customize Vax session manager security as above and APPLY it 2. telnet to sunnode 3. cd /usr/bin/X11 4. ico -display vaxnode:0 where vaxnode is symbolic or numeric address or setenv DISPLAY vaxnode:0 ico the ico demonstration program runs on SUN and displays on VAXstation. Many thanks to those that responded, hope this helps those also interested. ======================================================================= W. Todd Wipke wipke@secs.ucsc.edu Molecular Engineering Laboratory wipke@ucscd.ucsc.edu Thimann Laboratories wipke@ucscd.bitnet University of California BBS 408 429-8019 Santa Cruz, CA 95064 FAX 408 459-4716 ============= TCM-Online@TCM.UCSC.EDU SUBSCRIBE ===================