Описание тега gitolite

Gitolite позволяет использовать одного пользователя на сервере для размещения множества репозиториев git и предоставления доступа многим разработчикам без необходимости предоставления им реальных идентификаторов пользователя или доступа к оболочке на сервере. Основное волшебство в этом - доступ через ssh к pubkey и файл author_keys, а источником вдохновения стала старая программа под названием gitosis.

Gitolite может ограничивать тех, кто может читать (клонировать / извлекать) или писать (выдвигать) репозиторий. Он также может ограничивать, кто может подтолкнуть к какой ветви или тегу, что очень важно в корпоративной среде. Gitolite может быть установлен без рут-прав и без дополнительного программного обеспечения, кроме самого git и perl. Он также имеет несколько других полезных функций, описанных ниже и в других местах в каталоге doc/.

Gitolite отделен от git и должен быть установлен и настроен. Итак... почему мы беспокоимся?

Gitolite полезен на любом сервере, где будет размещаться несколько git -репозиториев, в каждом из которых много разработчиков, где требуется какой-то контроль доступа.

Теоретически это может быть сделано с простыми старыми разрешениями Unix: каждый пользователь является членом одной или нескольких групп, каждая группа "владеет" одним или несколькими репозиториями и использует разрешения unix (особенно бит setgid - chmod g + s) Вы можете разрешить / запретить пользователям доступ к репозиториям.

Но здесь есть несколько недостатков:

• каждому пользователю нужен идентификатор пользователя и пароль на сервере. Это обычно убийца, особенно в жестко контролируемых условиях
• добавление / удаление прав доступа включает в себя сложные бормотания usermod -G ..., с которыми большинство администраторов не хотели бы иметь дело
• просмотр (или аудит) текущего набора разрешений требует запуска нескольких команд для вывода списка каталогов и их разрешений / владельцев, пользователей и их членства в группах, а затем сопоставления всех их вручную
• аудит исторических разрешений или изменений разрешений практически невозможен без посторонних инструментов
• ошибки или упущения в точной настройке разрешений могут вызвать проблемы любого рода: ложное принятие или ложное отклонение
• не входя в ACL, невозможно предоставить кому-либо доступ только для чтения к репо; они либо получают доступ для чтения и записи, либо не имеют доступа
• абсолютно невозможно ограничить отправку по имени ветви или имени тега.

Гитолит покончил со всем этим:

• он использует магию ssh, чтобы избавить разработчиков от необходимости предоставлять фактические идентификаторы пользователей Unix
• он использует простой, но мощный формат файла конфигурации для определения прав доступа
• На изменения управления доступом влияют изменение этого файла, добавление или удаление открытых ключей пользователя и "компиляция" конфигурации.
• это также делает аудит тривиальным - все данные находятся в одном месте, и изменения в конфигурации также регистрируются, так что вы можете проводить их аудит.
• наконец, файл конфигурации позволяет различать доступ только для чтения и доступ для чтения и записи не только на уровне репозитория, но и на уровне ветвления в репозиториях.

Основные характеристики

Самая важная функция, которая мне была нужна, была разрешения для каждой ветви. Это в значительной степени обязательно в корпоративной среде, и это почти единственная причина, по которой я начал думать о написании gitolite.

Это не просто "только чтение" против "чтение-запись". Перематывание ветки (также называемое "без ускоренной перемотки вперед") потенциально опасно, но иногда необходимо. То же самое относится и к удалению ветки (что на самом деле просто крайняя форма перемотки). Мне нужно было что-то среднее между тем, чтобы кто-нибудь мог сделать это (по умолчанию) и полностью отключить его (receive.denyNonFastForwards или receive.denyDeletes).

Некоторые дополнительные функции - все они и многое другое подробно описаны где-то в подкаталоге dit / gitolite:

• простой, но мощный синтаксис файла конфигурации, включая указание доступа к gitweb / daemon. Эта возможность понадобится вам, если вы управляете множеством пользователей + репозитории + комбинации доступа
• Помимо ограничений, основанных на имени ветви, вы также можете ограничить изменением имени файла / каталога (т. е. вывод команды git diff - name-only)
• если ваши требования все еще слишком сложны, вы можете разделить файл конфигурации и делегировать полномочия на его части
• легко указать владельца gitweb, описание и доступ к gitweb / daemon
• простая синхронизация gitweb (http) авторизации с конфигурацией доступа gitolite
• комплексное ведение журнала [aka: руководство не считает, что "вина" - это просто синоним слова "аннотировать":-)]
• префикс "личное пространство имен" для каждого разработчика
• руководство по миграции и простой конвертер для файла Gitosis Conf
• "исключить" (или "отказать") права на уровне ветви / тега
• указывайте репо с использованием шаблонов (шаблоны могут включать имя создателя)
• определять мощные операции на стороне сервера, даже github-подобные разветвления

Служба поддержки

Большинство проблем с установкой вызвано незнанием ssh. Взгляните на эту стенограмму, чтобы увидеть, насколько она проста, если демон ssh вашего сервера ведет себя сам. Кто-то также написал учебник, смотрите здесь.

Если я подозреваю, что ваша проблема связана с ssh, я, вероятно, проигнорирую ее. Пожалуйста, узнайте, как Gitolite использует SSH, а затем методично изучите документ по устранению неполадок SSH. Эти два документа содержат все, что я мог бы вам сказать. Мне нечего добавить.

Даже по другим темам, прежде чем задавать вопрос, просмотрите хотя бы оглавление хотя бы пронумерованных документов, чтобы убедиться, что на ваш вопрос уже дан ответ.

Безопасность

Из-за среды, в которой это было создано, и необходимости, которую он удовлетворяет, я считаю, что это программа "безопасности", хотя и очень скромная.

Для первого человека, который обнаружит в нем дыру в безопасности, определяемую как разрешение обычному пользователю (не администратору gitolite) читать репозиторий или писать / перематывать ссылку, которую файл конфигурации говорит, что он не должен, и вызванную ошибка в коде, который находится в ветви "master" (не в других ветках, или в файле конфигурации, или в Unix, perl, shell и т. д.).

Тем не менее, есть несколько дополнительных функций (которые должны быть явно включены в файле RC), в которых у меня просто не было времени достаточно тщательно рассуждать о безопасности. Пожалуйста, прочитайте комментарии в conf / example.gitolite.rc для деталей, ища слово "безопасность".

Лицензия

Гитолит выпущен под лицензией GPL v2.