Major Update to Debian / Stretch Today

I have two computers running Debian / Stretch, which is the code-name for Debian 9. I name those computers ‘Phosphene’ and ‘Klexel’. Debian 9 has just received a major update, from Debian 9.9 to Debian 9.10. At the same time, this update installed a kernel update on both machines.

As far as I can tell, the upgrade went smoothly on both machines.

Dirk

 

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

 

Unattended-Upgrades fails to install any updates (Solved).

All my desktop and laptop computers are Linux-based, more specifically, being Debian-based, but I enjoy having some of the simplifications which Windows offers, including either to notify me of pending updates, so that I can use point-and-click methods to install those, or even, in some cases, to install updates automatically. The package which I use, to install updates automatically, as I sleep, is called ‘unattended-upgrades’, which is a package which cannot simply be installed and forgotten. If the user has installed this package, he or she must also configure it. And the following Web-article explains, how to do so under Debian:

https://wiki.debian.org/UnattendedUpgrades

A situation I was having for some time was, that ‘unattended-upgrades’ was installed and working fine, on my Debian / Jessie – aka Debian 8 computer named ‘Phoenix’, but that even though I had followed all the instructions for how to install and configure it on my Debian / Stretch – aka Debian 9 computer named ‘Phosphene’, the same package did not seem to work on that one. I had often found that if there did exist updates which the automated process was supposed to install, then the log file on ‘Phosphene’ would break off, just before indicating which packages were going to be installed, and no updates would take place. This would happen every time that some updates were to be installed, and required each time, that I install the updates in question manually. Also, the ‘normal’ logging output did not include any error messages; it would simply stop in mid-process.

What I finally needed to do in order to troubleshoot this process, was to wait until there were going to be pending updates, and then, instead of installing those manually, to run the following command from the command-line, as root, and to observe the output:

 


# unattended-upgrades -d

 

Running this command when there were no updates pending was rather useless, because the malfunction would not take place, unless there were updates pending. Also, this process should not be interrupted if it’s in the middle of installing updates, because doing so can and will cause package-corruption and / or software corruption. If the process is going to install multiple packages, the user needs to wait until that process has finished, before doing anything else from the same command-line. What I finally found was, that the article linked to above omits a very important piece of information.

Continue reading Unattended-Upgrades fails to install any updates (Solved).

How to patch ‘kdeconnect’ to work under Debian / Stretch.

There exists an Android app named ‘kdeconnect’, which, when paired with the Debian / Stretch / Plasma 5.8 desktop widget by the same name, allows users to sync various features between their Linux desktop, and their Android device. The versions I’m presently using are:

  • Android app: 1.12.9
  • Linux package: 1.0.3~bpo9+0

Besides syncing certain basic messages, such as phone Notifications to the widget, this app allows for the desktop computer to browse directories on the Android device, which the user has authorized from his Android device – as long as the Linux desktop widget software has been patched! Below is another shot, of what this looks like when it’s working:

Screenshot_20190615_181900

The main observation about this is the fact, that it does not work out of the box. The reason for this is the fact that the Linux widget is out-of-date, as a backport. The Linux-based software tries to use an SSH-FS Mount, that specifies ‘DSA’ as its crypto-algorithm. DSA is an outdated, insecure protocol, for which reason the application framework of Android no longer supports it! Android will demand that RSA be used as a minimum.

And so, due to this initial incompatibility, the SSH-FS Mount, which creates a virtual file system in the user’s home directory, in a hidden sub-directory, fails, with an error message to the user that doesn’t seem helpful. This error message simply complains that certain files and folders could not be found, that are supposed to exist remotely, from the Android device.

And so at first glance it might seem like an unsolvable problem. But as it happens, with this exact version of the Linux package, there is a fix, which I’ve been using for months. In the past I wanted to keep this patch to myself, out of fear that my readers might botch this delicate surgery. But I’ve had a change of heart, in that I want everybody to benefit from this app, even if they are using an outdated version of the Linux software. If the reader has the courage to perform this surgery, then the following is for you:

Continue reading How to patch ‘kdeconnect’ to work under Debian / Stretch.