XServer, remote Debian workstation

Question

I wish to set up a headless workstation machine running Debian Linux. I'd like to actually run XServer on another machine. Think thin-client, though the "thin client" machine is actually fairly beefy. To the maximum extent possible, I want the thin client machine to feel like I'm doing everything locally, while actually storing all files (apart from config, cache and maybe ssh private keys, I suppose) on the remote workstation and doing all the CPU processing on the remote workstation. The two computers are hooked up on a LAN.

So, thin client for keyboard input, mouse input, and displaying the GUI. Everything else (desktop manager, all software, all processing) on the workstation.

How do I accomplish this? VNC doesn't really fit as it requires (or seems to require) I sign in locally, on the workstation, then just echo the desktop remotely. I could use ssh, but that requires that I run a full desktop environment on the thin client machine, but I really want as little as possible there.

I don't need hand-holding, I'm just not sure what my options are. It's obviously possible, we used to do this back in the early 90s, I just don't know how. The thin client has plenty of hard drive space, plenty of CPU power, and 32GB of RAM, it's just that the workstation is more powerful. And better controlled. But sits in a closet, without a monitor.

Answer 1

On the client you'll need enough OS to boot, load libraries, manage the local video/keyboard/mouse, and run a X server. On the remote headless box, do your regular install of whatever you want and configure the greeter on it (gdm, kdm, mdm, xdm are the typical choices, depending on desktop environment, etc) to allow querying via the XDMCP protocol. Once that is done, on your local client start the X server and tell it to query the greeter on the remote host. Apps run from remote host, user interaction takes place on local client.

You could even run a full OS on your local machine, and when you need something from the remote you could use Xnest to nest a second X server inside your current one, query the remote host, and run the 2nd desktop as an application, much like VNC works.

Answer 2

Your question raise a number of concepts whose detailed discussion require more than a book (...as most of those "concepts" originated in the early days of XWindow and evolved up to current days...).

Hence, I don't want to appear crazy by saying that I'm going to provide a detailed answer to you.

Nevertheless, I'll address it by touching the surface of some points that you should have clearly in mind, when approaching the remotization of applications under Unix/Linux/XWindows systems:

1. The "X Window System" is at the base of almost every Linux application that show some sort of GUI. While inviting you to check for details by yourself (there are more than 30 years of history that you can search around), I want to stress a very important point: by design, X11 was architectured so that every single application can run on an host and, at the same time, rendered (as for the GUI) on a completely different host. This without any single explicit effort required by the programmer.

   This is radically different from what people were used to, under Win32 platform, where only an addition of an explicit layer (RDP and related Terminal Services) provide a similar behaviour, starting from some decades ago (but were surely missing in Win 3.XX, Windows 95, Windows 98, Windows NT and probably on some later system. Not to mention licensing issues...)

   So this means --in general-- that in the early 90s you could sit yourself in front of an X-Terminal and have it display the application you were running on a different server machine. Exactly the decoupling you're pointing in your OP.

So, back to your question, you can surely run your X11 application on the big-iron you have in the closet and have its GUI rendered somewhere else.

Is this enough? Unfortunately not.... Let me explain why:

2. "remote application" vs. "remote desktop": sometimes it would be enough to have on my desktop (I'm referring to the graphical stuffs that are display on the monitor of my notebook, where I'm running a full Ubuntu Desktop) the GUI of an application that is running somewhere else. As an example, I have the normal desktop but... the "firefox" window is related to a "firefox" running on a different machine. In such a case, I'm accessing a remote application, within my desktop environment.

   Other times I'd prefer to have the whole desktop to be rendered by the remote system, and not the single applications. Hence, the remote system need to address slightly more issues as... there's also some "special" window (the one that cover the whole monitor and not present any border, more or less) to render, and of top of it, render the whole set of desktop applications (menu bar, status bar, etc. etc.). In such a case, I'm accessing a whole remote desktop.

Based on your question, it's not clear if you're interested in "remote applications", "remote desktop" or both.

Is it all? Not yet... unfortunately.

3. "transport": it's obvious that decoupling the application logic (running on the server machine) from the GUI (displaying on a remote display), imply the needs of a reliable network communication channel. When X11 was developed, probably I was not born yet (BTW: I'm 46!). There were no Internet. And there were no concept of "risks being network-connected". As such there were absolutely NO security point in the X11 protocol. As such, if you were sitting in front of a X-Terminal with IP a.b.c.d, from it you would simply telnet e.f.g.h and, from there, launch something like:

xclock --display a.b.c.d:0.0

and suddenly the xclock window appeared. At the time, if your friend were sitting on the terminal y.z.x.w and you would give him a root shell on e.f.g.h, you (from a.b.c.d), could simply:

telnet e.f.g.h
su -
xterm --display y.z.x.w:0.0 &

and suddenly your friend had an xterm window popping up, with root permission, and without entering any password!

Please keep in mind that we're speaking about a timeframe where Win32 systems did not exists. At best, it was the time of Windows 3.11.

Now fast-forward 20 years. The Internet arrived. The security issues with it. And suddenly lots of people discovered that was easy to grab "video" and "mouse" and "keyboard" flowing around an unencrypted X11 session.

Several solutions (lots of which are still obscure/unknown to me) were implemented, but by far the best one is SSH-X11-Forwarding. Thanks to it, still now, in 2017, every single day that I sit down on my desk, at work, I:

• place my notebook on the docking station and turn it on (in a corner of my desk);
• login on my desktop computer (left powered on, with display/session "locked"), attached to two big 27" displays;
• from my desktop, ssh to my notebook with ssh -X verzulli@10.0.72.21;
• from the resulting terminal, launch a thunderbird &;

So I have my thunderbird, installed and running on the notebook (with all the related archives), and displaying on a much more comfortable 2 x 27" displays.

This... despite more that 30 years passed since the introduction of X11... and without the need of any form of licensing!

Is this all? Not yet :-)

4. X.client vs. X-Server: thinking to what I do every day with my thunderbird, you should see that:

   • thunderbird is the X-Client running on my notebook, where noone is sitting in front;
   • my Linux desktop PC is the X-server, receiving the X11-stream from the client, and rendering it on the local display.

   So it sounds like the role of client and server are reversed. That's exactly what happens with the stuff you call "Thin Client": they are NOT client in the networking point of view: they are the "server". That's why in order to display a remote X11 application on your device, you need an X-Server running on it: because you need an X-Server, being able to understand the X11 stream coming from the network (...from the client) and properly rendering the resulting display.

   In previous answers you have been told about Xnest, and actually I'd add Xephyr: they are:

   • standard X11 applications, from the point of view of the local XServer. As such they are tipical rendered "locally", on the local display;

   • they are X-Servers, in the sense that they are able to receive the X11 stream of a remote application (tipical, a whole-remote-desktop), and render it INSIDE a single window.

In general, nothing prevent you from using the already-installed XServer of your machine, without the need of Xephyr or Xnest. You might want, in other words, use your XServer installed in your own linux host to connect to a remote host asking to receive a whole X11-desktop-stream. In general it would be as easy as:

• get out of X11, back in a text CLI (no GUI);
• just launch a sort of : X -query a.b.c.d

where a.b.c.d is the IP address of an host, where the XDMCP protocol has been configured and enabled (more or less).

Gurus on this site will say that I'm oversimplyfying.... and they are right! So, please, take the above approach (X -query) only as a point for further investigation.

Have we finished? Yes... but not before adding a couple of other quick points:

5. Protocol efficiency: X11, being developed more than 30 years ago, is definitely a non-performing protocol: you'll have LOTS of troubles in using it with bandwidth lower than 100Mbps (BTW: In my office, I've gigabit connection between my notebook and my desktop). YMMW, but please, keep this in mind when you'll experiment (the xclock window could appear even after 30 seconds, when you launch it on your remote VPS). I've no problems in admitting that RDP, from Microsoft, that arrived LOTS of years later, are incredibly much more bandwidth friendly. From this point of view, RDP is really superior to X11;

6. In order to address point 5., lots of effort have been put in place by several projects. Main ones - IMHO - are NX and related FreeNX (that actually seems a dead project, unfortunately);

7. In my opinion, in current days (2017), trying to achieve the remotization of the whole desktop (without Xnest or, better, Xephyr) is much more complex than before... and definitely much more complex then remotizing only the applications you need. This due to the fact that current desktop-environments evolved at a so higher level that... they have lots of problems in "fitting" in a remote X11 display (think to the amazing animations you can have with compiz-like technologies, and related requirements for a decent remote rendering. This, in addition to security issues demanded by the intrinsic vulnerabilities of the X11 protocol).

That's all.

I really know that I absolutely have NOT answered your questions: I only hope to have given to you some really nice insight of this wonderful X11 world... you'll be happy to discover by yourself :-)

Answer 3

Enable auto login on the thin client. Set a startup application on the thin client desktop of your choice of remote login programs. Consider RDP, which also connects easily to any Windows servers you might have.

The thin client will need enough of a GUI to run an X server or equivalent. Specialized, light weight, read only root thin client distributions exist like LTSP. Or just ssh -X and run remote programs ad-hoc.

Remember that the programs are running on the server. Users need to be in the habit of saving to network shares if they want to find their files. Also, the GUI can look a bit different, if a different version, or a user selected theme.