Remote X sessions or VNC (was:Re: Headless YellowDog)

[Longman, Bill]

>  From g3ydl, I ssh into aragorn, set DISPLAY to g3ydl:1 and 
> export it. 
> Next I start an xterm, which immediatly exits with error:
> Xlib: connection to "g3ydl:1.0" refused by server
> Xlib: no protocol specified
> 
> On my virtual console on g3ydl that I used to start X :1, I get this 
> message:
> AUDIT: <date>: 1452 X: client 1 rejected from IP 192.168.0.2 
> port 32827
> 
> So this part of the faq is not working out of the box. By the way 
> 192.168.0.2 is the ip address of aragorn, so it's really my 
> remote xterm 
> being refused
> 
> I remember in my unix days, we had to set xhost +[remote ip] 
> or simply 
> xhost + to unlock the remote access to the X server.
> 
> So when I type xhost in console 2 on g3ydl, I get
> access control enabled, only authorised clients can connect
> 
> and the screen switches to console 8
> 
> switching back to console 2 and typing xhost +, gives me
> access control disabled, clients can connect from any host
> 
> and another switch to console 8
> 
> switching back yet again to console 2 and typing xhost shows 
> me that the 
> access control is enabled again.
> 
> Then I had a bright idea :-) , and in console 2 I typed xterm, which 
> started an xterm in my X:1 session. In this xterm, I typed xhost +, 
> which disabled the access control again.
> 
> Now with this setup, in my remote session on aragorn, I start 
> an xterm, 
> which now does appear on my X:1 session in g3ydl, hiding the locally 
> started xterm.
> 
> So apparently, I'm missing some clue about this access control. Can 
> anyone elaborate a bit on this, and maybe Bill, extend the concerning 
> faq a bit ?
 
I don't think you're missing anything, Geert. It's acting as it should. You
just have to understand that your console session #2 is the "controller" for
X session :1 until your window manager gets started. You should be able to
start X, change the permissions and start the window manager all from
console session 2. Every time you do any of these, you get automatically
switched to the X:1 console, for some reason. At least that's the behaviour
I've seen. You have to keep switching back to console 2 until you're all
done. I think it's kind of a pain in the rump, but I've learned to live with
it. Why the heck does the X console have to come up just because I add a
host with xhost?

Anyway, you've found another way to do it, too. I find it's often easier to
start X and then an xterm and then just run what I need from the xterm
instead of jumping back and forth to the console session 2. That's a handy
way to do it. Then, you have X running, you can xhost directly from the
xterm and then you can login to the other system and start the window
manager or the clients of your choice. The reason you have to run xhost from
the console or the xterm is that you need a local client with access to the
local X server in order to change the permissions. Look at the xinit
command. This is basically what xinit does - it starts the X server and then
a single client that enables you to control the rest of the X session.

Two caveats: when using ssh, you can forget about all the xhost stuff if you
just use "ssh -X aragorn". You'll also get DISPLAY set in your aragorn
session, too, so you won't have to set it. Try it first, though. The ssh
server on aragorn may not be set to allow X forwarding, so you might have to
change the setting in the sshd.conf file and restart the sshd. You'll see
DISPLAY set to something like localhost:10 if X forwarding is enabled.
 
> 2. With the workaround for the access control, I could 
> effectively start 
> wmaker from my aragorn remote session, and that worked.
> 
> 3. Next, I exited from wmaker, and typed startx, thinking this would 
> start my default window manager (kde), but that did not work. 
> Instead, 
> it complained KDE was already running on display :0.0. Ok, so I typed 
> startx -- :1, which started another X session :1, but on 
> aragorn's vt8. 
> This was not what I had in mind. Apparently startx ignores 
> the display 
> setting, and maybe, startx does what the name implies: starting an X 
> session, but then completely with window and session managers.
> 
> 4. So next, I used startkde on my aragorn remote session. And 
> yes, this 
> finally brought me my KDE session. I did however skip the 
> login session. 
> Is this normal, considering display 0 is also a logged in X 
> session, or 
> that I logged in via ssh ?

Here you've proven that you want to run a window manager, not X and *then* a
window manager (which is what startx does). You are already logged into the
machine, so it won't ask you for credentials - you've already supplied them
- so it starts up automatically.

startx - this starts X (locally. X always runs locally.) and the window
manager. This is the most brain-dead of the ways to start X. It blindly
assumes you mean a local X server :0 and completely falls over if there's
already one running on :0.

X - just an X server. You have to do all the rest, like start a client and
start a window manager. Dumb in its own way, but it's the basis for *all* of
this.

startkde, startblackbox, startgnome, wmaker - these are all ways to invoke
*just* the window manager. You have to have an X server running before you
run these commands.

xinit - this starts X and then, usually, just an xterm where you can
complete the rest of the X session. You can log onto the host you want and
run the window manager from there. Or you can just launch another local
window manager that's not your default. Pick and choose. You are in total
control! (At a minimum, this is what vncserver has to run - X and an xterm
in order to do something useful.)

> 5. So all of the above to learn something more about X, which 
> I did. Now 
> I started all this as a question about VNC. But considering X can 
> display a remote KDE session locally, why would I still want VNC ?
> 
> This is meant as a general question. Perhaps for my purpose here, the 
> remote X solution is good, but what are the (dis)advantages 
> of remote X 
> over VNC and vice versa ? In which situations would VNC be 
> preferred or 
> the only solution, and in which situations remote X ?
 
This is exactly the question you need to ask yourself. I only use VNC server
sessions if I'm trying to login to my linux box from a windows machine that
doesn't have an X server on it. I can always get the vnc client, run it on
the Windows machine and, presto, I have X because I can log into the VNC
server. If I can run X, I would not use VNC. In my environment, I have lots
of different machines with different OS's on them - Sun's, Windows clients
and servers, and lots of different linux machines. They can all get to each
other because they have access to each others VNC servers and the VNC client
runs on all of them as well.

Not all the Windows machines have X, though, so on machines that can run X,
I just run that.

Final point - you need to determine where you want to run the window
manager. A local window manager is faster, obviously, than one that has to
do everything through a slow network cable. But it only has access to the
locally installed programs and all clients run from that window manager run
in that context - on the local machine. If you want to run a remote machine
as if you were on the console, you typically run the window manager of that
remote machine during your X session. That's what vncserver is doing. You're
just using a different protocol to get the display bits sprayed on your
local machine. Sometimes it's good to run it with the remote window manager,
sometimes it's a pain because it's slow. If it's slow, then just login to
the remote system with an xterm and run the specific clients you want. It
will still be slow, but only *that* client, not all the window commands
which would be the case otherwise.

HTH,

Bill