My openSUSE 12 Journal 13: NetworkManager Config for Cisco LEAP Wireless

This is my 100th blog entry!  

In short, I wasted a few days and a weekend to get my shiny new 12.3 to connect with my company's Cisco LEAP (henceforth referred to as just LEAP) wireless network.

For those who do not have a requirement to connect to wifi via LEAP but are curious anyways, please see this link for LEAP.

To save you the same grief, here is the answer (see screenshot below) on how to configure NetworkManager:

The one on the Left WORKED; the one on the Right did NOT work for me

Disclaimer: Your mileage may vary (YMMV) because I did not test this against another LEAP wifi network outside of my company's implementation.

openSUSE 11.2 on EeePC 701: Wifi works!? Voodoo?

Luv openSUSE 11.2 so much, especially the default KDE 4.3 GUI... I find myself staring and admiring at it... this is big for me as I've not stopped and marvel at GUI for quite a while now... ...

That was all the motivation I needed to install it onto my ASUS EeePC 701 (remember the very 1st netbook?) with 4GB SSD and 1GB RAM. Good news is everything works! Well, when I say 'everything', I meant things that matter to me like KDE GUI with compositing (ie 3D eye-candy), Firefox, OpenOffice and other apps, embedded webcam worked on Kopete and .... *drum roll*, Wireless! What's a netbook if wifi doesn't work yeah?

So, why am I so excited that wifi worked out of the box...? Apparently, wifi should not work with the default ath5k driver as its been reported at OpenSUSE on EeePC page and its true... until, by chance, I got it to work... and I'm going to described it here in very non-technical terms as I still have not figured out how/why it worked... hoping readers will have some good input and theories... maybe even a good technical answer. Here goes:

1) Original challenge: Wifi appears to be available, can scan for SSIDs. However, it failed to connect with my home SSID.

2) Plugged in a Ethernet cable on my home network, just to test if physical network connection would work, I am able to surf the web. Hurray!

3) When I unplugged the Ethernet cable, it suddenly is able to automagically connect with my home wifi. While its a step forward, I am still unable to surf the web. However, I am able to ping all IPs in my home network.

4) Added a network route via route add and I can surf the web! So happy.
route add default gw 192.xxx.xxx.xxx metric 0 dev wlan0 (where 192.xxx.xxx.xxx is my home internal IP range)

Hope this will help those with the same itch/challenge. Would definitely appreciate your inputs on this behaviour. Thanks in advance.

PS: hwinfo | grep -i atheros returns:
info.vendor = 'Atheros Communications Inc.'
pci.vendor = 'Atheros Communications Inc.'
info.vendor = 'Atheros Communications Inc.'
E: ID_VENDOR_FROM_DATABASE=Atheros Communications
<6>[ 4.942343] Atheros(R) L2 Ethernet Driver - version 2.2.3
<6>[ 4.942355] Copyright (c) 2007 Atheros Corporation.
<6>[ 7.105539] ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
Model: "Atheros AR5001 Wireless Network Adapter"
Vendor: pci 0x168c "Atheros Communications Inc."

Xen Bridged networking with NIC Bonding on SLES

We have a customer that uses the SLES Xen hypervisor (SLES 10 SP2 and now SLES 11) on their test and development server. The idea is simple, virtualize all their test and development servers on a single 2-way QUAD core, 32 GB RAM and 1TB RAID-5 SATA drive. This way, they save money on the number of physical machines in their test/development environment, improve utilization (not all projects runs concurrently). Their production systems are still running on bare-metal without virtualization... for now.

They've been having some networking issues (ie packet drop in PING test) and suspected its either the NIC (Broadcom 4 port Gb NIC and using NIC bonding) hardware or the netorking setup needs tweaking. Here's a journal of what I discovered and resolved (to a certain extent - hardware not in my scope):

1. Boot up SLES 11 (x86_64) with the default kernel (non-Xen) and configure the basic networking. Created a bond0 device that bonds 2, out of the 4, physical ports for NIC bonding (static IP, DNS and Routing info provided by customer). Tested the configuration and it works, we can ping other servers and development desktops can ping the server. Opened port in SuSEFirewall and SSH session works. Used yast2 lan for configuring and verified (always a good thing) via the following files /etc/hosts, /etc/resolv.conf, /etc/sysconfig/network/ifcfg-bond0

The following steps are done with reference to this Novell support document "Hassle-free Xen Networking" at this link.

2. Restart SLES 11 with the Xen kernel. Verify the following entry is commented out in /etc/xen/xend-config.sxp

## (network-script network-bridge)

and instead have the following:

(network-script )

Restart Xen via rcxend restart.

3. Created a bridge interface called br0 and bridged it to bond0. Moved all the static IP settings from bond0 to br0. In the place of the now empty bond0 (zero IP settings), I placed static IP 0.0.0.0 and Subnet Mask /32 (or 255.255.255.255). Verify that br0 is the interface with the static IP while bond0 does not. Also verify all the network pings between the servers and development desktop.

You can see this in more detail as referenced earlier at this link.

4. Almost there! Next, I just needed to verify and update virtual NIC settings in all domUs (VMs). By inspecting each VM configuration file in /etc/xen/vm/, we need to amend the vif variable/s (see example below):

from: vif=[ 'mac=00:16:3e:24:96:38', ]
to: vif=[ 'mac=00:16:3e:24:96:38,bridge=br0', ]

Don't forget to refresh the configuration via xm delete [VM] and xm new [VM] where [VM] is the name of the domU (VM).

Done! Customer can ping the host (SLES 11) and their domUs (SLES, RHEL and Windows) successfully without any packet drops.

TARing across the network with SSH

I'm getting old and I really thought I did blog about this... until I announced that its there on my blog at my workshop only to find that its NOT.

Anyway, the scenario is you want to tar up some files (or directories) but you want the resulting tar file on a remote machine connected via the network. This saves you some hard disk space locally and you get to do it in one step as opposed to tarring things locally and then copying it over the network.

The prerequisite is the target server has Secure Shell Daemon (SSH) running.

Here it is (and some variants):

tar -zcvf - ./<directory> | ssh <user>@<remoteIP-or-Hostname> 'dd of=<filename>.tar.gz'

Explanation: TAR and GZIP the entire <directory> but send the bits over stream via SSH to remote machine, as <user>, and write the bits into the file <filename>.tar.gz.

tar -cvf - ./<directory> | ssh <user>@<remoteIP-or-Hostname> 'gzip > <filename>.tar.gz'

Explanation: TAR the entire <directory> but send the bits over stream via SSH to remote machine, as <user>, and GZIP the stream into the file <filename>.tar.gz. Similar to first but divides the work of TAR and GZIP across 2 machines... workload management, woo-hoo!

tar -cf - ./<directory> | ssh <user>@<remoteIP-or-Hostname> 'tar -xf -'

Explanation: TAR the entire <directory> but send the bits over stream via SSH to remote machine, as <user>, and UN-TAR the stream into the same directory and file structure of the source machine.

OSSPAC 2009

I was at the Open Source Singapore Pacific-Asia Conference (OSSPAC) and had the privilege to share the Novell SUSE story at their keynote event yesterday (17th Feb 2009).

In the afternoon, while walking through the various vendor and partner exhibits, I came across these two fellas and just had to take a picture with them... from left to right: The Duke, MySQL Dolphin and me with SUSE Geeko in tow.


SUSE Linux Enterprise with JAVA and MySQL ... nice

Oh, and here are a short snippet on the contents of my keynote:

• The Novell SUSE history and how SUSE is gaining more than 5000 new customers for Novell in 2007 alone... and growing revenue at 38% from 2006 to 2007 and from 2007 to 2008. We are growing SUSE at a higher rate than the Linux market at 22% year on year
• All these are possible with the strong support from Novell partner ecosystem and it includes our strategic relationships with IBM, Microsoft, Dell, HP, Lenovo, Intel and AMD
  
• SUSE is important but not the only open source story at Novell. I picked Mono/Moonlight and SUSE Studio as some of the projects that Novell is investing in and hoping to yield fruits down the line
• Mono success at Unity3D and FusionFall MMORPG (other success stories)
  
• Moonlight bringing equality to Firefox users for President Obama's inauguration
• SUSE Studio and how partners can create custom Linux application appliances in multiple format (disk image, VMware and Xen)... and its still in Alpha!

Have fun!

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.

Simple NAT setup with Xen

When using Xen in SUSE Linux Enterprise Server 10, the default network configuration is BRIDGE networking. Every virtual OS (domU) will have a unique IP in the same range as that of the physical network card. For example, if the physical network card (eth0) have an IP of 192.168.0.10, each domU will have an IP address in the range of 192.168.0.X. This means that the host OS (dom0) AND, more importantly, other machines on the the network will be able to ping each domU as it appears to be another machine on the network with an IP.

What if you want to setup a private network for a set of virtual machines running on dom0? What if you want this private network to still be able to access the WWW (when available) ?

I found myself in this predicament as I have a set of virtual machines (Windows, SLES, SLED etc) running on my Thinkpad T61p. The nature of my [mobile] work is such that there isn't always a LAN cable or a wifi connection available readily. Irregardless of my network environment, I need to perform testing and demonstration of software running on these virtual machines. Thus, I need a flexible setup with private networking for my domUs with Network Address Translation (NAT) for accessing the WWW when a physical LAN or Wifi becomes available.

Thanks to Till and Kai, my new German connections , the following is how I did it on SLED 10 SP2* ...

* - Note that official production support for Xen is for SLES only. I'm using SLED as a development & testing desktop and the following steps will work on SLES as well.

Attention: Linux commands in braces [ ] are executed as root

1) Stop Xen daemon with [ rcxend stop ]

2) Remove the default bridge networking by editing the config file /etc/xen/xend-config.sxp. Look for the following 2 lines and comment them out with hashes ##:
(network-script network-bridge)
(vif-script vif-bridge)
becomes
##(network-script network-bridge)
##(vif-script vif-bridge)

3) Setting up the bridge to physical network (eg eth0)

Create a network bridge br0 to the physical network device (ie eth0) by creating the file /etc/sysconfig/network/ifcfg-br0 with the following contents:
BRIDGE='yes'
STARTMODE='onboot'
BRIDGE_PORTS='eth0'
BOOTPROTO='dhcp'
BROADCAST=''

For br0 to work, it has to have the IP address. Therefore, change the physical network device (ie eth0) to not start the DHCP client routine by editing the /etc/sysconfig/network/ifcfg-eth-id-xxx file with the following setting:
BOOTPROTO='none'

4) Setting up a private network (eg. 192.168.1.x)

Create a private network bridge br1 by creating the file /etc/sysconfig/network/ifcfg-br1 with the following contents:
BRIDGE='yes'
STARTMODE='onboot'
IPADDR='192.168.1.1'
NETMASK='255.255.255.0'

5) Changing the firewall settings for br0 and br1.

Change the firewall to allow network traffic for br0 and br1 as an external and internal network device respectively. Edit the file /etc/sysconfig/SuSEfirewall2 and change the following settings as shown below:
FW_DEV_EXT="br0"
FW_DEV_INT="br1"
FW_ROUTE="yes"
FW_MASQUERADE="yes"

6) Restart networking and start Xen daemon

Execute the following in order:
[ SuSEconfig ]
[ rcnetwork restart ]
[ rcxend start ]

7) Edit each domUs config in /etc/xen/vm directory to include ,bridge=br1 as follows:
From:
vif=[ 'mac=00:16:3e:75:06:c3,model=rtl8139,type=ioemu', ]
To:
vif=[ 'mac=00:16:3e:75:06:c3,model=rtl8139,type=ioemu,bridge=br1', ]

Refresh this change for each domU via:
[ xm delete domUName ]
[ xm new domUName ]

8) Boot up your virtual machines (domUs) and setup IP address in the range of 192.168.1.xxx. Remember to set the default gateway to 192.168.1.1.

For Windows VMs: Control Panel, Network Connections, from network device, right-click properties, double-click Internet Protocol (TCP/IP), set a unique fixed IP within the range of 192.168.1.[2-254], subnet mask to 255.255.255.0 and your Default gateway to 192.168.1.1. Click OK and OK again to affect the change.

For SLES VMs (Linux): setting IP to 192.168.1.10 in example below:
[ ip addr add 192.168.1.10/24 dev eth0 ]
[ ip link set eth0 up ]
[ ip route add default via 192.168.1.1 ]

You should now be able to ping all your virtual machines (domUs) from dom0 and vice versa.

Have fun!