A Tiny Little Error in the Post-Install, of the Debian / Stretch Package ‘xrdp’

One of the projects which I have just undertaken on the newly reactivated computer I name ‘Klexel’ was, to install an XRDP Server on it, so that I’ll be able to create remote sessions on it.

In case readers do not know, XRDP implements an analogue of the RDP protocol, but only acts as a go-between, that listens on another port, starts a VNC session, and then makes an internal connection to the VNC session, looping back to port ‘127.0.0.1:5900′ by default. And, if multiple clients of that sort are connected, the VNC ports continue with the numbering ‘5901…’ One big problem in trying to use VNC all by itself is, the need to have physical access to the machine, to start a new VNC session, to which multiple viewers may connect, including a person sitting in front of that machine. And another way in which XRDP can be used, is to connect to the X-Server / Xorg Session already running locally…

If the user wants to allow connecting to an existing, local X-Server session, then he needs to install the package ‘xorgxrdp’ from the repositories. What this will do is to install the X-Server modules that allow ‘connections from the side’ like that. Using this package requires a restart of the X-Server, once after installing it, while using Xrdp only for remote sessions, does not.

AFAIK, Connecting to an existing local X-Server session additionally requires that the package ‘x11vnc’ be installed, but I have not tested this.

The way I’ve chosen to use ‘xrdp’ for the moment is, with the additional package ‘tigervnc-standalone-server’, that is not automatically selected as a dependency.

I first tried to install the package ‘xrdp’ (meaning, the 32-bit version under Debian / Stretch) from the repository, only to find that there was a bug in the post-install script. It would generate an RSA Key-Pair, which is the correct thing to do, but it would then try to install that key-pair in the file:

/etc/xrdp/rsakeys.ini

The problem is, that this file is first set with wrong attributes. It belongs to user ‘xrdp’, to group ‘root’, and has permission-bits set, so that ‘xrdp’ can read and write, but ‘root’ cannot. This might be brilliant once the server is running, but because apt-get is only running as ‘root’, which does not yet belong to group ‘xrdp’, the post-installation hangs, not in generating the keys, but just in trying to write them to that file.

I’ve tried changing the attributes concurrently with the waiting script, as well as afterwards, re-attempting to configure the package. But the additional problem then becomes the fact that the post-install script deletes whatever file was already there, and then just recreates one with the incorrect attributes again.

I think a lot of other users would like it, if the package became installable on 32-bit systems.

What I did instead was, to custom-compile Xrdp, and to install my custom-compilation. It runs beautifully.

Dirk

 

NoMachine NX

When people connect to their VPN, this could simply allow them to access shared files. But alternatively, this could also mean that they wish to create a virtual session, on the remote desktop of one of their servers. The latter exists under the terms VNC, RDP, XRDP, and several others.

On my main Linux server named ‘Phoenix’, I have the XRDP service installed, which is the Linux equivalent of RDP. But one main drawback of this method, of remotely accessing a desktop, is the fact that XRDP does not allow file-sharing, specifically in the version of this protocol that runs out-of-the-box from the package manager. I have read that certain custom-compiled versions support this, but do recall that this service is a mess to custom-compile, and to set up in such a way that it runs reliably. So I stick to the packaged version for now, and do not obtain file-sharing.

There exists a closed-source application named , which we could use to bridge this gap. But while their paid software subscriptions are very expensive (from my perspective), their Free software version has some big disadvantages.

First of all, even their Free version can be run in client or in server mode. I think that this is terrific. But in server mode – which affords access to the local machine desktop from elsewhere – there is no built-in support for SSH protocol. There is only the unencrypted NX protocol, for which their service listens.

Secondly, not every computer is strong enough to run in server mode. On the computer ‘Phoenix’ I have a fragile X-server, and this service has actually crashed my X-server. Not only that, but allowing this service to run on reboot, consistently prevents my X-server from starting. It gets its hooks into the session so early on boot, that the X-server crashes, before the user is even asked for a graphical log-in.

On the plus side, there are ways of solving both problems.

Continue reading NoMachine NX

Routine OpenVPN Test Successful Today

On my Home LAN, I host a VPN. Contrarily to what the term might suggest, “OpenVPN” does not stand for a VPN which is Open, nor which anybody might have access to for free. OpenVPN is just one possible protocol for implementing VPN, and is stuffed to the gills with security measures and encryption, which keep unauthorized people out, and which ensure the privacy of the VPN tunnel, which a Client can invoke from outside the LAN, into the LAN.

I possess an OpenVPN client for my Tablet, that receives updates from its developers from time to time. After several updates to the app, I need to test whether it still works, even if at that moment there is no practical need for me ‘to VPN into my LAN’. And just today I found, that indeed this Android app, as well as my server at home, still work 100%.

In order to verify that I have meshed adequately with my LAN, I typically make it a part of the test to ping a computer on that LAN, which is not itself the VPN Server, and to make sure that I get normal ping responses. This also tells me that my specific routing implementation works, beyond the VPN tunnel to the Server itself. My average ping time today was 37 milliseconds.

A VPN is not really a Proxy. If I wanted to change certain settings, I could redirect all my traffic to the Internet at large, through my VPN at home, which is currently still configured to be routed directly from where my Client is located. I was performing my test from a public WiFi hot-spot, so my regular Internet access was still taking place directly from there.

And, because my Home LAN is located in the same jurisdiction as that WiFi hot-spot was, there would also be zero benefit, to my redirecting all my Internet traffic through the VPN, because doing so would gain no special access privileges, geographically, to Internet content anywhere.

Continue reading Routine OpenVPN Test Successful Today