<?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" type="text/css" href="styles.css" />
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1" />
<link rel="home" 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" title="Choosing a Server Configuration">
<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 trade-offs. The Subversion project
itself doesn't endorse one server or another, or consider either
server more <span class="quote">“<span class="quote">official</span>”</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" title="The svnserve Server">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="svn.serverconfig.choosing.svnserve"></a>The svnserve 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 class="itemizedlist" type="disc">
<li class="listitem">
<p>Quick and easy to set up.</p>
</li>
<li class="listitem">
<p>Network protocol is stateful and noticeably
faster than WebDAV.</p>
</li>
<li class="listitem">
<p>No need to create system accounts on
server.</p>
</li>
<li class="listitem">
<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 class="itemizedlist" type="disc">
<li class="listitem">
<p>By default, only one authentication method is
available, the network protocol is not encrypted,
and the server stores clear text passwords. (All
these things can be changed by configuring SASL, but
it's a bit more work to do.)</p>
</li>
<li class="listitem">
<p>No advanced logging facilities.</p>
</li>
<li class="listitem">
<p>No built-in web browsing. (You'd have to
install a separate web server and repository
browsing software to add this.)</p>
</li>
</ul>
</div>
</dd>
</dl>
</div>
</div>
<div class="sect2" title="svnserve over SSH">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="svn.serverconfig.choosing.svn-ssh"></a>svnserve 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 class="itemizedlist" type="disc">
<li class="listitem">
<p>The network protocol is stateful and noticeably
faster than WebDAV.</p>
</li>
<li class="listitem">
<p>You can take advantage of existing SSH accounts
and user infrastructure.</p>
</li>
<li class="listitem">
<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 class="itemizedlist" type="disc">
<li class="listitem">
<p>Only one choice of authentication method is
available.</p>
</li>
<li class="listitem">
<p>No advanced logging facilities.</p>
</li>
<li class="listitem">
<p>It requires users to be in the same system
group, or use a shared SSH key.</p>
</li>
<li class="listitem">
<p>If used improperly, it can lead to file
permission problems.</p>
</li>
</ul>
</div>
</dd>
</dl>
</div>
</div>
<div class="sect2" title="The Apache HTTP Server">
<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 class="itemizedlist" type="disc">
<li class="listitem">
<p>It allows Subversion to use any of the
numerous authentication systems already integrated
with Apache.</p>
</li>
<li class="listitem">
<p>There is no need to create system accounts on
the server.</p>
</li>
<li class="listitem">
<p>Full Apache logging is available.</p>
</li>
<li class="listitem">
<p>Network traffic can be encrypted via SSL.</p>
</li>
<li class="listitem">
<p>HTTP(S) can usually go through corporate
firewalls.</p>
</li>
<li class="listitem">
<p>Built-in repository browsing is available via
web browser.</p>
</li>
<li class="listitem">
<p>The 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 class="itemizedlist" type="disc">
<li class="listitem">
<p>Noticeably slower than <span class="command"><strong>svnserve</strong></span>,
because HTTP is a stateless protocol and requires
more network turnarounds.</p>
</li>
<li class="listitem">
<p>Initial setup can be complex.</p>
</li>
</ul>
</div>
</dd>
</dl>
</div>
</div>
<div class="sect2" title="Recommendations">
<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 class="itemizedlist" type="disc">
<li class="listitem">
<p>If you're trying to set up the simplest possible server
for your group, 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, 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 class="listitem">
<p>If you need to integrate with existing legacy identity
systems (LDAP, Active Directory, NTLM, X.509, etc.),
you must use either the Apache-based server
or <span class="command"><strong>svnserve</strong></span> configured with SASL.</p>
</li>
<li class="listitem">
<p>If you've decided to use either Apache or stock
<span class="command"><strong>svnserve</strong></span>, create a single
<span class="command"><strong>svn</strong></span> user on your system and run the
server process as that user. Be sure to make the
repository directory wholly owned by the
<span class="command"><strong>svn</strong></span> 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 class="listitem">
<p>If you have an existing infrastructure that is heavily based
on SSH accounts, and if your users already have system
accounts on your server machine, it makes sense to
deploy an <span class="command"><strong>svnserve</strong></span>-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 class="listitem">
<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 a 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 permission 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 it 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>
<div xmlns="" id="svn-footer">
<hr />
<p>You are reading <em>Version Control with Subversion</em> (for Subversion 1.7), by Ben Collins-Sussman, Brian W. Fitzpatrick, and C. Michael Pilato.<br />
This work is licensed under the <a href="http://creativecommons.org/licenses/by/2.0/">Creative Commons Attribution License v2.0</a>.<br />
To submit comments, corrections, or other contributions to the text, please visit <a href="http://www.svnbook.com/">http://www.svnbook.com/</a>.</p>
</div>
</body>
</html>
distrib
>
Mageia
>
3
>
i586
>
media
>
core-updates
>
by-pkgid
>
1d6e0a3784534d5165fa22faeeca008d
>
files
>
205
