Fuzzy Orange Ltd

Home for 5pm workshop at CFCamp

Mon, 16 Jul 2012 20:56:00 -0000

As previously announced, I'll be giving a session at CFCamp on "Home for 5pm", which is an updated version of the talk I gave at Scotch on the Rocks in 2011.

Additionally, I'll also be giving a half days Hands On Training (HOT) on the same topic.

The HOT will take the productivity features mentioned in the one hour presentation and put them into practice. There's no requirement to attend the session to get the most out of the training, but if you're looking to increase your productivity by streamlining your development through task focused development I'd strongly recommend you come along to one or the other (or why not both).

You'll learn about using Mylyn, and it's commercial big brother Tasktop to enable your task focused development. By minimising distractions, unnecessary noise and ultimately focusing on the task at hand, you'll see just how easy it is to be Home for 5pm.

The training session is €300+vat.

There's a host of other HOTs running as well on topics covering; Railo, jQuery, Regular Expressions and more so check them out.

Hopefully we'll see you in Munich.

CFCamp, Munich

Thu, 28 Jun 2012 12:39:00 -0000

This October we're heading to Munich to take part in CFCamp conference.

In addition to sponsoring the event, I'll also be presenting. I had the pleasure of speaking at the first CFCamp back in 2008, and I'm delighted to get the chance to present once more.

More details on my session will be available nearer the time, as will our overall plans for the conference.

So, if your food of choice is CFML, or you want to taste CFML for the first time, why not join us in Munich.

ColdFusion 10 instance creation path issue

Thu, 07 Jun 2012 22:02:00 -0000

When ColdFusion 7 was released back in 2005, the ColdFusion team gave us the ability to create new instances (assuming we were running in multi-server mode) directly from the ColdFusion Administrator of the default 'cfusion' instance.

There were a number of quirks with the instance creation process, which resulted in some of us sticking with the old manual process as used in CF6.1

One of the instance creation issues related to new instances inheriting paths pointing to the cfusion instance rather than the path for the newly created instance.

This bug has found it's way into ColdFusion 10. Thankfully it's incredibly easy to work around.

Let me demonstrate the issue, and how to fix it.

To create additional instances with ColdFusion 10, you need to be running ColdFusion Enterprise, or be running in trial or developer mode. If you log into the default installation instance, called 'cfusion', you'll have the ability to create additional instances via the Enterprise Manager option.

What actually happens when you create a new instance, is that this cfusion instance is effectively cloned, thereby inheriting settings you've configured. There's obviously pros and cons to this.

One of the cons is that with pages such as Charting or Logging Settings, you simply need to 'touch' the pages (i.e. click submit without making any changes), and the default path of /ColdFusion10/cfusion/logs will find it's way into new instances you create.

if you don't 'touch' the page then the correct path of /ColdFusion10/<newinstance>/logs will correctly be set.

Thankfully you can just manually correct the paths if required.

I logged this as a bug back in 2005/6, and have done so again for ColdFusion 10. The bug number is 3208658 and can be viewed at https://bugbase.adobe.com/index.cfm?event=bug&id=3208658

Tomcat User Security

Wed, 06 Jun 2012 20:32:00 -0000

In my previous post on Different JVM settings for different Tomcat instances, I briefly touched on using tomcat-users.xml to allow access to the the Server Status page. This page, along with the Tomcat Manager application (amongst others), are installed by default when you deploy Tomcat. Access to them is controlled via the tomcat-users.xml file.

As we saw in the previous article, we can enable access by defining a role, and subsequently a user who is part of that role.

Why doesn't Tomcat ship with a default account?: Simple. It's a security issue. Instead of providing that default account, Tomcat is locked down completely, and it's up to us to enable access.

Let's try accessing the Tomcat Manager without having any users defined in tomcat-users.xml.

As you can see, access is restricted. However, what it does do is tell us (some of) the types of roles available to us.

Let's look at our tomcat-users.xml file again. Now, based on what you see in the file, and what we added in the previous article, I'm hoping most (if not all) of you are a little concerned by the fact passwords are stored in plain text.

Thankfully this file isn't directly accessible from a web browser, however it can be read by anyone who has access to the server.

Tomcat Manager roles

Tomcat 7 introduced granular control over the roles available to us for accessing the Tomcat Manager, Host Manager and Server status pages. (Technically it was already there in Tomcat 6, but you had to do a bunch of manual work).

Previously, there was a "manager' role that you would add users to, to give them access to the Server Status page. The downside of this approach was that by assigning the user to the "manager" role, you also gave them access to the Tomcat manager, which allows tasks such as deploying/undeploying apps, expiring sessions, etc.

Not really ideal.

Let me, or should I say, Tomcat 7 introduce four delegation roles:

manager-gui

Full access to the Tomcat Manager.

manager-script

Provides the same access as manager-gui, but from a text interface. Command-line savvy administrators can utilise this role to do everything that manager-gui does, but they can programatically control actions via scripts written using perl, python, etc.

manager-jmx

Provides access to the jmxproxy, which exposes information for monitoring purposes.

manager-status

Access to the Server Status page.

All manager-* roles can access the Server Status page.

As an aside, the "admin" role has also been split into admin-gui and admin-script. These do exactly what they say, and provide access to the Host Manager application.

Realms

Tomcat Realms are simply a way of "storing" usernames, passwords and roles. The default out of the box realm used is "UserDatabaseRealm". This particular realm reads clear text passwords out of tomcat-users.xml

We're going to look at a couple of alternative realms, namely: MemoryRealm and JDBCRealm. There are other realms available to you, and if your interested, you can read up on them at: http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html

MemoryRealm

What we're going to do is change the realm to "MemoryRealm", which whilst still reading the user details out of tomcat-users.xml, will now do so using a specified encrypted format: SHA, MD2 or MD5.

The algorithm must be supported by the java.security.MessageDigest class

Open up CATALINA_HOME/instance/conf/server.xml

Find "UserDatabaseRealm", as below, and comment it out.

Next, add the following Realm inside the Host block, which is just below the section you commented out.

Save the file, and exit.

We now need to create a SHA encrypted version of the password you want to use. Tomcat is useful here as it provides a script to do just that. Inside CATALINA_HOME/bin, run the following:


digest.sh -a SHA  
:a_whole_bunch_of_hex

As a proper example:


digest.sh -a -SHA admin
admin:d033e22ae348aeb5660fc2140aec35850c4da997

You now want to replace your password (in tomcat-users.xml) with the encrypted version.

Now restart Tomcat and you should be able to login.

As another little aside, let's briefly mention Realms and how they apply.

- This Realm is shared across all web applications, on all virtual hosts, unless overridden by a or element.
- This Realm is shared across all web applications for this virtual host, unless overridden by a element.
- This Realm will only be used for this application.

JDBCRealm

To configure the JDBCRealm, we need to do a couple of things first:

Create tables and columns in your database of choice (we're going to use MySQL in this scenario)
Configure a 'tomcat' user to allow Tomcat to talk to MySQL
Drop the MySQL connector JAR file into place
Set up our Realm

Use the following scripts to create your tables:

(I've created a dedicated database called TomcatAuthentication)


create table users (
  user_name         varchar(15) not null primary key,
  user_pass         varchar(50) not null
);
create table user_roles (
  user_name         varchar(15) not null,
  role_name         varchar(15) not null,
  primary key (user_name, role_name) );

We need to populate our tables with data, so now run the following:


insert into users values('admin','d033e22ae348aeb5660fc2140aec35850c4da997');
insert into user_roles values('admin','manager-gui');

We now need to grant a 'tomcat' user read access to these tables, so run the following from your favourite MySQL client tool:


grant select on TomcatAuthentication.* to 'tomcat'@'localhost' identified by 'acRs7mLLbA';
flush privileges;

The next thing we need to do is get a hold of the MySQL JDBC driver, which we can download from: http://dev.mysql.com/downloads/connector/j/

Download the file, extract the contents, and then copy the JAR file (in my case mysql-connector-java-5.1.20-bin.jar) to CATALINA_HOME/lib

Now we want to add a Realm to our servers.xml file to support JDBC.

Add the following to our definition (replacing the MemoryRealm):

I've already replace the appropriate entries above to those we're using in this article.

Now you can restart Tomcat, and when you try to access the Tomcat Manager or Service Status page, authentication will now take place against MySQL.

You can obviously harden your password further by using SSL, and locking down access to internal IPs or even just localhost, and we'll look at this in a future article.

Apache and SSL Keys

Wed, 06 Jun 2012 07:33:00 -0000

SSL certificates expire and need renewed regularly, which involves at least replacing the certificate file and possibly the key and chain certificate files too, running "apachectl configtest" to make sure everything is properly in place and then restarting. Quick, simple, and therefore quite surprising when Apache dies immediately afterwards.

SSL certificates and keys need to be matched - the key must be the one used to generate the signing request for the certificate. As wonderful as it otherwise is, "apachectl configtest" does not test for this! If for whatever reason they don't match then Apache can't handle SSL requests and will refuse to start and you'll see this in the error logs :

[Fri Feb 17 21:58:56 2012] [error] Unable to configure RSA server private key
[Fri Feb 17 21:58:56 2012] [error] SSL Library Error: 185073780 error:0B080074:x509 
certificate routines:X509_check_private_key:key values mismatch

This shouldn't happen if you have been careful with your key, request and certificate generation, but sometimes life isn't straightforward - security considerations can mean it's impossible to request SSL certificates on behalf of customers. Non-technical customers can sometimes get mixed up during the process and use the wrong keys and CSRs which means you end up with a mismatch.

Now you have to track down the correct pair of key and certificate files - and quickly, as at this point Apache is down and will not come back up until you fix it or disable SSL. Luckily the OpenSSL command line tool can help.

The first step is to find the correct certificate file. OpenSSL will tell you everything you need to know to track down the right one. For each of your possible certificate files you can run the following, replacing MYDOMAIN.crt with your certificate file :

openssl x509 -noout -text -in MYDOMAIN.crt

This will print a lot of detailed information, of which we are only interested in the first few lines :

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 198312 (0x306a8)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=GB, O=Fuzzy Orange, CN=Quick Example SSL CA
        Validity
            Not Before: Nov  8 12:32:56 2011 GMT
            Not After : Aug 27 04:55:46 2012 GMT
        Subject: serialNumber=1pfX346-sw4eFZmll0aBd3dWkwKKjLDx, C=GB, 
O=WWW.MYDOMAIN.COM, OU=FO3269373, OU=Fuzzy Orange, CN=WWW.MYDOMAIN.COM

The key elements here are the validity dates and the O and CN elements of the subject - these let you know what domain this certificate is for and the dates it can be used between. When you've found the certificate that you should be using, you then need to know it's modulus to compare with your keys. Once again OpenSSL can do this for you - simply run the following, once again replacing MYDOMAIN.crt with your certificate file :

openssl x509 -noout -modulus -in MYDOMAIN.crt

This will print a large string of characters :

Modulus=F06D8B592B348B8D6704B05496CC3E094F875E6A6C5219DA33A...

This modulus string will only match up with the correct key for this certificate, so all we need to do now is check the modulus of your possible key files. Run this to see it, replacing MYDOMAIN.key with your key file :

openssl rsa -noout -modulus -in MYDOMAIN.key

Once again you'll get a large string of characters, this time of the key's modulus. Compare it to the certificate's modulus as extracted before - when you find a match then you have found your key and certificate pair.

Now quickly copy these matching certificate and key files to the location where Apache expects them and start it up again - this time it should run as normal and not report any errors. And next time around, use OpenSSL to verify the keys and certificates match in advance!

Different JVM settings for different Tomcat instances

Fri, 01 Jun 2012 07:57:00 -0000

My previous post about Running Multiple Tomcat Instances resulted in both instances using identical JVM settings.

There will be plenty of scenarios where that is fine, but for the times when it's not, it's really straight forward to change your JVM settings, including: the JVM being used, your memory settings, the garbage collector, and so on.

Let's take a simple scenario. Instance1 can use the default Tomcat JVM settings, but instance2 requires the following changes:

Max Heap size of 1GB
Permanent Generation to be sized to 192m
Different JVM

Open up instance2-startup.sh in your favourite text editor, and add the following:

(We created instance2-startup.sh in the previous article, and it can be found in your CATALINA_HOME/bin directory)


export JAVA_HOME=/usr/java/jdk1.6.0_32
export CATALINA_OPTS="-Xmx1024m -XX:MaxPermSize=192m"

The JAVA_HOME path obviously needs changed depending on the alternative JVM you want to use (and you'll need to install it of course).

Your startup file should now look (somewhat) similar to:


export JAVA_HOME=/usr/java/jdk1.6.0_32
export CATALINA_OPTS="-Xmx1024m -XX:MaxPermSize=192m"
export CATALINA_BASE=/Applications/ApacheTomcat/apache-tomcat-7.0.27/instance1
./startup.sh

Save your file. Job done.

To confirm that your instance is now using the custom JVM configuration, we're going to take a look at the Tomcat Server Status page. Before we can do that, we need to enable access.

Tomcat stores user account data in the tomcat-users.xml file that can be found in your instances conf folder, e.g.

/opt/ApacheTomcat/apache-tomcat-7.0.27/instance2/conf/tomcat-users.xml

Add the following to the file:

The above creates a role called 'manager-gui' which basically allows access to all the Tomcat management pages, as well as a new user who is assigned that role.

Clearly you don't want to use admin/admin for your username and password in production but it will suffice for our current needs.

Save the file, and then stop/start your Tomcat instance.

Fire up your Tomcat dashboard in your favourite browser; http://localhost:8282 (remember and use the port number associated with your instance).

You can now click on the 'Server Status' button that is shown on the right hand side of the page, enter admin/admin for the username/password, and you'll see a bunch of information including; JVM memory settings, the JVM being used and more.

If you fire up your other instance, the one using the default settings (remember to edit it's tomcat-users.xml file to allow access to the Server Status page), and then view its server status, you'll see the contrasting information, which proves your utilising different JVM configurations for your Tomcat instances.

Running Multiple Tomcat Instances

Wed, 30 May 2012 23:53:00 -0000

We've been doing a fair bit of work with Tomcat for a while now. It was partly instigated by the knowledge that ColdFusion 10 was going to use Tomcat under the hood (in replace of JRun), but we've also been doing work deploying Railo as well as some Java apps (deploying as WAR files).

One of the things we're so used to is the ability to run multiple instances of ColdFusion on JRun, and we wanted to do the same with Tomcat. As such, this entry is a generic walkthrough to get up and running with multiple instances of Tomcat.

The first thing you need to do is get a hold of Tomcat. Go grab the most recent version from http://tomcat.apache.org (v7.0.27 as of writing).

We like to install Tomcat versions inside a master ApacheTomcat folder, e.g. /opt/ApacheTomcat/apache-tomcat-7.0.27

Once you've extracted Tomcat, take a look at the contents of the folder. You'll find some text files, and more importantly a bunch of folders:

bin
- contains all the binaries and scripts for running Tomcat
conf
- configuration files including server.xml and web.xml
lib
- the libraries that make Tomcat work
logs
- funnily enough, logs
temp
- used for temporary files
webapps
- this is where we put our apps
work
- folder used by Tomcat to write out files needed during runtime, including generated code for JSPs, class files, serialised sessions

An important part of any Tomcat installation is environment variables. There are 5 different variables that interact with Tomcat, two of which are mandatory:

Mandatory

CATALINA_HOME
JAVA_HOME

Optional

CATALINA_BASE
CATALINA_TMPDIR
CLASSPATH

All three optional variables can be calculated using CATALINA_HOME

The usual way

Under a normal install, we really only care about CATALINA_HOME. By default, this variable points to the Tomcat root folder, so using our set up, it points to /opt/ApacheTomcat/apache-tomcat-7.0.27

This gives access to the /bin and /lib folders, and allows all other environment variables to be set when we run startup.sh (found in the /bin folder).

And this is the important part. Instead of allowing CATALINA_BASE to be set automatically, we want to explicitly set it. That's the key to multiple instances.

Configuring Multiple Instances

Create two new folders inside your CATALINA_HOME folder, e.g.

/opt/ApacheTomcat/apache-tomcat-7.0.27/instance1
/opt/ApacheTomcat/apache-tomcat-7.0.27/instance2

Copy the following folders (and their contents) from CATALINA_HOME, and paste them into the two directories you created above:

/conf
/logs
/temp
/webapps
/work

(You might want to delete the contents of your copied log folders).

Next we need to configure the 3 different ports that each Tomcat instance will use. These are the connector port, the AJP port, and the shutdown port.

Connector port
- What Tomcat uses to communicate with the outside world. Default: 8080
AJP port
- If you're going to be connecting to Apache (or IIS), then you'll be looking to use AJP rather than the "basic" connector. AJP is a binary protocol and is therefore faster than the default connector. Default: 8009
Shutdown port
- Tomcat uses a port as part of it's shutdown process. It communicates with this port to shutdown cleanly, and therefore it has to be unique per instance. Default: 8005

Let's start by opening and editing /instance1/conf/server.xml. Find the blocks similar to below for the three connector ports


  
.....

Change the ports to something like:


  
.....

Do the same for the second instance, providing different port numbers again.

Let's now create some startup/shutdown scripts for our instances. Create a new file called instance1-startup.sh in CATALINA_HOME/bin

Add the following to the script:


export CATALINA_BASE=/opt/ApacheTomcat/apache-tomcat-7.0.27/instance1
cd $CATALINA_HOME/bin
./startup.sh

Create another new file called instance1-shutdown.sh in CATALINA_HOME/bin, and add the following:


export CATALINA_BASE=/opt/ApacheTomcat/apache-tomcat-7.0.27/instance1
cd $CATALINA_HOME/bin
./shutdown.sh

Do the same for instance2, being careful to change the paths.

You can now run ./instance1-startup.sh and ./instance1-shutdown.sh to start/stop your first instance, as well as your other scripts to control your other instances.

Congratulations, you're now running multiple instances of Tomcat, which can be accessed via (depending on the port numbers you chose above)
http://localhost:8181
http://localhost:8282

You can now deploy your ColdFusion and Railo WAR files directly into an instances webapps folders, e.g.
/opt/ApacheTomcat/apache-tomcat-7.0.27/instance1/webapps

Adobe ColdFusion 10 available now

Wed, 16 May 2012 19:11:00 -0000

With the release of ColdFusion 10, Adobe's Enterprise application server for Rapid Application Development, there's a lot to get excited about. HTML5 features heavily in the new release, with support for dynamic and interactive charting, web sockets, and video. RESTful web services are delivered out of the box. Improved Java integration as well the the move from JRun to Tomcat as the underlying JEE servlet container are just some of the new features. You can find a full list of what's new, on the ColdFusion 10 Family section at http://www.adobe.com/uk/products/coldfusion-family.html ColdFusion 10 is available now, and as an authorised reseller, Fuzzy Orange can help you with all your licensing requirements. Contact us for a quote, or for more information on how we can help you get the best out of ColdFusion 10.

Matt Gifford shortlisted for Developer of the Year

Wed, 05 Oct 2011 15:01:00 -0000

As previously blogged, our very own Matt Gifford was nominated in this years .NET Awards for Developer of the Year. We're delighted to announce that Matt has been shortlisted for the award, along with Paul Irish and Lorna Mitchell. Congrats Matt and best of luck!

.net Awards - Developer of the Year

Mon, 08 Aug 2011 10:38:00 -0000

The annual .net Awards, organised by .net magazine, is one of the Web industry's leading ceremonies recognising some of the best talent the world of Web Design and Development has to offer. For 2011, our very own Matt Gifford has been nominated in the "Developer of the Year" category. Matt has worked like a demon, not just for us or our our clients, but also for the ColdFusion community as a whole, releasing a huge number of open source applications, including the much loved monkehTweets. His hugely popular "Object Oriented Programming in ColdFusion" book, released Autumn 2010, has been a massive success, and he's authored numerous magazine articles covering (to name but a few): Building Mobile Application with Adobe AIR, ColdFusion ORM, HTML5, Application Security, and speaking at Conferences. We know just how good Matt's work is, as do our clients, and it's great to see that work be recognised globally. You too can vote for Matt. Just head to the .net Awards website.

Adobe MAX 2011

Tue, 02 Aug 2011 20:13:00 -0000

Two months from now, approximately 5,000 designers, developers, managers, technologists and more will once again descend upon LA for the 2011 edition of Adobe MAX. This will be the fourth time Fuzzy Orange have been involved in a speaking capacity; 2007 in Barcelona and 2009, 2010 in LA. For this years conference, Matt Gifford and myself will both be jetting in to present on a number of topics.

Matt Gifford

OWASP Enterprise Security API and available methods to help lock down a ColdFusion Application (Unconference)

Monday, October 3rd, 2.00 p.m. - 2.50 p.m.

Mobile Apps from 0 to 90: Powered by ColdFusion (BYOD Lab)

Tuesday, October 4th, 8.00 a.m. - 9.30 a.m.
In this 90 minute lab, you'll use Adobe Flash Builder to develop a mobile application from the ground up, compiling it as an Adobe AIR app. Learn how to create and push views, add a tabbed menu interface, and call and manage remote data from a ColdFusion web server. You'll also debug and deploy the final application to your mobile Android device.

Darwin Development (Unconference)

TBC
Evolution. It's a wonderful thing, and something that needs to occur for natural progression and the continuing advancement of ideas. As we see the modern trends, development paradigms and design practices evolve into different areas utilising newer technologies, should we really be saying goodbye to our old ways in favour of the new approach? Join Matt Gifford as he invites you to partake in a presentation with an emphasis on attendee input (with rewards) in a discussion to help understand what makes the web great, how we communicate in the modern world, and as a result whether or not we should leave the big screen behind entirely in favour of new formats.

Andy Allan

Adobe ColdFusion and modern Web front ends (Preconference Lab)

Sunday, October 2nd, 9.00 a.m. - 5.00 p.m.
Adobe ColdFusion works very well with most javascript frameworks and especially well with jQuery. See how ColdFusion, jQuery, and mobile web standard development can catapult your ColdFusion development to the latest and greatest. In addition to presenting, we'll also be networking like crazy, catching up with old friends and new, and taking part in as much ColdFusion related fun as possible. See you in LA!!

Migrating your Rackspace US Cloud Server to the UK

Wed, 08 Jun 2011 10:09:00 -0000

Migrating your Linux server from the Rackspace US Cloud to the UK

We here at Fuzzy Orange love the Cloud. We make extensive use of cloud services, particularly at Rackspace. When we started running cloud servers at Rackspace they only offered this service in the US but now it's offered in the UK too and we're migrating our servers over.

Rackspace have provided a detailed set of instructions which do the job well, but are maybe not the best at explaining what's going on. There are also one or two little "gotchas" not mentioned there.

Now, the first thing that should be noted is that depending on the complexity of the setup on your US cloud server it may be easier to just move files by hand. For example, if you just have a little web server with static content, it would be quicker and easier just to create a new UK cloud server and copy your content across manually.

Important things you need to know

1. US and UK usernames and API keys

The Rackspace migration scripts use the Cloud Files API to copy things around, so you will need valid usernames and API keys for both the US and UK cloud.

2. US and UK servers will run simultaneously

You need to have both servers up and running for the whole procedure, so you will be charged for both until everything is complete.

3. Python 2.6 on your UK server

Older Linux distributions ship with Python 2.4, which isn't good enough to run the Rackspace migration scripts. If you're so inclined you can build Python 2.6 from scratch, but it's easier to grab the ActiveState Python 2.6 installer and use that.

4. Files can't be changed during the process

Well, they can, but you'll have to transfer any changed files manually after the process is complete. When taking the source snapshot of your US cloud server you have to make sure no files are open for writing - this means databases either shut down or open read-only.

5. It will take about a day for this to complete

After you've created your migration image and run the Rackspace migration scripts you need to create a support ticket wait for Rackspace to do some work behind the scenes to link your US image to your UK server. It will take about a day or so for this to happen.

Step by step

1. Create the destination server in the UK cloud

Create a new, blank server in the UK cloud. Make sure it matches exactly your US server for memory, disk size and OS version.

2. Create an on-demand backup on the UK server

This is where the US image is eventually copied across to. Call this something like "MigrationImage" so you'll know what it's for.

Once it's complete, go to Cloud Files and look inside the cloudservers folder. Take note of the .yml file for your image for later (e.g. MigrationImage_20110607_123456.yml)

3. Prepare the US server

You need to prepare the server for an on-demand backup image. This means making sure no files are opened for writing, which means any databases need to be shut down or set to read-only.

4. Create an on-demand backup on the US server

This becomes the source image for your UK server. Call this something like "MigrationImageSource" so you'll know what it's from

Once you have the on-demand backup of the US server you can optionally restart your databases or make them read-write again, but understand that changes from this point on won't be copied by the migration scripts so you will have to deal with them manually afterwards.

Just like the UK image, go to Cloud Files and take note of the name of the .yml file for use later.

5. InstallPython 2.6 on your UK server

Check the version of Python you have installed by just running "python --version". If don't have Python installed at all, try to install it using your system's package manager (e.g. "yum install python" or "apt-get install python")

If you don't have at least Python 2.6.0 then you'll need to install it by hand. You can download the source and compile from scratch, but as you're probably only going to be using it this once for the migration, you might find the ActivePython from ActiveState easier to install - just remember to add the ActivePython bin directory to the beginning of $PATH once you're done.

6. Install PyYAML on your UK server

PyYAML is a Python module the migration scripts need to run. Download it from http://pyyaml.org/download/pyyaml/PyYAML-3.09.tar.gz, untar it to a folder and run "python setup.py install" to install it.

7. Download the migration script on your UK server

Get the Rackspace migration script from http://c857.r57.cf3.rackcdn.com/migrationscript_v1.0.zip and, if you like (and I'd recommend that you do so), verify the checksum with that on the Rackspace FAQ page. Unzip the file into a folder.

8. Run the migration script on your UK server

Now you need to run the command on your UK server to copy the migration image over from the US to the UK. The format of the command is :

You need to replace US_username, US_apikey, source.yml, UK_username and UK_apikey with your details so the command ends up looking like :

This will take a while to run depending on the size of the image to be migrated. It will print progress as it goes. Don't worry about getting it wrong, it handles errors gracefully and you can run it again. If you have an exceptionally large server image it may be worth running this inside Screen or some other tool that allows you to disconnect from the session without terminating your login.

9. Raise a support ticket in the UK portal

Once the migration script has completed you have to raise a support ticket in the UK cloud portal. The Rackspace FAQ has the correct wording to use in the ticket details, but additionally I would suggest you add the name of the US and UK servers.

10. Restore the migrated image to the UK server

Once you have notification from Rackspace support that they have finished migrating your image you should be able to restore the image to your UK server. The migration overwrites the on-demand UK backup you took at the start of all this with the US on-demand image, so restore using that.

Once this is done the UK server is now an identical copy of the US server at the point the on-demand image was taken there.

11. Change network settings on the UK server

Sometimes this happens automatically, but sometimes it doesn't. If you can't immediately access your UK server on the new IP address it has been assigned, you'll need to use the Cloud console to connect to it directly to change the network settings.

The Cloud portal already gives you the primary IP of your cloud server. Rackspace support assure me that for all cloud servers the netmask is always 255.255.255.0 and the default gateway is the same as the IP, but with the last octet changed to 1 - so, if your primary IP is 33.44.55.66, your default gateway is 33.44.55.1. DNS servers should be 83.138.151.80 and 83.138.151.81.

12. Test your UK server

Now you need to test the new UK server to make sure it's all working. Start any databases you had previously stopped or bring them out of read-only mode.

13. Sync up any changed content

If any content has changed on the US server since you started this process then this is the time to copy it across to the new UK server.

14. Change DNS names to point at UK server

If you have any public DNS records that refer to the US server you probably want to change them now to point at the new UK server.

15. Delete the US server

Once you are totally, 100% sure that the UK server has migrated correctly, all content has been copied and any DNS entries have been re-pointed towards it, you can delete your US server.

Remember that you are still charged even if your US server is switched off, so you need to delete it entirely. If desired, create an on-demand backup to Cloud Files before doing so you can re-create it if necessary.

And there you go - your US cloud server is now running in the UK.

We're hiring: ColdFusion Developer Wanted!

Thu, 27 Jan 2011 10:15:00 -0000

ColdFusion Developer, £25 - £28k DOE

Due to our continuing success and growth, Fuzzy Orange are currently looking for a highly-motivated, experienced ColdFusion Developer to be based in Glasgow, Scotland. The position is a key role working primarily on the development of ColdFusion solutions for customers on site. Your responsibilities include, but are not limited to analysing customer and development requirements, preparing technical development documentation, undertaking development based on agreed technical designs, testing of modifications and ongoing development assistance.

About You

The ideal candidate will have a passion for great development, a desire to innovate and be brimming with creativity. An easygoing sense of humour and the ability to get along with a wide range of people are a must.

Technical Skills & Experience

You will have strong technical skills and a willingness to manage tasks through to delivery, ideally supplemented with skills in associated technologies:

2 years minimum ColdFusion experience
Enterprise-level SQL relational databases
ColdFusion components and Object-Oriented Programming
Knowledge of current framework methodologies are advantageous
Developing Flex and AIR-based applications
jQuery, CSS, XHTML and JavaScript
Version control and ticketing systems for project management

Personal Skills

You will possess the skills necessary to work in a team environment with other developers and project managers.

Excellent problem solving and communication skills
Great attention to detail
Self-motivated and driven to achieve professional success in a hybrid development/consulting environment
Ability to manage workload and time according to deadlines set
Good team player as well as have the ability to work on your own initiative without supervision
Resourceful, energetic and enthusiastic

About Fuzzy Orange

Fuzzy Orange Ltd is one of Europe's leading consultancies specialising in Adobe ColdFusion, Flex and AIR. Our client base comprises of local government, transport, new media, technology and entertainment giants as well as small businesses and up and coming dot coms. Fuzzy Orange is the organiser of Europe's leading ColdFusion conference, Scotch on the Rocks.

Fuzzy Orange Ltd is an equal opportunity employer.

Contact

Please email your resume, in PDF/TEXT/HTML format only to info@fuzzyorange.co.uk

No agencies please. No MS-WORD attachments.

Christmas Development Give Away

Mon, 06 Dec 2010 17:11:00 -0000

As it's the season of good will, plus the fact we love giving swag away, we thought we'd put together a little ColdFusion development Santa sack.

Included in the sack are:

1 copy of ColdFusion Builder + 1 year maintenance & support
1 copy of Object Orientated Programming in ColdFusion book by our very own Matt Gifford
1 full pass to Scotch on the Rocks 2011
1 full license of Tasktop Pro (http://www.tasktop.com)

So what do you have to do? Simply send us your best Christmas photo. It could be of your Christmas tree, or you dressed up as Santa ... you take the photo and we'll decide which is the best.

Send your photo to christmas@fuzzyorange.co.uk - Photos need to be with us by Friday 17th December.

New Book: Object Orientated Programming in ColdFusion

Wed, 24 Nov 2010 12:16:00 -0000

Our very own Matt Gifford recently saw all his hard work, long hours and caffeine addiction pay off with the release of his very first book, Object Orientated Programming in ColdFusion. Released by Packt Publishing, this 192 page book is a short but concise manual on how to design and build your ColdFusion Components (CFCs), use Inheritance, encapsulate your code, deal with portability, work with Service Layers and so on and so forth.

The book is a fantastic read for those CFML developers who need a little help in making the jump to working with CFCs, or implement Object Orientated principles. It's also a great refresher for those who have already made the jump.

Visit the publishers page for full details, including special offers.

https://www.packtpub.com/object-oriented-programming-in-coldfusion/book