Размещение нескольких репозиториев (svn, hg, git)


8

Я недавно приобрел выделенный сервер, и мне нужно перенести на него несколько репозиториев из службы управления исходным кодом. Имея небольшой опыт администрирования серверов, я понятия не имею, как его эффективно организовать. Что я ищу -

  1. svn.host.com, hg.host.com, поддоменов git.host.com, которые будут корнями к различным репозиториям через ключи SSH
  2. простое создание новых репозиториев
  3. проверка подлинности с использованием списка пользователей unix сервера, но с разрешениями для каждого проекта, а также необязательный открытый доступ только для чтения для некоторых репозиториев

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

Какие-либо предложения, учебные пособия или письменные решения о том, где начать исследования? Решение с открытым исходным кодом для административного интерфейса для обработки этого (или, по крайней мере, для некоторых было бы идеально ...

Ответы:


6

Я использую только Git, поэтому постараюсь хотя бы помочь вам в этом:

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

Если вам действительно нужен веб-интерфейс, вы можете взглянуть на repo.or.cz ( http://repo.or.cz/w/girocco.git ) или gitorious ( http://gitorious.org/gitorious ). , Repo.or.cz более уродлив, но его проще установить (gitorious - это open-source, но это также и программное обеспечение для gitorious.org - у них нет особого стимула для написания хороших инструкций)

Вот более полный список параметров: https://git.wiki.kernel.org/index.php/GitHosting

Любой из этих вариантов позволит вам легко создавать новые репозитории.

Теперь одно слово предостережения: НИКОГДА не используйте список пользователей unix-сервера для разрешений хранилища. С ним достаточно легко связываться, а результаты легко катастрофические (gitosis использует простую конфигурацию файлов и ssh-ключи. Должен помочь вам).

Другое дело, я не понимаю, зачем вам нужны репозитории Subversion, HG и Git. Большинство проектов используют только один из этих вариантов. Хотите уточнить, почему?


У меня есть несколько проектов, состоявшихся в нескольких репозиториях. Многие коммитеры не особо разбираются в технологиях, поэтому hg и git будут для них проблемой, поэтому я оставляю svn для более открытых проектов. Лично я использую HG в качестве своего SCM выбора. Я также в гостях у меня несколько проектов для моих друзей, и некоторые из них используют git в качестве SCM по своему выбору. Нет способа угодить всем, как кажется :)
Kornel Kisielewicz

1
Кроме того, не могли бы вы подробнее рассказать об опасностях использования списка пользователей Unix для разрешений репо?
Корнел Киселевич

3
Почему использование списка пользователей Unix для репозиториев - плохая вещь: потеря детализации, потеря переносимости. Если вам нужно сменить репозитории на другой сервер, вам придется переместить весь список пользователей Unix. Если вы хотите делегировать права администратора, вы должны предоставить права root. Теперь, на Gitosis, если вы хотите сменить сервер, вам просто нужно клонировать репо. Если вы хотите делегировать права администратора, вам просто нужно добавить пользователя в группу gitosis-admin.
Тьяго Фассони

just_testing, согласовано, действительные баллы :)
Kornel Kisielewicz

2

SVN может быть выполнен с помощью Apache WebDAV, в vhost, с использованием аутентификации Unix и собственных ACL уровня пользователя subversion. Я ничего не знаю о mercurial или git, но я надеюсь, что их тоже можно подключить к DAV.


1

Если вы хотите использовать SSH , то вам нужно ограничить ключи, отредактировав authorized_keysфайл на сервере. Для Mercurial основные способы сделать это:

  • Вы можете использовать contrib/hg-sshскрипт для ограничения команд, которые люди могут выполнять при входе в систему по SSH. Файл содержит заголовок, чтобы объяснить, как его использовать, но вы в основном добавляете

    $ command="hg-ssh path/to/repo"
    

    перед ключом в authorized_keysфайле. Это ограничивает ключ, так что он может быть использован только для push и pull в указанное хранилище.

  • Вы также можете использовать сторонний инструмент mercurial-server , если вы хотите что-то вроде gitois . Это позволяет вам управлять пользователями и их правами доступа, редактируя файлы в специальном репозитории администратора.

См. Вики Mercurial для некоторых других подобных инструментов для SSH.

Для HTTP есть

  • Встроенный hgweb(быстрый) CGI или WSGI-скрипт, который поставляется с Mercurial. Это обрабатывает толчки и извлечения, но не позволяет создавать новые репозитории - для этого войдите на сервер.

  • Третья сторона RhodeCode проект. Это дает вам похожий на Bitbucket веб-интерфейс для Mercurial, где вы можете настраивать пользователей и их права доступа. Он поддерживает аутентификацию LDAP, поэтому вы можете подключить ее к существующей базе данных пользователей Unix.

См. Страницу по публикации репозиториев для получения дополнительной информации.


1

SCM-Manager может идеально подойти для ваших нужд:

Самый простой способ поделиться своими репозиториями Git, Mercurial и Subversion и управлять ими через http.

  • Очень простая установка
  • Не нужно взламывать файлы конфигурации, SCM-Manager полностью настраивается через веб-интерфейс
  • Нет Apache и не требуется установка базы данных
  • Центральное управление пользователями, группами и разрешениями
  • Встроенная поддержка Git, Mercurial и Subversion
  • Полный API веб-сервиса RESTFul (JSON и XML)
  • Богатый пользовательский интерфейс
  • Простой плагин API
  • Доступны полезные плагины (например, Ldap-, ActiveDirectory-, PAM-аутентификация)

0

RhodeCode - это браузер с открытым исходным кодом и инструмент управления хранилищем со встроенным сервером push-pull, LDAP / AD, системой разрешений и полнотекстовым поиском.

Вы можете увидеть это в прямом эфире здесь: http://demo.rhodecode.org/

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.