Install Subversion on the AWS Cloud

The Subversion Manual for Version 1.7 | The 4 Subversion Security Configurations – Choose One

Subversion Command Catalogue

  • Subversion Import Command | svn import – import a folder into the subversion repository
  • Subversion Export Command | svn export – export a versioned folder into the local filesystem

Did you know we offer free Subversion hosting? Drop us a note below and we will send your username/password – opening up 7Gig of free repository space.

Steps to install Subversion on an Amazon EC2 Cloud Server

Follow these steps to install Subversion on an Amazon EC2 cloud machine

  1. Install the Subversion Server and client
  2. Create the Subversion repository with svnadmin
  3. Put Subversion behind the Apache2 Web Server
  4. Setup the Subversion users and passwords
  5. Import a local folder into the repository

1. Install Subversion Server and Client

The Subversion Client package must be installed on every server that needs to access the repository.

Typically – only a build server running Jenkins, SBT and/or Maven needs to access a repository. Ensure Subversion and the Build Architecture are on different servers due to their nature.

Install the Subversion client first. Then put down the libapache2-svn subversion server. This is how.

sudo apt-get --assume-yes install subversion

sudo apt-get --assume-yes install libapache2-svn

Create a Subversion Repository

You can create the base repository at /var/www/assets. Then all your repositories fall under this directory. They could be data assets, software assets, recovery assets, script assets and so on.

sudo svnadmin create /var/www/assets
sudo chown www-data:www-data -R /var/www/assets

If setting up a production repository you should seek advice on setting the permissions. As we are learning, this setting provides the smoothest possible ride.

sudo chmod 770 -R /var/www/assets

Test Your Subversion Repository

sudo ls -alp /var/www/assets

The svn list command from the repository server can directly access the repository using a file url. From external servers use a http based url.

svn list --verbose file:///var/www/assets

2. Use svnadmin to create the Subversion repository

Why are we creating a test repository?

Why set up a small test repository?

Setting up a small repository is vital for configuring (and testing your configuration) Apache web access configuration.

The Before Test

Run this command and you should get very little back – that is okay.

svn list --verbose file:///var/www/assets

The command should reply like this.
         0 ? Feb 17 09:23 ./

Create a Test Folder and a Couple of Files

Go to your home directory and run this.

mkdir test-assets
cd test-assets/
touch testfile1.txt
touch testfile2.txt

Now add some text to your 2 new test files.

Import Your Test Folder Into Subversion

To import the folder we use the svn import command.

svn import -m "test subversion import" /home/<<your-home-dir>>/test-assets file:///var/www/assets

Get Used to It

The folder test-assets will NOT appear in the subversion repository.
Only the two files that we named testfile1.txt and testfile2.txt are imported into the repository.
This quirkiness exhibited also by tar, rsync and other svn commands like svn checkout and svn export goes with the Linux territory.

We have to just get used to it and get over it.

Now let us test the import.

Did the Subversion Import Work?

Run the svn list command again.

svn list --verbose file:///var/www/assets

This time you should be rewarded with a reply stating your two files. Good.

The time has come to configure repository access through Apache.

3. Use Apache as a Proxy for Subversion

The “behind Apache” pattern is rife for middleware services be it WordPress, Tomcat, Jira, Jenkins, Wikimedia or Nexus. Reuse is the key that underlies the “behind Apache” pattern – and the corresponding system administration benefits.

Installing HTTPS with certificates for each and every middleware service is rarely justified. Putting the gaggle of middleware services under Apache’s skirts and running a HTTPS (SSL) transport to the proxying web server is simple and usually good enough.

Why employ other transport protocols (like svnserve) for client access to subversion? In that regard HTTP/S is ubiquitous. Don’t look any further.

Running Subversion so that it can be accessed via untrusted networks is a common requirement. Sometimes we want Subversion in the cloud, at other times we need it accessible to our extranet, and for open source – we need the software in subversion to be world readable.

  1. How do we put Subversion behind the Apache Web Server?
  2. How do we enforce HTTPS for every Subversion request?

Although optional, it makes sense to put Subversion behind an Apache proxy server and also to enforce the HTTPS for all Subversion traffic.

Now even with open source and a world readable Subversion repository, you most likely do not want anonymous users checking in willy-nilly to your repository. You want to configure authorization for repository commits.

4. Subversion users and passwords

Authorization for commits whilst allowing anonymous users (anon) to read is the mantra of open source projects.

Enforce HTTPs and Do Regular Backups

You must enforce HTTPS (Secure Sockets Layer) to prevent exposing snoopable plaintext passwords to unwanted and uninvited electronic eyes.

Regular Backups – Through cockup or conspiracy your repository can get corrupted. If and when this happens, your ability to recover it to a last known good state will come under scrutiny. Backups and recovery practice is paramount if you don't want to be found wanting.

Update the svnserve.conf Configuration

This configuration file is within the repository you created with svnadmin create.

Uncomment these 3 lines.

anon-access = read
auth-access = write
password-db = passwd

Creating Subversion Users and Passwords

We must setup a username/password for each repository commit actor (people and/or systems).

To ensure you have the htpasswd run

sudo apt-get install apache2-utils

If it is already installed the above command will do no harm.

WARNING – Only use the -c switch once. If you use it twice it may OVERWRITE your current username/passwords.

sudo htpasswd -c /var/www/assets/conf/passwd <<username>>

You will be prompted to enter a password (twice). Do this for every commit account.

This reciprocal command deletes a user.

sudo htpasswd -D /var/www/assets/conf/passwd <<username>>

Creating the 2nd ++ Users

The next time you run the htpasswd command you must ommit the -c (create file) switch to avoid overwriting the previous entries.

sudo htpasswd /var/www/assets/conf/passwd <<username>>

5. The First Import into Repository

The first import can be tricky so follow this advice carefully.

Create a folder with mkdir <<-- local-parent-folder -->>
The name local-parent-folder will NOT appear in the subversion repository. The contents under local parent folder will be the root contents of your repository.

So it is good practice to have just folders (not files) inside local-parent-folder.

svn import -m "The first repository import." <<-- local-parent-folder -->> --username "apollo" --password "Apollo-password"

Note that the test-assets

Substitute values for local-parent-folder, the server host name, the username and password (if check-ins require it).

Leave a Reply

Your email address will not be published. Required fields are marked *