Я пытаюсь настроить 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: PONG
Перезапустите {unicorn, sidekiq, redis}
Отчеты о том, что перезапуск одной или нескольких служб устраняет эту проблему, здесь не применяются. Это не временная проблема, которую исправляет выпуск демона.
Репо не создается физически
Но это. Каждый раз в первый раз, голый репозиторий git в ~gitlab/repositories/username/reponame.git
создается каждый раз и, кажется, имеет правильные разрешения.
Gitlab-shell не может общаться с сервером API, потому что A) проблемы с DNS, B) неправильная привязка ip / port / interface C) отсутствие / наличие косой черты.
Сценарий проверки говорит, что доступ к API в порядке.
Я не использую nginx, поэтому проблема привязки ip по умолчанию, связанная с этим, отсутствует.
Я пробовал оба *: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` безрезультатно. Та же ошибка.
Кажется, это целый перечень предлагаемых решений, но ни одно из них не кажется правильным. Примечание I могу протолкнуть http. Запрос на вход в систему принимает мое имя пользователя и пароль ldap и принимает push. Это только проблема при попытке использовать SSH. Тестирование только части входа в ssh с помощью ssh -T gitlab@server
работает отлично.
Что еще могло вызвать эту ошибку?
Как отладить такую проблему в gitlab? Кажется, что в ~gitlab/gitlab-shell/gitlab-shell.log
. Где найти более информативное сообщение об ошибке?
Я почти уверен, что у вас есть проблема с настройкой между SSH и системой из-за этого сообщения отладки SSH:
client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
Вы получаете это сообщение сразу после успешной аутентификации и отсутствия сообщения от bash, что означает, что никакая программа не была запущена после входа в систему.
Посмотрите в своем файле passwd, если у вас есть правильные настройки для пользователя gitlab:
gitlab:x:1011:1012:GitLab,,,:/path/to/gitlab:/bin/bash
Убедитесь, что bash не имеет ничего странного в файлах конфигурации, таких как
Затем перейдите на более высокий уровень: Gitlab-shell Проверьте /path/to/gitlab/.ssh/authorized_keys имеет конфигурацию ниже:
command="/path/to/gitlab/gitlab-shell/bin/gitlab-shell key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa A...
с участием / путь / к / gitlab / gitlab-shell / bin / gitlab-shell принадлежит пользователю gitlab и исполняемому файлу.
Вы можете быть уверены, что gitlab-shell полностью работоспособен, запустив команду:
# /path/to/gitlab-shell/bin/gitlab-shell
Welcome to GitLab, Anonymous!
Если удаленный вход в систему действительно работает и правильно подключен к оболочке gitlab, вы должны получить такое же приветственное сообщение (но соответствующее пользователю, чей ключ ssh вы использовали для входа в систему), прежде чем он выкинет вас, если вы попытаетесь войти в систему удаленно.
$ ssh gitlab@server
Welcome to GitLab, <your user's full name>!
Connection to <server> closed.
Нет сообщения здесь, вероятно, означает, что ssh вообще не подключает вас к gitlab.
Наконец, проверьте конфигурацию оболочки gitlab (config.yml) и убедитесь, что:
http_settings:
# trailing slash is important
gitlab_url: "https://remote_server/"
ca_file: /path/to/webserver/certificate.crt
и в итоге:
self_signed_cert: false
У меня была такая же проблема, и после нескольких дней поиска в Google и поиска по переполнению стека я наконец нашел свою проблему. Я хотел связать это в письменной форме с Gitlab на случай, если у кого-то такая же проблема.
Я нашел здесь свое решение: https://stackoverflow.com/questions/17307154/git-bash-push-to-bitbucket-ignores-ssh-key
Я работаю в Windows, и проблема заключалась в том, что Git Bash пытался получить местоположение своего ключа SSH из файла plink.exe, установленного с Putty.
Решением было удалить переменную окружения GIT_SSH. Потом все заработало.
Надеюсь, это поможет кому-то там.