Re: [devel] BTE

[AntonFarygin <rider@altlinux.com>]

[-- Attachment #1: Type: text/plain, Size: 4433 bytes --]

Alexander Bokovoy пишет:

>On Tue, Dec 10, 2002 at 07:00:20PM +0300, AntonFarygin wrote:
>  
>
>>>2. Высокий уровень безопасности используемых для достижения (1) средств.
>>>3. По возможности единообразные алгоритмы для выполнения одинаковых задач
>>> в разных процессах.
>>>4. Единая система сборки всех категорий результирующих продуктов -- от
>>> отдельных пакетов и репозитариев до ISO-образов, содержащих
>>> конкретные решение ("устанавливаемые дистрибутивы", "системы для
>>> запуска прямо с CD" и так далее).
>>>5. Единая система контроля качества всех категорий результирующих 
>>>продуктов.
>>>
>>>      
>>>
>>Пункт 5 - единый с чем именно? Не понимаю...
>>    
>>
>Единая со всей остальной системой (BTS, project management, сборочной
>средой). Потому что контроль качества -- это не только проверка на
>устанавливаемость пакетов, это и feedback, и соответствующие блокировки
>выполнения задач в проекте.
>
>  
>
>>>системы, дополнений, etc), выполнение которых должно происходить
>>>идентично, насколько это возможно.
>>>
>>>      
>>>
>>Согласен со всем, кроме пункта 1. Ибо, на мой взгляд, в сборочной среде 
>>не должно присутствовать:
>>a) по возможности установленных сервисных программ
>>    
>>
>Ты имеешь в виду тех, что ставят себя в init.d?
>
Да.

>
>  
>
>>б) по возможности _запущенных_ сервисных программ. Например - на данный 
>>момент процесс N 1 обламывается на этапе установки пакета apache на 
>>скрипте добавления chkconfig --add httpd (что естественно). Да и не 
>>    
>>
>Неестественно.
>
Кстати, действительно. Обламывается с сообщением о том, что на операцию 
нет прав. Если надо - вышлю логи сборки mod_ruby

>
>  
>
>>совсем понятно - почему для apache-devel необходим пакет apache ??? 
>>Разве нельзя пакеты собирать, не имея реальных сервисов в системе, а 
>>имея только библиотеки?
>>    
>>
>В случае apache надо рассматривать подробнее (я не помню прямо сейчас).
>Однако я не понимаю, почему chkconfig --add httpd должен что-то ломать --
>ведь при выполнении этой команды ничего реально не запускается, только
>делается symlink.
>
Да, он действительно не ломает. Так это же еще один плюс в эту систему.

>
>  
>
>>Все остальные среды, несомненно, должны эмулировать реальную систему.
>>
>>Причина, побудившая выполнять создание сборочной среды под обычным 
>>пользователем - в первую очередь безопасность. Не стоит забывать, что  у 
>>нас сейчас будет открываться доступ к сборочным серверам через почтовый 
>>интерфейс. И, честно говоря, давать возможность создавать рутовые чруты 
>>по письму (пусть даже авторизованному) - страшно.
>>    
>>
>Страшно -- помести "исполнителя" в UML. Это вопрос deployment
>соответствующей службы, а не ее реализации. Вот cvs и shell не
>предоставляют достаточных средств для защиты, а devel.altlinux.ru тем не
>менее серьезно защищен.
>
Так мы чем и занимаемся. Реализация очень тесно связана с дальнейшей 
эксплуатацией.

>
>  
>
>>>Та реальность, которую ты предлагаешь считать "не хуже других", не
>>>позволяет обеспечить идентичную реализацию одинаковых подпроцессов. Более
>>>того, исходя из развернутого разговора с AVN, данная реальность не
>>>предполагает одинакового поведения при сборке всех пакетов, что неумолимо
>>>ведет к рождению исключений. Я считаю это серьезной ошибкой в
>>>проектировании.
>>>
>>>      
>>>
>>Можно поподробнее про неодинаковое поведение?
>>Поведение сборочной среды диктуется исключительно зависимостями пакета и 
>>возможностью указывать другой apt репозиторий.
>>    
>>
>Этот вопрос я переадресую AVN, поскольку он и вел речь про неодинаковое
>поведение.
>
Я у него уже уточнил. Как сказал мне AVN, под неодинаковым поведением он 
имел в виду отсутствие системных сервисов, поднимаемых в чруте.

Вы с ним явно друг друга не поняли ;-)

Для всех без исключения пакетов установка проходит единообразно, за 
исключением, пожалуй, сборочных зависимостей. То, что некоторые POST 
скрипты не могут выполняться с правами, отличными от root - недостаток 
этих POST скриптов, а не как не системы сборки.
Т.е. - реальное тестирование _установки_ выходит на качественно более 
высокий уровень, позволяюще выявлять абсолютно не нужные,мало того - 
запрещенные в реальной системе действия. Как то старт сервиса, открытие 
соединений наружу и т.д. и т.п.

Правда остается еще одна проблема - возможность изменения системных 
библиотек из пост-скриптов. Может быть стоит делать полностью весь 
chroot read-only ?


Rgds,
Rider


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]