[Devel] git.office

[Vitaly Lipatov]

В сообщении от Суббота 04 июля 2009 Evgeny Sinelnikov написал(a):
> С точки зрения безопасности этот вариант приемлем только при
> использовании https. Иначе это дыра. Вопрос в том насколько важно
Значит поставим задачу использовать https. Кроме использования отдельного IP, 
ничего сложного в этом нет.

> недопустить утечку из git.office. Если это не так уж важно, то можно и
> сделать... Если важно, но нужно использовать https, а это для обмена
> исходниками не так удобно - придётся указывать пароль.
Через https не нужно обмениваться исходниками. Через него можно заходить на 
сайт и смотреть, что там находится.

> https я пока не пробовал, так что точно не могу сказать как он работает.
>
> Честно говоря, я с трудом могу себе представить кому вдруг может
> понадобится, для работы, просматривать закрытые исходники через веб.
> При наличии доступа, проще склонировать и смотреть локально.
Для начала надо узнать, что клонировать. При политике, когда у каждого лежит 
своя копия проекта, это актуально вроде как...

А где взять последнюю версию etercifs, вообще пока не ясно. Особенно из 
http://wiki.etersoft.ru/Etercifs

> >> Так вот. Столкнулся я с этим вопросом с след. задаче. Решил хранить
> >> изменения сайта в git и, по мере тестирования, заливать их к себе на
> >> git.office. После отладки предполагал делать на хостинге git pull.
> >
> > Зачем исходники сайта хранить в закрытом git?
>
> Хм... Ну, затем, чтобы не хранить в открытом :)
> Пока я обошёлся каталогом private, как и описывал...
Что такого секретного в исходниках сайта (кроме возможного пароля к базе), 
интересно? :)

> >> Не удобство оказалось в том, что для доступа к git.office обязательно
> >> нужны ключи, а хранить их на хостинге не хочется.
> >
> > Для этого все пользуются ssh-agent и форвардом агента при заходе на
> > удалённые хосты. В мане это называется "forwarding of the authentication
> > agent connection."
> > А ключи все хранят у себя на машине.
>
> ух ты... я такое пока не использовал... Локально - да, а форвардинг я
> эмулировал вот так:.
>
> $ cat /home/sin/.bash_profile
> ...
> /etc/X11/profile.d/ssh-agent.sh &&
> SSH_AGENT_PID=`pgrep ssh-agent -u sin|head -1 2>&1` &&
> SSH_AUTH_SOCK=/home/sin/.ssh/agent &&
> export SSH_AGENT_PID &&
> export SSH_AUTH_SOCK
К счастью, он работает без эмуляции.

>
> >> PS: не гибкая схема распределения прав является вообще проблемным
> >> вопросом, как и права на файловых системах в unix, имеющих
> >> существенные проблемы при групповой работе.
> >
> > Связи с темой распределения прав пока не заметил.
>
> Что тут непонятного ? :)
> Неудобно в Unix группы использовать для совместного доступа...
Ставишь SGID-бит и работаешь, особой проблемы не вижу.
Главное знать, что это возможно.

> Вот яркий пример:
>  - делаем группу staff
>  - даём права на каталог 775 и эту группу назначаем
>  - создаём в этом каталоге файл с правами 664 одним пользователем
>  - пытаемся с ним работать другим пользователем: править, удалять
> каталог можем, перезаписать, из-под mc, другим файлом не можем... И
> чего только не можем - этого не можем, того не можем :) Те же права
> сменить не можем и возможности дать такое право стандартными путями
> нет. Ну костыли suid'ные только и помогают.
Это не костыли, это штатное средство, специально для этого предназначенное. В 
рамках такого подхода только они и подходят.

>  - оба пользователя в группе staff, если что...
>
> Использование этих средств требует сакрального знания. Из графики этим
Я думаю, что знание всё-таки банально, а проблема проста - никто никогда не 
работал в Unix/Linux совместно в массовом порядке, поэтому как это делать, 
никто не знает. У меня сложилось такое впечатление.

> обычно уже не пользуются... Вот вам и не гибкая схема распределения
> прав, как большой вопрос на файловых системах в unix.
Зато она работает, и это большой плюс.

-- 
С уважением,
Виталий Липатов
Россия, Санкт-Петербург. www.etersoft.ru
GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!