Table of contents

Overview

This document is intended to provide you with advice on how to configure the use of X-Windows between an emulator instance (either Tru64 or OpenVMS) and it’s Windows or Linux host.

Prerequisites

• Familiarity with X11
• Familiarity with the guest operating system (Tru64 or OpenVMS)
• Familiarity with the CHARON-AXP product

Conditions and Limitations

• The X-server configurations described in this document were tested using the VcXsrv X-server on Windows.
• The guest operating system versions tested were: Tru64 V4.0F/V5.1B, OpenVMS V7.1/V7.3-2

Terminology

For the purposes of this document, the following definitions apply:

Displaying Graphical Applications Over The Network

There are various ways of methods and styles when using a separate system (X11 Server System, “Host”) to display applications running on an emulator (X11 Client System, “Guest”). The first thing to decide is if the entire “desktop environment” is to be transported to the Host. The entire desktop environment means a sessions begins with a graphical login window. The user must authenticate himself using credentials associated with the Guest. After authentication, a session manager, either CDE or DECwindows/Motif is started. Transporting the entire desktop environment will be referred to henceforth as the “Desktop Environment Session” (DES).

If transporting the DES is the goal, there are three ways of doing it:

1. Initiating a desktop session from the Host using XDMCP
2. Running a command on the Guest to start a new session on the Host. This can be done from the Host remotely, using, for example, rsh
3. Configuring the Guest XDM (X Display Manager) to automatically start a session on the Host

If the DES is not to be transported to the Host, but rather only individual application windows, each application must be started on the Guest, possibly using a remote execution protocol such as rsh.

If the Host has multiple Windows screens (i.e. monitors), and you are planning to transport the DES, you must additionally decide if you want all (or some subset) of the Windows screens to appear to the Guest as one large screen, or as several screens. One large screen allows windows to span the Windows screens, and be moved anywhere within the one large logical screen. Configuring several logical screens means that applications on the Guest must explicitly be directed to screens other than the first, for example, using “<Host>:0.1” as the display target would cause the application window to be directed to the 2nd logical screen.

One LargeWindow

A DES should almost certainly be encapsulated in a single window, with or without a frame. This can be combined with XDMCP (the X11 Display Manager Control Protocol), if the Guest supports it.

SeveralWindows

Without XDMCP, each application to be run on the guest system must be started individually. This is can be done from Windows using Putty with X11 tunneling enabled, if the Guest supports SSH. If the guest is running Tru64 V4.x or OpenVMS V7.1, it will not have an ssh-daemon. You have several choices in this case:

• Use the rsh protocol to start a remote X-application. For an rsh program for Windows, see the “Links” section of the appendix.
• Use the telnet protocol to start a remote X-application
• Install my Tru64-Helpers for V4.x, which includes an SSH client and server.

Keep in mind that both rsh and telnet transmit everything, including passwords, in clear text over the network.

Security Considerations

X11 does not contain any provision for encrypting network traffic. This means you must satisfy one of the following conditions:

1. Both client and server are on a private, trusted network
2. X11 traffic flows through an encrypted tunnel, provided by SSH, for example

If you wish to use theWindows host as the X11-display for the emulator, I recommend setting up a virtual network on the Windows host using the “vmini” network driver.

You must use the “vmini” driver, because other virtual network drivers do not work with CHARON.

NOTE: be sure to disable any firewall on the virtual network devices

Host Configuration

The procedure for configuring the host depends completely on whether it is running Windows or Linux.

Linux

This part will be enhanced/described later

In principle, it should be a relatively simple matter to configure the Linux host, because X11 is currently a standard Linux component. This will change soon, though, as many Linux distributions are evaluating new windowing systems, such as Wayland (RedHat, Fedora) or Mir (Ubuntu), which may not offer X11 compatibility.

Windows (7, 2008 R2)

You will need to install an X-Server on the Windows host. There are a variety to choose from. The Free and Open Source Software (FOSS) choices include Xming, VcXsrv, and the X-Server available as a package with Cygwin. There are many commercial packages available, including Hummingbird-Exceed, Reflection-X, X-WIN32 and MKS X-Server.

FOSS X-Servers

The Cygwin, Xming, and VcXsrv servers are all based on the X-Org open-source XServer. Xming and VcXsrv in particular are very similar. Xming actually has two versions, a current version (7.5.0.77) with bug-fixes and new features, for which a donation (suggested amount: GBP 10) is required. Without making a donation, and getting a donor password, you can only download and older version (6.9.0.31) from sourceforge (http://sourceforge.net/projects/xming). VcXsrv, on the other hand, seems to be relatively current, with bug fixes and new functionality.

VcXsrv

This article will concentrate on using VcXsrv. Much will also apply to Xming, and to a certain extent, to the Cygwin server.

To install, download the Windows installer and run as “administrator”.

Configuring the Launcher

Start the VcXsrv “Xlaunch” program by clicking on Start → All Programs → VcXsrv → XLaunch.

A “Display settings” window will appear and lead you through a series of configuration screens. The first is “display settings”. There are four choices:

1. Multiple windows
2. One large window
3. Fullscreen
4. One window without titlebar

If you intend to use the XDMCP protocol, you can choose any but “Multiple windows”.

On the next screen (“start clients”), select XDMCP if you want it.

If you selected XDMCP, the next screen allows you to specify the system to which the XDMCP session should be initiated. I recommend enabling the “Terminate on server reset” option, which will cause the VcXsrv server to shutdown on logout. Otherwise,

the X-server may get into an endless loop when a session is terminated.

On the next screen (“Extra settings”), leave “Clipboard”, “Primary Selection”, and “Native opengl” selected. Do not select “Disable access control” unless you have a good reason to. In the “Additional parameters for VcXsrv” entry box, add “-from <address-of-windows-host>” if the Windows host has more than one IPaddress, otherwise VcXsrv will fail with an error message.

On the next and last screen, click on “Save configuration” and save to a permanent file somewhere thatmakes sense, such as C:\Xlaunch-Configs\<name>.xlaunch. After that you can click on “Cancel” to close the XLaunch dialog.

Set up a desktop icon by starting a “Windows Explorer” window, browsing to the VcXsrv installation directory, inmost cases “C:\Program Files\VcXsrv”, rightclicking-and-dragging the xlaunch.exe file to the desktop. Rename the icon to something that makes sense, and then right-click on it and select “Properties”. Append “-run <path-to-xlaunch-config-file>” in the “Target” Field, which already contains the path to the xlaunch command.

Using Multiple Monitors

To configureVcXsrv to use severalmonitors as one large screen, add “-multimonitors” to the command line parameters. In an XLaunch file itmust be added to “ExtraParams”.

To add it to a VcXsrv desktop icon, right-click on the icon and select “Properties”. Add “-multimonitors” to the other parameters in the “Target” field.

To configure VcXsrv to use several monitors as distinct screens, add "-screen 0 @1 -screen 1 @2" (for two monitors) to the command line parameters. You can also add the “-xinerama” parameter – it depends if the X client programs are Xineramaaware.

Configuring the Guest System

Tru64 UNIX V4.X and V5.X

Desktop Environment Session (DES) Configuration

Both V4 and V5 support XDMCP. You have two choices of how to start the DES:

• It can be initiated from the Host using XDMCP by VcXsrv
• The Guest can be configured to automatically start the DES.

The steps below apply to both scenarios above:

• Find the file pointed to by /var/dt/Xservers. It will probably be /usr/dt/config/Xservers.nc. Edit this file, and make sure the line “* Local local@console /usr/bin/X11/X :0” is commented out. This stops the emulated system from trying to start an X-Server on the local hardware.
• Add an entry for the Windows Host in /etc/hosts.
• If you want to be able to log in as “root”, add a line to the end of /etc/securettys with the value “<windows-host>:0”, where “<windows-host> is the name you added to /etc/hosts.

• Make sure there is a symbolic link from /sbin/rc3.d/S95xlogin to /sbin/init.d/xlogin. If not, create it using:

  ln -s /sbin/init.d/xlogin /sbin/rc3.d/S95xlogin

After satisfying the above requirements, you can use VcXsrv to initiate the DES via XDMCP. If you prefer to configure the Guest to start the DES, you must add a line to the “/var/dt/Xservers” file of the form:

where <hostname> is the name the you entered in /etc/hosts for the Host.
This approach may be preferable. If the XDM on Tru64 cannot start the DES, for example because the X-Server is not running on the Host, it will wait patiently until the X-Server becomes ready. When a DES is terminated, Tru64 immediately starts a new one.

Non-DES Configuration

This part will be described later

OpenVMS V7.1 and V7.3-2

Depending on the OpenVMS version, various methods and mechanisms may or may not be available.

Currently, this document contains information aboutV7.1 and V7.3-2. As new versions are tested, this document will be kept up to date. I tested V7.1 using the default UCX version 4.1 without any patches. The DECwindows patches (see the Links section of the Appendix) were installed.

The commands below are all written in UPPERCASE, in order to differentiate them better. You can enter the commands using any mix of case you like, except in quoted strings, where case is significant.

Configure TCP/IP

On V7.1, run SYS$MANAGER:UCX$CONFIG, onV7.3-2, run SYS$MANAGER:TCPIP$CONFIG.

• Core environment: configure at least one interface, routing, and time zone
• Client components: enable “REXEC and RSH”, “RLOGIN”, and possible “TELNET” and “FTP Client”. On V7.3-2 enable “SSH Client”.
• Server Components: enable RLOGIN, and on V7.3-2 SSH and XDM.

The Hosts Database (V7.1 and V7.3-2)

No matter how you intend to configure a VMS guest to use a remote X-Server, you will almost certainly want to add all relevant IP-addresses to the VMS UCX/TCPIP hosts database. This is done from the SYSTEM account by entering “UCX” on the command line on V7.1, or “TCPIP” on V7.3-2. You will then see the corresponding prompt “UCX> “ or “TCPIP> “, below represented as “PROMPT> “.

To add a host/IP-address to the database, enter the following command:

Putting the “hostname” in quotes cases it to be entered in lowercase, assuming you also use lowercase characters, which is a Good Idea. The alias will be all uppercase.

After adding a host, you can ping it from within UCX/TCPIP using the command:

V7.1 reports “...host is alive” upon success. V7.3-2 uses the standard UNIX answer syntax, and sends ICMP packets until interrupted using CTRL-C.

The Proxy Database (V7.1 and V7.3-2)

The Proxy Database is also managed from within UCX/TCPIP.

If you want to be able to execute VMS commands remotely using the “RSH” protocol, you will need to make entries to the Proxy Database. The Proxy Database allows you to associate a remote user on a remote system with a local user, and allow remote execution from that remote user.

The add an entry to the database, enter the following command:

For example, to add a proxy for user “urban” on remote host “windows-privnet” for the VMS user “SYSTEM”, enter the following command:

The quote-characters are important. Please note that VMS will convert all non-quoted characters in commands to uppercase. A proxy entry for the remote user “URBAN” will not match the remote user “urban”.

After you have create such a proxy entry, you can test it from a Linux or Windows system with the command:

which should display a directory listing of SYSTEM’s login directory.

On Windows, you will need the “rsh_vista.zip” utility (see links below).

Remote Execution Using RSH

If you want to run a command on an OpenVMS Guest, use the rsh program. On Fedora/RedHat Linux, you will probably need to install the rsh package. On Windows, you will need the “rsh_vista.zip” package (see links below). On a Windows host, assuming you have unpacked “rsh_vista.zip” into “C:\Program Files\Rsh”, you can create a shortcut to the rsh.exe program by opening a Windows Explorer window, navigating to the above directory, right-clicking and dragging “rsh.exe” to the desktop. When you release the mouse button, you will get a pop-up menu from which you should choose “Create shortcuts here”. Right-click on the new desktop icon and select properties. In the “Target” field append -l <user> target-host “<command>” after the path to the program in quotes.

The entire field should look as follows:

You should also change the value in the “Run” field from “Normal window” to “Minimized”, which avoids having the CMD-window pop up when the icon is executed.

On the VMS guest, you will probably need to write a small DCL command procedure in order to set up the remote display before starting a DECwindows program. For example, to start a DES, the following DCL procedure can be used:

This works on V7.1 and V7.3-2. If you only wish to start a single application, such as a DECterm, you can substitute “DECW$TERMINAL” for “DECW$STARTLOGIN” above.

OpenVMS V7.1

The standard UCX version on VMS V7.1 is 4.1, which does not support XDMCP. You can use the above procedure to start the DES.

OpenVMS V7.3-2

V7.3-2, with the default TCPIP services version 5.4, supports XDMCP. In order to use it, you will need to configure XDM. Please note that I was unable to get XDMCP to work without disabling access control in VcXsrv (adding “-ac” to command line parameters).
To configure VMS V7.3-2 to respond to XDMCP requests, begin by entering the following commands (“$” is the DCL prompt):

Next, edit XACCESS.TXT and add the IP-address of the Host at the bottom.
Next, edit XSERVERS.TXT and comment out any lines at the bottom that would start a remote X session, for example “rufus.compaq.com:0 foreign”.
Finally, restart the XDM service using the following commands:

You might be tempted to add a line to XSERVERS.TXT to have the VMS system automatically start the DES, however I was unable to get this to work reliably.

Related articles

• Page:
  Using X-Windows with Charon-AXP