On Sun, Nov 19, 2000 at 10:10:31PM +0300, Alexey Berejnev wrote:
> > Рассматриваемая схема отличается некоторой несвойственной для подобных
> > задач сложностью; это обусловлено особенностями security policy на том
> > сервере, где предполагается размещение CVS repository, и, надеюсь,
> > Алексей Бережнев расскажет нам об этом несколько подробнее.
> Политика сервера крайне проста - запрещено все, кроме того чтьо жизненно
> необходимо. Кроме того запрещено все что может породить большой трафик
> (В данном случае для CVS делается исключение). Кроме того, запрещено все 
> что заведомо несет коммерческие цели.

Не вполне конкретно, но пока противоречий нет.

> > Итак, все хранимые файлы расположены в CVS.
> > Доступ к CVS осуществляется с использованием SSH в качестве транспорта.
> > Работа с CVS осуществляется 2-мя способами:
> > + Основной: удаленный cvs-клиент запускает через ssh "cvs server", и они
> > обмениваются информацией согласно протоколу cvs.
> > + Файловый: разработчик запускает некий shell на сервере с тем, чтобы
> > закачивать туда данные с других серверов для последующего commit'a.
> Хотелось бы посмотреть на скрипты.

В качестве shell планируется "bash -r".
Скриптов практически нет (если не считать bashrc, profile, ...) - в основном
это скомпилированные программы.

> > Для каждого разработчика создается персональный account на сервере со
> > следующими свойствами:
> > + без возможности использования пароля, в качестве авторизации через ssh
> > используется RSA/DSA;
> > + в качестве login shell используется специальный wrapper, который, будучи
> > запущен ssh-сервером после успешной авторизации, далее запускает либо "cvs
> > server", либо shell, предварительно сделав chroot в специальный cvs
> > В последнем, помимо самого package repository, находятся программы,
> > необходимые для работы cvs и закачки данных (около 20 штук), их
> > конфигурационные файлы, разделяемые библиотеки и home directories
> > разработчиков. Никаких приложений, исполняемых внутри CE с рутовыми
> > правами, не планируется. Никаких устройств, помимо /dev/null, внутри CE не
> > требуется.
> А можно ли все-таки обойтись без shell, даже и в restricted режиме? 

В отдаленной перспективе, наверное, возможно.
Чтобы этого достичь, придется разработать протокол, описывающий способ
передачи тех действий, для которых сейчас нужен rbash, а также реализовать
клиентскую и серверную часть этого протокола. Список действий на данный
момент: закачка "pristine sources" в хранилище с других серверов,
управление сборкой на сборочном сервере, быстрый просмотр CVS. Второе
также предполагает наличие небольшого демона, находящегося на связи со
сборочным сервером и запускаемого оттуда через SSH, который, собственно,
и будет принимать запросы от разработчиков на сборку.

Вопрос для всех: какую программу лучше всего использовать для
закачки исходников на сервер (по ftp/http)?

Вопрос для будущих пользователей repository: придумайте себе login name,
состоящее не более чем из 4-ех букв (для кого это актуально).


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.