Ryan Kanno: The diary of an Enginerd in Hawaii

Since I haven’t put out a technical article in a while, this blog will explain how I’ve setup Dreamhost + Django + Subversion to play nicely together in a seamless development environment via a shared hosting provider. Hopefully – someone, somewhere can find this information useful and insightful in their own development environment.

The very first thing I did was unleash my first Django web application on Dreamhost. Thanks to an excellent tutorial from Jeff Croft, a detailed explanation about FastCGI contained within the Django documentation, and a few helpful pointers on the Dreamhost wiki, I was able to get my application deployed in a matter of a few hours.

You can check it out here!

However, after going through Jeff’s excellent tutorial, I still wasn’t completely satisfied with my Django deployment on Dreamhost. Something was missing. There wasn’t a seamless way to continue development on my home machine, deploy to a test environment, and still keep my live site intact. After all, I’m a true believer in the open source dictum of ‘release early, release often‘, and without a way to test my application on a live server, I wasn’t happy with my configuration management.

Ideally, I envisioned having a live web application (i.e. http://www.wegoeat.com/) and another url that I could deploy my beta releases to (i.e. http://beta.wegoeat.com/). From a configuration management standpoint, I would tag major release builds and to maintain that release over its life (via bug fixes, minor enhancements), I would create a branch of the tag. Thus, the live site would be updated from the branches directory, while the beta url would update from the trunk in my Subversion repository. So to summarize the ‘extra’ steps I did to ensure a smoother deployment cycle, I’ve conjured up the following action list.

1. The very first thing I did was follow Jeff’s tutorial – instead of creating a single directory in my django_projects directory, I created two. One was named ‘project_live’ and the other ‘project_beta’.
2. Next, I checked out the appropriate source files from the appropriate locations in my Subversion repository. The ‘project_live’ directory came from my branches directory and represents my ‘live’ site. The ‘project_beta’ directory came from the trunk and represents my ‘beta’ site. Obviously, the settings.py file for the Django applications as well as the configuration files for FastCGI were different according to the directories. Since my settings will probably be very different then your settings, I’ll leave this as an exercise to the reader.
3. Note, as far as Dreamhost goes, I created two domain entries, one @ http://www.wegoeat.com that will host my live site, and another @ http://beta.wegoeat.com that will be my beta site.
4. I followed my own tutorial and created a post-commit hook to update the appropriate Dreamhost directories when I committed to the repository.

And voila! We’re done.

Now, I can develop on my home machine where I’ve checked out the trunk of my Subversion repository. Whenever I commit, the post-commit hook updates the project_beta directory on my Dreamhost account, and all the while, my live site is still functioning.

Stay tuned for my next blog where I discuss how to get Custom PHP + MediaWiki + EAccelerator playing nicely together on Dreamhost!

Popularity: 24% [?]

I’ve found that many bloggers with Wordpress installations seem to overlook the simple task of backing up their data. Rather, they put their blogging fate into the hands of their trustworthy web-hosting provider. Not that I don’t trust my provider, but I like to sleep knowing full well that my data is resting in a few safe places – rather than putting my eggs all in one basket. So you can either learn the hard way like here, here, and here, or you can follow the simple backup recipe below.

Backing up your Wordpress blog calls for the installation of two very simple Wordpress plugins, WP-DB Backup and WP-Cron, and a dummy Gmail account. After going through the painstaking task of downloading, installing, and configuring each plugin on my hosting provider, I come to find out that other users have reportedthat these plugins have stopped working for Wordpress 2.0.4, the exact version I have installed on my hosting provider. After searching around a bit (how did people live without Googs?), I found this blog posting that outlined the exact versions of the plugins you’ll need to get backups working with Wordpress 2.0.4. In any case, I’ll walk you through the procedure I followed to get my Wordpress installation backed up.

The setup

If you’ve somehow managed to SSH/telnet into your hosting account, you can issue the wget command to retrieve the two Wordpress plugins. I highly suggest creating a temp directory, then cd’ing into the directory to execute these commands.

wget URL/TO/LATEST/WP-DB-BACKUP.zip
wget URL/TO/LATEST/WP-CRON.zip

Note: I didn’t include the URL’s since they are likely to change depending on when this post is read.

The install

After downloading these two files, you’ll need to move them into your Wordpress plugins directory using the following command:

mv *.zip WP_INSTALL_DIRECTORY/wp-content/plugins

Cd into the directory and extract the two zip files using the following commands:

unzip LATEST_WP-CRON.zip
unzip LATEST_WP-DB-BACKUP.zip

Once these files are unzipped, click here to find the files you need to overwrite. This can be done by cutting and pasting the file contents from the blog over to the same files on your hosted account. You can even delete the files on your hosted site and create a new file with the contents from the aforementioned blog.

You pick your poison.

Once installed, login to your Wordpress admin site and find the Plugins link atop the administration panel. You’ll have to ‘activate‘ your plugins via the administration panel. Once you’ve activated both WP-Cron and WP-DB Backup, click on the Manage link atop the administration panel. In the sub panel, you’ll find a new link that reads ‘Backup’.

The config

I highly, highly recommend that before setting up your backup to execute nightly, immediately test to see if you can backup your current Wordpress installation. This can be done by selecting the ‘Email backup to:’ option (fill in an email address) and pressing the Backup button. Once you know that the backups are working (check your email address)… fill in the Scheduled backup section by selecting Daily and filling in an email address. Make sure to add any extra tables (if there are any) that you would like to backup.

You’re probably wondering what the Gmail account was for. Since Google mail offers a sweet 2 GBs of free storage, create an appropriately named dummy Gmail account such as ‘my-blog-backup@gmail.com’ and send all your backups to this address. Periodically, download the backups to your home machine by accessing Gmail via POP, but also leave a few backups sitting in the actual account. If you ever approach the 2 GB storage limit, log into your account via the web and delete the extraneous backups.

Voila! Blog on!

Now bloggers can rest assured that Googs, your hosting provider, and your local machine will have a copy of your current blog.

Popularity: 11% [?]

Update

According to Jeff, Dreamhost has disabled setuid for home directories – which they probably should’ve done years ago. As a side note, some other alternatives include the following:

• Setting the directory permissions to +777 (probably not a good idea)
• Setup cron to perform the same task. If you need an introduction to cron, check out my blog about backing up your Subversion respository

In any case, I’ve since moved half my sites to WebFaction so if you know of a solution, post it in the comments and I’ll write a new blog post about it.

Since Dreamhost has integrated Subversion into their services, I finally decided to take the leap and move my local repository to my hosted account. After all, I was tired of always having to remember to transfer my updated files via scp. With my repository moved over to Dreamhost, I figured I would take advantage of Subversion’s post-commit hooks to automagically update my live beta site.

After reading a myriad of solutions (like here and here ), I found the Dreamhost wiki entry the most helpful. So without further adieu, here’s a small, quick and dirty tutorial on how to automagically get post-commit working with Subversion on your Dreamhost account.

The setup

The very first thing you need to do is create a directory on your Dreamhost account to checkout the source files to (I’m assuming you’ve already created your Subversion repository, have checked files into it, and are ssh’ed into your Dreamhost account.). In my situation, I created a subdomain in Dreamhost called beta.localkinegrinds.com. Dreamhost automatically creates a directory named beta.localkinegrinds.com within the root of the admin account. I cd’ed into that directory and issued the following command:

svn co PATH_TO_FILES_IN_REPOSITORY . --username USERNAME --password PASSWORD

Once checked out, I switched into my Subversion repository directory; it was named svn in the root of my admin account. From there, I went into my named repository, and then into the ‘hooks’ directory.

Here’s where all the fun begins!

First, I created a script called ‘post-commit.script’ that looked like the following:

#!/bin/sh
/usr/bin/svn up PATH_TO_DIR --username SVN_USERNAME --password PASSWORD

I exited my text editor, then issued the following command:

chmod +x post-commit.script

From reading all the forums, the main issue with the post-commit hooks is that svnserve will run the hooks as the Apache user; in Dreamhost’s case, the dhapache user. Thus, we have the following options as described here. We can:

1. Run password-less sudo (which we don’t have access to on Dreamhost)
2. Change the group permissions (which we don’t have access to on Dreamhost)
3. Checkout the files as the dhapache user from a post-commit hook, then change it to update as described here (which I thought was a pain in the rear, not to mention having the directory be world writeable)
4. Compile a small C program with its setuid bit set

Being the programmer that I am, I chose the last option. Basically, as Wikipedia describes, “when a binary executable file has been given the setuid attribute, normal users on the system can execute this file and gain the privileges of the user who owns the file (commonly root) within the created process.” This means that even though the Apache user will run the post-commit hook, it’ll assume the privileges of the user who owns the file (my account) and be able to execute the post-commit.script file we just created!

Neat!

So… taking a look at the Dreamhost wiki, I created the following c program named post-commit.c

#define PATH_TO_POST_COMMIT_SCRIPT "/PATH/TO/POST_COMMIT.SCRIPT"
#include <sys/types.h>
#include <unistd.h>
main( ac, av ) char **av;
{
  execv( PATH_TO_POST_COMMIT_SCRIPT, av );
}

I then issued the following command to compile the program into a binary called post-commit:

gcc -o post-commit post-commit.c

And then to set the setuid bit on the post-commit file:

chmod 4755 post-commit


Voila!

Assuming you set all the correct paths, on a commit to your Subversion repository – your live site will be updated!

As a side note, most of the sites previously mentioned didn’t have any troubleshooting tips. Here’s a few that I ran into along the way:

1. Always test the scripts out first, ie, execute them from the command line and make sure they are doing what you want them to.
2. Apparently, according to the Subversion book, “Subversion repository executes hook scripts with an empty environment.” This is something good to know.
3. If everything was done right, and it’s still not working, try to update your checked out Subversion directory. Sometimes you need to clean up before any other updates can occur. That problem took me a whole half-an-hour to figure out.

In any case, if done correctly, you’ll be on your way to a better development environment!

Popularity: 42% [?]

As a child, I always thought of my dad as the ultimate source of knowledge. His head was incessantly buried in the newspaper solving the daily Jumble and crossword puzzle. To this day, whenever anything is amiss in my life – whether the toilet isn’t flushing, my car’s clutch is slipping, or I need to hang a painting – the phone call to my father is always first on my list.

Over the years, I’ve come to realize that no matter how many academic accolades I achieve – I’ll never know as much as my dad. Don’t get me wrong, my years of schooling has educated me quite a bit… on discrete and differential calculus, complex algorithmic analysis, and other such (useless) topics. All my years of education didn’t teach me the most important lessons of them all… simple life lessons.

I’ve realized that I need to start capturing and documenting my father’s knowledge – before it skips my generation. So without further adieu, I present to you, the first in a short series of “How To’s” featuring the “OG Mr. Kanno” aka my dad… Enjoy!

Popularity: 6% [?]