Last active
June 10, 2021 13:59
-
-
Save edharman/2ab7976a71c413e9617add12dc94b278 to your computer and use it in GitHub Desktop.
Setup Windows X-Server
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As with most things under linux there are many ways to acheive the same thing so here is my recipe for launching X applications | |
from the numerous headless hosts I run at home onto my Windows desktop. | |
Download and launch the installer VcXsrv - this is the more modern incarnation of mingw or Cygwins xwin | |
https://sourceforge.net/projects/vcxsrv/files/latest/download | |
Accept the default features to be installed | |
Accept the default location directory | |
You will find a new icon on your desktop - XLaunch, double click it to run | |
In the display settings I select the default multiple windows, Next | |
Start no client, Next | |
In Extra settings I select Clipboard, Primary Selection and native opengl | |
There is also an option to disable access control, which is probably worth some discussion - | |
If you leave this unchecked then by default a remote host will not be able to authenticate with the X-Server unless you have explicitly | |
enabled this via the cmdline xhost utility. | |
If on a vanilla Win-10 host you do not have one of the Windows Services for Linux (WSL) installed then you will not have | |
programmatic access to control X authentication, so you might be tempted to select the disable access control. | |
The risks of doing this will vary on a use-case basis, however for most home networks where by default you have no open inbound ports | |
enabled on your ISP's router/modem then the risk exposure is limited to how much you trust your own hosts.. | |
If as I do you use SSH keys to authenticate with your hosts then they are pretty much secure and so it should be safe to allow any | |
of them to | |
launch X windows onto your Win-10 desktop (on the basis that you are likely the person remotely controlling this...) | |
So lets not select disable access control and click Next, and then click Save Configuration, by default it will prompt for a location, | |
the default Documents folder is fine, select Save | |
Finally select Finish. | |
If all went well the App will close and if you look in your system tray you should see an X-Server running with on <your hostname>:0.0 | |
You might get a pop-up from Windows Defender wrt VcXsrv, if so select the tickbox allow access over Private networks | |
I then add VxSRV.xlaunch to my Windows startup folder so that it launches in the background upon system start. | |
To gain most benefit from the ability to e.g. | |
Simplify exchanging host keys using ssh-copy-id | |
Simplify X-11 forwarding on remote sessions (the ssh -X <host> removes the need to set the DISPLAY variable) | |
I strongly recommend installing one of the WSL environments onto your Win-10 host, I generally use flavours of Ubuntu but under the | |
hood most distros will be using similar SSH packages and X11 utils so you can use whatever you feel more comfortable with. | |
I won't go into the detail as to how to install these, just go to the App store end perform a search. | |
When installing don't get hung up on what username to use, I just default to the same name I use to authenticate with Windows, | |
you just need to remember that they are in fact stored seperately and are not intrinsically connected in any way. | |
Launch whatever WSL distro you installed and in the session window install - x11-xserver-utils, openssh-server, | |
and not strictly necessary fontconfig, xterm - | |
sudo apt install x11-xserver-utils, openssh-server, fontconfig, xterm | |
Next we will configure access control to the X-Server, the simplest assuming you have no security concerns is to allow all by typing | |
xhost + <cr> | |
The default shell for Ubuntu is bash so if you are using a different distro the following will need adjusting to suit - | |
Edit the .bashrc file - | |
nano ~/.bashrc | |
add the following line to the end of the file then save and close- | |
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0 | |
This will ensure that subsequent launches of the shell will have the appropriate DISPLAY value set, to test exit the session window, | |
and relaunch it | |
In the new session terminal type xterm | |
If all went ok, a new terminal X-11 window will appear set to the same pwd as the prior window and that xterm window will be the | |
active session. This shows that your Xserver is working as expected. | |
exit to return to your Ubuntu session. | |
Now to configure your ssh keys and enable passwordless remote access to your hosts - | |
First we need to generate a private & public key for your host- | |
ssh-keygen | |
it's ok to accept defaults for all the subsequent prompts. | |
This will store your keys by default in ~/.ssh | |
Now to copy your public key to a remote host and thus enable passwordless login between the two - | |
ssh-copy-id <targethost> | |
you will be prompted for your hosts password, enter it and hit return | |
You should see a message saying key added and return you to your local hosts session. | |
Now simply ssh <targethost> should automatically log you in to a remote shell on your target host! | |
Now to test X-ll - | |
log out of the remote session and relaunch adding a -X (which enables X-11 forwarding) - | |
ssh -X <targethost> | |
now you should be able say | |
ssh -X pi@<your RMS pi> | |
enter a password and establish a terminal session. | |
In that window - | |
cd ~/Desktop | |
./RMS_ShowLiveStream.sh | |
and a 2nd window will launch on your windows desktop with the LiveStream. | |
To enable passwordless login to your RMS host you have a few options - | |
1. Back at the default WSL installation where you are prompted to enter a username use Pi instead of your Windows name | |
2. If like me you used your current Windows username you could create an account on the RMS host with your windows username and set the | |
default directory to /home/pi | |
Some useful command modifiers are - | |
<command> & <- this will launch <command> and background the process so that the terminal can be re-used for other purposes. | |
You may notice that if (as I do) you install xterm on your remote host, then you can login once to the remote host and if | |
you want to say monitor a log file whilst launching another app, you can simply launch a 2nd xterm window by typing xterm & and the terminal window is launched | |
in the same default directory as the original. | |
so say in one terminal | |
tail -f <RMS logfile> | |
and in the other | |
launch StartCapture etc.... | |
One other aspect of xterm is that (actually as with most X-11 apps) the launched session takes default values from a local file on | |
your Windows host - ./Xresources | |
so for example you may notice that xterm windows by default are black text on a white background and also by default do not use | |
coloured text nor a particularly legible typface/font. | |
This can be remedied by performing the following within the normal WSL session - | |
List the currently installed fonts - | |
fc-list | |
and choose one you like - to try each you can launch xterm -fs "font family name" | |
then edit/create a file ~/.Xresources and e.g. put | |
xterm*faceName: Terminus | |
xterm*faceSize: 10:antialias=true | |
XTerm.vt100.reverseVideo: true | |
Save the file and then merge those changes into xrdb - | |
xrdb -merge ~/.Xresources | |
On my system this allows any new xterm to mimic the style and font of the WSL window and enhances readability somewhat. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment