Sean O'Donnells Weblog
Tech Camp Ireland looks like it will be a lot of fun. Theres a pretty diverse range of speakers. If you have Saturday the 15th of October 2005 free and a pet project or technology you can't shut up about why not come along? This many geeks in a room can't help but result in some interesting ideas.
Well my pleasant week off has come to a close. I just spent the evening in my parents house freeloading a meal and taking it easy. My little trip to Cork was pleasant and did the job of breaking my normal routine quite nicely.
Me being me , I have of course spent a fair amount of my time hacking. A new release of Ogham draws ever closer, and this blog is looking a lot more healthy. I have written all of the Vellum plugins I need to spend more time using it and less time hacking on it. I am planning on releasing all of my additions/changes soon. I have to come up with something to justify all that time playing with subversion.
I had more than few headaches getting Subversion up and running on Sarge or Etch. For my money Subversion is the best free source control system out there. I know fans of the distributed systems like arch will probably jump down my throat for saying that, but my experience is that if I want the source to a project using Subversion I can get it quickly and easily without having to immerse myself in a ton of documentation. I do not need to pass weird command line arguments like I find myself doing with CVS. It is easy and it works. (update, a long time has passed since this tutorial was originally written, I think subversion still makes a good first source control system, but I would recommend anyone who knows their way around to take a look at mercurial, bazaar or git, these systems are not that much harder to use but give you a lot of useful features subversion simply does not have) So without further delay, If you would like to know how I installed and configured it, read on.
Before we start, our goal is to set up Subversion and Apache2 using SSL for access with the ability to host multiple repositories on Debian Sarge and running the Subversion site on a subdomain as a Virtual Host. If thats what you want read on and we will walk through it step by step
Simplicity itself, log in as root and run
apt-get install apache2
Then run the script
to set up a SSL certificate for Apache.Debian etch seem to be missing this script, but the following command will do the same job if apache2-ssl-certificate is not there.
export RANDFILE=/dev/random mkdir /etc/apache2/ssl openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem -keyout /etc/apache2/ssl/apache.pem chmod 600 /etc/apache2/ssl/apache.pem
Yet again, pretty easy
apt-get install subversion libapache2-svn subversion-tools
Make a directory for our Subversion repositories to live in ( I am planning on having more than 1)
su cd / mkdir /subversion
chown www-data:www-data /subversion
We need to create another directory below this for the individual repositories to live in, yet again Apache needs access to all of these directories so we will use su to switch to the www-data user in order to create them
cd subversion su www-data
I called my base directory public, it doesn't have to be called public, thats just my choice. If you want to call it something else go ahead, just watch out for the references to public further on.
mkdir public cd public
Now we can actually create a repository, the first repository I wanted to create was for my ogham project. so...
svnadmin create ogham
First of all we want to use SSL to connect to our repositories so we need Apache to listen for SSL connections on port 443.
Add the line
Now we will create the Virtual Host
Create the file /etc/apache2/sites-available/subversion. Edit the file to look like the following. I will go through it line by line in a moment
<VirtualHost 220.127.116.11:443> ServerAdmin email@example.com ServerName svn.odonnell.nu LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so SSLEngine On SSLCertificateFile /etc/apache2/ssl/apache.pem <Location /public> Order allow,deny Allow from all DAV svn SVNParentPath /subversion/public AuthzSVNAccessFile /etc/apache2/auth-files/public-svn-authzfile Satisfy Any Require valid-user AuthType Basic AuthName "odonnell.nu Subversion Repository" AuthUserFile /subversion/.dav_svn. passwd </Location> ErrorLog /var/log/apache2/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/access. log combined </VirtualHost>
Ok , line by line here is what we have done
The Virtual Host should listen to port 443 on IP Address 18.104.22.168, obviously you will need to change the IP to that of your server.
I want the server to be called svn.odonnell.nu , I have already created the DNS records for this subdomain and this tutorial does not cover the creation of those DNS records. You will have to alter this line to reflect the subdomain you want to use
Load the modules required for Subversion and SSL to work. Apache may already be doing this in which case it will give a warning when starting that they are already loaded.If that is the case the relevent lines can be removed.
LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so
We want Apache to use ssl for this virtual host and we want to use the ssl key in the file /etc/apache2/ssl/apache.pem. The apache2-ssl-certificate script we ran earlier should have created this.
SSLEngine On SSLCertificateFile /etc/apache2/ssl/apache.pem
The following settings apply to urls that look like https://svn.odonnell.nu/public, if you remember from earlier, public is also the name of the parent directory for the various repositories. I am not actually sure if the two have to match, but this is one of the parts I had a great deal of trouble with, so I am not going to mess with it. If someone with more expertise than me wants to clarify the matter, I will update this document accordingly.
Accept all connections, Apache seems to deny all by default on sarge.
Order allow,deny Allow from all
Use the svn_dav module instead of the normal webdav module. svn_dav is a superset of normal webdav.
Our Subversion repositories can be found under this directory
This file contains details of which users are allowed to access which repositories. We will create it shortly.
One of the following authentication schemes must be satisfied or Apache will return a 403 Forbidden Error ( I was sick of these before I got it all to work correctly). We are only going to use one authentication method HTTP Basic Authentication.
We require that the user who connects be a valid user from the file specified in the AuthUserFile line (we will create this file shortly). We will authenticate that user using Basic Authentication. The Authname line simply provides the text that appears in the title of the login window when it appears. Change this to whatever you like.
Require valid-user AuthType Basic AuthName "odonnell.nu Subversion Repository" AuthUserFile /subversion/.dav_svn. passwd
Use the standard Apache error log for error messages.
Log everything as serious as a warning and worse. Any line in this config file beginning with a # is just a comment, so only the last line here actually does anything.
# Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn
Use the standard log file for logging access to this website.
CustomLog /var/log/apache2/access. log
To actually enable this site configuration.
ln -s /etc/apache2/sites-available/subversion /etc/apache2/sites-enabled/subversion
This just means if you ever want to turn the site off you can simply delete the file in sites-enabled and restart Apache, to turn it back on re-link and restart Apache.For example if you find that this tutorial is not working for you and Apache wont start, just delete the file in sites-enabled and you can come back to it later.
In the virtual host configuration we specified that we would store our valid users and passwords in /subversion/.dav_svn.passwd. Its time to create it. logged in as root run
htpasswd -cm /subversion/.dav_svn.passwd sean chown www-data:www-data /subversion/.dav_svn.passwd
The first line creates the file and adds the user sean (it will prompt you for a password), the -c switch actually creates the file, so to add another user drop the c from the command like this.
htpasswd -m /subversion/.dav_svn.passwd dave
That will add the dave user to the file without wiping the sean user, which it would do if you did not lose the -c switch. The second file we have to create describes which users can access which repositories once they have logged in. In the virtual host configuration we said we would place the file at AuthzSVNAccessFile /etc/apache2/auth-files/public-svn-authzfile. So create this file and edit it to look like this. Yet again I will go through this line by line in a moment.
# directory specific authorization control [groups] owner=sean ogham-developers=sean [/] @owner=rw [ogham:/] @ogham-developers=rw *=r
The first groups section sets the owner of the entire installation to be sean, and then creates a group called ogham-developers and adds sean to it. If you wanted to include the dave user in the group as well , it would look like.
# directory specific authorization control [groups] owner=sean ogham-developers=sean, dave
This file is extremely touchy about format, if you get 403 errors later, check you haven't added any unnecessary whitespace, tabs, or anything else. If you cant see anything wrong with it, delete it and create it again, there might be a weird little typo there you cannot see.
Next we give the owner (sean) read write permissions on the repository root. This effectively means sean is the only one who can create a new repository
Now we give everyone in the ogham-developers group read write access to the ogham repository.
[ogham:/] @ogham-developers=rw *=r
And finally we allow everyone read access on this repository, if you do not want your repository to be publicly readable, then don't add this line
For more details on the syntax of this file check here http://svnbook.red-bean.com/en/1.1/ch06s04.html
Once you have finished settings up your users and groups, change ownership of the file to www-data so Apache can read it
chown www-data:www-data /etc/apache2/auth-files/public-svn-authzfile
Ok, we should be in business now, restart Apache
If you did not get any errors, we are ready to import some code into our repository
I keep my development version of ogham in /home/sean/ogham on my laptop, so I switch to that directory.
And now to import the code into the repository.
svn --username sean import ogham https://svn.odonnell.nu/public/ogham -m "Initial Import"
The syntax is svn [user to log in as] import [directory to import] [address of repository] -m "[comment]"
If you now browse to your equivalent of https://svn.odonnell.nu/public/ogham you can browse the source tree. If you did not enable public read access you may need to log in first.
To check the code out again, run the command
svn co https://svn.odonnell.nu/public/ogham
Which is the same command anyone will use to check the code out for the first time.
For a nice tutorial on the basics of Subversion see
There is also a very comprehensive Subversion Manual available online.
I hope you have now successfully installed your own repository and are enjoying it. I would like to thank Nelson Castillo for his tutorial and Vinay Venkatesh for his tutorial. This tutorial largely consists of me patching their works together to get the configuration I wanted and without them I would still be scratching my head while looking at 403 Forbidden errors.
All comments, tips and corrections will be gratefully received.
To check it out install subversion and run
svn co https://svn.odonnell.nu/public/ogham
Johnaton Ellis seems to think that there is no way an Ajax app like Meebo can compete with traditional desktop IM clients. And in many ways he is right, but in just as many others he is missing the point. How many corporate desktops are locked down tight so you cannot install any unapproved applications? His take on this kind of Ajax app seems to be "When all you have is a hammer...[everything looks like a nail]". For those with a more nomadic pattern of computer usage you cannot depend on having the perfect tool for the job at hand.
I recently replaced the perfectly good RSS Reader Liferea with a private installation of TinyRSS. Liferea is the nicer app to use. It is more responsive, flexible, has more features and is in each and every way more pleasant to use than TinyRSS. So why did I switch? TinyRSS stays in synch. No matter where I go I can pop up my reader and not have to filter out the stuff I have read elsewhere already. This one single simple feature consigned Liferea to the dustbin. I was fed up with trawling through the posts I had already read over lunch or at a friends place, when I got home. TinyRSS lets me manage the feeds I read from anywhere. Its the first time a web app has completely replaced a desktop app for me. The rules of the game have changed. Some applications don't need to be the prettiest , the fastest or the most usable to win any more, some applications just need to be where I am.
If you still dont get where I am coming from, check out this quote from the Meebo Weblog.
"Hey i just wanted to say meebo is great ,im in the army and im in iraq right now.We cant download yahoo messenger or connect to it if we already have it which sucks because it really comes in handy to keep in contact with my family,but meebo works like a charm ,thanks."