Setting Up Subversion for One or Multiple Projects

Deploying a secure and manageable Subversion installation that uses Apache 2.0 as a central authentication checkpoint and SSL for data integrity and confidentiality.
Installation

Before installing Subversion, we need to install the Apache 2.0 Web Server. So, download and unpack the source tarball and start the configure script:


sackville httpd-2.0.49 # ./configure --enable-mods-shared=most

The command-line option enables most of the Apache modules, building them as shared modules. You may need to fine tune the command-line options to include (or exclude) more modules; for example, you may need LDAP modules to authenticate against an LDAP server. To install the Apache Web Server, issue a make && make install.

Next, grab the latest Subversion source tarball, unpack the sources and start the configure script:


sackville subversion-1.0.1 # ./configure
--with-apxs=/path/to/apache2/bin/apxs \
                                         --with-ssl

The option -with-apxs may not be required if you installed Apache2 in a default location. Likewise, the option -with-ssl is not needed if you plan to install a server-only Subversion, because SSL support is provided by Apache's built-in mod_ssl.so module. In addition you may need to specify locations for your shared libraries. In particular, many users seem to have trouble with the Berkeley DB libraries. Carefully read the Subversion users' mailing list if you encounter problems.

Issue make && make install to build and install mod_dav_svn.so modules. If everything went well, you'll find mod_dav_svn.so among your modules.

Configuration

The Subversion installation process should have created the proper entries in your Apache configuration file to activate the mod_dav_svn.so module. In addition, you should see entries for a mod_authz_svn.so module; it's part of the access control machinery of Subversion and we'll take a look at it later.

In our setup, Apache2 must reside side by side with Apache1, so we need to tell Apache2 to listen to a port other than 80--assume it's the 8080 port. Because Apache2 is accessed through Apache1, you should block that port in your firewall configuration or make Apache2 bind to the loopback interface. The latter solution is better than the former, because we don't need to rely on a firewall to drop incoming connections from external hosts. You also should apply common security tips to enhance Apache2 security, which I won't describe here. For example, Apache with Subversion modules tends to be a little too verbose in its error messages, showing version numbers for most activated modules (SSL, DAV, Subversion and so on). Security purists call this behaviour information leakage; to minimize it act on the ServerTokens directive.

Now it's time to decide where the repository will live. We must answer the following questions:

  • Where in the Apache2 URL's space will our repository be accessible? Because Apache2 is being used as a Subversion-only server, we decide to have the server root be the root of our repository.

  • Where in the server's filesystem is the repository physically located? We have no constraints here, so we choose /svn to contain all the Subversion-related files.

  • Where in the external Apache1 URL's space will our repository live? A common strategy is to put Subversion repositories in the /svn directory.

The layout of the /svn directory thus is:

  • /svn/conf: contains all the files needed for Apache2 and Subversion to work, such as user authentication information, access control policies and so on.

  • /svn/repository: contains two subdirectories for public and private projects. Inside each subdirectory we create a project using svnadmin's create command.

In the Apache2 httpd.conf file we add the following lines:


<IfModule mod_dav_svn.c>
Include /svn/conf/mod_dav_svn.conf
</IfModule>

Including the file /svn/conf/mod_dav_svn.conf, we centralize any Subversion-related information in the same place, that is, the directory /svn.

To proxy all the HTTP requests from Apache1 to Apache2, add the following entry to your Apache1 configuration file:


Proxy /svn/ http://localhost:8080/

Default HTTP Policies

When defining the access control policy, we must distinguish plain HTTP connections from HTTPS connections, because passwords are not protected over a plain HTTP connection. In the following lines, we define the default policy for HTTP connections. We add the following entries to the /svn/conf/mod_dav_svn.conf file:


Include /svn/conf/public_default_policy.conf
Include /svn/conf/private_default_policy.conf

Each *_default_policy.conf contains the default access control policy for the corresponding project group. We want read-only HTTP public access for public projects, so add the following lines to your /svn/conf/public_default_policy.conf file:


<Location /public>
        Dav svn # Tell Apache to use Subversion's own module
                # for HTTP's Dav extensions.

        SVNParentPath /svn/repository/public

        <LimitExcept GET PROPFIND OPTIONS REPORT>
            Order deny,allow
            Deny from all
        </LimitExcept>
</Location>

This configuration denies access to any HTTP method except GET, PROPFIND, OPTIONS and REPORT, which are used during a read-only session. If you have a trusted subnet (assume 192.168.0.0/24) you want to allow write access from, you may change the above configuration snippet to:


<Location /public>
        Dav svn
        SVNParentPath /svn/repository/public

        <LimitExcept GET PROPFIND OPTIONS REPORT>
            Order deny,allow
            Deny from all
            Allow from 192.168.0.0/24
        </LimitExcept>
</Location>

Notice, however, that if you don't add more access control rules to restrict access, anyone connecting from the subnet 192.168.0.0/24 can write to the repository. If you need strict user-based access control, then I advise you not to use this default policy.

The access control policy for the private project group denies access to anyone over an HTTP connection. The corresponding configuration snippet you must put in your /svn/conf/private_default_policy.conf is:


<Location /private>
        Dav svn
        SVNParentPath /svn/repository/private

        Order deny,allow
        Deny from all
</Location>

If you wish to allow access from the trusted subnet, use the following:


<Location /private>
        Dav svn
        SVNParentPath /svn/repository/private

        Order deny,allow
        Deny from all
        Allow from 192.168.0.0/24
</Location>

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

VisualSVN Check out

Anonymous's picture

Hello All ... i really need help,
is there is any way to disable multiple checkouts in VisualSVN ?

which means when i'm checking out a file and working on it no one else can check it out ... as in Microsoft Visual Source Safe when someone try to check out a file that i'm currently worked in ... a message is displayed to the other user the me is working on this file and he cant access it.

your help will be much appreciated.

adding a new project to repository

Anonymous's picture

I like to know how to add a new project to repository. Can somebody pls help me. Your help will be highly appreciated.

502 Bad gateway error could

Mapk's picture

502 Bad gateway error could be solved by adding in your httpd.conf,

RequestHeader edit Destination ^https http early

Source:
5. Enable DAV to work with Apache running HTTP through SSL...
http://httpd.apache.org/docs/2.2/mod/mod_headers.html

web based administration

Anonymous's picture

If you're after a simple approach that has a web-based administration on the top, you may want to check out Atlassian Crowd.

permisions

billie's picture

Getting the svn permissions just right for my security has been a real pain. Anyone else have good solutions to work with svn security?

Problem with per-directory

georgeen's picture

I read the svn-book, but isn´t clear the paths when the Subversion is on windows. Another thing is that in your article the users are defined into Apache but in svn-book them are defined into a plain text, at least as far as I undertood. Right now I have a problem because I don't know how to write the path of the directory inside svn_authz file (repo:c:/path...) or ( repo:/c:/path...) or (repo:c:\path...) or (repo:c/path... and variants). By the other hand when I use the Apache users file nobody can access, and message "FORBIDDEN You don't have permission to access..." appear, after the first try, but if is the plain text users file as svn-book then nobody can access but after three tries or pushing cancel button then the message "Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required." appear. Multiple paths on svnsecur were used with the same results if the Require valid-user is set. If I use only the Apache users file everything works fine, but isn't I need.

My configuration is:

svnusers.conf //this is the plain text user file

ehenao = pass_of_ehenao
oalvarez = pass_of_oalvarez
aperilla = pass_of_aperilla
marcelas = pass_of_marcelas
arodriguez = pass_of_marcelas
fcarrascal = pass_of_fcarrascal

svnsecur.conf

[groups]
developers = ehenao,oalvarez,aperilla,marcelas
document = arodriguez,fcarrascal
all = @developers,@document

[Delphirep:C:/SVNRepositorio/Delphirep]
@developers = rw

[Delphirep:/Delphirep/doc]
@document = rw
@developers = r

[cursorep:/C:\SVNRepositorio\Cursorep]
@todos = rw

and in httpd.conf

DAV svn
SVNParentPath C:\SVNRepositorio

AuthzSVNAccessFile C:\Archiv~1\Collab~1\httpd\conf\svnsecur.conf

AuthType Basic
AuthName "Repositorio PCT"
AuthUserFile C:\Archiv~1\Collab~1\httpd\conf\svnusers.conf
#AuthUserFile C:\Archiv~1\Collab~1\httpd\conf\svnusers.http.conf

Require valid-user

svnusers.http.conf is the file generated with htpasswd.

what I'm missing or overlooked?

MKACTIVITY - 403 Forbidden Error

Dinesh Pillay's picture

Hi,

First off thanks for the great article. I followed the steps described and am able to see my repository and even checkout a test project from the same via HTTP.One difference here was that in public_default_policy.conf instead of "SVNParenPath /path/to/repo/public", I had to use "SVNPath /path/to/repo/public". Only then did I start seeing my projects.

Problems start when I try committing anything to that test project. I keep getting this particular error

svn: MKACTIVITY of '/public/!svn/act/505453b1-b22f-0410-b2eb-ca2e1334eb90': 403 Forbidden (http://localhost)

I see that you have printed a similar line in your article but the difference here is that for you it was "/public//svn..." but in my case it comes up as "/public/svn.." without the project name! Any ideas why that is happening?

Please let me know if you can find anything.

- Dinesh.

Just a correct.. its

Dinesh Pillay's picture

Just a correction.. its "public/_project_name_/svn.." the angle brackets were discarded by the engine.

- Dinesh.

Subversion Multi-Site

Elaine Murphy's picture

Interesting article - you should take a look at active/active replication for geographic distribution of Subversion - http://www.wandisco.com

Suggestion: mod_macro

Michael's picture

A nice thing to use for real complex setups with a lot of projects is mod_macro which we use over at the hosted-projects.com Subversion hosting service. It allows to re-use SVN configuration directives by simply adding a line like:
Use SVNRepositories Project1

Care to post it somewhere?

AnonymousR's picture

Care to post it somewhere?

Re: Setting Up Subversion for One or Multiple Projects

Anonymous's picture

First, I would like to say the article is very informative. However there are some inaccuracies (wrong paths, typos, missing paths) in the suggested configuration examples. It seems as though the author did not bother to actually test the configurations he suggests on a clean installation Linux with a default Apache 1.x installation; this is in-excusable.

I am running Slackware-current and I have setup the Apache 1.3.31 to ProxyPass to the Apache 2.0.50 server, as described in the article however I am having trouble with the Proxying.

I can do the following (at the local command prompt):
svn checkout http://localhost:8080/public/svn/myrepository/trunk

and it checks out fine.

However if I then do:
svn checkout http://mypublicname.com/svn/public/myrepository/trunk

then I get the following error:
svn: PROPFIND request failed on '/public/myrepository/!svn/vcc/default'
svn: '/public/myrepository/!svn/vcc/default' path not found

Does anyone know if this is an issue with the proxying or maybe an issue with the svn client stripping '/svn/' on subsequent PROPFIND requests?

Here is my Proxy statements in my /etc/apache/httpd.conf file:
ProxyRequests Off
ProxyPass /svn/ http://localhost:8080/

Here is what I have configured in my /usr/local/svn/conf/public_default_policy.conf file:

Location /public
Dav svn
SVNParentPath /usr/local/svn/repository/public
/Location

same path to proxy

Anonymous's picture

To have proxy working properly you have to use the SAME path in both server.e.g.

ProxyPass /svn/ http://localhost:8080/svn/

VERY IMPORANT: same path to proxy

Anonymous's picture

THIS IS A VERY IMPORTANT CONFIGURATION STEP!!!
If you wish to proxy all SVN/WebDAV requests correctly from Apache1 to Apache2, IT IS VERY IMPORTANT that the paths are the SAME in the ProxyPass, for example:

ProxyPass /svn/ http://localhost:8080/svn/

I spent 5h without any clue why I was getting PROPFIND error, and finally I made SVN to work behind a reverse proxy just by using the same path!!!!!

Re: Setting Up Subversion for One or Multiple Projects

Anonymous's picture

Just a wild guess, but don't you need a ProxyPassReverse in addition ?!?

in-excusable?

Anonymous's picture

remember what you paid for the information ...

Remember what I paid for the

Lee's picture

Remember what I paid for the info? About as much as I paid for the OS! Dear-oh-deary me...

Re: in-excusable?

Anonymous's picture

If a computer technie writes a free tutorial with their real name and it is discovered that the tutorial is highly inaccurate, then only their reputation suffers for writing such garbage. Getting upset and posting you're disappointment is a good way to expose the incompetence of the writer of the tutorial. Just because the tutorial is free of charge does not protect the author from negative feedback from the readers.

Re: in-excusable?

Anonymous's picture

I hope you're not suggesting that visiting linuxjournal.com for information is a waste of time, because it contains information for free.

By the way, I found a solution to the issue.

Re: in-excusable?

Anonymous's picture

Btw I forgot to mention in my previous post that the proxies work through my web browers but are having the same issues as above in the svn checkout:

In browser: http://localhost/svn/proj1 correctly points to the Apache 2 server and my repository

svn co http://localhost/svn/proj1 proj1 produces the same error as above
svn co http://localhost:8800/proj1 proj1 works

Re: in-excusable?

Anonymous's picture

Can you please post a solution as I am having the same issues (with both http and https requests).

Also I have given up trying to use the public and private setup (all my repositories are now stored in /svn/repository/proj1 /svn/repository/proj2 etc.. and I have indiviudal conf files. This is because no matter what I tried the public/private directories kept getting a 403 forbidden error - anyone know the solution to this as well?

Re: Setting Up Subversion for One or Multiple Projects

Anonymous's picture

Nice tutorial, might have saved some time setting up our Subversion hosting service over at wush.net :)

svn: COPY of foo: 502 Bad Gateway ()

Anonymous's picture

Does anyone else experience this problem when trying to use tags and branches?

svn copy trunk/ https://svn.example.com/public/project/tags/foo

svn: Commit failed (details follow):
svn: COPY of foo: 502 Bad Gateway (https://svn.example.com)

svn: COPY of foo: 502 Bad Gateway ()

Jean-Pol Landrain's picture

Note: this can only happen with HTTPS

The explanation:
It seems there is no standard solution to this problem. Greg Stein has refused to implement a workaround in the Apache module: the problem happens because the hardware (reverse proxy, SSL accelerator or whatever decrypts the HTTPS) doesn't do correctly his job. It modifies the URL in the request but not in the "Destination" header of the DAV "COPY" requests (these DAV requests are issued from the SVN client when you do either a "copy" or "move"). Then when the svn server checks the parameters, it finds something incorrect. The position of Greg is understandable as it's not a problem caused by Apache or by SVN. The way we've fixed it here has required implementing a script inside the ssl accelerator, in order to also modify the "Destination" header in the DAV "COPY" requests to our SVN server. This solution works perfect, we've almost forgotten it's in place. If you can't do it in your reverse proxy, it's also possible to do it with a PERL script installed inside Apache (using mod_perl and the directives SetHandler and PerlHeaderParserHandler in the apache configuration file). If both these can't be done in your environment, your last resort will be to activate the ssl connection between the reverse proxy and Apache (but this wasn't possible here).

For reference:
http://svn.haxx.se/users/archive-2006-03/0549.shtml
http://svn.haxx.se/users/archive-2003-08/0780.shtml

One possible solution (using mod_perl):
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=96866

Cheers.
Jean-Pol.

Re: svn: COPY of foo: 502 Bad Gateway ()

Anonymous's picture

I think the problem is that Apache processes the proxy URL translation before it decrypts the HTTPS request. Since the to-URL of the COPY is in the encrypted body of the request, it never gets translated.

I haven't verified this but I'm pretty sure that's what's breaking you

Re: svn: COPY of foo: 502 Bad Gateway ()

Anonymous's picture

Oh, just found it:

"Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol"

if you are using virtual host, then that is most likely what is causing it.

You can, but...

Brian C. Lane's picture

You can use SSL with named virtual hosts, but all of the clients connecting will get errors when checking the SSL certificate. All they need to do is ignore the errors (which you usually do for selfed CA certs anyway).

bcl

Re: svn: COPY of foo: 502 Bad Gateway ()

Anonymous's picture

I also get this problem.

I don't know what causes it but it seems to only happen with https and copying or moving (which is just a fancy copy) a file. It also use to work but then stopped, but I don't know what has changed in between.

Invalid command 'Proxy'

Anonymous's picture

For my Apache 1.3.31 "Proxy" is an unknown directive. Could you provide more information, how to enable this directive or do you meant the Redirect directive?

Proxy /svn/ http://localhost:8080/

vs.

Redirect /svn/ http://localhost:8080/

"Invalid command 'Proxy', perhaps mis-spelled or defined by a module not included in the server configuration"

Re: Invalid command 'Proxy'

Anonymous's picture

You have to make sure that proxy_module is loaded. Look for

LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so

in the file /etc/apache/modules.conf

Look up your Apache-dokumentation for more information.

Regards, Bj

Re: Invalid command 'Proxy'

Anonymous's picture

Would you please check your documentation? There is no command Proxy!

http://httpd.apache.org/docs/mod/mod_proxy.html

Regards, Kai

Re: Invalid command 'Proxy'

rhpk's picture

It was a typing mistake. The correct Apache directive is:

ProxyPass

Sorry.

Cristiano

Re: Setting Up Subversion for One or Multiple Projects

Anonymous's picture

Although this in itself is interesting, how about indicating which parts (to an apache newbie) are not relevant if you are working with a pure Apache 2 setup?

Re: Setting Up Subversion for One or Multiple Projects

rhpk's picture

Since all the information about athentication and access control is centralized in the Apache 2.0 server, the setup described in the article works as standalone too. The only change refers to SSL connections, which should be handled directly by Apache 2.0 through the SSL module.

Why two levels of apache?

happynut's picture

What was the reason for using two levels of apache?
It appears that the first apache just proxies everything
to the second.

Is it because you don't think apache 2.0 is secure enough
to be facing a public network? Or is there a subtler reason
that I'm just missing.

Re: Why two levels of apache?

Anonymous's picture

I'd expect it's because Apache 2.0's mod_ssl is not complete. It has an outstanding bug that prevents POST from working in conjunction with per directory/location SSL configuration. I've no idea how mod_ssl 2 would interact with DAV's other request types, either.

Re: Why two levels of apache?

Anonymous's picture

Mod SSL is fine with DAV requests - they're just http, after all.

Re: Why two levels of apache?

Anonymous's picture

Just a hunch as I'm still experimenting but I've found that trying to add the svn modules on top of an already working apache2 setup (PHP,SSL,mod_auth_mysql) just ends up being a mess that I can't get to work. I'm pretty well resigned to having to split up svn access, like this article, just to have mod_auth_mysql work in both environments.

Re: Why two levels of apache?

rhpk's picture

When compiled as an Apache module, Subversion requires Apache 2.0 while many production servers are based on the 1.3 series.

The migration from the 1.3 series to 2.0 series may not be the best choice for those installations: if you feel confident (from a security point-of-view) in your existing setup, you may not want to migrate to just enable Subversion.

If such situations, if you still want to use Subversion as an Apache module, the proxy solution is a good compromise.

Re: Why two levels of apache?

Anonymous's picture

Probably because most people with a public web server are already using Apache 1.3, and won't want to make more work for themselves by having to change that if it's working OK.

Very easy installation of apache subversion active directory

Anonymous's picture

Everyone is facing the problem of integration of apache/Subversion with Active directory. I found the document with complete package and it takes only 5-10 mins to install. You can also use the same and if any problem, Logon to http://forum.opensourcedevelopment.net, It is really very good.
Path is http://opensourcedevelopment.net/text-tutorials/apache-subversion-active...

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix