System Insights

Will Sobel — Sat, 16 May 2009 03:42:00 -0500

Just started System Insights with Athulan Vijayaraghavan. This company is developing advanced software targeted at the manufacturing industry.

For more information visit: System Insights

Capistrano 2.0 and Mongrel

Will Sobel — Fri, 19 Oct 2007 13:09:00 -0500

I’ve been teaching a class over at UC Berkeley on Ruby on Rails and when we got to deployment, I didn’t want to have all the students go through the headache of setting up their deploy repos, configuring mongrel and apache2 on the server for multiple applications. I have canned most of the configuration and setup procedure using cap and svn via http. It took me a little while to figure this all out and I thought it would may be of help to others out there.

This article is assuming you have some control over you own machine as in a VPS scenario. If you’re using shared hosting, cap is pretty much ready to go out of the box and you really don’t have much choice about how things are set up.

I have heard many people complain about the lack of documentation for Capistrano 2.0. It turns out the latest version is actually easier and more robust than the pervious version, but there is no good reference on how to do simple installations. I’ve recently developed a plugin, since cap gems are no longer fashionable, that automates a deployment using capistrano, mongrel, and apache2.

The deploy takes three steps and some pieces have been ported from the railsmachine gem or templating apache multi-app configuration. The plugin imports the code into the repository, checks out a version controlled working directory. Sets up the server directory structure, database, mongrel, and apache2 configuration. And then deploys the application to the server.

In the following article I’ll go over subversion setup, cap scripting for mongrel and apache2, and deployment.

Subversion Setup on Apache2

Subversion can be configured on apache2 fairly easily using web dav and the dav_svn module. There are a few gotcha’s that will have you feeling rather irritated if you’re not familiar with the arcane aspects of apache2 configuration. That being said, I found http to be the most robust way to install subversion for group access and provides the best cross platform behavior.

First make sure you have subversion installed on your machine. Type the following command:

svn --version

If this comes back with the subversion version, you’re all set for the next step. Otherwise you will need to install subversion.

apt-get install subversion

To get subversion working with apache2, your need to install the dav_svn module for apache2. On most linuxs this can be done with:

apt-get install libapache2-svn

This will also automatically activate the module. A quick regression on apache2; in the bad old days of apache 1.x you needed to activate all your modules by hacking at one large httpd.com file. Now, things are better, but if you don’t know where to look, can be a bit confusing at first. In the /etc/apache2/mods-available directory are all the modules that are currently installed. These modules are not available until you create a symbolic link to the /etc/apache2/mods-enabled directory.

For instance, to get the reverse proxy load balancing working in apache2 you need to do the following:

ln -s /etc/apache2/mods-available/proxy* /etc/apache2/mods-enabled/

I almost always use mod_deflate to automatically gzip, so while we’re enabling modules, lets enable deflate as well.

ln -s /etc/apache2/mods-available/deflate* /etc/apache2/mods-enabled

This enabes all the proxy modules necessary for load balancing and deflate modules to reduce the size of your downloads. Simple, eh? Ok, now with those two steps we’re on our way to getting subversion set up. You now need to set up the subversion repository on the site.

Apache2 runs as user www-data and group www-data. The repositories will need to be run readable and writable by www-data. The default permissions on the files in the subversion will need to be changed if you create the repository as owned by anyone other than www-data. I just created it as www-data to avoid the hassle.

So, for the apache2 configuration, you will want to add the following line at the bottom of the default apache2.conf file:

NameVirtualHost *:80

NameVirtualHost allows multiple virtual directories to be associated with the same web server bound to the same port (80) but differentiated by the host name. So, you can have a www.foobar.com and a svn.foobar.com using completely different configurations. Place this line just before the following line:

Include /etc/apache2/sites-enabled/

Now, create the subversion site configuration file in the /etc/apache2/sites-available/ directory.

/etc/apache2/sites-available/subversion:

<VirtualHost *:80>
  ServerName svn.foobar.com
  ServerAdmin admin@foobar.com
  <Location /repos>
    Order allow,deny
    Allow from all
    DAV svn
    SVNParentPath /subversion/repos

    AuthzSVNAccessFile /subversion/repos/repos-svn-authzfile
    Satisfy Any

    Require valid-user
    AuthType Basic
    AuthName "My subversion repository"
    AuthUserFile /subversion/repos/.dav_svn.passwd
  </Location>

  ErrorLog /var/log/apache2/subversion-error.log
  LogLevel warn
  CustomLog /var/log/apache2/subversion-access.log combined
</VirtualHost>

Now, I’ll explain some of the more important parts of the configuration file. In the first few lines you have to tell apache the name of your server so it can choose the correct configuration for the host name. This is done by this line:

ServerName svn.foobar.com

You can add aditional ServerAliass to assoicate the configuration with secondary host names as well. The next piece is the definition of the location or the repository. Serving up the repo via http provides the most flexibility. You can use svn, a browser, and web_dav to access the code.

If you are only serving up one repository, use the following declaration:

SVNPath /subversion/my_application

The path will be the root directory of the repository.

If you have multiple repositories, you need to use the SVNParentPath declaration and specify the directory where all your repositories live.

Now for the fun part, security. Unless you want everyone in the world to access your repository, you need to make sure you can enforce some basic login and access control. You need to enforce both Auth and subversion controls. Either one used separately will not work. If you use Auth you will require the user log in but all commits will be associated with (no author).

On the other hand if you only use subversion authorization, it apache2 will not require a password. The Auth password file can be managed using the htpasswd utility. On LINUX or UNIX, htpasswd defaults to crypt. You should probably use MD5 passwords as they are more secure. To do this use the -m argument. The first time you create your AuthFile, use the -c argument as well.

htpasswd -c -m <account>

For every other account, do the following:

htpasswd -m <account>

You will be prompted to enter the password. The -b option will allow you to put the password on the command line if you’re not worried about someone else seeing it.

Now for the subversion access file:

AuthzSVNAccessFile /subversion/repos/repos-svn-authzfile

This file is a text file you must maintain. Subversion allows very fine grained control over access to different directories and repositories. If you don’t care, here’s the simplest way to get it up and running. If you want more complex control, refer to the svn docs.

In the file: /subversion/repos/repos-svn-authzfile

[/]
user1 = rw
user2 = rw

This will give users user1 user2 full read/write access to all repositories and all directories.

To activate the subversion site, do the following:

ln -s /etc/apache2/sites-available/subversion /etc/apache2/sites-enabled/

And then restart apache2.

apache2ctl restart

That’s it for the configuration of apache2 and subversion using web-dav.

Capistrano 2.0 Deployment

I have created a plugin that will deploy your application in three steps. The first imports the app into subversion, the second configures the servers, and the last deploys the application. The scripts I developed are specifc to the class I’m teaching, but can be generalized to almost any environement.

Since there is scant documentation on cap 2.0, this will hopefully provide an example of what can be done. I got a lot of the ideas by reading the cap source; not the most pleasent way to understand a framework!

If you want to create a template that can be used for multiple projects, this will be of interest. I have used this to quickly deploy student projects with minimal configuration.

For a student to configure their application, they must supply the following information in their deploy.rb:

set :user, 'a_deploy_user'
set :local_user, 'an_import_user'
set :application, 'app_name'
set :group_num, _number_

load 'vendor/plugins/rorclassify/rorclassify'

The number is an integer that is used to compute the ports for each mongrel instance. This keeps all the applications on separate port numbers.

Ruby DB

Will Sobel — Thu, 08 Feb 2007 23:54:00 -0600

For UCB Ruby Class

ruby_db.zip

January AJAX Presentation

Will Sobel — Thu, 18 Jan 2007 21:23:00 -0600

Here’s the code from my AJAX presentation I gave. I’ll write some more later..

Ajax code

Artisanal Software, LLC