Walter Nicholls wrote:
>Hi all,
>Has anyone had any success setting up a proxy server in front of a
>Subversion server?
>
>Here's my scenario. I have a Subversion server on my LAN running
>Apache/mod_dav_svn et al. This server is *NOT* going to be directly
>hooked to the Internet (it's a Win2k box for one, and pretty critical to
>the company). Currently it listens on port 80 on a dedicated IP address
>.. No problems accessing internally.
>http://svn.csl/svn/reposname/trunk/etc/etc/etc/ and all that.
>
>Now the developers are clamouring for the remote access (refused for
>VSS, promised by Subversion) to work. My preferred method is to give
>them an Internet-accessible HTTPS version of SVN provided by a proxy
>server (which must run on a Linux Debian box).
>
>I only have one external IP address to play with, and several HTTPS
>applications, so I either have to redirect via pattern matching on the
>URL - ie https://xnet.cornerstone.co.nz/svn/... goes to the subversion
>server, https://xnet.cornerstone.co.nz/otherapp/.. Goes to another web
>server etc; Or I could give them a non-standard port ..
>https://svn.cornerstone.co.nz:8080/ kind of thing. (Anyone wondering
>at that, read up on the way HTTPS does not allow multiple server names
>on the same port.)
>
>OK.. I'm by no means finished playing with possibilities (more below)
>but I am keen to get this working before Christmas <g> especially since
>there are developers snapping at my heels that all want to work from
>home over the break. And the easier the better.
>
>Is there anyone out there that has got a proxy server working and what
>did you use? There seem to be a variety of options:
>- Apache in proxy mode (a bit complex and will it work?)
>- Squid as an explicit proxy (ie configure svn client to use proxy
>server)
>- Pound
>- ... Others? Stunnel? ...
>
>I'm open to suggestions, but I am after working situations here. Maybe
>this can turn into a chapter in THE BOOK?
>
>Walter Nicholls
>Technology Manager
>Cornerstone Software Ltd (http://www.cornerstone.co.nz/)
>
>
>-----------
>Where I'm at so far (this may help someone or -better- someone can help
>me). I'm saying this mainly to prove I'm not trying very hard <g>
>
>So far I have set up Pound (www.apsis.ch/pound) (I started with the
>pound-1.5 package from debian/testing) with some success. I have Pound
>providing https://xnet.cornerstone.co.nz/svn/ which is proxying (via
>HTTP, not HTTPS) to the real Subversion server on the LAN.
>
>When I point a web browser at this, it works fine. So the HTTPS-HTTP
>protocol switch, and the backend communication is fine.
>
>The svn client dies with 'PROPFIND .. 501 method not implemented'. I
>know what this means .. I now need to compile a custom version of Pound
>with --enable-msdav. Actually I've done this, but I want a .deb
>package. Time to learn some more things (no it didn't work first time..)
>
>This is where I decided to ask for ideas, since this could snowball into
>a lot of work, and "apt-get install pound" would instantly break my
>configuration.
>
>I'd really really like to use Pound as a general HTTP/HTTPS guardian,
>since it is written to sanitise HTTP requests and thus adds a layer of
>security - it won't be open to any security holes discovered in Apache
>for instance, and is unlikely to have (m)any of its own.
>
>The only problem I have is with the author's opinion on a few things,
>like the assertion that "virtual hosts should be implemented in the
>back-end servers" This results in a few limitations in Pound's design in
>its virtual hosting (eg can't make decisions on port). But I can live
>with those limitations, and once I'm comfortable with the running
>configuration and have some spare time (next century) maybe I can patch
>it.
>
>
>
Why not set up your external apache server to act as a (authenticated?!)
proxy via straight http so the https is done end-to-end from the svn
client to the subversion server? Clients could access it from the
outside by putting some entries into their .svn/servers. They'd probably
also need to hard-code the IP address for svn.csl into their hosts
file. Let's assume your public IP server is outside.yourco.com. Then
when they're external they modify .svn/servers with:
[groups]
svn_csl = svn.csl
[svn_csl]
http-proxy-host = outside.yourco.com
If you'd like you can set up outside.yourco.com to authenticate them for
proxying the connections and then add the appropriate http-proxy-*
settings above. On outside.yourco.com you enable proxying and restrict
it to CONNECT to svn.csl. Now clients can do the SSL end-to-end which is
really probably what you want. Don't worry about DAV support in your
proxy. Clients will just use CONNECT which works as a transport-level
proxy and the proxy doesn't need to know anything else.
Then if the same client machine is in the office the users can use the
same setup but just remove or comment out the http-proxy-host entry in
servers.
Granted now I haven't set up this configuration myself but it should
work well I think.
--
Jens B. Jorgensen
jens.jorgensen@tallan.com
"With a focused commitment to our clients and our people, we deliver value through customized technology solutions."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 12 16:34:43 2003