Recently at work my co-workers and I have been working on a fairly large and complex website (which will be top secret until early next year🙂 ), and we have encountered one of the pitfalls associated with group web development: Overwriting each other’s code with FTP. The natural solution was to use Subversion to manage our source code. We created our repository, checked out our local copies, and regularly updated and committed our code. While this greatly reduced the frequency and severity of our FTP mishaps, it did not eliminate them entirely. As tension began to mount (exaggerated greatly for literary value), we decided to seek a better solution… something that would allow for our development server to automatically reflect the contents of our source repository. We eventually settled on the use of a post-commit hook, which for those of you who are new to subversion is simply a script (which can be written in any language your server understands) which is executed every time anyone commits to the repository. Unfortunately for us our Subversion Repository was hosted on a third party server, and we did not have access to the server to write the hook. This meant that we were going to need to create a new repository on a server we could access. We chose to use the Web Server we host our site on, just because it reduces the overall complexity of our setup considerably. The following steps were implemented on an Ubuntu 11.04×64 server, but the steps should be nearly identical (with the exception of possibly the package management) on any modern Linux server.
Using Subversion to Automatically Publish Your Website
Install Subversion and Subversion Apache Support
sudo apt-get install subversion libapache2-svn
Create the SVN Directories
You can place your SVN Root anywhere you would like on the filesystem, but I chose to place mine in /svn, feel free to edit these commands to reflect your desired location. Also, in my example I change the ownership of the svn directory to the user/group www-data. If you are using a different Linux distribution you may need to check to see which user Apache runs as by default, and adjust the commands accordingly.
sudo mkdir /svn sudo chown www-data:www-data /svn
Creating Your Repository and Configuring Apache to Serve It
We need to configure Apache to know the location of our repository (which I realize we haven’t created yet), so point your favorite text editor (I’m a Nano guy) at /etc/apache2/mods-available/dav_svn.conf:
sudo nano /etc/apache2/mods-available/dav_svn.conf
By default almost everything in the file is commented out. While it is possible to set up your repository to allow anonymous reading (and is in fact the default option), I opted to require authentication for every action on this repository since this source code will most likely end up containing database user credentials. Since an example of setting up anonymous reading is in the configuration file, I will allow you to un-comment it if you would like to use it. Here is an example of the config file I am using:
<Location /svn/repository> # Uncomment this to enable the repository DAV svn # Set this to the path to your repository SVNPath /svn/repository # Authorization Data AuthType Basic AuthName "Subversion Repository" AuthUserFile /etc/apache2/dav_svn.passwd Require valid-user </Location>
There are a few things to note about the above file. The first is the tag, which needs to point to the location we plan to create the repository in. Also note that SVNPath should point to the same location. The next section contains data about how to authorize users. I used basic .htaccess style authentication, with an auth file located at /etc/apache2/dav_svn.passwd. The last line before the closing tag states that only users with a valid username and password are able to access the repository.
Now that we have Apache pointed at the repository, let’s create it! In order to prevent permissions issues, we need to become the www-data user:
sudo su www-data
when asked for a password, enter your own password. Now that we are the correct user, let’s create the repository at the location we specified above.
svnadmin create /svn/repository exit
Now that the repository exists and Apache is configured to see it, we need to restart Apache to refresh the configuration:
sudo /etc/init.d/apache2 restart
After a moment, try to point your browser to http://%5Byourdomain%5D.com/svn/repository. If everything is configured correctly you should see a password box pop up. Of course, there are no users authenticated for the repository, so at this point you can’t get in.
Creating Your SVN User Accounts
Now that the repository is set up, we need to have authenticated users to commit to and update from the repository. When creating users, the command to create the first user is slightly different from the command to create all other users. For the first user do:
sudo htpasswd -cm /etc/apache2/dav_svn.passwd username
and for the rest do:
sudo htpasswd -m /etc/apache2/dav_svn.passwd username
After creating a user for yourself, go back to http://%5Byourdomain%5D.com/svn/repository and enter your username and password. If all goes well, you should see a screen indicating that your repository is at revision 0.
Setting Up Your Website to Retrieve Data from the Repository
There are several way to do this next step, and several things to consider before choosing a path. If your website already exists, you may want to set up a new virtual host on your server to hold the new copy until you are satisfied with the performance of the repository, or if you have an up to date local copy you may feel free to simply delete your old directory on the server (as we will be remaking it in a moment). Another thing to consider will be subversion configuration directories inside your website. If your server is configured like mine, it denies access to .svn directories, and an svn checkout command should be an easy way to accomplish our task. Otherwise, you may want to consider using an svn export command instead. Since my server is configured to be safe with .svn directories, I decided to go with the checkout command. Since my website is located at /var/www/mysite, the commands to do a fresh svn checkout is:
sudo rm -rf /var/www/mysite cd /var/www sudo svn checkout file:///svn/repository mysite --username yourusername --password yourpassword
You should now have a basically empty directory, which has the distinct advantage of being able to be quickly updated to contain the contents of the repository.
Updating Your Website After SVN Commit
Now that the repository is set up and our website is pointing to a working copy, we can set up our post-commit hook to update the website every time a commit is made. Due to the somewhat complex nature of Linux permissions, we will be performing three main steps to accomplish this goal: Creating a script to update the working copy in our webroot, giving the Apache user (in my case www-data) the ability to run that script as root without a password, and then creating our hook to call that script as root.
First we create the script (Note: this command will open Nano to a blank file for you to edit and as soon as you save the file it will also make that file executable):
sudo nano /usr/local/bin/svn-post-commit-update-mysite && sudo chmod +x /usr/local/bin/svn-post-commit-update-mysite
And inside place:
#!/bin/bash cd /var/www/mysite && sudo svn update
This code will simply navigate to the working copy we checked out in the last step, and run svn update. This should update the contents of that folder to reflect the contents of the repository.
Next we will give the Apache user the ability to run this script as root without a password by editing /etc/sudoers
sudo nano /etc/sudoers
and adding the following line:
www-data ALL=(root) NOPASSWD: /usr/local/bin/svn-post-commit-update-mysite
Next we will create and edit the post-commit hook for the repository:
sudo nano /svn/repository/hooks/post-commit && sudo chmod +x /svn/repository/hooks/post-commit
And inside place:
#!/bin/bash sudo /usr/local/bin/svn-post-commit-update-mysite 1>&2
Testing Your Setup
Now that everything is theoretically set up, all we have left to do is test. The best way to do this would be to do an svn checkout on your local machine, copy the local backup of your website into the folder you performed your checkout into, and then attempt to run a commit on your working copy. If all goes well, you should be able to point your web browser at your Website and see what you just committed.