Network Installation of openSUSE

This will be my main blog entry discussing the best practices (mine anyway) on setting up a network installation server.

What is the Motivation for this setup?

1) Local Area Networks (LANs) are ubiquitous... even in homes where, chances are, you have a modem to the Internet and next to it is a wireless/ethernet router for multiple wifi and ethernet capable devices (PCs, Laptops, Smartphones, Tablets etc) to connect and surf the web.

2) If you are a Linux/OSS enthusiast, you would be constantly downloading the latest ISOs from the web, burning them onto a DVDs and installing them on physical/virtual machines. This is time/resource intensive... time to download, time to burn a DVD, time/money spent on blank DVDs etc. Of course, if you install openSUSE on virtual machines, you avoid the DVD part of the process but you would still have lots of ISOs on your filesystem... if you have a classroom of 20 machines... well, you get the idea.

3) Almost all PCs and Laptops these days have an ethernet port and are capable of booting up from the network (ie PXE-boot). This means you physically power them on, tell it to go into PXE-boot mode and it will go onto the network and seek out an installation server to download and install the openSUSE binaries.

4) This is an efficient way to install openSUSE onto both physical and virtual machines in a LAN environment where there is only one central place for your software binaries.

Pre-requisites:

i) You have a LAN environment connecting a few machines via the network cable. Although booting from wifi is possible but it is out of the scope of this discussion.

ii) You have a physical machine (preferably*) with openSUSE installed and this will be the designated network installation server.
*It is possible to set this up on a virtual machine but you need to ensure it is connected to the physical LAN in a Bridge networking mode and not the usual NAT networking mode for typical virtual machines.

3 Simple^ Steps to Success:
^Simple - it will become more simple as you do this more frequently.

Step 1: Install and configure Apache2 webserver to host and distribute openSUSE binaries.
Please refer to my other blog entry on this subject - Using Apache2 to deploy & maintain SUSE

Step 2: Install and configure tftpboot server to enable initial boot of target machines over the network.
Please refer to my other blog entry on this subject - Install and configure TFTP server for PXE boot environment

Step 3: Install and configure dhcpd server to provide an IP address for target machines and redirect them to the tftpboot server.
Please refer to my other blog entry on this subject - Install and configure DHCP server

Step 4: On the target physical machines, on boot and depending on the BIOS, activate the boot from LAN option and watch it get an IP address from the Installation Server (via Step 3), followed by connecting to the TFTP server and presenting an installation menu (via Step 2). Enter the choice of OS to install and your installation will commence over the LAN (via Step 1).

Additional points of note:

a) Everything discussed here applies to SLES, SLED and openSUSE. The steps documented are based on openSUSE 11.x and should work on older versions and even the enterprise editions of SUSE.

b) Software installation (apache2, tftpboot, syslinux, dhcpd etc) assumes your SLE or openSUSE server have access to their respective binaries, either in DVD (also ISO) or software repository on the web.

References:

• openSUSE.org - SDB:PXE boot installation


• Novell Cool Solutions - Setting Up a SUSE PXE Installation Server in an Existing NetWare Environment


• Novell Article - Setting up a PXE Boot Server
  

Enjoy!

nVidia 3D desktop effects with XEN on SLED 10 SP2

Here's my first post for the new year 2009...

Having 3D desktop effects (ie Compiz) on SUSE Linux Enterprise Desktop (SLED) 10 is not a new thing since its been available for a few years. However, if you are using Xen virtualization with SLED, you would have realized that the Xen kernel don't play nice with these fancy graphics.

About a year ago, some brilliant and kind soul published how he got his Thinkpad T61p with nVidia graphics card to work with Xen and also enabled the 3D desktop effects. An awesome article (link here).

However, the technique used required a specific patch to be applied to a specific nVidia driver. About a month or so ago, I came across another entry online that talks about using the latest (and greatest) nVidia driver with Xen ... WITHOUT patching the nVidia driver!

Here are the summarized steps (link and credit to muchologo's original entry on nvnews forum):

Pre-reqs: Ensure you have installed kernel-source and C/C++ tools.

1. Download the desired nVidia driver. Link to good nVidia driver info.
2. Install the nVidia driver per instructions on a non-Xen SLED 10 and check that 3D desktop effects works. Link to custom install of nVidia driver on SUSE.
   
3. Reboot into the Xen SLED 10. Basic desktop GUI should fail to work (that's normal).
4. Prepare the kernel:
• cd /usr/src/linux
• cp arch/x86_64/defconfig.xen .config
• If you are using 32bit kernel, change x86_64 to i386
  
• make oldconfig && make scripts && make prepare
5. At the default TTY1, login as root, expand the nVidia driver package via:
• ./NVIDIA-Linux-x86_64-177.82-pkg2.run --extract-only
• You could be using a newer driver/arch, the above is just a sample using version 177.82 and x86_64 arch.
6. Here's the magic:
• IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT -DNV_SIGNAL_STRUCT_RLIM" make SYSSRC=/usr/src/linux module
• This will compile a new nvidia.ko module that will work with Xen
7. Now, replace the newly compiled nvidia.ko file and restart the nvidia module as follows:
• cp nvidia.ko /lib/modules/-xen/kernel/drivers/video/
• cd /lib/modules/-xen/kernel/drivers/video/
• depmod -a
• modprobe nvidia
• startx
8. All the steps only needs to be performed once for each new driver or kernel update.

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

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

SLED 10 SP2 can work with newer HP Printers

This entry is prompted by my previous entry for openSUSE 11 (link). I recall that I had similar challenges in setting up my home HP Deskjet F2120 printer with SLED 10 SP2. With SLED 10 SP2, the challenge was the bundled hplip driver was of a much older version and did not have the necessary support for newer HP Printers.

With an enterprise product (ie 7 years support), Novell had to keep its SUSE Linux Enterprise Desktop (aka SLED) 10 in a fairly "stable and supportable" state. Therfore, its kernel (2.6.16) and its associated packages are mostly static (unless there is a security or mandatory patch).

Unfortunately (for me), this means the hplip is at version 0.9.7 and another alternative version at 1.7.2. The latest hplip from source is at version 2.8.5 (as of this writing).

Here's how I got my SLED 10 SP2 to work with my new HP Deskjet F2120.

Note: You are on your own as the steps below will install a newer hplip version that does not come with the official SLED 10 SP2 package... Ergo, outside the official enterprise support scope.

1) Use Firefox to surf to openSUSE Build Service at http://software.opensuse.org/search
2) In the search field, enter hplip and select SLES/SLED 10 in the drop-down list and click Search
3) From the results, as shown below, note that there is a version 2.8.2 of hplip available.



Note: Do NOT click the 1-Click Install button. The default SLED 10 does not support this feature... most likely available in the SLED 11 timeframe.

4) Instead, take note of the line above the 1-Click Install button (ie home:jsmeix/SLE_10). You can do so by right-clicking on (home:jsmeix/SLE_10) and select Copy Link Location.

The actual URL link is http://download.opensuse.org/repositories/home:jsmeix/SLE_10

5) Start YaST -> Installation Source. Select Add, followed by Specify URL... and click Next. Paste the link in step (4) in the URL field and click Next. After YaST downloads the respective meta-data and creates a new installation source, click Finish.

6) Start YaST -> Software Management. Enter hplip in the Search field. You will see the hplip package but a newer 2.8.2 version is available for installation. Select this newer hplip version and install or update (if you have a previous hplip version installed).

OOPS: You will need to re-install yast2-printer package. If you do not re-install, the YaST Printer module will hang while it re-organize its new printer database (you installed a new hplip). A re-installation of yast2-printer will overcome this problem.

7) Plug in the USB connector of the HP Deskjet F2120 and use the Control Center -> Printers to configure and you will find the driver for F2120 is now available.

TIP: To monitor all printer definitions, status and print jobs. Use Firefox with the following link http://localhost:631

Viola! Happiness...