Sometimes, You Have to Do It Yourself
François, make sure that hub is plugged in. Merci, mon ami. Now watch as I connect to the terminal in the wine cellar's east wing. You see, I have full access from up here. I can control the desktop, start applications, install software and so on. In fact, François, if you were down there now, we could both use the desktop. What do you mean, “But what is it good for?”
Sometimes, François, there is no control like remote control. If you could share your Linux desktop with another user or take control of another user's desktop as needed, you could save a great deal of time controlling the session or simply observing what is happening. For instance, let's pretend a certain waiter recently installed his new Linux system and occasionally needs a little guidance. Mais non, François, it is purely a hypothetical question. Your expertise with the desktop is well known. Please do not fret.
Ah, mes amis! Welcome to Chez Marcel, home of tantalizing Linux fare, great service and fine wine. Please sit and make yourselves comfortable. François, why don't you run down to the cellar? Something Italian today, I think. Bring back the 1997 Brunello di Montalcino for our guests.
I was explaining to François that there are times when nothing works better than taking control of a remote desktop in order to do what needs to be done. Perhaps the best incentive is the office environment. Using desktop sharing, a system administrator could deal with individual desktop issues without leaving the comfort (or convenience) of the office. Do you need to show a user how to add an icon to the desktop? Connect to their desktops and have them watch. Have you received a call asking for help interpreting an error message? Connect to the system and ask the user to recreate the scenario while you watch. The possibilities are endless.
An excellent cross-platform remote-control package is VNC from AT&T Laboratories in Cambridge, England. The problem with VNC is it doesn't provide any means of controlling the main X display ($DISPLAY:0), so taking control of a user's desktop to fix a problem or to show them how to do something is out of the question.
Enter KDE Desktop Sharing from creator Tim Jansen. The package is scheduled to be part of the standard network offerings in KDE 3.1, which may be out as we speak. Those running KDE 3.0 also can take advantage of this great package by visiting Tim's site, www.tjansen.de/krfb, and downloading the latest source.
Building the package is the standard extract and build five-step with a twist. The twist is the package is stored as a bzip2 file rather than as a straight gzip file.
tar -xjvf desktopsharing-0.7.tar.bz2 cd desktopsharing-0.7 ./configure --prefix= make su -c "make install"
The reason I suggest adding the prefix shown above is KDE Desktop Sharing becomes a KDE control center module, so letting your KDE implementation know where the software lives is a good idea. For instance, I've installed this on Red Hat, Mandrake and SuSE systems. Red Hat and Mandrake's KDE directories are subdirectories of /usr, while SuSE's are in /opt/kde3.
Before we move on to using the product, let me clear up one other potential area of confusion. Different distributions sometimes opt for nonstandard KDE menus, meaning that things aren't where this little installer expects to find them. A case in point is the Mandrake 9.0 desktop. Despite the installation having gone smoothly, the Desktop Sharing configuration option did not appear in the Control Center menu. The fix is an easy one, once you know about it. Here is what you do: from the desktopsharing distribution directory, change to the krfb/kcm_krfb directory and manually install the desktop entry for the KDE Control Center (the following is one single command line):
/usr/bin/install -c -p -m 644 kcmkrfb.desktop /usr/share/applnk-mdk/Configuration/KDE/Network/
Once again, I stress that when this feature becomes part of the actual KDE distribution (release 3.1), installation won't be a problem at all. Now, when you have finished compiling, installing and tweaking menus, make sure to log out from your KDE desktop before you continue. While the desktop reboots, why not take a moment to appreciate the bouquet from this most excellent wine, non?
To configure your client PC for remote access, start by bringing up the KDE Control Center from your application starter menus (the big K in the lower left-hand corner). You also can start the control center by typing kcontrol & at a shell prompt. When kcontrol starts, click on the Network icon in the left-hand sidebar menu and select Desktop Sharing, as shown in Figure 1. As you can see, two tabbed windows appear on the right-hand side. One is labeled Access and the other is Network.
The Network tab takes the least amount of explanation, so I will cover it first. Click the tab, and you'll have the opportunity to override the default to Assign port automatically. KDE Desktop Sharing's default port is 5900, but unchecking this box here makes it possible to assign a specific port number.
On to the Access tab. Invitations are the means by which access is granted to the desktop, but it also is possible to allow uninvited connections as well. I suspect, mes amis, that I do not have to explain the security implications of this course of action. For this reason, allow me to tell you how to create and manage invitations.
For starters, click the button that says Create & Manage Invitations. The window that pops up offers you two important choices. You can create either a New Personal Invitation or a New E-mail Invitation. Let's start with a personal invitation.
For security reasons, the invitation itself lasts for only an hour. If you don't do anything else, Desktop Sharing automagically comes up with a password and an expiration time for the session. The host address necessary for the connection also is displayed. Overriding either the password or the expiration time is not allowed. Make sure you pass on the information as it is shown to the person who will be connecting. When you have passed on the information (or written it down), click Close.
The other option is an e-mail invitation. The only catch here is you are sending the means to access your system via e-mail during that one hour period. If you choose this option, you'll receive a warning about plain-text e-mail over the Internet and the wisdom of encrypting said e-mail. Click Continue to get past the warning and a KMail message appears, ready for you to click Send. If no one answers the invitation, it disappears within an hour. Incidentally, you also can manage invitations with the following command:
Before we move on, click Close to get past all those invitations, and we'll have another look at the second means of providing access, uninvited connections. If sending an e-mail invitation presents interesting security concerns, then a wide-open, permanent invitation should ring additional bells. That said, in an office environment it also may be the sanest method of giving yourself access. If you check on Allow uninvited connections, you still have to assign a password for connecting. Furthermore, you have the opportunity to Confirm uninvited connections before accepting. You also can decide to give those uninvited connections the ability to control the desktop.
To connect to the desktop, you can use any VNC client; but the slicker way is to install KDE Desktop Sharing on the controlling desktop also. You'll find the interface friendly and appealing. To start the client, either select it from the Internet menu under the big K or call the program directly from the command line:
After creating an open invitation with a confirm option, a remote client trying to connect generates a warning message asking whether you want to allow that connection (Figure 3).
After accepting the request, the remote user still has to enter the password, at which point you'll see a nice blue eye staring at you from the system tray.
One of the great things about this particular program is you can resize or scale the virtual desktop to almost any size. Size your window, then click on the magnifying glass icon. If you would like a particularly psychedelic experience, set up an invitation on your own machine and try connecting to it. You'll receive an endless cascade of desktops, an effect much like standing between two parallel mirrors facing each other (Figure 4).
Ah, it is very exciting to consider how much closer Linux can bring us, non? It is true even when dealing with non-Linux systems. Allow me to demonstrate.
Another remote-control package worth your consideration is a little something Matt Chapman has cooked up called rdesktop. Here's the idea. From time to time, you may have to work on a box running Windows 2000. If that box requires you to connect using Win2K's Terminal Server, you no longer need to shut down your Linux system to do your work.
Simply put, rdesktop is a GPLed Windows (NT/2000) Terminal Server client, which means it uses RDP (remote desktop protocol). If you'd like to use rdesktop and keep running a Linux desktop in the process, pick up your copy of the source at www.rdesktop.org. Build it using the classic extract and build five-step:
tar -xzvf rdesktop-1.1.0.tar.gz cd rdesktop-1.1.0 ./configure make su -c "make install"
The whole process should take no more than a few seconds.
When the installation is complete, you can start the program like this:
rdesktop -u Administrator -p PaSsWoRd 192.168.22.212
The -u parameter specifies a user account on the Windows server, while the -p option specifies the password. Have a look at Figure 5 for a screenshot of my KDE 3.1 desktop running rdesktop to a remote Windows 2000 server.
As you can see, mes amis, with a network connection and your Linux system, you are never far away. It is just like being there.
Mon Dieu, has the time passed so quickly. As I cannot connect to your systems and pour you a glass of wine, I must attend to it here before François and I close the restaurant for the night. François, would you be so kind as to refill our guests' glasses a final time? Until next time, mes amis, let us all drink to one another's health. A votre santé! Bon appétit!
Marcel Gagné lives in Mississauga, Ontario. He is the author of Linux System Administration: A User's Guide (ISBN 0-201-71934-7), published by Addison-Wesley (and is currently at work on his next book). He can be reached via e-mail at email@example.com.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Reply to comment | Linux Journal
7 hours 14 min ago
- Dynamic DNS
7 hours 48 min ago
- Reply to comment | Linux Journal
8 hours 47 min ago
- Reply to comment | Linux Journal
9 hours 37 min ago
- Not free anymore
13 hours 39 min ago
17 hours 26 min ago
- Reply to comment | Linux Journal
17 hours 34 min ago
- Understanding the Linux Kernel
19 hours 49 min ago
22 hours 18 min ago
- Kernel Problem
1 day 8 hours ago