[svnbook] r4460 committed - Rest of ticket #322 (cf. http://www.svnbook.de/ticket/322).

svnbook at googlecode.com svnbook at googlecode.com
Sat Apr 6 11:05:59 CDT 2013


Revision: 4460
Author:   jmfelderhoff at gmx.eu
Date:     Sat Apr  6 09:05:38 2013
Log:      Rest of ticket #322 (cf. http://www.svnbook.de/ticket/322).

http://code.google.com/p/svnbook/source/detail?r=4460

Modified:
  /branches/1.5/de/book/ch06-server-configuration.xml

=======================================
--- /branches/1.5/de/book/ch06-server-configuration.xml	Wed Feb 20 12:27:54  
2013
+++ /branches/1.5/de/book/ch06-server-configuration.xml	Sat Apr  6 09:05:38  
2013
@@ -6020,9 +6020,15 @@

      </sidebar>

+<!--
      <para>Once your server knows where to find your rules file, it's
        time to define the rules.</para>

+-->
+    <para>Sobald Ihr Server weiß, wo sich Ihre Regeldateien befinden,
+      ist es an der Zeit, die Regeln zu definieren.</para>
+
+<!--
      <para>The syntax of the file is the same familiar one used
        by <filename>svnserve.conf</filename> and the runtime
        configuration files.  Lines that start with a hash
@@ -6035,6 +6041,20 @@
        (read/write).  If the user is not mentioned at all, no access is
        allowed.</para>

+-->
+    <para>Die Syntax der Datei ist dieselbe wie bei
+      <filename>svnserve.conf</filename> und den
+      Laufzeit-Konfigurationsdateien. Zeilen, die mit einer
+      Raute (<literal>#</literal>) beginnen, werden ignoriert. In der
+      einfachsten Form benennt jeder Abschnitt ein Projektarchiv und
+      einen Pfad darin. Die authentifizierten Anwendernamen sind die
+      Optionen und der entsprechende Wert beschreibt das Zugriffsrecht
+      des Anwenders auf den Pfad im Projektarchiv, entweder
+      <literal>r</literal> (nur lesend) oder <literal>rw</literal>
+      (lesend und schreibend). Wird der Anwender gar nicht erwähnt,
+      ist kein Zugriff erlaubt.</para>
+
+<!--
      <para>To be more specific: the value of the section names is
        either of the form <literal>[repos-name:path]</literal> or of the
        form <literal>[path]</literal>.  If you're using the
@@ -6047,12 +6067,27 @@
        directive, however, it's fine to only define paths in your
        sections—after all, there's only one repository.</para>

+-->
+    <para>Genauer gesagt: Der Wert des Abschnittsnamens hat entweder
+      das Format <literal>[projektarchiv-name:pfad]</literal> oder
+      <literal>[pfad]</literal>. Falls Sie die Direktive
+      <literal>SVNParentPath</literal> verwenden, ist es wichtig, die
+      Namen der Projektarchive in den Abschnitten anzugeben. Falls Sie
+      sie weglassen, wird ein Abschnitt wie etwa
+      <literal>[/some/dir]</literal> auf den Pfad
+      <filename>/some/dir</filename> <emphasis>jedes</emphasis>
+      Projektarchivs zutreffen. Falls Sie jedoch die Direktive
+      <literal>SVNPath</literal> verwenden, ist es in Ordnung, in den
+      Abschnitten nur Pfade zu definieren, da es ja schließlich nur
+      ein einziges Projektarchiv gibt.</para>
+
      <screen>
  [calc:/branches/calc/bug-142]
  harry = rw
  sally = r
  </screen>

+<!--
      <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
@@ -6060,10 +6095,26 @@
        <literal>sally</literal> has read-only access.  Any other users
        are blocked from accessing this directory.</para>

+-->
+    <para>Im ersten Beispiel hat der Anwender <literal>harry</literal>
+      vollständigen Lese- und Schreibzugriff auf das Verzeichnis
+      <filename>/branches/calc/bug-142</filename> im Projektarchiv
+      <literal>calc</literal>, die Anwenderin <literal>sally</literal>
+      hat jedoch nur Lesezugriff. Allen anderen Anwendern ist der
+      Zugriff auf dieses Verzeichnis nicht gestattet.</para>
+
+<!--
      <para>Of course, permissions are inherited from parent to child
        directory.  That means we can specify a subdirectory with a
        different access policy for Sally:</para>

+-->
+    <para>Selbstverständlich werden Berechtigungen von den Eltern- auf
+      die Kindverzeichnisse vererbt. Das bedeutet, dass wir ein
+      Unterverzeichnis mit unterschiedlichen Berechtigungen für Sally
+      angeben können:</para>
+
+<!--
      <screen>
  [calc:/branches/calc/bug-142]
  harry = rw
@@ -6073,16 +6124,42 @@
  [calc:/branches/calc/bug-142/testing]
  sally = rw
  </screen>
+-->

+    <screen>
+[calc:/branches/calc/bug-142]
+harry = rw
+sally = r
+
+# Sally bekommt nur für das Unterverzeichnis 'testing' Schreibrecht
+[calc:/branches/calc/bug-142/testing]
+sally = rw
+</screen>
+
+<!--
      <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>

+-->
+    <para>Nun kann Sally im Verzeichnis <filename>testing</filename>
+      des Zweigs zwar schreiben, an anderen Stellen allerdings immer
+      noch nur lesen.  Andererseits besitzt Harry weiterhin
+      vollständigen Lese- und Schreibzugriff auf den gesamten
+      Zweig.</para>
+
+<!--
      <para>It's also possible to explicitly deny permission to someone
        via inheritance rules, by setting the username variable to
        nothing:</para>

+-->
+    <para>Es ist ebenfalls möglich, einer Person über die
+      Vererbungsregeln explizit Berechtigungen zu entziehen, indem die
+      Variable mit dem Anwendernamen auf den leeren Wert gesetzt
+      wird:</para>
+
      <screen>
  [calc:/branches/calc/bug-142]
  harry = rw
@@ -6092,20 +6169,34 @@
  harry =
  </screen>

+<!--
      <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>

+-->
+    <para>In diesem Beispiel hat Harry Lese- und Schreibzugriff auf
+      den gesamten Baum <filename>bug-142</filename>, jedoch überhaupt  
keinen Zugriff auf das darin befindliche Unterverzeichnis  
<filename>secret</filename>.</para>
+
      <tip>
+<!--
        <para>The thing to remember is that the most specific path
          always matches first.  The server 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 access file will always override any permissions
-        inherited from parent directories.</para>
+-->
+      <para>Man muss sich nur merken, dass der am genauesten
+        angegebene Pfad stets am besten passt. Der Server versucht
+        zunächst, den Pfad selbst abzugleichen, dann das
+        Elternverzeichnis hiervon, dann dessen Elternverzeichnis usw.
+        Unter dem Strich läuft es darauf hinaus, dass die Erwähnung
+        eines bestimmten Pfades in der Zugriffsdatei stets die von
+        Elternverzeichnissen ererbten Berechtigungen überdeckt.</para>
      </tip>

+<!--
      <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
@@ -6113,11 +6204,21 @@
        asterisk variable (<literal>*</literal>), which means <quote>all
        users</quote>:</para>

+-->
+    <para>Standardmäßig hat niemand irgendeine Zugriffsberechtigung
+      auf das Projektarchiv. Das bedeutet, wenn mit einer leeren Datei
+      begonnen wird, sollte mindestens für alle Anwender die
+      Leseberechtigung für die Wurzel des Projektarchivs gewährt
+      werden. Das kann mit der Stern-Variablen (<literal>*</literal>)
+      erreicht werden, die für <quote>alle Anwender</quote>
+      steht:</para>
+
      <screen>
  [/]
  * = r
  </screen>

+<!--
      <para>This is a common setup; notice that no repository
        name is mentioned in the section name.  This makes all repositories
        world-readable to all users. Once all users have read access to
@@ -6125,6 +6226,16 @@
        <literal>rw</literal> permission to certain users on specific
        subdirectories within specific repositories.</para>

+-->
+    <para>Dies ist eine verbreitete Einstellung. Beachten Sie, dass im
+      Abschnittsnamen kein Projektarchiv erwähnt wird. Das führt dazu,
+      dass alle Projektarchive fųr alle Anwender der Welt lesbar sind.
+      Sobald alle Anwender Lesezugriff auf die Projektarchive haben,
+      können Sie bestimmten Anwendern fUr ausgewählte Verzeichnisse
+      bestimmter Projektarchive die Berechtigung <literal>rw</literal>
+      geben.</para>
+
+<!--
      <para>The asterisk variable (<literal>*</literal>) is also worth
        special mention because it's the
        <emphasis>only</emphasis> pattern that matches an anonymous
@@ -6135,10 +6246,27 @@
        if it can't find one, it demands real authentication from
        the client.</para>

+-->
+    <para>Die Stern-Variable (<literal>*</literal>) verdient ebenso
+      besondere Erwähnung, da sie das <emphasis>einzige</emphasis>
+      Muster ist, das auf einen anonymen Anwender passt. Falls Sie
+      Ihren Server-Block für einen gemischten anonymen und
+      authentifizierten Zugriff konfiguriert haben, beginnen alle
+      Anwender mit anonymen Zugriff. Der Server sucht nach einem
+      für den Zugriffspfad definierten <literal>*</literal>-Wert; kann
+      er keinen finden, verlangt er echte Authentifizierung vom
+      Client.</para>
+
+<!--
      <para>The access file also allows you to define whole groups of
        users, much like the Unix <filename>/etc/group</filename>
        file:</para>

+-->
+    <para>Die Zugriffsdatei erlaubt es Ihnen auch, ganze
+      Anwendergruppen zu definieren, ähnlich der Unix-Datei
+      <filename>/etc/group</filename>:</para>
+
      <screen>
  [groups]
  calc-developers = harry, sally, joe
@@ -6146,10 +6274,17 @@
  everyone = harry, sally, joe, frank, sally, jane
  </screen>

+<!--
      <para>Groups can be granted access control just like users.
        Distinguish them with an <quote>at</quote>
        (<literal>@</literal>) prefix:</para>

+-->
+    <para>Gruppen können ebenso wie Anwendern Zugriffsberechtigungen
+      erteilt werden. Sie werden von Anwendern durch einen
+      <quote>At</quote>-Präfix (<literal>@</literal>)
+      unterschieden:</para>
+
      <screen>
  [calc:/projects/calc]
  @calc-developers = rw
@@ -6159,6 +6294,7 @@
  @paint-developers = rw
  </screen>

+<!--
      <para>Another important fact is that
      the <emphasis>first</emphasis> matching rule is the one which gets
      applied to a user.  In the prior example, even though Jane is a
@@ -6167,8 +6303,22 @@
      discovered and matched before the group rule, thus denying Jane
      write access.</para>

+-->
+    <para>Ein weiterer wichtiger Punkt ist, dass die
+      <emphasis>erste</emphasis> passende Regel diejenige ist, die für
+      einen Anwender gilt. Im vorhergehenden Beispiel trifft die Regel
+      <literal>jane = r</literal> vor der Gruppenregel zu; obwohl Jane
+      Mitglied der Gruppe <literal>paint-developers</literal> ist (die
+      uber Lese- und Schreibzugriff verfügt), bleibt Jane somit der
+      Schreibzugriff verwehrt.</para>
+
+<!--
      <para>Groups can also be defined to contain other groups:</para>

+-->
+    <para>Gruppen können auch definiert werden, indem sie andere
+      Gruppen beinhalten:</para>
+
      <screen>
  [groups]
  calc-developers = harry, sally, joe
@@ -6176,6 +6326,7 @@
  everyone = @calc-developers, @paint-developers
  </screen>

+<!--
      <para>Subversion 1.5 brings another useful feature to the access
        file syntax:  username aliases.  Some authentication systems
        expect and carry relatively short usernames of the sorts we've
@@ -6192,6 +6343,25 @@
        correct complex username only once, in a statement which assigns to
        it a more easily digestable alias.</para>

+-->
+    <para>Subversion 1.5 führt eine nützliche Erweiterung in die
+      Syntax der Zugriffsdatei ein: Anwendernamen-Aliase. Einige
+      Authentifizierungssysteme erwarten und verwenden relativ kurze
+      Anwendernamen, wie wir sie hier bereits beschrieben haben:
+      <literal>harry</literal>, <literal>sally</literal>,
+      <literal>joe</literal> usw. Andere Authentifizierungssysteme
+      jedoch, wie solche, die LDAP oder SSL-Client-Zertifikate
+      verwenden, könnten wesentlich komplexere Anwendernamen
+      verwenden. So könnte beispielsweise Harrys Anwendername in einem
+      durch LDAP geschützten System <literal>CN=Harold
+        Hacker,OU=Engineers,DC=red-bean,DC=com</literal> lauten. Mit
+      derartigen Anwendernamen könnte die Zugriffsdatei mit langen
+      oder undurchsichtigen Anwendernamen zugemüllt werden, was auch
+      leicht zu Tippfehlern führen kann. Glücklicherweise ermöglichen
+      es Anwendernamen-Aliase, den komplizierten Anwendernamen nur
+      einmal in einer Anweisung einzutippen, die ihm ein einfacheres
+      Alias zuteilt.</para>
+
      <screen>
  [aliases]
  harry = CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com
@@ -6200,12 +6370,21 @@
  …
  </screen>

+<!--
      <para>Once you've defined a set of aliases, you can refer to the
        users elsewhere in the access file via their aliases in all the
        same places you could have instead used their actual usernames.
        Simply prepend an ampersand to the alias to distinguish it from
        a regular username:</para>

+-->
+    <para>Sobald Sie eine Menge an Aliasen definiert haben, können Sie
+      sich an allen Stellen der Zugriffsdatei über die Aliase auf die
+      Anwender beziehen, an denen Sie sonst die eigentlichen
+      Anwendernamen benutzt hätten. Setzen Sie einfach ein
+      kaufmännisches Und vor den Alias, um ihn von einem normalen
+      Anwendernamen zu unterscheiden:</para>
+
      <screen>
  [groups]
  calc-developers = &harry, &sally, &joe
@@ -6213,23 +6392,44 @@
  everyone = @calc-developers, @paint-developers
  </screen>

+<!--
      <para>You might also choose to use aliases if your users'
        usernames change frequently.  Doing so allows you to need to
        update only the aliases table when these username changes occur,
        instead of doing global-search-and-replace operations on the
        whole access file.</para>

+-->
+    <para>Sie könnten sich auch dazu entscheiden, Aliase zu verwenden,
+      falls sich die Anwendernamen Ihrer Anwender häufig ändern. In
+      diesem Fall müssen Sie bei Änderungen der Anwendernamen
+      lediglich die Aliastabelle aktualisieren anstatt eine globale
+      Such- und Ersetzungsoperation über die gesamte Zugriffsdatei
+      vornehmen zu müssen.</para>
+
    <!-- TODO(sussman): Once serf becomes officially support, this
         sidebar will need to be revisited. -->

    <sidebar>
+<!--
      <title>Partial Readability and Checkouts</title>
+-->
+    <title>Teilweise Lesbarkeit und Checkouts</title>

+<!--
      <para>If you're using Apache as your Subversion server and have
        made certain subdirectories of your repository unreadable to
        certain users, you need to be aware of a possible
        nonoptimal behavior with <command>svn checkout</command>.</para>

+-->
+    <para>Falls Sie Apache als Ihren Subversion-Server verwenden und
+      bestimmte Unterverzeichnisse Ihres Projektarchivs für bestimmte
+      Anwender unlesbar gemacht haben, müssen Sie über ein
+      mögliches suboptimales Verhalten von <command>svn
+        checkout</command> Bescheid wissen.</para>
+
+<!--
      <para>When the client requests a checkout or update over HTTP, it
        makes a single server request and receives a single (often
        large) server response.  When the server receives the request,
@@ -6249,6 +6449,30 @@
        rather than asking for authentication partway through.</para>
    </sidebar>

+-->
+    <para>Wenn der Client einen Checkout oder eine Aktualisierung über
+      HTTP verlangt, macht er eine einzige Anfrage beim Server und
+      erhält eine einzelne (oftmals umfangreiche) Antwort vom Server.
+      Wenn der Server die Anfrage erhält, ist das die
+      <emphasis>einzige</emphasis> Gelegenheit für Apache, die
+      Authentifizierung des Anwenders einzufordern. Das hat einige
+      merkwürdige Seiteneffekte. Wenn beispielsweise ein
+      Unterverzeichnis des Projektarchivs nur für die Anwenderin Sally
+      lesbar ist und der Anwender Harry ein Elternverzeichnis
+      auscheckt, wird sein Client auf die initiale Aufforderung zur
+      Authentifizierung als Harry antworten. Während der Server die
+      umfangreiche Antwort erzeugt, besteht keine Möglichkeit beim
+      Erreichen des besonderen Verzeichnisses eine erneute
+      Aufforderung zu senden; das Verzeichnis wird somit einfach
+      übergangen, anstatt den Anwender im passenden Moment
+      aufzufordern, sich als Sally zu authentifizieren. Auf ähnliche
+      Weise wird der komplette Checkout ohne Authentifizierung
+      vollzogen, falls das Wurzelverzeichnis des Projektarchivs anonym
+      für jeden lesbar ist; auch hier werden nicht lesbare
+      Verzeichnisse übergangen, anstatt zwischendurch zur
+      Authentifizierung aufzufordern.</para>
+  </sidebar>
+
    </sect1>

    <!-- =================================================================  
-->


More information about the svnbook-dev mailing list