[svnbook commit] r2127 - trunk/src/es/book

gradha svnbook-dev at red-bean.com
Sun Apr 23 12:14:14 CDT 2006


Author: gradha
Date: Sun Apr 23 12:14:13 2006
New Revision: 2127

Modified:
   trunk/src/es/book/ch06.xml

Log:
Book Spanish. Translated nine paragraphs.

Modified: trunk/src/es/book/ch06.xml
==============================================================================
--- trunk/src/es/book/ch06.xml	(original)
+++ trunk/src/es/book/ch06.xml	Sun Apr 23 12:14:13 2006
@@ -2465,27 +2465,31 @@
       </listitem>
     </itemizedlist>
     
-    <para>The most common problem administrators run into is repository
-      ownership and permissions.  Does every process (or user) in the
-      previous list have the rights to read and write the Berkeley DB
-      files?  Assuming you have a Unix-like operating system, a
-      straightforward approach might be to place every potential
-      repository user into a new <literal>svn</literal> group, and
-      make the repository wholly owned by that group.  But even that's
-      not enough, because a process may write to the database files
-      using an unfriendly umask—one that prevents access by
-      other users.</para>
-    
-    <para>So the next step beyond setting up a common group for
-      repository users is to force every repository-accessing process
-      to use a sane umask.  For users accessing the repository
-      directly, you can make the <command>svn</command> program into a
-      wrapper script that first sets <command>umask 002</command> and
-      then runs the real <command>svn</command> client program.  You
-      can write a similar wrapper script for the
-      <command>svnserve</command> program, and add a <command>umask
-      002</command> command to Apache's own startup script,
-      <filename>apachectl</filename>.  For example:</para>
+    <para>El problema más común que se encuentran los administradores
+      es con la propiedad y permisos del repositorio. ¿Tiene cada
+      proceso (o usuario) en la lista anterior permisos para leer y
+      escribir los ficheros de la base de datos Berkeley? Asumiendo
+      que tiene un sistema operativo tipo Unix, una opción simple
+      sería colocar a cada usuario potencial del repositorio
+      en un nuevo grupo <literal>svn</literal>, y hacer que el
+      repositorio al completo esté poseído por este grupo. Pero
+      ni si quiera eso es suficiente, porque un proceso puede
+      escribir los ficheros de la base de datos usando una máscara
+      de permisos hostil—aquella que impida el acceso a
+      otros usuarios.</para>
+
+    <para>Así que el siguiente paso tras el establecimiento de
+      un grupo común para los usuarios del repositorio es forzar
+      a todos los procesos que acceden al repositorio a usar una
+      máscara de permisos aceptable. Para los usuarios que acceden
+      al repositorio directamente, puede envolver el programa
+      <command>svn</command> en un script cuyo primer paso sea
+      ejecutar <command>umask 002</command> y después ejecute
+      el programa cliente <command>svn</command> auténtico.
+      Puede escribir un script de envoltorio similar para el
+      programa <command>svnserve</command>, y añadir el comando
+      <command>umask 002</command> al propio fichero de arranque
+      de Apache, <filename>apachectl</filename>.  Por ejemplo:</para>
 
     <screen>
 $ cat /usr/local/bin/svn
@@ -2497,72 +2501,81 @@
 
 </screen>
 
-    <para>Another common problem is often encountered on Unix-like
-      systems.  As a repository is used, BerkeleyDB occasionally
-      creates new logfiles to journal its actions.  Even if the
-      repository is wholly owned by the <command>svn</command> group,
-      these newly created files won't necessarily be owned by that
-      same group, which then creates more permissions problems for
-      your users.  A good workaround is to set the group SUID bit on
-      the repository's <filename>db</filename> directory.  This causes
-      all newly-created logfiles to have the same group owner as the
-      parent directory.</para>
-
-    <para>Once you've jumped through these hoops, your repository
-      should be accessible by all the necessary processes.  It may
-      seem a bit messy and complicated, but the problems of having
-      multiple users sharing write-access to common files are classic
-      ones that are not often elegantly solved.</para>
+    <para>Hay otro problema común en sistemas tipo Unix.
+      A medida que se usa un repositorio, la base de datos Berkeley
+      ocasionalmente crea nuevos ficheros de registro para sus
+      transacciones. Incluso si el repositorio completo pertenece
+      al grupo <command>svn</command>, estos nuevos ficheros no
+      pertenecerán necesariamente al mismo grupo, lo cual crea
+      de nuevo problemas de permisos para sus usuarios. Un buen
+      método para corregir esto es activar el bit de grupo SUID
+      en el directorio <filename>db</filename> del repositorio.
+      Esto causa que todos los ficheros de registros creados tengan
+      el mismo grupo que el directorio padre..</para>
+
+    <para>Una vez haya saltado por estos aros, su repositorio
+      debería ser accesible por todos los procesos necesarios. Puede
+      que parezca un poco lioso y complicado, pero los problemas
+      de tener múltiples usuarios compartiendo acceso de escritura
+      a ficheros comunes son clásicos, pocas veces solucionados de
+      manera elegante.</para>
     
-    <para>Fortunately, most repository administrators will never
-      <emphasis>need</emphasis> to have such a complex configuration.
-      Users who wish to access repositories that live on the same
-      machine are not limited to using <literal>file://</literal>
-      access URLs—they can typically contact the Apache HTTP
-      server or <command>svnserve</command> using
-      <literal>localhost</literal> for the server name in their
-      <literal>http://</literal> or <literal>svn://</literal> URLs.
-      And to maintain multiple server processes for your Subversion
-      repositories is likely to be more of a headache than necessary.
-      We recommend you choose the server that best meets your needs
-      and stick with it!</para>
+    <para>Afortunadamente, la mayoría de los administradores de
+      repositorios no tendrán nunca la <emphasis>necesidad
+      </emphasis> de tener configuraciones tan complejas.
+      Los usuarios que desean acceder a repositorios que residen
+      en la misma máquina no están limitados a usar el las URLs
+      de accesl <literal>file://</literal>—típicamente
+      pueden contactar con el servidor HTTP de Apache
+      o <command>svnserve</command> usando el nombre de
+      servidor <literal>localhost</literal> en sus URLs
+      <literal>http://</literal> o <literal>svn://</literal>.
+      Y mantener múltiples procesos servidores para sus repositorios
+      de Subversion es probablemente un dolo de cabeza más que
+      algo necesario. ¡Le recomendamos que escoja el servidor que
+      se ajuste mejor a sus necesidades y que se limite a él!</para>
 
     <sidebar>
-      <title>The svn+ssh:// server checklist</title>
+      <title>Lista de tareas para servidor svn+ssh://</title>
 
-      <para>It can be quite tricky to get a bunch of users with
-        existing SSH accounts to share a repository without
-        permissions problems.  If you're confused about all the things
-        that you (as an administrator) need to do on a Unix-like
-        system, here's a quick checklist that resummarizes some of
-        things discussed in this section:</para>
+      <para>Puede ser complicado hacer que un grupo de usuarios con
+        cuentas SSH existentes compartan un repositorio sin
+        problemas de permisos. Si se siente confuso respecto a
+        todas las cosas que usted (como administrador) necesita
+        realizar en un sistema tipo Unix, aquí tielen una lista
+        de tareas que resumen algunas de las cosas discutidas en
+        esta sección:</para>
 
       <itemizedlist>
         <listitem>
-          <para>All of your SSH users need to be able to read and
-            write to the repository.  Put all the SSH users into a
-            single group.  Make the repository wholly owned by that
-            group, and set the group permissions to read/write.</para>
+          <para>Todos sus usuarios SSH necesitan ser capaces de leer
+            y escribir en el repositorio. Ponga a todos los usuarios
+            SSH en un único grupo.  Haga que el propietario del
+            repositorio sea ese grupo, y active los permisos de
+            lectura/escritura para el mismo.</para>
         </listitem>
 
         <listitem>
-          <para>Your users need to use a sane umask when accessing the
-            repository.  Make sure that <command>svnserve</command>
-            (<filename>/usr/local/bin/svnserve</filename>, or wherever
-            it lives in <literal>$PATH</literal>) is actually a
-            wrapper script which sets <command>umask 002</command> and
-            executes the real <command>svnserve</command>
-            binary.  Take similar measures when using
-            <command>svnlook</command> and
-            <command>svnadmin</command>.  Either run them with a sane
-            umask, or wrap them as described above.</para>
+          <para>Sus usuarios deben usar una máscara de permisos
+            aceptable al acceder al repositorio. Asegúrese
+            de que <command>svnserve</command>
+            (<filename>/usr/local/bin/svnserve</filename>, o
+            donde quiera que esté en <literal>$PATH</literal>)
+            es en realidad un script envoltorio que ejecuta
+            <command>umask 002</command> y luego el binario
+            <command>svnserve</command> auténtico. Tome
+            medidas similares con <command>svnlook</command> y
+            <command>svnadmin</command>. Es decir, ejecútelos con
+            una máscara de permisos aceptable, o envuélvalos tal y
+            como se describe anteriormente.</para>
         </listitem>
 
         <listitem>
-          <para>When BerkeleyDB creates new logfiles, they need to be
-            owned by the group as well, so make sure you run
-            <command>chmod g+s</command> on the repository's
-            <filename>db</filename> directory.</para>
+          <para>Cuando la base de datos Berkeley crea nuevos
+            ficheros de registros, también necesitan pertenecer
+            al mismo grupo, así que asegúrese de que ejecuta
+            <command>chmod g+s</command> en el directorio
+            <filename>db</filename> del repositorio.</para>
         </listitem>
       </itemizedlist>
 




More information about the svnbook-dev mailing list