stressfree - ubuntu

Tuning Ubuntu's software RAID

David — Fri, 23 Apr 2010 03:04:31 +0000

Recently I encountered an issue where the read/write performance of Ubuntu's software RAID configuration was relatively poor. Fortunately, others have encountered this problem and have documented a potential cause and solution here:

The short story is that Ubuntu uses some very conservative defaults for RAID caching. Whilst this may ensure reliable behavior across a range of hardware, it does mean that for many read/write performance will be lacklustre. The solution to this problem is to define a more aggressive caching options on any software RAID partitions that are in use.

Setting the stripe_cache_size and read ahead caches

The following example assumes that the Ubuntu server has two software-based RAID-5 partitions, /dev/md0 (the root partition) and /dev/md1 (the /var partition).

Set the stripe_cache_size and read ahead caches in the /etc/rc.local script. In the example below the stripe_cache_size is set to 8192, and the read ahead cache 4096:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution bits.
#
# By default this script does nothing.

# Tune the RAID5 configuration
echo 8192 > /sys/block/md0/md/stripe_cache_size
echo 8192 > /sys/block/md1/md/stripe_cache_size

blockdev --setra 4096 /dev/md0
blockdev --setra 4096 /dev/md1

exit 0

Restart Ubuntu to apply these settings.
Note: It is possible to apply these changes without a restart by executing each directive at the command line.

The pages linked to above explain how to test the influence of these cache changes. In general I have found that the parameters given in the example above have improved performance without influencing the reliability of the system, or the data stored on it.

USB devices with VMWare Server 2.0 on Ubuntu

David — Mon, 17 Aug 2009 05:17:18 +0000

One of the nice features of VMWare Server 2.0 is that it supports the forwarding of USB devices to virtual machines. Unfortunately when it comes to Linux the VMWare team have leveraged an old method (/proc/bus/usb) for scanning the USB bus which newer distributions, such as Ubuntu Server 8.04 no longer support.

To resolve this problem the "old" method for scanning for USB devices must be enabled in the underlying operating system. In the case of Ubuntu Server 8.04 this is a case of editing the file /etc/init.d/mountdevsubfs.sh and uncommenting the following section:

#
# Magic to make /proc/bus/usb work
#
mkdir -p /dev/bus/usb/.usbfs
domount usbfs "" /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
ln -s .usbfs/devices /dev/bus/usb/devices
mount --rbind /dev/bus/usb /proc/bus/usb

Reboot the server and /proc/bus/usb should be functional once more.

Activating a USB device within a virtual machine

Once the underlying USB subsystem is configured the USB device needs to be associated with a virtual machine. For this to occur the virtual machine must have the USB Controller added to its virtual hardware configuration. If the controller is not already part of the virtual machine's configuration shutdown the VM, add the device and restart.

The VMWare web console with USB device selection (click to enlarge)

Assuming there are USB devices attached to the server, once the virtual machine boots a small USB icon will appear within the VMWare web management console. Click on the icon and select the relevant USB device to attach it to the running virtual machine.

All going well the USB device will appear within the virtual machine as an accessible device. VMWare Server remembers this selection, so the next time the virtual machine (or server itself) is restarted the USB device will automatically be attached to the running VM.

VMWare Server 2.0 optimisations

David — Sun, 19 Jul 2009 08:42:08 +0000

VMWare Server 2.0 is emerging as a capable, zero cost alternative to VMWare ESX when used in combination with Ubuntu Server 8.04LTS. Unfortunately "out of the box" performance can be a little disappointing, especially when running guest Windows virtual machines. What follows are a few system tweaks that can improve performance without hampering overall system stability. I have not come up with these myself, instead they are pruned from the following pages:

Kernel parameters

In addition to the default Ubuntu Server kernel parameters, the following should be appended to the end of /etc/sysctl.conf.

vm.swappiness=0
vm.overcommit_memory=1
vm.dirty_background_ratio=5
vm.dirty_ratio=10
vm.dirty_expire_centisecs=1000
dev.rtc.max-user-freq=1024

Once added reboot the server to ensure their application is successful and permanent.

Create an in-memory temp drive

In the host's /tmp directory create a new directory named vmware (e.g. /tmp/vmware). This will be used as the mount point for a tmpfs (in-memory) partition for storing VM related, temporary files.

Edit /etc/fstab and add the /tmp/vmware partition to your list of mount points:

tmpfs /tmp/vmware tmpfs defaults,size=100% 0 0

Now if you execute the following command the tmpfs filesystem will be mounted at /tmp/vmware:

sudo mount /tmp/vmware

If successful, reboot the Ubuntu server to ensure the tmpfs partition is mounted at boot time.

VMWare Server configuration

Edit the /etc/vmware/config file and ensure the following configuration declarations are set:

prefvmx.minVmMemPct = "100"
prefvmx.useRecommendedLockedMemSize = "TRUE"
mainMem.partialLazySave = "TRUE"
mainMem.partialLazyRestore = "TRUE"
tmpDirectory = "/tmp/vmware"
mainMem.useNamedFile = "FALSE"
sched.mem.pshare.enable = "FALSE"
MemTrimRate = "0"
MemAllowAutoScaleDown = "FALSE"

These configuration declarations instruct VMWare Server to keep all virtual machines in memory and not to write unused blocks to disk. It also sets the temporary directory to the newly created tmpfs partition at /tmp/vmware.
Restart the VMWare Server process (sudo /etc/init.d/vmware restart) or reboot the server for these changes to take effect. The net result should be notably smoother virtual machine performance, especially when it comes to Windows guests.

Virtual machine tips

Always use fully allocated disk images.
Do not use snapshots as they are approximately 20% slower.
Always install the VMWare Tools package.
If running Linux make sure the kernel is compiled for running within a VM, or is using the correct boot time parameters.

VMWare Server 2 finally goes gold

David — Sun, 05 Oct 2008 08:46:03 +0000

On September 23 after a year of public development VMWare Server 2.0 was officially released. Server is VMWare's free, entry-level, server-centric hypervisor. Unlike VMWare's other server virtualisation products ESX and ESXi, Server must be pre-installed onto a host operating system (Windows or Linux). This adds a management and performance overhead, which for some is incentive enough to choose VMWare's more costlier offerings (or explore Xen). However if you are looking to easily virtualise a handful of servers and do not mind a small performance hit, VMWare Server is a great place to begin.

In comparison to VMWare Server 1 (a.k.a GSX) this new release appears to be a complete rewrite. However when first announced the new version received a mixed response as many existing users viewed it as slow, bloated and buggy compared to its predecessor. Ignoring the bugs which come with any beta-quality code, the majority of this criticism fell into two areas: the new web-based management console and a 500MB+ download (up from ~100MB).

Web-centric virtualisation management

Without a doubt the most controversial aspect of VMWare Server 2 is its focus on a web-based management console. In the previous release management was primarily conducted through a Windows-only client with a token web interface provided to view what was running. This new interface enables all of the hypervisor's functionality to be managed and monitored from any modern, Javascript-enabled browser. The only cavet being that virtual machine console access requires an ActiveX or Firefox extension (Windows/Linux only). Process-wise this is a little disjointed as a browser restart is needed when this extension is first installed. Whilst not a major problem this two-step process does take the shine from being able to manage your virtual infrastructure from 'any' computer.

The web administration console (click to enlarge)

As an aside given the variety of Java-based SSH, VNC and remote client applets it is a little surprising to see VMWare go the ActiveX/Firefox extension route. Whilst I have not tried the ActiveX control, the Firefox extension is large and feels sluggish when running in both Windows and Linux. Still the ability to setup and manage VMWare from something other than Windows is a definite bonus. However as an OSX user it would be nice to see VMWare management support on this platform as well.

The Firefox extension for virtual console access (click to enlarge)

But wait, VI Client to the rescue

If you are used to a traditional Windows client or just cannot stand the new web interface you will be glad to hear it is possible to manage Server 2 from the Virtual Infrastructure Client. The VI Client is very polished and feels far more responsive than the web interface for administration and console tasks. It also comes with some very nice realtime monitoring tools that graph hardware utilisation at a VM and host level. Whilst personal preference, if you manage VMWare from Windows I suggest ignoring the web interface altogether and heading straight to the VI Client.

The VI Client running against VMWare Server 2.0 (click to enlarge)

Server 2 comes with the VI Client which can be downloaded from: http://your.vmware.server/client/VMware-viclient.exe.

Does a 500MB download represent a bloated hypervisor?

The five fold jump in installer size gave many the impression that the new hypervisor would leave no free resources for the virtual machines it was intended to run. In reality this is far from the case, with the increased download size attributable an enhanced feature-set and broader guest operating system support. The installer size is also not helped by the packaging all software dependencies such as Java, Tomcat and VIX rather than relying on these to be installed independently.

The end result is that an installation of VMWare Server 2 will consume more disk space than its predecessor, but it does not use excessive amounts of CPU or memory. For example the primary 'vmware-hostd' process consumes approximately 130MB of memory and the Java web console 64MB. Assuming you are running a slim host O/S such as Ubuntu 8.04 Server this leaves plenty of memory and CPU cycles for virtual machines.

Ubuntu Server, the perfect VMWare host

For the last six months I have had great success with Ubuntu Server 8.04 as the host operating system. The default installation of Ubuntu Server is very light-weight and has extensive hardware support. To top it off Ubuntu 8.04 is a Long Term Release (LTS) which is supported by Canonical until 2013. VMWare Server 2 comes with pre-compiled kernel modules for Ubuntu 8.04 making installation a breeze. The only thing you need to do prior to installing VMWare Server is install the make package:

sudo apt-get install make

Whilst nothing needs to be compiled for VMWare Server to run, the installer does not like it when the make tool is not present. Apart from this minor distraction installation goes smoothly on both 32bit and 64bit variants of Ubuntu & VMWare Server.

A couple of VMWare tips

1. Keep your host machine 'clean'

For best performance only run the bare minimum on the host operating system. If possible stick to a cut down server O/S like Ubuntu Server instead of Windows or a full blown X-Windows Linux install.

2. Run optimised kernels on Linux virtual machines

The 2.6 Linux kernel introduced a 1000Hz clock ticker that is great for desktop performance but a drain on a hypervisor. Not only does this degrade overall performance but it can lead to weird (fast or slow) clocks in the virtual machines themselves. VMWare is optimised for a 100Hz clock so try to run a kernel optimised for virutalisation or set the following kernel parameters: "clock=pmtmr divider=10".

For example if you are using Grub as your Linux virtual machine's bootloader it would look something like this:
/boot/grub/menu.lst (in this example a Centos 5.2 VM)

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-92.1.13.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-92.1.13.el5 ro root=/dev/VolGroup00/LogVol00 clock=pmtmr divider=10
initrd /initrd-2.6.18-92.1.13.el5.img

* divider=10 instructs a 2.6 Linux kernel to check the hardware clock every 100Hz (1000Hz/10).

3. Install VMWare Tools

Take the time to install VMWare Tools on each of your virtual machines. This package has a decent network driver that removes some of the shortcomings of using a virtualised network interface. If you are running virtual machines with a graphical interface (i.e. Windows) you will also notice significantly improved performance.

4. Always use SCSI hard drive controllers in your virtual machines

Whilst it is possible to define an IDE hard drive controller within your virtual machine you run the risk of encountering issues when migrating from VMWare Server to ESX/ESXi. This is not an issue if you will only ever be using VMWare Server, but to be sure just stick to the default SCSI controller.

5. Do not overload RAM

Whilst it is possible to allocate more virtual RAM than your server actually has this is not a good idea. Hard drive access is far slower than memory, so if possible do not impose this bottleneck on your virtual machines.

Conclusion

VMWare Server 2.0 has come a long way since its early beta releases. Virtual machine performance is very good especially once VMWare Tools is installed and the kernel optimised (if Linux). A lot of work has obviously gone into the web interface and although it is not mind-blowing it does work pretty well. However if you are managing your VMWare infrastructure with Windows you will find the VI Client is superior in terms of functionality and performance. Overall for a free (as in beer) hypervisor VMWare Server 2.0 provides a simple and reliable introduction to virtualisation. Also its compatability with VMWare's Virtual Intrastructure ensures that it is easy (but not cheap) to scale your virtual machines well beyond one or two physical hosts.

Building a webcam with an old laptop, Canon camera and Linux

David — Fri, 22 Aug 2008 09:51:03 +0000

Recently I put together a webcam for the Aorangi Ski Club's lodge on Ruapehu. The system consists of a second-hand laptop, an old Canon camera and Ubuntu Linux. Images are automatically captured every hour, timestamped and posted to Flickr. The end result is a pretty impressive looking Flickr slideshow:

To put a similar setup together follow these steps.

Step 1: Get the gear

Find a Linux compatible laptop and a Canon camera compatible with the Capture software.

Step 2: Install Linux

I installed Ubuntu 8.04 on the laptop because from my experience it has the best 'out of the box' support for laptop hardware. It didn't prove me wrong when installing onto the four year old Toshiba, it even detected the winmodem.

Step 3: Internet connectivity

The problem of getting Internet connectivity will vary depending on where your webcam is located. In my case it was in a relatively isolated position half-way up one of New Zealand's largest mountains. That meant the only Internet connection available was via the phone line.

Unfortunately in this day and age winmodems are not supported that well by the popular Linux distributions. Your best bet is to get a hardware modem rather than relying on a cheaper 'winmodem' alternative. For me however budget was a driving factor so the winmodem had to stay. Fortunately the Conexant winmodem in the laptop did have a binary kernel driver available.

Setting up a modem in Linux will vary depending on your distribution, but if all else fails read the PPP howto and edit the configuration files directly.

Step 4: Install the software requirements

At this point it is a good idea to plug your laptop into your LAN and perform a full software update (i.e. apt-get update or yum update). Once that is complete install Imagemagick, Capture and the Perl library flickr_upload.

Imagemagick is very popular and should be just a case of running apt-get install imagemagick (or yum install imagemagick). Unfortunately it is highly unlikely you will find prebuilt .deb or .rpm packages for Capture or flickr_upload. In both cases it is best to download the source code and follow the compile/installation instructions. Both these packages have dependencies which you will need to track down and install, but trust me, both do compile and install on Ubuntu 8.04.

Step 5: Test your camera

At this point you should have all the prerequisits in place to start writing your webcam script.

Note: For simplicity these scripts will run as root. This gets around all the permissions issues when accessing modems and USB devices. Also the fact that this will be a standalone device doing non-mission critical work means it isn't a huge problem.

Create a directory somewhere (say /usr/local/webcam) and create a file called capture.sh.

nano capture.sh

Give it the following contents:

#!/bin/bash
# Get the new image from the camera
capture 'start'
capture 'flash off'
capture 'zoom 1'
capture 'metering spot'
capture 'focuspoint center'
capture 'capture raw.jpg'
capture 'detach'

Set the execute properties on this script.

chmod a+x

Plug the camera in to the laptop via a USB cable, turn it on and execute this script.

./capture.sh

All going well the camera should come alive, focus itself, take a photo and download it to the current directory (i.e. /usr/local/webcam) with a filename of raw.jpg.

If things do not work Google the error message, check the cable connections and try again. I tried the Capture application with a couple of supported Canon cameras and they all worked fine.

Step 6: Setup Flickr API access

Assuming your camera is happily taking photos when directed by your laptop you can go ahead and setup Flickr.

Sign up for a Flickr account (they are free). This will be where your webcam photos are sent to. Next sign up for a Flickr API key here: http://www.flickr.com/services/api/keys/apply/

Record the Flickr API key and secret that you are provided at the end of this process.

In the /usr/local/webcam directory create a file named flickr-auth.pl.

nano flickr-auth.pl

Give the file the following contents (replace YOUR_FLICKR_KEY/SECRET with your actual key and secret):

#!/usr/bin/perl

use Flickr::API;
use Flickr::Upload;

my $flickr_key = 'YOUR_FLICKR_KEY';
my $flickr_secret = 'YOUR_FLICKR_SECRET';

my $ua = Flickr::Upload->new(
{
'key' => $flickr_key,
'secret' => $flickr_secret
});
$ua->agent( "perl upload" );

my $frob = getFrob( $ua );
print "FROB:$frob;\n";

my $url = $ua->request_auth_url('write', $frob);
print "1. Enter the following URL into your browser\n\n",
"$url\n\n",
"2. Follow the instructions on the web page\n",
"3. Hit when finished.\n\n";

<>;

my $auth_token = getToken( $ua, $frob );
die "Failed to get authentication token!" unless defined $auth_token;

print "Token is $auth_token\n";

sub getFrob {
my $ua = shift;

my $res = $ua->execute_method("flickr.auth.getFrob");
return undef unless defined $res and $res->{success};

return $res->{tree}->{children}->[1]->{children}->[0]->{content};
}

sub getToken {
my $ua = shift;
my $frob = shift;

my $res = $ua->execute_method("flickr.auth.getToken",
{ 'frob' => $frob ,
'perms' => 'write'} );
return undef unless defined $res and $res->{success};

return $res->{tree}->{children}->[1]->{children}->[1]->{children}->[0]->{content};
}

Set the execute permissions for the file and run the script.

chmod a+x flickr-auth.pl
./flickr-auth.pl

Follow the onscreen instructions. You will be directed to open a browser window to the location specified, and accept the request. Once accepted press enter on the laptop and the script with return your Flickr auth token. Write this token down somewhere as it will be needed in a moment.

Step 7: Setup the Flickr upload script

Create a file named flickr-upload.pl and give it the following contents (again replace YOUR_FLICKR_KEY/SECRET/TOKEN with your actual key, secret and token):

#!/usr/bin/perl
use strict;

use Flickr::Upload;

my $flickr_key = "YOUR_FLICKR_KEY";
my $flickr_secret = "YOUR_FLICKR_SECRET";
my $auth_token = "YOUR_FLICKR_TOKEN";

my $photograph = "";
foreach my $arg (@ARGV) {
$photograph = $arg;
}

my $ua = Flickr::Upload->new(
{
'key' => $flickr_key,
'secret' => $flickr_secret
});

$ua.agent => ( "perl upload" );

$ua->upload(
'photo' => $photograph,
'auth_token' => $auth_token,
'tags' => 'webcam',
'is_public' => 1,
'is_friend' => 1,
'is_family' => 1
) or die "Failed to upload image";

You can also edit the last couple of lines to define the tags applied to the uploaded photo and its privacy settings.

Step 8: The webcam script

Create a file named process.sh and give it the following contents:

#!/bin/bash
TEMP="/usr/local/webcam"
DATESTRING=`date +%l:%M%P\ on\ %A,\ %d\ %B\ %Y`
RAWFILE="raw.jpg"
RESIZEDFILE="resized.jpg"
STAMPEDFILE="stamped.jpg"
UPLOADFILE="Webcam $DATESTRING.jpg"

logger "Webcam process initiated"

# Change to the temp directory
cd $TEMP

# Get the new image from the camera
echo "Taking photograph..."
./capture.sh

# Connect to the Internet
pon

# Convert and stamp the photograph
echo "...converting image for the web"
convert -resize 1024x768 $RAWFILE $RESIZEDFILE
convert -fill "#333333" -draw "rectangle 0,722 1024,768" $RESIZEDFILE $STAMPEDFILE
convert -fill "#eeeeee" -draw "rectangle 0,723 1024,768" $STAMPEDFILE $STAMPEDFILE
convert -font "Helvetica" -pointsize 28 -fill "#111111" -draw "text 25, 755 '$DATESTRING'" $STAMPEDFILE $STAMPEDFILE

# Wait for connection
echo "Connecting to the Internet..."
sleep 45

# Update the system time
ntpdate nz.pool.ntp.org

# Upload the photograph
echo "Uploading photograph"
# echo $UPLOADFILE
cp $STAMPEDFILE "$UPLOADFILE"
./flickr-upload.pl "$UPLOADFILE"

# Disconnect
echo "Disconnecting..."
sleep 5
poff
echo "...complete"

# Clean up - delete working files (if they exist)
rm *.jpg

logger "Webcam process complete"

This script ties everything together:

it executes the capture.sh script and takes a photo
connects the modem to the Internet
syncs the system time with a nearby NTP server
resizes and stamps the photograph with the current date and time
uploads the resized image to your Flickr account
disconnects from the Internet
removes the temporary image files

Note: You will probably want to edit parts of this script. For example you could use different image names or temp directories or a time server pool for your country.

Set the execute permissions of the file, set the camera up and run the script.

chmod a+x process.sh
./process.sh

All going well your laptop and camera should run through the routine outlined above. If you experience any errors it is just a case of debugging and trying again.

Step 9: Setup the cron job

Once the script is working as expected setup a cron job to run on a regular basis. How often is semi-dependent on your daylight hours and available Flickr bandwidth. A free Flickr account has limited upload bandwidth per month so you want to be careful your webcam does not take too many photographs. In the case of the Aorangi webcam it takes a photo once per hour between 7:30am and 4:30pm.

Create a file in /etc/cron.d named webcam and give it the following contents:

30 7-15 * * * root /usr/local/webcam/process.sh

Restart cron and you should find everything runs like clockwork from that point forward.

linux
ubuntu

Clueless Linux pundit of the week

David — Wed, 06 Sep 2006 11:43:45 +0000

There was a posting on the Linux forums that caught my attention mainly because its title and subsequent logic was so twisted that it was hard to ignore. Why Ubuntu Got It All Wrong is a fairly lengthy posting about how Ubuntu Linux, arguably the most successful Linux of the last few years, is completely wrong and should be viewed as a dismal failure. It is an interesting concept, Ubuntu is certainly showing signs of being too popular too fast, but the logic behind the argument is wrong. The weirdest statement made is that a 'revolutionary' Linux desktop should not resemble the current desktop (i.e. Windows/OSX) at all. In fact in the eyes of the author Ubuntu seems to fail because it is too conventional and the money invested by Mark Shuttleworth would have been better spent on experimental, never to be seriously adopted concepts like Project Looking Glass.

A screenshot from Project Looking Glass

Ubuntu and most Linux desktops are not about 'revolutionising' the desktop experience if there is such a thing. The key ideology behind Ubuntu and to a lesser extent Red Hat/Suse is to bring an open-source desktop alternative to the Microsoft dominated table. With this objective in mind Ubuntu is doing an excellent job, the operating system installs on just about anything, it is relatively stable and what's more the end result can be used by normal people as long as they are semi-computer literate. This ease of use is the key behind Ubuntu and if the desktop experience was as 'revolutionary' as this poster is suggesting then my guess is the end result would be interesting from an academic perspective but hardly practical.

What's more the poster contradicts himself by first stating the desktop experience is not revolutionary enough and then goes on to say "human beings don't like change and cannot be expected to change every piece of software they all use at once". I am afraid you can't have one without the other and once you start running applications like Photoshop through Wine any hope of a revolutionary desktop is lost in the flat-tone grey that is Windows GUI emulation in Linux.

It is a shame the post is so riddled with these contradictions, the underlying premise seems to hold merit and there is the odd valid point made. Like for example why haven't large companies invested serious effort (in developer and support time) on Wine? It would appear Wine is a very promising technology from the perspective that it can get essential business applications running native in Linux. Google has provided some patches in order to ensure Picasa compatibility but that is at the low-key end of support. Unfortunately whilst Wine is kept out in the relative cold by Ubuntu, Red Hat, Novell and others it will never reach its full potential, and whilst this remains the case I am affraid neither will desktop Linux.

Ubuntu on PowerBook

David — Wed, 17 Aug 2005 05:08:18 +0000

I formatted my hard drive today and repartitioned it with space for OSX and Ubuntu. Originally I planned on putting in a larger hard disk but cracking open an aluminium PowerBook is like tackling a lobster with a butter knife.
Ubuntu installed effortlessly on the machine with very little input from myself. I was even surprised to find my Apple bluetooth mouse works without having to do anything. Apparently the wireless will not work but that is because the wireless manufacturer uses a closed source driver.

(Click to Enlarge)