Klaus Knopper answers your Linux questions
Ask Klaus

Klaus looks at problems with VNC-based shared desktops and a frozen screen with an Nvidia card.
VNC-Based Shared Desktop
Hi Klaus: I was asked to provide a generic method of remote desktop sharing on a fairly complex environment. The servers in this environment are running Fedora 19/20 with LightDM as the desktop manager and a variety of desktop environments available on each server (Gnome/KDE/LXDE/Xfce/Openbox) with TigerVNC as the VNC server/client.
I need each VNC session to go through system authentication via LightDM (I skip VNC passwords by setting the Xvnc option -SecurityTypes None
), but I want to be able to connect to existing sessions. I've tried to tackle this problem two different ways.
1. I managed to set up a shared Xvnc inetd service, but once the user goes through the initial LightDM authentication, any additional connections log in to the existing session WITHOUT any authentication (i.e., I can't get them to authenticate via LightDM). This, of course, is completely unacceptable from a security standpoint. I can work around the problem by forcing the VNC server to accept connections from localhost only and then from the client side use SSH local port forwarding to the VNC session, thus forcing people to authenticate via SSH, but I'm looking for a solution rather than a workaround.
2. Conversely, I managed to set up LightDM to handle all VNC connection requests by un-remarking the [VNCServer]
section in /etc/lightdm/lightdm.conf
, but each request starts a new session. I cannot get any session to be shared.
Your assistance will be greatly appreciated. Thanks, Shiron
Hopefully, I understood your request correctly, so let me explain first what happened in your two scenarios.
In your first experiment, you started the VNC server via inetd, which means that inetd will:
1. Open a port and listen to it.
2. Once a client connects, the Xvnc server is started, then LightDM running on the Xvnc server will ask for login/password as usual, and the user can log in.
3. If a second client connects, it will just be attached to the same port, same Xvnc server, and same running session, which explains what you experienced: You just get a copy of the same session with no password asked (because a user is already logged in to the running Xvnc).
What you really want is a choice of starting a new Xvnc server session or attaching to a running one using the user credentials. Unfortunately, this cannot be done by running a single Xvnc instance. Using just one network port and just running one Xvnc server will not work if you want multiple users logging in.
You will need a session manager as a gateway. It will either start a new Xvnc on a new, free local port every time a connection is made to the session manager, or it will attach the user to an already running session, which needs to be listed in the session manager's choice, asking for authentication. Here, you could add a password for Xvnc itself so that the user will be asked for her login+password when logging in the first time, and then for a "shared connection" password that will allow others to connect to the same session. This way, the login is protected, as well as access to the running Xvnc server.
So, your second experiment using LightDM as session manager for Xvnc sessions is already going in the right direction. However, a configuration with LightDM as a session manager for VNC sessions, which keeps track of all users running sessions in a list, may be more complex than necessary.
Maybe xrdp using the RDP protocol (which can be used by Linux and Windows – Windows has a built-in RDP client) is a better choice, because it comes with a session manager (sessman) and can be configured as a "terminal server" that starts up RDP user sessions on demand. The package name is xrdp in Debian. The xrdp service can be configured in /etc/xrdp/xrdp.ini
and started as:
/etc/init.d/xrdp start
As a nice side feature, xrdp also has a plugin to bridge protocols between running VNC sessions and remote RDP connection requests. For this reason, I use it in Knoppix, too, for remote desktop viewing and control for teachers when started from the menu, exporting the running local session.
Frozen Screen
I have a relatively new HP notebook with an NVidia card that, when starting Ubuntu, Debian, or even Knoppix, will end up in a frozen, pixelated screen. Starting Knoppix with
knoppix64 xmodule=vesa
will give me a working display but with the wrong resolution. How can I get the full resolution and decent performance?
The graphics chipset in question (lspci
shows the card as ID 10de:0cbc) is not completely supported in the Nouveau driver, which is the open source accelerated Xorg module for NVidia cards. With some rather minor drawbacks, you can still use this card without installing a proprietary driver.
The trick is that the Nouveau kernel module needs to be loaded with option noaccel=1
, which can be set in /etc/modprobe.d/nouveau.conf
as:
options nouveau noaccel=1
Note that modeset=1
, which is needed for kernel mode settings to switch resolutions, is normally enabled by default. Or, in the boot loader's APPEND
line, use:
nouveau.noaccel=1
Additionally, make sure to set:
Option "Composite" "Disable"
in the "Extensions"
section of /etc/X11/xorg.conf
; otherwise, Compiz or other desktop managers using Composite extensions for effects will cause pixel freeze. In Knoppix, disabling Composite can be done with the nocomposite
boot option. The full boot command line for Knoppix would be:
knoppix64 nouveau.noaccel=1 nocomposite
With these options, you can expect a frame rate of about 550fps in glxgears, which is even sufficient for playing Tux Racer or Neverball.
Klaus Knopper
Klaus Knopper is the creator of Knoppix and co-founder of LinuxTag expo. He currently is a Professor, Dipl. Ing., at the University of Applied Sciences Kaiserslautern. If you have a configuration problem, or if you just want to learn more about how Linux works, send your questions to: klaus@linux-magazine.com
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
Fedora 39 Beta is Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.
-
UbuntuDDE 23.04 Now Available
A new version of the UbuntuDDE remix has finally arrived with all the updates from the Deepin desktop and everything that comes with the Ubuntu 23.04 base.
-
Star Labs Reveals a New Surface-Like Linux Tablet
If you've ever wanted a tablet that rivals the MS Surface, you're in luck as Star Labs has created such a device.
-
SUSE Going Private (Again)
The company behind SUSE Linux Enterprise, Rancher, and NeuVector recently announced that Marcel LUX III SARL (Marcel), its majority shareholder, intends to delist it from the Frankfurt Stock Exchange by way of a merger.