Я настраиваю экземпляр Gitlab в своей домашней лаборатории виртуальных машин и сбит с толку тем, как SSH настроен в Gitlab, поэтому я был бы признателен за понимание того, что я делаю что-то не так, или Gitlab использует некое соглашение, о котором я не знаю.

Я только что установил Gitlab 7.10 CE на CentOS 7 под ESXi 5.5 U2, используя yum install gitlab-ce . Прежде чем переконфигурировать gitlab в первый раз, я изменил /etc/gitlab/gitlab.rb для использования внешней базы данных postgresql, определил внешний SMTP-сервер, внешний порт и каталог внешнего репозитория git (каталог с поддержкой NFS от моего NAS).

Все работает гладко (gitlab-ctl reconfigure выдает исключений, gitlab-rake gitlab:check устраняет ошибок, я могу войти в экземпляр, я могу создавать проекты и вижу, как изменения распространяются в каталог с поддержкой NFS) - до В первый раз я пытаюсь нажать на git-репозиторий, используя сгенерированные инструкции с веб-страницы проекта (я использую msysgit, чтобы нажать на git-репозиторий, если это даже отдаленно актуально).

Нет другого экземпляра / установки git на серверном компьютере, кроме встроенного gitlab - в официальных инструкциях это не упоминалось по мере необходимости, и это звучит разумно; зачем мне в любом случае два экземпляра git? Это звучит как проблема.

При необходимости я опубликую здесь вывод проверки gitlab-rake как обновление, но я бы хотел изначально уменьшить размер поста.

ssh-ключ пользователя клиента -> добавлен через веб-интерфейс Gitlab
путь к git bin сервера -> /opt/gitlab/embedded/bin/git
сервер git home dir -> /var/opt/gitlab/
серверная оболочка git -> sh
проектная группа gitlab -> algorithms

Вот хронология моих усилий:

Действие:

$ git push -u origin master
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Ответ: добавьте авторизованный ключ в каталог .ssh пользователя git.

Действие:

$ git push -u origin master
sh: git-receive-pack: command not found
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

$ ssh git@remote-machine.net echo \$PATH
/usr/local/bin:/usr/bin

Ответ: добавить ~git/.profile файл git пользователю с встроенным мерзавцем путем на экспорте. Добавьте файл ~git/.ssh/environment с экспортированным вложенным путем git (для неинтерактивного режима оболочки). Изменен /etc/ssh/sshd_config для принятия новой конфигурации. Перезапустил sshd .

Действие:

$ ssh git@remote-machine.net echo \$PATH
/usr/local/bin:/usr/bin:/opt/gitlab/embedded/bin/

$ git push -u origin master
fatal: 'algorithms/sedgewick-book.git' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Действие (мотивировано публикацией SO): Добавлена явная директива AllowUsers <...> git для sshd хотя я не использую нестандартный порт.

Ответ: нет. То же сообщение об ошибке, что и раньше.

Действие: я начинаю подозревать, что в URL-адресе SSH чего-то не хватает, поэтому я начал использовать полный путь к своему удаленному репозиторию, хотя мне это и не нужно было, и Gitlab не генерирует это во время начальной настройки проекта.

$ git push origin master
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (5/5), 520 bytes | 0 bytes/s, done.
Total 5 (delta 0), reused 0 (delta 0)
remote: GitLab: No such user or key
To git@remote-machine.net:/mnt/git/repositories/algorithms/sedgewick-book.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'git@remote-machine.net:/mnt/git/repositories/algorithms/sedgewick-book.git'

Ответ: нет. Смотрите ошибку выше.


На данный момент, я должен признать свое поражение. Я попытался использовать другое пространство имен gitlab (а именно, мое собственное имя пользователя вместо группы проектов), я попытался выровнять точно свое имя пользователя gitlab с именем пользователя, используемым в ключе SSH, я попытался создать коммит через Gitlab UI на origin/ мастер, а затем снятие защиты с ветки - конечный результат всегда один и тот же, ошибка выше.

Весьма подозрительно, что я должен указать абсолютный путь к хранилищу (клиент должен полностью не знать, где находится хранилище!) и у групп Gitlab нет каких-либо метаданных, которые, как я вижу, могли бы помешать и добавить некоторые дополнительные данные под таблицу (я вижу их как простые удобные контейнеры проектов).

Наконец, этот пост SO имел очень похожую проблему для меня, но предлагаемое решение не имеет особого смысла - это как если бы я должен был создать отдельного пользователя Gitlab для каждой группы, что было бы совершенно ненормальным, не говоря уже о том, что я Я уже пытался выровнять имя пути к репозиторию с именем пользователя Gitlab, но безрезультатно (но, к сожалению, это тоже очень сомнительно, но я был в отчаянии, поэтому я попробовал).

Ошибка указывает, что Gitlab не знает, как найти пользователя (git), с которым я нажимаю, но я не знаю, что еще попробовать - я добавил ключ SSH к пользователю Gitlab, а также попытался выровнять имя пользователя Gitlab с Имя клиента git (используется в самом открытом ключе SSH).

Я не знаю, что еще попробовать. Любые намеки, пожалуйста?

1 ответ1

1

Я был в состоянии сделать эту работу - я добавлю объяснение в надежде, что кто-то еще будет избавлен от того, за что я потянул за волосы.

Решение было тривиальным, но сообщаемая ошибка вводит в заблуждение, а основная причина неожиданная. Только случайно я наткнулся на ссылку, которая точно описала причину и решение.

По сути, корень проблемы в том, что я вручную добавлял авторизованный SSH-ключ клиента в ~git/.ssh/authorized_keys . Gitlab действительно не любит это, поскольку он вставляет некоторую дополнительную информацию метаданных о своих хранилищах как часть самого ключа - вы должны добавлять ключ SSH в профиль пользователя исключительно через веб-интерфейс.

Причина, по которой я пошел с ручным добавлением ключа SSH, заключается в том, что я получал Permission denied (publickey,gssapi-keyex,gssapi-with-mic) несмотря на то, что ключ SSH был определен, поэтому я согласился с приведенным выше.

Возможно, это может быть сомнительный выбор дизайна, и это похоже на хак - я совсем не убежден, что помещать что-либо, но ключ в authorized_keys ключи целесообразен: не похоже, что он предназначен для хранения информации метаданных (по сути, ложь о назначении самого файла, так как он содержит «что-то еще» в дополнение к ключам), и он противоречит существующим рекомендациям относительно размещения ключей в файле (это первый раз, когда я видел что-то подобное). С другой стороны, можно утверждать, что пользователь git Gitlab действительно является внутренним компонентом Gitlab, и вы не обязаны и не должны вмешиваться в него вручную. Это можно исправить с помощью улучшенной документации.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .