Upgrade workstation from Opensuse Leap 15.1 to Leap 15.2

Two weeks ago I upgraded my main Linux-Workstation from Leap 15.1 to Leap 15.2. Some first impressions:

  • Leap 15.2 with KDE/X11 works relatively well. Some minor setting-options for the Plasma desktop have changed.
  • KDE/Wayland with Nvidia cards does not work – unusable for production.
  • No problems with QEMU based KVM- and LXC-container virtualization – my old Debian and Kali guest systems worked as expected on the Leap 15.2-host. No problems with multi-screen configurations of the guests with remote-viewer either.
  • Unexpected high power consumption of the Nvidia card – it has increased by about 5% to 8%. I am not sure whether this is a KDE or a driver problem.
  • The usual suspects for problems during the upgrade are the Nvidia drivers, Pulseaudio, VMware and this time – to my big surprise – CUPS.
  • You may have to change/reset some KDE config and rc-files in your home-directory – especially for the plasma desktop itself.
  • Chromium showed some glitches.

I shortly describe the upgrade process and some obstacles I had to overcome.

Basic upgrade process

I always prepare for a quick restoration of my running system configuration (here: Leap 15.1). Ahead of any upgrade activity, I therefore create a backup of my Leap 15.1 “/”-filesystem on an external drive and in addition create another copy in a target partition on one of my bootable disks. I use the “dd“-command for both purposes. As all productive application and development data as mails, project documents, PHP- and Python modules are on independent partitions or on network locations anyway, the risk of running into major problems afterwards is relatively small. In addition I comment certain critical entries in the “/etc/fstab” out.
In case of a major disaster a recovery can be achieved very quickly by just re-copying the copy of the Leap 15.1 partition back to its original place.

Regarding the backup of the “/”-filesystem to an external disk you have the choice between creating a copy of a partition and creating a (zipped) file. See e.g.:
I just made simple partition copies. Regarding the blocksize “bs” option of “dd” I am very generous with SSDs; I use a size like bs=1M or bs=4M to get a reasonable performance. When copying around 100 GB you probably do not want to wait for an hour :-). E.g.:

dd if=/dev/sdg1 of=/dev/sdh5 bs=4M status=progress

Warning 1:

If you copy your partition with “/”-filesystem into another partition, then the target partition must at least have the size of the original one. Really take care of this point! I always try to achieve the exact same size with a partition tool (gparted or YaST partitioner).

Warning 2:

Do not forget to change the UUID of the partition’s copy if the target partition resides on an internal disk; you should never have two filesystems with the same UUID on a system! But write down the original UUID at a safe place. Use “uuidgen
” and the “tune2fs -U” commands to change the copied filesystem’s UUID, afterwards.

See: how-to-change-filesystem-uuid-2-same-uuid

And: In case of an emergency restoration, i.e. after having copied the backup filesystem into its old position, you, of course, have to change the UUID back to the old one.

Why are these UUID-precautions required?
Because of your boot-loader – probably Grub2. Depending on its configuration (and some other system settings) it will probably have created entries in the “/boot/grub2/grub.cfg” which refer to the UUIDs of the bootable partitions. And if such a UUID-reference cannot be resolved in a unique way you may in the best case boot a system you did not want to boot, but you may also experience worse conflicts. Now, you may ask:

What is the copy on the same or another internal hard disk good for anyway?
I create the copy on my main SSD (or another internal disk) not only for restoration purposes, but also for the purpose of transforming it into a fully bootable filesystem at its new position later on – i.e. after the upgrade. I shall return this point in an extra section below.

Upgrade process

After the backup procedures I followed the guideline of the Brasilian Linux Kamarada for the upgrade; see

Their way of upgrading Opnesuse systems is straight-forward and well-tested. I also liked their recent inclusion of the “releasever“-variable …

I tend to use multiple repositories besides the standard upgrade repository of Opensuse. Therefore, I had to delete quite an amount of repositories following the Kamarada recipe. If you are in the same position, you should make a screenshot of the repository-configuration in YaST to be able to reconfigure them after the upgrade. During the upgrade zypper may recognize many packages for which it has to change the repository. It is a bit of an ordeal to answer to all of the related questions, but I recommend to follow the questions with focused concentration: The order of offered alternatives may change!

Hint: Take care of sufficient filesystem-space! The download of new packages requires extra space during the upgrade period – and usually also the total size of used disk space after an upgrade typically tends to grow somewhat. Therefore: Have at least 20GB available on your “/”-filesystem. (LVM is your friend – if you use(d) it …).

After the upgrade you have to reboot (init 6). If your graphics card is from Nvidia you probably will find yourself on some console terminal and not at a desktop-manager-login (e.g. sddm or gdm3) at the end of the boot process. We must install the (new) Nvidia drivers afterwards.

Nvidia re-setup

There are at least two ways of installing Nvidia-drivers on an Opensuse-system: 1) Directly, i.e. by a manual installation with the help of of the downloaded driver installation scripts. 2) With the help of YaST and the Nvidia community repository. I have used the latter option during the last 2 years. Either way you probably prohibited loading the Opensource Nouveau driver already at some point in the past – e.g. by blacklisting the related kernel module in some of the files in “/etc/modprobe.d”. If not – it is time to do so now.

When you rebooted after the Leap 15.2 upgrade the old Nvidia modules did not work as they were not compiled for the new kernel which was installed during the upgrade. So, from the console login, which you hopefully have reached, you need to invoke YaST in ASCII-mode, activate the
Nvidia community repository and reinstall the proprietary Nvidia drivers from there. In my case the packages

nvidia-computeG05, nvidia-gfxG05-kmp-default, nvidia-glG05, x11-video-nvidiaG05

A compilation is done automatically during this update.
Hint: I also suggest to issue “mkinitrd” immediately after the driver installation to be on the safe side regarding the “initramfs”-phase of the boot-process.
This worked pretty well in may case. After a reboot I got to my SDDM-login screen afterwards. My standard X11-based graphical KDE Plasma desktop started smoothly afterwards. I also tested the functionality of my Cuda installation for Keras and Tensorflow2 – worked perfectly.

Increased idle power consumption of the graphics card on a running KDE plasma desktop (Version 5.18)
A unwelcome surprise regarding Nvidia was the following: When watching the power consumption of my graphics card with

watch -n0.1 nvidia-smi

I saw a rise in the average consumption.
An average value of the GPU load (with “Force Composition Pipeline” activated on all my 3 screens) now had a value of 15%; on my old Leap 15.1 it was below 10%. All with having set the Powermizer mode to “Adaptive” (via (nvidia-settings). I fiddled a bit around with some Nvidia settings – but found no real solution, yet. When I changed a desktop theme (with the help of “systemsettings5”) I observed a drop of power consumption to 11% – but after some movement of windows across my 3 screens it settles again at 15% – quite independent of style and desktop settings. At least with an OpenGL-compositor activated (systemsettings5 >> “screen … >> compositor”. Choosing “Xrender” leads to a drop of GPU-consumption to 9%.

What brought me down a bit to 12% with an activated OpenGL-compositor (OpenGL2 or OpenGL3.1) was to deactivate keeping window-previews:

I did not experience any real disadvantages by doing so. On Leap 15.1 the average consumption with a driver a bit older was still lower by 4% to 5%. We talk about 2 Watt here, but still I do not like such unexpected changes. I do not know whose fault this is – KDE’s or Nvidia’s. We shall see what happens with the next driver version ….

Reconfigure KDE settings

The screen order on my Plasma 5.18 desktop was OK. No screen-tearing (see: Opensuse, KDE Plasma, X11, Nvidia – stop video and screen tearing); my old “xorg.conf“-settings were respected and active.

However, when trying to change design- and plasma-style-settings via “systemsettings5” a click on the “plasma-style”-icon led to a window crash and a Plasma error. This is usually a sign that something is wrong with the KDE configuration files:

Because the KDE setting- and configuration files in the home-directory survive the upgrade untouched some may not be compatible with the new KDE version.

I do not know about an easy way to find out which of the files are to be recreated. My standard way is to make a copy of the “~/.config-directory (with a new suitable name), delete the original directory, wait until it is automatically created again (with new default settings). We
make a copy of this new default-“.config” version (with a unique name), too, and then copy the original version into its standard place again. In the end we have 3 “.config”- directories with different names – one in place with the user’s original settings, one with the new default settings and one with the original settings as “.config”.
Then I overwrite files in the “.config”-file with the new default files, at least those for which I suspect some problems – starting with the plasma-specific “plasma…..rc”-files, then the “systemsettingrc”, then “kwinrc”. Thus, the problems with “plasma-style”-settings could be resolved quickly.

I also got some problems with a standard activation of the OpenGL-compositor at the start of the plasma desktop. A change of the respective settings in the “kwinrc”-file helped – especially “Enabled=True”:


Pulseaudio [PA]

A major frustration came up when I tried to start Clementine and listen to some songs – all my PA-settings were gone with the exception of the PA-LADSPA-equalizer. This had partially to do with changes in the Phonon-settings – now to be found under “systemsettings5 >> Audio“. I had to turn off my onboard HD sound card, activate my mainly used Xonar D2X explicitly and also deactivate an existing XFI-Card, too.

The dialog for setting the KDE/Phonon “standard device” have changed once again :-(. You cannot choose priorities for different sources (audio, video, …) any longer. Simplification? I hate this new KDE politics of taking more and more configuration options away from the standard user. I had to make the equalizer the “standard device” in the new dialog to direct all streams (from browsers and players) through this device.

Compare this to the settings in Leap 15.1; see KDE, Pulseaudio and Browsers – make the LADSPA equalizer the default sink.
In addition: We cannot play test sounds for the various sinks any more. This does no longer work in “YaST Audio” either … I do not call such things progress.

With PA activated “pavucontrol” serves as my primary mixer. It worked more or less as expected though some functionality has been removed there, too. E.g. the ability to remove some input channels completely. Another stupid thing which happens now regarding the default channel for volume adjustment via kmix is now that you may choose “Simultaneous output ….” – but volume controls will affect the Xonar channels, too – at least as long as no device uses the equalizer ….

It took some fiddling until I got back most of my old functionality and sound quality. I found again that its worth to reduce the Clementine input in pavucontrol down to 80% to avoid some oversteering and sound-distortion. Do not forget to set the default channel for sound control with kmix to “Simultaneous output …” for your multi-channel soundcard!

One can in addition install and activate the XFCE-mixer, which basically is a graphical frontend to an alsa mixer. This allows additional shifts of the different channels against each other – performed after pulseaudio’s own mixer settings, namely those of “pavucontrol”.

A major problem with sound and the onboard card:
For some reason a switch from the graphical terminal to a console terminal (by “Ctrl Alt F3”) automatically
activates an Nvidia HDMI stereo device on my system now. It comes up again even if I explicitly deactivated it in the KDE or PA audio settings. I have no solution for this, yet. It affects, however, at least a running Chromium (see below) – and leads to a restart of desktop effects when I return to the graphical session. I get a corresponding explicit message from Plasma ….

VMware – a yearly game of money …

VMware Workstation 15.5 Pro does not work on a Leap 15.2 host without special prerequisites. See e.g.:

However, WS Pro 16.0 does. I upgraded to this version. My Win 10 guests felt a bit more sluggish than with WS 15.5. But this may also have to do with a subsequent Upgrade of Win 10 to the 2004 version.

By the way: Note that VMware wants you to pay extra maintenance support, if you order it from SW resellers – at least here in Germany. The cheapest choice was to order it directly from the VMware shop. Do we like such anti-competition monopoly and customer control measures? No, we do not like it => time to get Windows 10 guests running on KVM machines … and to forget VMware for the future. See:

Hint: Be a bit reluctant with changing the HW compatibility of your VMware virtual machine for two reasons: You may want the virtual image to continue running in your old 15.1 implementation, too – until you feel that Leap 15.2 is stable enough. Second reason: Changing too much of HW settings may lead to a reactivation of your Windows license key.

CUPS bug – reconfigure printers – use the CUPS packages from the printing repository

I have two printers in my network. They can be addressed both by a local configuration and via a cups server in the net, which offers a variety of queues.
The reconfiguration of the local settings were a piece of cake with YaST. The updated HP-drivers simply worked.
However, printing from my system via a CUPS server in the net and its queues did not work any more. In contrast to all previous upgrades of at least the last 4 years :-(.
It took me a while to find out that this is due to a major bug in the present CUPS version delivered by the standard Update repository of Opensuse. Use the CUPS version > 2.3.0 from the “Printing repository“.
Then your server based queues will work again!

Chromium: Problems with HW acceleration / sound from Chromium does not get upmixed on a multichannel sound card

I had some problems with Chromium. Maybe I had them already before, but I noticed them now:
I had to refrain from HW-acceleration: Whenever I changed to one of the console terminals (e.g. Ctrl-Alt-F2) and returned to the graphical terminal the Chromium user interface got totally destroyed. Not funny when you were editing a blog :-(.
In addition: Chromium sound does not get upmixed completely – the probable reason is that Chromium supports real 7.1 channel sound these days. So, stereo may remain stereo or only gets upmixed by some special soundcard setting to 4.0, 6.0 – but not by PA. Despite such
settings on my Xonar card, I had some disturbing experiences: When changing to a console terminal and back to the graphical one, the upmixing changed from 4.0 to 2.0 …. :-(. When I rebooted afterwards, the 4.0 upmixing was there again. The whole effect probably was due to an automatic activation of some onboard/oncard Nvidia HDMI sound channels during the switch to the console terminals.

Firefox sound, however, which sends a pure stereo signal to the system as, gets properly upmixed by PA to 7.1 sound and this remains stable during switches between console and graphical terminals. So, for the time being, I do not use chromium for TV streaming any longer. Maybe the Chromium developers should have a talk with the PA developer …. It seems to be a difficult problem to me – you would have to analyze that only stereo sound is coming despite a 8 channel signal. A simple workaround would be that we get a switch in the chromium browser which allows to set its operation from multichannel to stereo, only.

For those who like to experiment with “pactl” commands (like “pactl list sinks” as standard user) I would like to draw your attention to work others ave done regarding PA and upmixing:

It should be possible to write two scripts one activating a certain upmixing with pactl commands and one deactivating it again. But my time is so limited that I haven’t tried it myself, yet.

KDE Plasma, Nvidia and Wayland do not work

As with Leap 15.1, KDE and Wayland lead to a direct crash on my workstation with Nividia graphics. The system freezes. You have to enforce a reset of your PC and start a reboot. However, on a laptop with a i915 Intel driver for a CPU integrated graphics Wayland works. So, we have a clear Nvidia topic here.

After the upgrade: Make the copy of our original partition of Leap 15.1 a bootable one

If you had copied your original Leap 15.1 partition into another partition on your hard disk you may want to make it a bootable fully functional system offered as an entry in the Grub2 menu. This requires some additional efforts.

Firstly, you have to change all references to the modified UUID in the internal boot-relevant files of the moved filesystem – i.e. in the “/etc/fstab”  AND  in the “/boot/grub2/grub.cfgthere on the Leap 15.1-partition. For this purpose you must mount the copied Leap 15.1 partition on your running Leap 15.2 system and edit the entries in both files of the mounted Leap 15.1 filesystem very carefully with respect to the changed UUID (see the sections on backups above). Take care that you do not change the files on the running Leap 15.2 system. And, please, make copies of both files before you change them! You may need the original contents.

Instead ofchnaging entries in the “/boot/grub2/grub.cfg” of the Leap 15.1 copy you can also rename the “/boot/grub2/grub.conf” on the Leap 15.1 partition to something like “grub.conf_orig” (you want to keep the contents!). This gives the grub “os-prober” on you Leap 15.2 installation a chance to create correct entries regarding the address of the partition.

Then we remove the “/boot/grub2/grub.cfg” in the Leap 15.2 installation and run “grub2-mkconfig -o /boot/grub2/grub.cfg” again to give the os-prober there a chance to create valid entries. Please, cou check these entries first before you install the grub loader from your running Leap 15.2 again! If you find correct UUID or other references to the partition the you can reinstall the bootloader. I always do this with YaST. Afterwards you should be able to boot both your new Leap 15.2 and your old 15.1 installation a respective entries in the Grub2 menu. Thus we have our old Leap 15.1
installation available for comparisons.


An upgrade of a Linux workstation from Opensuse Leap 15.1 to Leap 15.2 brought no major problems with it. One remarkable exception is a bug in the CUPS package – for which you find a solution in form of a newer package in another Suse repository. The fact that Wayland does not work with KDE on Nvidia graphics came not unexpected – although I think its a shame for Nvidia. The same could be said about the increased power consumption of the Nvidia card.

Have fun with Leap 15.2.

KDE, Pulseaudio and Browsers – make the LADSPA equalizer the default sink

During these days of Covid-19, home-office and lock-downs browsers and other Internet streaming tools as VLC become important personal gates to the world. When streaming videos or songs a user, of course, wants to hear some sound. No problem with Linux – Alsa helped you already decades ago. But things used to become a bit complicated if you wanted to direct the output of multiple sound-sources through a global equalizer of your Linux desktop environment (in my case preferably KDE). An equalizer may help to compensate deficits of cheap speakers or hearing problems of elderly persons as me. Well, if you found a global desktop equalizer at all. With KDE, no chance – it always was a strange policy of the KDE-people to assume that an equalizer is none of their responsibilities. So, a standard Linux user depended on application specific equalizers – which at least many Linux sound and video players offered. But what about browsers?

This is, where “Pulseaudio” and the related “Ladspa” based equalizer really were of help to a common user. As a matter of fact, I have never been a real friend of “Pulseaudio” [PA]; you can find some critical posts regarding PA in this blog. However, I gladly admit that Pulseaudio and its control interfaces have become substantially better with the years. At some point in the past PA started to work reasonably well even with multi-channel soundcards. It is now also much better integrated with KDE’s “Phonon” system than some years ago. Today, you can define e.g. a central volume control without destroying the relative volume ratios of different output channels of a sound card. And: We have a well integrated equalizer as a desktop-wide, global tool to improve the sound quality. So, why a post about it?

A problem with (automatically) changing streams and an assignment to a default sink

A problem with KDE and Pulseaudio in the past was the following: Only some applications (as e.g. “Clementine) ” gave/give the user a chance to specify a sink of the sound environment to which the sound output of the application is transferred for further processing.

A sound sink is a kind of sound module which accepts a sound stream as input, processes it and may send an output to other processing modules or an amplifier. On KDE you may find some available sinks for your sound card or cards under “system-settings >> Multimedia”. An important sink in our present context is the PA equalizer. See https://doc.qt.io/archives/qt-4.8/phonon-overview.html for the inclusion of media objects and sinks into a sound flow model (“graphs”) for KDE.

However, a lot of applications as e.g. browsers do not offer any settings to modify the primary sound sink. Instead they address a “default sink” of the system. What the “default sink” was, was either non-transparent to the user, or some related settings within your KDE desktop were just ignored, or you had to dive deep into the unhandy Alsa and the PA-configuration options. This led to major inconveniences for normal users:

When a new sound stream was activated a default sound sink was chosen by many applications which often did not correspond to the preferred one – namely the equalizer.

This problem could only partially be overcome by using “pavucontrol”, a PA-tool to control volume settings on channels and sinks in the system. “pavucontrol”actually allowed and allows the user to assign sinks to running applications and their sound streams. However, when the application switched from one stream to another – e.g. automatically in a media-player with a list of songs or on the web (youtube changing videos) – then the newly selected stream fell back to the default sink. Driving the user nuts ….

Setting of the default sink for the KDE desktop

nI use Opensuse Leap 15.1/2 with KDE as my main working environment (besides Debian and Kali with Gnome 🙂 ). By chance I recently found something which did not work for me in previous installations. In KDE we have a specific sound system – “Phonon” – which allows the user to organize the priority of “devices” (sinks) for certain kinds of applications. In my case you see the settings for “music” applications:

You see that I have 2 sound cards available – but to make things simpler I deactivated one of them for this blog post. The first device listed is the PA’s LADSPA equalizer:

It got the highest priority for music streams – more precisely for applications which follow the Qt/Phonon-API-rules when playing music streams. But, what about browsers (FF, Chromium, Opera, …), what about applications designed for Gnome and GTK3? You often can direct them to use PA, but what does PA respect as a default sink in a KDE environment with Phonon?

Well the simple “trick” which I found working recently is to set the priorities for all audio in KDE’s Phonon-settings:

Then we get the following PA-settings (install and start the pulseaudio-manager application “paman”):

This is what we need! And this setting is (now) respected by browsers and other applications that seek a default sink.

So: KDE, Pulseaudio and Phonon settings actually give a common KDE user the chance to direct all sound through the Ladspa equalizer as a default sink.

If your media-player offers its own equalizer you can of course combine both equalizers.

By the way: Common volume control

In the above picture on Phonon settings the sink “Simultaneous output to …” directs multiple sound sources to one or multiple sound devices. As we direct all sound through the equalizer first, we give the “Simultaneous output …“-device second priority.

We can use it for a common volume control in KDE’s Kmix: If you right-click on the Kmix symbol or open it you get an option to choose the main output channel :

Now, this setting assigns the desktop’s global volume control to this sink – which leaves all other volume settings, e.g. for the relative volumes of the sound-card channels, untouched:

You may find that this settings is transported to the sound control keys of a keyboard with a media control bar (e.g. on a Cherry keyboard).


With the help of KDE’s system-settings and Pulseaudio we can direct the output of all audio applications through a desktop wide equalizer, which we define by Phonon settings as a default sink. This is simply done by giving PA’s LADSPA equalizer the highest priority for all audio. You do not need to dive into PA configuration depths or the command line for changing PA’s device and sink graphs for sound flows.
The “Simultaneous output ….” device (or sink) allows for a global volume control which respects other volume settings controlled e.g. via PA’s “pavucontrol”.

Remote Desktop für Debian 8 mit X2Go auf Strato-V-Servern

In unserer Firma fallen z.Z. mehrere technische Schritte an, die wir parallel abwickeln müssen:

So stellen wir einerseits zwei Opensuse-Leap-Server für einen Kunden auf Debian-8-basierte vServer beim Hoster Strato um. Zeitgleich ersetzen wir das von uns unter Eclipse genutzte Versionsverwaltungssystem SVN durch Git und binden u.a. auch dabei einen der gehosteten vServer ein.

Damit wir und unser Kunde auf dem vServer

  • das dortige Git-Server-Repository besser kontrollieren und verfolgen können,
  • gelegentlich Branches anlegen und Merge-Aktionen durchführen können,

sollen auf dem vServer auch graphische GIT-Frontends zum Einsatz kommen. Z.B. “cola-git”, “qgit”, “giggle”. Ziel ist u.a. die Ansicht solcher Graphen wie in der nachfolgenden Abbildung:

Obwohl die Anwendung am Server läuft, wollen wir den Output natürlich auf dem Desktop unserer Arbeitsplatz-PCs oder denen des Kunden ansehen können.

So stellte sich uns also die Frage, wie man am schnellsten zu einem performanten graphischen Remote-Desktop für ein gehostetes “headless” System, also für ein System ohne echte eigene Grafik-Ressourcen, kommt. In unserem Fall zeigte sich, dass X2GO die richtige Wahl war und ist.

Nomenklatur – Remote Hosts, X-Server, X-Clients

Wir verwenden im weiteren Text die nachfolgende Nomenklatur, um Missverständnisse zu vermeiden. Bekanntermaßen ist ja beim X11-Protokoll die laufende Grafik-Anwendung ein “X-Client”. Das Umsetzungsprogramm, das aus den Grafik-Befehlen des Clients schließlich Fenster und grafische Inhalte auf den Bildschirm eines Linux-Desktops oder oder die Grafikstation eines Thin Client zaubert, ist hingegen der “X-Server”.

Die zuständigen Protokolle für den Datenaustausch zwischen X-Client und X-Server funktionieren auch über Netzwerke hinweg:

  • Als “Remote-Host” bezeichne ich den vServer bei Strato. Dort laufen dann Linux-Anwendungen, die grafischen Output im Rahmen ihres Benutzerinterfaces anbieten (in unserem Beispiel GIT-Anwendungen mit GUI).
  • Das Linux-System, von dem aus wir auf den vServer zugreifen, nenne ich “Arbeitsplatz-PC” oder kurz “PC”. Auf ihm läuft unter Linux selbstverständlich auch ein lokaler X-Server. Dieser dient wiederum einem Linux-Desktop – in meinem Fall KDE 5 – als technische Basis für die Integration grafischer Benutzerschnittstellen zu lokalen und entfernten Anwendungen.
  • Die graphischen Programme wie “qgit”, die auf dem vServer (=Remote-Host) laufen und ihren Output wie grafische Anweisungen einem lokalen oder über das Internet auch einem entfernten X-Server zuweisen, nennen wir “Remote X-Clients”.

Bzgl. möglicher Lösungen für Remote-Desktop-Darstellungen auf einem Arbeitsplatz-PC ist es nicht von vornherein klar, wo und in welcher Form ein X-Server zum Einsatz kommt. Natürlich läuft auf einem normalen Linux-PC ein X-Server für eine grafische Oberfläche; das schließt aber nicht aus, dass auch auf dem Remote-System ein X-Server aktiv ist.

Ein Remote-X-Client-Programm könnte also einerseits mit einem (headless) X-Server auf dem Remote-Host zusammenarbeiten. Er könnte andererseits aber auch direkt mit dem X-Server am Arbeitsplatz-PC über das Internet interagieren (z.B. über ssh -X oder die explizite Vorgabe eines entfernten X-Servers samt Screen über die Umgebungsvariable “DISPLAY”).

Funktionsweise von VNC vs. X2Go

Der Vollständigkeit halber werfen wir deshalb auch einen kurzen Blick auf Unterschiede in der typischen Funktionsweise von VNC und X2Go. Man beachte, dass in beiden Fällen “Server”-Komponenten auf dem Remote-Host und “Client”-Komponenten auf dem Arbeitsplatz-PC zum Einsatz kommen; das ist gerade umgekehrt wie bei den X11-Komponenten:

  • VNC: Auf dem Remote-Host kann theoretisch ein headless X-Server laufen, für dessen Implementierung ggf. die zu installierende Remote-Desktop-Umgebung (wie etwa ein VNC-Server-Modul) sorgen muss. Dessen Bilddaten-Output könnten dann über ein VNC-Programm abgegriffen und über das Internet an einen Arbeitsplatz-PC bei uns übertragen werden. Dort greift dann ein VNC-Client-Programm die Daten auf und blendet sie als lokaler X-Client über ein passendes Fenster in den grafischen Linux-Desktops des PCs ein.
  • X2Go: Unter X2Go läuft auf dem Remote-Host der sog. “X2Go-Server”. Der nutzt essentielle Teile des X11-Protokolls um Daten und Grafikanweisungen an den X-Server eines Arbeitsplatz-PCs zu übertragen. Dort koppelt allerdings ein zwischengeschalteter “X2Go-Client” an den X11-Server des Arbeitsplatz-PCs an. (Unter Windows Clients ist ein geeigneter X11-Server bereitzustellen!). Im Unterschied zu ” ssh -X” oder einem direkten Remote Zugriff auf einen X11-Server werden von den zwischengeschalteten X2Go-Komponenten zusätzlich Kompressionsalgorithmen und Caches exzessiv genutzt und der Statusabgleich zwischen X11-Server und X11-Client auf das notwendige Minimum reduziert.

In beiden Fällen müssen die VNC- oder X2Go-Client-Komponenten natürlich die Keyboard- und Mausinteraktionen mit den relevanten Fenstern am Arbeitsplatz-PC abfangen und an die X-Clients auf dem Remote-Host übertragen.

Ich gehe nachfolgend von klassischen X-Servern (und nicht Wayland) aus. Wayland ist meines Wissens nicht mit X2Go kompatibel.

SSH -X als Alternative ?

Natürlich habe ich auf unserem Strato-vServer erstmal eine direkte grafische Datenübertragung zwischen den X-Clients der vServer und meinem Arbeitsplatz-PC mittels “ssh -X” ausprobiert. Dabei wird der Grafik-Output der X-Remote-Clients (über das zwischengeschaltete Internet) direkt vom X-Server am Arbeitsplatz-PC behandelt. Aber Qgit, Giggle und Co. sind doch schon recht komplexe Anwendungen, die mit einem X-Server relativ häufig relativ viele Informationen austauschen müssen.

Ich war mit der Performance überhaupt nicht zufrieden. Das Arbeiten an sich erwies sich zwar nicht als unmöglich; aber bei verschiedenen Schritten treten doch spürbare Wartezeiten auf – u.a. beim Aufbau von Verzeichnis- und Strukturbäumen. Die Durchführung von Änderungen war dann nicht wirklich bequem, sprich nicht flüssig möglich. Mein Eindruck war: Es wird eine deutlich bessere Kompression und Pufferung der Daten benötigt.

Probleme mit VNC – und Einschränkungen bzgl. der Desktop-Umgebung

Ich dachte als Nächstes natürlich an klassische VNC-Anwendungen (https://de.wikipedia.org/ wiki/ Virtual_Network_Computing), mit deren Hilfe man einen echten Remote-Desktop realisiert.

In LANs hatte ich früher schon mal TurboVNC eingesetzt. Ich hatte das damals als recht performant empfunden. Sogar der Einsatz von VirtualGL für Remote-Hosts, die mit einer 3D-Grafik-Karte ausgestattet waren, war möglich. Nun braucht man für einen Strato vServer und GIT-Frontends natürlich kein VirtualGL. Aber TurboVNC war ja auch sonst ganz OK – zumindest unter älteren Opensuse-Systemen.

Dennoch habe ich den Einsatz von TurboVNC auf einem Strato-vServer mit Debian nach ein paar Experimenten abgebrochen. Unter Debian 8 gab es (fast erwartungsgemäß) Probleme mit Gnome 3 (trotz vorhandener Mesa-Bibliotheken). Gnome 3 ist (wie KDE 5 auch) von Haus aus für VNC problematisch, da 3D-Fähigkeiten der Umgebung vorausgesetzt werden. Bei mir klappte der Start des Desktops trotz vorhandener Mesa-Bibliotheken und des lokalen VMware-Grafiktreibers des Virtuozzo-Containers für den Strato-vServer nicht.

Auch eine kurze Recherche im Internet zeigte: Der Einsatz von Gnome erfordert unter klassischen VNC-Servern (und auch unter TurboVNC) einfach viel zu viele Klimmzüge. Wie funktionabel und performant dagegen der in Gnome integrierte VNC-Server “vino” ist, habe ich in meinem Frust dann nicht mehr ausprobiert.

KDE 4 unter Debian 8 ging zwar unter TurboVNC; ich bekam aber keine Veränderung der Auflösung jenseits 1024x768px am TurboVNC-Client auf dem Arbeitsplatz-System hin. Der Zeitaufwand für das Rumprobieren wurde mir dann irgendwann zu groß. Das hatte zwei Konsequenzen:

  • Als erstes reduzierte ich meine Anforderungen an eine Desktop-Umgebung kurzentschlossen auf LXDE und KDE4. Mit letzterem kennt sich auch unser Kunde in hinreichendem Maße aus.
  • Als zweites konzentrierte ich mich auf die von Debian im Standardumfang mitgelieferten VNC-Pakete: “tightvnc” und “vnc4server”.

Ein Kurztest der beiden VNC-Varianten überzeugte mich aber hinsichtlich der Performance mit KDE 4 nicht; besonders nicht der vnc4server. Mit LXDE konnte ich dagegen ganz gut arbeiten.

KDE 4 ist halt ein Desktop-Schwergewicht, das den X11-Server je nach Desktop-Gestaltung laufend belastet. Dabei ist zu bedenken, dass die meisten VNC-Systeme auf dem Remote-Linux-System einen laufenden (headless) X11-Server brauchen, dessen Bilddaten dann abgegriffen und an einen VNC-Client auf einem lokalen PC übertragen werden. Das ist vom logischen Prozess-Ablauf her gesehen ein Umweg, weil neben dem X11-Server noch eine Zwischenschicht auf dem Remote-System ausgeführt werden muss. Die Bilddaten auf dem lokalen PC müssen zudem wieder in einem Fenster auf dem lokalen X11-Server dargestellt werden.

X2Go als Alternative ?

Wenn es denn hinreichend schnell funktionieren würde, würde man deshalb als Linuxer eigentlich immer gerne direkt Remote-X11 über SSH einsetzen. Auf dem Remote-System – hier also dem vServer – liefen dann Anwendungen, die als X-Window-Client-Programme ihre Daten und graphischen Steuerbefehle (über einen SSH-Tunnel) direkt an den aktuell laufenden X11-Server auf meinem Arbeitsplatz-PC übertragen. In unserem LAN klappt das auch wunderbar – sogar mit der Übertragung von 3D-Grafik-Daten. Da reicht die Bandbreite schon in einem Gigabit-Netz zur schnellen Datenübertragung völlig aus. Das gilt aber leider nicht unbedingt für Remote-Systeme im Internet zu denen die Bandbreite in beide Richtungen begrenzt ist. (Zumindest bei mir).

Dann fiel mir ein: Eine hinsichtlich Kompression, Caching und X11-Server/Client-Abgleich optimierte Variante des X11-Protokolls über ein Netzwerkverbindungen lieferte doch das NX3-Nomachine-Protokoll; es bildet die Grundlage des Opensource Forks X2Go (siehe hierzu die Links weiter unten).

Ergebnis eines kurzen X2Go-Tests

Am Ostersamstag habe ich mir dann nach ein wenig Internet-Recherche (und zum Leidwesen meiner Frau) auch den X2Go-Server und X2Go-Client angesehen. Ergebnis: Ich bin nach wie vor begeistert! Stichpunkte sind:

  • Denkbar einfache Installation und Konfiguration. Einfache Integration von SSH-Schlüsseln. Einfache Einstellung unterschiedlicher Auflösungen.
  • Sehr gute, wirklich überzeugende Performanz!
  • Der Datenaustausch zwischen Remote-System und dem Arbeitsplatz-PC erfolgt von vornherein auf SSH-Basis.

Weitere erwähnenswerte Features, die die praktische Nutzung erleichtern, sind:

  • Copy/Paste zwischen nativen lokalen Fenstern des Arbeitsplatz-PCs und Fenstern des Remote-Desktops ist nahtlos möglich.
  • Freigabe lokaler Verzeichnisse: X2Go erlaubt vom Remote-Desktop aus auch einen Zugriff auf (dafür freigegebene) lokale Verzeichnispfade des Arbeitsplatz-PCs. Damit können Files auf dem Remote-Host z.B. in einem graphischen File-Manager zwischen den dortigen Verzeichnissen (des Hosts) und dem lokalen Verzeichnis des Arbeitsplatz-PCs verschoben/kopiert werden. Zur Wahrung der Sicherheit bei solchen Transaktionen gibt es die Option, den Datenaustausch über SSH getunnelt durchzuführen.
  • Mehrere Sitzungen gleichzeitig: Will man mehrere Sitzungen zu verschiedenen Servern gleichzeitig öffnen, so startet man auf dem lokalen PC mit “x2goclient &” einfach einen neuen Client. Auch zwei Sitzungen unter unterschiedlichen Benutzernamen zum gleichen Server sind möglich. Ebenso zwei Sitzungen mit derselben Remote-UID für verschiedene Desktops/Window-Manager – z.B. eine Sitzung mit LXDE und eine mit KDE für ein und denselben User auf demselben Remote-Host. X2Go-Client zeigt einem eine Liste laufender Sitzungen und fragt, was mit den laufenden Sitzungen passieren soll. Die lässt man weiterlaufen und wählt für die neue Sitzung die Option “Neu”. Die verschiedenen Remote-Sitzungen zum gleichen Remote-Host teilen sich dann aber natürlich dessen Netzwerk-Ressourcen. Die sind bei Stratos vServern durchaus begrenzt.
  • Seamless Mode: X2Go erlaubt anstelle der Anzeige eines kompletten Remote-Desktops theoretisch auch das Remote-Starten einer einzelnen Anwendung und deren Anzeige auf dem lokalen Desktop des Arbeitsplatz-PCs. (Seamless Mode; das Ganze entspricht dann in der klassischen SSH-Welt in etwa dem vorkonfigurierten Aufruf einer grafischen Remote-Applikation nach einem ssh -X.). Leider klappt das aber auf einem KDE5-Plasma-Desktop (s.u.) nicht wie erwartet.
  • Desktop-Sharing: X2Go bietet auch die Möglichkeit des Desktop-Sharings zwischen verschiedenen Nutzern an – das habe ich aber unter den Bedingungen eines vServers aber noch nicht ausprobiert. Ich gehe darauf in diesem Artikel auch nicht weiter ein.

Mit jedem dieser Punkte kann ja jeder mal selber herumexperimentieren. Siehe zur Thematik paralleler Sitzungen auch
https://gist.github.com/ ledeuns/ f0612fb43b967c129c88)

Bzgl. des Desktop-Sharings:
http://wiki.x2go.org/ doku.php/ doc:usage:desktop-sharing

Arbeitet man gleichzeitig unter derselben UID mit 2 getrennten Sessions – z.B. einer LXDE- und einer KDE-Sitzung – auf demselben Arbeitsplatz-PC, so können dabei interessante Effekte z.B. unter Libreoffice auftreten: Ist Libreoffice bereits auf einem der (Remote-)Desktops (z.B. dem KDE-Desktop) geöffnet, so wird ein nachfolgendes Libreoffice-Programm, das in einer parallel laufenden LXDE-Sitzung gestartet wird, trotzdem im KDE-Desktop angezeigt. Ansonsten läuft das Meiste aber normal und erwartungsgemäß.

Für mich war wirklich überraschend, dass neben meinen Git-GUIs auch stark grafiklastige Anwendungen wie Libre-Office Draw, Impress, Inkscape etc. gleichzeitig und sehr, sehr flüssig nutzbar waren. Aus meiner Sicht ist hier die Performance eines Terminal-Servers gegeben, die im wesentlichen nur durch die Netzanbindung des vServers ans Internet limitiert wird und im getesteten Umfang (4 parallele 1920×1200 Sitzungen) überhaupt nicht durch CPU/RAM des Virtuozzo Containers für unseren vServer [V30 bzw. V40, HP3PAR] begrenzt wurde.

Weil es so schön ist, nun eine Zusammenstellung der wichtigsten Hinweise zur Installation und Inbetriebnahme von X2Go, die ich bei dieser Gelegenheit im Internet aufgesammelt habe.

X2Go-Installation: Passende Repositories ziehen

Unter folgendem Link ist beschrieben, wo man die aktuellen Repositories mit X2Go-Komponenten für Debian 8 (64Bit) findet: http://wiki.x2go.org/ doku.php/ wiki:repositories:debian.

Man trägt dann die Repositories über folgende Zusatzzeilen in die Datei “/etc/apt/sources.list” ein:

root@myremotedebian:~# cat /etc/apt/sources.list
# See sources.list(5) for more information, especialy
# Remember that you can only use http, ftp or file URIs
# CDROMs are managed through the apt-cdrom tool.
deb ftp://ftp.stratoserver.net/pub/linux/debian/ jessie main contrib non-free
deb ftp://ftp.stratoserver.net/pub/linux/debian-security/ jessie/updates main contrib non-free

#ICH - 15.04.2017 - Repos for X2Go:
# -----------------------------------
#X2Go Repo
deb http://packages.x2go.org/debian jessie main
# X2Go Repository (sources of release builds)
deb-src http://packages.x2go.org/debian jessie main

Zur Sicherheit machen wir den zugehörigen Key verfügbar; als root:

root@myremotedebian:~ # apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E

Dann Update der Paket-Datenbank durchführen:

root@myremotedebian:~ # apt-get update

Nun – als Test – Installieren des Schlüssels über ein Paket aus dem X2Go-Repository:

root@myremotedebian:~ #  apt-get install x2go-keyring && apt-get update

Dann die Pakete x2goserver und x2goserver-xsession installieren:

root@myremotedebian:~ #  apt-get install x2goserver

Bei mir wurde x2goserver-xsession automatisch mit installiert. Falls das nicht der Fall sein sollte:

root@myremotedebian:~ #  apt-get install x2goserver-xsession

Man glaubt es vielleicht nicht – aber das war es im Prinzip serverseitig schon. Zumindest was X2Go anbelangt. Der Grund hierfür ist, dass der X2GO-Client (s.u.) eine SSH-Sitzung nutzt und im Zuge des SSH-Logins die nötigen Umgebungsvariablen setzt und erforderliche Programme auf dem Server für eine Remote-X-Sitzung startet.

LXDE und KDE 4 installieren

Sollte man LXDE oder KDE 4 unter Debian 8 noch nicht installiert haben, so ist dies über

root@myremotedebian:~ #  apt-get install lxde


root@myremotedebian:~ #  apt-get install kde-standard


Will man Remote-Audio nutzen, sollte man ggf. auf dem Remote-Host und auch auf dem Arbeitsplatz-PC Pulseaudio installieren. Für mich ist Sound irrelevant – und Pulseaudio kommt bei mir aus Prinzip nicht auf einen PC-Desktop. Aber das mag ja bei anderen anders sein … 🙂

Natürlich muss auf beiden Systemen SSH bereitstehen ..

Auf dem Debian 8 Remote-Host muss zwingend das Paket “openssh-server” installiert sein. Zudem sollte der Server aus Sicherheitsgründen so konfiguriert sein, dass der SSH-Port verlagert ist, sichere Kex-Algorithmen genutzt und eine Authentifizierung über asymmetrische Keys (hinreichender Länge) durchgeführt wird. Der Zugang sollte ferner durch eine Firewall und weitere Maßnahmen auf bestimmte Clients beschränkt werden. Ich gehe auf die SSH-Server-Konfiguration hier nicht weiter ein. Da wir es hier mit gehosteten Remote-Systemen zu tun haben, gehe ich davon aus, dass der zuständige Admin dieses Metier beherrscht.

Jedenfalls muss auf dem Server ein SSHD-Dämon laufen und bereit sein, Logins über einen in der Firewall für bestimmte Clients geöffneten Port entgegen zu nehmen. X2Go tunnelt später die gesamte Kommunikation zwischen Client und Server durch die SSH-Verbindung. Darum muss man sich nicht mehr selber kümmern; s.u.. Es ist übrigens nicht notwendig, für verschiedene Sitzungen auf ein und demselben Remote-Host mehrere unterschiedliche SSH-Ports zu öffnen.

Installation und Nutzung auf dem Arbeitsplatz-PC (X2Go-Client)

Bzgl. der Client-Installation gilt: Es sind passende Pakete für die Distribution zu finden, die man auf seinem Arbeitsplatz-PC einsetzt. Siehe für Hinweise
http://wiki.x2go.org/ doku.php/ doc:installation: x2goclient.

Ich beschreibe die Clientseite hier nur für einen Opensuse Leap 42.2 Client. Für Opensuse liegen die erforderlichen RPMs unter folgendem Repository:
repositories/X11:/RemoteDesktop:/ x2go/openSUSE_Leap_42.2/
Von dort installiert man mittels YaST etwa “x2goclient”, “pyhoca-gui”. Der Rest der benötigten Pakete wird dann über Abhängigkeiten nachgezogen:

Nun öffnet man auf seinem Client-PC den Client am Terminal etwa über:

ich@mytux:~> x2goclient &

Es öffnet sich initial eine Oberfläche, die die Anlage von sog. “Sitzungen” zu Remote-Hosts erlaubt; diese “Sitzungsvarianten” werden später im X2Go-Client-Fenster zur Auswahl angeboten.

Ich zeige nachfolgende die verschiedenen Konfigurationsdialoge für eine Sitzung (die ich “Dummy” genannt habe). Natürlich muss man die Eingabefelder mit den für seine eigene Situation passenden Daten ausfüllen.
Siehe für eine ausführliche Beschreibung des X2Go-Client-Setups zudem:
http://wiki.x2go.org/ doku.php/ doc:usage:x2goclient

Zunächst – und das ist das Wichtigste – müssen wir die Serververbindung einstellen:

Dann steht eine Konfiguration der Bandbreite der Verbindung an:

Wir wenden uns anschließend einer Konfiguration der Auflösung der Desktop-Darstellung zu:

Für erste Tests deaktivieren mal die Sound-Unterstützung:

Als letztes kann man konfigurieren, ob man bestimmte Verzeichnisse auf dem Arbeitsplatz-PCs für einen direkten Zugriff durch Remote_X-Client-Programme freigeben will. Tut man das, so sollte man in jedem Fall die zugehörige Option zur SSH-Port-Weiterleitung aktivieren.

Man kann all diese Konfigurationseinstellungen später über den Menüpunkt “Sitzung => Sitzungsverwaltung” nachbessern.


Hat man seine “Sitzung” konfiguriert, so steht diese im rechten Bereich des X2Go-Client-Fensters zur Aktivierung bereit.

Nach einem Doppelklick rückt die aktivierte Verbindung ins Zentrum der Anzeige; in unserem Fall öfnnet sich zudem ein kleines Dialogfenster, in dem wir die Passphrase für unseren SSH-Key eingeben müssen. Und nach wenigen Augenblicken/Sekunden öffnet sich schließlich das Fenster für unseren Remote-Desktop – hier mit LXDE :

Der aufmerksame Betrachter wird Qgit im linken Bildbereich entdeckt haben – hier für ein noch sehr langweiliges Test-Repository. Ich habe fast alle mir unter Linux bekannten Git-Clients ausprobiert – jeder läuft flüssig; fast wie lokal.

Das Ganze nun auch nochmal für einen Remote-KDE-Desktop:

Für 2 parallele Sitzungen zum gleichen Server muss man einfach zwei x2go-Clients öffnen und in einer zwischenzeitlichen Anzeige bereits geöffneter Sessions die Optionen so wählen, dass die bereits geöffnete Sitzung nicht unterbrochen werden soll, sondern dass eine neue Sitzung geöffnet werden soll.

Die nachfolgende Abbildung zeigt zwei parallel zu einem vServer unter Debian 8 geöffnete Sitzungen – eine unter LXDE, die andere unter KDE4:

Getestet habe ich das Ganze mit einer vDSL-Leitung, aber auch einer ADSL-16MBit-Leitung – auch bei letzterer sind mehrere gleichzeitige Sitzungen kein Problem !

Wo so viel Licht ist, gibt es aber auch Schatten. Daher sei abschließend noch auf 2 Punkte hingewiesen, die in der Praxis relevant werden können.

Problematischer Punkt bzgl. der Soundunterstützung und Firefox unter X2Go

Im Prinzip kann X2Go (angeblich) Audio-Daten übertragen. Allerdings über einen Pulseaudio-Server. Den habe ich bei mir allerdings wegen vieler Probleme mit einer Xonar D2X und einer X-Fi nicht am Laufen. Ich benutze ausschließlich plain Alsa – das funktioniert zuverlässig und erlaubt das Umschiffen vieler Pulseaudio-Probleme. Fakt ist jedenfalls, dass es mit einer aktivierten Sound-Unterstützung für Pulseaudio unter X2Go und einem remote gestarteten Firefox ESR erhebliche Probleme gibt:

Alle Menüpunkte der Firefox-Oberfläche reagieren nicht mehr bzw. mit erheblicher (!) Zeitverzögerung auf Maus-Klicks im X2GO-Client. Firefox wirkt wie eingefroren; das stimmt aber nicht – die Reaktion kommt nur mit Minuten Verzögerung. Das ist u.a. hier beschrieben:
http://thescriptingadmin.blogspot.de/ 2015/09/ firefox-freezing-on-linux-x2go.html
https://debianforum.de/ forum/ viewtopic.php?t=164257

Wer immer daran Schuld hat. Da das mit anderen GTK-Anwendungen als FF nicht passiert, tippe ich darauf, dass FF bei installiertem PA auch erwartet, dass PA reagiert. Was remote evtl. ein Problem darstellt, wenn dort PA ggf. gar nicht installiert ist.

Ich habe mangels Interesse nicht getestet, ob dieser Fehler u.U. daran liegt, dass auf meinem Arbeitsplatz PA nicht aktiv ist. Lasst mir gerne eine Email zukommen, wenn ihr dazu was wisst. Ich persönlich verzichte aber lieber auf Sound von einer Remote-X2Go-Quelle, als mich mit PA herumzuschlagen. Vielleicht probiere ich das später mal auf einem Laptop. Falls ihr auch auf dieses Problem mit FF stoßen solltet und bereit seid, auf Sound vom X2go-Server zu verzichten, gilt Folgendes:

Wichtiger Hinweis zu einem Problem mit Firefox und dem X2Go-Client unter Linux:

Soundunterstützung im X2Go-Client abschalten (Reiter “Medien” unter den Einstellungen) oder aber auf einen anderen Soundserver umschalten. Bei mir funktionierte ein Remote-Firefox FF im X2Go-Desktop-Fenster nach einer Abschaltung der Soundunterstützung durch Pulseaudio problemfrei.

X2Go Seamless Mode funktioniert nicht unter KDE5

X2Go bietet zwar im Prinzip die Möglichkeit an, Remote X-Anwendungen auch als singuläre Applikationen zu starten, die direkt als Fenster (also ohne umgebenden Remote-Desktop) in den Desktop des Arbeitsplatz-PCs eingeblendet werden.

Hierzu konfiguriert man eine entsprechende Sitzung, z.B. nur für “qgit”, wie folgt:

Danach startet die angegebene Applikation im seamless Fenstermode. Das klappt auch mit einem Terminal wie etwa “lxterminal” (“/usr/bin/lxterminal”). Von der Kommandozeile aus, kann man dann weitere Anwendungen wie “qgit” starten, die dann wiederum als Einzelapplikation auf dem lokalen Desktop angezeigt werden.

Leider täuscht aber der erste positive Eindruck; unter KDE5 sind die zugehörigen Fenster für komplexere Anwendungen als ein Terminal in ihrer Größe leider nicht veränderbar. Das macht den Einsatz des “Seamless Mode” für KDE5 am Arbeitsplatz-PC in der Praxis unbrauchbar. Der seamless Mode funktioniert aber sehr wohl unter einem LXDE-Desktop am Arbeitsplatz-PC.


X2Go bietet eine einfache zu handhabende Möglichkeit, performant von einem Linux-Arbeitsplatz-PC auf grafische Anwendungen eines Remote-Strato-vServers zuzugreifen. Die Linux-Installation des vServers muss lediglich einen LXDE- oder KDE4-Desktop unterstützen. (Desktops unter XFCE, Mate, LXQT habe ich nicht getestet; das sollte aber auch alles funktionieren).

Als einzige Wermutstropfen bleiben, dass der Seamless Mode auf einem KDE5-Target-Desktop des Arbeitsplatz-PCs nicht richtig funktioniert und dass im Moment weder native KDE5- noch Gnome3-Desktops des vServers unterstützt werden. Angeblich wird daran aber bereits von den X2Go-Entwicklern gearbeitet; wir freuen uns auf entsprechende neue X2Go-Versionen.


Was ist X2GO?
http://www.mn.uio.no/geo/ english/services/it/help/ using-linux/x2go.html
https://de.wikipedia.org/ wiki/ NX_NoMachine
https://serverfault.com/ questions/227542/ what-alternatives-to-vnc-are-there-for-linux

Details zum Server
http://wiki.x2go.org/doku.php/wiki: advanced: x2goserver-in-detail

Installation von X2Go
http://wiki.x2go.org/doku.php/ wiki:repositories:debian
http://wiki.x2go.org/ doku.php/ doc:installation:x2goserver
http://www.linux-community.de/Internal/Artikel/ Print-Artikel/LinuxUser/2011/07/X2go-Terminalserver-auch-fuer-den-Hausgebrauch
https://mun-steiner.de/ wordpress/ index.php/ linux/ x2go-mit-ssh/

Installation und Übersicht über ein paar Bugs
http://www.mn.uio.no/geo/english/ services/it/help/ using-linux/x2go.html

VNC : Benötigt VNC einen X-Server?
https://unix.stackexchange.com/ questions/ 129432/vnc-server-without-x-window-system