Tuesday, August 19, 2008

IDC Green IT Conference in Malaysia & Singapore

IDC's Green IT Conference is doing its round in Asia and I had the privilege to speak at the Kuala Lumpur (Malaysia) and Singapore event last week.

Update (20th Aug 2008): Found another blog entry that summarizes the KL event. I'm very delighted to see the key messages of my session have been communicated and captured by an attendee. There is even a link to my entire presentation online. Thank you Brandon. senyum

The agenda for my session:
  • The Push for Green IT
  • SUSE Linux Enterprise as the Hypervisor
  • The Stages of Virtualization
  • Summary & Customer References
I've upgraded my Live Migration of Windows Server 2008 demo... to use OCFS2/iSCSI instead of NFS. Now I'm able to live migrate with more confidence. senyum Will probably post this setup in more detail at a later time... stay tuned.

Some photos from these 2 events:

The Penguins & Geeko setup at the Novell booth... they told everyone to drop their business card and stand a chance to go home with one of these endangered animals... saving the planet... gelakguling. The next picture is Novell and their partners at work talking to prospective clients and finally, the main hall where the conference takes place... nice green theme... feels right at home for SUSE. kenyit

The event in Singapore has a similar green theme... that's me working hard to setup my 2 Thinkpad demo before the crowd comes in, the crowd listening to my presentation/demo and yours truly on stage talking about Green IT, power consumption, floor space, virtualization... blah blah blah... senyum

Monday, August 18, 2008

My friend, the Certified Linux Engineer

Last week was a busy one ... for me and my friend, Chris... although for different reasons. Chris is already a Novell Certified Linux Professional and is going to take the practicum exam to be a Novell Certified Linux Engineer on Friday.

I'm proud and happy to announce that he's now officially a Novell Certified Linux Engineer 10... the best one that I know in Singapore, Malaysia and some say Batam. senyum I know his managers would be proud of this achievement too... maybe can charge more for his services since he's now an NCLE. sembah

Anyway, I'm happy for him and even happier to brag that I know a friend who's a NCLE... don't play play ah... haha! sengihnampakgigi

Friday, August 8, 2008

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. senyum

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.

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. senyum

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. peace

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). senyum

Thursday, August 7, 2008

IBM promotes Windows-free Desktop PCs

I just have to blog about this one since its been reported virtually (pun intended) everywhere on the WWW.

It appears that Big Blue has announced a partnership with the top 3 Linux distributions (SUSE, Red Hat and Ubuntu) from Novell, Red Hat and Canonical to offer their customers a Windows-free desktop alternative.

Links to the stories:
- MarketWatch.com
- theInquirer.net
- ZDNet.co.uk
- internetnews.com

In my opinion, this has more to do with marketing and awareness. IBM's embrace and support of Linux and open source, where it made sense for them and their customers, is well documented and goes back about 10 years now.

Since 2000, SUSE was the first operational and certified Linux on the IBM System z (aka mainframe). Today, Novell SUSE Linux Enterprise enjoys a market share of above 85% in the System z space. Slightly more than a year ago, IBM Lotus announced the Open Collaboration Client Solution (OCCS) with Novell and later with Red Hat. The OCCS is a new suite of collaboration software from Lotus v8. There was even an integrated install DVD of SUSE Linux Enterprise Desktop 10 with Lotus Notes 8 from Novell.

Check out this video demonstrating Lotus Notes 8 on SUSE Linux Enterprise Desktop 10 SP1 from a year back.

The real news is that IBM sees a window (pun intended) of opportunity where it can capitalize on the slow adoption of Vista. IBM demonstrates to the customers the functional parity between Windows and Linux desktops and introduces the math of Total Cost of Ownership (TCO). By helping their clients save on fundamentals of computing (ie OS cost), their clients will have more budget left over to spend of value added software (ie Lotus suite of collaboration software).

The most quoted success for IBM and Novell is Peugeot Citro├źn and 20,000 desktops moving to SUSE Linux Enterprise Desktop 10. In the Asia Pacific region, we have seen successes in the SMB space with notably references like India's ELCOT and China Meteorological Administration, just to name a few.

So the real question is, will this work? It depends. senyum We know there is potential in this value proposition but there is equally many probable customer scenarios from IT deployment, licensing cost structures to human buying behaviour (ie Toyota is more economical but I WANT a Hummer). gelakguling

Like the authors from ZDNet who wrote this piece titled "IBM should spend another $1B to sell its Symphony OpenOffice-Linux desktop to the masses", the way to truly engage and win in the consumer desktop space as opposed to the server space, its all a matter of marketing to change user perception. One only needs to look at Apple for a good example. Show us the marketing dollars!!! duit

As a nod to my good friend and Notes Guru (aka NotesSensei), check out his blog entry where he has skinned his Thinkpad T61 to show his dedication to the cause. sembah Methinks his newly skinned Thinkpad would look even better when placed right next to mine. encem

Monday, August 4, 2008

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). senyum

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 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, issue the following command at the terminal:


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

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 via ip addr at the terminal.

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


Ta-Da! senyum

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.


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. xpasti

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


where 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. senyum

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... kenyit

Sunday, August 3, 2008

My openSUSE 11 Journal - 5 (ASUS EeePC 701)

Yes, I finally did it. Installed openSUSE 11 (KDE 4) on my ASUS Eee PC 701 last weekend. peace

As an aside, the ASUS Eee PC 701 is a nice little laptop that has single-handedly opened a whole new sub-segment in the mobile computing space. Now, almost every major manufacturer is entering this market. This new sub-segment goes by many names like subnotebook, netbook, ultra-mobile PC (UMPC), low-cost PC (LCPC) etc.

I got my Eee PC 701 earlier this year and I just loved it. For me, its the (almost) perfect combination of form factor, price and the fact that its a x86 PC. I know I'm gonna have some fun customizing it for my needs.

Anyway, I've been using the default Linux (Xandros variant) since I mainly use it to surf the web, check my emails, read PDF and MS Office documents. Due to its small keyboard and screen, I will never use it as a 9-to-5 office PC. Lately though, I have been a little frustrated at the patches that ASUS rolls out... big downloads, seeing little improvements and some patches breaks the GUI. Sigh... I guess I shouldn't expect a hardware equipment manufacturer to be good at software... even software giants don't get it right from time to time. garupale

Being more familiar with the SUSE flavour of Linux, I decided to try out openSUSE 11 (KDE 4). I've had some success in the past with openSUSE 10.3 but I found it too much work to get it to a level where I am productive.

This time around, with openSUSE 11 (KDE 4), I am very pleased. First, the installer worked very well with the small screen estate (800x480) and the installation was very smooth. The only extra bit of work is the LAN & Wifi drivers. None of the drivers in the default openSUSE package works with the hardware. Thankfully, these drivers have been packaged by a very kind soul and I just have to download them onto a USB memory stick prior to the installation. [ appleonkel, whoever you are, Thank you! sembah ]

The default openSUSE 11 (KDE 4) UI looks great with its nice Big icons. Turned on 3D desktop effects with a click of a checkbox. Sweeet! encem

Here are some details of my installation and configurations:

1) Prior to installation, I downloaded a bunch of LAN/Wifi RPMs (atl2*.rpm and madwifi*.rpm) from http://download.opensuse.org/repositories/home:/appleonkel:/EEE/openSUSE_10.3_Update/i586/

2) I used an external USB DVD drive and the standard openSUSE 11 DVD. At boot time, hit the Esc key to choose the boot device (ie DVD drive). If you do not have an external USB DVD drive, you can use USB memory sticks too. Please refer to this openSUSE article at http://en.opensuse.org/OpenSUSE_on_the_EeePC#Installation .

I removed the 2GB SD card. There were reports that the installation did not go well with some SD cards plugged in.

4) After initial installation, noted the kernel (2.6.25...-pae) and applied the relevant atl2 and madwifi (pae) rpms from (1). Reboot and the system can now access the WWW.

Other bits of additional work I did are to enable some of the Hotkeys, the embedded camera for use with Skype and the CPUFreq support. All very well documented at http://en.opensuse.org/OpenSUSE_on_the_EeePC

Nice to have an all SUSE setup at home and at work. peluk

My openSUSE 11 Journal - 4 (Firefox, Java and the 64bit)

I should have run into this challenge earlier as there are a number of webpages that require the Java plugin. However, I have been using my Thinkpad more frequently lately (SLED 10 SP2 64bit) so this little annoyance did not hit me till last weekend.

I needed my home XPC (openSUSE 11) to connect to a particular website that provides VPN service (via a Java plugin) so that I can download a bunch of binaries for testing and demo. BAM! That's when I realized the 64-bit Firefox 3.0 does not have a Java plugin... well, to be precise... 64-bit Firefox doesn't support the 32-bit Java plugin. It appears that SUN does not have a 64-bit Java plugin at this time. angkatkening

Searched the web for more information and alternatives and here they are:

1) Iced Tea is a free software implementation of Java based on SUN's openJDK. Using YaST, I removed the 32-bit SUN Java 1.6 plugin and installed 64-bit IcedTea 7 plugin. It worked for some sites with Java applets but not all. I decided to ditch this and go for (2) below as openJDK and IcedTea are fairly new and I'm not really interested in debugging where/why a particular applet wouldn't work with it. tension

2) Remove 64-bit Firefox and install a 32-bit Firefox and Java plugin. I know, its kinda silly and seems a step backwards. However, I can live with a 32-bit Firefox as its just the browser and the rest of my system still leverages the 64-bit hardware.

You can read more, in detail, at this openSUSE page on the same subject. senyum

Oh yeah, I mentioned that I didn't have this challenge when using the 64-bit SLED 10 SP2 on my Thinkpad...senyum heheh, its default is a 32-bit Firefox with SUN's Java 1.6 plugin... that's why.