[sisyphus] php: new config files structure???

[sisyphus] php: new config files structure???

[@ 2003-11-07 16:46 UTC (permalink / raw)]

Re: [sisyphus] php: new config files structure???

[@ 2003-11-08 12:20 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-08 17:46 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 8:04 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 9:16 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 11:19 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 11:22 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 11:30 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 11:33 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 11:54 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 12:06 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 13:53 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 14:29 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 14:38 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 15:03 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 14:45 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 15:00 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 15:05 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 15:24 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 15:35 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 17:44 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structu???

[@ 2003-11-11 8:21 UTC (permalink / raw)]

[sisyphus] бочки для мейнтейнеров нестабильного репозитория

[@ 2003-11-11 10:45 UTC (permalink / raw)]

[sisyphus] Re: бочки для мейнтейнеров нестабильного репозитория

[@ 2003-11-12 13:59 UTC (permalink / raw)]

[sisyphus] [POLICY] Re: php: new config files structu???

[@ 2003-11-11 17:40 UTC (permalink / raw)]

Re: [sisyphus] [POLICY] Re: php: new config files structu???

[@ 2003-11-11 21:44 UTC (permalink / raw)]

Re: [sisyphus] [POLICY] Re: php: new config files structu???

[@ 2003-11-12 8:01 UTC (permalink / raw)]

[sisyphus] Re: [POLICY] php: new config files structu???

[@ 2003-11-12 14:05 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structu???

[@ 2003-11-12 16:29 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structu???

[@ 2003-11-13 1:28 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structu???

[@ 2003-11-13 14:58 UTC (permalink / raw)]

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

[@ 2003-11-13 18:00 UTC (permalink / raw)]

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

[Michael Shigorin]

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

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 <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

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

[Денис Смирнов]

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

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

[@ 2003-11-17 9:57 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 15:13 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 17:40 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 20:32 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 17:39 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 18:12 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 11:48 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 11:57 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 12:01 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 12:57 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 13:55 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 14:44 UTC (permalink / raw)]

Re: [sisyphus] Re: php: new config files structure???

[@ 2003-11-10 14:47 UTC (permalink / raw)]

[sisyphus] Re: php: new config files structure???

[@ 2003-11-10 17:36 UTC (permalink / raw)]

[sisyphus] php: iconv

[@ 2003-11-11 8:05 UTC (permalink / raw)]

Re: [sisyphus] php: iconv

[@ 2003-11-11 8:26 UTC (permalink / raw)]

Re: [sisyphus] [OFFTOPIC] php: iconv

[@ 2003-11-11 8:54 UTC (permalink / raw)]

[sisyphus] Re: [OFFTOPIC] php: iconv

[@ 2003-11-11 9:20 UTC (permalink / raw)]

Re: [sisyphus] php: iconv

[@ 2003-11-11 10:29 UTC (permalink / raw)]

Re: [sisyphus] php: iconv

[@ 2003-11-11 10:57 UTC (permalink / raw)]

Re: [sisyphus] php: iconv

[@ 2003-11-11 12:06 UTC (permalink / raw)]

Re: [sisyphus] php: iconv

[@ 2003-11-11 12:26 UTC (permalink / raw)]

Re: [sisyphus] php: iconv

[@ 2003-11-11 12:46 UTC (permalink / raw)]

Re: [sisyphus] php: iconv

[@ 2003-11-11 13:19 UTC (permalink / raw)]

Re: [sisyphus] php: iconv

[@ 2003-11-11 13:27 UTC (permalink / raw)]

Re: [sisyphus] php: iconv

[@ 2003-11-11 12:38 UTC (permalink / raw)]