Estou tentando configurar o gitlab (6.5.1) em um servidor limpo e fresco. Tudo parece funcionar, mas o git é incapaz de enviar para qualquer projeto. Seguir os comandos da página do projeto recém-criada e enviar para o controle remoto via ssh fornece:
$ 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.
Este parece ser um problema bastante comum. Infelizmente, parece ter várias causas em potencial e nenhuma delas parece corresponder. Da edição 3424 em uma versão antiga e várias outras fontes online, eu vi e verifiquei as seguintes sugestões:
Teclas ssh restantes
Esta é uma configuração limpa, sem sobras. Minha chave foi adicionada corretamente ao arquivo de chaves autorizadas e é a única listada.
A execução do ssh com o log de depuração mostra erros relacionados aos vars do ambiente Ruby.
O meu aparece limpo. A depuração SSH mostra uma conexão bem-sucedida. Tudo sobre o handshaking de autenticação é normal, então este é o fim da saída:
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_NONBLOCK
Problemas com o ambiente gitlab-shell.
Ao contrário de muitos outros com a mesma mensagem de erro acima, meu script de verificação do gitlab-shell retorna um atestado de integridade:
% 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: PONG
Reinicie {unicorn, sidekiq, redis}
Os relatórios de que reiniciar um ou mais serviços esclarecem isso não parecem se aplicar aqui. Este não é um problema intermitente que corrige o daemon.
O repo não está sendo criado fisicamente
Mas isso é. Na primeira vez, o repositório bare git
~gitlab/repositories/username/reponame.git
é criado toda vez e parece ter as permissões corretas.O Gitlab-shell não pode falar com o servidor da API porque A) problemas de DNS, B) ligação incorreta de ip / porta / interface C) não tendo / tendo uma barra final.
O script de verificação diz que o acesso à API está bom.
Como não estou executando o nginx, o problema de ligação de IP padrão relacionado a isso é n / a.
Eu tentei tanto
*:8080
e127.0.0.1:8080
quanto ao valor de escutaunicorn.yml
.Além disso, tentei várias iterações do host local, 127.0.0.1 e o nome de domínio totalmente qualificado (que está resolvendo bem o DNS) com e sem barras
shell.yml
inutilizáveis. Também tentei conectar isso diretamente ao servidor unicórnio na porta 8080, em vez do host SSL / proxy Apache na porta 80. Nada parece fazer alguma diferença. Meu certificado não é autoassinado e está funcionando bem para navegadores, mas tentei configurar deself_signed_cert: true
qualquer maneira. Nada.Os caminhos do git relatados estão incorretos; adicione o caminho completo da página inicial do usuário do gitlab.
Isso parece uma sugestão legítima, se o gitlab-shell não estiver fazendo algum negócio de macacos para corrigir isso, mas tentei mudar
git remote add origin gitlab@server:username/reponame.git
para `` git remote add origin gitlab @ server: repositories / username / reponame.git` sem sucesso. Mesmo erro.
Essa parece ser a litania de soluções sugeridas, mas nenhuma delas parece certa. Nota: eu sou capaz de enviar http. O prompt de login aceita meu nome de usuário e senha ldap e aceita um envio. Este é apenas um problema ao tentar usar o SSH. Testar apenas a parte de login do ssh ssh -T gitlab@server
funciona bem.
O que mais poderia estar causando esse erro?
Como é possível depurar esse problema no gitlab? Não parece haver nada de relevante ~gitlab/gitlab-shell/gitlab-shell.log
. Onde seria encontrada uma mensagem de erro mais informativa?