[Info-vax] OSes

[Johnny Billquist]

On 2016-01-18 07:43, lists at openmailbox.org wrote:
> On Sun, 17 Jan 2016 21:12:45 +0100
> Johnny Billquist via Info-vax <info-vax at rbnsn.com> wrote:
>
>> On 2016-01-17 19:14, lists at openmailbox.org wrote:
>>> On 15 Jan 2016 16:33:57 -0500
>>> Bob Koehler via Info-vax <info-vax at rbnsn.com> wrote:
>>>
>>>> In article <mailman.1.1452850533.15674.info-vax_rbnsn.com at rbnsn.com>,
>>>> lists at openmailbox.org writes:
>>>>>
>>>>> I got the impression this (DECwindows using X forwarding from VMS to a
>>>>> Linux X server) is not possible on SIMH. Has anybody gotten it to
>>>>> work?
>>>>
>>>>      Not specifically that combination, but ever other combination of
>>>>      X11 on Linux with other systems, and X11 on VMS, including from
>>>> simh, has worked for me, no matter which one I wanted as the server
>>>> and which one I wanted as the client.
>>>
>>> What are you running from SIMH that you X forward, if not VAX/VMS?
>>
>> Are you aware that X is a protocol over TCP.
>
> Yes.
>
>> There is no need to "forward" it. And what people are talking about here
>> is actually to not* forward it, but let the X clients talk directly with
>> the X server, without any forwarding agent in between...?
>
> The two ways I know about are logging into the remote host's X server which
> I guess is what you are talking about, and X forwarding from the remote
> host to the local host which is how I usually prefer do things. For remote
> desktops I use other solutions. I use X forwarding all the time when I want
> to run just one app on a remote host and use my local X server to run the
> app with the rest of the apps on my desktop.

Right. And that is not the only way to do it. In fact, that is the more 
recent solution that people use for various reasons. And it seems that 
the knowledge and understanding about how X works have been lost for a 
lot of people today.

So, no, I am not talking about any of that.

Logging on to the remote hosts X server is in fact a meaningless 
sentence. The remote host is not running an X server. The X server is 
always local. The X server is what is managing the display that you are 
sitting at.

Another machine might also have an X server, but that X server is then 
serving some other user, who is sitting locally at that machine.

It would appear that you know, in theory, that X can run over TCP, but 
you do not seem to really understand what that means. X clients can talk 
to the X server, without you having ssh forwarding the traffic. In fact, 
that is not what is meant by X running over TCP. When you tunnel X over 
SSH, you are in fact faking that you have an X server on the remote 
machine. That is what the ssh tunnel do for you.

Now I'm going to describe this very specific for Unix, since I know that 
the best, and then give some hints on VMS.

The X server, like I said, is always running on your local machine. The 
X server is also, always listening on a tcp port. Any X client program 
can connect to the X server, and get things shown on the display. This 
can sometimes be unwanted, and therefore the X server can restrict 
access through various mechanisms.
As this is a connection using TCP, the X client programs can in fact be 
anywhere in the world. They obviously do not need to be on the same 
machine as the server.
So, how do a X client program know which X server to connect to. After 
all, you could have several users running on the same machine, but 
coming from different places, each with their own X server.
In Unix, this is controlled by the DISPLAY environment variable. It 
usually holds the hostname and display number. So, it could, for example 
be that DISPLAY holds "myhost.com:0", which would point to an X server, 
and a specific display on that X server.
In most cases nowadays, people on Unix machines have the DISPLAY 
variable set to just ":0", which means display 0 on the local machines X 
server. When you tunnel X over ssh, you will have a DISPLAY variable 
that looks something like that.
In order to let your X client programs talk directly with the X server, 
without running through your ssh tunnel, you need to set your DISPLAY 
variable properly. In addition, direct communication is way more 
efficient than running through an encrypted ssh tunnel.

So, ssh to the machine you want to run your X client program on (or 
telnet, or whatever), then change the DISPLAY variable to actually hold 
the hostname for your machine, followed by :0, and then run the X client 
program.

As you do this, you will most likely get an error. This is because by 
default your X server will not accept connections from random places. 
So, in another window, which is local on your machine, you run the 
program xhost, which you can use to allow or deny other hosts from 
connecting to your X server. And you'll type something like "xhost 
+remote.host", and after that you can run X client programs on your 
remote host that talks directly to your X server. ssh tunneling is not 
involved.

Other ways than the DISPLAY variable also exist. Many X client programs 
can actually take the X server destination also as a command line 
argument. Check the documentation.

Now, for VMS, you obviously have to adapt this somewhat. You do not have 
environment variables in VMS, but you have logical names. And unless I 
remember wrong, you instead use the logical name DISPLAY to point at the 
display to use. Much of the rest applies just like above. In addition, X 
can actually also use DECnet as a transport, and not just TCP. If I 
remember right, if you put a double colon after the host, but before the 
display, such as "FOO::0", DECnet will be used.

I hope you understand this a little better now. ssh tunnels are not the 
only way, and with older systems, that existed before ssh even was 
thought of, might be tricky to use ssh on, but X still works just fine. 
You just have to know how X actually was designed and intended to be used.

The ssh tunnels are a hack. They work by setting the DISPLAY variable in 
a way that makes it look like a local X server on the remote machine, 
with a unique display number, and then that gets routed to your ssh 
session, where a tcp tunnel exists, and when a connection comes through 
there, the originating ssh client then establish a tcp connection to 
your local X server, and thus manage to get it all working. Which is 
also why you normally do not need to touch xhost, since in this case, 
the X server thinks its a connection from the local host, which is 
normally already permitted.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol