<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Choosing a Server Configuration</title><link rel="stylesheet" href="styles.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Version Control with Subversion" /><link rel="up" href="svn.serverconfig.html" title="Chapter 6. Server Configuration" /><link rel="prev" href="svn.serverconfig.overview.html" title="Overview" /><link rel="next" href="svn.serverconfig.svnserve.html" title="svnserve, a custom server" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Choosing a Server Configuration</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="svn.serverconfig.overview.html">Prev</a> </td><th width="60%" align="center">Chapter 6. Server Configuration</th><td width="20%" align="right"> <a accesskey="n" href="svn.serverconfig.svnserve.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="svn.serverconfig.choosing"></a>Choosing a Server Configuration</h2></div></div></div><p>So, which server should you use? Which is best?</p><p>Obviously, there's no right answer to that question. Every team has different needs, and the different servers all represent different sets of tradeoffs. The Subversion project itself doesn't endorse one server or another, or consider either server more “<span class="quote">official</span>” than another.</p><p>Here are some reasons why you might choose one deployment over another, as well as reasons you might <span class="emphasis"><em>not</em></span> choose one.</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="svn.serverconfig.choosing.svnserve"></a>The <span class="command"><strong>svnserve</strong></span> Server</h3></div></div></div><div class="variablelist"><dl><dt><span class="term">Why you might want to use it:</span></dt><dd><div class="itemizedlist"><ul type="disc"><li><p>Quick and easy to set up.</p></li><li><p>Network protocol is stateful and noticeably faster than WebDAV.</p></li><li><p>No need to create system accounts on server.</p></li><li><p>Password is not passed over the network.</p></li></ul></div></dd><dt><span class="term">Why you might want to avoid it:</span></dt><dd><div class="itemizedlist"><ul type="disc"><li><p>By default, only one authentication method is available, the network protocol is not encrypted, and the server stores cleartext passwords. (All these things can be changed by configuring SASL, but it's a bit more work to do.)</p></li><li><p>No logging of any kind, not even errors.</p></li><li><p>No built-in web browsing. (You'd have to install a separate web server and some CGI software to add this.)</p></li></ul></div></dd></dl></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="svn.serverconfig.choosing.svn-ssh"></a><span class="command"><strong>svnserve</strong></span> over SSH</h3></div></div></div><div class="variablelist"><dl><dt><span class="term">Why you might want to use it:</span></dt><dd><div class="itemizedlist"><ul type="disc"><li><p>Network protocol is stateful and noticeably faster than WebDAV.</p></li><li><p>You can take advantage of existing ssh accounts and user infrastructure.</p></li><li><p>All network traffic is encrypted.</p></li></ul></div></dd><dt><span class="term">Why you might want to avoid it:</span></dt><dd><div class="itemizedlist"><ul type="disc"><li><p>Only one choice of authentication method.</p></li><li><p>No logging of any kind, not even errors.</p></li><li><p>Requires users to be in same system group, or use a shared ssh key.</p></li><li><p>If used improperly, can lead to file permissions problems.</p></li></ul></div></dd></dl></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="svn.serverconfig.choosing.apache"></a>The Apache HTTP Server</h3></div></div></div><div class="variablelist"><dl><dt><span class="term">Why you might want to use it:</span></dt><dd><div class="itemizedlist"><ul type="disc"><li><p>Allows Subversion to use any of the numerous authentication systems already integrated with Apache.</p></li><li><p>No need to create system accounts on server.</p></li><li><p>Full Apache logging.</p></li><li><p>Network traffic can be encrypted via SSL.</p></li><li><p>HTTP(S) can usually go through corporate firewalls.</p></li><li><p>Built-in repository browsing via web browser.</p></li><li><p>Repository can be mounted as a network drive for transparent version control. (See <a class="xref" href="svn.webdav.autoversioning.html" title="Autoversioning">the section called “Autoversioning”</a>.)</p></li></ul></div></dd><dt><span class="term">Why you might want to avoid it:</span></dt><dd><div class="itemizedlist"><ul type="disc"><li><p>Noticeably slower than svnserve, because HTTP is a stateless protocol and requires more turnarounds.</p></li><li><p>Initial setup can be complex.</p></li></ul></div></dd></dl></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="svn.serverconfig.choosing.recommendations"></a>Recommendations</h3></div></div></div><p>In general, the authors of this book recommend a vanilla <span class="command"><strong>svnserve</strong></span> installation for small teams just trying to get started with a Subversion server; it's the simplest to set up, and has the fewest maintenance issues. You can always switch to a more complex server deployment as your needs change.</p><p>Here are some general recommendations and tips, based on years of supporting users:</p><div class="itemizedlist"><ul type="disc"><li><p>If you're trying to set up the simplest possible server for your group, then a vanilla <span class="command"><strong>svnserve</strong></span> installation is the easiest, fastest route. Note, however, that your repository data will be transmitted in the clear over the network. If your deployment is entirely within your company's LAN or VPN, this isn't an issue. If the repository is exposed to the wide-open internet, then you might want to make sure that either the repository's contents aren't sensitive (e.g. it contains only open-source code), or that you go the extra mile in configuring SASL to encrypt network communications.</p></li><li><p>If you need to integrate with existing legacy identity systems (LDAP, Active Directory, NTLM, X.509, etc.), then you must use either the Apache-based server or <span class="command"><strong>svnserve</strong></span> configured with SASL. If you absolutely need server-side logs of either server errors or client activities, then an Apache-based server is your only option.</p></li><li><p>If you've decided to use either Apache or stock <span class="command"><strong>svnserve</strong></span>, create a single <code class="literal">svn</code> user on your system and run the server process as that user. Be sure to make the repository directory wholly owned by the <code class="literal">svn</code> user as well. From a security point of view, this keeps the repository data nicely siloed and protected by operating system filesystem permissions, changeable by only the Subversion server process itself.</p></li><li><p>If you have an existing infrastructure heavily based on SSH accounts, and if your users already have system accounts on your server machine, then it makes sense to deploy an svnserve-over-ssh solution. Otherwise, we don't widely recommend this option to the public. It's generally considered safer to have your users access the repository via (imaginary) accounts managed by <span class="command"><strong>svnserve</strong></span> or Apache, rather than by full-blown system accounts. If your deep desire for encrypted communication still draws you to this option, we recommend using Apache with SSL or <span class="command"><strong>svnserve</strong></span> with SASL encryption instead.</p></li><li><p>Do <span class="emphasis"><em>not</em></span> be seduced by the simple idea of having all of your users access a repository directly via <code class="literal">file://</code> URLs. Even if the repository is readily available to everyone via network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file-permissions problems (see <a class="xref" href="svn.serverconfig.multimethod.html" title="Supporting Multiple Repository Access Methods">the section called “Supporting Multiple Repository Access Methods”</a>.) Note that this is also one of the reasons we warn against accessing repositories via <code class="literal">svn+ssh://</code> URLs—from a security standpoint, it's effectively the same as local users accessing via <code class="literal">file://</code>, and can entail all the same problems if the administrator isn't careful.</p></li></ul></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="svn.serverconfig.overview.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="svn.serverconfig.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="svn.serverconfig.svnserve.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Overview </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> svnserve, a custom server</td></tr></table></div></body></html>