В этом разделе мы вкратце рассмотрим Gitolite, научимся его
устанавливать и настраивать. Gitolite представляет собой дополнительную
прослойку поверх Git'а, обеспечивающую широкие возможности по управлению
правами доступа. Gitolite для авторизации использует sshd или httpd.
Gitolite даёт возможность назначать права доступа не только для всего репозитория, но и для отдельных веток или имён меток внутри любого репозитория. То есть вы можете указать, что определённые люди (или группы людей) могут отправлять (push) определённые "ссылки" (ветки или метки), а остальные нет.
Установить Gitolite очень просто, даже не читая идущую с ним обширную
документацию. Вам понадобится аккаунт на сервере с каким-нибудь
Unix'ом. Вам не нужен root-доступ, если Git, Perl и OpenSSH-совместимый
SSH-сервер уже установлены. Далее в примерах мы будем использовать
аккаунт git на хосте с именем gitserver.
Gitolite несколько необычен, по крайней мере, в сравнении с другим "серверным" ПО — доступ осуществляется по SSH, и, следовательно, каждый пользователь на сервере является потенциальным "gitolite-хостом". В этом разделе мы рассмотрим самый простой метод установки; про остальные методы можно прочитать в документации.
Для начала, создайте пользователя с именем git на своём сервере и войдите в систему под этим пользователем. Скопируйте свой открытый ключ (это файл ~/.ssh/id_rsa.pub, если вы сгенерировали его с помощью просто ssh-keygen без изменения параметров) со своего рабочего компьютера и переименуйте его в <вашеимя>.pub (в нашем примере это будет файл scott.pub). Затем выполните следующие команды:
$ git clone git://github.com/sitaramc/gitolite
$ gitolite/install -ln
# предполагает, что $HOME/bin существует и находится в $PATH
$ gitolite setup -pk $HOME/scott.pub
Последняя из команд создаст на сервере новый Git-репозиторий с именем gitolite-admin.
В завершение, вернитесь на свой рабочий компьютер и выполните там git clone git@gitserver:gitolite-admin. И всё! Gitolite теперь установлен на сервере, а на вашей рабочей станции теперь есть новый репозиторий, который называется gitolite-admin. Администрировать свой установленный Gitolite нужно, внося изменения в этот репозиторий и отправляя их на сервер.
Хотя быстрая установка с параметрами по умолчанию подходит для
большинства людей, есть несколько способов изменения параметров
установки, если вам это нужно. Если опустить опцию -q, вы
получите "подробную" установку с детальной информацией о том, что
происходит на каждом шаге. Подробный режим также позволяет изменить
некоторые параметры на стороне сервера такие, как расположение
репозиториев, с помощью редактирования "rc" файла, используемого
сервером. Этот "rc" файл содержит развёрнутые комментарии так, чтобы вы
легко смогли сделать любые изменения, сохранить их и продолжить. Этот
файл также содержит различные настройки, которые вы можете изменить,
чтобы активировать или выключить некоторые "продвинутые" функции
Gitolite'а.
Теперь, когда установка завершена, перейдите в клон репозитория gitolite-admin на вашем рабочем компьютере и осмотритесь, чтобы выяснить, что же вы получили:
$ cd ~/gitolite-admin/
$ ls
conf/ keydir/
$ find conf keydir -type f
conf/gitolite.conf
keydir/scott.pub
$ cat conf/gitolite.conf
repo gitolite-admin
RW+ = scott
repo testing
RW+ = @all
Заметьте, что "scott" (имя файла открытого ключа, использовавшееся ранее при запуске команды gitolite setup) имеет права на чтение и запись в репозиторий gitolite-admin, а также файл с открытым ключом с таким же именем.
Добавить нового пользователя просто. Чтобы добавить пользователя "alice", возьмите её ключ, переименуйте его в alice.pub и положите в каталог keydir клона репозитория gitolite-admin на вашем компьютере. Выполните add, commit, отправьте изменения, и пользователь добавлен.
Синтаксис конфигурационного файла для Gitolite'а подробно продокументирован, так что мы рассмотрим здесь только основные моменты.
Вы можете сгруппировать пользователей или репозитории для удобства. Имена групп совсем как макросы; когда вы их определяете, даже неважно, определяют ли они проекты или пользователей; это различие делается, только когда вы используете "макрос".
@oss_repos = linux perl rakudo git gitolite
@secret_repos = fenestra pear
@admins = scott
@interns = ashok
@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, не совпадёт с первыми двумя правилами, а третье правило его разрешает.
Вдобавок к ограничению веток, в которые пользователю можно отправлять изменения, вы можете также ограничить файлы, которые он может трогать. Например, возможно, Makefile (или какая-то другая программа) не предназначен для изменения кем угодно, так как многие вещи зависят от него или сломаются, если изменения не будут сделаны правильно. Вы можете сказать Gitolite'у:
repo foo
RW = @junior_devs @senior_devs
- VREF/NAME/Makefile = @junior_devs
Стоит предостеречь тех, кто пользовался старыми версиями Gitolite'а, о том, что в новых версиях поведение этой функции было сильно изменено. Подробнее об этих изменениях можно узнать в руководстве по миграции.
Gitolite также имеет средство, которое называется "персональные ветки" (или даже "персональное пространство имён веток"), которое может быть весьма полезным в корпоративных средах.
Очень часто обмен кодом в мире Git'а происходит через запросы "пожалуйста, заберите (pull)". В корпоративных средах, однако, неаутентифицированный доступ под строгим запретом, и рабочая станция разработчика не может выполнить аутентификацию. Так что вы вынуждены отправить (push) работу на центральный сервер и попросить кого-нибудь забрать (pull) её оттуда.
Это обычно вызывает такой же беспорядок с именами веток, что и в централизованных СКВ, плюс настройка прав доступа для этого становится ежедневной обязанностью админа.
Gitolite позволяет определить "персональный" или "рабочий" префикс пространства имён для каждого разработчика (например, refs/personal/<devname>/*); подробное описание этой функциональности есть в документации.
Gitolite позволяет указывать репозитории с помощью шаблонов (на самом деле регулярных выражений Perl'а), таких как, например, assignments/s[0-9][0-9]/a[0-9][0-9]. Это позволяет назначать новый режим доступа (C),
который позволяет пользователям создавать репозитории на основе
подобных шаблонов, автоматически назначает владельцем пользователя,
который создал репозиторий, позволяет ему раздавать R и RW права другим пользователям и т.п.
Мы закончим это обсуждение рассмотрением подборки других функций, все они и многие другие описаны в мельчайших подробностях в документации.
Логирование: Gitolite регистрирует все успешные действия. Если вы несколько легкомысленно раздали людям права на откатывание изменений (RW+) и кто-то снёс master, лог-файл спасёт вам жизнь, и вы легко и быстро найдёте потерянный SHA.
Уведомление о правах доступа: Другая удобная функция проявляется в момент, когда вы просто проверяете и заходите по ssh на сервер. Gitolite показывает, к каким репозиториям у вас есть доступ и какого типа доступ может быть получен. Вот пример:
hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
R anu-wsd
R entrans
R W git-notes
R W gitolite
R W gitolite-admin
R indic_web_input
R shreelipi_converter
Делегирование: При действительно больших установках вы можете делегировать ответственность за группы репозиториев различным людям, которые будут независимо управлять этими частями. Это уменьшает нагрузку на главного админа и делает его не таким критичным элементом.
Зеркалирование: Gitolite может помочь вам поддерживать несколько зеркал, и легко переключаться между ними, если основной сервер упадёт.
prev | next