Заблокирован из Гитолита и не может GL-Admin-Push - PullRequest
Новая
       49

Заблокирован из Гитолита и не может GL-Admin-Push

2 голосов
/ 20 февраля 2012

Я тупо отформатировал жесткий диск моего ноутбука с помощью ключей 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 ]

2 голосов
/ 16 июля 2012

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

Исправлено обновление файла authorized_keys на сервере для моего пользователя git (который работает с гитолитом) в его папке ~/.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 было возможно.

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

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

2 голосов
/ 20 февраля 2012

OP 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.
...