Merge pull request #138 from DiegoFRamirez/new_corrections

Review files in 04-git-server finished

Author: andres-mancera

book/04-git-server/sections/generating-ssh-key.asc

@@ -4,11 +4,11 @@
 (((SSH keys)))
 Tal y como se ha comentado, muchos servidores Git utilizan la autentificación
 a través de claves públicas SSH. Y, para ello, cada usuario del sistema ha de
-generarse una, si es que no la tiene ya. El proceso para hacerlo es similar
+generarse una, si es que ya no la tiene. El proceso para hacerlo es similar
 en casi cualquier sistema operativo.
-Ante todo,  asegurarte que no tengas ya una clave. Por defecto, las claves
+Ante todo,  asegúrate que no tengas ya una clave. Por defecto, las claves
 de cualquier usuario SSH se guardan en la carpeta `~/.ssh` de dicho usuario.
-Puedes verificar si tienes ya unas claves, simplemente situándote sobre dicha
+Puedes verificar si ya tienes unas claves, simplemente situándote sobre dicha
 carpeta y viendo su contenido:
 
 [source,console]
@@ -65,4 +65,3 @@ NrRFi9wrf+M7Q== [email protected]
 
 Para más detalles sobre cómo crear unas claves SSH en variados sistemas operativos,
 consultar la correspondiente guía en GitHub: https://help.github.com/articles/generating-ssh-keys[].
-

book/04-git-server/sections/git-daemon.asc

@@ -1,9 +1,9 @@
 === El demonio Git
 
 (((serving repositories, git protocol)))
-Ahora vamos a configurar un demonio sirviendo repositorios mediante el
-protocolo ``Git''. Es la forma mas común para dar acceso anónimo
-pero rápido a los repositorios. Recuerda que puesto que es un acceso
+Ahora vamos a configurar un ``demonio'' sirviendo repositorios mediante el
+protocolo ``Git''. Es la forma más común para dar acceso anónimo,
+pero rápido, a los repositorios. Recuerda: puesto que es un acceso
 no autentificado, todo lo que sirvas mediante este protocolo será
 público en la red.
 
@@ -15,7 +15,7 @@ integración continua o de compilación) tengan acceso de sólo lectura y no
 necesiten establecer una clave SSH para cada uno de ellos.
 
 El protocolo Git es relativamente fácil de configurar. Básicamente, necesitas
-ejecutar el comando con la variante demonio (daemon):(((git commands, daemon)))
+ejecutar el comando con la variante ``demonio'' (daemon):(((git commands, daemon)))
 
 [source,console]
 ----
@@ -25,9 +25,9 @@ git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
 El parámetro `--reuseaddr` permite al servidor reiniciarse sin esperar
 a que se liberen viejas conexiones; el parámetro `--base-path` permite a los
 usuarios clonar proyectos sin necesidad de indicar su camino completo; y el
-camino indicado al final del comando mostrará al demonio Git dónde buscar los
+camino indicado al final del comando mostrará al ``demonio'' Git, dónde buscar los
 repositorios a exportar. Si tienes un cortafuegos activo, necesitarás abrir
-el puerto 9418 para la máquina donde estás configurando el demonio Git.
+el puerto 9418 para la máquina donde estás configurando el ``demonio'' Git.
 
 Este proceso se puede demonizar de diferentes maneras, dependiendo del sistema
 operativo con el que trabajas. En una máquina Ubuntu, puedes usar un script
@@ -52,13 +52,13 @@ exec /usr/bin/git daemon \
 respawn
 ----
 
-Por razones de seguridad, es recomendable lanzar este demonio con un usuario
+Por razones de seguridad, es recomendable lanzar este ``demonio'' con un usuario
 que tenga únicamente permisos de lectura en los repositorios (Lo puedes hacer
-creando un nuevo usuario 'git-ro' y lanzando el demonio con él). Para
-simplificar, en estos ejemplos vamos a lanzar el demonio Git bajo el mismo
+creando un nuevo usuario 'git-ro' y lanzando el ``demonio'' con él). Para
+simplificar, en estos ejemplos vamos a lanzar el ``demonio'' Git bajo el mismo
 usuario `git` que se usa con `git-shell`.
 
-Tras reiniciar tu máquina, el demonio Git arrancará automáticamente y se
+Tras reiniciar tu máquina, el ``demonio'' Git arrancará automáticamente y se
 reiniciará cuando se caiga. Para arrancarlo sin necesidad de reiniciar la
 máquina, puedes utilizar el comando:
 
@@ -83,4 +83,3 @@ $ touch git-daemon-export-ok
 
 La presencia de este archivo dice a Git que este proyecto se puede servir sin problema
 sin necesidad de autentificación de usuarios.
-

book/04-git-server/sections/git-on-a-server.asc

@@ -1,5 +1,5 @@
 [[r_git_on_the_server]]
-=== Configurando Git en un servidor 
+=== Configurando Git en un servidor
 
 Ahora vamos a cubrir la creación de un servicio de Git ejecutando estos protocolos en su propio servidor.
 [NOTE]
@@ -43,14 +43,14 @@ Suponiendo que existe `/ opt / git` en ese servidor, puedes configurar tu nuevo
 $ scp -r my_project.git [email protected]:/opt/git
 ----
 
-En este punto, otros usuarios que con acceso SSH al mismo servidor que tiene permisos de lectura-acceso al directorio `/ opt / git` pueden clonar tu repositorio mediante el comando
+En este punto, otros usuarios con acceso SSH al mismo servidor que tiene permisos de lectura-acceso al directorio `/ opt / git` pueden clonar tu repositorio mediante el comando
 
 [source,console]
 ----
 $ git clone [email protected]:/opt/git/my_project.git
 ----
 
-Si un usuario accede por medio de SSH a un servidor y tiene permisos de escritura en el directorio `git my_project.git` / opt / /, automáticamente también tendrán acceso push.
+Si un usuario accede por medio de SSH a un servidor y tiene permisos de escritura en el directorio `git my_project.git` / opt / /, automáticamente también tendrá acceso push.
 
 Git automáticamente agrega permisos de grupo para la escritura en un repositorio apropiadamente si se ejecuta el comando `git init` con la opción` --shared`.(((git commands, init, bare)))
 
@@ -61,13 +61,13 @@ $ cd /opt/git/my_project.git
 $ git init --bare --shared
 ----
 
-Puedes ver lo fácil que es tomar un repositorio Git, crear una versión vacía, y colocarlo en un servidor al que tú y tus colaboradores tienen acceso SSH.
-Ahora estan listos para colaborar en el mismo proyecto.
+Puedes ver lo fácil que es tomar un repositorio Git, crear una versión vacía y colocarlo en un servidor al que tú y tus colaboradores tienen acceso SSH.
+Ahora están listos para colaborar en el mismo proyecto.
 
 Es importante tener en cuenta que esto es literalmente todo lo que necesitas hacer para ejecutar un útil servidor Git al cual varias personas tendrán acceso - sólo tiene que añadir cuentas con acceso SSH a un servidor, y subir un repositorio vacío en alguna parte a la que todos los usuarios puedan leer y escribir.
 Estás listo para trabajar. Nada más es necesario.
 
-En las próximas secciones, verás cómo ampliar a configuraciones más sofisticadas.
+En las próximas secciones, verás cómo ampliarlo con configuraciones más sofisticadas.
 Esta sección incluirá no tener que crear cuentas para cada usuario, añadiendo permisos de lectura pública a los repositorios, la creación de interfaces de usuario web y más.
 Sin embargo, ten en cuenta que para colaborar con un par de personas en un proyecto privado, todo_lo_que_necesitas_es un servidor SSH y un repositorio vacío.
 
@@ -82,12 +82,12 @@ Si quieres que algunos repositorios sean de sólo lectura para ciertos usuarios
 (((serving repositories, SSH)))
 Si tienes un servidor al que todos los desarrolladores ya tienen acceso SSH, es generalmente más fácil de configurar el primer repositorio allí, porque no hay que hacer casi ningún trabajo (como ya vimos en la sección anterior). Si quieres permisos de acceso más complejas en tus repositorios, puedes manejarlos con los permisos del sistema de archivos normales del sistema operativo donde tu servidor se ejecuta.
 
-Si deseas colocar los repositorios en un servidor que no tiene cuentas para todo el mundo en su equipo para el que deseas tener acceso de escritura, debes configurar el acceso SSH para ellos. Suponiendo que tienes un servidor con el que hacer esto, ya tiene un servidor SSH instalado, y así es como estás accediendo al servidor.
+Si deseas colocar los repositorios en un servidor que no tiene cuentas para todo el mundo en su equipo para el que deseas tengan acceso de escritura, debes configurar el acceso SSH para ellos. Suponiendo que tienes un servidor con el que hacer esto, ya tiene un servidor SSH instalado y así es como estás accediendo al servidor.
 
 Hay algunas maneras con las cuales puedes dar acceso a todo tu equipo. La primera es la creación de cuentas para todo el mundo, que es sencillo, pero puede ser engorroso. Podrías no desear ejecutar `adduser` y establecer contraseñas temporales para cada usuario.
 
 Un segundo método consiste en crear un solo usuario 'git' en la máquina, preguntar a cada usuario de quién se trata para otorgarle permisos de escritura para que te envíe una llave SSH pública, y agregar esa llave al archivo `~ / .ssh / authorized_keys` de tu nuevo usuario 'git'.
 En ese momento, todo el mundo podrá acceder a esa máquina mediante el usuario 'git'.
 Esto no afecta a los datos commit de ninguna manera - el usuario SSH con el que te conectas no puede modificar los commits que has registrado.
 
-Otra manera de hacer que tu servidor SSH autentifique desde un servidor LDAP o desde alguna otra fuente de autentificación centralizada que pudieras tener ya configurada. Mientras que cada usuario sea capaz de tener acceso shell a la máquina, cualquier mecanismo de autentificación SSH que se te ocurra debería de funcionar.
+Otra manera es hacer que tu servidor SSH autentifique desde un servidor LDAP o desde alguna otra fuente de autentificación centralizada que pudieras tener ya configurada. Mientras que cada usuario sea capaz de tener acceso shell a la máquina, cualquier mecanismo de autentificación SSH que se te ocurra debería de funcionar.

book/04-git-server/sections/gitlab.asc

@@ -68,8 +68,8 @@ seguirán a su nombre y relacionados con su perfil.
 
 ``Destruir'' un usuario, por su parte, borra completamente al usuario de la
 base de datos y el sistema de archivos. Todos los proyectos y datos de su
-espacio de nombres se perderá, así como cualquier grupo que le pertenezca.
-Esto es, por supuesto, la acción más permanente y destructiva, y casi nunca
+espacio de nombres se perderán, así como cualquier grupo que le pertenezca.
+Esto es, por supuesto, la acción más permanente, destructiva y casi nunca
 se usa.
 
 [[r_gitlab_groups_section]]
@@ -85,12 +85,12 @@ http://server/formacion/materiales[].
 .Pantalla de administración de grupos en GitLab.
 image::images/gitlab-groups.png[Pantalla de administración de grupos en GitLab.]
 
-Cada grupo se asocia con un conjunto de usuarios, y cada usuario tiene un nivel
+Cada grupo se asocia con un conjunto de usuarios, donde cada usuario tiene un nivel
 de permisos sobre los proyectos así como el propio grupo. Estos permisos van desde
 el de ``Invitado'' (que solo permite manejar incidencias y chat) hasta el de
 ``Propietario'' (con control absoluto del grupo, sus miembros y sus proyectos).
 Los tipos de permisos son muy numerosos para detallarlos aquí, pero
-en la ayuda de la pantalla de administración de GitLab la encontraremos
+en la ayuda de la pantalla de administración de GitLab los encontraremos
 fácilmente.
 
 ===== Proyectos
@@ -107,15 +107,15 @@ tiene acceso de lectura a las páginas del proyecto y al propio repositorio.
 Si un proyecto es _Privado_, el propietario debe conceder los accesos para que
 determinados usuarios tengan permisos. Un proyecto _Interno_ es visible a
 cualquier usuario identificado, y un proyecto _Público_ es visible a todos,
-incluso usuarios identificados y visitantes. Observa que esto controla
+incluso usuarios no identificados y visitantes. Observa que esto controla
 también el acceso de lectura git (``fetch'') así como el acceso a la página
 web del proyecto.
 
 ===== Enganches (hooks)
 
 GitLab tiene soporte para los enganches (hooks), tanto a nivel de proyecto
 como del sistema. Para cualquiera de ellos, el servidor GitLab realizará
-una petición HTTP POST con determinados datos JSON cuando ocurran determinados
+una petición HTTP POST con determinados datos JSON cuando ocurran ciertos
 eventos. Es una manera interesante de conectar los repositorios y la instancia
 de GitLab con el resto de los mecanismos automáticos de desarrollo, como
 servidores de integración continua (CI), salas de charla y otras utilidades
@@ -149,7 +149,7 @@ $ git clone https://server/namespace/project.git
 ----
 
 La interfaz web te permite acceder a diferentes vistas interesantes del
-repositorio. Además la página principal del proyecto muestra la actividad
+repositorio. Además, la página principal del proyecto muestra la actividad
 reciente, así como enlaces que permiten acceder a los archivos del proyecto
 y a los diferentes commits.
 
@@ -160,10 +160,10 @@ Para trabajar en un proyecto GitLab lo más simple es tener acceso de escritura
 sección ``Members'' de los ajustes del mismo, y asociar el usuario con un
 nivel de acceso (los niveles los hemos visto en
 <<r_gitlab_groups_section>>). Cualquier nivel de acceso tipo
-``Developer'' o superior permite al usuario enviar commits y ramas sin
+``Developer'' o superior, permite al usuario enviar commits y ramas sin
 ninguna limitación.
 
-Otra forma, más desacoplada, de colaboración, es mediante las peticiones
+Otra forma de colaboración, más desacoplada, es mediante las peticiones
 de fusión (merge requests). Esta característica permite a cualquier usuario
 con acceso de lectura, participar de manera controlada. Los usuarios con
 acceso directo pueden, simplemente, crear la rama, enviar commits y
@@ -173,8 +173,8 @@ u otra cualquiera. Los usuarios sin permiso de push pueden hacer un
 a _esa copia_, y abrir una petición de fusión desde su fork hacia el proyecto
 del que partió.
 Este modelo  permite al propietario tener un control total de lo que entra
-en el repositorio, permitiendo sin embargo la cooperación de usuarios
-en los que no se confía el acceso total.
+en el repositorio, permitiendo a su vez la cooperación de usuarios
+a los que no se confía el acceso total.
 
 Las peticiones de fusión y las incidencias (issues) son las principales
 fuentes de discusión en los proyectos de GitLab. Cada petición de fusión permite

book/04-git-server/sections/gitweb.asc

@@ -58,7 +58,7 @@ $ sudo cp -Rf gitweb /var/www/
 
 Fíjate que es necesario indicar la ubicación donde se encuentran los repositorios
 Git, utilizando la variable 'GITWEB_PROJECTROOT'. A continuación, tienes que
-preparar Apache para que utilice dicho script, Para ello, puedes añadir un
+preparar Apache para que utilice dicho script. Para ello, puedes añadir un
 VirtualHost:
 
 [source,console]
@@ -81,4 +81,3 @@ Recordar una vez más que GitWeb puede servirse desde cualquier servidor web con
 capacidades CGI o Perl. Por lo que si prefieres utilizar algún otro, no debería
 ser difícil configurarlo. En este momento, deberías poder visitar `http://gitserver/`
 para ver tus repositorios online.
-

book/04-git-server/sections/hosted.asc

@@ -3,18 +3,17 @@
 Si no quieres realizar todo el trabajo que implica poner en marcha tu propio
 servidor Git, tienes varias opciones para alojar tus proyectos Git en un
 sitio externo dedicado. Esto tiene varias ventajas: normalmente en los alojamientos
-externos es fácil configurar y comenzar proyectos y no hay que preocuparse del
+externos es fácil configurar y comenzar proyectos sin preocuparse del
 mantenimiento del servidor o de su monitorización.
 Aunque pongas en marcha tu propio servidor internamente, probablemente quieras usar
 un sitio público para tu código abierto. Será más fácil que la comunidad de software
 libre encuentre tu proyecto y colabore.
 
 Actualmente hay bastantes opciones de alojamiento para elegir, cada una con sus
 ventajas e inconvenientes. Para ver una lista actualizada, mira la página acerca
-de alojamiento Git en el wiki principal de Git, en https://git.wiki.kernel.org/index.php/GitHosting[]
+de alojamiento Git en el wiki principal de Git en https://git.wiki.kernel.org/index.php/GitHosting[]
 
 Nos ocuparemos en detalle de Github en <<ch06-github#ch06-github>>, al ser el sitio de alojamiento
 de proyectos más grande, y donde probablemente encuentres otros proyectos en los que
-quieras participar, pero en cualquier caso hay docenas de sitios para elegir sin
+quieras participar. Pero en cualquier caso hay docenas de sitios para elegir sin
 necesidad de configurar tu propio servidor Git.
-