Fix for x11vnc problems on Stretch

Following up to my last article, having tested x11vnc for a day on mediapc, it crashed with the "stack smashing detected" issue. Reported as a Debian bug here:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859213

This issue affects multiple distros, including ones unrelated to Debian, such as Red Hat, Arch and Fedora, as well as related such as Ubuntu.

The recommended solution for Debian Stretch is to install the x11vnc packages from the testing repository. I have now applied them to mediapc for further evaluation.

Hopefully this will make x11vnc reliable enough to be used for my purposes. This is about the first update to x11vnc in eight years.

HOWTO: Share a screen in Linux

Screen sharing is a generic name for allowing the screen on one computer to be accessed from another. It is similar to, but different from, Windows Remote Desktop. There are a number of options that are mostly based on VNC. I have a Windows 10 Home computer here that has TightVNC Server installed on it, and with Remmina running on one of my Linux computers, the user session running on the Windows 10 computer can be controlled through Remmina, and at the same time as being displayed on the Win10PC's screen. This is different from RDP which locks the screen when you log in to the remote computer, although you are connecting to the same session.

However the scenario where I want to control the current session that is running on a Linux computer, is a bit more difficult because most VNC programs work differently under Linux than they do under Windows, including TightVNC for example. Under Linux, the current session under X-Windows (the basis for most GUIs in Linux, although Wayland is starting to be adopted as a replacement) can't be shared in most of the common VNC implementations. So these programs generally create a new remote session which the user can run stuff in, but they can't share the default user session on the computer. This means that many of the FOSS VNC packages won't perform this function and so you can't expect to install some VNC system and it will just work.

Exceptions to this include the following packages:

• Vino is the screen sharing package for Gnome. It is provided with Ubuntu and variations. Standalone packages are also available for other distros and will work with XFCE, but it is more and more being integrated into Gnome these days which makes it difficult to use with other desktop environments. I have used Vino in the past with Xubuntu, but the impression I have now is it would be difficult to use in Debian/XFCE because the configuration is supposed to be done with a Gnome-only tool. There is a desktop sharing tool in Cinnamon which is probably Vino adapted to a non-Gnome environment. I haven't used Cinnamon since I used to have Linux Mint a couple of years ago, so I don't consider this to be an option.
• X11vnc is a package developed formerly by Karl Runge. It is in the repositories of major distros such as Debian. It is easy to set up and install, but has not been actively developed for several years, and my impression of it is that it is not very reliable, tending to crash a lot. I remember a year ago using it with Xubuntu and it seemed to have better performance than Vino. (I will take another look at X11vnc to see if I just need to change some configuration settings, but I was unable to make it run as a service on my computers)
• RealVNC is unlike most of the other VNCs in that by default it shares the current Linux user session. However it is commercial software although a limited free license is available. I haven't bothered to install it because of this licensing issue.
• Xpra is a package that among other things is supposed to be able to "shadow" the current user session on a computer. I tested it and it seems to be difficult to configure and make work successfully. The documentation for it is tricky to understand. It looks like it has some potential but is either very complex in operation, or needs a lot of work to make it as user friendly as some of the other packages.
• X2Go is another open source community supported package. I am currently testing this on mediapc to be able to control it from mainpc. There is a specific package with it called X2godesktopsharing that is specifically used for the screen sharing functionality. Unfortunately X2Go turns out, like Xpra, to be another poorly written and supported package.
• NX/NoMachine is the last option to consider. X2Go is based on it. NX uses its own protocols and NoMachine provides a limited free version of a commercial package. There used to be an open source part called FreeNX but it is well out of development.

So I have been looking into a lot of options this week. There is in theory another option which is the Linux RDP clone which I think is called rdesktop. I haven't looked into that one.

Right now I only have NoMachine left to test having gone down the list, or I could still consider RealVNC if I run out of options.

Computing resources optimisation [1E]

Got to thinking more about how to make the best use of resources with the computers. The biggest issue is ergonomics. You can only really practically use two keyboards at a time. So if using more than two computers you prefer to have more than two keyboards/mice, but it's hard to access them without moving your chair, unless you can use VNC. At the moment I have a love/hate relationship with VNC because I haven't been able to make it run as a service on any of my Linux computers and therefore work out of the box every time. Also X11vnc is less than reliable and crashes quite frequently.

In terms of the two computers that are most frequently used, the serverpc that only has 16 GB of RAM should be boosted to 32 GB at some point, probably with a new mainboard, and its existing mainboard gets moved into mediapc, which in turn its board gets moved into the 4th computer. The main issue with running lots of applications on a 32 GB computer is when one of them causes it to crash. I'm still looking at the optimum way to use the 3rd or 4th computer to run some stuff such as email and spread the load of map resources onto the 2nd computer so it isn't all the 1st computer, but it's a tricky process to try to work out the best way of making that happen. I think it will be necessary to focus mainly on the two computers with the keyboards that are easiest to reach that will run virtually everything, so mediapc will stay media and ministrypc will stay ministry.

Running the day to day stuff in a VM on mainpc is a possibility. We are looking at what is internet based and doesn't have issues with local resource access. It's possible I may put email onto mediapc and possibly some other resources because it isn't used for that much and occasional access via its own keyboard, which can also be switched onto one of the main keyboards, is viable. This is different from using it for image display, which is what I have already experimented with, which often runs into problems getting updates from mainpc over the network. Internet based stuff like email doesn't have that limitation.

So probably the next goal is to get serverpc up to 32 GB, there is quite a bit of cost to this so it would end up happening in stages. Of course, I presently have no budget for this, so really it is a dream for the present. We just keep working with our current resources for now. If I can make VNC work properly on mediapc then it will be easier to do stuff on that which I find hard to use it for at the moment. However doing the new board for serverpc and putting its board into mediapc would also help because mediapc would have enough resources to run more stuff and over VNC it would be very good because I am using VNC to control the screen, which is still being displayed, unlike RDP where the screen turns off. 

I will have another look at VNC support for Debian and do some testing with tightvnc as it seems I should be able to make this work and then mediapc in particular can be used for more things.

Using VNC for remote control again

One year ago almost exactly I wrote about using VNC with a couple of home computers. My computer arrangement after that date was changed and remote access was not needed between two rooms of the house. However this week I have decided there are scenarios for remoting from the bedroom to the lounge where three main computers are. Mainly that it will enable me to do some computing stuff and have a devotional time at the same time in the bedroom as that room is set up for devotional time and there are many small tasks that can be done on the computer that don't need me sitting in front of it all of the time. So in enabling me to increase my devotional time which is what I really want to be able to do. It is also better for being able to work on the computer while in bed so that I can avoid staying up way past my bedtime as I have at times. Bed is a much better place to be if you are tired as falling asleep in front of the desk is risky since many times I have fallen off my chair and landed heavily on the floor.

Remmina as a client and x11vnc as the server are the combination used just as my previous post described and Remmina presents the screen as two windows side by side that you can just move the mouse to the edge of the monitor to scroll to the other screen. I will not be setting up remote access to the other computers in the lounge as it's only MainPC that really justifies this. Since for more indepth stuff I can just work in the other room. Working from in bed at times and at other times sitting in front of a music keyboard, using a multimedia computer keyboard is not very productive as compared to a regular desk setup but I won't be doing this with the desk even though it has been fitted in the past with a keyboard slide as it has since been lowered to be at the right height for playing the music keyboard. In effect this options is really only for relatively simple tasks that do not require a lot of typing or a regular mouse in place of a touchpad. And I don't want the distraction of a full keyboard/mouse setup in the bedroom because it is of secondary importance. I already had the E350 HTPC set up to play videos and it has adapted easily to this new role with a pair of Dell 22" screens. Unfortunately at this stage I cannot used the 1366x768 Sony 32" monitor as one of the screens as this resolution is not available when mirroring the screens so cannot use a 1680x1050 screen mirrored with the Sony so 3 screens in the bedroom for now.

I had already been using a second screen with the computer (2 screens mirrored) to serve a dual purpose of enabling me to look at PDF music charts with my Casio keyboard as well as this second screen enabling me to have the computer on while playing music for night time intercession, a common scenario because of time differences doing international intercession, since I can just turn my head to the opposite side of the bed and the light from the screen won't keep me awake. At a time when it is all important to have more devotional time, being able to use this setup is really useful. This week I have been doing lots of small repetitive tasks on the PC that don't really warrant spending a lot of time sitting in front of it but still have to get done so being able to retreat to the bedroom is the best of both worlds and I am sure will continue to be in the future.

This is the first and last blog post written using this arrangement as being limited to two finger typing on a multimedia computer in bed is very slow and tedious.

More Remote Access with VNC Servers and Clients

Last time I wrote about remote access it was to talk about RDP clients for Linux. Now it is time to have a look at using VNC, which is better supported as a server for Linux than RDP. Ubuntu comes with what is called "Desktop Sharing" which can also be installed as the vino package. This is a straightforward and easy to set up VNC server for your computer. I am only using it on my home network, not over the Internet - if you need to do the latter you should set it up to work over SSH. I have never set up any remote access to my home network over the Internet and don't plan to do so in the future.

Some instructions here

You will also need a VNC client. TightVNC which I used on Windows is capable but is no longer produced natively for Linux as the producers have focused exclusively on Windows for their present and future development of the native client. It is possible however to have it running on Java but I want a native client.

https://help.ubuntu.com/community/VNC/Clients

From this I can see a few recommended options like Vinagre. This was easy to install, but terrible to use. It was incredibly slow to update the screen. So I ditched it pretty quickly.

Here is another article that is worth a look:

http://www.techradar.com/news/software/applications/7-of-the-best-linux-remote-desktop-clients-716346

From that article I have tried installing TigerVNC (which is in fact a TightVNC fork), but it won't run on my system. So for now I am playing with Remmina. This at least will give me access to all three screens (on MainPC) in one wide window I can scroll across. There is still a lag I am not quite used to when typing and moving the cursor around. Having used Remmina quite extensively with RDP clients you don't see these sort of delays on RDP so maybe there is just something to adjust in the configuration, but it could also be Vino that is responsible for the slowish performance. I noticed in the article they used X11VNC rather than Vino. TurboVNC looks good as a client but turns out to require Java, which I don't see the point of, as this computer is going to have resource challenges running it. 

Back to the the Ubuntu.com website and we have a separate section on VNC servers worth looking at:

https://help.ubuntu.com/community/VNC/Servers

This one talks about both Vino and X11VNC. I chose at this juncture to remove the former and install the latter. The instructions for X11VNC are very useful simply because this software's man page reveals a huge number of configuration options. Well as soon as I got X11VNC running I can see that immediately it is way better than Vino. This well and truly justifies the high praise that the combination got in the TechRadar report mentioned above. In fact I am finishing off this blog post from a remote machine running Remmina accessing MainPC running X11VNC and the result is as good as RDP, flawlessly smooth response for both keyboard and mouse, the colours look great and so on. Although Remmina doesn't appear to provide a way of displaying the client window over multiple local monitors it provides quite a painless way when it is in full screen mode of scrolling between the server's monitors by simply displaying them from left to right and moving the mouse to the right or left simply causes the client to scroll across to the next monitor. Switching between virtual desktops on the server was quite straightforward as well. So I can see that if I choose to work in the lounge with the only PC there now being a fairly lightweight AMD E350 which even with 8 GB of RAM is quite stretched running more than a web browser and definitely struggling with more than a few browser tabs open, then I do have the option of VNCing to one of the other computers. It is further interesting that starting VirtualBox on MainPC provided another means of interacting with it as a pair of windows on MainPC, compared to remoting to it with Remmina. As Remmina does not have the ability via RDP to handle multiple windows, using it under VNC is a more desirable option, although of course I do have the ability to also use XFreeRDP on this computer to get to the VM as previously mentioned.

So all round getting VNC working on my computers is a great move forward due to the location of where computers are currently being used and their various capabilities.

Remote Access with Remmina and XFreeRDP

In the title of this message I have listed two remote access clients: the Remmina gui based RDP software and XFreeRDP which is command line based. Right now these are the tools I am having a play with to try out different remote access systems, which in my scenario is to allow me to remote from a Xubuntu desktop to a Windows 7 virtual machine running on VirtualBox. The big issue is that this VM is running with dual displays, which Remmina in particular doesn't support. I certainly want to have both of those displays appearing on my computer screen on the lounge computer when I work there.

Remmina is otherwise a good package that I use all the time for work purposes, it is similar to RD Tabs with a tabbed interface to access multiple simultaneous remote desktop sessions at the same time. XFreeRDP is something I have tested and shown to work with the dual screens of the VM but I was not able to find a way to exit from its full screen mode so the aim of this post is to more fully document its functionality as a reference for using it later.

Instructions for installing Remmina

The command line syntax for XFreeRDP goes along these lines

xfreerdp [file] [options] [/v:server[:port]]

There are a lot of possible switches and the ability to store settings into a .rdp file, which I presume has the same format as Windows does. The simplest option by far is to simply pass a server name and optional port number. These settings and perhaps the -f (for fullscreen) option could be saved in a shortcut without having to create the .rdp file. Pressing Ctrl-Alt-Enter turns out to be the keyboard shortcut that toggles full screen mode, but only if you put -f in to start with. But to get out, also, you can select Disconnect from the start menu. The next thought is how do you make it use the multiple monitors present in the source in this case? And the answer is the -multimon switch. So a useful command line will look something like the following:

xfreerdp -v 192.168.20.103 -u admin -p password -f -multimon

As it happens Remmina is good enough to use for non-multimon purposes so I am just going to use that xfreerdp for this exact situation, connecting to that virtual machine, which it happens I was doing with MSTSC when this computer was running Windows. So I made a shortcut with those parameters, and it works flawlessly.

Here is a description of the man page for xfreerpd:

http://linux.die.net/man/1/xfreerdp