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
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.