[sisyphus] Re: [POLICY] Надёжность Sisyphus

["Денис Смирнов" <mithraen@freesource.info>]

On Thu, Nov 13, 2003 at 10:29:35PM +0200, Michael Shigorin wrote:

 >> Обоснование: обновление из сизифа часто является вынужденым,
 >> даже если человек и не хочет принимать активного участия в
 >> разработке, по таким причинам, как отсутствие багфиксов к
 >> Мастеру, за исключением security.
 > Ммм... в таком случае может быть более осмысленно поддерживать
 > локальный репозиторий бэкпортов.  У меня в некоей форме такое
 > водится, по крайней мере leafnode и apache на alm2.2-системы
 > попадают именно так.

Это решение со стороны администратора, на текущий момент единственное
и оптимальное. Я сейчас смотрю на проблему и методы её решения со стороны
разработки дистрибутива.

 > Если критичность * общесть проблемы превышает некий субъективный
 > порог -- может быть оправданно рекомендовать (org@?) включение
 > таких пакетов в updates после проверки.

Думаю что лучше всего если будет некий унифицированый подход. Чем меньше
исключений из правил, тем меньше шансов сделать что-нибудь не так.
 
 >> Причины:
 >>  - ошибки в upstream
 > Есть updates, которые errata.  Для критичных ошибок они могут
 > выпускаться.

Могут не значит выпускаются. Увы. Сейчас у админов нет выхода, кроме как
либо заниматься пересборкой пакетов из сизифа, либо обновляться до сизифа
во многих случаях.
 
 >>    С этим борется каждый мантейнер как может, гарантированых
 >>    решений быть не может. Улучшить ситуацию можно:
 >>    1. автоматическими тестированиями;
 >>       как реализовать это на практике в общем виде я себе
 >>       представляю слабо, однако для таких продуктов как PHP
 >>       вполне можно реализовать набор тестов (хотя бы анализ
 >>       того, что возвращает phpinfo() ).
 > Анализ по каким критериям?

Например соответствия тому, что утверждает PHP на предмет подключеных
модулей тому, что по этому поводу говорит rpm -qa | grep ^php-

Таких автоматических тестов придумать можно много. Вопрос только как может
выглядеть унифицированые средства для создания таких средств (пользователь
должен иметь возможность _быстро_ узнать о _наличии_ таких средств для
данного конкретного пакета, и по _каким параметрам_ это тестирование
выполняется).

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

Не понял реплику.
 
 > >       при этом иметь список людей (привязаный к каждому пакету)
 > >       заинтересованых в том, чтобы отслеживать развитие данного
 > >       конкретного пакета, речь идёт о людях _не обязательно_
 > >       являющихся членами Team.
 > Ну так это участники BTS.  Это уже имеем.

Они получают нотификации о каждом изменении пакета, каждом закрытии каждой
(не только ими выставленой) баги?
 
 >>  - ошибки в пакетах
 >>    1. тестирование вроде приведённого выше;
 >>    2. продуманое полиси, в котором будут перечислены вещи, на
 >>       которые важно обращать внимание.
 > Ммм... боюсь, обобщить тестирование -- проблема еще та, судя по
 > количеству живой силы на этой задаче у поставщиков коммерческого
 > ПО.

У поставщиков коммерческого ПО большие силы уходят на то, чтобы
тестировщик был заинтересован в тестировании. В случае free-software
community об этом заботиться смысла нет, достаточно позаботиться о том,
чтобы тем, кому это важно, это было сделать _легко_ (т.е. наличие
технических средств и документации).

То есть любой мантейнер-новичок должен знать о том, какие последствия
могут быть у каких серьёзных изменений. Тем более что даже зубры
ошибаются.
 
 >> собственно мои мысли на тему "при обновлении не должна
 >> меняться конфигурация",
 > Зависит.  Иногда известно, что с имеющейся конфигурацией новый
 > код попросту не взлетит.

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

 > Т.к. в sisyphus изменения между большими ветками _могут_ быть и
 > бывают, то приходим к необходимости их отслеживать.  Т.к. это
 > трудно, то выход для тех, кому приходится пользовать sisyphus
 > вместо master видится таким:
 
 > - реализация механизма нотификации при поступлении новых пакетов,
 >   который позволил бы разделять изменения по степени масштабности
 >   (критичности, опасности).

Ага, об этом я и говорю. Хотя как разделить эти изменения я не знаю, и,
IMHO, любые изменения которые изменяют поведение сервера после обновления
должны быть известны админу.
 
 >   Примерно так уже сделано в Debian; у нас хотелось бы вырулить
 >   на то, информацию о чем можно получить той же почтой и
 >   отфильтровать по порогу, причем в идеале -- иметь возможность
 >   подвесить туда же робота (доступного в дистрибутиве), который
 >   может, глядя на подпись и некоторые иные критерии (тот же порог
 >   важности) -- дернуть rsync и/или apt и/или /bin/mail.

Опа, мы кажется немного о разных вещах говорим :( Я говорил изначально
о нотификации изменений _после установки_, потом это уже спуталось с
другой моей идеей -- нотификацией заинтересованых лиц в выпуске нового
пакета.
 
 >>       "если при обновлении меняется конфигурация, это повод
 >>       срочно проинформировать админа, да ещё и так, чтобы он
 >>       эту информацию потерять лишь с большим трудом мог"
 > Ммм... *.rpmsave?

И это тоже. Однако информацию о том, что изменилось значение по-умолчанию
какой-то переменной оно содержать не будет, и если установочные скрипты не
могли это отследить, то тогда нужно информировать админа.
 
 > >       "средства коммуникации, журналирования, авторизации
 > >       должны тестироваться особенно тщательно, и нарушение их
 > >       работы недопустимо даже в Sisyphus" это исключительно
 > >       мысли, которые, IMHO, имеет смысл в развёрнутом виде
 > >       иметь в таком полиси (рекомендательно-объяснительного
 > >       характера, ибо проверять каждый пакет на соответствие
 > >       _перед_ добавлением в сизиф нереально ни для кого, кроме
 > >       самого мантейнера).
 > Проблема в том, что люди, которые отвечают за базовые средства
 > удаленного доступа и контроля/смены привилегий -- a priori
 > полагаются более чем сведущими в вопросе.
 
 > Соответственно что делать с этим вопрсом -- непонятно.

Только подразумевать то, что даже Величайшие Гуру являются всего лишь
живыми людьми и склонны хотя бы иногда ошибаться. Соответственно это
решается тем, что пакет должен полежать некоторое время в отстойнике и
быть провереным (и подписаным) ещё некотороым количеством людей, завсиящим
от уровня важности пакета.
 
 >>>> К тому же ситуация, при которой обновление может блокировать
 >>>> работу почтовика, является одной из той, опасность которых
 >>> Вот.  А тут добавляется еще одно требование его живости.
 >> Сейчас эта информация просто теряется.
 > Лог?

В каком логе была информация о изменении структуры конфига в PHP? Или о
изменении поведения su?

-- 
С уважением, Денис

http://freesource.info