Estoy tratando de configurar gitlab (6.5.1) en un servidor nuevo y limpio. Todo parece funcionar, pero git no puede impulsar ningún proyecto. Seguir los comandos de la página del proyecto recién creado y presionar el control remoto a través de ssh proporciona:
$ git push -u origin master
fatal: Could not read from remote repository.
Please make sure you have the correct access
rights and the repository exists.
Esto parece ser un problema bastante común. Desafortunadamente, parece tener varias causas potenciales y ninguna de ellas parece coincidir. Desde el número 3424 en una versión anterior y varias otras fuentes en línea, he visto y verificado las siguientes sugerencias:
Sobrantes teclas ssh
Esta es una configuración limpia sin restos. Mi clave se agregó correctamente al archivo de claves autorizadas y es la única listada.
La ejecución de ssh con registro de depuración muestra errores relacionados con los vars del entorno Ruby.
El mío sale limpio. La depuración SSH muestra una conexión exitosa. Todo sobre el protocolo de enlace de autenticación es normal, entonces este es el final de la salida:
debug1: Sending command: git-receive-pack 'username/reponame.git' debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCKProblemas con el entorno gitlab-shell.
A diferencia de muchos otros con el mismo mensaje de error anterior, mi secuencia de comandos de verificación gitlab-shell devuelve un estado de salud limpio:
% sudo -u gitlab -H ~gitlab/gitlab-shell/bin/check Check GitLab API access: OK Check directories and files: /var/lib/gitlab/repositories: OK /var/lib/gitlab/.ssh/authorized_keys: OK Test redis-cli executable: redis-cli 2.8.5 Send ping to redis server: PONGReiniciar {unicornio, sidekiq, redis}
Los informes de que reiniciar uno o más servicios aclaran esto no parecen aplicarse aquí. Este no es un problema intermitente que corrige la liberación de un demonio.
El repositorio no se está creando físicamente
Pero es. La primera vez cada vez, el repositorio de git desnudo
~gitlab/repositories/username/reponame.gitse crea cada vez y parece tener los permisos correctos.Gitlab-shell no puede hablar con el servidor API porque A) problemas de DNS, B) enlace incorrecto de ip / puerto / interfaz C) no tener / tener una barra inclinada final.
El script de verificación dice que el acceso a la API está bien.
No estoy ejecutando nginx, por lo que el problema de enlace de ip predeterminado relacionado con eso es n / a.
He intentado ambos
*:8080y127.0.0.1:8080por el valor de escuchar enunicorn.yml.Más allá de eso, he intentado varias iteraciones de localhost, 127.0.0.1 y el nombre de dominio completo (que está resolviendo bien el DNS) con y sin barras diagonales finales en
shell.ymlvano. También he intentado conectar esto directamente al servidor unicornio en el puerto 8080 en lugar del host Apache SSL / proxy en el puerto 80. Nada parece hacer ninguna diferencia. Mi certificado no está autofirmado y funciona bien para los navegadores, pero intenté configurarlo deself_signed_cert: truetodos modos. Nada.Las rutas de acceso de git informadas son incorrectas, agregue una ruta totalmente calificada desde el inicio del usuario de gitlab.
Esto parece una sugerencia legítima si gitlab-shell no está haciendo algunos negocios de monos para corregir esto, pero intenté cambiar
git remote add origin gitlab@server:username/reponame.gita `` git remote add origin gitlab @ server: repositories / username / reponame.git` en vano. Mismo error.
Esta parece ser la letanía de soluciones sugeridas, pero ninguna de ellas parece correcta. Tenga en cuenta que puedo empujar sobre http. La solicitud de inicio de sesión acepta mi nombre de usuario y contraseña de ldap y acepta una inserción. Esto es solo un problema al intentar usar SSH. Probar solo la parte de inicio de sesión ssh ssh -T gitlab@serverfunciona bien.
¿Qué más podría estar causando este error?
¿Cómo se puede depurar un problema de este tipo en gitlab? No parece haber nada relevante en absoluto en ~gitlab/gitlab-shell/gitlab-shell.log. ¿Dónde se encontraría un mensaje de error más informativo?