A busy October and November

Looks like I did not manage to write a single entry for the 2nd half of October and the whole of November.

Here's a quick recap of the stuff I've been up to:

1. HP-Intel EDA Seminar 2008 - It was a fruitful trip up to Penang. We were greatful for HP's invitation and we are happy to share the High-Performance Computing (HPC) capabilities and leading marketshare position with our target audience. Did you know that 6 out of the TOP 10 supercomputers in 2008 are using SUSE Linux Enterprise Server?
• Links to the presentation and photos (Day 1, Day 2)
2. VMware Virtualization Forum 2008 - Showed off Platespin products with our Platespin colleagues and business parter at Singapore's Suntec City Convention Centre.
3. Dell APJ Enterprise Summit 2008 - Attended the one at Kuala Lumpur and it was a very fruitful trip. I had a good interactive time presenting the entire Novell Virtualization/Automation solution suite. The only challenging bit was to do this 1 hour session 6 times over 2 days. It was worth it though as the audience understood Novell's value proposition and how we can GTM very well together.
4. IBM NEDC Summit 2008 - Attended both the Kuala Lumpur and Singapore event. Spoke to IBMers and their customers on the value of SUSE Linux Enterprise and our ability to have a common code base across the commodity System x to the industry proven and very resilient System z (mainframe).

I've been working on a few projects with customers and partners... and hope to share what I've learnt on this blog later this month... and I can't wait for openSUSE 11.1 and the next big leap forward of SUSE Linux Enterprise 11.

XEN/ZOS training for partners - Oct 2008

Finally have the opportunity to work with Jo De Baer on a 4.5 day XEN/ZOS training workshop for our Singapore and Malaysia business partners this week.

Wishing them all the best for the ZOS certification exam.


PS: ZOS is short for ZENworks Orchestrator

XEN Live Migration with iSCSI & OCFS2

Its been slow in coming but I've previously promised to blog about setting up iSCSI / OCFS2 as a means to share XEN domU images so as to facilitate Live Migration. Here we go...

Background:
Live migration in XEN is the moving of a running virtual machine (domU) from one physical machine to another. XEN will replicate the running domU's RAM across the wire between the source and target physical machine (both running XEN and having the right configurations, of course). It is up to us to ensure that the target machine has read/write access to the domU's virtual disks.

Hence, the most common way to do this is via NFS. For most, especially when setting up a demo system or in a class setting, this is sufficient. For larger scale deployments, customers usually have a SAN environment and that's that.

What about folks who are between the demo/class and larger-scale deployment scenarios? This is where this iSCSI / OCFS2 solution fits nicely. This is also commonly known as the poor man's SAN. There are quite a number of articles online that discuss this in detail (like pointing out the various SPOFs) so I'll not bother to blog about it here. Here's a good link for further reading though -> Build your own iSCSI SAN appliance, save money.

Solution:

SUSE Linux Enterprise Server 10 has both iSCSI and OCFS2 support. The following is based on SLES 10 SP2. iSCSI is a means to present a remote disk via TCP/IP to a local server just like its a local SCSI device. Hence, the little i stands for internet. OCFS2 is a proven cluster-aware filesystem and its the recommended filesystem when deploying Oracle RAC on Linux.

Here are the steps in general, you can find the details via online SLES documentation (or a one time 9Mb PDF download).

Link to documentation -> http://www.novell.com/documentation/sles10/index.html
Link to the specific section (12 & 14) -> http://www.novell.com/documentation/sles10/sles_admin/data/part_administration.html

Step 1: Setting aside a disk (or partition) to be shared via iSCSI

With reference to section 12.1, you will need to identity a disk or a disk partition to be used. Next, YaST -> Misc -> iSCSI Target to configure (if iSCSI is not installed, it will do so at this time).

Step 2: Configuring XEN servers as iSCSI clients to the shared disk

With reference to section 12.2, we configure the XEN servers to connect using YaST -> Network Services -> iSCSI Initiator so that the shared disk (or partition) will appear as local.

Step 3: Installing and Configuring OCFS2 on all servers

If you are not familiar with OCFS2, its recommended that you read section 14.0 through to 14.4.

From section 14.5, we install OCFS2 packages on all servers (storage and XEN servers). In section 14.6, we configure OCFS2 and format the disk (or partition) on the storage server.

In section 14.7, we configure OCFS2 to mount the shared storage on a common directory on the XEN servers (ie /mnt/xen/).

Step 5: Edit the domU configuration file

Copy the XEN domU configuration and virtual disk (eg disk0) into the mounted /mnt/xen/vm and /mnt/xen/images subdirectories respectively.

You will need to edit the domU VM configuration file to ensure that the disk parameter is not pointing to the new virtual disk (eg disk0) location in /mnt/xen/images/.

Don't forget to propagate these changes via xm delete and xm new commands.

Step 6: Live Migrate!

Live migrate the running domU from one physical XEN server to another via:

xm migrate [domU ID/Name] [target server hostname/IP] --live


Good luck.

Singapore Software Freedom Day 2008

Last Saturday (20 Sept) was Software Freedom Day 2008 worldwide. For Singapore, it was held at the Singapore Management University (SMU) School of Information Systems. The website for this event is at http://www.softwarefreedomday.sg

I had the privilege to present a topic at the Technology/Consumer Track. My topic titled "Road to Freedom: Practical Steps to Linux and Open Source Productivity". As this is a consumer track, I wanted to educate the public on the latest openSUSE 11 and how it can become a productive end-user desktop... using Windows analogies to bridge the gap in understanding Linux and Open Source tools.

Had a good time there. Looking forward to an even better one next year as the organizers are already enthusiastically talking of a bigger and more public venue.

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.

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



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

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. I know his managers would be proud of this achievement too... maybe can charge more for his services since he's now an NCLE.

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!

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

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

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!!!

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. Methinks his newly skinned Thinkpad would look even better when placed right next to mine.

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

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.

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.

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! ]

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!



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.

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.

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.

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.

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