What is RemoteApp?

RemoteApp enables you to make programs that are accessed remotely through Remote Desktop Services appear as if they are running on the end user’s local computer.  These programs are referred to as RemoteApp programs.  Instead of being presented to the user in the desktop of the Remote Desktop Session Host server, the RemoteApp program is integrated with the client’s desktop.  The RemoteApp program runs in its own resizable window, can be dragged between multiple monitors, and has its own entry in the taskbar.

Usually, RemoteApps are hosted on Windows Server 2008 (and above), but some smart folk figured out how to host them on other versions, including Windows XP and Windows 7.

Why would you want to do this?

There’s lots of uses for this, like sandboxing software or easily running multiple versions of a piece of software side-by-side.  However, here at Liquidstate, I wanted a nice way of using applications installed on virtual machines.  I’ve used VMware Workstation with its Unity mode and wanted a similar experience, but using virtual machines hosted on my ESXi server, rather than having a hypervisor running on my desktop.  The key benefit for me is that I can have a network unaware application like “iTunes” installed on a virtual machine that I can access from any device in my house.  RemoteApp just makes that experience a little nicer.

Here’s an example of Notepad running on my Windows 7 desktop PC, right next to a RemoteApp version of Notepad running from a Windows XP virtual machine hosted on my ESXi server.

How do I do that?

In this post, I’ll walk you through how I achieved the above example whereby we have seamless integrated Notepad running on a virtualised Windows XP machine.

In the following steps, I’ll refer to my “local machine” as being the physical Windows 7 computer I’m sitting in front of.  The “remote machine” is a the virtual machine running on a remote VMware ESXi server.

Step 1 – install Remote Desktop Client v7

RemoteApp requires Remote Desktop Client v7 to be installed on both your local and remote machines.  In this example, my local machine is fine because its running Windows 7, but the remote virtual machine is running Windows XP SP3.

Download Remote Desktop Client 7 for Windows XP SP3 here and install it onto the remote machine.

Step 2 – install Update for Windows XP SP3 to enable RemoteApp

If your remote machine is running Windows XP (which ours is in this example), then you will need to download and install the hotfix released by Microsoft.  Its available here and will require a reboot.

Step 3 – set up a user account to use for RemoteApps

Now we will create a new user account on our remote Windows XP machine that will be used to run our RemoteApps.  In this example, I’ve created a “Test” user with Administrative privileges and the password “Test”.

Step 4 – install Microsoft .NET Frame 3.5 SP1

Later in this post we will be using a tool that requires the Microsoft .NET Framework 3.5 to run.  Download it from here and install it onto the remote machine(s) that you plan to access via RDP.

Step 5 – install the RemoteApp Tool

As discussed earlier, RemoteApps are usually hosted on Windows Server 2008 (and above), but some smart folk figured out that you can make them work on other versions, including Windows XP and Windows 7. This required manually editing of the registry and RDP files.  Thankfully, Kim Knight created the RemoteApp Tool, a GUI tool that allows you to create and manage RemoteApps hosted on a remote machine as well as automatically generate RDP files for use on your local PC.

Download the latest version from Kim’s website and install it onto the remote machine(s) that you plan to access via RDP.

Step 6 – create a new RemoteApp

Log in to your remote computer through RDP as normal and run the RemoteApp tool that you installed in the previous step.  Create a new RemoteApp by clicking the “Create new…” button and giving it any name you like.  Now fill in the Properties section.  Below is a screenshot of my example Notepad application:

Above you’ll notice that there is a “Client connection” section.  These details should be automatically generated for you, but should refer to the connection details of your remote machine, as viewed from your local machine.  To explain, the settings you see here will be inserted into the generated RDP file that you will use from your local machine to connect to the remote machine.

Once you’ve filled in the details, hit “Save”, followed by “Create RDP file…”.  Save the resulting RDP file somewhere safe – you’ll need it in the next step!

Step 7 – try it!

We now need to copy the RDP file created by RemoteApp Tool in the previous step from our remote machine to our local machine.  You can do this by either copying it to a network share (as I did) or by using the drive sharing options built into RDP.

Once you have the RDP file on your local machine, run it!  You’ll be prompted by a few security boxes the first time you do this, so I’ll give a few screenshots and explain what’s going on.

When we first run the RDP session, we’re informed that the RemoteApp is unsigned.  That’s normal as we’ve generated this RemoteApp ourselves.  Click “Connect” to continue anyway.

Now we are warned that the remote computer we’re connecting to cannot be verified.  As the error message explains, this is normal if it is running a version of Windows prior to Vista, which ours is.  Hit “Yes” to continue.

Now we get asked for our login credentials.  Use the username and password of the account we created in Step 3.  In this example, the username is “Test” and the password is “Test”.  You may need to hit the “Use another account” button if the username is pre-populated to something else.

After a short delay, you should now see a XP version of Microsoft Notepad integrated right into your Windows 7 desktop.  You can drag it round, resize the window; just like a normal application!

For the uninitiated, CrashPlan comprises of two components:

• CrashPlan Engine: This is always running from the moment you install CrashPlan and continues to run even if you log out. It is responsible for the actual backup functions
• CrashPlan Desktop: This runs the nice GUI desktop application that helps you configure and manage the CrashPlan Engine.

Here at Liquidstate, we have a central file server that runs Linux.  Naturally, it doesn’t have X Windows installed and is operated as a headless server – much like the type you would deploy to a data centre in a corporate environment.  I have a PC running Windows 7 that I use for any serious work and an iPad for casual web browsing etc.  In this post, I’ll show you how you can use the CrashPlan Desktop running on Windows 7 to manage the CrashPlan Engine running on a seperate Linux server.

Installation

Before we begin, I’ll assume that you’ve followed my other post that covers installing CrashPlan on a headless Linux Server.  I’ll also assume that you’ve downloaded and installed the CrashPlan software on your Windows 7 PC.  If you haven’t, then why not go do that now.

Configure CrashPlan GUI to access a remote CrashPlan Engine

We’re now going to reconfigure the CrashPlan Desktop installation on our Windows PC to access a different port which we’ll then redirect to the CrashPlan Engine instance running on our Linux Server.  Annoyingly, if you also have a CrashPlan Engine instance running on your Windows PC then you’ll need to add/remove (or comment/uncomment) this line each time you want to switch between them.  Note that the CrashPlan Engine is unaffected by changes to this text file – it will happily trundle along in the background, backing up files from your Windows PC.

Open the folder where you installed CrashPlan on your Windows PC. By default, this is in C:\Program Files\CrashPlan. Inside, you’ll find a folder called “conf” and inside there, a file called “ui.properties”. Open this file using a decent text editor like Notepad++ and add the following line:
servicePort=4200

You might find that Notepad doesn’t show line breaks properly.  You may also notice that there’s already a line similar to the above that starts with ‘#’.  This means that line is commented out, so you have the choice of changing that line and removing the ‘#’ (or just follow these instructions and add it at the bottom).

For reference, here is the content of my “ui.properties” file:
#Fri Dec 09 09:50:22 CST 2005
#serviceHost=127.0.0.1
servicePort=4200
#pollerPeriod=1000 # 1 second
#connectRetryDelay=10000 # 10 seconds
#connectRetryAttempts=3
#showWelcome=true

#font.small=
#font.default=
#font.title=
#font.message.header=
#font.message.body=
#font.tab=

SSH Tunnelling

If you’re running a Linux server, I expect you’ll already know how to use an SSH client like Putty to open a Linux command shell from a remote Windows PC.  However, SSH tunneling might be new to you.  An SSH tunnel allows you to forward a specified local TCP port to a port on the remote machine.  In this example, we’ll create an SSH tunnel that fowards any traffic to port of our choosing on our Windows PC to port 4243 on our Linux server (the port that CrashPlan Engine uses to communicate).

Creating an SSH tunnel using Putty

Download and install Putty if you don’t already have it installed. Open the program and:

• Enter the Hostname (or IP address) of your Linux server.
• Leave the Port field set to the default value of 22.
• Leave the Connection Type set to the default value of “SSH”.
• In the “Saved Sessions” field, type a name for this session, like “Crashplan”.
• Hit the “Save” button.
• Your session name should now appear in the list for future use.

Now,

• In the left-hand pane, expand the “Connection” tab, followed by the “SSH” tab, and then select “Tunnels”.
• Below where it says “Add new forwarded port:”, set the “Source port” field to 4200 and the “Destination” to “localhost:4243″.
• You can leave the default settings “Local” and “Auto” as-is.
• Hit the “Add” button to the right of the “Source port” field.
• The list of “Forward ports” should now include a line that reads “L4200   localhost:4243″
• To save the changes, in the left-hand pane, select the “Session” tab; ensure that the Host Name, Port, and “Saved Sessions” fields are how you left them; and hit the “Save” button.

Open the tunnel

• Ensure that you’re looking at the “Session” tab by selecting it in the left-hand pane.
• Ensure that the “Crashplan” session we saved earlier is loaded by selecting it from the list and hitting “Load”.
• Hit the “Open” button at the bottom right of the window.
• An Linux command shell will open, asking for your username and password.
• After you’ve entered these, it will look and act like a normal remote session, but hidden behind the scenes is our SSH tunnel.

Connect to the remote CrashPlan Engine

If you’ve already opened your SSH Tunnel, you should be able to launch the CrashPlan Desktop application on your Windows PC and it will connect through to the CrashPlan Engine instance running on your Linux PC.  If you get a connection error, make sure that you have edited the “ui.properties” file correctly;  that you entered the right port numbers in Putty; and that you have an open Putty session running in the background.

[root@server tmp]# wget http://download.crashplan.com/installs/linux/install/CrashPlan/CrashPlan_3.0.3_Linux.tgz
[root@server tmp]#
[root@server tmp]# tar -xzf CrashPlan_*_Linux.tgz

Lets just quickly check that your system has some of the basic tools that the installation script depends on, and install them if necessary.

[root@server tmp]# yum install grep sed cpio gzip coreutils


Now lets run the installer and I’ll walk you through a typical installation:

[root@server tmp]# ./install.sh
Welcome to the CrashPlan Installer.

Press enter to continue with installation.

As it suggests, press your ‘Enter’ key to continue with the installation. CrashPlan will now check your system to make sure you’ve got the necessary pre-requisite programs installed. We’ve checked this above already, so you should fly through this check.

Validating environment…
detected root permissions


You’ll notice that I’ve chosen to install CrashPlan using the ‘root’ account, giving it full access to all my data.  The installer will also let you install using a non-privileged user, but then the agent will only be able to back up files that are readable by that user. If you’d prefer to have a more secure system and are happy with managing this limitation, just quit the installer by pressing Ctrl+C; change to the user you would like to install as and then start again from the beginning of this post.

CrashPlan is written in Java and requires a valid Sun JRE or OpenJDK. If you already have it installed CrashPlan will use it, otherwise, you’ll be asked if you would like to download a dedicated copy for CrashPlan. This is my preferred method as it means that CrashPlan is self-contained.

No Java VM could be found in your path
Would you like to download the JRE and dedicate it to CrashPlan? (y/n) [y]


The next step is to accept the EULA (yawn)

You must review and agree to the EULA before installation.

Press enter to read the EULA.
…
…
…
Do you accept and agree to be bound by the EULA? (yes/no) yes

Now we need to set our installation path and enter a few configuration parameters. The installer will suggest hopefully useful defaults. You’ll notice I’ve changed the location of where CrashPlan should store backups.

What directory do you wish to install CrashPlan to? [/usr/local/crashplan]
/usr/local/crashplan does not exist. Create /usr/local/crashplan? (y/n) [y]

What directory do you wish to link the CrashPlan executable to? [/usr/local/bin]

What directory do you wish to store backups in? [/usr/local/var/crashplan] /mnt/backupdata
/mnt/backupdata does not exist. Create /mnt/backupdata? (y/n) [y]

What directory contains your SYSV init scripts? [/etc/init.d]

What directory contains your runlevel init links? [/etc/rc3.d]

Your selections:
CrashPlan will install to: /usr/local/crashplan
And put links to binaries in: /usr/local/bin
And store datas in: /mnt/backupdata
Your init.d dir is: /etc/init.d
Your current runlevel directory is: /etc/rc3.d

Is this correct? (y/n) [y]

Have a quick check over your selection and then type ‘Y’ if you’re happy to install the software.

Unpacking /./CrashPlan_3.0.3.cpi …
29808 blocks
Starting CrashPlan Engine … OK

CrashPlan has been installed and the Service has been started automatically.

Press Enter to complete installation.

Important directories:
Installation:
/usr/local/crashplan
Logs:
/usr/local/crashplan/log
Default archive location:
/mnt/backupdata

Start Scripts:
sudo /usr/local/crashplan/bin/CrashPlanEngine start|stop
/usr/local/crashplan/bin/CrashPlanDesktop

Excellent! That should now be the CrashPlan Engine/Agent installed and running. Now the installer is going to ask about installing the Desktop UI, which we will decline as this guide is about setting up a headless server. Instead, we’ll use port forwarding and a little configuration file editing to control this CrashPlan Engine from our Windows desktop instead.

You can run the CrashPlan Desktop UI locally as your own user or connect
a remote Desktop UI to this Service via port-forwarding and manage it
remotely. Instructions for remote management are in the readme files
placed in your installation directory:
/usr/local/crashplan/doc

Would you like to start CrashPlanDesktop? (y/n) [y] n

Installation is complete. Thank you for installing CrashPlan for Linux.

As with most geek homes, we have a computer that acts as a central file server (among other things).   On there we have music, movies, books, photos and our own home directories that contain a multitude of random things.  The idea is that we should be able to pick up any device in the house (PC, laptop, iPad, iPhone) and get access to our data.  It also means that if a particular device should fail or need rebuilt, then its an easy job.  Lovely.

However, what I hadn’t necessarily appreciated was how important that little server had become in our lives.  What originally started off as a place to store music and movies now has our financial info, wedding photos, videos of our kids’ first steps, and a heap of other memories – something that no insurance policy can replace.

So, it was time to practice at home what I preach at work!  We already had a (Un)RAID setup to provide an easy method of future expansion and cost-effective protection against disk failure, but that’s off little use in the event of a fire/flood/theft.  So, after some discussion with the client (my wife) and following my own advice, I estimated our Recovery Point Objective (RPO) should be measured in days and our Recovery Time Objective (RTO) to be measured in months.  In other words, in the event of a disaster we don’t really mind how long it takes to get our data back as long as we can, and that the backup is reasonably up to date.

Enter CrashPlan. CrashPlan is a piece of backup software that runs on Windows, Mac, Linux and Solaris and lets you backup your data off-site to removable hard disks, computers belonging to friends and family or to CrashPlan’s own “cloud” backup solution.  The software tracks changes to files in realtime and backup data is encrypted before it leaves your computer.  You’ll receive regular emails giving you a summary of your backups, as well as a warning if any computer has failed to backup for a few days.  And, the software will automatically update itself when new versions are available.  However, best of all, “it just works!”.

I’ve been using CrashPlan for over a year now and I must say that my experience has been excellent.  The software is easy to install (including Linux) and there’s plenty of technical information and how-to’s on the CrashPlan website.  My only niggle was that the software assumes that you’ll have a graphical user interface, which my Linux server does not.  I’ll cover how to get around this limitation very easily in a later post.

My advice to you all is go do it now.  No, really, now.  It’ll take you ten minutes.  Download the CrashPlan client, sign up for a trial of their online backup service and then once you’re data is uploaded, you’re safe and you can practically forget about it.  You’ve probably thought about backups a few times but its always relegated to the “later” pile.  If you’ve read this post and (heavens forbid) you do have a home-based disaster, you’re really going to kick yourself.  So, go on, go do it now … I’ll even give you the link!

If like me you use Firefox within a corporate environment, you perhaps repeatedly get prompted for your username and password when you use internal web applications whereas Internet Explorer just lets you log right in using Single Sign-On (SSO).  Some people don’t realize it, but Firefox is capable of NTLM authentication (Windows pass-through), just like Internet Explorer – all you need to do is tell it for which sites it should permit NTLM.

Firefox and others in the Mozilla family acheives this through what it calls integrated authentication that entails support for the the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) internet standard (RFC 2478) to negotiate either NTLM, Kerberos, or other authentication protocols supported by the operating system, leveraging system libraries that provide SPNEGO: SSPI on Microsoft Windows, and GSS-API on Linux, Mac OSX, and other UNIX-like systems.

So, that’s great, but how do you do it?

Method 1 – Do it yourself!

• Open Firefox and type about:config in the address bar.
• You will be prompted with a warning – click the “I’ll be careful, I promise!” button.

• Use the ‘Filter’ field to find the network.automatic-ntlm-auth.trusted-uris configuration parameter
• Double-click the name of the configuration parameter
• Enter the URLs of the sites you wish to enable NTLM authentication for in the form:
• http://intranet,http://sharepoint
• Note that we only include the http:// prefix and then the hostname of the server; there is no trailing slash nor a path to any particular page.  Authentication is enabled on a per-site basis.

• Now, when you go to the websites listed, you should be logged on using your Windows credentials through NTLM.

Method 2 – Use an extension!

If you don’t want to open up the about:config page whenever you come across a site that you’d like to add NTLM authentication, then as you would expect, someone has written a Firefox Extension called Integrated Authentication for Firefox that provides a simple interface to add and remove entries.  Install the Extension, restart Firefox, and then in your Tools menu, you will find a new option called Integrated Authentication Sites that will open up a simple dialog box that lets you add or remove entries. As per the manual method, note that you should only include the http:// prefix and the hostname of the server; there is no trailing slash nor a path to any particular page. Authentication is enabled on a per-site basis.

Business continuity is not something implemented at the time of a disaster; Business Continuity refers to those activities performed daily to maintain service, consistency, and recoverability.

So, where do you start?  Well, firstly, the field of Business Continuity is huge, but the purpose of this post is to give enough information for you to go do something.  By all means, once you’ve got the basics sorted, then by all means go read up further – but right now, lets just focus on understanding the basic concepts, learning some of the jargon, and some helpful hints to convince people in your company that there’s more to Business Continuity than having some backup tapes in a cupboard!

Business Continuity? Disaster Recovery?

Understanding what you’re doing is important, but all too often I’ve seen organisations spend far too much time debating what they mean by Business Continuity, rather than agreeing some basic terms and getting on with it!  In this post, we’ll work on the principle that Disaster Recovery is the act of preparing for recovery or continuation of critical IT components after a disaster (natural or otherwise) and that Business Continuity is the larger process of ensuring that all aspects of the business keep functioning.  For example, a Business Continuity Plan might involve identifying the risks faced by critical business functions and identifying the IT components they rely upon.  Meanwhile, Disaster Recovery is focussed on ensuring that there’s sufficient fault tolerance and backups to meet the requirements of the Business Continuity Plan.

What do I need to do?

Your manager might prefer you call it a Business Impact Assessment (BIA), but I’d suggest you probably need to identify all the business functions within your organisation, assign each a level of importance and then work out what IT components these systems depend on.  You can make this job as big and as complicated as you like, but at the end the day, you need to gain agreement with the business about what’s important to them.  The two fundamental measurements in Business Continuity are the:

• Recovery Time Objective (RTO):  How quickly must we restore a business function after a disruption or disaster before it causes “unacceptable consequences” to the business.
• Recovery Point Objective (RPO):  The maximum window of time before a disruption or disaster during which data may be lost.

The usual mistake is that IT ask the business what level of “uptime” is required and how much data loss is acceptable.  Of course, the answer is almost always “100% uptime with zero data loss” – usually without any real understanding of what that might involve either technically or financially!  A useful way of getting the facts is to ask the question in a different way:

If we had a major disaster right now, how long would our business survive without this particular business function?  An hour?  A day?  A week?  What would the impact be if we lost the last minute of transactions?  What about the last hour?  The last day?

Now all you have to do is review the IT components that each business function depends upon and ensure you can meet the agreed Recovery Time Objective (RTO) and Recovery Point Objective (RPO).  That might sound like a cop out, but there’s a vast array of documented solutions out there for introducing fault tolerance to an IT system.  However, its very likely that you’ll need to take a serious look at how quickly you could recover from a disaster.  Also, once you’ve identified a critical business function and analysed all the IT components it depends on, you’ll often find out that there’s some long forgotten line-of-business application that’s sitting on a single ancient server in the corner of the server room that turns out to be critical to the success of the business!

Why should I go to all this hassle?

From an IT perspective, the key purpose of the Business Impact Assessment is to understand the real requirements of the business in terms of fault tolerance and data backups.  More importantly, done right, its an opportunity to clearly document the expectations of the business in a measurable fashion.  This empowers the IT team to:

• Correctly design IT systems to ensure they have “sufficient and necessary” levels of fault tolerance.
• Put the right backup mechanisms and schedules in place to ensure you can recover from a disaster.
• Justify the IT costs associated with additional servers, storage, vendor support contracts, etc.
• Sleep sound at night knowing that if disaster does strike, then you have it in black & white what was expected of you.

Squeezebox Server

Squeezebox Server (formerly SlimServer and SqueezeCenter) is the streaming audio server software developed to stream music over your home network, allowing you to play your music collection to both software and hardware receivers (namely, the Squeezebox range).  It’s written in Perl and will run on Linux, Microsoft Windows, Apple Macintosh, and BSD platforms.  It supports a large number of audio formats including MP3, FLAC, WAV, Ogg, and AAC, as well as transcoding.  Best of all, Squeezebox Server is open source and plugins from Logitech and the community allow additional functionality to be added, such as the live radio and ‘listen-again’ features of BBC iPlayer.

Here at Liquidstate, we have Squeezebox Server running on a CentOS Linux server (virtualised, of course!).  Logitech very gratiously provide a yum repository making installation on any RedHat-based system remarkably easy:

# Install the yum repository
rpm -Uvh http://repos.slimdevices.com/yum/squeezecenter/squeezecenter-repo-1-6.noarch.rpm

# Install Squeezebox Server (and any dependencies via yum)
yum install squeezeboxserver

Now, just go to http://YOUR_SERVER:9000 and you can scan your music libary as well as configure and control any squeezebox devices on your network – all through a nice web interface.  Easy huh?

Squeezebox Boom

Our Squeezebox journey started with looking for an iPod/iPhone dock to use in our kitchen.  However, we wanted the device out of the way, which would most probably mean a stereo with third party iPhone dock attached through line-in.  Of course, we also wanted the dock to charge whatever was plugged into it and not before long, it all seemed a bit complicated.

Enter the Squeezebox Boom, a self-contained device with an LCD display, front panel controls, 30W integrated amplifier, bi-amped stereo two-way speakers, 3.5mm line in, 3.5mm line out for a subwoofer as well as both wired and wireless network adapters.  It’s very easy to set up and you’ll be up and running in no time.  The sound quality is pretty good – probably not as good as the Bose iPod dock we have, but definitely good enough.  Technical details about the “careful and innovative acoustic design” can be found in this white paper.

So now, we can listen to Internet radio, play music from our NAS device, or stream music from Last.FM or Spotify (requires a premium account).  The Boom comes with its own (basic) remote control, but we can also exercise full control using an iPhone app.  Nice!

Squeezebox Receiver

The Squeezebox Receiver is designed to be used in conjunction with your stereo.  It has Digital optical, coax and analog connectors with a 24-bit Wolfson DAC.  Just like the Squeezebox Boom, it can play a variety of music formats ans has built-in 802.11b/g wireless network adapter and a 10/100Mbps Ethernet port.

Setting up the Squeezebox Receiver is a little more fiddly due to the lack of controls and requires the use of the Squeezebox Controller, which comes with the Receiver as part of the Squeezebox Duet package.  I found the supplied User Guide to be absolutely terrible, so below is some information you might find useful if you run into any problems.

The Squeezebox Receiver has one button with a TricolorLED behind it.

Button Usage

• To put Squeezebox Receiver into setup mode, press and hold the button for about 3 seconds or until it blinks slow red then release it.
• To do a factory reset on Squeezebox Receiver, continue holding for a total of 6 seconds until it starts blinking fast red. Release and after factory reset, it will start flashing slower and be ready to set up.
• If you press and hold the button while plugging in the Receiver, you’ll see the button sequence through a series of colors and a set of ascending test tones will be played through the audio outputs.
• When connected to Squeezebox Server, the button is white, and you can press it to pause the music. Press again to start the music up again.

Colour Codes

• a solid red light means the device is booting up.
• a slow blinking red light means the device is awaiting to be setup (see below regarding fast blinking).
• a yellow light means the device is waiting for wireless to connect (and the ethernet link is down).
• a green light means the network is connected and the device is waiting for an IP address to be assigned via DHCP (this step is skipped if using static IP).
• a blue light means the device is waiting to connect to Squeezebox Server or mysqueezebox.com.
• a solid white light means the device has successfully connected to Squeezebox Server or mysqueezebox.com and is ready for use.
• a fast blinking white light means that a firmware update is in progress.
• a fast blinking red light means that a Factory Reset and xilinx update is in progress.
• a purple light is bad news and means the device has an error – it will blink a number of times, followed by a one second pause between.

Error Codes

•  1 purple blink indicates that the MAC address is missing or bad (checked second upon boot-up).
• 2 purple blinks indicates that the wireless card is missing or bad (checked first upon boot-up).
• 3 purple blinks indicates an SNV failure or error.
• 4 purple blinks indicates an upgrade error.
• 5 purple blinks indicates an CPLD XSVF file open error (xilinx file).
• 6 purple blinks indicates that the UID is not set or all zeros (checked third upon boot-up).

Control using the Squeezebox Controller

The Squeezebox Controller is a handheld remote controller with a 2.4 inch LCD TFT display that lets you control any Squeezebox device.  Like the other devices, it communicates with your Squeezebox Server over wireless using a built-in 802.11b/g wireless network adapter.

A little known feature of the Squeezebox Controller is its ability to also act as a client, capable of streaming music over wireless just like the other devices in the Squeezebox range.  This feature is still in beta and has to be enabled through the advanced options.

Local playback is enabled through Settings->Advanced->Audio Playback menu option:

 

Once enabled, you will find an extra option in the <code>Choose Player</code> menu called <code>Controller</code>.  Alternatively, if you plug headphones into the controller’s 3.5mm jack, it should automatically choose local playback for you.

If you have problems selecting between the headphone jack or internal speaker, you can try installing this third party app on to your Squeezebox Controller.

Control using your iPhone/iPad or Android

There are a number of options available to you if you want to control your Squeezebox devices from your iPhone, iPad or Android smartphone/tablet.

• The Squeezebox Controller App from Logitech is a free smartphone / tablet app to control your Squeezebox devices.  You should be able to find it in the Apple App Store or Android Marketplace by searching for ‘Logitech’ or ‘Squeezebox’.
• The iPeng iPhone Plugin for Squeezebox Server is a free third party plugin for Squeezebox Server that provides a web interface that is optimized for iPhone’s Safari browser and is also supported by Android’s Chrome.  The iPeng plugin still works but due to the small number of users still downloading it, it is less well supported.
• Finally, the iPeng iPhone App is a commercial third party app available from the Apple App Store for both iPhone and iPad.  Although it costs a few quid, it provides a fast, slick interface that is more powerful than the stock Logitech App.  For example, the app can be used to synchronise playback between multiple Squeezebox devices, letting you play the same music in multiple rooms.  An in-app purchase will also let you stream music directly to your iPhone.

Note: if you are using LVM, then this post isn’t relevant as LVM already supports persistent naming.

Inversely, imagine you’ve got a system with internal SAS disks that has been working fine, with the root filesystem on /dev/sda and some other key directory (like /usr/) on /dev/sdb.  After a while, you decide to add some additional storage via a Fiber Channel card and all of a sudden the system won’t boot correctly because the RAID array on your fibre channel disks has become /dev/sda.

However, some people don’t seem to know that this can be easily resolved by using one of the schemes for persistent naming.  From man fstab:

Instead of giving the device explicitly, one may indicate the
 (ext2 or xfs) filesystem that is to be mounted by its UUID or
 volume label (cf. e2label(8) or xfs_admin(8)), writing
 LABEL=<label> or UUID=<uuid>, e.g., LABEL=Boot or UUID=3ede-813...
 This will make the system more robust: adding or removing a SCSI
 disk changes the disk device name but not the filesystem volume label.

Persistent naming

There are two main methods of addressing filesystems in a persistent fashion; by-uuid or bl-label.

• UUID is a mechanism to give each filesystem a unique identifier. All Linux filesystems (including swap) support UUID.  And although, FAT and NTFS filesystems technically don’t, they will still be presented with a unique identifier.  The downside is that they’re not very readable (eg. “63c9c012-d93d-4953-962a-66f8130238af“).
• Almost all filesystems types can have a label, including ext2, ext3, xfs, btrfs and swap filesystems.  FAT file
  systems don’t have any mechanism to support disk labels, so you should use the udev by-id device specification instead.  Labels are the preferred method, but can suffer from name collisions if you’re not sensible about the labels you assign.

On boot, udev reads the available filesystem labels and configures useful symlinks under /dev/disk:

[root@localhost ~]# ls -lR /dev/disk/by-uuid
/dev/disk/by-uuid:
lrwxrwxrwx 1 root root 10 Apr 26  2010 63c9c012-d93d-4953-962a-66f8130238af -> ../../sda1

[root@localhost ~]# ls -lR /dev/disk/by-label
/dev/disk/by-label:
lrwxrwxrwx 1 root root 10 Apr 26  2010 boot -> ../../sda1

You can also use the blkid command to query block device attributes, including UUID and labels:

[root@localhost ~]# blkid
/dev/mapper/VolGroup00-LogVol01: TYPE="swap"
/dev/mapper/VolGroup00-LogVol00: UUID="b990560a-1d49-4751-afdb-7f3bd070d140" TYPE="ext3"
/dev/sda1: LABEL="/boot" UUID="63c9c012-d93d-4953-962a-66f8130238af" TYPE="ext3"
/dev/hda: LABEL="CentOS_5.3_Final" TYPE="iso9660"
/dev/VolGroup00/LogVol00: UUID="b990560a-1d49-4751-afdb-7f3bd070d140" TYPE="ext3"
/dev/VolGroup00/LogVol01: TYPE="swap"

Setting Disk Labels

How to set or change a disk label depends on the filesystem.  Below are some common examples:

• EXT2/EXT3: e2label /dev/XXX <label>

• ReiserFS: reiserfstune -l <label> /dev/XXX

• JFS: jfs_tune -L <label> /dev/XXX

• XFS: xfs_admin -L <label> /dev/XXX

• Btrfs: btrfs filesystem label <device> <newlabel>

• Swap: mkswap -L SWAP0 /dev/XXX

Using Persistent Naming

There are two ways to use the above persistent naming schemes.  Firstly, you could simple reference the device by the symlink in /dev/disk/by-uuid/XXX or /dev/disk/by-label/XXX as shown above, or, more directly as in the examples below by prefixing with either LABEL=XXX or UUID=XXX.

LABEL=ROOT          /         ext3    defaults      - 1
LABEL=BOOT          /boot     ext3    defaults      - 2
LABEL=SWAP          swap      swap    defaults      0 0
LABEL=HOME          /home     ext3    nosuid,auto   - 2

title CentOS  root (hd0,0)
kernel (hd0,0)/vmlinuz ro root=LABEL=ROOT rhgb quiet
initrd (hd0,0)/initrd.img

However, a few years ago, I stopped.  I just couldn’t handle the inefficiency of it all.  I seemed to spend a stupid amount of time organising things on the off chance that I was asked to produce a particular piece of paperwork or quote a block of text from some email I received months ago.

These days, I rely on search.  At home, at the start of each year, I take a big box that practically all my paperwork gets put into.  Every few years, I shred/recycle the contents of the oldest box.  Since implementing it, I’ve been asked to produce a particular document only a handful of times.  Interestingly, it doesn’t take as long as you would think to find a particular document and there’s no doubt as to where it should be – everything is in one of those boxes.  Meanwhile, at work, I have my “inbox” where all new emails arrive and an “Email” archive folder where everything is put once its gone through my GTD (Getting Things Done) system.  Like at home, I create a new archive file at the start of each year.  I archive my “Sent Items” into an annual folder too so that I’ve got a record of everything.

It seems that a recent study by researchers at IBM have produced some evidence that suggests that I was maybe right to change my ways.  The researchers “carried out a field study of 345 long-term users who conducted over 85,000 refinding actions” and found that “people who create complex folders indeed rely on these for retrieval, but these preparatory behaviors are inefficient and do not improve retrieval success. In contrast, both search and threading promote more effective finding”.  Finding emails by searches took on average 17 seconds, versus 58 seconds finding the emails in categorised folders.  The likelihood of finding the intended email was no greater when it had been filed in a folder.

According to the study, “people spend an average of 10% of their total email time filing messages” on the assumption that such preparatory actions will expedite  future retrieval.  That’s a pretty significant amount of time to spend doing something that doesn’t really help you in the long run.  More interesting for me was some of the results of the interviews the researchers held with their users in order to understand why people feel the need to create folders in the face of such evidence.  They found that “users receiving many messages were more likely to create folders, possibly because this serves to rationalize their inbox, allowing them to better see their ‘todos’”.  Indeed, the study suggests that “people defer responding to 37% of messages that need a reply” and that “deferral occurs because people have insufficient time to respond at once, or they need to gather input from colleagues”.

In other words, people seem to have a natural tendency to use their inbox as a todo list and filing emails into folders is more to do with task management than an efficient way of finding important information at a later date.

So … if you want to save yourself some time, get a decent task management system up and running (like GTD); stop using your inbox as a todo list; and spend more of your time making productive headway, rather than filing emails into folders in the slightly misguided hope that it will help you in the long run!  It’s worked successfully for me for a number of years and I haven’t looked back!

Why don’t we just use a Password?

Let’s assume that we have two people who would like to communicate privately.  To keep with tradition, lets call them Alice and Bob.  Traditionally, we’d suggest that Alice should encrypt a message using a secret password; send the encrypted message to Bob; and then Bob uses the same secret password to decrypt the message.  When Bob wants to reply to Alice, he performs the same process, encrypting his message with the same secret password.

We call this symmetric cryptography because both the sender and receiver need the same information.  Both of them can encrypt and decrypt messages using the password.  There’s no way to distinguish between the two on the basis of what information they have or how they encrypt their messages.  This leads us to two critical problems:

• How does Alice tell Bob what the secret password is without letting anyone else know?  After all, if she has a secure way to share the password, well, why not just use that same communication medium to send the message and skip all this encryption stuff?
• What if a third person, Chuck, intercepts the password unbeknown to Alice or Bob?  Well, Chuck could cause all sorts of trouble.  He could theoretically read any of the encrypted messages passed between Alice and Bob.  Or, if he really wanted to, he could send his own encrypted messages to either party, pretending to be Alice or Bob.

So, maybe we need a Better Way…

Public Key Cryptography

Public Key cryptography relies on some fancy maths to get round some of the problems inherit with the traditional shared-secret approach.  Rather than a shared password, everyone has two keys; a Public Key and a Private Key.  Anything encrypted with the Public key can only be decrypted by the corresponding Private Key, and likewise, anything encrypted by a Private Key can only be decrypted by the corresponding Public Key.  And, importantly, it must be computationally infeasible to guess one key given the other.  Like I said, some very clever maths going on there and, that’s what we spent several hours learning at the lecture I opened this post with.

The point about it being computationally infeasible to work out what either key might be given the other is more important that you might immediately realise.  The whole concept behind Public Key cryptography is that you keep our Private Key locked away and never share it with anyone.  In fact, you probably want to use a traditional symmetric cryptography to encrypt your Private Key with a secret password that only you know so that only you can use the Private Key.  Meanwhile, you can openly communicate our Public Key to everyone; post it on your website, put it in your email signature or register it with public key libraries.

So, if you want to send a secret message to someone, you would encrypt it using their Public Key, safe in the knowledge that only the corresponding Private Key is able to decrypt it.  Likewise, if you want to give the recipient some reassurance that the message came from you, then you could re-encrypt the resulting cipher text with your Private Key.  Anyone with your Public Key can decrypt the resulting message, but only you could have created that message.

How does Public Key Cryptography work?

Let’s go back to our example, but this time lets assume that Alice and Bob have both created their own Public and Private key pairs.  Likewise, lets assume that they’ve both published their Public Keys to a key-exchange library – meaning that Chuck also has both Alice and Bob’s Public Key too.

If Alice wants to send a message to Bob, she first looks up Bob’s Public key from library.  She encrypts her message using Bob’s Public Key.  She can then pass the message on to Bob, safe in the knowledge that only Bob’s Private Key (which only Bob has) can decrypt the message.  Now, this means that even if Chuck does intercept the message, there’s nothing he can do, because he only has Bob’s Public Key and not Bob’s Private Key.  Poor Chuck.

When Bob receives Alice’s message, he uses his (very well protected) Private Key to decrypt the message that Alice originally encrypted using his Public Key.  To Reply, Bob repeats the same process that Alice followed, using Alice’s Public Key (that everyone has) to encrypt a message so that only Alice’s Private Key can decrypt it.

So, we’ve demonstrated that Alice and Bob can now communicate privately without the need to share any secret passwords.  In fact, Public Key cryptography actually relies on Alice and Bob having some method of openly sharing their Public Keys.

Dealing with Impostors

Well, if you’ve been paying attention then you’re probably thinking “that’s great, but Chuck could still impersonate either Alice or Bob”.  You’re quite right!  But, by using the same principles of Public and Private keys, we can also digitally “sign” a message to prove that it came from a particular person.

So, Alice and Bob have both created their own Public and Private key pairs; they’ve shared the Public Keys to everyone, including Chuck who would like to get up to mischief.  Alice wants to send a message (M) to Bob and she wants to prove to Bob that it came from her and not Chuck.

Alice begins by encrypting her message firstly using her Private Key.  She then encrypts it a second time using Bob’s Public Key.  The message has been encrypted twice: the first encryption guarantees that the message is from Alice (because only she has access to her Private Key); and the second encryption guarantees that no one but Bob can read it (because only Bob’s Private Key can decrypt it).

When Bob receives the message, he firstly decrypts the message using his Private Key.  He then decrypts the message using Alice’s Public Key.  If this works, then it means the message must have been encrypted using Alice’s Private Key, which only Alice has access to.

So, if Chuck was to intercept the message, he wouldn’t be able to decrypt it because other than Bob, nobody has access to Bob’s Private Key.  Likewise, he can’t pretend to be Alice and send a message to Bob because only Alice can encrypt messages using Alice’s Private Key.

Did you follow that okay?  Don’t worry if you’re scratching your head – just go back over it again, it sometimes just takes a while to get your head around asymmetric cryptography if you’ve been used to shared secret passwords for a long time.

Man in the Middle

Of course, nothing is perfect; as I stated earlier, Public Key authentication relies on Alice and Bob being able to share public keys.  However, all parties need to be confident that they have the right public keys.

As before, let’s assume that Alice wants to send a private message to Bob and they haven’t already exchanged Public Keys.  However, let’s also assume that Chuck is able to intercept communications between the two and possibly deliver false messages.

Alice firstly asks Bob for his public key.  If Bob sends his public key to Alice, but Chuck is able to intercept it, a man-in-the-middle attack can begin.  Chuck sends a forged message to Alice that claims to be from Bob, but instead includes Chuck’s public key.

Alice, believing this public key to be Bob’s, encrypts her message with Chuck’s key and sends the encrypted message back to Bob. Chuck again intercepts, decrypts the message using his (Chuck) Private Key, possibly alters the messages, and re-encrypts it using the public key that Bob originally sent to Alice.  When Bob receives the newly encrypted message, he believes it came from Alice.

Thankfully, there are various solutions to the problem of verifying the ownership of a Public Key.  It’s a topic in its own right, but Public Key Infrastructure (PKI) and Web Of Trust (WoT) are solutions that leverage both technology and human supervision to bind public keys with user identities with a degree of confidence.  Lets discuss that another day!