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.
Per-Project Configuration

To achieve greater granularity in the access control management, we want to define separated policies for each project. The case in which we have a trusted subnet will be analysed here because it's much more involved. In this scenario we allow password-based authentication over HTTP only from the trusted subnet. We specify the policy for each project in a separate file contained in the /svn/conf/private and /svn/conf/public. To achieve this, add the following lines to your /svn/conf/mod_dav_svn.conf file:


Include /svn/conf/policies/public/*
Include /svn/conf/policies/private/*

Suppose we have foo and bar public projects. John and Bob are foo's developers, while John and Mike are bar's developers. We want one project's developers to have full access only to the project they develop over HTTP from the trusted subnet. First of all, let's fill in the users' password file:


sackville apache2 # bin/htpasswd -c /svn/conf/svnpasswd john *****
sackville apache2 # bin/htpasswd /svn/conf/svnpasswd bob *****
....

Then, we create the users' group file: each project is associated with a group whose name has the form (public|private)_projectname and contains the users participating in the project:


public_foo: john bob
public_bar: john mike

We save this file as /svn/conf/svngroups. The last operation consists of associating a file in the /svn/conf/policies/public directory with a project. foo's access control policy file is called /svn/conf/policies/public/foo and contains the following lines:


<Location /public/foo>
        <LimitExcept GET PROPFIND OPTIONS REPORT>
                AuthType Basic
                AuthName "Public Subversion repository for project Foo"
                AuthUserFile /svn/conf/svnpasswd
                AuthGroupFile /svn/conf/svngroups

                Require group public_foo
        </LimitExcept>
</Location>

We could move AuthType, AuthUserFile and AuthGroupFile to the default policy file to avoid replication of configuration entries. We had to add the Satisfy directive to require users to authenticate from the trusted subnet during a read/write session. So modify your public_default_policy.conf file in this way:


<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

            Satisfy all
        </LimitExcept>
</Location>

The configuration for private projects is quite similar; we simply discard any LimitExcept directive so the public_default_policy.conf becomes:


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

        Order deny,allow
        Deny from all
        Allow from 192.168.0.0/24

        Satisfy all
</Location>

and the private project worldconquest's access control policy file is:


<Location /private/worldconquest>
        AuthType Basic
        AuthName "Private Subversion repository for project WorldConquest"
        AuthUserFile /svn/conf/svnpasswd
        AuthGroupFile /svn/conf/svngroups

        Require group private_worldconquest
</Location>

HTTPS Configuration

Now it's time to consider HTTPS connections, which allow users around the world to access the repository, granting password confidentiality and data integrity over insecure channels such as the Internet. Apache manages HTTPS in a separate virtual host space, which is set up using a configuration like this one:


<VirtualHost _default_:443>
...
</VirtualHost>

But which Apache are we talking about? External Apache1 or internal Apache2 plus Subversion? Subversion clients using HTTPS can connect to the external Apache1 Web server, of course, and try to establish secure connections to it. So we must configure HTTPS for our external Apache1 Web server. There's no need for proxy requests to the internal Apache2 Web server to be delivered over a secure connection too, but because we want to centralize access control policies in our Apache2 Web server, we must provide a mechanism for Apache2 to discriminate proxy requests coming from an external secure channel.

We use another port (assume 8081) to discriminate when an HTTP request has been delivered to the Apache1 Web server using SSL. So when an HTTP request hits Apache1 over SSL, it is proxied internally in clear to port 8081, where Apache2 is listening. As usual, remember to block incoming connections to port 8081 from external hosts or to bind Apache2 to the loopback interface (or both).

In the Apache1 configuration file, add the following line to the SSL virtual host directive:


Proxy /svn/ http://localhost:8081/

Now tell Apache2 to listen to port 8081, adding the following entry to your httpd.conf file: Listen localhost:8081.

Now we must set up a virtual host environment for access through port 8081. The main difference with respect to HTTP connections is related to source-based access control: using HTTPS connections we drop the notion of trusted and untrusted subnet. HTTPS requests can arrive from just anywhere.

Thus, the default policy files must include a VirtualHost directive for the port 8081. Here's the one for public projects that we put in the /svn/conf/public_default_policy.conf file:


<VirtualHost _default_:8081>
<Location /public>
        Dav svn
        SVNParentPath /svn/conf/repository/public

        Order allow,deny
        Allow from all

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

                Satisfy all
        </LimitExcept>
</Location>

Include /tmp/LJ/policies/public/*

</VirtualHost>

As usual, using the Satisfy clause allows us to write access only to authenticated users. In addition, we recycled the per-project configuration files (see the Include directive) because they do not depend on the source-based access control policy, but we can specialize them for another purpose if we need to. The default policy for private projects is similar:


<VirtualHost _default_:8081>
<Location /private>
        Dav svn
        SVNParentPath /svn/conf/repository/private

        Order allow,deny
        Allow from all

        Satisfy all
</Location>

Include /tmp/LJ/policies/private/*

</VirtualHost>

______________________

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...

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState