[Devel] git.office

[Vitaly Lipatov]

В сообщении от Суббота 04 июля 2009 Evgeny Sinelnikov написал(a):
> OK, осталось разрешить вопрос с сертификатами... У меня нет опыта их
> генерации. Я так понимаю, что сначала делаем http, а потом 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
И какой из них последний?

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

> где всегда можно обнаружить последнюю версию, кроме того, при этом
> создаётся репозиторий робота, через который доступен последний git
> выбранного пакета.
Это плюс конечно.

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

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

> >> /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
> >
> > К счастью, он работает без эмуляции.
>
> У меня не работал... логинюсь далее ключей - нет...
grep yes ~/.ssh/config | head
ForwardX11 yes
ForwardAgent yes
Compression yes

...
> > Ставишь SGID-бит и работаешь, особой проблемы не вижу.
> > Главное знать, что это возможно.
>
> Нет, это не всегда возможно... Как в описанном ниже примере поможет SGID?
>
> Оно просто не работает... уже сразу... Все права есть, для каталога
> установлен sgid, хотя это и не важно, поскольку в примере я руками
> ставлю группу... Все равно не работает...
Естественно, самое главное тут SGID, поскольку он заставит все создаваемые 
файлы быть в той же группе, что и каталог, что при условии нормальной umask в 
системе (0002) даст возможность  нормальной совместной работы.

Думаю, это стоит попробовать, иначе 1С не запуститься никогда ;)

> >> Вот яркий пример:
> >>  - делаем группу staff
> >>  - даём права на каталог 775 и эту группу назначаем
Нужно 2775

> >>  - создаём в этом каталоге файл с правами 664 одним пользователем
> >>  - пытаемся с ним работать другим пользователем: править, удалять
> >> каталог можем, перезаписать, из-под mc, другим файлом не можем... И
Диагностика не ясна - почему не можем?
...
> > Это не костыли, это штатное средство, специально для этого
> > предназначенное. В рамках такого подхода только они и подходят.
>
> http://lists.altlinux.org/pipermail/community/2008-September/639985.html
> "Все так думают, только решения предложить не могут..."
> rlz@ in community@
>
> О каком штатном средстве ты говоришь? Каким штатным средством я должен
> воспользоваться, чтобы дать право на смену владельца или группы на
> каталог и всё его содержимое, включая подкаталоги и файлы... Нет
> такого средства...
Это да. Но такое право не нужно. Достаточно самому поменять группу.

> А как это сделать, чтобы из графики работало?
В текущем варианте схема подразумевает некое администрирование, да. А из 
графики локальная совместная работа не нужна обычно.

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

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

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

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