Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/faster-networked-x-through-nx
Created: 2006-06-14 by JackWasey
Contributors: TollefFogHeen JackWasey AnthonyLiguori WaltherZwart
Packages affected: xserver-xorg
Summary
Solutions like CITRIX are still booming. Ubuntu already is able to display applications running on a remote server via VNC and SSH -X. NX is a new solution, which makes this possible using the X protocol - being as fast as CITRIX.
Rationale
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. 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
- Katie's 50 terminal LTSP setup runs very smoothly using NX instead of plain X, releasing bandwidth so multimedia runs much more smoothly than before.
- 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
- NX as default remote desktop option, instead of or in addition to VNC.
- 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.
- Zerconf Announce NX through avahi. ?. 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.
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)