[svnbook commit] r3200 - in trunk/src/nb: . book
sunny256
noreply at red-bean.com
Wed Jul 16 22:17:08 CDT 2008
Author: sunny256
Date: Wed Jul 16 22:17:08 2008
New Revision: 3200
Log:
Sync the Norwegian and English book up to r2629.
* src/nb/book/ch-server-configuration.xml
Merged and updated r2628, r2629.
* src/nb/LAST_SYNC
Updated by "make sync HEAD=2629".
* src/nb/TRANSLATION-STATUS
Updated by "make status". Do I really have to write this every time?
Oh well.
Modified:
trunk/src/nb/LAST_SYNC
trunk/src/nb/TRANSLATION-STATUS
trunk/src/nb/book/ch-server-configuration.xml
Modified: trunk/src/nb/LAST_SYNC
==============================================================================
--- trunk/src/nb/LAST_SYNC (original)
+++ trunk/src/nb/LAST_SYNC Wed Jul 16 22:17:08 2008
@@ -1 +1 @@
-2625
+2629
Modified: trunk/src/nb/TRANSLATION-STATUS
==============================================================================
--- trunk/src/nb/TRANSLATION-STATUS (original)
+++ trunk/src/nb/TRANSLATION-STATUS Wed Jul 16 22:17:08 2008
@@ -26,8 +26,8 @@
* book/ch-repository-admin.xml
Untranslated: 2.84% - 131 lines in 9 blocks
* book/ch-server-configuration.xml
- Untranslated: 1.45% - 53 lines in 4 blocks
- Need proofreading: 83.82% - 2070 lines in 1 block
+ Untranslated: 15.39% - 462 lines in 11 blocks
+ Need proofreading: 67.47% - 1850 lines in 3 blocks
* book/ch-customizing-svn.xml
Untranslated: 35.66% - 412 lines in 2 blocks
Need proofreading: 63.98% - 711 lines in 1 block
@@ -49,4 +49,4 @@
* book/index.xml
Translation complete
-Summa summarum: 57.75% translated, 16.93% need proofreading
+Summa summarum: 56.72% translated, 15.94% need proofreading
Modified: trunk/src/nb/book/ch-server-configuration.xml
==============================================================================
--- trunk/src/nb/book/ch-server-configuration.xml (original)
+++ trunk/src/nb/book/ch-server-configuration.xml Wed Jul 16 22:17:08 2008
@@ -87,36 +87,6 @@
<xref linkend="svn.serverconfig.overview.tbl-1"/> viser en
sammenligning av de to &server;modellene.</para>
- <!-- @ENGLISH {{{
- <para>Note that Subversion, as an open-source project, does not
- officially endorse any server as <quote>primary</quote> or
- <quote>official</quote>. Neither network implementation is
- treated as a second-class citizen; each server has advantages
- and disadvantages. In fact, it's possible for different servers
- to run in parallel, each accessing your repositories in its own
- way, and each without hindering the other (see <xref
- linkend="svn.serverconfig.multimethod"/>). <xref
- linkend="svn.serverconfig.overview.tbl-1"/> gives a brief overview and
- comparison of the two available Subversion servers—as an
- administrator, it's up to you to choose whatever works best for
- you and your users.</para>
- @ENGLISH }}} -->
- <para>Legg merke til at Subversion, som et opensourceprosjekt, ikke
- erklærer noen &server;modeller som <quote>primær</quote> eller
- <quote>offisiell</quote>.
- Ingen nettverksimplementasjoner blir sett på som andreklasses
- borgere; hver &server;modell har fordeler og ulemeper.
- Faktisk er det mulig for forskjellige &servers; å kjøre parallelt
- og aksessere depotet på hver sin måte uten å legge hindringer i
- veien for den andre (se <xref
- linkend="svn.serverconfig.multimethod"/>).
- <xref
- linkend="svn.serverconfig.overview.tbl-1"/> inneholder en kort
- oversikt og sammenligning av de to tilgjengelige
- Subversion&the_servers; – som en administrator er det opp til deg
- å velge hva som fungerer best for deg og dine brukere.</para>
-
-
<table id="svn.serverconfig.overview.tbl-1">
<!-- @ENGLISH {{{
<title>Network Server Comparison</title>
@@ -137,140 +107,405 @@
<row>
<!-- @ENGLISH {{{
<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 or SSH</entry>
@ENGLISH }}} -->
<entry>Autentiseringsvalg</entry>
-
<entry>vanlig HTTP(S)-autentisering, X.509-sertifikater,
LDAP, NTLM eller enhver annen mekaniske som er
tilgjengelig for Apache httpd</entry>
-
<entry>CRAM-MD5 eller SSH</entry>
</row>
-
+
<row>
<!-- @ENGLISH {{{
<entry>User account options</entry>
-
<entry>private 'users' file</entry>
-
<entry>private 'users' file, or existing system (SSH)
accounts</entry>
@ENGLISH }}} -->
<entry>Valg for brukerkontoer</entry>
-
<entry>privat fil med brukerliste</entry>
-
<entry>privat fil med brukerliste eller eksisterende
systemkontoer (SSH)</entry>
</row>
-
+
<row>
- <!-- @ENGLISH {{{
+<!-- @TR {{ -->
<entry>Authorization options</entry>
-
- <entry>blanket read/write access, or per-directory
- read/write control</entry>
-
- <entry>blanket read/write access, or per-directory write
- (but not read) control using a pre-commit hook</entry>
- @ENGLISH }}} -->
- <entry>Autorisasjonsvalg</entry>
-
- <entry>fullstendig lese/skrivetilgang, eller katalogbasert
- lese/skrivekontroll</entry>
-
- <entry>fullstendig lese/skrivetilgang, eller katalogbasert
- skrive- (men ikke lesing) kontroll ved å bruke et
- <filename>pre-commit</filename>-påhakningsskript</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
+ repository, or specified per-path.</entry>
+<!-- @TR }} -->
</row>
-
+
<row>
<!-- @ENGLISH {{{
<entry>Encryption</entry>
-
<entry>via optional SSL</entry>
-
<entry>via optional SSH tunnel</entry>
@ENGLISH }}} -->
<entry>Kryptering</entry>
-
<entry>via valgfri SSL</entry>
-
<entry>via valgfri SSH-tunnel</entry>
</row>
+<!-- @TR {{ -->
+ <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>
+ </row>
+<!-- @TR }} -->
+
<row>
<!-- @ENGLISH {{{
<entry>Interoperability</entry>
-
<entry>partially usable by other WebDAV clients</entry>
-
- <entry>not interoperable</entry>
+ <entry>only talks to svn clients</entry>
@ENGLISH }}} -->
<entry>Samspillsevne</entry>
-
<entry>delvis brukbar for andre WebDAV-klienter</entry>
-
- <entry>fungerer ikke sammen</entry>
+ <entry>Kommuniserer bare med svn-klienter</entry>
</row>
<row>
<!-- @ENGLISH {{{
<entry>Web viewing</entry>
-
<entry>limited built-in support, or via 3rd-party tools
such as ViewVC</entry>
-
- <entry>via 3rd-party tools such as ViewVC</entry>
+ <entry>only via 3rd-party tools such as ViewVC</entry>
@ENGLISH }}} -->
<entry>Visning på web</entry>
-
<entry>begrenset innebygget støtte, eller via tredjeparts
verktøy som for eksempel ViewVC</entry>
-
- <entry>via tredjeparts verktøy som for eksempel
+ <entry>kun via tredjeparts verktøy som for eksempel
ViewVC</entry>
</row>
<row>
<!-- @ENGLISH {{{
<entry>Speed</entry>
-
<entry>somewhat slower</entry>
-
<entry>somewhat faster</entry>
@ENGLISH }}} -->
<entry>Hastighet</entry>
-
<entry>Noe langsommere</entry>
-
<entry>Noe raskere</entry>
</row>
<row>
<!-- @ENGLISH {{{
<entry>Initial setup</entry>
-
<entry>somewhat complex</entry>
-
<entry>fairly simple</entry>
@ENGLISH }}} -->
<entry>Innledende oppsett</entry>
-
<entry>Noe komplekst</entry>
-
<entry>Ganske enkelt</entry>
</row>
</tbody>
- </tgroup>
+ </tgroup>
</table>
-
+
+
+
+ <sect2 id="svn.serverconfig.overview.apache">
+
+<!-- @TR {{ -->
+ <title>The Apache HTTP Server</title>
+
+ <variablelist>
+
+ <varlistentry>
+ <term>How it works:</term>
+ <listitem>
+ <para>Install and configure and standard Apache 2.0
+ server, then activate a special subversion-server module.
+ Clients speak to server via HTTP or HTTPS, using the WebDAV
+ protocol.</para>
+ </listitem>
+ </varlistentry>
+
+ <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
+ 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
+ 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.overview.svnserve">
+
+ <title>The <command>svnserve</command> Server</title>
+
+ <variablelist>
+
+ <varlistentry>
+ <term>How it works:</term>
+ <listitem>
+ <para>A lightweight serve process which can run either as
+ a persistent daemon, or as something automatically
+ launched by inetd when necessary. Clients authenticate
+ via CRAM-MD5 algorithm and speak a custom network
+ protocol.</para>
+ </listitem>
+ </varlistentry>
+
+ <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.overview.svn-ssh">
+
+ <title><command>svnserve</command> over SSH</title>
+
+ <variablelist>
+
+ <varlistentry>
+ <term>How it works:</term>
+ <listitem>
+ <para> Each client uses an existing SSH (system) account
+ to spawn a temporary <command>svnserve</command> process
+ (running as themselves) on the server machine. The
+ <command>svnserve</command> process accesses the
+ repository, communicates with the client over the SSH
+ tunnel, then dies when the SSH connection is closed.
+ (There is no long-running <command>svnserve</command>
+ process.)</para>
+ </listitem>
+ </varlistentry>
+
+ <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>Can lead to file permissions
+ problems.</para></listitem>
+
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ </sect2>
+
+ <sect2 id="svn.serverconfig.overview.choosing-a-server">
+
+ <title>Choosing the Best 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>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.
+ Remember, you can always switch to a more complex server
+ deployment as your needs change.</para>
+
+ <para>Here are some general recommendations, based on years of
+ supporting users:</para>
+
+ <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
+ repository data will be transmitted in the clear over the
+ network. If your deployment is entirely within your
+ company's LAN or VPN, this isn't an issue. If the
+ repository is exposed to the wide-open internet, then you
+ might want to make sure 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
+ 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
+ <command>svnserve</command>, create a
+ single <literal>svn</literal> user on your system, and
+ run either Apache or svnserve as that user. Be sure to
+ make the repository directory wholly owned by
+ the <literal>svn</literal> user as well. These keeps the
+ repository data nicely siloed and protected by operating
+ system filesystem permissions, changeable by only the
+ Subverion server process itself.</para>
+ </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
+ recommend this option to the general public. It's
+ generally considered safer to have your users access the
+ repository via (imaginary) accounts managed
+ by <command>svnserve</command> or Apache, rather than by
+ full-blown system accounts. If your deep desire for
+ encrypted communication still draws you to this option, we
+ recommend using Apache with SSL instead.</para>
+ </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
+ network share, this is a bad idea. It removes any layers
+ of protection between the users and the repository: users
+ can accidentally (or intentionally) corrupt the repository
+ database, it becomes hard to take the repository 'offline'
+ for inspection or upgrade, and it can lead to a mess of
+ file-permissions problems (see
+ <xref linkend="svn.serverconfig.multimethod"/>.) Note
+ that this is also one of the reasons we warn against
+ accessing repositories via <literal>svn+ssh://</literal>
+ URLs — from a security standpoint, it's effectively
+ 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>
+<!-- @TR }} -->
+
+ </sect2>
+
</sect1>
<!-- ================================================================= -->
@@ -957,8 +1192,7 @@
back to the client. When <command>svnserve</command> is
invoked by a tunnel agent like this, be sure that the
authenticated user has full read and write access to the
- repository database files. (See <xref
- linkend="svn.serverconfig.svnserve.invoking.sb-1"/>.) It's essentially the same as
+ repository database files. It's essentially the same as
a local user accessing the repository via
<literal>file:///</literal> URLs.</para>
@ENGLISH }}} -->
@@ -978,65 +1212,10 @@
Når <command>svnserve</command> blir startet av en <!-- ¤ agent
-->tunnelagent som dette, pass på at den autentiserte brukeren
har full skrive- og leseaksess til databasefilene i depotet.
- (Se <xref linkend="svn.serverconfig.svnserve.invoking.sb-1"/>.)
Det er hovedsaklig det samme prinsippet som når en lokal bruker
får tilgang til depotet via
<literal>file:///</literal>-URLer.</para>
- <sidebar id="svn.serverconfig.svnserve.invoking.sb-1">
- <!-- @ENGLISH {{{
- <title>Servers and Permissions: A Word of Warning</title>
- @ENGLISH }}} -->
- <title>&Servers; og rettigheter: En liten advarsel</title>
-
- <!-- @ENGLISH {{{
- <para>First, remember that a Subversion repository is a
- collection of database files; any process which accesses the
- repository directly needs to have proper read and write
- permissions on the entire repository. If you're not
- careful, this can lead to a number of headaches, especially
- if you're using a Berkeley DB database rather than FSFS. Be
- sure to read <xref linkend="svn.serverconfig.multimethod"/>.</para>
- @ENGLISH }}} -->
- <para>For det første, husk at et Subversiondepot er en samling
- med databasefiler; enhver prosess som aksesserer depotet
- direkte må ha tilstrekkelige lese- og skriverettigheter til
- hele depotet.
- Hvis du ikke er forsiktig, kan dette føre til en rekke
- hodepiner, spesielt hvis du bruker en Berkeley DB-database
- istedenfor FSFS.
- Pass på å lese <xref
- linkend="svn.serverconfig.multimethod"/>.</para>
-
- <!-- @ENGLISH {{{
- <para>Secondly, when configuring <command>svnserve</command>,
- Apache <command>httpd</command>, or any other server
- process, keep in mind that you might not want to launch the
- server process as the user <literal>root</literal> (or as
- any other user with unlimited permissions). Depending on
- the ownership and permissions of the repositories you're
- exporting, it's often prudent to use a
- different—perhaps custom—user. For example,
- many administrators create a new user named
- <literal>svn</literal>, grant that user exclusive ownership
- and rights to the exported Subversion repositories, and only
- run their server processes as that user.</para>
- @ENGLISH }}} -->
- <para>For det andre, når du setter opp
- <command>svnserve</command>, Apache <command>httpd</command>
- eller en annen &server;prosess, husk på at du ikke vil starte
- tjenesten som <literal>root</literal>-brukeren (eller en annen
- bruker med ubegrensede rettigheter).
- Avhengig av eierskapet og rettighetene på depotene du
- eksporterer, er det ofte fornuftig å bruke en annen – kanskje
- spesiallaget – bruker.
- For eksempel lager mange administratorer en ny bruker kalt
- <literal>svn</literal>, gir denne eksklusivt eierskap og
- rettigheter til de eksporterte Subversiondepotene og kjører
- &server;prosessene kun som denne brukeren.</para>
- </sidebar>
-
-
<!-- @ENGLISH {{{
<para>Once the <command>svnserve</command> program is running,
it makes every repository on your system available to the
@@ -1449,49 +1628,42 @@
# autentiserte brukere kan både lese og skrive
auth-access = write
</screen>
+<!-- @CHK }} -->
- <!-- @ENGLISH {{{
- <para>Notice that <command>svnserve</command> only understands
- <quote>blanket</quote> access control. A user either has
- universal read/write access, universal read access, or no
- access. There is no detailed control over access to
- specific paths within the repository. For many projects and
- sites, this level of access control is more than adequate.
- However, if you need per-directory access control, you'll
- need to use either use Apache with
- <command>mod_authz_svn</command> (see <xref
- linkend="svn.serverconfig.httpd.authz.perdir"/>) or use a
- <command>pre-commit</command> hook script to control write
- access (see <xref linkend="svn.reposadmin.create.hooks"/>). The
- Subversion distribution comes with
- <command>commit-access-control.pl</command> and the more
- sophisticated <command>svnperms.py</command> scripts for use
- in pre-commit scripts.</para>
- @ENGLISH }}} -->
- <para>Legg merke til at <command>svnserve</command> bare forstår
- <!-- ¤ blanket --><quote>fullstendig</quote> tilgangskontroll.
- En bruker har enten universell lese/skrive-tilgang, universell
- lesetilgang eller ingen tilgang.
- Det er ingen detaljert kontroll over tilgang til spesifikke
- stier i depotet.
- For mange prosjekter og <!-- ¤ sites -->&servers; er dette
- nivået på tilgangskontroll mer enn nok.
- Hvis du imidlertid trenger tilgangskontroll på katalognivå, må
- du enten bruke Apache med <command>mod_auth_svn</command> (se
- <xref linkend="svn.serverconfig.httpd.authz.perdir"/>) eller
- bruke et <command>pre-commit</command>-påhakningsskript for å
- kontrollere skrivetilgangen (se <xref
- linkend="svn.reposadmin.create.hooks"/>).
- Subversiondistribusjonen kommer med skriptet
- <command>commit-access-control.pl</command> og det mer
- sofistikerte <command>svnperms.py</command> for bruk i
- <command>pre-commit</command>-skript.</para>
+<!-- @TR {{ -->
+ <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>
+[general]
+password-db = userfile
+realm = example realm
+
+# Specific access rules for specific locations
+authz-db = authzfile
+</screen>
+
+ <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
+ exclusive with the <literal>anon-access</literal>
+ 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>
+<!-- @TR }} -->
</sect3>
</sect2>
<!-- =============================================================== -->
<sect2 id="svn.serverconfig.svnserve.sshauth">
+<!-- @CHK {{ -->
<!-- @ENGLISH {{{
<title>SSH authentication and authorization</title>
@ENGLISH }}} -->
@@ -1651,7 +1823,14 @@
tunneling, the <filename>svnserve.conf</filename> file can
still be used to block access, by simply setting
<literal>auth-access = read</literal> or <literal>auth-access
- = none</literal>.</para>
+ = none</literal>.
+ <footnote>
+ <para>Note that using any sort
+ of <command>svnserve</command>-enforced access control at
+ all is a bit pointless; the user already has direct access to
+ the repository database.</para>
+ </footnote>
+ </para>
@ENGLISH }}} -->
<para>Når tilkobling skjer gjennom en tunnel, blir autorisering
for databasefilene i depotet hovedsaklig kontrollert av
@@ -1665,8 +1844,16 @@
Men selv i tilfellet med bruk av tunnel kan
<filename>svnserve.conf</filename> bli brukt til å blokkere
tilgang ved å sette <literal>auth-access = read</literal> eller
- <literal>auth-access = none</literal>.</para>
-
+ <literal>auth-access = none</literal>.<footnote>
+<!-- @TR {{ -->
+ <para>Note that using any sort of
+ <command>svnserve</command>-enforced access control at all
+ is a bit pointless; the user already has direct access to
+ the repository database.</para>
+<!-- @TR }} -->
+ </footnote>
+ </para>
+
<!-- @ENGLISH {{{
<para>You'd think that the story of SSH tunneling would end
here, but it doesn't. Subversion allows you to create custom
@@ -2526,11 +2713,11 @@
Vanligvis kan du bruke
<literal>ServerName</literal>-direktivet i
<filename>httpd.conf</filename> for å få dette til.</para>
-
+
<screen>
ServerName svn.example.com
</screen>
-
+
<!-- @ENGLISH {{{
<para>If you are using Apache's virtual hosting support via
the <literal>NameVirtualHost</literal> directive, you may
@@ -2557,7 +2744,7 @@
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. (See <xref linkend="svn.serverconfig.svnserve.invoking.sb-1"/>.)</para>
+ repository.</para>
@ENGLISH }}} -->
<para>På dette steget bør du sterkt vurdere spørsmålet angående
rettigheter.
@@ -2569,10 +2756,8 @@
sagt, som gjør at Apache virker med disse filene.
Når Apache brukes som en Subversion&server; vil den også trenge
de riktige rettighetene for å lese og skrive til
- Subversiondepotet.
- (Se <xref
- linkend="svn.serverconfig.svnserve.invoking.sb-1"/>.)</para>
-
+ Subversiondepotet.</para>
+
<!-- @ENGLISH {{{
<para>You will need to determine a permission system setup that
satisfies Subversion's requirements without messing up any
@@ -3689,338 +3874,14 @@
</Location>
</programlisting>
</example>
-
- <!-- @ENGLISH {{{
- <para>Once your basic <literal>Location</literal> block is
- configured, you can create an access file and define some
- authorization rules in it.</para>
- @ENGLISH }}} -->
- <para>Når den grunnleggende <literal>Location</literal>-blokken
- er satt opp, kan du opprette en aksessfil og definere noen
- autorisasjonsregler i den.</para>
-
- <!-- @ENGLISH {{{
- <para>The syntax of the access file is the same familiar one
- used by <command>svnserve.conf</command> and the runtime
- configuration files. Lines that start with a hash
- (<literal>#</literal>) are ignored. In its simplest form,
- each section names a repository and path within it, and the
- authenticated usernames are the option names within each
- section. The value of each option describes the user's
- level of access to the repository path: either
- <literal>r</literal> (read-only) or <literal>rw</literal>
- (read-write). If the user is not mentioned at all, no
- access is allowed.</para>
- @ENGLISH }}} -->
- <para>Syntaksen til aksessfilnen er den samme kjente som brukes
- av <command>svnserve.conf</command> og konfigurasjonsfilene
- som brukes under kjøring.
- Linjer som starter med en hash (<literal>#</literal>)
- ignoreres.
- I sin enkleste form <!-- ¤ -->navngir hver seksjon et depot og
- en sti i det, og de autentiserte brukernavnene er <!-- ¤
- -->valgnavnene innenfor hver seksjon.
- Verdien til hvert valg beskriver brukerens adgangsnivå til
- depotstien:
- Enten <literal>r</literal> (kun lesing) eller
- <literal>rw</literal> (både skriving og lesing).
- Hvis brukeren ikke nevnes i det hele tatt, gis ingen tilgang i
- det hele tatt.</para>
-
- <!-- @ENGLISH {{{
- <para>To be more specific: the value of the section-names are
- either of the form <literal>[repos-name:path]</literal> or
- the form <literal>[path]</literal>. If you're using the
- <literal>SVNParentPath</literal> directive, then it's
- important to specify the repository names in your sections.
- If you omit them, then a section like
- <literal>[/some/dir]</literal> will match the path
- <filename>/some/dir</filename> in <emphasis>every</emphasis>
- repository. If you're using the <literal>SVNPath</literal>
- directive, however, then it's fine to only define paths in
- your sections—after all, there's only one
- repository.</para>
- @ENGLISH }}} -->
- <para>For å være mer spesifikk:
- Verdien til seksjonsnavnene er enten på formen
- <literal>[depotnavn:sti]</literal> eller på formen
- <literal>[sti]</literal>.
- Hvis du bruker <literal>SVNParentPath</literal>-direktivet, er
- det viktig å spesifisere depotnavnet i seksjonene dine.
- Hvis du utelater dem, vil en seksjon som
- <literal>[en/katalog]</literal> samsvare med stien
- <filename>en/katalog</filename> i <emphasis>hvert
- eneste</emphasis> depot.
- Hvis du bruker imidlertid bruker
- <literal>SVNPath</literal>-direktivet, er det greit å bare
- definere stier i seksjonene dine — når alt kommer til alt,
- finnes det bare ett depot.</para>
-
- <screen>
-[calc:/branches/calc/bug-142]
-harry = rw
-sally = r
-</screen>
-
- <!-- @ENGLISH {{{
- <para>In this first example, the user <literal>harry</literal> has
- full read and write access on the
- <filename>/branches/calc/bug-142</filename> directory in the
- <literal>calc</literal> repository, but the user
- <literal>sally</literal> has read-only access. Any other
- users are blocked from accessing this directory.</para>
- @ENGLISH }}} -->
- <para>I dette første eksempelet har brukeren
- <literal>harry</literal> full lese- og skrivetilgang i
- katalogen <filename>/branches/calc/big-142</filename> i
- <literal>calc</literal>-depotet, men brukeren
- <literal>sally</literal> har kun lesetilgang.
- Alle andre brukere nektes tilgang til depotet.</para>
-
- <!-- @ENGLISH {{{
- <para>Of course, permissions are inherited from
- parent to child directory. That means that we can specify a
- subdirectory with a different access policy for
- Sally:</para>
- @ENGLISH }}} -->
- <para>Alle tilganger arves selvfølgelig fra foreldrekataloger
- til underkataloger.
- Dette betyr at vi kan spesifisere en underkatalog med en
- forskjellig adgangsregel for Sally:</para>
- <!-- @ENGLISH {{{
- <screen>
-[calc:/branches/calc/bug-142]
-harry = rw
-sally = r
-
-# give sally write access only to the 'testing' subdir
-[calc:/branches/calc/bug-142/testing]
-sally = rw
-</screen>
- @ENGLISH }}} -->
- <screen>
-[calc:/branches/calc/bug-142]
-harry = rw
-sally = r
-
-# gi sally skrivetilgang kun til underkatalogen «testing»
-[calc:/branches/calc/bug-142/testing]
-sally = rw
-</screen>
-
- <!-- @ENGLISH {{{
- <para>Now Sally can write to the <filename>testing</filename>
- subdirectory of the branch, but can still only read other
- parts. Harry, meanwhile, continues to have complete
- read-write access to the whole branch.</para>
- @ENGLISH }}} -->
- <para>Nå kan Sally skrive til underkatalogen
- <filename>testing</filename> på grenen, men kan fortsatt bare
- lese andre deler.
- Imens fortsetter Harry å ha både lese- og skrivetilgang til
- hele grenen.</para>
-
- <!-- @ENGLISH {{{
- <para>It's also possible to explicitly deny permission to
- someone via inheritance rules, by setting the username
- variable to nothing:</para>
- @ENGLISH }}} -->
- <para>Det er også mulig å eksplisitt nekte <!-- ¤ -->adgang til
- noen ved hjelp av <!-- ¤ -->arveregler, ved å sette
- brukernavnvariabelen til ingenting:</para>
-
- <!-- @ENGLISH {{{
- <screen>
-[calc:/branches/calc/bug-142]
-harry = rw
-sally = r
-
-[calc:/branches/calc/bug-142/secret]
-harry =
-</screen>
- @ENGLISH }}} -->
- <screen>
-[calc:/branches/calc/bug-142]
-harry = rw
-sally = r
-
-[calc:/branches/calc/bug-142/hemmelig]
-harry =
-</screen>
-
- <!-- @ENGLISH {{{
- <para>In this example, Harry has read-write access to the
- entire <filename>bug-142</filename> tree, but has absolutely no
- access at all to the <filename>secret</filename>
- subdirectory within it.</para>
- @ENGLISH }}} -->
- <para>I dette eksempelet har Harry både lese- og skrivetilgang
- til hele <filename>bug-142</filename>-treet, men har absolutt
- ingen tilgang i det hele tatt til underkatalogen
- <filename>hemmelig</filename> innenfor det.</para>
-
- <!-- @ENGLISH {{{
- <para>The thing to remember is that the most specific path
- always matches first. The <command>mod_authz_svn</command>
- module tries to match the path itself, and then the parent
- of the path, then the parent of that, and so on. The net
- effect is that mentioning a specific path in the accessfile
- will always override any permissions inherited from parent
- directories.</para>
- @ENGLISH }}} -->
- <para>Tingen å huske på er at den mest spesifikke stien alltid
- samsvarer først.
- <command>mod_authz_svn</command>-modulen prøver selv å få
- stien til å stemme, deretter forelderen til stien, så
- forelderen til den, og så videre.
- Netteffekten er at det å nevne en spesifikk sti i aksessfila
- alltid vil overstyre alle rettigheter som er arvet fra
- foreldrekataloger.</para>
-
- <!-- @ENGLISH {{{
- <para>By default, nobody has any access to the repository at
- all. That means that if you're starting with an empty file,
- you'll probably want to give at least read permission to all
- users at the root of the repository. You can do this by
- using the asterisk variable (<literal>*</literal>), which
- means <quote>all users</quote>:</para>
- @ENGLISH }}} -->
- <para>Som standard har ingen noen tilgang til depotet i det hele
- tatt.
- Det betyr at hvis du starter med en tom fil, vil du
- sannsynligvis ønske å i det minste gi leserettigheter til alle
- brukere ved roten av depotet.
- Du kan gjøre dette ved å bruke asteriskvariabelen
- (<literal>*</literal>), som betyr <quote>alle
- brukere</quote>:</para>
-
- <screen>
-[/]
-* = r
-</screen>
-
- <!-- @ENGLISH {{{
- <para>This is a common setup; notice that there's no
- repository name mentioned in the section name. This makes
- all repositories world readable to all users, whether you're
- using <literal>SVNPath</literal> or
- <literal>SVNParentPath</literal>. Once all users have
- read-access to the repositories, you can give explicit
- <literal>rw</literal> permission to certain users on specific
- subdirectories within specific repositories.</para>
- @ENGLISH }}} -->
- <para>Dette er et vanlig oppsett; legg merke til at det ikke
- nevnes noen depotnavn i seksjonsnavnet.
- Dette gjør alle depotene fullstendig lesbare for alle
- brukerne, enten du bruker <literal>SVNPath</literal> eller
- <literal>SVNParentPath</literal>
- Når alle brukerne har lesetilgang til depotene, kan du gi
- eksplisitt <literal>rw</literal>-rettigheter til visse brukere
- i spesifikke underkataloger inne i spesifikke depoter.</para>
-
- <!-- @ENGLISH {{{
- <para>The asterisk variable (<literal>*</literal>) is also
- worth special mention here: it's the
- <emphasis>only</emphasis> pattern which matches an anonymous
- user. If you've configured your <literal>Location</literal>
- block to allow a mixture of anonymous and authenticated
- access, all users start out accessing Apache anonymously.
- <command>mod_authz_svn</command> looks for a
- <literal>*</literal> value defined for the path being
- accessed; if it can't find one, then Apache demands real
- authentication from the client.</para>
- @ENGLISH }}} -->
- <para>Asteriskvariabelen (<literal>*</literal>) er også verdt
- litt spesiell omtale her:
- Det er det <emphasis>eneste</emphasis> mønsteret som samsvarer
- med en anonym bruker.
- Hvis du har satt opp <literal>Location</literal>-blokken din
- til å tillate en blanding av anonym og autentisert tilgang,
- starter alle brukere med å aksessere Apache anonymt.
- <command>mod_authz_svn</command> ser etter en
- <literal>*</literal>-verdi for stien som blir aksessert; hvis
- den ikke finner noen, forlanger Apache skikkelig autentisering
- fra klienten.</para>
-
- <!-- @ENGLISH {{{
- <para>The access file also allows you to define whole groups
- of users, much like the Unix <filename>/etc/group</filename>
- file:</para>
- @ENGLISH }}} -->
- <para>Aksessfila lar deg også definere hele grupper med brukere,
- ganske likt <filename>/etc/group</filename> på
- Unix-systemer:</para>
-
- <!-- @ENGLISH {{{
- <screen>
-[groups]
-calc-developers = harry, sally, joe
-paint-developers = frank, sally, jane
-everyone = harry, sally, joe, frank, sally, jane
-</screen>
- @ENGLISH }}} -->
- <screen>
-[groups]
-calc-utviklere = harry, sally, joe
-paint-utviklere = frank, sally, jane
-alle = harry, sally, joe, frank, sally, jane
-</screen>
-
- <!-- @ENGLISH {{{
- <para>Groups can be granted access control just like users.
- Distinguish them with an <quote>at</quote> (<literal>@</literal>)
- prefix:</para>
- @ENGLISH }}} -->
- <para>Grupper kan bli gitt tilgang akkurat som brukere.
- Skill mellom dem ved å sette en krøllalfa
- (<literal>@</literal>) foran gruppenavnet:</para>
-
- <!-- @ENGLISH {{{
- <screen>
-[calc:/projects/calc]
- at calc-developers = rw
-
-[paint:/projects/paint]
- at paint-developers = rw
-jane = r
-</screen>
- @ENGLISH }}} -->
- <screen>
-[calc:/prosjekter/calc]
- at calc-utviklere = rw
-
-[paint:/prosjekter/paint]
- at paint-utviklere = rw
-jane = r
-</screen>
-
- <!-- @ENGLISH {{{
- <para>Groups can also be defined to contain other
- groups:</para>
- @ENGLISH }}} -->
- <para>Grupper kan også bli definert til å inneholde andre
- grupper:</para>
-
- <!-- @ENGLISH {{{
- <screen>
-[groups]
-calc-developers = harry, sally, joe
-paint-developers = frank, sally, jane
-everyone = @calc-developers, @paint-developers
-</screen>
- @ENGLISH }}} -->
- <screen>
-[groups]
-calc-utviklere = harry, sally, joe
-paint-utviklere = frank, sally, jane
-alle = @calc-utviklere, @paint-utviklere
-</screen>
-
- <!-- @ENGLISH {{{
- <para>…and that's pretty much all there is to it.</para>
- @ENGLISH }}} -->
- <para>…og det er omtrent det som er å si om den saken.</para>
+<!-- @TR {{ -->
+ <para>Once you've settled on one of these three
+ basic <filename>httpd.conf</filename> templates, you need to
+ create your file containing access rules for particular
+ paths within the repository. This is described in
+ <xref linkend="svn.serverconfig.pathbasedauthz"/>.</para>
+<!-- @TR }} -->
</sect3>
@@ -4475,6 +4336,7 @@
<quote>share</quote> (delt ressurs eller disk).
Dette er et kompliser tema; for detaljer, les <xref
linkend="svn.webdav"/>.</para>
+<!-- @CHK }} -->
</sect3>
@@ -4483,12 +4345,422 @@
</sect1>
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <sect1 id="svn.serverconfig.pathbasedauthz">
+
+<!-- @TR {{ -->
+ <title>Path-Based Authorization</title>
+
+ <para>Both Apache and <command>svnserve</command> are capable of
+ granting (or denying) permissions to users. Typically this is
+ done over the entire repository: a user can read the repository
+ (or not), and she can write to the repository (or not). It's
+ also possible, however, to define finer-grained access rules.
+ One set of users may have permssion to write to a certain
+ directory in the repository, but not others; another directory
+ might not even be readable by all but a few special
+ people.</para>
+
+ <para>Both servers use a common file format to describe these
+ path-based access rules. In the case of Apache, one needs to
+ load the <command>mod_authz_svn</command> module and then add
+ the <literal>AuthzSVNAccessFile</literal> directive (within
+ the <filename>httpd.conf</filename> file) pointing to your own
+ rules-file. (For a full explanation, see
+ <xref linkend="svn.serverconfig.httpd.authz.perdir"/>.) If
+ you're using <command>svnserve</command>, then you need to make
+ the <literal>authz-db</literal> variable
+ (within <filename>svnserve.conf</filename>) point to your
+ rules-file.</para>
+
+ <sidebar>
+ <title>Best practice: do you really need path-based access
+ control?</title>
+
+ <para>A lot of administrators setting up Subversion for the
+ first time tend to jump into path-based access control without
+ giving it a lot of thought. The administrator usually knows
+ which teams of people are working on which projects, so it's
+ easy to jump in and grant certain teams access to certain
+ directories and not others. It seems like a natural thing,
+ and it appeases the administrator's desire to maintain tight
+ control of the repository.</para>
+
+ <para>Note, though, that there are often invisible costs
+ associated with this feature. Most of the time, while certain
+ users <emphasis>shouldn't</emphasis> be committing changes to
+ certain parts of the repository, that social contract doesn't
+ need to be technologically enforced. Teams can sometimes
+ spontaneously collaborate with each other; someone may want to
+ help someone else out by committing to an area she doesn't
+ normally work on. By preventing this sort of thing at the
+ server level, you're setting up barriers to unexpected
+ collaboration. You're also creating a bunch of rules that
+ need to be maintained as projects develop, new users are
+ added, and so on. It's a bunch of extra work to maintain.</para>
+
+ <para>Remember that this is a version control system! Even if
+ somebody accidentally commits a change to something they
+ shouldn't, it's easy to undo the change. And if a user
+ commits to the wrong place with deliberate malice, then it's a
+ social problem anyway, and that the problem needs to be dealt
+ with outside of Subversion.</para>
+
+ <para>So before you begin restricting users' access rights, ask
+ yourself if there's a real, honest need for this, or if it's
+ just something that <quote>sounds good</quote> to an
+ administrator. Remember that there's very little risk
+ involved, and that it's bad to become dependent on technology
+ as a crutch for social problems.<footnote><para>A common theme
+ in this book!</para></footnote>.</para>
+
+ <para>As an example to ponder, consider that the Subversion
+ project itself has always a notion of who is allowed to commit
+ where, but it's always been enforced socially. This is a good
+ model of community trust, especially for open-source projects.
+ Of course, sometimes there <emphasis>are</emphasis> truly
+ legitimate needs for path-based access control; within
+ corporations, for example, certain types of data really can be
+ sensitive, and access needs to be genuinely restricted to
+ small groups of people.</para>
+
+ </sidebar>
+
+ <para>Once your server knows where to find your rules-file, it's
+ time to define the rules.</para>
+<!-- @TR }} -->
+
+ <!-- @ENGLISH {{{
+ <para>The syntax of the file is the same familiar one used
+ by <command>svnserve.conf</command> and the runtime
+ configuration files. Lines that start with a hash
+ (<literal>#</literal>) are ignored. In its simplest form, each
+ section names a repository and path within it, and the
+ authenticated usernames are the option names within each
+ section. The value of each option describes the user's level of
+ access to the repository path: either
+ <literal>r</literal> (read-only) or <literal>rw</literal>
+ (read-write). If the user is not mentioned at all, no access is
+ allowed.</para>
+ @ENGLISH }}} -->
+ <para>Syntaksen til fila er den samme kjente som brukes
+ av <command>svnserve.conf</command> og konfigurasjonsfilene
+ som brukes under kjøring.
+ Linjer som starter med en hash (<literal>#</literal>)
+ ignoreres.
+ I sin enkleste form <!-- ¤ -->navngir hver seksjon et depot og
+ en sti i det, og de autentiserte brukernavnene er <!-- ¤
+ -->valgnavnene innenfor hver seksjon.
+ Verdien til hvert valg beskriver brukerens adgangsnivå til
+ depotstien:
+ Enten <literal>r</literal> (kun lesing) eller
+ <literal>rw</literal> (både skriving og lesing).
+ Hvis brukeren ikke nevnes i det hele tatt, gis ingen tilgang i
+ det hele tatt.</para>
+
+ <!-- @ENGLISH {{{
+ <para>To be more specific: the value of the section-names are
+ either of the form <literal>[repos-name:path]</literal> or the
+ form <literal>[path]</literal>. If you're using the
+ <literal>SVNParentPath</literal> directive, then it's important
+ to specify the repository names in your sections. If you omit
+ them, then a section like
+ <literal>[/some/dir]</literal> will match the path
+ <filename>/some/dir</filename> in <emphasis>every</emphasis>
+ repository. If you're using the <literal>SVNPath</literal>
+ directive, however, then it's fine to only define paths in your
+ sections—after all, there's only one repository.</para>
+ @ENGLISH }}} -->
+ <para>For å være mer spesifikk:
+ Verdien til seksjonsnavnene er enten på formen
+ <literal>[depotnavn:sti]</literal> eller på formen
+ <literal>[sti]</literal>.
+ Hvis du bruker <literal>SVNParentPath</literal>-direktivet, er det
+ viktig å spesifisere depotnavnet i seksjonene dine.
+ Hvis du utelater dem, vil en seksjon som
+ <literal>[en/katalog]</literal> samsvare med stien
+ <filename>en/katalog</filename> i <emphasis>hvert
+ eneste</emphasis> depot.
+ Hvis du bruker imidlertid bruker
+ <literal>SVNPath</literal>-direktivet, er det greit å bare
+ definere stier i seksjonene dine — når alt kommer til alt, finnes
+ det bare ett depot.</para>
+
+ <screen>
+[calc:/branches/calc/bug-142]
+harry = rw
+sally = r
+</screen>
+
+ <!-- @ENGLISH {{{
+ <para>In this first example, the user <literal>harry</literal> has
+ full read and write access on the
+ <filename>/branches/calc/bug-142</filename> directory in the
+ <literal>calc</literal> repository, but the user
+ <literal>sally</literal> has read-only access. Any other users
+ are blocked from accessing this directory.</para>
+ @ENGLISH }}} -->
+ <para>I dette første eksempelet har brukeren
+ <literal>harry</literal> full lese- og skrivetilgang i katalogen
+ <filename>/branches/calc/big-142</filename> i
+ <literal>calc</literal>-depotet, men brukeren
+ <literal>sally</literal> har kun lesetilgang.
+ Alle andre brukere nektes tilgang til depotet.</para>
+
+ <!-- @ENGLISH {{{
+ <para>Of course, permissions are inherited from parent to child
+ directory. That means that we can specify a subdirectory with a
+ different access policy for Sally:</para>
+ @ENGLISH }}} -->
+ <para>Alle tilganger arves selvfølgelig fra foreldrekataloger til
+ underkataloger.
+ Dette betyr at vi kan spesifisere en underkatalog med en
+ forskjellig adgangsregel for Sally:</para>
+
+ <!-- @ENGLISH {{{
+ <screen>
+[calc:/branches/calc/bug-142]
+harry = rw
+sally = r
+
+# give sally write access only to the 'testing' subdir
+[calc:/branches/calc/bug-142/testing]
+sally = rw
+</screen>
+ @ENGLISH }}} -->
+ <screen>
+[calc:/branches/calc/bug-142]
+harry = rw
+sally = r
+
+# gi sally skrivetilgang kun til underkatalogen «testing»
+[calc:/branches/calc/bug-142/testing]
+sally = rw
+</screen>
+
+ <!-- @ENGLISH {{{
+ <para>Now Sally can write to the <filename>testing</filename>
+ subdirectory of the branch, but can still only read other parts.
+ Harry, meanwhile, continues to have complete read-write access
+ to the whole branch.</para>
+ @ENGLISH }}} -->
+ <para>Nå kan Sally skrive til underkatalogen
+ <filename>testing</filename> på grenen, men kan fortsatt bare lese
+ andre deler.
+ Imens fortsetter Harry å ha både lese- og skrivetilgang til hele
+ grenen.</para>
+
+ <!-- @ENGLISH {{{
+ <para>It's also possible to explicitly deny permission to someone
+ via inheritance rules, by setting the username variable to
+ nothing:</para>
+ @ENGLISH }}} -->
+ <para>Det er også mulig å eksplisitt nekte <!-- ¤ -->adgang til noen
+ ved hjelp av <!-- ¤ -->arveregler, ved å sette
+ brukernavnvariabelen til ingenting:</para>
+
+ <!-- @ENGLISH {{{
+ <screen>
+[calc:/branches/calc/bug-142]
+harry = rw
+sally = r
+
+[calc:/branches/calc/bug-142/secret]
+harry =
+</screen>
+ @ENGLISH }}} -->
+ <screen>
+[calc:/branches/calc/bug-142]
+harry = rw
+sally = r
+
+[calc:/branches/calc/bug-142/hemmelig]
+harry =
+</screen>
+
+ <!-- @ENGLISH {{{
+ <para>In this example, Harry has read-write access to the
+ entire <filename>bug-142</filename> tree, but has absolutely no
+ access at all to the <filename>secret</filename> subdirectory
+ within it.</para>
+ @ENGLISH }}} -->
+ <para>I dette eksempelet har Harry både lese- og skrivetilgang til
+ hele <filename>bug-142</filename>-treet, men har absolutt ingen
+ tilgang i det hele tatt til underkatalogen
+ <filename>hemmelig</filename> innenfor det.</para>
+
+ <!-- @ENGLISH {{{
+ <para>The thing to remember is that the most specific path always
+ matches first. The <command>mod_authz_svn</command> module
+ tries to match the path itself, and then the parent of the path,
+ then the parent of that, and so on. The net effect is that
+ mentioning a specific path in the accessfile will always
+ override any permissions inherited from parent
+ directories.</para>
+ @ENGLISH }}} -->
+ <para>Tingen å huske på er at den mest spesifikke stien alltid
+ samsvarer først.
+ <command>mod_authz_svn</command>-modulen prøver selv å få stien
+ til å stemme, deretter forelderen til stien, så forelderen til
+ den, og så videre.
+ Netteffekten er at det å nevne en spesifikk sti i aksessfila
+ alltid vil overstyre alle rettigheter som er arvet fra
+ foreldrekataloger.</para>
+
+ <!-- @ENGLISH {{{
+ <para>By default, nobody has any access to the repository at all.
+ That means that if you're starting with an empty file, you'll
+ probably want to give at least read permission to all users at
+ the root of the repository. You can do this by using the
+ asterisk variable (<literal>*</literal>), which means <quote>all
+ users</quote>:</para>
+ @ENGLISH }}} -->
+ <para>Som standard har ingen noen tilgang til depotet i det hele
+ tatt.
+ Det betyr at hvis du starter med en tom fil, vil du sannsynligvis
+ ønske å i det minste gi leserettigheter til alle brukere ved roten
+ av depotet.
+ Du kan gjøre dette ved å bruke asteriskvariabelen
+ (<literal>*</literal>), som betyr <quote>alle
+ brukere</quote>:</para>
+
+ <screen>
+[/]
+* = r
+</screen>
+
+ <!-- @ENGLISH {{{
+ <para>This is a common setup; notice that there's no repository
+ name mentioned in the section name. This makes all repositories
+ world readable to all users, whether you're
+ using <literal>SVNPath</literal> or
+ <literal>SVNParentPath</literal>. Once all users have
+ read-access to the repositories, you can give explicit
+ <literal>rw</literal> permission to certain users on specific
+ subdirectories within specific repositories.</para>
+ @ENGLISH }}} -->
+ <para>Dette er et vanlig oppsett; legg merke til at det ikke nevnes
+ noen depotnavn i seksjonsnavnet.
+ Dette gjør alle depotene fullstendig lesbare for alle brukerne,
+ enten du bruker <literal>SVNPath</literal> eller
+ <literal>SVNParentPath</literal>
+ Når alle brukerne har lesetilgang til depotene, kan du gi
+ eksplisitt <literal>rw</literal>-rettigheter til visse brukere i
+ spesifikke underkataloger inne i spesifikke depoter.</para>
+
+ <!-- @ENGLISH {{{
+ <para>The asterisk variable (<literal>*</literal>) is also worth
+ special mention here: it's the
+ <emphasis>only</emphasis> pattern which matches an anonymous
+ user. If you've configured your <literal>Location</literal>
+ block to allow a mixture of anonymous and authenticated access,
+ all users start out accessing Apache anonymously.
+ <command>mod_authz_svn</command> looks for a
+ <literal>*</literal> value defined for the path being accessed;
+ if it can't find one, then Apache demands real authentication
+ from the client.</para>
+ @ENGLISH }}} -->
+ <para>Asteriskvariabelen (<literal>*</literal>) er også verdt litt
+ spesiell omtale her:
+ Det er det <emphasis>eneste</emphasis> mønsteret som samsvarer med
+ en anonym bruker.
+ Hvis du har satt opp <literal>Location</literal>-blokken din til å
+ tillate en blanding av anonym og autentisert tilgang, starter alle
+ brukere med å aksessere Apache anonymt.
+ <command>mod_authz_svn</command> ser etter en
+ <literal>*</literal>-verdi for stien som blir aksessert; hvis den
+ ikke finner noen, forlanger Apache skikkelig autentisering fra
+ klienten.</para>
+
+ <!-- @ENGLISH {{{
+ <para>The access file also allows you to define whole groups of
+ users, much like the Unix <filename>/etc/group</filename>
+ file:</para>
+ @ENGLISH }}} -->
+ <para>Aksessfila lar deg også definere hele grupper med brukere,
+ ganske likt <filename>/etc/group</filename> på
+ Unix-systemer:</para>
+
+ <!-- @ENGLISH {{{
+ <screen>
+[groups]
+calc-developers = harry, sally, joe
+paint-developers = frank, sally, jane
+everyone = harry, sally, joe, frank, sally, jane
+</screen>
+ @ENGLISH }}} -->
+ <screen>
+[groups]
+calc-utviklere = harry, sally, joe
+paint-utviklere = frank, sally, jane
+alle = harry, sally, joe, frank, sally, jane
+</screen>
+
+ <!-- @ENGLISH {{{
+ <para>Groups can be granted access control just like users.
+ Distinguish them with an <quote>at</quote>
+ (<literal>@</literal>) prefix:</para>
+ @ENGLISH }}} -->
+ <para>Grupper kan bli gitt tilgang akkurat som brukere.
+ Skill mellom dem ved å sette en krøllalfa (<literal>@</literal>)
+ foran gruppenavnet:</para>
+
+ <!-- @ENGLISH {{{
+ <screen>
+[calc:/projects/calc]
+ at calc-developers = rw
+
+[paint:/projects/paint]
+ at paint-developers = rw
+jane = r
+</screen>
+ @ENGLISH }}} -->
+ <screen>
+[calc:/prosjekter/calc]
+ at calc-utviklere = rw
+
+[paint:/prosjekter/paint]
+ at paint-utviklere = rw
+jane = r
+</screen>
+
+ <!-- @ENGLISH {{{
+ <para>Groups can also be defined to contain other groups:</para>
+ @ENGLISH }}} -->
+ <para>Grupper kan også bli definert til å inneholde andre
+ grupper:</para>
+
+ <!-- @ENGLISH {{{
+ <screen>
+[groups]
+calc-developers = harry, sally, joe
+paint-developers = frank, sally, jane
+everyone = @calc-developers, @paint-developers
+</screen>
+ @ENGLISH }}} -->
+ <screen>
+[groups]
+calc-utviklere = harry, sally, joe
+paint-utviklere = frank, sally, jane
+alle = @calc-utviklere, @paint-utviklere
+</screen>
+
+ <!-- @ENGLISH {{{
+ <para>…and that's pretty much all there is to it.</para>
+ @ENGLISH }}} -->
+ <para>…og det er omtrent det som er å si om den saken.</para>
+
+ </sect1>
+
<!-- ================================================================= -->
<!-- ================================================================= -->
<!-- ================================================================= -->
<sect1 id="svn.serverconfig.multimethod">
+<!-- @CHK {{ -->
<!-- @ENGLISH {{{
<title>Supporting Multiple Repository Access Methods</title>
@ENGLISH }}} -->
More information about the svnbook-dev
mailing list