FreeNxIntegration

Introduction

Ubuntu would benefit greatly from tight FreeNX integration. It would allow remote assistance to work at useable speeds across the internet, and be on a par with the competition. There are additional benefits when using Xen.

Rationale

The vast majority of people do NOT have access to high-speed internet connections. VNC relies on moderate speeds, and is only useable in LAN situations. Ubuntu should support NX / FreeNX innately to allow useable remote administration and assistance over the internet, and over slow connections.

Use Cases

  • James has a slow ADSL line and needs help. He goes to help, and selects invite user to share session. Annabel is then able to control James' desktop in a useable way.
  • Grace works on a five year old laptop in rural Africa. To work on her thesis she must connect to her university's server across a mesh of wifi connections, which means she has a slow connection, similar to dial-up speeds. Using FreeNX, she is able to run a remote desktop at reasonable speeds, and exploit the server's power.
  • Jenny wants to install xen instances to run her personal mail and web servers, and another to try out the new version of Ubuntu. She uses the Xen configuration GUI to add three instances, which are automatically networked to each other. She is then able to connect from work with FreeNX directly to each virtual machine instance.

Scope

  1. ability to export a FreeNX session from an existing desktop session attached to a VT in read-only mode or with simultaneous control. This opens up the possibility of remote invitations for help (as with VNC), but at a useable speed for people with less than T3 connections to the internet.
  2. ability to manage Xen instances running on the same machine. This could be done with VNC, since there is no bandwidth problem, but standardising on FreeNX would be better, and give all the usual benefits if remotely administering the Xen instances.
  3. by comparison with Windows remote desktop, VNC is miserable: Ubuntu should have the best-of-breed remote desktop solution.
  4. ? Instead of clumsy VT switching using Ctrl-Alt F7 etc., having session unattached to VTs might have benefits.

Design

  • Change the open source NX components to use xorg instead of XFree86.
  • Include these amendments in the default xorg installation
  • Include the ability to export sessions and request help using FreeNX instead of VNC
  • Security audit required

Implementation Plan

Comments

In particular, I see great value in providing desktop environments for xenU instances on the same machine. These instances may not be ubuntu-based, but if ubuntu provided for easy creation of ubuntu xenU instaces, it could integrate beautifully. Although the point of xenU instances in server consolidation is often security, allowing reduction of installed elements in each component; we should remember that windows sys admins are accustomed to using GUIs for administration, not command line.

Are there possible advantages in any circumstances of having individual users logged into new xenU instances? E.g. in a LTSP environment?

I think we should also look at the way the connection is created between nx clients and servers. Currently the client logs in on port 22 as user nx and then the the nx server is started and communicates through the ssh connection. In my opinion the server should listen on its own port. After connecting to that port the user should get a gdm login screen. This way it works more like XDMCP. It is probably more work to implement this though (WaltherZwart).

From a Xen perspective, we have a virtual framebuffer planned for version 3.0.3 which ought to be released well before the Etch time frame. I plan on providing an SDL and VNC client for the framebuffer (that runs in dom0). NX really isn't an option because the drawing primitives I've got access to are too simple to do anything useful with NX. Another potential downside of NX integration is that it only works for X-based (paravirt) platforms. Since 3.0.0, we've supported full virtualization with VT/SVM hardware extensions. These domains will also be available via SDL or VNC. Planning on SDL or VNC level integration will probably get you greater mileage for future versions of Xen. (AnthonyLiguori)

You don't have to pull all of NX in at the same time. Just bring first the nx compression libraries, the nx-proxy and some configuration. That will enable automatically the simple cases of remote X to use the awesome compression stuff. The base libraries are also tiny, in a few dozen kilobytes range if I recall correctly. Small enough to make easy default installation inclusion possible. Pull in the session management and the rest later, they generate more work. I heard btw that freenx development has ceased. 2x.com is what people are now talking about.. -- Erich

Another possibility might be the XRDP project. At present it may be somewhat immature. However, it might be a much more useful and compatible solution. Ubuntu already comes with an RDP client, as does Windows. Using RDP (instead of NX) opens up a much broader client base. (ChrisOstler)

References

FreeNxIntegration (last edited 2008-08-06 16:26:28 by localhost)