[svnbook-pt-br commit] r113 - trunk/book
codesite-noreply at google.com
codesite-noreply at google.com
Tue Jul 8 06:52:14 CDT 2008
Author: ccidral.newsbox
Date: Tue Jul 8 04:52:08 2008
New Revision: 113
Modified:
trunk/book/ch06-server-configuration.xml
Log:
Reverte as alterações da revisão 102. Para maiores detalhes, vide <http://www.red-bean.com/pipermail/svn-pt_br/2008-May/000689.html>.
Modified: trunk/book/ch06-server-configuration.xml
==============================================================================
--- trunk/book/ch06-server-configuration.xml (original)
+++ trunk/book/ch06-server-configuration.xml Tue Jul 8 04:52:08 2008
@@ -1,33 +1,38 @@
-<?xml version="1.0" encoding="utf-8" ?>
-
<chapter id="svn.serverconfig">
- <title>Server Configuration</title>
- <para>A Subversion repository can be accessed simultaneously by
+ <title>Server Configuration</title>
+
+ <para>A Subversion repository can be accessed simultaneously by
clients running on the same machine on which the repository
resides using the <literal>file://</literal> method. But the
typical Subversion setup involves a single server machine being
accessed from clients on computers all over the office—or,
perhaps, all over the world.</para>
- <para>This chapter describes how to get your Subversion repository
+
+ <para>This chapter describes how to get your Subversion repository
exposed outside its host machine for use by remote clients. We
will cover Subversion's currently available server mechanisms,
discussing the configuration and use of each. After reading
this section, you should be able to decide which networking
setup is right for your needs, and understand how to enable such
a setup on your host computer.</para>
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <sect1 id="svn.serverconfig.overview">
- <title>Overview</title>
- <para>Subversion was designed with an abstract network layer.
+
+
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <sect1 id="svn.serverconfig.overview">
+
+ <title>Overview</title>
+
+ <para>Subversion was designed with an abstract network layer.
This means that a repository can be programmatically accessed by
any sort of server process, and the client <quote>repository
access</quote> API allows programmers to write plugins that
speak relevant network protocols. In theory, Subversion can use
an infinite number of network implementations. In practice,
there are only two servers at the time of this writing.</para>
- <para>Apache is an extremely popular webserver; using the
+
+ <para>Apache is an extremely popular webserver; using the
<command>mod_dav_svn</command> module, Apache can access a
repository and make it available to clients via the
WebDAV/DeltaV protocol, which is an extension of HTTP. Because
@@ -36,7 +41,8 @@
SSL communication, logging, integration with a number of
third-party authentication systems, and limited built-in web
browsing of repositories.</para>
- <para>In the other corner is <command>svnserve</command>: a small,
+
+ <para>In the other corner is <command>svnserve</command>: a small,
lightweight server program that speaks a custom protocol with
clients. Because its protocol is explicitly designed for
Subversion and is stateful (unlike HTTP), it provides
@@ -46,7 +52,8 @@
to encrypt network traffic. It is, however, extremely easy to
set up and is often the best option for small teams just
starting out with Subversion.</para>
- <para>A third option is to use <command>svnserve</command>
+
+ <para>A third option is to use <command>svnserve</command>
tunneled over an SSH connection. Even though this scenario
still uses <command>svnserve</command>, it differs quite a bit
in features from a traditional <command>svnserve</command>
@@ -61,265 +68,286 @@
via <literal>file://</literal> URLs. Path-based access control
has no meaning, since each user is accessing the repository
database files directly.</para>
- <para>Here's a quick summary of the three typical server
+
+ <para>Here's a quick summary of the three typical server
deployments.</para>
- <table id="svn.serverconfig.overview.tbl-1">
- <title>Comparison of Subversion Server Options</title>
- <tgroup cols="4">
- <thead>
- <row>
- <entry>Feature</entry>
- <entry>Apache + mod_dav_svn</entry>
- <entry>svnserve</entry>
- <entry>svnserve over SSH</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>Authentication options</entry>
- <entry>HTTP(S) basic auth, X.509 certificates, LDAP, NTLM, or
+
+ <table id="svn.serverconfig.overview.tbl-1">
+ <title>Comparison of Subversion Server Options</title>
+ <tgroup cols="4">
+ <thead>
+ <row>
+ <entry>Feature</entry>
+ <entry>Apache + mod_dav_svn</entry>
+ <entry>svnserve</entry>
+ <entry>svnserve over SSH</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>Authentication options</entry>
+ <entry>HTTP(S) basic auth, X.509 certificates, LDAP, NTLM, or
any other mechanism available to Apache httpd</entry>
- <entry>CRAM-MD5</entry>
- <entry>SSH</entry>
- </row>
- <row>
- <entry>User account options</entry>
- <entry>private 'users' file</entry>
- <entry>private 'users' file</entry>
- <entry>system accounts</entry>
- </row>
- <row>
- <entry>Authorization options</entry>
- <entry>read/write access can be granted over whole
+ <entry>CRAM-MD5</entry>
+ <entry>SSH</entry>
+ </row>
+
+ <row>
+ <entry>User account options</entry>
+ <entry>private 'users' file</entry>
+ <entry>private 'users' file</entry>
+ <entry>system accounts</entry>
+ </row>
+
+ <row>
+ <entry>Authorization options</entry>
+ <entry>read/write access can be granted over whole
repository, or specified per-path.</entry>
- <entry>read/write access can be granted over whole
+ <entry>read/write access can be granted over whole
repository, or specified per-path.</entry>
- <entry>read/write access only grantable over whole
+ <entry>read/write access only grantable over whole
repository</entry>
- </row>
- <row>
- <entry>Encryption</entry>
- <entry>via optional SSL</entry>
- <entry>none</entry>
- <entry>SSH tunneled</entry>
- </row>
- <row>
- <entry>Logging</entry>
- <entry>full Apache logs of each HTTP request, with
+ </row>
+
+ <row>
+ <entry>Encryption</entry>
+ <entry>via optional SSL</entry>
+ <entry>none</entry>
+ <entry>SSH tunneled</entry>
+ </row>
+
+ <row>
+ <entry>Logging</entry>
+ <entry>full Apache logs of each HTTP request, with
optional <quote>high-level</quote> logging of general
client operations</entry>
- <entry>no logging</entry>
- <entry>no logging</entry>
- </row>
- <row>
- <entry>Interoperability</entry>
- <entry>partially usable by other WebDAV clients</entry>
- <entry>only talks to svn clients</entry>
- <entry>only talks to svn clients</entry>
- </row>
- <row>
- <entry>Web viewing</entry>
- <entry>limited built-in support, or via 3rd-party tools
+ <entry>no logging</entry>
+ <entry>no logging</entry>
+ </row>
+
+ <row>
+ <entry>Interoperability</entry>
+ <entry>partially usable by other WebDAV clients</entry>
+ <entry>only talks to svn clients</entry>
+ <entry>only talks to svn clients</entry>
+ </row>
+
+ <row>
+ <entry>Web viewing</entry>
+ <entry>limited built-in support, or via 3rd-party tools
such as ViewVC</entry>
- <entry>only via 3rd-party tools such as ViewVC</entry>
- <entry>only via 3rd-party tools such as ViewVC</entry>
- </row>
- <row>
- <entry>Speed</entry>
- <entry>somewhat slower</entry>
- <entry>somewhat faster</entry>
- <entry>somewhat faster</entry>
- </row>
- <row>
- <entry>Initial setup</entry>
- <entry>somewhat complex</entry>
- <entry>extremely simple</entry>
- <entry>moderately simple </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- </sect1>
- <sect1 id="svn.serverconfig.choosing">
- <title>Choosing a Server Configuration</title>
- <para>So, which server should you use? Which is best?</para>
- <para>Obviously, there's no right answer to that question. Every
+ <entry>only via 3rd-party tools such as ViewVC</entry>
+ <entry>only via 3rd-party tools such as ViewVC</entry>
+ </row>
+
+ <row>
+ <entry>Speed</entry>
+ <entry>somewhat slower</entry>
+ <entry>somewhat faster</entry>
+ <entry>somewhat faster</entry>
+ </row>
+
+ <row>
+ <entry>Initial setup</entry>
+ <entry>somewhat complex</entry>
+ <entry>extremely simple</entry>
+ <entry>moderately simple </entry>
+ </row>
+
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect1>
+
+ <sect1 id="svn.serverconfig.choosing">
+
+ <title>Choosing a Server Configuration</title>
+
+ <para>So, which server should you use? Which is best?</para>
+
+ <para>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 <quote>official</quote> than another.</para>
- <para>Here are some reasons why you might choose one deployment
+
+ <para>Here are some reasons why you might choose one deployment
over another, as well as reasons you
might <emphasis>not</emphasis> choose one.</para>
- <sect2 id="svn.serverconfig.choosing.svnserve">
- <title>The <command>svnserve</command> Server</title>
- <variablelist>
- <varlistentry>
- <term>Why you might want to use it:</term>
- <listitem>
- <itemizedlist>
- <listitem>
- <para>Quick and easy to set
- up.</para>
- </listitem>
- <listitem>
- <para>Network protocol is stateful and
- noticeably faster than WebDAV.</para>
- </listitem>
- <listitem>
- <para>No need to create system accounts on
- server.</para>
- </listitem>
- <listitem>
- <para>Password is not passed over the
- network.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Why you might want to avoid it:</term>
- <listitem>
- <itemizedlist>
- <listitem>
- <para>Network protocol is not
- encrypted.</para>
- </listitem>
- <listitem>
- <para>Only one choice of authentication
- method.</para>
- </listitem>
- <listitem>
- <para>Password is stored in the clear on the
- server.</para>
- </listitem>
- <listitem>
- <para>No logging of any kind, not even
- errors.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect2>
- <sect2 id="svn.serverconfig.choosing.svn-ssh">
- <title>
- <command>svnserve</command> over SSH</title>
- <variablelist>
- <varlistentry>
- <term>Why you might want to use it:</term>
- <listitem>
- <itemizedlist>
- <listitem>
- <para>Network protocol is stateful and
- noticeably faster than WebDAV.</para>
- </listitem>
- <listitem>
- <para>You can take advantage of existing ssh
- accounts and user infrastructure.</para>
- </listitem>
- <listitem>
- <para>All network traffic is
- encrypted.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Why you might want to avoid it:</term>
- <listitem>
- <itemizedlist>
- <listitem>
- <para>Only one choice of authentication
- method.</para>
- </listitem>
- <listitem>
- <para>No logging of any kind, not even
- errors.</para>
- </listitem>
- <listitem>
- <para>Requires users to be in same system group, or
- use a shared ssh key.</para>
- </listitem>
- <listitem>
- <para>If used improperly, can lead to file permissions
- problems.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect2>
- <sect2 id="svn.serverconfig.choosing.apache">
- <title>The Apache HTTP Server</title>
- <variablelist>
- <varlistentry>
- <term>Why you might want to use it:</term>
- <listitem>
- <itemizedlist>
- <listitem>
- <para>Allows Subversion to use any of the
+
+ <sect2 id="svn.serverconfig.choosing.svnserve">
+
+ <title>The <command>svnserve</command> Server</title>
+
+ <variablelist>
+ <varlistentry>
+ <term>Why you might want to use it:</term>
+ <listitem>
+ <itemizedlist>
+
+ <listitem><para>Quick and easy to set
+ up.</para></listitem>
+
+ <listitem><para>Network protocol is stateful and
+ noticeably faster than WebDAV.</para></listitem>
+
+ <listitem><para>No need to create system accounts on
+ server.</para></listitem>
+
+ <listitem><para>Password is not passed over the
+ network.</para></listitem>
+
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Why you might want to avoid it:</term>
+ <listitem>
+ <itemizedlist>
+
+ <listitem><para>Network protocol is not
+ encrypted.</para></listitem>
+
+ <listitem><para>Only one choice of authentication
+ method.</para></listitem>
+
+ <listitem><para>Password is stored in the clear on the
+ server.</para></listitem>
+
+ <listitem><para>No logging of any kind, not even
+ errors.</para></listitem>
+
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ </sect2>
+
+ <sect2 id="svn.serverconfig.choosing.svn-ssh">
+
+ <title><command>svnserve</command> over SSH</title>
+
+ <variablelist>
+ <varlistentry>
+ <term>Why you might want to use it:</term>
+ <listitem>
+ <itemizedlist>
+
+ <listitem><para>Network protocol is stateful and
+ noticeably faster than WebDAV.</para></listitem>
+
+ <listitem><para>You can take advantage of existing ssh
+ accounts and user infrastructure.</para></listitem>
+
+ <listitem><para>All network traffic is
+ encrypted.</para></listitem>
+
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Why you might want to avoid it:</term>
+ <listitem>
+ <itemizedlist>
+
+ <listitem><para>Only one choice of authentication
+ method.</para></listitem>
+
+ <listitem><para>No logging of any kind, not even
+ errors.</para></listitem>
+
+ <listitem><para>Requires users to be in same system group, or
+ use a shared ssh key.</para></listitem>
+
+ <listitem><para>If used improperly, can lead to file permissions
+ problems.</para></listitem>
+
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ </sect2>
+
+ <sect2 id="svn.serverconfig.choosing.apache">
+
+ <title>The Apache HTTP Server</title>
+
+ <variablelist>
+ <varlistentry>
+ <term>Why you might want to use it:</term>
+ <listitem>
+ <itemizedlist>
+
+ <listitem><para>Allows Subversion to use any of the
numerous authentication systems already integrated
- with Apache.</para>
- </listitem>
- <listitem>
- <para>No need to create system accounts on
- server.</para>
- </listitem>
- <listitem>
- <para>Full Apache logging.</para>
- </listitem>
- <listitem>
- <para>Network traffic can be encrypted via
- SSL.</para>
- </listitem>
- <listitem>
- <para>HTTP(S) can usually go through corporate
- firewalls.</para>
- </listitem>
- <listitem>
- <para>Built-in repository browsing via web
- browser.</para>
- </listitem>
- <listitem>
- <para>Repository can be mounted as a network
+ with Apache.</para></listitem>
+
+ <listitem><para>No need to create system accounts on
+ server.</para></listitem>
+
+ <listitem><para>Full Apache logging.</para></listitem>
+
+ <listitem><para>Network traffic can be encrypted via
+ SSL.</para></listitem>
+
+ <listitem><para>HTTP(S) can usually go through corporate
+ firewalls.</para></listitem>
+
+ <listitem><para>Built-in repository browsing via web
+ browser.</para></listitem>
+
+ <listitem><para>Repository can be mounted as a network
drive for transparent version control. (See
<xref
- linkend="svn.webdav.autoversioning"/>.)</para>
- </listitem>
- </itemizedlist>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Why you might want to avoid it:</term>
- <listitem>
- <itemizedlist>
- <listitem>
- <para>Noticeably slower than svnserve, because
+ linkend="svn.webdav.autoversioning"/>.)</para></listitem>
+
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Why you might want to avoid it:</term>
+ <listitem>
+ <itemizedlist>
+
+ <listitem><para>Noticeably slower than svnserve, because
HTTP is a stateless protocol and requires more
- turnarounds.</para>
- </listitem>
- <listitem>
- <para>Initial setup can be complex.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect2>
- <sect2 id="svn.serverconfig.choosing.recommendations">
- <title>Recommendations</title>
- <para>In general, the authors of this book recommend a vanilla
+ turnarounds.</para></listitem>
+
+ <listitem><para>Initial setup can be complex.</para></listitem>
+
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ </sect2>
+
+ <sect2 id="svn.serverconfig.choosing.recommendations">
+
+ <title>Recommendations</title>
+
+ <para>In general, the authors of this book recommend a vanilla
<command>svnserve</command> 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.</para>
- <para>Here are some general recommendations and tips, based on
+
+ <para>Here are some general recommendations and tips, based on
years of supporting users:</para>
- <itemizedlist>
- <listitem>
- <para>If you're trying to set up the simplest possible
+
+ <itemizedlist>
+ <listitem>
+ <para>If you're trying to set up the simplest possible
server for your group, then a
vanilla <command>svnserve</command> installation is the
easiest, fastest route. Note, however, that your
@@ -329,17 +357,19 @@
repository is exposed to the wide-open internet, then you
might want to make sure the repository's contents aren't
sensitive (e.g. it contains only open-source code.)</para>
- </listitem>
- <listitem>
- <para>If you need to integrate with existing identity
+ </listitem>
+
+ <listitem>
+ <para>If you need to integrate with existing identity
systems (LDAP, Active Directory, NTLM, X.509, etc.), then
an Apache-based server is your only real option.
Similarly, if you absolutely need server-side logs of
either server errors or client activities, then an
Apache-based server is required.</para>
- </listitem>
- <listitem>
- <para>If you've decided to use either Apache or stock
+ </listitem>
+
+ <listitem>
+ <para>If you've decided to use either Apache or stock
<command>svnserve</command>, create a
single <literal>svn</literal> user on your system and run
the server process as that user. Be sure to make the
@@ -349,9 +379,10 @@
siloed and protected by operating system filesystem
permissions, changeable by only the Subversion server
process itself.</para>
- </listitem>
- <listitem>
- <para>If you have an existing infrastructure heavily based
+ </listitem>
+
+ <listitem>
+ <para>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
@@ -362,9 +393,10 @@
full-blown system accounts. If your deep desire for
encrypted communication still draws you to this option, we
recommend using Apache with SSL instead.</para>
- </listitem>
- <listitem>
- <para>Do <emphasis>not</emphasis> be seduced by the simple
+ </listitem>
+
+ <listitem>
+ <para>Do <emphasis>not</emphasis> be seduced by the simple
idea of having all of your users access a repository
directly via <literal>file://</literal> URLs. Even if
the repository is readily available to everyone via
@@ -381,16 +413,21 @@
the same as local users accessing
via <literal>file://</literal>, and can entail all the
same problems if the administrator isn't careful.</para>
- </listitem>
- </itemizedlist>
- </sect2>
- </sect1>
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <sect1 id="svn.serverconfig.svnserve">
- <title>svnserve, a custom server</title>
- <para>The <command>svnserve</command> program is a lightweight
+ </listitem>
+ </itemizedlist>
+
+ </sect2>
+
+ </sect1>
+
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <sect1 id="svn.serverconfig.svnserve">
+
+ <title>svnserve, a custom server</title>
+
+ <para>The <command>svnserve</command> program is a lightweight
server, capable of speaking to clients over TCP/IP using a
custom, stateful protocol. Clients contact an
<command>svnserve</command> server by using URLs that begin with
@@ -399,48 +436,47 @@
<command>svnserve</command>, how clients authenticate themselves
to the server, and how to configure appropriate access control
to your repositories.</para>
- <!-- =============================================================== -->
- <sect2 id="svn.serverconfig.svnserve.invoking">
- <title>Invoking the Server</title>
- <para>There are a few different ways to run the
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.serverconfig.svnserve.invoking">
+ <title>Invoking the Server</title>
+
+ <para>There are a few different ways to run the
<command>svnserve</command> program:</para>
- <itemizedlist>
- <listitem>
- <para>Run <command>svnserve</command> as a
+
+ <itemizedlist>
+ <listitem><para>Run <command>svnserve</command> as a
standalone daemon, listening for
- requests.</para>
- </listitem>
- <listitem>
- <para>Have the Unix <command>inetd</command> daemon
+ requests.</para></listitem>
+ <listitem><para>Have the Unix <command>inetd</command> daemon
temporarily spawn <command>svnserve</command> whenever a
- request comes in on a certain port.</para>
- </listitem>
- <listitem>
- <para>Have SSH invoke a
+ request comes in on a certain port.</para></listitem>
+ <listitem><para>Have SSH invoke a
temporary <command>svnserve</command> over an encrypted
- tunnel.</para>
- </listitem>
- <listitem>
- <para>Run <command>svnserve</command> as a Windows
- service.</para>
- </listitem>
- </itemizedlist>
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
- <sect3 id="svn.serverconfig.svnserve.invoking.daemon">
- <title>
- <command>svnserve</command> as Daemon</title>
- <para>The easiest option is to run <command>svnserve</command>
+ tunnel.</para></listitem>
+ <listitem><para>Run <command>svnserve</command> as a Windows
+ service.</para></listitem>
+ </itemizedlist>
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <sect3 id="svn.serverconfig.svnserve.invoking.daemon">
+ <title><command>svnserve</command> as Daemon</title>
+
+ <para>The easiest option is to run <command>svnserve</command>
as a standalone <quote>daemon</quote> process. Use the
<option>-d</option> option for this:</para>
- <screen>
+
+ <screen>
$ svnserve -d
$ # svnserve is now running, listening on port 3690
</screen>
- <para>When running <command>svnserve</command> in daemon mode,
+
+ <para>When running <command>svnserve</command> in daemon mode,
you can use the <option>--listen-port=</option> and
<option>--listen-host=</option> options to customize the
exact port and hostname to <quote>bind</quote> to.</para>
- <para>Once we successfully start <command>svnserve</command> as above,
+
+ <para>Once we successfully start <command>svnserve</command> as above,
it makes every repository on your system available to the
network. A client needs to specify an
<emphasis>absolute</emphasis> path in the repository URL. For
@@ -451,25 +487,30 @@
To increase security, you can pass the <option>-r</option>
option to <command>svnserve</command>, which restricts it to
exporting only repositories below that path. For example:</para>
- <screen>
+
+ <screen>
$ svnserve -d -r /usr/local/repositories
…
</screen>
- <para>Using the <option>-r</option> option effectively
+
+ <para>Using the <option>-r</option> option effectively
modifies the location that the program treats as the root of
the remote filesystem space. Clients then use URLs that
have that path portion removed from them, leaving much
shorter (and much less revealing) URLs:</para>
- <screen>
+
+ <screen>
$ svn checkout svn://host.example.com/project1
…
</screen>
- </sect3>
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
- <sect3 id="svn.serverconfig.svnserve.invoking.inetd">
- <title>
- <command>svnserve</command> via <command>inetd</command></title>
- <para>If you want <command>inetd</command> to launch the
+
+ </sect3>
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <sect3 id="svn.serverconfig.svnserve.invoking.inetd">
+ <title><command>svnserve</command> via <command>inetd</command></title>
+
+ <para>If you want <command>inetd</command> to launch the
process, then you need to pass the <option>-i</option>
(<option>--inetd</option>) option. In the example, we've shown the
output from running <literal>svnserve -i</literal> at the
@@ -477,11 +518,13 @@
daemon; see the paragraphs following the example for how to
configure <command>inetd</command> to
start <command>svnserve</command>.</para>
- <screen>
+
+ <screen>
$ svnserve -i
( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )
</screen>
- <para>When invoked with the <option>--inetd</option> option,
+
+ <para>When invoked with the <option>--inetd</option> option,
<command>svnserve</command> attempts to speak with a
Subversion client via <emphasis>stdin</emphasis> and
<emphasis>stdout</emphasis> using a custom protocol. This is
@@ -490,17 +533,21 @@
for the Subversion protocol, so on a Unix-like system you can
add lines to <filename>/etc/services</filename> like these (if
they don't already exist):</para>
- <screen>
+
+ <screen>
svn 3690/tcp # Subversion
svn 3690/udp # Subversion
</screen>
- <para>And if your system is using a classic Unix-like
+
+ <para>And if your system is using a classic Unix-like
<command>inetd</command> daemon, you can add this line to
<filename>/etc/inetd.conf</filename>:</para>
- <screen>
+
+ <screen>
svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i
</screen>
- <para>Make sure <quote>svnowner</quote> is a user which has
+
+ <para>Make sure <quote>svnowner</quote> is a user which has
appropriate permissions to access your repositories. Now, when
a client connection comes into your server on port 3690,
<command>inetd</command> will spawn an
@@ -508,12 +555,14 @@
you may also want to add <option>-r</option> to the
configuration line as well, to restrict which repositories are
exported.</para>
- </sect3>
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
- <sect3 id="svn.serverconfig.svnserve.invoking.tunnel">
- <title>
- <command>svnserve</command> over a Tunnel</title>
- <para>A third way to invoke <command>svnserve</command> is in
+
+ </sect3>
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <sect3 id="svn.serverconfig.svnserve.invoking.tunnel">
+ <title><command>svnserve</command> over a Tunnel</title>
+
+ <para>A third way to invoke <command>svnserve</command> is in
<quote>tunnel mode</quote>, with the <option>-t</option>
option. This mode assumes that a remote-service program
such as <command>RSH</command> or <command>SSH</command> has
@@ -533,14 +582,17 @@
full read and write access to the repository database files.
It's essentially the same as a local user accessing the
repository via <literal>file://</literal> URLs.</para>
- <para>This option is described in much more detail in
+
+ <para>This option is described in much more detail in
<xref linkend="svn.serverconfig.svnserve.sshauth"/>.</para>
- </sect3>
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
- <sect3 id="svn.serverconfig.svnserve.invoking.winservice">
- <title>
- <command>svnserve</command> as Windows Service</title>
- <para>If your Windows system is a descendant of Windows NT
+
+ </sect3>
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <sect3 id="svn.serverconfig.svnserve.invoking.winservice">
+ <title><command>svnserve</command> as Windows Service</title>
+
+ <para>If your Windows system is a descendant of Windows NT
(2000, 2003, XP, Vista), then you can
run <command>svnserve</command> as a standard Windows
service. This is typically a much nicer experience than
@@ -552,25 +604,29 @@
automatically, and can be started and stopped using the same
consistent administration interface as other
Windows services. </para>
- <para>You'll need to define the new service using the
+
+ <para>You'll need to define the new service using the
command-line tool <command>SC.EXE</command>. Much like
the <command>inetd</command> configuration line, you must
specify an exact invocation of <command>svnserve</command>
for Windows to run at start-up time:</para>
- <screen>
+
+ <screen>
C:\> sc create svn
binpath= "C:\svn\bin\svnserve.exe --service -r C:\repos"
displayname= "Subversion Server"
depend= Tcpip
start= auto
</screen>
- <para>This defines a new Windows service
+
+ <para>This defines a new Windows service
named <quote>svn</quote>, and which executes a
particular <command>svnserve.exe</command> command when
started (in this case, rooted
at <filename>C:\repos</filename>.) There are a number of
caveats in the prior example, however.</para>
- <para>First, notice that the <command>svnserve.exe</command>
+
+ <para>First, notice that the <command>svnserve.exe</command>
program must always be invoked with
the <option>--service</option> option. Any other options to
<command>svnserve</command> must then be specified on the
@@ -589,72 +645,78 @@
need escaping), place the entire inner value
of <literal>binpath</literal> in double-quotes, by escaping
them:</para>
- <screen>
+
+ <screen>
C:\> sc create svn
binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r C:\repos"
displayname= "Subversion Server"
depend= Tcpip
start= auto
</screen>
- <para>Also note that the word <literal>binpath</literal> is
+
+ <para>Also note that the word <literal>binpath</literal> is
misleading—its value is a <emphasis>command
line</emphasis>, not the path to an executable. That's why
you need to surround it with quote marks if it contains
embedded spaces.</para>
- <para>Once the service is defined, it can stopped, started, or
+
+ <para>Once the service is defined, it can stopped, started, or
queried using standard GUI tools (the Services
administrative control panel), or at the command line as
well:</para>
- <screen>
+
+ <screen>
C:\> net stop svn
C:\> net start svn
</screen>
- <para>The service can also be uninstalled (i.e. undefined) by
+
+ <para>The service can also be uninstalled (i.e. undefined) by
deleting its definition: <literal>sc delete svn</literal>.
Just be sure to stop the service first!
The <command>SC.EXE</command> program has many other
subcommands and options; run <literal>sc /?</literal> to
learn more about it.</para>
- </sect3>
- </sect2>
- <!-- =============================================================== -->
- <sect2 id="svn.serverconfig.svnserve.auth">
- <title>Built-in authentication and authorization</title>
- <para>When a client connects to an <command>svnserve</command>
+
+ </sect3>
+
+ </sect2>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.serverconfig.svnserve.auth">
+ <title>Built-in authentication and authorization</title>
+
+ <para>When a client connects to an <command>svnserve</command>
process, the following things happen:</para>
- <itemizedlist>
- <listitem>
- <para>The client selects a specific
- repository.</para>
- </listitem>
- <listitem>
- <para>The server processes the repository's
+
+ <itemizedlist>
+ <listitem><para>The client selects a specific
+ repository.</para></listitem>
+
+ <listitem><para>The server processes the repository's
<filename>conf/svnserve.conf</filename> file, and begins to
enforce any authentication and authorization policies defined
- therein.</para>
- </listitem>
- <listitem>
- <para>Depending on the situation and authorization
+ therein.</para></listitem>
+
+ <listitem><para>Depending on the situation and authorization
policies,</para>
- <itemizedlist>
- <listitem>
- <para>the client may be allowed to make requests
+
+ <itemizedlist>
+ <listitem><para>the client may be allowed to make requests
anonymously, without ever receiving an authentication
- challenge, OR</para>
- </listitem>
- <listitem>
- <para>the client may be challenged for
- authentication at any time, OR</para>
- </listitem>
- <listitem>
- <para>if operating in <quote>tunnel
+ challenge, OR</para></listitem>
+
+ <listitem><para>the client may be challenged for
+ authentication at any time, OR</para></listitem>
+
+ <listitem><para>if operating in <quote>tunnel
mode</quote>, the client will declare itself to be
- already externally authenticated.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- </itemizedlist>
- <para>At the time of writing, the server only knows how to send
+ already externally authenticated.</para></listitem>
+ </itemizedlist>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>At the time of writing, the server only knows how to send
a CRAM-MD5 <footnote><para>See RFC 2195.</para></footnote>
authentication challenge. In essence, the server sends a
small amount of data to the client. The client uses the MD5
@@ -664,13 +726,15 @@
password to verify that the result is identical. <emphasis>At
no point does the actual password travel over the
network.</emphasis></para>
- <para>It's also possible, of course, for the client to be
+
+ <para>It's also possible, of course, for the client to be
externally authenticated via a tunnel agent, such as
<command>SSH</command>. In that case, the server simply
examines the user it's running as, and uses it as the
authenticated username. For more on this, see <xref
linkend="svn.serverconfig.svnserve.sshauth"/>.</para>
- <para>As you've already guessed, a repository's
+
+ <para>As you've already guessed, a repository's
<filename>svnserve.conf</filename> file is the central
mechanism for controlling authentication and authorization
policies. The file has the same format as other configuration
@@ -681,20 +745,24 @@
specific variables that can be set (<literal>variable =
value</literal>). Let's walk through these files and learn how
to use them.</para>
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
- <sect3 id="svn.serverconfig.svnserve.auth.users">
- <title>Create a 'users' file and realm</title>
- <para>For now, the <literal>[general]</literal> section of the
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <sect3 id="svn.serverconfig.svnserve.auth.users">
+ <title>Create a 'users' file and realm</title>
+
+ <para>For now, the <literal>[general]</literal> section of the
<filename>svnserve.conf</filename> has all the variables you
need. Begin by changing the values of those variables:
choose a name for a file which will contain your usernames
and passwords, and choose an authentication realm:</para>
- <screen>
+
+ <screen>
[general]
password-db = userfile
realm = example realm
</screen>
- <para>The <literal>realm</literal> is a name that you define.
+
+ <para>The <literal>realm</literal> is a name that you define.
It tells clients which sort of <quote>authentication
namespace</quote> they're connecting to; the Subversion
client displays it in the authentication prompt, and uses it
@@ -704,12 +772,14 @@
<literal>password-db</literal> variable points to a separate
file that contains a list of usernames and passwords, using
the same familiar format. For example:</para>
- <screen>
+
+ <screen>
[users]
harry = foopassword
sally = barpassword
</screen>
- <para>The value of <literal>password-db</literal> can be an
+
+ <para>The value of <literal>password-db</literal> can be an
absolute or relative path to the users file. For many
admins, it's easy to keep the file right in the
<filename>conf/</filename> area of the repository, alongside
@@ -723,11 +793,14 @@
set the file's read and write permissions appropriately. If
you know which user(s) <command>svnserve</command> will run
as, restrict read access to the user file as necessary.</para>
- </sect3>
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
- <sect3 id="svn.serverconfig.svnserve.auth.general">
- <title>Set access controls</title>
- <para>There are two more variables to set in the
+
+ </sect3>
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <sect3 id="svn.serverconfig.svnserve.auth.general">
+ <title>Set access controls</title>
+
+ <para>There are two more variables to set in the
<filename>svnserve.conf</filename> file: they determine what
unauthenticated (anonymous) and authenticated users are
allowed to do. The variables <literal>anon-access</literal>
@@ -738,7 +811,8 @@
<literal>read</literal> allows read-only access to the
repository, and <literal>write</literal> allows complete
read/write access to the repository. For example:</para>
- <screen>
+
+ <screen>
[general]
password-db = userfile
realm = example realm
@@ -749,11 +823,13 @@
# authenticated users can both read and write
auth-access = write
</screen>
- <para>The example settings are, in fact, the default values of
+
+ <para>The example settings are, in fact, the default values of
the variables, should you forget to define them. If you
want to be even more conservative, you can block anonymous
access completely:</para>
- <screen>
+
+ <screen>
[general]
password-db = userfile
realm = example realm
@@ -764,14 +840,16 @@
# authenticated users can both read and write
auth-access = write
</screen>
- <para>The server process not only understands
+
+ <para>The server process not only understands
these <quote>blanket</quote> access controls to the
repository, but also finer-grained access restrictions placed
on specific files and directories within the repository. To
make use of this feature, you need to define a file containing
more detailed rules, and then set
the <literal>authz-db</literal> variable to point to it:</para>
- <screen>
+
+ <screen>
[general]
password-db = userfile
realm = example realm
@@ -779,7 +857,8 @@
# Specific access rules for specific locations
authz-db = authzfile
</screen>
- <para>The syntax of the <filename>authzfile</filename> file is
+
+ <para>The syntax of the <filename>authzfile</filename> file is
discussed in detail in
<xref linkend="svn.serverconfig.pathbasedauthz"/>. Note
that the <literal>authz-db</literal> variable isn't mutually
@@ -787,23 +866,27 @@
and <literal>auth-access</literal> variables; if all the
variables are defined at once, then <emphasis>all</emphasis>
of the rules must be satisfied before access is allowed.</para>
- </sect3>
- </sect2>
- <!-- =============================================================== -->
- <sect2 id="svn.serverconfig.svnserve.sshauth">
- <title>Tunneling over SSH</title>
- <para>
- <command>svnserve</command>'s built-in authentication can
+
+ </sect3>
+ </sect2>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.serverconfig.svnserve.sshauth">
+ <title>Tunneling over SSH</title>
+
+ <para><command>svnserve</command>'s built-in authentication can
be very handy, because it avoids the need to create real
system accounts. On the other hand, some administrators
already have well-established SSH authentication frameworks in
place. In these situations, all of the project's users
already have system accounts and the ability to <quote>SSH
into</quote> the server machine.</para>
- <para>It's easy to use SSH in conjunction with
+
+ <para>It's easy to use SSH in conjunction with
<command>svnserve</command>. The client simply uses the
<literal>svn+ssh://</literal> URL scheme to connect:</para>
- <screen>
+
+ <screen>
$ whoami
harry
@@ -815,7 +898,8 @@
baz
…
</screen>
- <para>In this example, the Subversion client is invoking a local
+
+ <para>In this example, the Subversion client is invoking a local
<command>ssh</command> process, connecting to
<literal>host.example.com</literal>, authenticating as the
user <literal>harry</literal>, then spawning a private
@@ -829,7 +913,8 @@
user <literal>harry</literal>, and if the client performs a
commit, the authenticated username will be used as the
author of the new revision.</para>
- <para>The important thing to understand here is that the
+
+ <para>The important thing to understand here is that the
Subversion client is <emphasis>not</emphasis> connecting to a
running <command>svnserve</command> daemon. This method of
access doesn't require a daemon, nor does it notice one if
@@ -837,7 +922,8 @@
<command>ssh</command> to spawn a temporary
<command>svnserve</command> process, which then terminates
when the network connection is closed.</para>
- <para>When using <literal>svn+ssh://</literal> URLs to access a
+
+ <para>When using <literal>svn+ssh://</literal> URLs to access a
repository, remember that it's the <command>ssh</command>
program prompting for authentication, and
<emphasis>not</emphasis> the <command>svn</command> client
@@ -852,7 +938,8 @@
use a separate SSH password-caching tool like
<command>ssh-agent</command> on a Unix-like system, or
<command>pageant</command> on Windows.</para>
- <para>When running over a tunnel, authorization is primarily
+
+ <para>When running over a tunnel, authorization is primarily
controlled by operating system permissions to the repository's
database files; it's very much the same as if Harry were
accessing the repository directly via a
@@ -872,7 +959,8 @@
the repository database.</para>
</footnote>
</para>
- <para>You'd think that the story of SSH tunneling would end
+
+ <para>You'd think that the story of SSH tunneling would end
here, but it doesn't. Subversion allows you to create custom
tunnel behaviors in your run-time <filename>config</filename>
file (see <xref linkend="svn.advanced.confarea"/>). For example,
@@ -882,11 +970,13 @@
<literal>[tunnels]</literal> section of your
<filename>config</filename> file, simply define it like
this:</para>
- <screen>
+
+ <screen>
[tunnels]
rsh = rsh
</screen>
- <para>And now, you can use this new tunnel definition by using a
+
+ <para>And now, you can use this new tunnel definition by using a
URL scheme that matches the name of your new variable:
<literal>svn+rsh://host/path</literal>. When using the new
URL scheme, the Subversion client will actually be running the
@@ -896,11 +986,13 @@
will also include that in its command (<command>rsh
username at host svnserve -t</command>). But you can define new
tunneling schemes to be much more clever than that:</para>
- <screen>
+
+ <screen>
[tunnels]
joessh = $JOESSH /opt/alternate/ssh -p 29934
</screen>
- <para>This example demonstrates a couple of things. First, it
+
+ <para>This example demonstrates a couple of things. First, it
shows how to make the Subversion client launch a very specific
tunneling binary (the one located at
<filename>/opt/alternate/ssh</filename>) with specific
@@ -909,7 +1001,8 @@
particular SSH binary with <option>-p 29934</option> as
arguments—useful if you want the tunnel program to
connect to a non-standard port.</para>
- <para>Second, it shows how to define a custom environment
+
+ <para>Second, it shows how to define a custom environment
variable that can override the name of the tunneling program.
Setting the <literal>SVN_SSH</literal> environment variable is
a convenient way to override the default SSH tunnel agent.
@@ -922,64 +1015,80 @@
variable—<command>$JOESSH</command> would be executed
instead of <command>/opt/alternate/ssh -p
29934</command>.</para>
- </sect2>
- <!-- =============================================================== -->
- <sect2 id="svn.serverconfig.svnserve.sshtricks">
- <title>SSH configuration tricks</title>
- <para>It's not only possible to control the way in which the
+
+ </sect2>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.serverconfig.svnserve.sshtricks">
+ <title>SSH configuration tricks</title>
+
+ <para>It's not only possible to control the way in which the
client invokes <command>ssh</command>, but also to control
the behavior of <command>sshd</command> on your server
machine. In this section, we'll show how to control the
exact <command>svnserve</command> command executed
by <command>sshd</command>, as well as how to have multiple
users share a single system account.</para>
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
- <sect3 id="svn.serverconfig.svnserve.sshtricks.setup">
- <title>Initial setup</title>
- <para>To begin, locate the home directory of the account
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <sect3 id="svn.serverconfig.svnserve.sshtricks.setup">
+ <title>Initial setup</title>
+
+ <para>To begin, locate the home directory of the account
you'll be using to launch <command>svnserve</command>. Make
sure the account has an SSH public/private keypair
installed, and that the user can log in via public-key
authentication. Password authentication will not work,
since all of the following SSH tricks revolve around using
the SSH <filename>authorized_keys</filename> file.</para>
- <para>If it doesn't already exist, create the
+
+ <para>If it doesn't already exist, create the
<filename>authorized_keys</filename> file (on Unix,
typically <filename>~/.ssh/authorized_keys</filename>).
Each line in this file describes a public key that is
allowed to connect. The lines are typically of the
form:</para>
- <screen>
+
+ <screen>
ssh-dsa AAAABtce9euch… user at example.com
</screen>
- <para>The first field describes the type of key, the second
+
+ <para>The first field describes the type of key, the second
field is the base64-encoded key itself, and the third field
is a comment. However, it's a lesser known fact that the
entire line can be preceded by a <literal>command</literal>
field:</para>
- <screen>
+
+ <screen>
command="program" ssh-dsa AAAABtce9euch… user at example.com
</screen>
- <para>When the <literal>command</literal> field is set, the
+
+ <para>When the <literal>command</literal> field is set, the
SSH daemon will run the named program instead of the
typical <command>svnserve -t</command> invocation that the
Subversion client asks for. This opens the door to a number
of server-side tricks. In the following examples, we
abbreviate the lines of the file as:</para>
- <screen>
+
+ <screen>
command="program" TYPE KEY COMMENT
</screen>
- </sect3>
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
- <sect3 id="svn.serverconfig.svnserve.sshtricks.fixedcmd">
- <title>Controlling the invoked command</title>
- <para>Because we can specify the executed server-side command,
+
+ </sect3>
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <sect3 id="svn.serverconfig.svnserve.sshtricks.fixedcmd">
+ <title>Controlling the invoked command</title>
+
+ <para>Because we can specify the executed server-side command,
it's easy to name a specific <command>svnserve</command>
binary to run and to pass it extra arguments:</para>
- <screen>
+
+ <screen>
command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT
</screen>
- <para>In this example, <filename>/path/to/svnserve</filename>
+
+ <para>In this example, <filename>/path/to/svnserve</filename>
might be a custom wrapper script
around <command>svnserve</command> which sets the umask (see
<xref linkend="svn.serverconfig.multimethod"/>). It also shows how to
@@ -990,18 +1099,21 @@
system, or simply to relieve the user of having to type an
absolute path in the <literal>svn+ssh://</literal>
URL.</para>
- <para>It's also possible to have multiple users share a single
+
+ <para>It's also possible to have multiple users share a single
account. Instead of creating a separate system account for
each user, generate a public/private keypair for each
person. Then place each public key into
the <filename>authorized_users</filename> file, one per
line, and use the <option>--tunnel-user</option>
option:</para>
- <screen>
+
+ <screen>
command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry at example.com
command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally at example.com
</screen>
- <para>This example allows both Harry and Sally to connect to
+
+ <para>This example allows both Harry and Sally to connect to
the same account via public-key authentication. Each of
them has a custom command that will be executed;
the <option>--tunnel-user</option> option
@@ -1010,7 +1122,8 @@
<option>--tunnel-user</option>, it would appear as though
all commits were coming from the one shared system
account.</para>
- <para>A final word of caution: giving a user access to the
+
+ <para>A final word of caution: giving a user access to the
server via public-key in a shared account might still allow
other forms of SSH access, even if you've set
the <literal>command</literal> value
@@ -1020,20 +1133,28 @@
To give the user as little permission as possible, you may
want to specify a number of restrictive options immediately
after the <literal>command</literal>:</para>
- <screen>
+
+ <screen>
command="svnserve -t --tunnel-user=harry",no-port-forwarding,\
no-agent-forwarding,no-X11-forwarding,no-pty \
TYPE1 KEY1 harry at example.com
</screen>
- </sect3>
- </sect2>
- </sect1>
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <sect1 id="svn.serverconfig.httpd">
- <title>httpd, the Apache HTTP server</title>
- <para>The Apache HTTP Server is a <quote>heavy duty</quote>
+
+ </sect3>
+
+ </sect2>
+
+ </sect1>
+
+
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <sect1 id="svn.serverconfig.httpd">
+
+ <title>httpd, the Apache HTTP server</title>
+
+ <para>The Apache HTTP Server is a <quote>heavy duty</quote>
network server that Subversion can leverage. Via a custom
module, <command>httpd</command> makes Subversion repositories
available to clients via the WebDAV/DeltaV protocol, which is an
@@ -1052,7 +1173,8 @@
While an Apache-Subversion server has more features than
<command>svnserve</command>, it's also a bit more difficult
to set up. With flexibility often comes more complexity.</para>
- <para>Much of the following discussion includes references to
+
+ <para>Much of the following discussion includes references to
Apache configuration directives. While some examples are given
of the use of these directives, describing them in full is
outside the scope of this chapter. The Apache team maintains
@@ -1060,7 +1182,8 @@
<ulink url="http://httpd.apache.org"/>. For example, a general
reference for the configuration directives is located at <ulink url="
http://httpd.apache.org/docs-2.0/mod/directives.html"/>.</para>
- <para>Also, as you make changes to your Apache setup, it is likely
+
+ <para>Also, as you make changes to your Apache setup, it is likely
that somewhere along the way a mistake will be made. If you are
not already familiar with Apache's logging subsystem, you should
become aware of it. In your <filename>httpd.conf</filename>
@@ -1072,9 +1195,11 @@
the contents of those files for information that might reveal
the source of a problem that is not clearly noticeable
otherwise.</para>
- <sidebar>
- <title>Why Apache 2?</title>
- <para>If you're a system administrator, it's very likely that
+
+ <sidebar>
+ <title>Why Apache 2?</title>
+
+ <para>If you're a system administrator, it's very likely that
you're already running the Apache web server and have some
prior experience with it. At the time of writing, Apache 1.3
is by far the most popular version of Apache. The world has
@@ -1085,21 +1210,26 @@
are waiting for a 2.X port. Whatever the reason, many people
begin to worry when they first discover that Subversion's
Apache module is written specifically for the Apache 2 API.</para>
- <para>The proper response to this problem is: don't worry about
+
+ <para>The proper response to this problem is: don't worry about
it. It's easy to run Apache 1.3 and Apache 2 side-by-side;
simply install them to separate places, and use Apache 2 as a
dedicated Subversion server that runs on a port other than 80.
Clients can access the repository by placing the port number
into the URL:</para>
- <screen>
+
+ <screen>
$ svn checkout http://host.example.com:7382/repos/project
…
</screen>
- </sidebar>
- <!-- =============================================================== -->
- <sect2 id="svn.serverconfig.httpd.prereqs">
- <title>Prerequisites</title>
- <para>To network your repository over HTTP, you basically need
+ </sidebar>
+
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.serverconfig.httpd.prereqs">
+ <title>Prerequisites</title>
+
+ <para>To network your repository over HTTP, you basically need
four components, available in two packages. You'll need
Apache <command>httpd</command> 2.0, the
<command>mod_dav</command> DAV module that comes with it,
@@ -1107,22 +1237,24 @@
filesystem provider module distributed with Subversion.
Once you have all of those components, the process of
networking your repository is as simple as:</para>
- <itemizedlist>
- <listitem>
- <para>getting httpd 2.0 up and running with the mod_dav
+
+ <itemizedlist>
+ <listitem>
+ <para>getting httpd 2.0 up and running with the mod_dav
module,</para>
- </listitem>
- <listitem>
- <para>installing the mod_dav_svn plugin to mod_dav, which
+ </listitem>
+ <listitem>
+ <para>installing the mod_dav_svn plugin to mod_dav, which
uses Subversion's libraries to access the repository,
and</para>
- </listitem>
- <listitem>
- <para>configuring your <filename>httpd.conf</filename>
+ </listitem>
+ <listitem>
+ <para>configuring your <filename>httpd.conf</filename>
file to export (or expose) the repository.</para>
- </listitem>
- </itemizedlist>
- <para>You can accomplish the first two items either by
+ </listitem>
+ </itemizedlist>
+
+ <para>You can accomplish the first two items either by
compiling <command>httpd</command> and Subversion from
source code, or by installing pre-built binary packages of
them on your system. For the most up-to-date information on
@@ -1130,53 +1262,83 @@
as well as how to compile and configure Apache itself for
this purpose, see the <filename>INSTALL</filename> file in
the top level of the Subversion source code tree.</para>
- </sect2>
- <!-- =============================================================== -->
- <sect2 id="svn.serverconfig.httpd.basic">
- <title>Configuração básica do Apache</title>
- <para>Depois de ter todos os componentes necessários instalados em seu sistema,
- tudo o que resta é a configuração do Apache através do seu arquivo <filename>httpd.conf</filename>.
- Você deve instruir o Apache para carregar o <command>mod_dav_svn</command> na diretiva <literal>LoadModule</literal>.
- Esta diretiva deve preceder qualquer outro item de configuração relacionada com Subversion. Se o seu Apache foi instalado usando o layout padrão, seu módulo
- <command>mod_dav_svn</command> deveria ter sido instalada no subdiretório de <filename>modules</filename> do Apache local da instalação (geralmente
- <filename>/usr/local/apache2</filename>). A diretiva <literal>LoadModule</literal> tem uma sintaxe simples, mapear um chamado ao módulo para a localização de uma biblioteca compartilhada em disco:</para>
- <screen>
+
+ </sect2>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.serverconfig.httpd.basic">
+ <title>Basic Apache Configuration</title>
+
+ <para>Once you have all the necessary components installed on
+ your system, all that remains is the configuration of Apache
+ via its <filename>httpd.conf</filename> file. Instruct Apache
+ to load the mod_dav_svn module using the
+ <literal>LoadModule</literal> directive. This directive must
+ precede any other Subversion-related configuration items. If
+ your Apache was installed using the default layout, your
+ <command>mod_dav_svn</command> module should have been
+ installed in the <filename>modules</filename> subdirectory of
+ the Apache install location (often
+ <filename>/usr/local/apache2</filename>). The
+ <literal>LoadModule</literal> directive has a simple syntax,
+ mapping a named module to the location of a shared library on
+ disk:</para>
+
+ <screen>
LoadModule dav_svn_module modules/mod_dav_svn.so
</screen>
- <para>Note que se <command>mod_dav</command> foi compilado como um objeto
- compartilhado (ao em invés de estático ligado diretamente ao o binário
- <command>httpd</command>), você precisará de uma declaração semelhante ao
- <literal>LoadModule</literal> também. Tenha a certeza de que <command>mod_dav_svn</command> está antes da linha:</para>
- <screen>
+
+ <para>Note that if <command>mod_dav</command> was compiled as a
+ shared object (instead of statically linked directly to the
+ <command>httpd</command> binary), you'll need a similar
+ <literal>LoadModule</literal> statement for it, too. Be sure
+ that it comes before the <command>mod_dav_svn</command> line:</para>
+
+ <screen>
LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so
</screen>
- <para>Em um local mais adiante em seu arquivo de configuração,
- agora você precisa dizer ao Apache onde você mantêm seu Repositório Subversion (ou repositórios).
- A diretiva <literal>Location</literal> tem uma notação como XML, começando com a tag de abertura,
- e termina com a tag de fechamento, com várias outras diretivas de configuração entre elas.
- O objetivo da diretiva de <literal>Location</literal> é a de instruir o Apache a fazer algo especial,
- ao tratar os pedidos que são dirigidos para um determinado URL ou um dos seus filhos. No caso do Subversion,
- você simplesmente deseja que o Apache controle e de apoio para que as URLs que apontam para recursos versionados
- para a camada DAV. Você pode instruir o Apache para delegar a manipulação de toda as URLs cujo parte do caminho
- (a parte do URL que segue o nome do servidor e o número de porta opcional) comecem com <filename>/repos/</filename>
- para um prestador DAV esse repositório está localizado em <filename>/absolute/path/to/repository</filename>
- utilizando no <filename>httpd.conf</filename> a seguinte sintaxe:</para>
- <screen>
+
+
+ <para>At a later location in your configuration file, you now
+ need to tell Apache where you keep your Subversion repository
+ (or repositories). The <literal>Location</literal> directive
+ has an XML-like notation, starting with an opening tag, and
+ ending with a closing tag, with various other configuration
+ directives in the middle. The purpose of the
+ <literal>Location</literal> directive is to instruct Apache to
+ do something special when handling requests that are directed
+ at a given URL or one of its children. In the case of
+ Subversion, you want Apache to simply hand off support for
+ URLs that point at versioned resources to the DAV layer. You
+ can instruct Apache to delegate the handling of all URLs whose
+ path portions (the part of the URL that follows the server's
+ name and the optional port number) begin with
+ <filename>/repos/</filename> to a DAV provider whose
+ repository is located at
+ <filename>/absolute/path/to/repository</filename> using the
+ following <filename>httpd.conf</filename> syntax:</para>
+
+ <screen>
<Location /repos>
DAV svn
SVNPath /absolute/path/to/repository
</Location>
</screen>
- <para>Se você pretende utilizar múltiplos repositórios com o
- Subversion que irão residir no mesmo diretório pai em seu disco rígido,
- você pode usar uma diretiva alternativa, a diretiva <literal>SVNParentPath</literal>,
- para indicar que o comum diretório pai. Por exemplo, se você sabe que será criando vários
- repositórios Subversion em um diretório <filename>/usr/local/svn</filename> que iria ser acessado via URLs como
- <uri>http://my.server.com/svn/repos1</uri>, <uri>http://my.server.com/svn/repos2</uri>, ae assim por diante,
- você pode usar a sintaxe de configuração <filename>httpd.conf</filename>
- como o seguinte exemplo:</para>
- <screen>
+
+ <para>If you plan to support multiple Subversion repositories
+ that will reside in the same parent directory on your local
+ disk, you can use an alternative directive, the
+ <literal>SVNParentPath</literal> directive, to indicate that
+ common parent directory. For example, if you know you will be
+ creating multiple Subversion repositories in a directory
+ <filename>/usr/local/svn</filename> that would be accessed via
+ URLs like <uri>http://my.server.com/svn/repos1</uri>,
+ <uri>http://my.server.com/svn/repos2</uri>, and
+ so on, you could use the <filename>httpd.conf</filename>
+ configuration syntax in the following example:</para>
+
+ <screen>
<Location /svn>
DAV svn
@@ -1184,98 +1346,145 @@
SVNParentPath /usr/local/svn
</Location>
</screen>
- <para>Usando a sintaxe anterior, o Apache irá delegar
- a manipulação de todos os URLs cujo parte do caminho comecem com
- <filename>/svn/</filename> para o fornecedor Subversion DAV,
- que irá então assumir que quaisquer itens no diretório especificado
- pela diretiva <literal>SVNParentPath</literal> são, na realidade,
- repositórios do Subversion. Esta sintaxe é particularmente conveniente uma,
- em que, ao contrário da utilização da diretiva <literal>SVNPath</literal>
- você não ter de reiniciar o Apache, a fim de criar novos repositórios na rede.
- </para>
- <para>Tenha a certeza de que quando você definir seu novo <literal>Location</literal>,
- esse não se sobrepõe a outros endereços exportados. Por exemplo, se o seu diretório
- <literal>DocumentRoot</literal> é exportado para <filename>/www</filename>, dnão exporte um
- repositório Subversion para <literal><Location /www/repos></literal>.
- Se uma solicitação para a URI <filename>/www/repos/foo.c</filename>, O Apache, não saberá
- onde procurar pelo arquivo <filename>repos/foo.c</filename> no diretório <literal>DocumentRoot</literal>,
- ou se delega ao <command>mod_dav_svn</command> uma resposta a<filename>foo.c</filename> a partir do repositório
- Subversion. O resultado é muitas vezes um erro do servidor do formulário <literal>301 Moved Permanently</literal>.
- </para>
- <sidebar>
- <title>Servidor de Nomes e de Solicitação de Cópia</title>
- <para>Subversion faz uso da solicitação de <literal>COPY</literal>
- para realizar cópias de arquivos e diretórios do lado do servidor.
- Como parte da verificação de integridade feita pelo módulo do Apache,
- a fonte da cópia é esperada que se situe na mesma máquina que o destino da cópia.
- Para satisfazer este requisito, você necessariamente deverá dizer ao mod_dav o nome
- que você usa como o host de seu servidor. Geralmente,
- você pode usar a diretiva <literal>ServerName</literal> em
- <filename>httpd.conf</filename> para realizar esta tarefa.</para>
- <screen>
+
+ <para>Using the previous syntax, Apache will delegate the
+ handling of all URLs whose path portions begin with
+ <filename>/svn/</filename> to the Subversion DAV provider,
+ which will then assume that any items in the directory
+ specified by the <literal>SVNParentPath</literal> directive
+ are actually Subversion repositories. This is a particularly
+ convenient syntax in that, unlike the use of the
+ <literal>SVNPath</literal> directive, you don't have to
+ restart Apache in order to create and network new
+ repositories.</para>
+
+ <para>Be sure that when you define your new
+ <literal>Location</literal>, it doesn't overlap with other
+ exported Locations. For example, if your main
+ <literal>DocumentRoot</literal> is exported to
+ <filename>/www</filename>, do not export a Subversion
+ repository in <literal><Location /www/repos></literal>.
+ If a request comes in for the URI
+ <filename>/www/repos/foo.c</filename>, Apache won't know
+ whether to look for a file <filename>repos/foo.c</filename> in
+ the <literal>DocumentRoot</literal>, or whether to delegate
+ <command>mod_dav_svn</command> to return
+ <filename>foo.c</filename> from the Subversion repository.
+ The result is often an error from the server of the form
+ <literal>301 Moved Permanently</literal>.</para>
+
+ <sidebar>
+ <title>Server Names and the COPY Request</title>
+
+ <para>Subversion makes use of the <literal>COPY</literal>
+ request type to perform server-side copies of files and
+ directories. As part of the sanity checking done by the
+ Apache modules, the source of the copy is expected to be
+ located on the same machine as the destination of the copy.
+ To satisfy this requirement, you might need to tell mod_dav
+ the name you use as the hostname of your server. Generally,
+ you can use the <literal>ServerName</literal> directive in
+ <filename>httpd.conf</filename> to accomplish this.</para>
+
+ <screen>
ServerName svn.example.com
</screen>
- <para>Se você estiver usando o Apache como host virtual com o apoio da diretiva
- <literal>NameVirtualHost</literal> pode ser necessário usar a diretiva
- <literal>ServerAlias</literal> para especificar que seus nomes adicionais serão
- reconhecido pelo servidor. Mais uma vez, remeter a documentação do
- Apache para informações completas.</para>
- </sidebar>
- <para>Nesta fase, você deve considerar fortemente a questão de permissões.
- Se você está executando Apache há algum tempo como o seu servidor web,
- você provavelmente já tem uma coleção de conteúdo das páginas da web, scripts e tal.
- Esses itens já foram configurados com um conjunto das permissões que lhes permite trabalhar com Apache,
- ou mais apropriadamente, que permite que o Apache trabalhe com esses arquivos. Apache,
- quando usado como um servidor Subversion, também terão as permissões corretas para ler e escrever para o seu repositório Subversion.</para>
- <para>Nesta fase, você deve considerar fortemente a questão de permissões. Se você está executando Apache há algum tempo como o seu servidor web, você provavelmente já tem uma coleção de conteúdo das páginas da web, scripts e tal. Esses itens já foram configurados com um conjunto das permissões que lhes permite trabalhar com Apache, ou mais apropriadamente, que permite que o Apache trabalhe com esses arquivos. Apache, quando usado como um servidor Subversion, também terão as permissões corretas para ler e escrever para o seu repositório Subversion.
-Você terá que determinar uma permissão do sistema que satisfaz os requisitos do Subversion sem alterar quaisquer instalações de páginas web anteriormente existentes ou script. Isto poderá significar mudar as permissões em seu repositório Subversion que estejam à altura desses em uso por outras coisas para qual você utiliza o Apache como servidor, ou ele pode utilizar as diretivas
- <literal>User</literal> e <literal>Group</literal>
- em <filename>httpd.conf</filename> para especificar que o Apache deve rodar com os usuário e grupos que seu repositório Subversion detém. Não existe uma maneira correta de configurar a sua permissão, e cada administrador possuem diferentes razões para fazer as coisas de determinada maneira. Basta ter consciência de que problemas relacionadas com a permissão são talvez as mais comuns quando configurando um repositório Subversion para uso com o Apache.
- </para>
- </sect2>
- <!-- =============================================================== -->
- <sect2 id="svn.serverconfig.httpd.authn">
- <title>Opções de autenticação</title>
- <para>Neste ponto, se você configurou o
- <filename>httpd.conf</filename> ele deve conter algo como</para>
- <screen>
+
+ <para>If you are using Apache's virtual hosting support via
+ the <literal>NameVirtualHost</literal> directive, you may
+ need to use the <literal>ServerAlias</literal> directive to
+ specify additional names that your server is known by.
+ Again, refer to the Apache documentation for full
+ details.</para>
+ </sidebar>
+
+ <para>At this stage, you should strongly consider the question
+ of permissions. If you've been running Apache for some time
+ now as your regular web server, you probably already have a
+ collection of content—web pages, scripts and such.
+ These items have already been configured with a set of
+ permissions that allows them to work with Apache, or more
+ appropriately, that allows Apache to work with those files.
+ Apache, when used as a Subversion server, will also need the
+ correct permissions to read and write to your Subversion
+ repository.</para>
+
+ <para>You will need to determine a permission system setup that
+ satisfies Subversion's requirements without messing up any
+ previously existing web page or script installations. This
+ might mean changing the permissions on your Subversion
+ repository to match those in use by other things that Apache
+ serves for you, or it could mean using the
+ <literal>User</literal> and <literal>Group</literal>
+ directives in <filename>httpd.conf</filename> to specify that
+ Apache should run as the user and group that owns your
+ Subversion repository. There is no single correct way to set
+ up your permissions, and each administrator will have
+ different reasons for doing things a certain way. Just be
+ aware that permission-related problems are perhaps the most
+ common oversight when configuring a Subversion repository for
+ use with Apache.</para>
+
+ </sect2>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.serverconfig.httpd.authn">
+ <title>Authentication Options</title>
+
+ <para>At this point, if you configured
+ <filename>httpd.conf</filename> to contain something like</para>
+
+ <screen>
<Location /svn>
DAV svn
SVNParentPath /usr/local/svn
</Location>
</screen>
- <para>…Então o seu repositório é <quote>anonymously</quote>
- acessível para o mundo. Até você configurar algumas políticas de autenticação e autorização,
- o repositório Subversion que você fez disponível através da diretiva de
- <literal>Location</literal> será geralmente accessível a todos. Em outras palavras,
- </para>
- <itemizedlist>
- <listitem>
- <para>qualquer pessoa pode usar seu cliente Subversion para fazer uma copia de trabalho de um repositório URL (ou qualquer um de seus subdiretórios), </para>
- </listitem>
- <listitem>
- <para>qualquer pessoa pode navegar interativamente a última revisão do repositório simplesmente apontando a URL do repositório no navegador web </para>
- </listitem>
- <listitem>
- <para>qualquer um pode escrever no repositório.</para>
- </listitem>
- </itemizedlist>
- <para>Evidentemente, você já pode ter criado um script de <filename>pre-commit</filename>
- para evitar escrita (veja <xref linkend="svn.reposadmin.create.hooks"/>).
- Mas, como você lerá adiante, você verá que também é possível utilizar métodos do Apache para
- restringir o acesso de formas específicas.
- </para>
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
- <sect3 id="svn.serverconfig.httpd.authn.basic">
- <title>Autenticação Básica HTTP</title>
- <para>A maneira mais fácil de se autenticar um cliente é a via mecanismo
- básico de autenticação HTTP, que utiliza apenas um nome de usuário e senha para
- verificar se um usuário é que ela diz que ela é. O Apache fornece um utilitário o
- <command>htpasswd</command>
- para gerenciar a lista de nomes de usuários e senhas aceitável. Vamos conceder acesso a
- escrita a Harry e Sally. Primeiro, temos que adicioná-los ao arquivo de senha.
- </para>
- <screen>
+
+ <para>…then your repository is <quote>anonymously</quote>
+ accessible to the world. Until you configure some
+ authentication and authorization policies, the Subversion
+ repositories you make available via the
+ <literal>Location</literal> directive will be generally
+ accessible to everyone. In other words,</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>anyone can use their Subversion client to check out a
+ working copy of a repository URL (or any of its
+ subdirectories),</para>
+ </listitem>
+ <listitem>
+ <para>anyone can interactively browse the repository's
+ latest revision simply by pointing their web browser to
+ the repository URL, and</para>
+ </listitem>
+ <listitem>
+ <para>anyone can commit to the repository.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>Of course, you might have already set up
+ a <filename>pre-commit</filename> hook script to prevent
+ commits (see <xref linkend="svn.reposadmin.create.hooks"/>).
+ But as you read on, you'll see that it's also possible use
+ Apache's built-in methods to restrict access in specific
+ ways.</para>
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <sect3 id="svn.serverconfig.httpd.authn.basic">
+ <title>Basic HTTP Authentication</title>
+
+ <para>The easiest way to authenticate a client is via the
+ HTTP Basic authentication mechanism, which simply uses a
+ username and password to verify that a user is who she says
+ she is. Apache provides an <command>htpasswd</command>
+ utility for managing the list of acceptable usernames and
+ passwords. Let's grant commit access to
+ Sally and Harry. First, we need to add them to the password
+ file.</para>
+
+ <screen>
$ ### First time: use -c to create the file
$ ### Use -m to use MD5 encryption of the password, which is more secure
$ htpasswd -cm /etc/svn-auth-file harry
@@ -1288,16 +1497,27 @@
Adding password for user sally
$
</screen>
- <para>Em seguida, você precisa acrescentar mais algumas diretivas ao
- <filename>httpd.conf</filename> dentro do seu bloco
- <literal>Location</literal> dizer ao Apache o que fazer com a sua novo arquivo de senha. A diretiva
- <literal>AuthType</literal> especifica o tipo de sistema de autenticação a ser usado. Neste caso, nós queremos especificar o sistema de autenticação <literal>Basic</literal>.
- <literal>AuthName</literal> é um nome arbitrário que você dá para o domínio de autenticação. A maior parte dos navegadores irá exibir esse nome na caixa de diálogo pop-up quando o navegador está questionando o usuário para o seu nome e senha. Por último, a utilização da diretiva <literal>AuthUserFile</literal> para especificar a localização do arquivo de senha que você criou o usando o
+
+ <para>Next, you need to add some more
+ <filename>httpd.conf</filename> directives inside your
+ <literal>Location</literal> block to tell Apache what to do
+ with your new password file. The
+ <literal>AuthType</literal> directive specifies the type of
+ authentication system to use. In this case, we want to
+ specify the <literal>Basic</literal> authentication system.
+ <literal>AuthName</literal> is an arbitrary name that you
+ give for the authentication domain. Most browsers will
+ display this name in the pop-up dialog box when the browser
+ is querying the user for his name and password. Finally,
+ use the <literal>AuthUserFile</literal> directive to specify
+ the location of the password file you created using
<command>htpasswd</command>.</para>
- <para>Depois de adicionar estas três diretivas, seu bloco
- <literal><Location></literal> deve ficar parecido com este:
- </para>
- <screen>
+
+ <para>After adding these three directives, your
+ <literal><Location></literal> block should look
+ something like this:</para>
+
+ <screen>
<Location /svn>
DAV svn
SVNParentPath /usr/local/svn
@@ -1306,10 +1526,21 @@
AuthUserFile /etc/svn-auth-file
</Location>
</screen>
- <para>Este bloco<literal><Location></literal> ainda não está completo, e não vai fazer alguma coisa útil. É simplesmente dizer ao Apache que sempre é necessário uma autorização, o Apache deve colher um nome de usuário e senha a partir do cliente Subversion. O que está faltando aqui, no entanto, são diretivas para dizer ao Apache que <emphasis>tipo</emphasis> de requisição do cliente necessita de autorização. Sempre que a autorização é necessária, o Apache irá exigir autenticação também. A coisa mais simples a fazer é proteger todas as solicitações. Adicionando <literal>Require valid-user</literal>
- informando o Apache que todas as requisições exigem um usuário autenticado:
- </para>
- <screen>
+
+ <para>This <literal><Location></literal> block is not
+ yet complete, and will not do anything useful. It's merely
+ telling Apache that whenever authorization is required,
+ Apache should harvest a username and password from the
+ Subversion client. What's missing here, however, are
+ directives that tell Apache <emphasis>which</emphasis> sorts
+ of client requests require authorization. Wherever
+ authorization is required, Apache will demand
+ authentication as well. The simplest thing to do is protect
+ all requests. Adding <literal>Require valid-user</literal>
+ tells Apache that all requests require an authenticated
+ user:</para>
+
+ <screen>
<Location /svn>
DAV svn
SVNParentPath /usr/local/svn
@@ -1319,37 +1550,82 @@
Require valid-user
</Location>
</screen>
- <para>Certifique-se de ler a próxima seção (<xref
- linkend="svn.serverconfig.httpd.authz"/>) para obter mais detalhes sobre a diretiva de
- <literal>Exigir</literal> autenticação e outras maneiras de definir políticas de autorização.</para>
- <para>Uma palavra de advertência: Autenticação básica em HTTP passa muito perto de senhas de texto simples através da rede, e, portanto, são extremamente precárias. Se você estiver preocupado com snooping de senha, pode ser melhor usar algum tipo de criptografia SSL, de modo que os clientes devem autenticar via <literal>https://</literal>
- ao em vez de <literal>http://</literal>; em um mínimo necessário, você pode configurar o Apache para usar um servidor certificado auto-assinado.
+
+ <para>Be sure to read the next section (<xref
+ linkend="svn.serverconfig.httpd.authz"/>) for more detail on the
+ <literal>Require</literal> directive and other ways to set
+ authorization policies.</para>
+
+ <para>One word of warning: HTTP Basic Auth passwords pass in
+ very nearly plain-text over the network, and thus are
+ extremely insecure. If you're worried about password
+ snooping, it may be best to use some sort of SSL encryption,
+ so that clients authenticate via <literal>https://</literal>
+ instead of <literal>http://</literal>; at a bare minimum,
+ you can configure Apache to use a self-signed server
+ certificate.
<footnote>
- <para>Embora certificados auto-assinado de servidor ainda são vulneráveis a ataque <quote>de uma pessoa entre o servidor e o cliente</quote> tal ataque é muito mais difícil para um observador casual, em comparação com snifar senhas desprotegidos.</para>
+ <para>While self-signed server certificates are still
+ vulnerable to a <quote>man in the middle</quote> attack,
+ such an attack is much more difficult for a casual
+ observer to pull off, compared to sniffing unprotected
+ passwords.</para>
</footnote>
- Consulte a documentação do Apache (e documentação OpenSSL) sobre como fazer isso.</para>
- </sect3>
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
- <sect3 id="svn.serverconfig.httpd.authn.sslcerts">
- <title>Gestão de certificado SSL </title>
- <para>As empresas que precisam expor os seus repositórios de acesso fora do firewall da empresa
-devem estar conscientes da possibilidade de que possa ter pessoas não autorizadas
- <quote>sniffing</quote> o tráfego de sua rede. O SSL faz com que esse tipo de atenção indesejada seja menor, reduzindo a probabilidade de fugas de dados sensíveis.</para>
- <para>Se um cliente Subversion é compilado para usar OpenSSL, ele ganha a habilidade de falar com um servidor Apache via URLs <literal>https://</literal>. A biblioteca Neon usada pelo cliente Subversion não é apenas capaz de verificar certificados de servidor, mas também pode fornecer certificados cliente quando desafiados. Quando o cliente e o servidor tiver trocado os certificados SSL e autenticados com êxito, toda a comunicação é criptografada por meio de uma sessão chave.
- </para>
- <para>Está fora do âmbito deste livro descrever a forma de gerar certificados cliente e servidor, e de como configurar o Apache para usá-los. Muitos outros livros, incluindo a própria documentação do Apache, descrevem esta tarefa. Mas o que <emphasis>pode</emphasis> ser coberto aqui é a forma de gerir certificado servidor e cliente a partir de um simples cliente Subversion.</para>
-<para>Quando se fala de Apache via <literal>https://</literal>,
- um cliente Subversion pode receber dois tipos diferentes de informação:</para>
- <itemizedlist>
- <listitem>
- <para>um certificado de servidor </para>
- </listitem>
- <listitem>
- <para>uma procura por um certificado de cliente</para>
- </listitem>
- </itemizedlist>
- <para>ISe o cliente recebe um certificado de um servidor, é necessário se verificar se o certificado é confiável: é o servidor realmente que ela afirma ser? A biblioteca OpenSSL faz isso através da análise do signatário do certificado de servidor, ouSe o cliente recebe um certificado de um servidor, é necessário se verificar se o certificado é confiável: é o servidor realmente que ela afirma ser? A biblioteca OpenSSL faz isso através da análise do signatário do certificado de servidor, ou <firstterm>autoridade certificadora</firstterm> (CA).Se OpenSSL é automaticamente impedido de confiança a CA, ou se algum outro problema ocorre (tal como um certificado expirou ou não encontrou o hostname), o cliente de linha de comando Subversion irá perguntar-lhe se você quer confiar no certificado desse servidor assim mesmo:</para>
- <screen>
+ Consult Apache's documentation (and OpenSSL documentation)
+ about how to do that.</para>
+
+ </sect3>
+
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <sect3 id="svn.serverconfig.httpd.authn.sslcerts">
+ <title>SSL Certificate Management</title>
+
+ <para>Businesses that need to expose their repositories for access
+ outside the company firewall should be conscious of the
+ possibility that unauthorized parties could be
+ <quote>sniffing</quote> their network traffic. SSL makes
+ that kind of unwanted attention less likely to result in
+ sensitive data leaks.</para>
+
+ <para>If a Subversion client is compiled to use OpenSSL, then
+ it gains the ability to speak to an Apache server via
+ <literal>https://</literal> URLs. The Neon library used by
+ the Subversion client is not only able to verify server
+ certificates, but can also supply client certificates when
+ challenged. When the client and server have exchanged SSL
+ certificates and successfully authenticated one another, all
+ further communication is encrypted via a session key.</para>
+
+ <para>It's beyond the scope of this book to describe how to
+ generate client and server certificates, and how to
+ configure Apache to use them. Many other books, including
+ Apache's own documentation, describe this task. But what
+ <emphasis>can</emphasis> be covered here is how to manage
+ server and client certificates from an ordinary Subversion
+ client.</para>
+
+ <para>When speaking to Apache via <literal>https://</literal>,
+ a Subversion client can receive two different types of
+ information:</para>
+
+ <itemizedlist>
+ <listitem><para>a server certificate</para></listitem>
+ <listitem><para>a demand for a client certificate</para></listitem>
+ </itemizedlist>
+
+ <para>If the client receives a server certificate, it needs to
+ verify that it trusts the certificate: is the server really
+ who it claims to be? The OpenSSL library does this by
+ examining the signer of the server certificate, or
+ <firstterm>certifying authority</firstterm> (CA). If
+ OpenSSL is unable to automatically trust the CA, or if some
+ other problem occurs (such as an expired certificate or
+ hostname mismatch), the Subversion command-line client will
+ ask you whether you want to trust the server certificate
+ anyway:</para>
+
+ <screen>
$ svn list https://host.example.com/repos/project
Error validating server certificate for 'https://host.example.com:443':
@@ -1363,22 +1639,49 @@
(R)eject, accept (t)emporarily or accept (p)ermanently?
</screen>
- <para>Este diálogo deve-lhe ser familiar; que é essencialmente a mesma questão que você provavelmente deve ter visto proveniente de seu navegador da web (que é apenas mais um cliente como o HTTP Subversion). Se você escolher a opção (p) ermanent, o certificado do servidor será armazenado na sua sessão privada
- <filename>auth/</filename> da mesma forma em que apenas seu nome de usuário e senha estão em cache (veja <xref
- linkend="svn.serverconfig.netmodel.credcache"/>). Se em cache,o Subversion confiará neste certificado automaticamente em futuras negociações.
- </para>
- <para>Seu <filename>servidor </filename> de tempo de execução de arquivo também dá a você a habilidade de fazer seu cliente Subversion automaticamente confiar em específicos CAs, quer a nível global ou a um host. Basta definir a variável <literal>ssl-authority-files</literal>
- e separar por ponto e virgula a lista de certificados PEM e CA:
- </para>
- <screen>
+
+ <para>This dialogue should look familiar; it's essentially the
+ same question you've probably seen coming from your web
+ browser (which is just another HTTP client like Subversion).
+ If you choose the (p)ermanent option, the server certificate
+ will be cached in your private run-time
+ <filename>auth/</filename> area in just the same way your
+ username and password are cached (see <xref
+ linkend="svn.serverconfig.netmodel.credcache"/>). If cached,
+ Subversion will automatically trust this certificate
+ in future negotiations.</para>
+
+ <para>Your run-time <filename>servers</filename> file also gives
+ you the ability to make your Subversion client automatically
+ trust specific CAs, either globally or on a per-host basis.
+ Simply set the <literal>ssl-authority-files</literal>
+ variable to a semicolon-separated list of PEM-encoded CA
+ certificates:</para>
+
+ <screen>
[global]
ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem
</screen>
- <para>Many Muitas instalações de OpenSSL têm um conjunto pré-definido de CAs <quote>padrão</quote> que são quase universalmente confiáveis. Para fazer com que o cliente Subversion automaticamente confie nestas autoridades padrão, basta definir a variáve
- <literal>ssl-trust-default-ca</literal> como
+
+ <para>Many OpenSSL installations also have a pre-defined set
+ of <quote>default</quote> CAs that are nearly universally
+ trusted. To make the Subversion client automatically trust
+ these standard authorities, set the
+ <literal>ssl-trust-default-ca</literal> variable to
<literal>true</literal>.</para>
- <para>Quando falo com Apache, um cliente Subversion poderá receber também um desafio para um cliente certificado. O Apache está pedindo o cliente se identificar: é o cliente realmente que ele diz que é? Se tudo correr corretamente, o cliente Subversion envia de volta um certificado privado assinado por uma autoridade que o Apache confia. Um cliente certificado é normalmente armazenado no disco em formato criptografado, protegido por uma senha local. Quando Subversion recebe este desafio, ele irá pedir-lhe para tanto um caminho para a obtenção do certificado e a senha que a protege:</para>
- <screen>
+
+ <para>When talking to Apache, a Subversion client might also
+ receive a challenge for a client certificate. Apache is
+ asking the client to identify itself: is the client really
+ who it says it is? If all goes correctly, the Subversion
+ client sends back a private certificate signed by a CA that
+ Apache trusts. A client certificate is usually stored on
+ disk in encrypted format, protected by a local password.
+ When Subversion receives this challenge, it will ask you for
+ both a path to the certificate and the password which
+ protects it:</para>
+
+ <screen>
$ svn list https://host.example.com/repos/project
Authentication realm: https://host.example.com:443
@@ -1386,10 +1689,21 @@
Passphrase for '/path/to/my/cert.p12': ********
…
</screen>
- <para>Note que o certificado do cliente é um arquivo
- <quote>p12</quote>. Para usar um cliente certificado com Subversion, ele deve ser em formato PKCS # 12, que é um padrão portátil. As maiorias dos navegadores já estão capazes de importar e exportar certificados nesse formato. Outra opção é usar ferramentas de linha de comando do OpenSSL para converter os certificados existentes em PKCS # 12.</para>
- <para>Novamente, os <filename>servidores</filename> de arquivo em tempo de execução permitem a você automatizar esse desafio com uma base por host. Uma ou ambas as peças de informação pode ser descrita em variáveis em tempo de execução:</para>
- <screen>
+
+ <para>Notice that the client certificate is a
+ <quote>p12</quote> file. To use a client certificate with
+ Subversion, it must be in PKCS#12 format, which is a
+ portable standard. Most web browsers are already able to
+ import and export certificates in that format. Another
+ option is to use the OpenSSL command-line tools to convert
+ existing certificates into PKCS#12.</para>
+
+ <para>Again, the runtime <filename>servers</filename> file
+ allows you to automate this challenge on a per-host basis.
+ Either or both pieces of information can be described in
+ runtime variables:</para>
+
+ <screen>
[groups]
examplehost = host.example.com
@@ -1397,26 +1711,52 @@
ssl-client-cert-file = /path/to/my/cert.p12
ssl-client-cert-password = somepassword
</screen>
- <para>Depois de definir as variáveis
- <literal>ssl-client-cert-file</literal> e
- <literal>ssl-client-cert-password</literal> o cliente Subversion automaticamente pode responder a um desafio sem o certificado cliente lhe perguntar
+
+ <para>Once you've set the
+ <literal>ssl-client-cert-file</literal> and
+ <literal>ssl-client-cert-password</literal> variables, the
+ Subversion client can automatically respond to a client
+ certificate challenge without prompting you.
<footnote>
- <para>Pessoas com consciência mais segura não pretendem guardar a senha de certificado de cliente em arquivo nos <filename>servidores</filename>de tempo de execução.</para>
+ <para>More security-conscious folk might not want to store
+ the client certificate password in the runtime
+ <filename>servers</filename> file.</para>
</footnote>
</para>
- </sect3>
- </sect2>
- <!-- =============================================================== -->
- <sect2 id="svn.serverconfig.httpd.authz">
- <title>Opções de autorização</title>
- <para>Até este ponto, você configurou a autenticação, mas não a autorização. O Apache é capaz de desafiar clientes e confirmar identidades, mas não tem sido dito quanto a permitir ou restringir o acesso aos clientes que ostentem essas identidades. Esta seção descreve duas estratégias para controlar o acesso aos seus repositórios.</para>
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
- <sect3 id="svn.serverconfig.httpd.authz.blanket">
- <title>Controle de Acesso Coberto</title>
- <para>A forma mais simples de controle de acesso é o de autorizar determinados usuários só de leitura, a um repositório, ou acesso a leitura / escrita a um repositório.</para>
- <para>Você