uscr 19.04.2011 13:08

Есть проблема!Gitolite. gitolite-admin - пустой репозиторий.

Здравствуйте. Вчера поставил git в связке gitosis. Сегодня прозрел и понял, что gitosis мне не подходит, а подходит мне gitolite. Но я не придумал как удалить gitosis, поэтому просто поставил Gitolite под другим пользователем. Теперь делаю git clone gitolite@some-server:gitolite-admin и получаю:
Initialized empty Git repository in /home/nazarovd/gitolite-admin/.git/
warning: You appear to have cloned an empty repository.


И это логично, ведь:

# ls -la gitolite-admin/
total 12
drwxr-xr-x 3 gitolite gitolite 4096 Apr 19 12:18 .
drwx------ 7 gitolite gitolite 4096 Apr 19 12:18 ..
drwxrwxr-x 7 gitolite gitolite 4096 Apr 19 12:18 .git

Вопросы:
Как правильно грохнуть gitosis (ставил не пакетом, а скриптом из исходников)?
Что делать с настроечным репозиторием gitolite-admin (он пустой же)?

UPD
Вот как я всё делал на самом деле:

Делаю так:

На стороне сервера.

Cтавлю Git, создаю пользователя с именем git.
Клонирую репозиторий с Gitolite'ом: git clone git://github.com/sitaramc/gitolite gitolite-source

Далее так:
cd gitolite-source
mkdir -p /var/www/git/data/gitolite/conf /var/www/git/data/gitolite/hooks
src/gl-system-install /usr/local/bin /var/www/git/data/gitolite/conf /var/www/git/data/gitolite/hooks
gl-setup /home/git/.ssh/git.pub
<b>Теперь проверяю что всё работает, скачивая настроечный репозиторий и добавив нового пользователя:</b>

<<b>git@localhost ~</b>>$ git clone git@localhost:gitolite-admin
Cloning into gitolite-admin…
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
<<b>git@localhost ~</b>>$ cd gitolite-admin/
<<b>git@localhost gitolite-admin</b>>$ cp /tmp/nazarovd.pub keydir/
<<b>git@localhost gitolite-admin</b>>$ git add.
<<b>git@localhost gitolite-admin</b>>$ git commit -am «test»
test
Committer: Git Git
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

git config --global user.name «Your Name»
git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

git commit --amend --reset-author

1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 keydir/nazarovd.pub
<<b>git@localhost gitolite-admin</b>>$ git push
Counting objects: 6, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 679 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
remote:
remote: ***** WARNING *****
remote: the following users (pubkey files in parens) do not appear in the config file:
remote: nazarovd(nazarovd.pub)
To git@localhost:gitolite-admin
6447e62..c1bd008 master -> master
<<b>git@localhost gitolite-admin</b>>$ cat conf/gitolite.conf
repo gitolite-admin
RW+ = id_rsa

repo testing
RW+ = @all

<b>Всё впорядке.

Теперь ухожу на локальную машину. Логинюсь под юзером nazarovd (его открытый ключ я положил на сервер).
Настраиваю авторизацию по ключу:
</b>
nazarovd@workmashine:~$ ssh-copy-id -i ~/.ssh/id_rsa git@192.168.0.135
git@192.168.0.135's password:
Now try logging into the machine, with «ssh 'git@192.168.0.135'», and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

nazarovd@workmashine:~$ ssh 'git@192.168.0.135'
<<b>git@localhost ~</b>>$ logout

<b>Пытаюсь клонировать тестовый репозиторий:</b>

nazarovd@workmashine:~$ git clone git@192.168.0.135:testing
Initialized empty Git repository in /home/nazarovd/testing/.git/
fatal: 'testing' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

РЕШЕНИЕ:
Не делать ssh-copy-id и больше спать. Тогда всё заработает.


Тэги:
+ -3 -
Похожие Поделиться

doit 19.04.2011 13:35 #
Гитосис, так же как и гитолайт просто набор скриптов, удалять в принципе кроме них ничего не нужно. Если ставил с репы, удали метапакет и забудь.

Гитолайт на самом деле более адекватный, конфиг гораздо понятнее. Покажи конфиг гитолайт и конфиг с ACL твоими, покажи вывод ssh user@server info user
Проверь права до файлов на сервере (sudo -u user -i и попробуй клонировать локально)
Переинициализируй гитолайт
sudo -H -u user gl-setup keay.pub
uscr 19.04.2011 13:46 #
Гитосис, так же как и гитолайт просто набор скриптов, удалять в принципе кроме них ничего не нужно. Если ставил с репы, удали метапакет и забудь.

Ставил из исходников. Просто я думал, что есть некий скрипт для удаления скриптов.

Покажи конфиг гитолайт и конфиг с ACL твоими

# pwd
/home/gitolite/.gitolite/conf
# cat gitolite.conf
repo gitolite-admin
RW+ = @all

repo testing
RW+ = @all
#
Оно?
uscr 19.04.2011 13:47 #
покажи вывод ssh user@server info user.

ssh gitolite@someserver info user
info: Writing node (coreutils.info.gz)users invocation... File: coreutils.info, Node: users invocation, Next: who invocation, Prev: groups invocation, Up: User information 20.5 `users': Print login names of users currently logged in ============================================================
_-=bla-bla-bla=-_
info: Done.
Работает.

sudo -H -u user gl-setup keay.pub

# whereis glsetup
glsetup:
Провал.
doit 19.04.2011 13:49 #
whereis gl-setup
gl-setup: /usr/bin/gl-setup

Или если gl ставил с сырцов, то бинарники должны быть в пакете
uscr 19.04.2011 13:50 #
Вру. gl-setup есть, я дефис забыл. Но там с путями проблема. Сейчас поправлю скрипт...
doit 19.04.2011 14:24 #
Странно он у тебя отображает, вот мое
ssh git@server info user
hello user, the gitolite version here is 1.5.4-2+squeeze1 (Debian)
the gitolite config gives you the following access:
@R @W testing
doit 19.04.2011 14:52 #
Понял ) Ты выполни команду так. чтобы ее обработал frontend, а именно gitolite.
Ты не должен авторизироваться стандартным ssh. Убери нафиг юзера gitolite локального и info это команда gitolite.
uscr 19.04.2011 13:57 #
Помогла переинициализация, но с настроечным репозиторием можно работать только локально. Удалённо всё равно стягивается пустым.
doit 19.04.2011 14:15 #
При клонировании попробуй указать master, в качестве ветки по умолчанию
doit 19.04.2011 14:16 #
Ошибка не изменилась? раньше он правильно пустой клонировал...
uscr 19.04.2011 14:51 #
Я вдруг понял, что к настроечному репозиторияю имеет доступ только один юзер в независимости от конфига. Только вот не могу достучатся до репозитория test. Делаю так:
nazarovd@workmashine:~/test_project$ git init
Initialized empty Git repository in /home/nazarovd/test_project/.git/
nazarovd@workmashine:~/test_project$ git remote add origin gitolite@someserver:test.git
nazarovd@workmashine:~/test_project$ git add .
nazarovd@workmashine:~/test_project$ git commit -am "Begin test"
Begin test
_-=bla-bla-bla=-_
2 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 about
create mode 100755 test.py
nazarovd@workmashine:~/test_project$ git push
fatal: 'test.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
nazarovd@workmashine:~/test_project$ git remote rm origin
nazarovd@workmashine:~/test_project$ git remote add origin gitolite@someserver:test
nazarovd@workmashine:~/test_project$ git push
fatal: 'test' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
Я пропустил какой то шаг или просто ничегон е работает?
doit 19.04.2011 14:56 #
https://github.com/sitaramc/gitolite/tree/pu/doc

Очень рекомендую
doit 19.04.2011 14:59 #
Если новый реп не описан в конфиге. как он будет права раскидывать? )
Можно в конфиге прописать права для создание бранчей, но не новых репов.
И новые репы gitolite и gitosys делают bare, в принципе понятно зачем
doit 19.04.2011 15:01 #
Попробуй git clone user@erver:testing.git по умолчанию вроде
uscr 19.04.2011 15:10 #
Так и делаю.
Репозиторий описан. Я ошибся - не test, а testing. Но все те же действия с testing плодов не принесли. Или нужно на сервере руками инициализировать репозиторий? gitosis сам создавал.
doit 19.04.2011 15:13 #
НЕт, руками только прописываешь и пушишь конфиг. в .gitolite.rc прописан путь до репов, посмотри как там фактически поживает твой testing и gitolite-admin должен там же
doit 19.04.2011 14:55 #
Создать репозиторий можно только указав его в конфиге и запушить изменения. Потом уже клонируешь реп и делаешь с ним что хочешь.
doit 19.04.2011 14:55 #
Не туда ответил
uscr 19.04.2011 14:59 #
Точно! Клонировать же надо!
uscr 19.04.2011 15:01 #
Нет. Кстати я уже исправился. Не test, а testing.
uscr 19.04.2011 15:02 #
git clone gitolite@someserver:testing.git
Initialized empty Git repository in /home/nazarovd/test_project/testing/.git/
fatal: 'testing.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
doit 19.04.2011 15:08 #
Уже лучше, просто на серваке не может найти эту репу.
ssh gitolite@someserver покажи
В конфиге прописал путь до репов или по дефолту в хомяке валяются?
uscr 19.04.2011 15:43 #
В хомяке.
ssh 'gitolite@someserver'
Last login: Tue Apr 19 15:30:26 2011 from 94.228.243.135
$

Оболочку не менял. Это критично?
doit 19.04.2011 15:55 #
ssh 'gitolite@someserver'
Last login: Tue Apr 19 15:30:26 2011 from 94.228.243.135

Он у тебя не должен логиниться этим юзером ) Удали с локального компа его, ты все операции выпольняешь от своего nazarovd ^_^ Не путай
uscr 19.04.2011 16:00 #
Бррр. Вот теперь я запутался.

Итак:
На сервере есть юзер gitolite. С его ключём я установил gitolite. Из-под gitolite на сервере я правлю настроечный реп.

На локальной машине у меня есть nazarovd. На сервере лежит открытый ключ nazarovd (хотя пока в этом нет смысла, репозиторий открыт для @all). Я залогинился как nazarovd, но все действия выполняю на сервере через юзера gitolite. Соответсвенно, у меня настроена авторизация по ключам.

Что не так?
doit 19.04.2011 16:10 #
Логиниться на сервер тебе не нужно, сделай проще:

Инициализируй gl с ключом твоего юзера nazarovd, таким образом ты сможешь забрать админку на локаль. Затем с твоего хоста, от своего пользователя (не с сервака) пробуешь подконектица к gl (ssh gitolite@server), если все верно настроено ты попадешь на gitolite, который сравнит твой ключ, найдет записи в конфиге acl и выведет список репозиториев к которым ты имеешь доступ.

@all - это означает либо все репозитории (указанные в конфиге) или, что все _добавленые_ пользователи могут получить доступ к репозиторию. Нет ключа - нет доступа.

Не добавляй свой ключ к юзеру gitolite, ключи добавляются только в gitolite-admin/keydir
uscr 19.04.2011 16:26 #
Да. Сейчас так попробую.
uscr 19.04.2011 16:44 #
Беда. Можно всё это прям по шагам рассписать для тупых?
Делаю на сервере из-под юзера git на сервере: /usr/local/bin/gl-setup /home/git/nazarovd.pub
Тратата. Происходит нечто.

Теперь с локального компа из по юзера nazarovd делаю так:
nazarovd@workmashine:~$ git clone git@someserver:gitolite-admin
Initialized empty Git repository in /home/nazarovd/gitolite-admin/.git/
fatal: 'gitolite-admin' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

Это провал?
uscr 19.04.2011 18:22 #
Попробовал эту схему на свежем центосе в виртуалке - результат аналогичный.
Мой способ тоже не работает. Проблемы аналогичные.
doit 20.04.2011 07:28 #
remote: ***** WARNING *****
remote: the following users (pubkey files in parens) do not appear in the config file:
remote: nazarovd(nazarovd.pub)


эм... Это не смутило?
Тут у тебя
repo gitolite-admin
RW+ = id_rsa

Хотя не в этом проблема, давай конфиг все таки попырим, смени путь до репозиториев, перенеси туда репы, попробуй склонировать по ssh админку удаленно, такая беда была у меня, точно помню копировал пустые репы, но как то очень быстро и просто решмлось, не заморачивайся тут беда мелкая какая-то.
uscr 19.04.2011 16:01 #
Насколько я понял, он не будет логинится, если поставить ему git'овскую оболочку. Но разве это не вопрос безопасности? Работоспобность не должна зависеть от этого.
doit 19.04.2011 16:18 #
Как он будет работать, там все действия скриптов основаны на post автаризации ssh. Что еще за гитовская оболочка? Про безопасность я тебя не понял, ты имеешь ввиду что не ссекурно хранить паблики у себя на локали?
kstep 19.04.2011 19:05 #
Для тех кто в танке (ниасилил справку по гитолайту).

Гитолайт вешает два хука: один на ssh-login (запуск основного скрипта-контроллера доступа), срабатывает при логине через юзера git (у вас юзер gitolite), и второй хук update в подконтрольных репах гита.

Вы ВСЕГДА логинитесь на гит-сервер под юзером gitolite. Вообще всегда. Все клонирования, пуши и пуллы идут из-под юзера gitolite. Гитолайт вас распознаёт не по ИМЕНИ пользователя, а по КЛЮЧУ. И только по ключу.

Гитолайт поддерживает файл ~gitolite/.ssh/authorized_keys в таком виде:

command="/var/git/gitolite/src/gl-auth-command production",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAA...4D5Q== soc@localhost
command="/var/git/gitolite/src/gl-auth-command useradmin",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAA...SKuc= rsa-key-20100707

То есть вы логинитесь ПОД ЮЗЕРОМ gitolite но со своим КЛЮЧЁМ. ssh ищет настройку для вашего ключа и запускает gl-auth-command с вашим именен юзера, под которым ваш ключ и доступ сконфигурен в гитолайте, и уже этот скрипт-хук опередяет ваше право вообще смотреть в ту репу, куда вы ломитесь. Это первый круг обороны.

Второй круг обороны — хук update в подкронтрольном репе, куда вас допустил gl-auth-command. Он срабатывает при попытке запушить что-то в реп и разруливает права на уровке конкретных веток и файлов (а не репов, как делает gl-auth-command).

Отсюда вывод: права на чтения можно выдавать только на весь реп, а не на конкретные ветки/файлы, для веток/файлов работают только права на запись.

kstep 19.04.2011 19:11 #
Гитосис работает аналогично, за исключением хука update в репах.
uscr 19.04.2011 23:49 #
Это вы мне?
Я, может быть, некорректно описал свои дествия, но я всё это понимаю. Вот скомканное резюме моей установки.
Вот много и подробно.
kstep 20.04.2011 00:09 #
Прошу прощения, возможно я немного не так понял =) Не принимай не свой счёт. В любом случае явно нигде про принцип работы гитолайтов в этом посте не было сказано, так что может эта инфа кому пригодится.
kstep 20.04.2011 00:14 #
Не надо делать ssh-copy-id самому, authorized_keys поддерживается гитолайтом, ручками это делать не надо. Надо сделать в админском репе гитолайта

mkdir -p keydir
cp ~/.ssh/id_rsa.pub keydir/nazarovd.pub
git add keydir
git commit -m "add nazarovd public key"
git push origin master

в этот момени гитолайт должен своим хуком на своем репе обновить authorized_keys с нужными ему настройками.
kstep 20.04.2011 07:02 #
Конкретно здесь проблема в том, что ключик свой ты добавил два раза: один раз правильно через гитолайт запушил, а второй раз залил ручками через ssh-copy-id, и это и стало ошибкой. Ты этим самым перебил хук гитолайта, из-за этого при клонировании ты стучишься не гитолайту, который уже сам подгонит все каталоги репов, а напрямую в шелл, соответственно репов найти не получается по короткому пути. Перепуши последний коммит со своим файлом-ключом на сервере и не пользую больше ssh-copy-id совместно с гитолайтом.