Установка и настройка gitolite на FreeBSD

Система Gitolite позволяет значительно увеличить возможности git репозиториев по разграничению прав доступа. Она представляет из себя дополнительную прослойку поверх git’a и работает по ssh или http. С помощью данной системы можно устанавливать права на скачивание/запись/перезапись не только самих репозиториев, но и веток в них и даже тегов. Так же благодаря механизму hooks (хуков), gitolite позволяте пользователю расширить возможности по управлению репозиторием. Например, организовать систему Push to Deploy.

Настройка данной системы не совсем тривиальна и в данном материале мы постараемся рассмотреть все сложности которые могут возникнуть.

Установка Gitolite

Устанавливаем из портов, при этом подтвердим создание нового пользователя в системе под которым и будет работать gitolite. Будет создан пользователь git с домашней дерикторией /usr/local/git

cd /usr/ports/devel/gitolite
make install clean

Поменять рабочие дериктории любого пользователя (если вам не нравится дериктория по умолчнию) можно командой

pw usermod git -d /home/git

Для доступа к репозиториям по ключу создаем его. Или можем воспользоваться уже существующем.

Для создания ключа заходим в git-bash (для виндовс) и вводим команду на генерацию ключа. Для Unix систем просто испольняем эту команду в консоли.

ssh-keygen -t rsa

Следуя инструкциям приложения получим 2 ключа. Закрытый (без расширения или с .ppk) необходимо сохранить в домашнюю дерикторию текущего пользователя в папку .ssh. Например, у меня эта папка — «C:\Users\HOME\.ssh\». Думаю говорить, что данный файл не должен попасть в чужие руки излишне. По умолчанию, ключ генерируется с именем «id_rsa», но если мы хотим использовать на локальном компьютере  несколько ключей для разных целей, то его стоит переименовать.

Публичный ключ (с расширеним pub ) небходимо скопировать на сервер в домашнюю дерикторию созданного пользователя. Далее необходимо задать имя пользователя которое будет использовать система gitolite под этим ключем. Для этого просто переименуем этот ключ в формате <username>.pub, где <username> — имя пользователя внутри системы gitolite. Потом на это имя будут прикрепляться права доступа. Установим этот первый ключ в системе gitolite’a

gitolite setup -pk /home/git/<username>.pub

после чего этот ключ будет зарегистрирован и его можно проверить в файле /home/git/.ssh/authorized_keys

Эти настройки нужны только для первой инициализации, все действия с другими пользователями будут настраиваться с помощью созаданного репозитория gitolite-admin.

Теперь, если мы переименовали  приватный ключ на нашей локальной машине, то необходимо сделать настройки, чтобы для сервера с нашим gitolite’ом использовался именно он, так как система по умолчанию ищет ключ с именем «id_rsa». В таком случае добавим  в свой локальный «.ssh/config»:

Host <ip адрес сервера> 
    User git
    Hostname <адрес сервера>
    Port 2222
    IdentityFile ~/.ssh/<наш приватный ключ>

После этого из консоли все отлично работает, но из моего редактора (PhpStorm), не читает прописанные таким образом ключи. Возможно как то можно настроить в на стройках редактора, но я просто меня используемый редактором git бинарник на поставляемый с git bash. В настройках вкладка Version control раздел Git и в поле Path to Git executable ставим — C:\Program Files\Git\bin\git.exe (путь до бинарника из поставки GitBash). Параметр SSH executable меняем на Native. После этого настройки из файла «.ssh/config» подхватываются редактором и репозиторием можно управлять прямо из него.

Настройка прав на проектах

Все настройки в системе хранятся немного не обычным способом. Что бы их подправить необходимо скачать(git clone) уже существующую репозиторию gitolite-admin с конфигурацией сервера, подредактировать её и «закомитить обратно» (git push).

Попробуем выкачать репозиторий с настройками(для пользователей Windows это удобно делать в консоли gitBash устанавливаемой вместе с git) и произвести некоторые настройки. Для этого из под пользователя ключ которого мы добавили выше выполним команду

git clone ssh://git@123.123.123.123:22/gitolite-admin

где git@ — имя пользователя созданное при установке gitolite

123.123.123.123:22 — адрес и порт сервера

В скаченном репозитории мы увидим две папки — conf и keydir

Для добавления новых пользователей под управление gitolite необходимо поместить публичный ключ этого пользователя в папку keydir и переименовать в его имя пользователя которое потом будет использоваться в конфигурационном файле для раздачи прав. Например для пользователя sergey, файл должен называться sergey.pub. После этого подредактируем конфигурационный файл в папке conf.

Так как я первый ключ создавал с именем admin.pub, то мой файл пока выглядит так

repo gitolite-admin
 RW+     =   admin

 repo testing
 RW+     =   @all

Добавим в него новый проект и нового пользователя sergey

repo    newproject
        RW+     =   admin sergey

Макрос «@all», отвечает за всех пользователей ключи которых есть в «keydir».

Так же для мы можем разбивать пользователей и на группы

@admins    = <user1> <user2>
@developers = @admins  sergey # comments
@teamlead = <user3>

repo    gitolite-admin
        RW+     =   @admins

repo    project
        R     =   @developers
                  W+       =       @teamlead

Возможные права:

• R — позволяет чтение
• RW — позволяет делать push в существующий ref или создавать новый ref
• RW+ — позволяет делать «push -f»(с перезаписью существующих) или удалять ref (т.е. уничтожать информацию)
• -(минус) — запрещает доступ

Так же можно раздавать права и на отдельные файлы, ветки и теги. Для примера сделаем чтобы @teamlead имели доступ ко всему, а @developers имели доступ только на чтение к ветке «production» и тегам «release*» (но не могли создавать такие теги).

repo  project
    RW+ NAME/                 = @teamlead
    RW+                       = @teamlead

    # Ветка production (с двумя способами ввода)
    R   production            = @developers
    -   refs/heads/production = @developers

    # Теги rc*
    R   refs/tags/release.*        = @developers
    -   refs/tags/release.*        = @developers

    # Права на конкретные файлы:
    R   NAME/project.conf       = @developers
    -   NAME/project.conf       = @developers

    RW+ NAME/                 = @developers
    RW+                       = @developers

Правила проверяются последовательно, так что порядок их следования важен.

Теперь сохраним наши изменения конфигурационного файла и «закоммитим» его на сервер.

git add conf/gitolite.conf
git commit -m "add new repos - newproject"
git push origin master

Пустая папка под наш проект создастся автоматически

>> Initialized empty Git repository in /home/git/repositories/newproject.git/

Новый проект проинициализирован, теперь можно скачать его с локальной машины.

git clone ssh://git@123.123.123.123:22/newproject

Изменения из локального(уже существующего) репозитория в удаленном сохраняем командой

git push origin master
#или
git push origin beta:production #из локальной ветаки beta в удаленную ветку production

Посмотреть содержание всех веток в репозитории можно командой

git fetch origin

Исполнив её мы не поменяем файлы в нашей рабочей копии. А чтобы скачать изменения с одной из веток, допустим master, то можно исполнить команду

git pull origin master

Последняя версия ветки master с репозитория скачается в вашу рабочую копию проекта.

Если мы не делали git clone, то подключить уже существующий репозиторий к удаленному можно командой

git remote add origin ssh://git@123.123.123.123:22/newproject 

Буду признателен за комментарии дополняющие материал. А если статья была Вам полезна, то за клик по рекламе.