Remote desktop support has come a long way since Microsofts NetMeeting fortunately for all of us except, perhaps, PC Anywhere and LapLink.
In the evolving world of Windows, desktop support has almost standardised on Microsofts Remote Desktop Connection after Microsoft provided a powerful incentive in Windows XP. Shipping XP with a helpdesk request option that mails the IP address of the client desktop to tech support solved in one elegant stroke the problem of identifying the users machine.
Simple though it was, that support-request tool set a new standard for open source desktop systems to match before they could compete in the support-enabled enterprise.
And they have. Or, more accurately, they are working hard at it.
Instead of using Microsofts lightweight Remote Desktop Protocol (RDP), Linux desktop environments KDE and Gnome rely on VNCs remote framebuffer (RFB) protocol. Like RDP and with a nod towards the traditional Unix remote desktop trick of redirecting X-windows displays VNCs RFB offers a stateful server but adds to it a super-lightweight protocol. "Stateful" means a broken desktop connection can be picked up as it was when the connection broke off.
VNC has become much easier to configure in modern desktops, from KDE 3.1 onwards, because Linux distributors are providing it with GUI tools with support invitation dialogues that allow users to send email requests for help.
They also allow true desktop sharing in that it enables VNC to display to support staff the users current server display display ":0" rather than a new display ":1". That solves a long-standing problem with X-Windows desktop sharing, which used to inflict the pain of having to manually configure users VNC servers to run with the "alwaysshared" option or to install workaround software like xf4vnc, which loads a library vnc.so to capture the Linux clients own ":0" display and route it over the VNC connection.
Based on but far advanced from open source tool krfb, KDEs VNC management tool allows users to issue multiple invitations and to subsequently delete unanswered invitations as necessary. Invitations expire after one hour if unused.
That rather puts KDE ahead of Microsoft in the remote desktop support stakes.
VNC-based support requests in the Gnome desktop still lack that grace and ease of KDEs, though mainstream Linux distribution packagers like Red Hat make the KDE tools available to both Gnome users as well.
It goes without saying that Linux support staff have long been able to control Windows servers over VNC with none of the display configuration hassle that bedevilled Linux/Unix X-Windows displays. And now it is just as easy to provide support to Windows desktops from Linux desktop terminals over Microsofts RDP with open source tools like rdesktop.
Built into mainstream distributions by default, rdesktop even offers smooth control over display sizes if they are fired up with arguments like:
An expanding range of GUI wrappers also fire up rdesktop from a GUI rather than a Linux terminal.
Of course, with Linux moving into the enterprise theres a pressing need to provide remote shared "desktop" support for users working on Linux machines equipped with only a command line terminal.
It sounds like a challenge but you can easily help such budding command line enthusiasts by allowing them to watch your command line antics in real-time. Now this isnt quite the same as Windows client remote desktop sharing, where the user can wrestle control of the mouse from you (unless they choose to give up the right to). Sharing command lines uses a different principle, where the watcher is a passive observer, so youd use it where you are with the user on the phone and talking them through what you are doing or where the user is issuing the commands and you are talking them through what to do and what to expect.
To do this, we use two tools that come as standard on mainstream Linux distributions: script and mkfifo.
"Script" pipes command line output into a named file, which the observer can watch by running "cat" against it. By using mkfifo to create a named pipe instead of a file, cat will update the output in real time as the demonstrator types. This may seem counter-intuitive to anyone who routinely impresses onlookers with their grasp of the "tail" command but theres good reason to use a named pipe and "cat" when demonstrating to remote users. Well come to the reason for that in a moment before we lose you in named pipes conceptual space-time warp.
Set up a shared command line session by creating a named pipe in a publicly-readable directory with the command:
Then force a copy of your command line output to be dumped into the "observe" pipe by issuing the "script" command with an "f" argument that will make script immediately flush its output to the "observe" pipe file:
This will leave your cursor hanging as though it were in a process (which it is!). The user can start to monitor your command line session when they issue the command:
If you the demonstrator are watching your terminal at the point the user issues the "cat /tmp/observe" command, you will see your cursor drop back to a prompt. From now on commands you type will be visible to the user along with the output that the system returns in response to those commands.
That cursor dropping back to its prompt is the reason we dump "scripts" output to a named pipe the reappearance of your prompt flags to you that the user has picked up the other end of the pipe and has successfully started monitoring your session. If you merely dumped "scripts" output to an ordinary file and had the user run "tail f" against that file, you would have no way of knowing if the user was monitoring the correct file. And neither would they. From a users point of view, the only sign they will have that they are correctly monitoring your session is when their terminal begins to output your commands.
Take care to clean up after running this kind of session. The /tmp directory we used will contain a pipe file called "observe" that will capture subsequent sessions if users attempt to open it with an editor without noticing that it is flagged as a pipe file if viewed with "ls l". Remove it with the usual "rm" command.