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

 

Problems Getting Synaptic To Work, On My Google Pixel C Tablet

One of the facts which I’ve blogged about was, that I had used an Android app (that does not require root) in order to install a Linux Guest System, on my Google Pixel C Tablet. The version of Linux it’s subscribed to is Debian 10 / Buster. And, the CPU of that tablet is an ARM-64. One of the considerations which need to be made, when setting up this Guest System, is that both RAM and Storage are scarce, the latter because the entire Linux Guest System consists of Application Data, belonging to this one Android app.

One idea which I was pursuing until last night was, to get the Synaptic GUI to work, where the ‘apt-get’ command-line does already work. Either would provide the main way to install software. But the GUI is much nicer, in allowing searches for packages to take place, instead of just package-names being burped on the command-line (blindly), and also, displaying lengthy descriptions of the packages first.

The way I’d need to launch Synaptic is like so:

 


$ xhost +
$ sudo synaptic

 

The first bug which needs to be dealt with, is This Bug. But, even when that bug has been dealt with, there are more problems facing the use of Synaptic under Debian / Buster. And they all have to do with the fact that the new Synaptic can no longer be used effectively, to search for packages.

First off, in order for the Search Field to display in the toolbar of Synaptic, one needs to install the following:

 


$ sudo apt-get install apt-xapian-index
$ sudo update-apt-xapian-index

 

This is a process that takes about an hour to complete, and when it has completed, its only result is that the Search Field displays in the Tool-Bar of Synaptic. By itself, this Search Field is useless because it only acts as a filter, on the actual search results, that we get when clicking on the Search Button. And, this process is not optimal in a ‘proot’ed environment, on an Android tablet, because the fully built database takes up more than 200MB.

The actual Search Button has been rendered useless. When told to search both the names and descriptions of packages, the resulting search takes about 20 minutes to complete, and does not become faster the second time, even when we have ‘apt-xapian-index’ installed and set up. The only other possibility is, only to search the names of packages, which defeats the entire purpose of using Synaptic.

I once had a (Debian 8 / Jessie) Linux Guest System installed the same way, on a Samsung Galaxy Tab S, first generation, and the searches within Synaptic were quick and painless.

(Updated 9/07/2019, 15h15 … )

Continue reading Problems Getting Synaptic To Work, On My Google Pixel C Tablet

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).