The YoLD is Dead; Long Live the YoLD!

Twas the first day of Christmas 2009 and my true love gave to me... a Linux-ready USB WebCam!

First, YoLD = Year of the Linux Desktop. This proclamation has been ringing in my ears since 2004... for some of you, even earlier. I think, collectively, we've come to realize that its an evolution and not a revolution... hence my proclamation:

The YoLD is Dead (2009); Long Live the YoLD (2010)!

Much Thanks and Gratitude to the French for inventing the original. See Wikipedia for details here.

Back to my Christmas gift from my wife. She recalled my frustrations 2 years back in getting a brand-new USB WebCam to work with Linux (openSUSE, SLED, Ubuntu etc). She, a non-IT person, went shopping this Christmas and found a WebCam that explicitly supports Linux! Wow!

And it WORKED! No driver installation/compilation required, true plug and play. Worked with Kopete and also with Skype. It worked on openSUSE 11.2 and SLED 11. Pretty sure it will work on many of the current Linux distributions. The box did say Kernel 2.6.21 & above. Here are a few pictures of the box.



Yes, I'm helping to advertise for this vendor because they deserve my support for their explicit Linux support.

Finally, I credit this Blog entry to my wife. Thanks dear, you're the best!

I was at Computex 2009 too!

Yup, I was there from 3-6 June earlier this month... due to my traveling schedule and procrastination, well... mostly procrastination, I end up posting this "me too" post 2 days before the end of June.

Anyway, I hereby present some SUSE highlights, photos and a video of the event from my perspective:

1) With our close collaboration with Intel on Moblin, we are 1 of 2 software vendors allowed to have a booth on the traditionally hardware vendor ONLY show floor.



2) On display are SUSE Studio (beta) and a whole string of Netbooks from Acer, MSI and ASUS loaded with openSUSE 11.1 with Moblin GUI. Really sweet!



3) I found some time to go up to the 83 or 85th floor on the famous Taipei 101... what a view of the city!



4) Finally, a picture of all the hardworking Novell folks (hackers, managers, sales, marketing) who pulled this first-of-its-kind presence at Computex. Also in the picture are attractive promoters and a dude who was in a Geeko suit.



Speaking of mascots, here is a video of a Computex mascot mixing it up with our SUSE Geeko... looks like we'll need to hire the guy (or gal) in the Computex mascot to our Geeko suit for next year... Enjoy!

Remote Desktop in Linux - Part 2

In Part 1, we demonstrated how easy it was to administrate a system via a remote desktop session with openSUSE, SLED and SLES. Now, lets discuss how we can secure your remote desktop session by encrypting the data stream between the remote system and your local machine.

We will use Secure Shell (aka SSH) to encrypt the VNC (RFB) protocol via a technique called SSH Tunneling. More info on the subject of tunneling protocol at Wikipedia.

Pre-conditions:
1) You have SSH running (enabled) and you have a strong password on your remote system.
2) The Firewall is set to allow SSH traffic on your remote system.

On your local machine, we create a SSH tunnel to the remote machine, via the terminal as follows:

ssh -L 5900:localhost:5900 -f -N user@remoteIP

ssh is the secure shell program and the rest are parameters. -L will forward a particular port (ie 5900) on the local machine to another port (ie 5900) on the remote machine. -f requests ssh to go to the background. -N tells ssh not to execute remote command as we are just port forwarding. user is the user on the remote system. remoteIP is the reachable Internet address of the remote machine.

A successful SSH connection will prompt you for the user's password. Enter the password and you have a secure shell tunnel.

Next, execute the typical vncviewer command as follows:

vncviewer localhost:0

Noticed we point vncviewer to the local machine. If the SSH tunnel is setup corrrectly, it will intercept the vncviewer RFB protocol and forward it to the remote machine for execution. [localhost:0 translate to localhost and port 5900]

Now, we have the VNC (RFB) protocol leaving your local machine encrypted by the SSH protocol. Upon reaching the remote machine, the VNC (RFB) protocol will be delivered to port 5900 where the vncserver is running... and vice versa.

Do expect a hit on performance as we are wrapping a protocol (RFB) within another (SSH). I do not have a good user experience as the remote desktop feels sluggish. One workaround is to reduce the size of the remote desktop from the typical 1024x768 to 600x480 (or any other dimension as long as you're still productive). Another suggestion is to use the -deferUpdate flag to set a higher time (in milliseconds), default at 40, to wait before sending all the user interaction updates down the stream.

If you find the above too painful or performance hit unacceptable, there are other Remote Desktop alternatives with encryption. One very popular Remote Desktop software is from NoMachine.com. The underlying NX protocol is Free(as in speech) and open source(GPL). The client and server software for Linux are Free(as in beer/soda).

Remote Desktop in Linux - Part 1

Instead of running around working on a few machines, wouldn't it be nice to be able to remote-control all of them? Remote administration of Linux systems is not a new subject, there are many options but most of them involves the terminal (ie command prompt in Windows speak).

As an aside, the terminal in Linux is NOT an inferior mechanism for administrating systems. We need to remember that Linux is UNIX-like. The breadth and depth of functions available on a Linux terminal far exceed what you can imagine (if you're coming from a Windows/DOS world). I really must rant as some people think that working on a terminal is limiting, slow, un-cool and so behind the times. Personally, I use a combination of GUI and terminal, whichever that allows me to get things done quickly. Anyway...

What if you have the network bandwidth and the need to remotely administer via the desktop GUI? Again, there are a couple of options but I will focus on open source software that are readily available on most Linux distributions... in particular, openSUSE and the SUSE Linux Enterprise Desktop (SLED) and Server (SLES).

Method 1:

This applies to openSUSE 10.x-11, SLED and SLES 10. Will partially apply to any Linux distribution with the Vino (GNOME VNC Server).

1) This is disabled by default. To enable it, click Computer -> Control Center -> Remote Desktop.

2) In the dialog box, check off the "Allow other users to view your desktop" and "Allow other users to control your desktop" option.

3) Optionally, you may want to disable the "Ask you for confirmation" option since you won't be at your desktop to allow remote access (duh...) unless you are helping a friend/colleague to configure their system and they want to learn from observing your steps.

4) For security (not fullproof), you may want to enable a password before anyone can remotely control your desktop.

5) Don't forget to open a port in the Firewall. This is a common oversight. To open the port (5900) in the Firewall, use YaST -> Security & Users -> Firewall. In Firewall Configuration, select Allowed Services followed by Advanced... button. In the dialog box, enter 5900 in the TCP Ports field and click OK. Click Next and Accept to save the changes and restart the Firewall.

Finally, note the IP address of the machine (eg 10.0.0.1) either via the network manager icon on the bottom-right of the screen or just issue the command ip addr at the terminal.

On the client machine where you are going to remotely control the machine (eg 10.0.0.1), issue the following command at the terminal:

vncviewer 10.0.0.1:0

You may be prompted for a password (if you did step 4 above). DONE!

Note: Remember that the remote machine must be logged in before you can remote-control it. Also, all your actions on that desktop will be visible to anyone looking at its monitor. If this is not desirable, see Method 2.


Method 2

This method allows the same remote administration with GUI. However, the remote system does not have to be logged in and no one will see your actions as it will not show up on the remote machine's monitor.

This applies to opensuse, SLED 10 and SLES 10. Its applicable to any Linux distribution with vncserver package installed (see Manual/Standalone section of Method 2).

1) YaST -> Network Devices -> Remote Administration. In Remote Administration, select the Allow Remote Administration radio button. Also check the Open Port in Firewall checkbox. Click Finish.

2) You will need to log out to allow the display manager to be restarted. Or you can issue the following command at the terminal:

rcxdm restart

Just like in Method 1, note the IP address of the system (eg 10.0.0.2) via ip addr at the terminal.

On the client machine where you are going to remotely control the machine (eg 10.0.0.2), issue the following command at the terminal:

vncviewer 10.0.0.2:1

Ta-Da!

Note: This uses vncserver via the xinetd service. The remote system does not have to be logged in and no one can see your actions on the remote machine's monitor. However, once you log out or close the remote session, your session on the remote machine will close as well. This means you cannot have a GUI application running (ie Firefox downloading something) after closing the session. To workaround this particular limitation, use the Manual/Standalone method below.


Manual/Standalone

To invoke the vncserver command manually, issue the following command:

vncserver :1 -geometry 1024x768 -depth 16

you will be prompted for a session password. Don't forget this password.

On the client machine, issue the vncviewer command as follows:

vncviewer 10.0.0.3:1

where 10.0.0.3 is the IP address of the remote machine running vncserver

Try leaving a window or GUI application open and close the window. Now, issue the same vncviewer command again and you will see the same window and GUI application still running on the remote machine.

Good.

Now, all the above is well and good if your client machine and the remote machines are on the same (trusted) network. What if you are in an untrusted network (public wifi, hotel Internet port etc) and want to do a remote desktop to the machine back at home? You may want to secure the data stream as it travels over the Internet. Stay tuned for Part 2...

3G surfing with SLED 10 SP2

Got my hands on a 3G HSPDA modem (USB) a few weeks ago from Starhub (link). While the device is capable of download speeds of up to 7.2Mbps, my subscription only has 1.0Mbps... not that I'm complaining since I don't have to pay a cent more as its part of my home broadband package deal.

On Windows, once you plug in the device, it will mount a read-only cdrom device and the drivers are installed and configured. Wonderful user experience. I know because I tried it out on my wife's Toshiba notebook.

On Linux... well, it works but only after a little Google research. The device is a Huawei E270 HSPDA modem. Vodafone (UK) is also offering this device and there is a vodafone mobile connect card driver for various Linux distros. Unfortunately, their latest driver requires a higher kernel version than that of SLED 10. I could have used their earlier version (1.0) but the SLED 10 SP2 installed on my Thinkpad T61p is 64 bit and that didn't go too well.

My solution? Turns out that SLED 10 SP2 ships with a nice little program called umtsmon. The latest version is 0.8 and its working really well for me. You can also find it on the openSUSE Build Service. Some links as reference here and here.

I'm able to surf the Web on SLED 10 SP2 with my Huawei E270. The caveats (work-in-progress to resolve) are:

• I have to boot up my Thinkpad with the device attached so that /dev/ttyUSB* appears. If I hotplug the device while SLED 10 SP2 is running, it will auto-mount the read-only CD-ROM device with Windows drivers (not a big issue) BUT there will be no /dev/ttyUSB* available for umtsmon to work with.
• I have to run umtsmon as root because of some permissions issue with normal user unable to initiate a pppd session.

So, if anyone out there knows how to resolve the 2 items above, would love to hear from you. Although I can work/live with the current setup, it will make it a little more elegant. Thanks in advance.

PS: With reference to my previous post on the NAT setup with Xen, hoping to bridge to the Xen clients on a private subnet so as to access the Web with the USB 3G modem attached.... another work-in-progress.