Ejecutar un servidor con Git

Como traté de demostrar en esta serie que condujo al 14.º aniversario de Git el 7 de abril, Idiota puede hacer una amplia variedad de cosas además de monitorear el código fuente. Lo crea o no, Git puede incluso administrar su propio servidor Git, por lo que puede, más o menos, ejecutar un servidor Git con Git mismo.

Obviamente, esto implica una gran cantidad de componentes además de Git todos los días, entre los cuales se encuentra Gitolita, la aplicación de back-end que maneja los bits complicados que configuras usando Git. Lo mejor de Gitolite es que debido a que usa Git como su interfaz de usuario, es fácil integrar la administración del servidor Git en el resto de su flujo de trabajo basado en Git. Gitolite proporciona un control preciso sobre quién puede acceder a repositorios específicos en su servidor y qué permisos tienen. Puede manejar este tipo de cosas usted mismo con las herramientas habituales del sistema Linux, pero requiere mucho trabajo si tiene más de uno o dos repositorios en media docena de usuarios.

Los desarrolladores de Gitolite han hecho el trabajo duro para facilitarle el acceso a muchos usuarios a su servidor Git sin darles acceso a todo su entorno, y puede hacerlo todo con Git.

¿Qué es Gitolita? no es un panel de administración y usuario GUI. Ese tipo de experiencia viene con la excelente Gitea proyecto, pero este artículo se centra en la elegancia simple y la cómoda familiaridad de Gitolite.

Índice

Instalar Gitolite

Suponiendo que su servidor Git ejecuta Linux, puede instalar Gitolite con su administrador de paquetes (mmm en CentOS y RHEL, lo superó en Debian y Ubuntu, cremallera en OpenSUSE, etc.). Por ejemplo, en RHEL:

$ sudo yum install gitolite3

Muchos repositorios todavía tienen versiones anteriores de Gitolite para soporte heredado, pero la versión actual es la versión 3.

Debe tener acceso SSH sin contraseña a su servidor. Puede usar una contraseña para iniciar sesión si lo prefiere, pero Gitolite se basa en claves SSH, por lo que debe configurar la opción para iniciar sesión con claves. Si no sabe cómo configurar un servidor para el acceso SSH sin contraseña, aprenda cómo hacerlo primero (la sección Configuración de la autenticación de clave SSH del artículo Ansible de Steve Ovens lo explica bien). Es una parte esencial de la administración segura del servidor, además de ejecutar Gitolite.

Configurar un usuario de Git

Sin Gitolite, si una persona solicita acceso a un repositorio de Git que aloja en un servidor, debe proporcionarle a esa persona una cuenta de usuario. Git proporciona un shell especial, el git-shell, que es un shell ultra específico que solo realiza tareas de Git. Esto le permite tener usuarios que solo pueden acceder a su servidor a través del filtro de un entorno de shell muy limitado.

Esa solución funciona, pero generalmente significa que un usuario obtiene acceso a todos los repositorios en su servidor a menos que tenga un esquema muy bueno para los permisos de grupo y mantenga esos permisos estrictamente cada vez que se crea un nuevo repositorio. . También requiere mucha configuración manual a nivel de sistema, un área generalmente reservada para un nivel específico de administradores del sistema y no necesariamente la persona que suele estar a cargo de los repositorios de Git.

Gitolite evita por completo este problema al designar un nombre de usuario para cada persona que necesita acceso a cualquier repositorio. Por defecto, el nombre de usuario es idiotay dado que la documentación de Gitolite asume que eso es lo que se usa, es un buen valor predeterminado para mantener cuando esté aprendiendo la herramienta. También es una convención muy conocida para cualquiera que haya usado alguna vez GitLab o GitHub o cualquier otro servicio de alojamiento de Git.

Gitolite llama a este usuario el usuario anfitrión. Cree una cuenta en su servidor para actuar como usuario de hosting (me quedo con idiota porque esta es la convención):

 $ sudo adduser --create-home git

para comprobar el idiota cuenta de usuario, debe tener una clave SSH pública válida que le pertenezca. Ya deberías tener esto configurado, entonces c.p. su clave pública (no es tu clave privada) al idiota directorio de inicio del usuario:

$ sudo cp ~/.ssh/id_ed25519.pub /home/git/
$ sudo chown git:git /home/git/id_ed25519.pub

Si su clave pública no termina con la extensión .pub, Gitolite no lo usará, así que cambie el nombre del archivo en consecuencia. Cambie a esa cuenta de usuario para ejecutar la configuración de Gitolite:

$ sudo su - git
$ gitolite setup --pubkey id_ed25519.pub

Después de ejecutar el script de instalación, el idiota el directorio de usuario de inicio tendrá un repositorio directorio, que (por ahora) contiene los archivos git-admin.git Y prueba.git. Esta es toda la configuración requerida por el servidor, así que cierre la sesión.

Usa Gitolita

Administrar Gitolite es una cuestión de editar archivos de texto en un repositorio de Git, específicamente gitolite-admin.git. No usará SSH en su servidor para la administración de Git, y Gitolite le recomienda que no lo intente. Los repositorios que usted y sus usuarios almacenan en el servidor de Gitolite son desnudo repositorio, por lo que es mejor mantenerse al margen.

$ git clone [email protected]:gitolite-admin.git gitolite-admin.git
$ cd gitolite-admin.git
$ ls -1
conf
keydir

El conferencia directorio en este repositorio contiene un archivo llamado gitolite.conf. Ábralo en un editor de texto o use gato para ver su contenido:

repo gitolite-admin
    RW+     =   id_ed22519

repo Pruebas
    RW+     =   @all

Puede tener una idea de lo que hace este archivo de configuración: gitolite-admin representa a este repositorio y al propietario de id_ed25519 key tiene privilegios de administrador de lectura, escritura y Git. En otras palabras, en lugar de asignar usuarios a usuarios locales normales de Unix (porque todos sus usuarios inician sesión usando el archivo idiota identidad del usuario de alojamiento), Gitolite asocia a los usuarios con las claves SSH enumeradas en el archivo directorio clave directorio.

El prueba.git El repositorio proporciona permisos completos a todos los que tienen acceso al servidor utilizando una notación de grupo especial.

Agregar usuarios

Si desea agregar un usuario llamado Alicia a su servidor Git, la persona que Alice tiene que enviarle su clave SSH pública. Gitolite usa lo que está a la izquierda de la .pub extensión como un identificador para sus usuarios de Git. En lugar de utilizar los valores de nombre de clave predeterminados, asigne a las claves un nombre que indique el propietario de la clave. Si un usuario tiene más de una clave (por ejemplo, una para su ordenador portátil y otra para su escritorio), se pueden usar subdirectorios para evitar conflictos de nombres de archivos. Por ejemplo, la clave que usa Alice desde su ordenador portátil puede llegar a usted de forma predeterminada id_rsa.pub, luego cámbiele el nombre alice.pub o similar (o permita que los usuarios nombren la clave de acuerdo con sus cuentas de usuario locales en sus ordenadores) y colóquela en el archivo gitolite-admin.git / keydir / trabajo / portátil / directorio. Si te envía otra clave desde su escritorio, dale un nombre alice.pub (igual que arriba) y agréguelo a keydir / trabajo / escritorio /. Podría entrar otra llave keydir / home / escritorio /, y así. Gitolite busca recursivamente directorio clave para .pub archivo correspondiente a un repositorio "usuario" y tratar cualquier coincidencia como la misma identidad.

Cuando agregas las claves al directorio clave directorios, debe restaurarlos en su servidor. Esto es algo tan fácil de olvidar que aquí hay un argumento real para usar una aplicación Git automatizada como Sparkleshare luego, cualquier cambio se devuelve inmediatamente a su administrador de Gitolite. La primera vez que se olvide de comprometerse y empujar, y desperdicie tres horas de su tiempo y el tiempo de su usuario resolviendo problemas, verá que Gitolite es la justificación perfecta para usar Sparkleshare.

$ git add keydir
$ git commit -m 'added alice-laptop-0.pub'
$ git push origin HEAD

Alice, por defecto, obtiene acceso a prueba.git directorio para que pueda probar la conectividad y la funcionalidad con eso.

Establecer permisos

Al igual que con los usuarios, los permisos de directorio y los grupos se abstraen de las herramientas normales de Unix a las que puede estar acostumbrado (o encontrar información en línea). Los permisos del proyecto se conceden en gitolite.conf archivo gitolite-admin.git/conf directorio. Hay cuatro niveles de autorización:

  • r permite solo lectura. un usuario con r permisos en un repositorio puede clonarlo, y eso es todo.
  • RW permite a un usuario avanzar rápidamente una rama, crear nuevas ramas y crear nuevas etiquetas. Más o menos, parece un repositorio Git "normal" para la mayoría de los usuarios.
  • LE + permite acciones Git potencialmente destructivas. Un usuario puede realizar empujes normales de avance rápido, así como también empujes de rebobinado, rebase y eliminación de ramas y etiquetas. Esto puede o no ser algo que desee otorgar a todos los colaboradores de un proyecto.
  • - niega explícitamente el acceso a un repositorio. Esto es esencialmente lo mismo que un usuario que no aparece en la configuración del repositorio.

Cree un nuevo repositorio o cambie los permisos de un repositorio existente ajustándolo gitolite.conf. Por ejemplo, para otorgar a Alice permisos para administrar un nuevo repositorio llamado widgets.git:

repo gitolite-admin
    RW+     =   id_ed22519

repo Pruebas
    RW+     =   @all

repo widgets
    RW+     =   alice

Ahora Alice, y solo Alice, puede clonar el repositorio:

[alice]$ git clone [email protected]:widgets.git
Cloning into 'widgets'...
warning: You appear to have cloned an empty repository.

En su empujón inicial, Alice debe usar el -tu opción para empujar su rama al repositorio vacío (como debería haber hecho con cualquier host de Git).

Para simplificar la gestión de usuarios, puede definir grupos de repositorios:

@qtrepo = widgets
@qtrepo = games

repo gitolite-admin
    RW+     =   id_ed22519

repo Pruebas
    RW+     =   @all

repo @qtrepo
    RW+     =   alice

Al igual que puede crear repositorios grupales, puede agrupar usuarios. Por defecto hay un grupo de usuarios: @todo. Como era de esperar, incluye a todos los usuarios, sin excepción. Puedes crear el tuyo propio:

@qtrepo = widgets
@qtrepo = games

@developers = alice bob

repo gitolite-admin
    RW+     =   id_ed22519

repo Pruebas
    RW+     =   @all

repo @qtrepo
    RW+     =   @developers

Al igual que con la adición o el cambio de archivos clave, cualquier cambio en el gitolite.conf el archivo debe guardarse y enviarse para que surta efecto.

Crear un depósito

Por defecto, Gitolite asume que el repositorio se crea de arriba a abajo. Por ejemplo, un administrador de proyectos con acceso al servidor Git crea un repositorio de proyectos y, a través del repositorio de administración de Gitolite, agrega desarrolladores.

En la práctica, es posible que prefiera otorgar a los usuarios permiso para crear repositorios. Gitolite llama a estos "repositorios salvajes" (no estoy seguro de si se trata de un comentario sobre cómo se originaron los repositorios o una referencia a los caracteres comodín requeridos por el archivo de configuración para que esto suceda). Aquí hay un ejemplo:

@managers = alice bob

repo foo/CREATOR/[a-z]..*
    C   =   @managers
    RW+ =   CREATOR
    RW  =   WRITERS
    R   =   READERS

La primera línea define un grupo de usuarios: el grupo se llama @gerente y contiene usuarios Alicia Y Beto. La siguiente línea establece un comodín que le permite crear repositorios que aún no existen en un directorio con nombre Foo seguido de un subdirectorio con el nombre del usuario que crea el repositorio. Por ejemplo:

[alice]$ git clone [email protected]:foo/alice/cool-app.git
Cloning into cool-app'...
Initialized empty Git repository in /home/git/repositories/foo/alice/cool-app.git
warning: You appear to have cloned an empty repository.

Existen algunos mecanismos para que el creador de un repositorio salvaje defina quién puede leer y escribir en su repositorio, pero tienen un alcance limitado. En su mayor parte, Gitolite asume que un conjunto específico de usuarios gobierna la autorización del proyecto. Una solución es otorgar acceso a todos los usuarios. gitolite-admin usando un gancho de Git para solicitar la aprobación del administrador para fusionar los cambios en la rama principal.

Saber más

Gitolite tiene muchas más características que las cubiertas en este artículo introductorio, así que pruébalo. El documentación es excelente, y después de leerlo puedes personalizar tu servidor Gitolite para dar a tus usuarios cualquier nivel de control con el que te sientas cómodo. Gitolite es un sistema simple y de bajo mantenimiento que puede instalar, configurar y luego olvidar.

Artículos de interés

Subir