Решение сервера Git с использованием прав доступа к файлам

В моей компании есть куча репозиториев git в папке, доступ к которой осуществляется через наш домен Active Directory. До сих пор доступ к папке осуществлялся через smb с использованием аутентификации Kerberos, и все наши клиенты настроены с URL-адресами file://.

Это явно очень плохо. Я пытаюсь настроить нас с помощью правильного git-сервера либо через http, либо через ssh, но наш сетевой администратор очень ясно понимает, что любое решение, которое мы используем, должно поддерживать разрешения на основе группы активных каталогов (предпочтительно поддерживать разрешения на уровне файлов) , и что компания не желает платить за решение. К сожалению, эти требования немного связывают мне руки и не позволяют использовать проверенный и надежный пакет nginx git.

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

  • Обслуживание git через стандартный протокол (предпочтительно http/https/ssh) вместо файлового протокола
  • Аутентификация всех пользователей в Active Directory
  • Бесплатно (предпочтительно с открытым исходным кодом)
  • Работает на Windows (нашему сетевому администратору не нравится unix).
  • В идеале будет принимать билеты Kerberos, чтобы разрешить единый вход.
  • В идеале будет аутентифицировать пользователей по разрешениям папки репозитория вместо отдельной конфигурации разрешений на основе группы (сетевой администратор не хочет больше работать, поддерживая это).

[Редактировать: добавлено забытое требование относительно ОС]

[Редактировать год спустя]

Я оставляю этот вопрос здесь, потому что он получил несколько голосов, поэтому, очевидно, есть и другие люди, у которых были подобные потребности. Любые и все ответы, которые частично соответствуют этому списку, могут быть полезны будущим читателям. Мои собственные проблемы были решены благодаря тому, что мы наняли нового системного администратора, который не боится Linux, что дало мне возможность использовать гораздо больше возможностей.

[/Редактировать]

Возможно, это не заслуживает отдельного ответа, но Apache может размещать репозитории Git с включенными соответствующими расширениями. У него также есть модули для использования аутентификации Windows, и пока все бесплатно и с открытым исходным кодом, способным работать как по http, так и по https. Я не делал этого сам, но подробности смотрите здесь: jeremyskinner.co.uk/2010/07/31/…
Вы предложили альтернативу ликвидации всего прямого доступа к файлам репозитория git? У этого есть несколько преимуществ: 1) это снижает ваши требования к «должны интегрироваться с активным каталогом для пользователей» и 2) это заставляет всех отказаться от прямого доступа к файлам. Люди вряд ли откажутся от того, что, по их мнению, хорошо работает, если только их не заставят, и вы, кажется, единственный, кто достаточно заботится о том, чтобы это изменить. 3) Сетевому администратору больше не нужно поддерживать причудливые разрешения на папки для кучи репозиториев. Если все захотят, вы можете даже полностью лишить его разрешения на репо.
Вплоть до конца: «Мои собственные проблемы были решены благодаря тому, что мы наняли нового системного администратора, который не боится, что Linux освободит меня для использования многих других возможностей» — я собирался предложить просто попросить вашего парня-сервера пройти курс Linux или получить сертификат lpi.

Ответы (2)

Я рекомендую RhodeCode Enterprise ( https://rhodecode.com ), который выполняет все требования к разрешению папки, кроме требований. RhodeCode Enterprise 3 бесплатен для 10 пользователей и EDU и дополнительно поддерживает Mercurial и SVN.

Отказ от ответственности: я соучредитель RhodeCode.

К вашему сведению, сайт нигде не упоминает о доступности различных механизмов аутентификации. Кроме того, на сайте упоминается совместимость с Windows, но затем я загружаю, а совместимость с Windows находится в бета-версии. По этим причинам мне не нравится идея заниматься этим. Можете ли вы предоставить некоторую документацию о том, как я буду это настраивать (обратите внимание, что в настоящее время наш репозиторий находится на сервере Windows)
Свяжитесь с нами на веб-сайте, упомянув эту ветку, чтобы получить бета-доступ к нашему установщику Windows для RhodeCode Enterprise 3.

Во-первых, ваш системный администратор должен понимать, что центральное репо похоже на базу данных, поэтому права собственности на файлы не имеют значения. AD следует использовать только для аутентификации для доступа к данным, на самом деле лучше всего, чтобы данные управлялись демоном, который имеет единственный доступ к безголовому репо в этом центральном месте. Так это делается во всех системах, таких как gitlab, github, stash и т. д. На самом деле, вы можете установить stash или gitlab (с длинным списком преимуществ, помимо безопасности) и разрешить пользователям проходить аутентификацию в AD либо через LDAP. шлюз или напрямую. Atlassian Stash и Gitlab являются бесплатными вариантами (я думаю), есть также GitHub Enterprise и другие, а также несколько вариантов FOSS (хотя я не знаю об их вариантах интеграции с AD).

Я на 100% согласен с тем, что вы говорите, к сожалению, ваш ответ зависит от изменения мнения SA о вещах, на которые у меня нет ни времени с компанией, ни влияния на SA, чтобы сделать это. Gitlab был моим первым и предпочтительным вариантом, но мой SA отказывается от этого из-за отношения Gitlab к окнам (очень глупая причина, чтобы быть уверенным, но вы играете в карты, которые вам раздали). Кроме того, я достаточно изо всех сил пытался заставить эту компанию заплатить единовременную плату за некоторое программное обеспечение (по какой-то причине аппаратное обеспечение легко получить), и все предложения, кроме Gitlab, являются платными после 5 пользователей.
Решение сервера Git с использованием прав доступа к файлам
СпросиСетьПолитика конфиденциальности1y, 0v