[LONG] DECWindows and XDM
supervinx
Hope this is the right place to post this question.
I own a VAXStation 4000/90, running OpenVMS 7.2, TCP/IP 053 and
DECWindows 072.
I'm almost a newbie with OpenVMS.
Since my kbd LK401 isn't working (the mouse it's OK, but can't login only
with it :P ), I tried to connect through XDM from a Linux box (Ubuntu
8.04 Hardy).
Here are the steps I made
VAX=192.168.1.170
UbuntuPIV=192.168.1.10
VAX
1) Enabled xdm with tcpip$config
2) Created XACCESS.TXT from the template, granting access to everyone.
Commented the other unused files in XDM_config.conf (servers.txt keys.txt)
3) "tcpip show service xdm" shows correctly it with 177/UDP
LINUX
4) xhost + 192.168.1.170
5) Xnest :1 -query 192.168.1.170 [hangs there at the cross-shaped mouse]
VAX
SYS$SPECIFIC:[TCPIP$XDM.WORK]UBUNTUIV_0.ERR
I/O Error from XOpenDesktop (similar).
Every other log shows everything it's OK.
Tried this method
6) telnet to VAX
7) set disp/create/node=192.168.1.10/transport=tcpip
8) mc decw$clock
... [long time]
Can't open desktop
----
So, DECWindows can't open windows on my Linux box, and no DECW$SESSION
either.
Can't understand if the problem lies on VAX's side on Linux's side.
Steven Schweda
> I own a VAXStation 4000/90, running OpenVMS 7.2, TCP/IP 053 and
> DECWindows 072.
tcpip show version
> 6) telnet to VAX
> 7) set disp/create/node=192.168.1.10/transport=tcpip
> 8) mc decw$clock
> ... [long time]
> Can't open desktop
search sys$manager:decw*.com transports
telnet /port = 6000 192.168.1.10
Hans Vlems
Possibly the security settings on the linux systems won't allow the
display to open.
I can't remember what file had to be modified, /etc/securettys
perhaps?
Hans
supervinx
I'm quite sure, now, the problems lie on Linux's side.
I tried to set/export/open applications from other machines running other
*nix OSes, getting the same response. :P
Not so important, I was curious to see DECWindows, since the KBD left
me :)
supervinx
> tcpip show version
>
Compaq TCP/IP Services for OpenVMS VAX Version V5.3
on a VAXstation 4000-90 running OpenVMS V7.2
>
> search sys$manager:decw*.com transports
>
******************************
SYS$COMMON:[SYSMGR]DECW$STARTSERVER.COM;1
$ decw$server_transports == "decnet,local''tcpip'"
$ decw$define_server_term decw$server_transports 'decw$server_transports'
> telnet /port = 6000 192.168.1.10
%TELNET-I-TRYING, Trying ... 192.168.1.10
%TELNET-I-SESSION, Session 01, host 192.168.1.10, port 6000
-TELNET-I-ESCAPE, Escape character is ^]
Stops here
Why this test from VAX to Linux box ?
My tries are in the opposite directions, from Linux box do DECWindow
supervinx
Issuing
set disp/create/transport=local/super (assuming node 0)
mc decw$clock gives me the clock windows on top of the greeter on the
VAXStation monitor.
Issuing
set disp/create/transport=tcpip/super (o /exec) gives me
X Toolkit Error: Can't Open display
%DWT-F-NOMSG, Message number 03AB8204
on the same local node.
May be there's something wrong with the tcpip transport (or DECnet)
Must review xdm security settings ...
Steven Schweda
> Why this test from VAX to Linux box ?
> My tries are in the opposite directions, from Linux box do
> DECWindow
If the keyboard and display are local to the GNU/Linux
system, then the GNU/Linux system is the X server, and the VMS
system is the X client. It may sound backward, but the system
with the display hardware is serving it to the other system.
> $ decw$server_transports == "decnet,local''tcpip'"
That was more complicated than I expected. On my Alpha
V8.3 system, it's more like:
$ decw$server_transports == "decnet,local,tcpip"
On yours, it's not clear what the DCL symbol "tcpip" is set
to. You could look through that .COM file and try to figure
out what "tcpip" is, or you could add a debug print statement,
like, say:
$ write sys$output "decw$server_transports = ''decw
$server_transports'"
or you could just replace that "''tcpip'" with a plain
"tcpip". Then restart the server. I normally use my (newer,
non-VAX) VMS system as the X server, so my knowledge and/or
memory in this neighborhood may be weak.
> %TELNET-I-TRYING, Trying ... 192.168.1.10
> %TELNET-I-SESSION, Session 01, host 192.168.1.10, port 6000
> -TELNET-I-ESCAPE, Escape character is ^]
>
> Stops here
It looks as if there's no firewall anywhere blocking this
stuff.
> %DWT-F-NOMSG, Message number 03AB8204
Around here, I get more:
ALP $ exit %x03AB8204
%DWT-F-DWTABORT, xtoolkit fatal error
but that doesn't really tell us very much.
> May be there's something wrong with the tcpip transport (or
> DECnet)
Telnet works, so I don't see an IP problem, and you're not
using DECnet ("/transport=tcpip"). The question may be
whether DECwindows is really able to use TCP/IP (and that
depends on what that "tcpip" symbol was).
JF Mezei
The VAX version is antique and doesn't support MIT Cookies for instance.
There are ways to make it work by hardcoding the displays in it. But you
must first get xwindow working.
On the vax:
In your systartup_vms.com before you start the TCPIP Services.
$define/system DECW$INSTALL_TCPIP "TRUE"
This causes the software to install the proper drivers and instruct the
tcpip software to listen to port 6000.
before you start decwrindows:
$define/system DECW$IGNORE_WORKSTATION TRUE
This causes decwidnows to not start the "x terminal" software on that
node but get everything ready to allow applications to be targetted at x
remote x terminals.
Once your system has booted, you should be able to
set display/create/transport=tcpip/node=xxxxxxxx
This command will succeed if the drivers are installed. it does not
check whether node xxxxxx will accept the connection.
mc decw$clock will attempt to create a clock on the remote display. At
this point, if the set disoplaty worked but mc decw$clock fails, it is
likely the remote node which has refused the connection.
On the remote node, you may need to use "xhost +[ip address of vax]"
(aka xhost +10.0.0.20 )
You can also try by node name.
man xhost for more information. on OS-X, you can make this a default by
populating /etc/X0.hosts (one line per host you wish to allow to
display x window on this node).
Once you have this working, you can tackle the actual session stuff.
On your vax, you can:
set display/create/exec/transport=TCPIP/node=xxxxxxx
then $DEFINE/SYSTEM DECW$DISPLAY F$TRNLNM("DECW$DISPLAY")
The above 2 create a persistent WSAx: device, and a persistent
DECW$DISPLAY that points to that device. (aka: you can re-use that
devide that always points to that same node (your workstation).
You can then $RUN/proc=Mysession SYS$SYSTEM:DECW$SESSION.EXE
This create a detached process that runs the session manager from whcih
you can start decwidnows applications. You can then logout from your
telnet session since the decw$session is a detached process.
If you want the full "login" experience, use DECW$STARTLOGIN.EXE instead
of the SESSION one. Warning: once you login, the VMS host will try to
take control of the root window on your linux box because it expects the
targe to be a dump x terminal.
the DECW$SESSION does not try to manage the root window. (if I remember
correctly).
Henry Crun
What works for me
(VMS V8.3 + Ubuntu linux 10.04)
On Linux: xhost +
telnet to VMS:, and do:
$ set display/create/node=<linux IP address>/transport=TCPIP
$ create/terminal/detach
N.B. Remember to set
$ decw$server_transports == "decnet,local,tcpip"
in SYS$COMMON:[SYSMGR]DECW$STARTSERVER.COM
--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/php/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
Ulrich Bellgardt
> LINUX
> 4) xhost + 192.168.1.170
> 5) Xnest :1 -query 192.168.1.170 [hangs there at the cross-shaped mouse]
>
> VAX
> SYS$SPECIFIC:[TCPIP$XDM.WORK]UBUNTUIV_0.ERR
> I/O Error from XOpenDesktop (similar).
> Every other log shows everything it's OK.
>
> Tried this method
>
> 6) telnet to VAX
> 7) set disp/create/node=192.168.1.10/transport=tcpip
> 8) mc decw$clock
> ... [long time]
> Can't open desktop
>
The X server on the Linux box must be setup to accept TCP connections.
On my Kubuntu, this is not the default, so on Ubuntu it might be
similar. You can verify this with
$ps ax |grep X
then you see "/usr/bin/X" along with its command line arguments. If one
of the arguments listed there is "-nolisten TCP", this is the reason
for the situation as described. Then you just need to spot the file
that contains the X command line arguments, and edit it accordingly. In
my Kubuntu system it is /etc/kde4/kdm/kdmrc
-Uli
supervinx
>>
> The X server on the Linux box must be setup to accept TCP connections.
>
I already setup X to accept connection: I can remotely login to the Linux
machine from other Linux or *nix machines
supervinx
Since set display works, and everything works with /transport=local,
xwindow is up and running locally to the VAX, I can Xnest from other
machine to the Linux box, I must investigate further the tcpip transport
on the VAX. I'll let you know ... thanks ! :)
smithfarm
My guess is that Hans is right. How to open up the Linux box for remote
X connections differs from distro to distro. Which distro are you using?
I know how to do it for Ubuntu 10.04 (and it's *not* obvious).
> Not so important, I was curious to see DECWindows, since the KBD left
> me :)
Not much there to see, really. On a VAX, about the only thing DEC
windows is useful for is running a DECterm for the VT terminal emulation
it provides.
When it comes to the user interface, there are two issues that have to
be dealt with: VT terminal emulation and keyboard. The most
straightforward way to resolve these issues is to either (a) get DEC
windows running on your VAXstation *with* an LK keyboard attached or (b)
attach a real VT terminal (with LK keyboard) to the VAXstation.
This is not to say there are not other options. You can reprogram the PC
keyboard on the linux box, for example, or convert the RJ11 connector on
the LK keyboard to a DB-9 connector and connect that to the linux box as
a second keyboard. These options, however, require more effort.
To make matters worse, when it comes to reprogramming the PC keyboard
there is no consensus on which keys/key combinations should be used to
emulate the missing LK keys, so each person essentially rolls his own
mapping. This is fine for experienced hackers but not so good for newbies.
Nathan
smithfarm
>
> (aka xhost +10.0.0.20 )
> You can also try by node name.
Note that, at least with Ubuntu as the remote node, this is not
sufficient because remote X connections are completely disabled by
default (for security reasons - not everyone is behind a NAT router) and
can only be enabled by editing a Ubuntu-specific configuration file
which differs from one Ubuntu version to another.
supervinx
%%%%%%%%%%% OPCOM 2-JAN-2011 23:42:34.66 %%%%%%%%%%%
Message from user INTERnet on VAX400
INTERnet ACP NOLISTEN Process creation success: Service - XDM
Why XDM is started with ACP NOLISTEN ???
JF Mezei
This is normal. I think it is TCPIP services which gets each incoming
call and starts XDM and passes it the call. (as oppopsed to XDM
listening to the port itself).
supervinx
VAX side:
Added DEFINE /SYSTEM "TRUE" in SYSTARTUP_VMS.COM
Now the tcpip symbol is equal to ,tcpip
There was a check for the DECW$INSTALL_TCPIP symbol in
SYS$COMMON:[SYSMGR]DECW$STARTSERVER.COM
Linux side:
Started Xnest with the -ac parameter.
xhost +192.168.1.170 wasn't enough. I should invsetigate further.
http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-Login.png
http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-Desktop01.png
http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-Desktop02.png
http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-Desktop03.png
http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-Desktop04.png
http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-DECUSERVE.png
Thank you all for the help ! :)
smithfarm
> Added DEFINE /SYSTEM "TRUE" in SYSTARTUP_VMS.COM
Did you mean to write DEFINE /SYSTEM DECW$INSTALL_TCPIP "TRUE"?
> Linux side:
> Started Xnest with the -ac parameter.
> xhost +192.168.1.170 wasn't enough. I should invsetigate further.
>
> http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-Login.png
> http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-Desktop01.png
> http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-Desktop02.png
> http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-Desktop03.png
> http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-Desktop04.png
> http://www.supervinx.com/Retrocomputer/DEC/VAX/VAXStation4000-90/DW/VAX-DECUSERVE.png
Nice. What Linux distribution/version are you using? Using Ubuntu 10.04
I tried the same thing (using Xnest). I see the XDM login screen in the
Xnest window and can log in, but after I log in, DECwindows takes over
:0, which is the Ubuntu desktop, and stops using the Xnest window, which
is :1. In other words, everything appears outside the Xnest window. It
even changes my Ubuntu desktop background color to DECwindows blue.
Then, when I exit from the DECwindows Session Manager, it closes my
entire Ubuntu desktop! I haven't looked into this further, but it would
appear that at some point as DECwindows is starting up, it defaults to
:0 instead of taking :1 from XDM.
I already wrote about this here, but nobody else seems to be seeing this
behavior.
Nathan
supervinx
Xnest :1 -ac -query VAX_IP_ADDRESS