Difference between revisions of "Configure SVN"
(→See also: a better procedure using SSH keys) |
(new setup using keys) |
||
| Line 2: | Line 2: | ||
== Setting an SVN repository == | == Setting an SVN repository == | ||
| − | The necessary packages should already have been installed as part of the [[organicdesign-server]] package, but if not, you'll need to '''apt-get install subversion libapache2-svn'''. Then the first step is to create the repositories as in the following example. | + | The necessary packages should already have been installed as part of the [[organicdesign-server]] package, but if not, you'll need to '''apt-get install subversion libapache2-svn'''. Then the first step is to create the repositories as in the following example. We create them in '''/var/www''' so that they're included in our content backups. |
| − | {{code|< | + | {{code|<bash>mkdir /var/www/svn |
| − | mkdir /svn | + | svnadmin create /var/www/svn/extensions |
| − | svnadmin create /svn/extensions | + | svnadmin create /var/www/svn/tools</bash>}} |
| − | svnadmin create /svn/tools | ||
| − | </ | ||
| − | Next create | + | Next create an ''svn'' user that all access to the repositories will be done through. We then set the permissions of the repository structures so that the ''svn'' user and the web-server (user ''www-data'' on Debian-based systems) can access it, we also set the UMODE to 2 so that new items are created with the correct permissions too. We can also at this point add a number of developer users to the ''www-data'' group so that they can access the repository. Note that these developer users are just those that will be accessing the repository from within the server itself, not those that access from remote locations. |
| − | {{code|< | + | {{code|<bash>adduser svn |
| − | |||
| − | + | chown -R svn:www-data /var/www/svn | |
| − | + | chmod -R 2770 /var/www/svn | |
| − | + | addgroup earl www-data | |
| − | + | addgroup tabatha www-data</bash>}} | |
| − | </ | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | The ''svn'' user will be used by all remote users to access the repositories securely. We assume here that all users already use RSA key-pairs for their shell access to the server, and that passwords are disabled in '''/etc/ssh/sshd_config'''. We also allow only specified users to have shell access to by using the ''ALLOW USERS'' directive in '''/etc/ssh/sshd_config''', so the new ''svn'' user should be added into this directive too. | ||
| − | + | Next each of the users public parts of their RSA key-pairs should be appended to '''/home/svn/.ssh/authorized_keys'''. This file will have to be created the first time a new key is to be added and its ownership and mode set properly. I'm assuming each user only has one key in the following example: | |
| − | {{code|< | + | {{code|<bash> |
| − | cd /svn | + | cd /home/svn |
| − | + | mkdir .ssh | |
| − | + | cp /home/earl/.ssh/authorized_keys .ssh/ | |
| − | + | cat /home/tabatha/.ssh/authorized_keys >> .ssh/authorized_keys | |
| − | + | chown -R svn:svn .ssh | |
| − | + | chmod -R 600 .ssh</bash>}} | |
| − | |||
| − | |||
| − | |||
| − | </ | ||
| − | + | Next, we need to lock down the ''svn'' user so that it can't be used for anything else except accessing the Subversion repositories. To do this, set the allowed command and turn off all other services that are usually available to applications using the SSH protocol. We also need to tunnel the correct user through the connection so that the commits are logged under the correct name instead of all being logged as the "svn" user. To do this we prepend the options before the RSA keys in the '''/home/svn/.ssh/authorized_keys''' file as follows. | |
| − | {{code|<pre> | + | {{code|<pre>command="/usr/bin/svnserve -t -r /var/www/svn/ --tunnel-user=earl",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding ssh-rsa AAA...vwXYZ= earl |
| − | + | command="/usr/bin/svnserve -t -r /var/www/svn/ --tunnel-user=tabatha",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding ssh-rsa AAA...abCDE= tabatha</pre>}} | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | </pre>}} | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | Now the users can all access the repository using the following example syntax: | ||
| + | {{code|<bash>svn co svn+ssh://svn@organicdesign.co.nz/tools}} | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== WebSVN == | == WebSVN == | ||
| Line 110: | Line 64: | ||
You can comment out all the themes in your config file except the one that matches your site best which removes the themes selection dropdown. To change the information, edit the ''index.tmpl'' file in the corresponding skins directory which are all found in the ''templates'' directory. | You can comment out all the themes in your config file except the one that matches your site best which removes the themes selection dropdown. To change the information, edit the ''index.tmpl'' file in the corresponding skins directory which are all found in the ''templates'' directory. | ||
| + | And that's all there is to it! no simply browse to your sub-domain, ours is http://svn.organicdesign.co.nz | ||
| − | + | == Backing up an SVN repository == | |
| − | {{code|< | + | Rather than just zip up the repository directory, it's best to use the '''svnadmin dump''' utility so that it can be easily imported again later regardless of specifics of platform and version. |
| − | + | {{code|<bash>svnadmin dump /svn/extensions > ~/extensions-2010-01-01.svn</bash>}} | |
| − | </ | ||
| − | + | ||
| + | Later the repository can be imported using the following: | ||
| + | {{code|<bash>cd /svn/extensions | ||
| + | svnadmin create extensions | ||
| + | svnadmin load extensions < ~/extensions-2010-01-01.svn</bash>}} | ||
== See also == | == See also == | ||
Revision as of 16:21, 29 February 2012
|
Configure SVN Organic Design procedure |
Setting an SVN repository
The necessary packages should already have been installed as part of the organicdesign-server package, but if not, you'll need to apt-get install subversion libapache2-svn. Then the first step is to create the repositories as in the following example. We create them in /var/www so that they're included in our content backups.
Next create an svn user that all access to the repositories will be done through. We then set the permissions of the repository structures so that the svn user and the web-server (user www-data on Debian-based systems) can access it, we also set the UMODE to 2 so that new items are created with the correct permissions too. We can also at this point add a number of developer users to the www-data group so that they can access the repository. Note that these developer users are just those that will be accessing the repository from within the server itself, not those that access from remote locations.
The svn user will be used by all remote users to access the repositories securely. We assume here that all users already use RSA key-pairs for their shell access to the server, and that passwords are disabled in /etc/ssh/sshd_config. We also allow only specified users to have shell access to by using the ALLOW USERS directive in /etc/ssh/sshd_config, so the new svn user should be added into this directive too.
Next each of the users public parts of their RSA key-pairs should be appended to /home/svn/.ssh/authorized_keys. This file will have to be created the first time a new key is to be added and its ownership and mode set properly. I'm assuming each user only has one key in the following example:
Next, we need to lock down the svn user so that it can't be used for anything else except accessing the Subversion repositories. To do this, set the allowed command and turn off all other services that are usually available to applications using the SSH protocol. We also need to tunnel the correct user through the connection so that the commits are logged under the correct name instead of all being logged as the "svn" user. To do this we prepend the options before the RSA keys in the /home/svn/.ssh/authorized_keys file as follows.
Now the users can all access the repository using the following example syntax:
WebSVN
MediaWiki uses viewvc for web viewing of their svn repositories, but the installation and configuration are a bit of a pain since its a Python CGI script rather than PHP like all our other web applications. So for this reason we're using the PHP websvn from Tigris instead.
Installation of websvn is a simple matter of downloading into /var/www/domains/websvn and creating a sub-domain and virtual host entry for it as for any other PHP web application. Next make a copy of the default config file:
And add a single entry in the repositories section pointing at the parent directory of your repositories, for example:
You may want to add or adjust the file extensions used for syntax highlighting, each language is an array key with an array of file-extensions as its value. For example, we wanted our wikid.conf.sample file to be highlighted as Perl, so we added the following line to add "sample" to the extensions list under the "perl" key:
You can comment out all the themes in your config file except the one that matches your site best which removes the themes selection dropdown. To change the information, edit the index.tmpl file in the corresponding skins directory which are all found in the templates directory.
And that's all there is to it! no simply browse to your sub-domain, ours is http://svn.organicdesign.co.nz
Backing up an SVN repository
Rather than just zip up the repository directory, it's best to use the svnadmin dump utility so that it can be easily imported again later regardless of specifics of platform and version.
Later the repository can be imported using the following:
See also
- Subversion - local article about Subversion
- Subversion access over SSH on Debian - a better procedure using SSH keys
