[Devel] git.office

Сб Июл 4 22:33:27 MSD 2009

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

OK, осталось разрешить вопрос с сертификатами... У меня нет опыта их
генерации. Я так понимаю, что сначала делаем http, а потом https. Но
мой критичный взгляд подсказывает, что вот здесь-то исходники могут и
уплыть ;)

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

Поиск исходников я делаю так:
$ ssh git.eter find-package '*cifs*'
/people/sin/packages/linux-cifs.git
/people/sin/packages/etercifs.git
/people/sin/packages/cifs-2.6.git
/people/piastry/packages/cifs-2.6.git
/people/kipruss/packages/linux-cifs.git
/people/kipruss/packages/kernel-source-etercifs-2.6.25.git
/people/kipruss/packages/etercifs.git
/people/kipruss/packages/dkms-etercifs.git
/people/kipruss/packages/cifs-2.6.git
/people/boris/packages/linux-cifs.git
/people/boris/packages/dkms-linux-cifs.git

ну, или так:
$ ssh git.eter ls /projects
total 0
drwxrwsr-x 6 130 Jun 17 23:18 eterwine.git
drwxrwsr-x 4 112 Jun 17 23:14 test.git

Веб для этого не удобен, ибо долго и из консоли выходить нужно.

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

И вот здесь снова должна помочь сборка в LINUX на Etersoft. На деле
LINUX на Etersoft тут не причём.. Конечным репозиорием может быть что
угодно. Видимо, нам стоит придумать свои карманы, тогда и искать будем
сразу там... Пока же ssh git.eter build собирает пакет в репозиторий
/var/ftp/pub/Etersoft/LINUX на Etersoft/Sisyphus/
где всегда можно обнаружить последнюю версию, кроме того, при этом
создаётся репозиторий робота, через который доступен последний git
выбранного пакета.

Например, последние исходники etercifs доступны здесь:
http://git.etersoft.ru/gears/e/etercifs.git/

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

Да, нужно дописать...

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

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

Заодно и git.office потестировать... Ну вот и нарвался тут же на вопрос.

>> >> Не удобство оказалось в том, что для доступа к 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-бит и работаешь, особой проблемы не вижу.
> Главное знать, что это возможно.
>

Нет, это не всегда возможно... Как в описанном ниже примере поможет SGID?

Оно просто не работает... уже сразу... Все права есть, для каталога
установлен sgid, хотя это и не важно, поскольку в примере я руками
ставлю группу... Все равно не работает...

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

http://lists.altlinux.org/pipermail/community/2008-September/639985.html
"Все так думают, только решения предложить не могут..."
rlz@ in community@

О каком штатном средстве ты говоришь? Каким штатным средством я должен
воспользоваться, чтобы дать право на смену владельца или группы на
каталог и всё его содержимое, включая подкаталоги и файлы... Нет
такого средства...

Можно сделать sudo на chown, но мне нужно чтобы не все файлы на ФС, а
только для данного каталога. Нет таких средств.

А как это сделать, чтобы из графики работало?

В общем, это уже обсуждалось... Приемлемых решений, даже для простых
задач - практически нет.

 Дима в community@ это как-то простую задачу обсуждал:
http://lists.altlinux.org/pipermail/community/2008-September/639971.html

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

Это взаимозависимые средства... От того, что кто-то что-то попробует,
никакие новые средства не появятся.

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

Ну, если только так...

-- 
Sin (Sinelnikov Evgeny)