Заблокирован из гитолита и не может gl-admin-push

Я тупо отформатировал жесткий диск моего ноутбука с помощью ключей ssh ​​для gitolite, у меня есть root-доступ к моему серверу, и я следовал этому ответу Gitolite access repair, успешно сделал копию моего репозитория в папке tmp и исправил файл

Моя проблема заключается в том, что я получаю сообщение об ошибке при выполнении "gl-admin-push" вот ошибка:

Unable to determine correct path for gitolite scripts from the authkeys file.

Perhaps you haven't installed gitolite yet?

Or perhaps this is an HTTP mode install?  If so, please set the GL_BINDIR
environment variable to the full path of the gitolite scripts, then re-try
this command.  For example (if you followed doc/http-backend.mkd precisely):

GL_BINDIR=/var/www/gitolite-home/bin /home/git/bin/gl-admin-push

Моя установка в gitolite работала нормально до того, как я заперся (facepalm)

Анни. Как я могу выбраться из этого беспорядка?

Источник

2 ответа

Решение

Purplefish32 понял, что это сообщение может также появиться, если пользователь выполняет gl-admin-push не имеет своего открытого ключа должным образом зарегистрирован.

Этот ключ должен быть установлен с помощью скрипта команды gitolite force-command.

command="/home/git/bin/gl-auth-command myusername",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

Это согласуется с тем, что делает этот скрипт:

# if GL_BINDIR was not passed in, find it
[ -z "$GL_BINDIR" ] &&
    GL_BINDIR=`  perl -ne 'print($1), exit if /^command="(.+?)\/gl-(time|auth-command) /' < $HOME/.ssh/authorized_keys`
# GL_BINDIR still not known?  we have a problem...
[ -z "$GL_BINDIR" ] && {
    echo "

Unable to determine correct path for gitolite scripts from the authkeys file.
Источник

У меня была точно такая же проблема.

Исправлено было обновить authorized_keys файл на сервере для моего git пользователь (тот, который работает с Gitolite) в его ~/.ssh/ папка с command=".." упомянутая строка VonC, плюс ssh-pubkey для пользователя, которого я хотел добавить вручную. Просто, чтобы запись соответствовала другим уже существующим записям.

Также я должен был удалить ~/ssh/old_authkeys файл, так как Gitolite, кажется, ссылается на него все время и, таким образом, удаляя обновленный authorized_keys файл в процессе. (Хорошо, я только что переместил его, на случай, если мне понадобится снова...)

Из-за этой второй части я чувствую себя способным сделать дополнительный пост.;)

РЕДАКТИРОВАТЬ:
Похоже на authorized_keys перемещен в old_authkeys каждый раз, когда я обновляю свой конфиг gitolite новыми настройками репо или группы.: |

EDIT2:
Источник всех проблем был... не вошел в систему как пользователь звонил git Я использую для Gitolite, как в

git@server:repo

при попытке получить доступ к репо сервера с сервера, но как, т.е. myuser,
Это привело к испорченным конфигурациям и время от времени возвращался authorized_keys файл.
Однажды я настроил ssh-ключи для пользователя git (и не для myuser), вошли как git (не как myuser), Я исправил настройки через

git clone /local/path/on/server/to/gitolite-admin
(then I set the right permissions in the gitolite config)
gl-admin-push

и все было сделано... когда залогинен как git Пользователь также gl-admin-push работал без ошибок.

После этого регулярное использование git clone git@server:repo-git add .-git commit-git push git@server:repo было возможно.

Еще один случай, когда права пользователей вызывают большие проблемы.

// Это приобретенное знание приходит с мудростью, что оно никогда не будет стоить потраченного на него времени.

Источник
Другие вопросы по тегам