@madpilot makes

I’ve never been particularly happy with proxying Mongrel processes behind Apache – for one if makes it really hard to scale without using something like God (which adds yet ANOTHER process your website is dependent on) and having separate services means multiple points of failure.

PHP has had mod_php which makes PHP a first class citizen in Apache land, and with the release of Passenger (aka mod_rails) a couple of months ago Rails can now get the same privileges. As most of my production Rails apps (both for me and my clients) run on Joyent, here is a quick recipe for setting up passenger on the newer pkg-src accelerators. You need to be root to do a lot of this, so it might be easiest to

su

before you start.

1. Getting passenger. DON’T use the gem, as it won’t work on Solaris – you need to pull it from git (I think it makes sense to put it in /usr/local):

cd /usr/local
git clone git://github.com/FooBarWidget/passenger.git

2. Run the apache module installer:

cd passenger/
bin/passenger-install-apache2-module

3. Create a configuration file for apache:

cd /opt/local/etc/httpd
echo "LoadModule passenger_module /usr/local/passenger/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/passenger
PassengerRuby /opt/local/bin/ruby18" > includes/passenger.conf

4. Add the following line to /opt/local/etc/httpd/httpd.conf:

Include etc/httpd/includes/passenger.conf

5. Make Apache a little less strict on what it can run. Open /opt/local/etc/httpd/includes/directory.conf and change the Directory directive to (Apache security geeks will probably lynch me at this point – please suggest a more secure setup):

<directory>
Options +FollowSymLinks -SymLinksIfOwnerMatch +MultiViews -Indexes -ExecCGI
AllowOverride ALL
Order allow,deny
Allow from all
</directory>

6. Restart Apache:

svcadm restart /network/http:apache

At this point Apache will be mod_rails enabled. Now to update your application. There is two ways to do this: manually or via the Joyent capistrano receipe. I’ll outline the latter, and you should be able to work out the former for these instructions (Hint: the virtual host descriptions are in /opt/local/etc/httpd/virtualhosts/). Edit config/accelerator/apache_vhosts.erb and find the VirtualHost directive and make it look something like this:

<VirtualHost <%= public_ip %>:80>
  ServerName <%= server_name %>
  RailsBaseURI /
  DocumentRoot <%= public_path %>
</VirtualHost>

Then run

cap accelerator:create_vhost

followed by

cap accelerator:restart_apache

If all went well, your site should be now running via passenger! If all is well, we should remove the mongrel service and update our capistrano receipe, as the restart options are now different. To remove the the mongrel config, run cap accelerator:smf_delete. Finally open config/deploy.rb and remove the start and stop deploy tasks, and replace the restart task with:

deploy.task :restart do
  run "touch #{current_path}/tmp/restart.txt"
end

That should be it. Next time: How to do it on the older Joyent accelerators.

When the Beachhouse closed a couple of months ago, I was back to working from home – which was fine. For a while. As much as our cat was keeping me company, it wasn’t really that good at pair programming, as it’s pads kept getting stuck on the keys, so I got off my arse and did what any other self respecting wog would do – asked my uncles (who are real estate agents) if they had any offices available – and they did – in the same building they were in! So just when you though one Eftos was enough, there is now three (sometimes four depending if my Dedo is in).

After 4 days of painting (when a painter quotes $1200 for three rooms, TAKE IT) the new offices are finally (almost) ready! Out of the three rooms that we have out the back of the Eftos Estates building, one still needs one coat of paint, but the other two are all done!Of course I don’t need three offices myself, so good buddies Grant, Alex, Ben and Gary have stepped up and taking up residency at 220s.

Here are some photos of the two finished offices:

So if you are in Leederville, drop in and say hi!

The address is 220 Carr Pl, Leederville (Just look for the Eftos Estates sign)

As is now becoming a tradition (can twice be a tradition?) I took the A List Apart survey for people who make websites. I see Eric Meyer tweeted that 11,000 people had filled it in just as I was filling it in. Not a bad effort for a couple of days :)

As any website grows, we often find ourselves having to move servers to deal with capacity, or better prices or whatever. This can be a right pain to do, but with a little planning and a few tricks, you can make the process somewhat smoother. In this quick howto, I’ll cover how to move a typical web setup: Web server, DNS, Mail and database. Of course there are more than one way to skin a cat, but this method works quite well if you have a couple of days up your sleeve and has the advantage of only costing you a few minutes in downtime. In this example, we will pretend to move http://www.mycoolwebapp.com from the IP address 192.168.0.1 to the new IP address of 10.0.0.1 (Fake web host, and fake, local IP addresses – substitute with real values).

Step 1. Move your DNS

DNS can be the most painful step, as it can take up to 72 hours to move from one primary DNS server to another. In a nutshell, DNS acts like a big phone book, which tells your browser that http://www.mycoolwebapp.com belongs to the IP address 192.168.0.1. When you enter http://www.mycoolwebapp.com in to your browser, it will ask the operating system for the IP address. If the Operating system has it cached, it will return it. If the cached value looks old (ie the TTL has expired), or it doesn’t know about it it will ask a parent DNS server (or root server) where it can find the updated records, and will then fetch the new records from the relevant DNS server. The TTL is usually set pretty high – in the range of days, as generally Name-to-IP address mappings don’t change much, but if you do change, there means there could be a couple of days before all the servers around the world are updated, meaning your site won’t be found during that time!

Most users don’t have control of the Time-to-live (TTL) value on the root servers, so you need to ensure that both your old primary DNS server, and your new primary DNS server mirror each other. This way, regardless of whether the user get old information or new information, they will still be directed to the same information.

Most users WILL have control of the TTL on their own servers, so we can set that to something small which will make switch over much easier. Make note of the TTL on your old DNS server – you will need to wait that long after changes things before you can switch over to your new server. Setup your new DNS server to point to the old server (192.168.0.1) – ensure that all of the values are exactly the same. Now, on both servers, set the TTL to something very small, say 10 minutes (which is 600 seconds).

As this can take a couple of days to for the root DNS changes to propagate, you may as well change the root DNS details now. This will usually done via the domain registrars control panel. Simply change the primary and secondary DNS server IPs from the old DNS servers to the new ones (192.168.0.1 to 10.0.0.1 in this example). Make sure you double check all the values, because if you make a mistake it can take days to rectify!

Step 2. Setup the new webserver

Now that the DNS is setup and in the process of re-delegating, you can setup website on the new server for final acceptance testing. This is usually the easiest part of the process. What I do here is deploy the current software to the new server, take a snapshot of the database (phpmyadmin helps here if you are on MySQL, but each database system has a mechanism for backing up the database) and copy over any uploaded files etc. Now, most shared hosts will use virtual hosts, which means it serves up different pages based on the domainname, not the IP address, and if your software relies on the domain name for functionality, it can be really hard to test all the functionality with out the having the name-to-IP address mapping in place (remember, at this point http://www.mycoolwebapp.com is still pointing to 192.168.0.1).

Hosts file to the rescue! You might not know this, but all the major operating systems have a “hosts” file, which is checked before a DNS check is made, so if the operating system finds the requested domain name in that file, it won’t even bother querying the DNS server. By associating the new server IP address with the domain name in this file, we can actually view what is going on on the new server (Just don’t forget to delete the entry when you are done!). Windows users can find the file in c:windowssystem32driversetchosts, and Linux (and I’m pretty sure OSX users) can find it in /etc/hosts. There is usually examples in the files, so it’s best to follow those, but I know these values work for Windows and linux:

10.0.0.1    www.mycoolwebapp.com

You may need to restart your browser for the change to take effect. Now if you go to http://www.mycoolwebapp.com you will be taken to the new server allowing you to set it up and check everything is working properly with out affecting the currently live version.

Step 3: Setup mail

Email can be pretty painful to setup, and is one of those things that will get you in a lot of trouble if you stuff it up. First off all you need to know all of the email addresses associated with the domain. If your hosting provider uses a web admin control panel like Plesk, this is usually pretty easy. Mirror all of the accounts on the new server, and make sure all of the quotas are either equal to or greater than the current values. If you need to setup new passwords for all of the accounts, note them down, as you will need to notify each user of their new password. Don’t forget to check for things like aliases and forwards.

Step 4: Check and double check

Make sure you note down any other bits and pieces that may have been setup, like cronjobs, other services and make sure that things like mail contact forms etc actually work. There is a trick here for young players with email forms – the resulting email may go to the new server, not the old one, so if you test a contact for and no email appears, check the new server.

Step 5: The big move

The way I usually play this is to replace the website on the old server with a “We are down for maintenance” page. This has the advantage of ensuring no one posts any new information whilst the the site is in flux and also gives you a visual confirmation that things worked. If your server can use .htaccess file, this is pretty easy using a rewrite directive. If the framework you use has friendly URLS, there will probably already be a .htaccess file that tells the server to rewrite the URLS to file – this is the simplest solution – just create a maintenance.html file and change the rewrite to look like this:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ maintenance.html [QSA,L]

This allows you to still access CSS, images and JS files, so you can style the maintenance page, but any request to a file that doesn’t really exists will get piped through to the maintenance.html file.

If .htaccess isn’t an option or you have a lot of static file, you might have to do the old fashioned “move the current site root and replace with a new one” trick (There are rewrite rules you can do, but this just might be easier). Create a new directory that has the maintenance file (You would probably have to call it index.html in this instance) and put any associated images, CSS and JS files. Then move the current site root (for example public_html) to say, public_html.old and then move the new directory to replace the old one (ie public_html). When you view the site on the old server (you might need to remove the entry in the hosts file to see it) you should now see the maintenance message.

Next, re-sync the database and any new uploaded files and give the new server a final test (by putting the hosts file entry back in). Once you are happy everything is working, we can flick the DNS over.

Step 6. Flicking the DNS

On both the old and new server, change the IP addresses for all of the relevant entries from the old IP address to the new one. Within 10 minutes, everyone should be seeing the new server’s version of the site! This also means that all of the email will be heading to the new server to, so…

Step 7. Re-configure mail clients and syncing up folders

If you configured new passwords for all of the mail clients, they will need to enter the new password into their mail clients. I generally walk them through creating a NEW mail account on their clients – the reason for this will be revealed in a second.

If they have been using POP in the past, then they will probably already have local copies of their email, so your job here is done. However, if they are using IMAP (probably more likely now) you will need to sync up the two accounts. There are tools out there that can do it, but you will need to know the passwords on both servers, and they can be a bit hit and miss – thankfully you can use the users mail client to do the sync.

Simply create a new account on their mail client that points at the new server, and change the old account to point to the IP address of the old server. If done correctly, the user should now be able to access their old email and folders as well as any new email on the new server. Most mail clients will actually allow you to drag folders across servers – do that and your email will be synced up! (It might take a while, if they have a lot of archived mail). After that is done, you can delete the old account and set the new account to default.

Step 8. Shutdown the old server

The final task is to shutdown the old server. I usually leave it running for a week to be on the safe side, mainly to recover any email that the user forgot to move across (It ALWAYS happens).

Step 9. Do and get a drink

You deserve it – it’s probably been a big week!

I hope that this made sense, or at least acts as a resource when you try to explain to a client why it can take a week to move servers! Of course, these instructions are pretty general, so your mileage may vary. Golden rule is don’t rush and double check everything!

For the past twelve months, I’ve been a house mate at the Silicon Beach House – the collaborative, shared office space in the Perth CBD. Having seen a number of arrivals and departures over the past year, it will see it final set of departures, as it closes and gets turned into a resort (Ok, some other company is taking over the lease, but I started this metaphor, and I’m going to finish with it god damn it).

Unfortunately, due to a number of factors, it wasn’t viable to keep it open so whilst the idea of having a shared working space isn’t dead, it’s been cryogentically frozen until sometime another suitable venue can be found. So if you are in town, don’t try to drop in any more, as, well you’ll freak out the new occupants. For those of you who want to find me, I’m back working from the home-office, so if you are in Mt Lawley, give me a call and we can go for coffee :)

Being an active member of the local web community, I’m often speaking to students at Port80 meetups, about the best way of getting work, and it isn’t an easy question to answer – and it seems that I’m not the only one – both Alex and Gary have recently blogged about apprenticeships, graduate programmes and internships.

The problem we seem to have at the moment, in Perth anyway, is the number of companies large enough to be able to take on interns and run graduate programmes is pretty small. I’ve seen this in the software industry – I remember vividly the last 6 weeks of final year, where every soon-to-be graduate was sending resumes to the big three software companies that ran graduate programmes – the numbers didn’t add up as there was many more applications, than positions. Of course, there is more than three software companies here – however many of them looked for people with some industry experience.

So the problem is a chicken and egg one – no experience means no job, and no job means no experience. I think the education institutions need to get a bit creative with how they are teaching. A perfect example of this is the Centre for Software Research at UWA run by my old honours supervisor and mentor, Dr. David Glance. I was lucky enough to be the first student to go through this system, and not only has it given me some great contacts, it gave me  valuable experience. They take internal university projects, and get final year students and graduates to work on them. They also take on some external projects, the proceeds of which pay for the running of the centre – and the student wages. This is a win-win on so many levels.

1. The students get practical experience working with a Project Manager, a client and deadlines. And they get paid to do it.
2. The lecturers, who acts as the Project Manager gets to keep their fingers on the pulse of what is happening in the real world – which is invaluable in such a fast moving industry.
3. The University can implement and experiment with adding systems to improve their work flow for little practical cost.

Of course these programs aren’t a silver bullet, and take resources, but in my opinion they a big step forward from handing someone a certificate and then throwing them in the deep end of the real world.

I’m not sure how well this metaphor is going to extend outside of people from Christan or Jewish backgrounds, but I can’t think of a decent non-denominational analogue, so bear with me.

As has been the tradition for many, many years, when a child is baptised, the parents select Godparents. Now originally, it was the Godparents responsibility to ensure the childs religious well-being – however, I (perhaps under some childish misconception) always thought of them as the next in line for guardianship if my folks died or disowned me.

Why don’t we do this for businesses? I’m a freelancer and if I got hit by the #66 on it’s way to Morley would there be anyone to notify my clients? It’s a bit morbid to think about, but we write wills for such an event – but how many people think about this for their business?

Even if you had the best documentation in the world, and kept your Outlook contact list up-to-date, it is all pretty worthless if nobody can access it, so they can contact the people that need to get contacted. So I’m proposing a system of Business Godparents – someone that can go in if the unimaginable happens and sort things out, to make sure your clients aren’t left high and dry.

Things to look for in a potential candidate:

• Be someone you trust. You are basically giving them sensitive business information – if you think they will take your client list and start cold calling them , they may not be the best person.
• They don’t have to be in the industry, but make sure they have a list of people that they can contact in-case of emergency. Having someone in the industry does have the advantage that they can start taking care of your clients right off the bat.
• Your accountant might  be a good choice – they already knows your business intimately, so what is a few other bits and pieces?
• Family members are probably good candidates as well.

What they will need to know and have access to? Well, that depends on the industry you are in – but if you are in the web industry you might include:

• Your client list. They will obviously need to be able to contact your clients to let them know, as well as be able to do things like release source code, or graphics or whatever.
• Usernames and passwords. This one is a bit tricky – obviously good password security states that no-one else should know your password, and that you should change it regularly. Maybe you could have a “needs to know” policy, where you spread the knowledge amongst a number of people. A non-industry person might be an advantage, here. If your accountant or a sibling has a “master password” (or a USB key with a private key certificate) that they can give to a nominated “person  (or persons) in the know”, there may be a smaller risk.
• Names of services that you use, such as domain registrars, hosting companies etc
• A list of other organisations that could potentially take over certain jobs, as well as a list of other stakeholders in the project. If the job was inherited from another firm, or if the job was a joint venture, it may be really easy to hand it over.

This is a bit of a brain dump, so feel free to leave comments on how this could work. What would you include in the list? How could you get around the security issues associated with password lists? I’d love to hear your thoughts.

WANTED: Freelancers, startups, consultants or small businesses who need some office space.

If you are a small business, freelancer, consultant or a startup and you have out grown your back room but can’t quite afford a swish office of your own, the Silicon Beach house could be just what you need! Even though we seem to have attracted a number of developers and graphic designers, we are open to any body who is desk-bound by day.

One of the great things about having people with different skill sets is if you come across something that you can’t do, there is quite possibly someone there who can (Within reason – we don’t have any wood-workers, so asking questions about lathing may not get such a quick response). Personally, I would love to see an accountant and a lawyer join us, so I can pick their brains! We are all friendly, maybe a little talkative, but all in all it is a great place to work.

You can see the inside of the office below – but it is a second-floor open plan office with a small board-room table, kitchenette, a couple of couches and (obviously) some desks. It is fully furnished, so basically you just need to bring your computer. Whilst many of us just bring our laptops, a couple of us do leave desktopmachines there, and we all leave external monitors, so your stuff will be safe.

The beach house has a monitored alarm, ADSL connection, wireless, printer/copier/fax machine and water cooler all included in the rent (which is pretty darn reasonable), is REALLY close to the Perth train station (It’s across the road) and is basically slap-bang the middle of the city CBD. If you want more information regarding prices, please contact me, and I’ll put you on to the right person.

If you are interested in coming and having a look, we are at

Level 2, 90 King St

Perth WA 6000

[Google Map]

So what are you waiting for?

Anyone who has ever freelanced knows that being your own boss is great, but it can also be lonely. Being able to work in your pyjamas is convenient but not being able to bounce ideas off other people can be frustrating. As many of you know, I work in at the Silicon beach house which is a shared office space and we have a board room table and some couches that are less than utilised, which kinda made me think – we should have a freelancer day! And so you, kind people of the intarwebs, I present Freelancer Friday.

The idea is simple – bring your laptop and bring your work. We all sit around doing said work, but we can bounce ideas off each other, try different things out or just generally find was to distract each other :)

It is really similar (if not exactly the same) as the Work At Jelly initiative, so if you have heard of that, you will know what we are talking about.

So we will be running the first Freelancer Friday in two weeks on 26 October 2007 at the beach house – Level 2 Kings St, Perth. There will be someone there by 9, so any time after that is cool.

Grant and I are feverishly plugging away at building a web site around the idea, and it should be up soon, but we don’t have to wait for that. If you are interested, please email me on myles@madpilot.com.au

Edit: Oops, nearly forgot – if you aren’t in Perth and think the idea of a Freelancer Friday is cool, start your own one up! Invites some freelancing mates over to your house and get to work. It’s really easy to do. They don’t even have to web type people ;)

Whilst we are on the topic of memes, I’ve just posted my “This is me, I work on the Web” meme post on Flickr. If you work on the web, I would do the same – just remember to tag it with I work on the web.