Знакомство с gitolite

gitolite — это средство для создания централизованных репозиториев для совместной разработки через git.

Зачем оно нужно?


Родные средства git для этой задачи на сегодня явно недостаточны: родной git-протокол не содержит каких-либо средств авторизации, а для работы через ssh потребуется завести полноценного юзера в ОС (с шеллом), что далеко не всегда уместно и желательно.
gitolite же позволит вам заводить пользователей независимо от наличия аккаунта в ОС и гибко раздавать права.


Пресуппозиции


  • Тема большая. Следовательно, описаны далеко не все возможности.
  • В своей документации разработчик gitolite ссылается на огромное количество проблем, которые возникают от недостаточного понимания принципов работы с ssh с аутентификацией через публичные ключи. Поэтому если вы несколько «плаваете» в этом вопросе — в конце статьи есть небольшое howto.
  • В статье подразумевается, что сервер, предназначенный для установки gitolite, работает на unix-like системе


Установка


На самом деле в большинстве случаев установка не вызывает каких-либо вопросов.
На сервере:
  • Заводим в системе нового пользователя. Для удобства назовем его git.
  • Копируем публичный ключ пользователя, который будет администратором, в домашнюю папку пользователя git. Обратите внимание, что имя ключа должны быть формата .pub, где — это то, как вас будет знать gitolite. Это имя может не совпадать с каким-либо системным. Если мы хотим, чтобы gitolite знал нас как gitadmin, то файл с ключем должен быть переименован в gitadmin.pub
    Логинимся под пользователем git и устанавливаем gitolite:
    su git
    cd ~
    git clone git://github.com/sitaramc/gitolite
    gitolite/src/gl-system-install
    gl-setup -q ~/gitadmin.pub
    




    Настройка


    Особенность настройки gitolite заключается в том, что почти никакие операции по его настройке НЕ производятся напрямую на сервере. Чтобы добавить нового пользователя, репозиторий или изменить права доступа надо сделать git clone специального gitolite-admin репозитория, внести изменения и сделать git push. Дело в том, что gitolite использует целую систему хуков, чтобы эти изменения вступили в силу.
    Итак, чтобы создать новый репозиторий и добавить нужных пользователей потребуется:
    • Из-под пользователя, публичный ключ которого был добавлен в gitolite при его установке (или любого другого пользователя, обладающего достаточными правами на репозиторий gitolite-admin) исполняем:
      git clone git@server:gitolite-admin
      

      Это, соответственно, создаст в текущей папке копию админ-репозитория. Он представляет собой две папки: conf и keydir. В папке conf хранится файл gitolite.conf, содержащий список репозиториев и прав доступа к ним. В папке keydir — публичные ключи пользователей, про которых должен знать gitolite.
    • Чтобы добавить нового пользователя просто записываем его публичный ключ в папку keydir. Имя ключа до окончания .pub будет являться именем пользователя в системе gitolite. Примеры: user1.pub или john-smith.pub. В имени допустимы символы точки и подчеркивания.
    • Чтобы добавить репозиторий и изменить права редактируем файл conf/gitolite.conf. Исходно он выглядит так:
      repo    gitolite-admin
              RW+     =   gitadmin
      
      repo    testing
              RW+     =   @all
      

      Добавим строчки:
      repo    megaproject
              RW+     =   gitadmin user1 john-smith
      

      Эти строчки описывают новый репозиторий megaproject, права на который имеют пользователи gitadmin, user1, john-smith.
    • После чего применяем и отправляем все изменения:
      git add .
      git commit -a -m "New repo and users added"
      git push
      


    Несколько слов о формате конфиг-файла:
    • Существует возможность использовать группы. Причем как для пользователей, так и для репозиториев. Пример:
      @oss_repos  =   gitolite linux git perl rakudo entrans vkc
      @staff      =   sitaram some_dev another-dev
      

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



    Работаем с вновь созданным репозиторием


    Собственно, работа с gitolite с точки зрения пользователя совершенно традиционна. Следуя нашему примеру, разработчик может исполнить команды:
    git clone git@server:megaproject
    cd megaproject
    touch newfile
    git add . 
    git commit -a -m "newfile"
    git push git@server:megaproject master
    


    ssh — аутентификация через публичный ключ


    Как вы, возможно, знаете, в ssh помимо традиционной аутентификации по паролю существует возможность пройти оную с использованием пары ключей. Аутентификация через публичный ключ — это когда вы генерируете пару ключей и отдаете публичный ключ на тот хост, который должен вас узнавать. После этого через ssh можно входить на удаленную машину не вводя пароль.
    Чтобы сгенерировать пару ключей для своего пользователя исполните
    ssh-keygen -t rsa
    Эта команда создаст в папке ~/.ssh два файла: id_rsa и id_rsa.pub. Первый — это частный ключ, который следует хранить как зеницу ока, а второй (с расширением .pub) — это публичный ключ, который и нужно передавать на удаленный хост. На самом деле внутри этого файла просто одна длинная текстовая строка, которую можно передать просто как текст.
    А на машине, доступ к которой требуется предоставить, необходимо внести указанный ключ в файлик ~/.ssh/authorized_keys того пользователя, доступ под которым необходимо организовать.

    gitolite — принцип работы


    Это для тех, кому интересно, как оно вообще устроено. Собственно, как уже понятно из описания, gitolite работает поверх ssh с использованием аутентификации через public-key (точнее, это наиболее популярная конфигурация).

    На сервере заводится единственный реальный пользователь, через которого будет происходить работа с репозиториями. А «магия» gitolite заключается в том, что в authorized_keys эти ключики попадают с опцией «command=[path]/gl-auth-command ...». Эта опция предписывает ssh-серверу запускать указанную команду независимо от того, что реально хотел исполнить юзер. При этом оригинальная команда сохраняется в переменной SSH_ORIGINAL_COMMAND, которую и считывает gitolite, чтобы узнать, что от него хотели.
Поделиться публикацией
Похожие публикации
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 22
    +1
    В чем преимущества по сравнению с gitosis? Просто я использую последний и не вижу у gitolite каких-либо преимуществ.
      +2
      Разработка gitosis давно закончена и сам по себе он имеет несколько уязвимостей(по слухам).

      А gitolite очень активно разрабатывается(на github) и изменений происходит очень и очень много.
        0
        gitolite проще настраивать (субъективно), я пробовал оба
        0
        основные отличия это более гибкая настройка прав доступа даже к веткам
        +4
        Жаль, что в статье не описано главное преимущество gitolite — возможность раздавать права доступа к веткам, тегам и т.д.
          +2
          Вот на этом месте хотелось бы поподробнее.
            0
            Хм… отвечал вроде вам, а коммент куда-то улетел
            посмотрите ниже
          +2
          Ну примерно так:

          @owners = vova dima

          @admins = @owners vasya petya

          @gitusers = @owners glash klasha mdprokhorov

          # gitolite-admin

          repo gitolite-admin
          RW+ = @admins

          repo russia/moscow
          RW+ sortir/ = adudaev
          RW+ = @owners seriozha

          repo russia/piter
          RW+ = @owners @admins



          Вроде все понятно в конфиге при этом :)
          Конфиг писал конечно же из головы и по памяти, лучше почитайте документацию, а не настраивайте, как я ;)
            0
            >>Конфиг писал конечно же из головы и по памяти
            было бы странно увидеть такой конфиг в продакшене :)
            0
            … а для работы через ssh потребуется завести полноценного юзера в ОС (с шеллом), что далеко не всегда уместно и желательно.


            для этого есть специальный git-shell (который идет из коробки)
            т.е. для случая когда у команды нет разграничений доступа к отдельным репозиториям — можно создать пользователя с шеллом=git-shell, а авторизацию для членов команды на ssh ключах
              0
              Кстати, gitolite мы для себя поднимали для того, чтобы вести совместную разработку веб-сайта.
              Причем, разумеется, нам хотелось, чтобы каждый push в центральный репозиторий обновлял webroot разрабатываемого сайта.
              И все было бы хорошо, но git не сохраняет исходных прав на файлы.

              Поэтому мы для себя сделали хитрый скрипт, который разбирает загружаемые файлики и интеллектуально выставляет права, максимально похожие на правильные.
              Если кому-то интересно — могу опубликовать как топик.

              Не исключено, что кто-то знает совсем красивое решение. Коли так — буду рад прочитать :)
                0
                git отлично сохраняет права на файлы, проблема видимо была в чём-то ещё, опишите
                  0
                  Не сохраняет.
                  Даже в официальной доке написано, что git обращает внимание только на executable bit:
                  Note that the files all have mode 644 or 755: git actually only pays attention to the executable bit.

                  Попробуйте сделать с исходной папки git push, а потом в новую git clone — права внутри папок будут разные.
                    0
                    да, извиняюсь, обратил внимание только на исполняемость
                  0
                  Совсем красивое решение — это любой deployment инструмент (Capistrano?). В задачи VCS входит отслеживание изменений в исходном коде. Весь процесс развертывания сайтов гораздо лучше описывается в интрументах, предназначенных для этого.
                  0
                  У gitolite плохо что нужен центральный суперадмин чтобы управлять доступом ко всем репозиториям. Не подходит для тех случаев когда нужно чтобы отдельные пользователи могли управлять правами доступа на те репозитории, которыми они владеют.
                  0
                  В документации говорят что можно передать права управления группой репозиториев кокретному пользователю.
                    0
                    Посту не хватает буквально пары полезных команд:
                    (предположим ваш паблик-кей уже добавлен владельцем репы в папку с ключами и вам прописаны права в gitolite.conf)

                    Добавить удалённый репозиторий:
                    git remote add repoholdername git@server.com:project.git
                    

                    После данной операции команда
                    ~> git remote show

                    выдаст примерно
                    
                    origin*
                    repoholdername

                    и у вас появляется возможность затягивать и пушить ветки минуя origin таким образом:
                    
                    ~> git fetch repoholder branchname
                    ~> git push repoholder branchname
                    

                    В общем и целом gitolite весьма удобен если разработчикам необходим обмен ветками до пуша на корпоративный ориджин или гитхаб.
                    Зачем это нужно? Например над проектом работает несколько групп по несколько человек, в таком случае для минимума конфликтов мерджит изменения тимлидер, затем сливает изменения с ориджином и возможно деплоит на стэйдж.
                    gitolite можно поднять на том-же vds сервере где хостится стейдж например, что позволит гибко распределять права доступа и сведёт к минимуму краши стэйджа в рамках одного root'а.
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Хороший пост, чтобы быстро разобраться в gitolite. Спасибо.
                          0
                          Если знаете — напишите как админа восстановить, если случайно удалили ему доступ. Мучаюсь уже час…

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

                          Самое читаемое