<?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>Supporting Multiple Repository Access Methods</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.optimization.html" title="Server Optimization" />
<link rel="next" href="svn.customization.html" title="Chapter 7. Customizing Your Subversion Experience" />
</head>
<body>
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center">Supporting Multiple Repository Access Methods</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="svn.serverconfig.optimization.html">Prev</a> </td>
<th width="60%" align="center">Chapter 6. Server Configuration</th>
<td width="20%" align="right"> <a accesskey="n" href="svn.customization.html">Next</a></td>
</tr>
</table>
<hr />
</div>
<div class="sect1" title="Supporting Multiple Repository Access Methods">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="svn.serverconfig.multimethod"></a>Supporting Multiple Repository Access Methods</h2>
</div>
</div>
</div>
<p>You've seen how a repository can be accessed in many
different ways. But is it possible—or safe—for your
repository to be accessed by multiple methods simultaneously?
The answer is yes, provided you use a bit of foresight.</p>
<p>At any given time, these processes may require read and
write access to your repository:</p>
<div class="itemizedlist">
<ul class="itemizedlist" type="disc">
<li class="listitem">
<p>Regular system users using a Subversion client (as
themselves) to access the repository directly via
<code class="literal">file://</code> URLs</p>
</li>
<li class="listitem">
<p>Regular system users connecting to SSH-spawned private
<span class="command"><strong>svnserve</strong></span> processes (running as
themselves), which access the repository</p>
</li>
<li class="listitem">
<p>An <span class="command"><strong>svnserve</strong></span> process—either a
daemon or one launched by
<span class="command"><strong>inetd</strong></span>—running as a particular fixed
user</p>
</li>
<li class="listitem">
<p>An Apache <span class="command"><strong>httpd</strong></span> process, running as a
particular fixed user</p>
</li>
</ul>
</div>
<p>The most common problem administrators run into is
repository ownership and permissions. Does every process (or
user) in the preceding list have the rights to read and write the
repository's underlying data files? Assuming you have a
Unix-like operating system, a straightforward approach might be
to place every potential repository user into a
new <code class="literal">svn</code> group, and make the repository wholly
owned by that group. But even that's not enough, because a
process may write to the database files using an unfriendly
umask—one that prevents access by other users.</p>
<p>So the next step beyond setting up a common group for
repository users is to force every repository-accessing process
to use a sane umask. For users accessing the repository
directly, you can make the <span class="command"><strong>svn</strong></span> program into a
wrapper script that first runs <strong class="userinput"><code>umask 002</code></strong> and
then runs the real <span class="command"><strong>svn</strong></span> client program. You
can write a similar wrapper script for the
<span class="command"><strong>svnserve</strong></span> program, and add a <strong class="userinput"><code>umask
002</code></strong> command to Apache's own startup script,
<code class="filename">apachectl</code>. For example:</p>
<div class="informalexample">
<pre class="screen">
$ cat /usr/bin/svn
#!/bin/sh
umask 002
/usr/bin/svn-real "$@"
</pre>
</div>
<p>Another common problem is often encountered on Unix-like
systems. If your repository is backed by Berkeley DB, for
example, it occasionally creates new log files to journal its
actions. Even if the Berkeley DB repository is wholly owned by
the <span class="command"><strong>svn</strong></span> group, these newly created log files
won't necessarily be owned by that same group, which then
creates more permissions problems for your users. A good
workaround is to set the group SUID bit on the
repository's <code class="filename">db</code> directory. This causes all
newly created log files to have the same group owner as the
parent directory.</p>
<p>Once you've jumped through these hoops, your repository
should be accessible by all the necessary processes. It may
seem a bit messy and complicated, but the problems of having
multiple users sharing write access to common files are classic
ones that are not often elegantly solved.</p>
<p>Fortunately, most repository administrators will never
<span class="emphasis"><em>need</em></span> to have such a complex configuration.
Users who wish to access repositories that live on the same
machine are not limited to using <code class="literal">file://</code>
access URLs—they can typically contact the Apache HTTP
server or <span class="command"><strong>svnserve</strong></span> using
<code class="literal">localhost</code> for the server name in their
<code class="literal">http://</code> or <code class="literal">svn://</code> URL.
And maintaining multiple server processes for your Subversion
repositories is likely to be more of a headache than necessary.
We recommend that you choose a single server that best meets your
needs and stick with it!</p>
<div class="sidebar" title="The svn+ssh:// Server Checklist">
<div class="titlepage">
<div>
<div>
<p class="title">
<strong>The svn+ssh:// Server Checklist</strong>
</p>
</div>
</div>
</div>
<p>It can be quite tricky to get a bunch of users with
existing SSH accounts to share a repository without
permissions problems. If you're confused about all the things
that you (as an administrator) need to do on a Unix-like
system, here's a quick checklist that resummarizes some of the
topics discussed in this section:</p>
<div class="itemizedlist">
<ul class="itemizedlist" type="disc">
<li class="listitem">
<p>All of your SSH users need to be able to read and
write to the repository, so put all the SSH users into a
single group.</p>
</li>
<li class="listitem">
<p>Make the repository wholly owned by that group.</p>
</li>
<li class="listitem">
<p>Set the group permissions to read/write.</p>
</li>
<li class="listitem">
<p>Your users need to use a sane umask when accessing the
repository, so make sure <span class="command"><strong>svnserve</strong></span>
(<code class="filename">/usr/bin/svnserve</code>, or wherever it
lives in <code class="literal">$PATH</code>) is actually a wrapper
script that runs <strong class="userinput"><code>umask 002</code></strong> and
executes the real <span class="command"><strong>svnserve</strong></span>
binary.</p>
</li>
<li class="listitem">
<p>Take similar measures when using
<span class="command"><strong>svnlook</strong></span> and
<span class="command"><strong>svnadmin</strong></span>. Either run them with a sane
umask or wrap them as just described.</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.optimization.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.customization.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Server Optimization </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Chapter 7. Customizing Your Subversion Experience</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
>
208
