Gitolite

Git начал становиться очень популярным в корпоративных средах, где обычно есть дополнительные требования в плане контроля доступа. Gitolite изначально был создан, чтобы посодействовать в выполнении таких требований. Но как оказывается он так же полезен и в мире open source: проект Fedora управляет доступом к своим репозиториям пакетов с помощью gitolite. А ведь этих репозиториев больше 10 000! По видимому это самая большая установка gitolite где бы то ни было. Gitolite позволяет указать права доступа не только для репозиториев, но и для веток или имён меток внутри каждого репозитория. То есть, вы можете указать, что определённые люди (или группы людей) могут отправлять (push) определённые “ссылки” (ветки или метки), а остальные нет.

Установка

Установить Gitolite очень просто, даже если вы не читали обширную документацию, которая идёт вместе с ним. Вам нужен аккаунт на каком-нибудь Unix сервере; были протестированы различные Linux-ы и Solaris 10. Вам не нужен root-доступ, если git, perl и openssh-совместимый сервер уже настроены. Далее в примерах мы будем использовать аккаунт gitolite на хосте с именем gitserver. Gitolite несколько необычен, по крайней мере, в сравнении с другим “серверным” ПО — доступ осуществляется по ssh, и следовательно каждый пользователь на сервере является потенциальным “gitolite-хостом”. Поэтому всё выглядит как “установка” самого ПО и затем “настройка” пользователя как “gitolite-хоста”. Gitolite может быть установлен четырьмя способами. Люди, использующие Fedora’у или Debian, могут получить RPM или DEB и установить его. Те, у кого есть root-доступ, могут сделать установку вручную. В обоих вариантах любой пользователь в системе затем может стать “gitolite-хостом”. Те, у кого нет root-доступа, могут установить его внутрь своих каталогов. И наконец, gitolite может быть установлен с помощью выполнения сценария на рабочей станции в bash-шелле. (Если вам интересно, даже тот bash, который идёт с msysgit, достаточен.) Последний способ мы опишем в этой статье; а остальные методы описаны в документации. Начните с настройки доступа к вашему серверу с помощью открытого ключа, так, чтобы вы могли войти с вашей рабочей станции на сервер без ввода пароля. Следующий способ работает в Linux; для рабочих станций с другими ОС вам, возможно, нужно будет сделать это вручную. Мы полагаем, что у вас уже есть пара ключей сгенерированных с помощью ssh-keygen.


$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver

Эта команда спросит у вас пароль к учётной записи ‘gitolite’, а затем настроит доступ по открытому ключу. Он необходим для сценария установки, так что убедитесь, что вы можете выполнять команды без ввода пароля:


$ ssh gitolite@gitserver pwd
/home/gitolite

Затем склонируйте Gitolite с главного сайта проекта и выполните сценарий для лёгкой установки (третий аргумент это ваше имя в том виде, в котором вам бы хотелось его видеть в окончательном репозитории gitolite-admin):


$ git clone git://github.com/sitaramc/gitolite
$ cd gitolite/src
$ ./gl-easy-install -q gitolite gitserver sitaram

Всё готово! Gitolite теперь установлен на сервере, и у вас в вашей домашней директории на рабочей станции теперь есть новый репозиторий, который называется gitolite-admin. Администрирование вашего установленного gitolite осуществляется с помощью внесения изменений в этот репозиторий и их отправки (push). Та последняя команда делает довольно большое количество вывода, который может быть интересно прочитать. Также, при первом её выполнении, создаётся новая пара ключей; вам придётся выбрать пароль или нажать enter, чтобы пароля не было. Зачем нужна вторая пара ключей и как она используется, описано в документе “ssh troubleshooting” поставляемым с Gitolite. (Ну должна же документация быть хоть для чего-то хороша!) По умолчанию на сервере создаются репозитории с именами gitolite-admin и testing. Если вы хотите получить локальную копию какого-то из них, наберите (под учётной записью, которая имеет консольный SSH-доступ к gitolite-аккаунту в authorized_keys):


$ git clone gitolite:gitolite-admin
$ git clone gitolite:testing

Чтобы склонировать эти же самые репозитории под любым другим аккаунтом:


$ git clone gitolite@servername:gitolite-admin
$ git clone gitolite@servername:testing

Изменение параметров установки

Хотя быстрая установка с параметрами по умолчанию подходит для большинства людей, есть несколько способов изменения параметров установки если вам это нужно. Если опустить опцию -q, вы получите “подробную” установку с детальной информацией о том, что происходит на каждом шаге. Подробный режим также позволяет изменить некоторые параметры на стороне сервера, такие как расположение репозиториев, с помощью редактирования “rc” файла используемого сервером. Этот “rc” файл содержит развёрнутые комментарии так, чтобы вы легко смогли сделать любые изменения, сохранить их и продолжить. Этот файл также содержит различные настройки, которые вы можете изменить, чтобы активировать или выключить некоторые “продвинутые” функции gitolite.

Конфигурационный файл и правила контроля доступа

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


$ cd ~/gitolite-admin/
$ ls
conf/ keydir/
$ find conf keydir -type f
conf/gitolite.conf
keydir/sitaram.pub
$ cat conf/gitolite.conf
#gitolite conf
# please see conf/example.conf for details on syntax and features

repo gitolite-admin
 RW+ = sitaram

repo testing
 RW+ = @all

Заметьте, что “sitaram” (это последний аргумент при выполнении gl-easy-install ранее) имеет права на чтение и запись в репозиторий gitolite-admin, а также файл с открытым ключом с таким же именем. Синтаксис конфигурационного файла для gitolite подробно продокументирован в conf/example.conf, так что мы рассмотрим здесь только основные моменты. Вы можете сгруппировать пользователей или репозитории для удобства. Имена групп совсем как макросы; когда вы их определяете, даже не важно определяют ли они проекты или пользователей; это различие делается только, когда вы используете “макрос”:


@oss_repos = linux perl rakudo git gitolite
@secret_repos = fenestra pear

@admins = scott # Adams, not Chacon, sorry :)
@interns = ashok # get the spelling right, Scott!
@engineers = sitaram dilbert wally alice
@staff = @admins @engineers @interns

Вы можете контролировать права доступа на уровне “ссылок” (то, что находится в .git/refs/). В следующем примере стажёры (группа @interns) могут отправлять (push) только ветку “int”. Инженеры (группа @engineers) могут отправлять любую ветку, чьё имя начинается с “eng“, а также метки начинающиеся с “rc” и затем цифры. И администраторы (группа @admins) могут делать всё (в том числе откатить назад) с любыми ссылками.


repo @oss_repos
 RW int$ = @interns
 RW eng- = @engineers
 RW refs/tags/rc[0-9] = @engineers
 RW+ = @admins

Выражение после RW или RW+ это регулярное выражение (regex), с которым сопоставляется имя отправляемой ссылки (ref). Поэтому мы называем его “refex”! Конечно, “refex” может быть гораздо более сильным, чем показанные здесь. Так что не переусердствуйте с ними, если вы не очень хорошо знакомы с регулярными выражениями perl. К тому же, как вы уже, наверное, догадались, Gitolite для удобства дописывает в начале регулярного выражения refs/heads/ если оно не начинается с refs/. Важной особенностью синтаксиса конфигурационного файла является то, что все правила для репозитория не обязательно должны находиться в одном месте. Вы можете держать все общие вещи вместе, как, например, правила для всех oss_repos выше, а потом добавить уточняющие правила для отдельных случаев следующим образом:


repo gitolite
 RW+ = sitaram

Это правило будет добавлено к набору правил для репозитория gitolite. В данный момент вы, возможно, задаётесь вопросом: “Каким образом правила контроля доступа применяются на самом деле?” — так что давайте вкратце рассмотрим это. В gitolite есть два уровня контроля доступа. Первый — на уровне репозитория; если у вас есть доступ на чтение (или запись) к любой ссылке в репозитории, то у вас есть доступ на чтение (или запись) к этому репозиторию. Второй уровень применим только к доступу на запись и осуществляется по веткам или меткам внутри репозитория. Имя пользователя, запрашиваемый уровень доступа (W или +) и имя ссылки, которая будет обновлена, известны. Правила доступа проверяются в порядке их появления в конфигурационном файле, в поисках совпадений для этой комбинации (но помните, что имя ссылки сопоставляется с регулярным выражением, а не просто строкой). Если совпадение найдено, отправка (push) проходит успешно. При неудачном исходе доступ запрещается.

Продвинутый контроль доступа с запрещающими правилами

До сих пор у нас были только права вида R, RW, или RW+. Однако, в gitolite есть другие права доступа: - означающий “запретить”. Это даёт гораздо больше возможностей взамен большей сложности, так как теперь отсутствие разрешающего правила не единственный способ получить запрет доступа, так что порядок правил теперь имеет значение! Предположим, в описанной выше ситуации мы хотим, чтобы инженеры могли откатить назад любую ветку кроме master и integ. Вот как это сделать:


 RW master integ = @engineers
 - master integ = @engineers
 RW+ = @engineers

Снова, вы просто идёте по правилам сверху вниз пока не наткнётесь на соответствующее вашему режиму доступа или на запрет. Неоткатывающий push в master или integ разрешается первым правилом. Откатывающий push для этих ссылок не соответствует первому правилу, переходит ко второму и поэтому запрещается. Любой push (откатывающий или неоткатывающий) по ссылкам отличным от master и integ не совпадёт с первыми двумя правилами, а третье правило его разрешает.

Ограничение `push`-ей на основе изменённых файлов

Вдобавок к ограничению веток, в которые пользователю можно отправлять изменения, вы можете также ограничить файлы, которые он может трогать. Например, возможно, Makefile (или какая-то другая программа) не предназначен для изменения кем угодно, так как многие вещи зависят от него или сломаются, если изменения не будут сделаны правильно. Вы можете сказать gitolite-у:


repo foo
 RW = @junior_devs @senior_devs

 RW NAME/ = @senior_devs
 - NAME/Makefile = @junior_devs
 RW NAME/ = @junior_devs

Это мощное средство продокументировано в conf/example.conf.

Персональные ветки

Gitolite также имеет средство, которое называется “персональные ветки” (или даже “персональное пространство имён веток”), которое может быть весьма полезным в корпоративных средах. Очень часто обмен кодом в мире git происходит через запросы “пожалуйста, заберите (pull)”. В корпоративных средах, однако, неаутентифицированный доступ под строгим запретом, и рабочая станция разработчика не может выполнить аутентификацию. Так что вы вынуждены отправить (push) работу на центральный сервер и попросить кого-нибудь забрать (pull) её оттуда. Это обычно вызывает такой же беспорядок с именами веток, что и в централизованных СУВ, плюс настройка прав доступа для этого становится ежедневной обязанностью админа. Gitolite позволяет определить “персональный” или “рабочий” префикс пространства имён для каждого разработчика (например, refs/personal/devname/*); подробное описание есть в разделе “personal branches” в doc/3-faq-tips-etc.mkd.

“Шаблонные” репозитории

Gitolite позволяет указывать репозитории с помощью шаблонов (на самом деле регулярных выражений perl), таких как, например, assignments/s[0-9][0-9]/a[0-9][0-9]. Это очень мощная функция, которая включается с помощью установки $GL_WILDREPOS = 1; в rc файле. Она позволяет назначать новый режим доступа (”C”), который позволяет пользователям создавать репозитории на основе подобных шаблонов, автоматически назначает владельцем пользователя, который создал репозиторий, позволяет ему раздавать R и RW права другим пользователям и т.п. Эта функция описана в документе doc/4-wildcard-repositories.mkd.

Другие функции

Мы закончим это обсуждение рассмотрением подборки других функций, все они и многие другие описаны в мельчайших подробностях в документе “faqs, tips, etc” и некоторых других.

Логирование

Gitolite регистрирует все успешные доступы. Если вы несколько легкомысленно раздали людям права на откатывание изменений (RW+) и кто-то удалил “master”, лог-файл спасёт вам жизнь, и вы легко и быстро найдёте утерянный SHA.

Git не в обычном PATH

Одна крайне полезная и удобная функция в gitolite это поддержка git установленного вне обычного $PATH (это совсем не такая редкость как вы думаете; в некоторых корпоративных средах или даже у некоторых хостинг-провайдеров отказываются устанавливать что-либо в систему и всё заканчивается тем, что вы кладёте всё в свои личные директории). Обычно, вы вынуждены каким-то образом заставить git на стороне клиента учитывать это нестандартное расположение бинарников git-а. С gitolite, просто выберите “подробную” установку и задайте $GIT_PATH в “rc” файлах. Никаких изменений на стороне клиента после этого не требуется:-)

Уведомление о правах доступа

Другая удобная функция проявляется в момент, когда вы просто проверяете и заходите по ssh на сервер. Gitolite показывает к каким репозиториям у вас есть доступ и какого типа доступ может быть получен. Вот пример:


 hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
 the gitolite config gives you the following access:
 R anu-wsd
 R entrans
 R W git-notes
 R W gitolite
 R W gitolite-admin
 R indic_web_input
 R shreelipi_converter

Делегирование

При действительно больших установках, вы можете делегировать ответственность за группы репозиториев различным людям, которые будут независимо управлять этими частями. Это уменьшает нагрузку на главного админа и делает его не таким критичным элементом. Эта функция описана в отдельном файле в каталоге doc/.

Поддержка Gitweb

Gitolite имеет поддержку gitweb в нескольких аспектах. Вы можете указать какие репозитории видны через gitweb. Вы можете назначить “владельца” и “описание” для gitweb из конфигурационного файла для gitolite. В gitweb есть механизм организации контроля доступа через аутентификацию по HTTP, и вы можете заставить его использовать “скомпилированный” конфигурационный файл сделанный gitolite-ом, что означает действие одинаковых правил контроля доступа (для доступа на чтение) и для gitweb, и для gitolite.

Зеркалирование

Gitolite может помочь вам поддерживать несколько зеркал, и легко переключаться между ними, если основной сервер упадёт. Pro Git