From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 13 Nov 2003 22:29:35 +0200 From: Michael Shigorin To: sisyphus@altlinux.ru Message-ID: <20031113202934.GB8394@osdn.org.ua> Mail-Followup-To: sisyphus@altlinux.ru References: <200311101745.04995.webmaster@unicon-ms.ru> <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <20031113180022.GB16641@localhost.localdomain> User-Agent: Mutt/1.4.1i Subject: [sisyphus] [POLICY] Re: =?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 20:29:41 -0000 Archived-At: List-Archive: --KsGdsel6WgEHnImy Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Thu, Nov 13, 2003 at 09:00:22PM +0300, Денис Смирнов wrote: > Обоснование: обновление из сизифа часто является вынужденым, > даже если человек и не хочет принимать активного участия в > разработке, по таким причинам, как отсутствие багфиксов к > Мастеру, за исключением security. Ммм... в таком случае может быть более осмысленно поддерживать локальный репозиторий бэкпортов. У меня в некоей форме такое водится, по крайней мере leafnode и apache на alm2.2-системы попадают именно так. Если критичность * общесть проблемы превышает некий субъективный порог -- может быть оправданно рекомендовать (org@?) включение таких пакетов в updates после проверки. > Причины: > - ошибки в upstream Есть updates, которые errata. Для критичных ошибок они могут выпускаться. > С этим борется каждый мантейнер как может, гарантированых > решений быть не может. Улучшить ситуацию можно: > 1. автоматическими тестированиями; > как реализовать это на практике в общем виде я себе > представляю слабо, однако для таких продуктов как PHP > вполне можно реализовать набор тестов (хотя бы анализ > того, что возвращает phpinfo() ). Анализ по каким критериям? > 2. тестированием в условиях приближеных к боевым в течении > нескольких дней группой из тех, для кого развитие этих > пакетов является важным, и кто, возможно, своей головой > будет отвечать за работоспособность и функциональность > сервисов на базе данного пакета, используемых в его > организации. Так без него критичность не определяется в любом случае. > при этом иметь список людей (привязаный к каждому пакету) > заинтересованых в том, чтобы отслеживать развитие данного > конкретного пакета, речь идёт о людях _не обязательно_ > являющихся членами Team. Ну так это участники BTS. Это уже имеем. > - ошибки в пакетах > 1. тестирование вроде приведённого выше; > 2. продуманое полиси, в котором будут перечислены вещи, на > которые важно обращать внимание. Ммм... боюсь, обобщить тестирование -- проблема еще та, судя по количеству живой силы на этой задаче у поставщиков коммерческого ПО. > собственно мои мысли на тему "при обновлении не должна > меняться конфигурация", Зависит. Иногда известно, что с имеющейся конфигурацией новый код попросту не взлетит. Т.к. в sisyphus изменения между большими ветками _могут_ быть и бывают, то приходим к необходимости их отслеживать. Т.к. это трудно, то выход для тех, кому приходится пользовать sisyphus вместо master видится таким: - реализация механизма нотификации при поступлении новых пакетов, который позволил бы разделять изменения по степени масштабности (критичности, опасности). Примерно так уже сделано в Debian; у нас хотелось бы вырулить на то, информацию о чем можно получить той же почтой и отфильтровать по порогу, причем в идеале -- иметь возможность подвесить туда же робота (доступного в дистрибутиве), который может, глядя на подпись и некоторые иные критерии (тот же порог важности) -- дернуть rsync и/или apt и/или /bin/mail. > "если при обновлении меняется конфигурация, это повод > срочно проинформировать админа, да ещё и так, чтобы он > эту информацию потерять лишь с большим трудом мог" Ммм... *.rpmsave? > "при обновлении нельзя вносить изменения, которые могут > блокировать удалённый доступ администратора к серверу" > (это я всё pam вспоминаю) Полностью согласен. > "средства коммуникации, журналирования, авторизации > должны тестироваться особенно тщательно, и нарушение их > работы недопустимо даже в Sisyphus" это исключительно > мысли, которые, IMHO, имеет смысл в развёрнутом виде > иметь в таком полиси (рекомендательно-объяснительного > характера, ибо проверять каждый пакет на соответствие > _перед_ добавлением в сизиф нереально ни для кого, кроме > самого мантейнера). Проблема в том, что люди, которые отвечают за базовые средства удаленного доступа и контроля/смены привилегий -- a priori полагаются более чем сведущими в вопросе. Соответственно что делать с этим вопрсом -- непонятно. > >> К тому же ситуация, при которой обновление может блокировать > >> работу почтовика, является одной из той, опасность которых > > Вот. А тут добавляется еще одно требование его живости. > Сейчас эта информация просто теряется. Лог? -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/s+mubsPDprYMm3IRAhBsAKCBb/7ZZrvM5/kYVPCRt+58twqHBACdEMa/ JvshioB0t83wNbVnE+u/9OE= =yzb+ -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy--