From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 14 Nov 2003 02:35:52 +0300 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= To: sisyphus@altlinux.ru Message-ID: <20031113233552.GC28958@localhost.localdomain> References: <20031110174409.GI686@osdn.org.ua> <20031111082105.GB13738@localhost.localdomain> <20031111174007.GS686@osdn.org.ua> <20031112140537.GC15955@localhost.localdomain> <20031112162941.GQ686@osdn.org.ua> <20031113012827.GA15658@localhost.localdomain> <20031113145857.GK686@osdn.org.ua> <20031113180022.GB16641@localhost.localdomain> <20031113202934.GB8394@osdn.org.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20031113202934.GB8394@osdn.org.ua> Subject: [sisyphus] Re: [POLICY] =?koi8-r?b?7sHEo9bOz9PU2A==?= Sisyphus X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: sisyphus@altlinux.ru List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 23:39:02 -0000 Archived-At: List-Archive: 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