[Devel] git.office

[Boris Savelev]

25 июня 2009 г. 0:54 пользователь Evgeny Sinelnikov (sin на etersoft.ru) написал:
> Здравствуйте,
>
> недавно я решил воспользоваться git'ом для ведения сайта
> office.etersoft.ru, в результате чего снова столкнулся с
> противоречивым вопросом "публичного доступа" к закрытым исходникам.
>
> Дело в том, что с некоторых пор у нас два girar-сервера. Первый
> git.etersoft.ru или git.eter, второй - git.office.etersoft.ru или
> git.office. Второй сервер используется для хранения не публичных
> проектов и закрытых исходников.
>
> Среди задач, связанных со вторым сервером, есть задачипроблема
> предоставления "публичного" доступа для разработчиков. Задача
> противоречивая. Не вижу особого смысла в ней, если сервер публично
> доступен. Исходники становятся постоянно скомпрометированы. Поэтому я
> не стремился открывать на git.office.etersoft.ru http:// и git://
> протоколы.
>
> Есть некоторая примитивная защита проверки по ip, но мне кажется, что
> это не правильно. Такой сервер либо должен быть доступен из-вне, как
> сейчас, и публичные протоколы для него недопустимы, либо недоступен
> из-вне (только в локалке), тогда его можно рассматривать как
> внутренний аналог git.eter.
>
> Так вот. Столкнулся я с этим вопросом с след. задаче. Решил хранить
> изменения сайта в git и, по мере тестирования, заливать их к себе на
> git.office. После отладки предполагал делать на хостинге git pull.
>
> Не удобство оказалось в том, что для доступа к git.office обязательно
> нужны ключи, а хранить их на хостинге не хочется.
>
> В итоге, я пока не решил как быть с этим. Есть вариант "сделать всем
> темно", "закрыв глаза руками". То есть воспользоваться каталогом
> private на git.eter, который отличается от других тем, в нём нельзя
> просмотреть список репозиториев, но если знаешь имя clone сделать
> можно. По сути, для private отключено право на чтение каталога, но
> оставлено право на запуск.
>
> В общем жду отклика заинтересованных, а также их предложения и идеи.
>
> PS: не гибкая схема распределения прав является вообще проблемным
> вопросом, как и права на файловых системах в unix, имеющих
> существенные проблемы при групповой работе.

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

-- 
Boris