Я пытаюсь настроить gitlab (6.5.1) на свежий чистый сервер. Кажется, все работает, но git не может перейти ни в один проект. Следование командам со страницы недавно созданного проекта и отправка на удаленный компьютер через ssh дает:
$ 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.
Это кажется довольно распространенной проблемой. К сожалению, кажется, у этого есть несколько потенциальных причин, и ни одна из них, кажется, не совпадает. Начиная с номера 3424 старого выпуска и различных других источников в Интернете, я видел и проверял следующие предложения:
Остаток ключей SSH
Это чистая установка без остатков. Мой ключ был добавлен в файл авторизованных ключей правильно и является единственным в списке.
Запуск ssh с ведением журнала отладки показывает ошибки, связанные с переменными среды Ruby.
Моя приходит чистой. Отладка SSH показывает успешное соединение. Все, что касается аутентификации, является нормальным, тогда это конец вывода:
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Проблемы со средой gitlab-shell.
В отличие от многих других с таким же сообщением об ошибке, приведенным выше, мой скрипт проверки gitlab-shell возвращает чистый счет здоровья:
% 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: PONGRestart {единорог, sidekiq, redis}
Сообщения о том, что перезапуск одной или нескольких служб устраняет эту проблему, похоже, здесь не применяются. Это не временная проблема, возникающая при выпуске исправлений демона.
Репо не создается физически
Но это. В первый раз каждый раз
~gitlab/repositories/username/reponame.gitсоздается пустое git-репо, и у него, кажется, есть правильные разрешения.Gitlab-shell не может общаться с сервером API, потому что: A) проблемы с DNS, B) неправильная привязка ip / port / interface C) отсутствие / наличие косой черты.
Скрипт проверки говорит, что доступ к API в порядке.
Я не запускаю nginx, поэтому проблема связывания с ip по умолчанию связана с n / a.
Я пробовал оба
*:8080и127.0.0.1:8080для значения прослушивания вunicorn.yml.Кроме того, я пробовал различные итерации localhost, 127.0.0.1 и полностью квалифицированное доменное имя (которое прекрасно разрешается DNS) с и без конечных слешей,
shell.ymlно безрезультатно. Я также попытался подключить это напрямую к серверу единорога на порту 8080 вместо хоста Apache SSL / прокси на порту 80. Кажется, ничего не имеет значения. Мой сертификат не самоподписан и работает нормально для браузеров, но яself_signed_cert: trueвсе равно попытался его настроить . Ничего.Сообщенные пути git неверны, добавьте полный путь из дома пользователя gitlab.
Это кажется правдоподобным предложением, если gitlab-shell не занимается каким-либо обезьяньим бизнесом, чтобы исправить это, но я попытался изменить
git remote add origin gitlab@server:username/reponame.gitна `` git remote add origin gitlab @ server: repositories / username / reponame.git` безрезультатно. Та же ошибка.
Кажется, это перечень предлагаемых решений, но ни одно из них не кажется правильным. Обратите внимание, я могу нажать http. Приглашение для входа в систему принимает мое имя пользователя и пароль ldap и принимает push. Это только проблема при попытке использовать SSH. Тестирование только части входа ssh ssh -T gitlab@serverработает нормально.
Что еще может быть причиной этой ошибки?
Как можно отладить такую проблему в gitlab? Там, кажется, не имеет ничего общего в ~gitlab/gitlab-shell/gitlab-shell.log. Где найти более информативное сообщение об ошибке?