[Comm] [POLICY] Re: вопрос по обновлениям...

[Michael Shigorin <mike@osdn.org.ua>]

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

	Здравствуйте.
Две части; сперва в осн. организационная, далее --
техн[олог]ическая.  Нет, еще дорисовалась бизнес-часть.

--- org

On Fri, Mar 19, 2004 at 02:30:21PM +0300, Dmitry Shubin wrote:
> Мы планируем использовать Alt Linux на серверах взамен
> почившего RH, потому стабильность и целостность системы после
> апдейта для нас очень критична, в связи с чем возник такой
> вопрос - поддерживаются ли security updates всех rpm продуктов
> входящих в состав релиза Master 2.2?

Хороший вопрос.  С одной стороны -- да, поддерживаются и обычно
неплохо.  Вплоть до выхода в числе первых часов публикации или
обнаружения проблемы.

Недостатков есть два:

- дырка, которая уже заткнута -- обычно не анонсируется как
  таковая (что было бы бесполезно по сути, но успокаивающе) --
  это в смысле "заткнуто два года назад", а не "только что";
- _гарантированного_ времени отклика и _гарантированного_
  качества обновлений нет.

По последнему пункту -- поймите меня правильно, я участвую в
команде, собираю сейчас эти самые apache и mod_ssl -- хотя в
продакшне mod_ssl у меня сейчас нет, по каковой причине security@
и не было оперативно додавлено.

Я крайне заинтересован в оперативности и качестве этих самых
обновлений и как менеджер компании-партнера Альт Линукс, и как
(все еще) hostmaster@ ряда систем, на которых по несколькилетнему
опыту эти самые обновления прикладываются автоматически.

Поэтому с одной стороны -- можно кивать на Debian с его весьма
неплохой sec team, но все же негарантированными по времени
обновлениями, можно -- на RH с исчезнувшими QA и поддержкой (и QA
поддержки) публично доступных версий (просьба не доколупываться к
формулировкам, все поняли)... но хочется-то "чтоб работало".

Персонально мое мнение -- даже текущая политика (выпуск в т.ч.
обновлений с увеличением версии) есть good enough, по крайней
мере мне найти свои грабли (не поднявшийся mysql) удалось однажды
за где-то три года, и то они были вычислены чуточку заранее из
анонса и автомат был продублирован наблюдением.

Что не значит, что нечего менять к лучшему.

Здесь, полагаю, предложения и пожелания -- принимаются.

Желательно -- с пониманием того, что ресурсы более чем реально
ограничены и едва ли не единственный (но возможный) способ
получить _гарантированные_ по срокам _и_ качеству обновления --
это заключить контракт на поддержку.

--- tech

> Вы скажете - бери отсюда mod_ssl-2.8.16-alt1.src.rpm

Это крайний случай.  Да, оно сработает.  Но это все равно слишком
плохо.

> "У нас нет секретных патчей и закрытого тестирования с
> подписками о не разглашении: то, что мы сделали сегодня, --
> завтра вы найдёте в сети." - цитата из описания Sisyphus.

Это другое.

> Но вот вопрос, продукты выложенные в Sisyphus прошли тестирование?

Какое-то -- обычно да.  Автоматическое (зависимости, библиотеки,
неконфликтность с базовой системой) -- обязательно;
"человеческое" -- в зависимости от продукта, майнтейнера,
активности сообщества пользователей именно этого продукта.

Понятное дело, что QA апстрима идет отдельной строкой, и
различные проекты по этой части различаются тоже очень сильно.

> Как-нибудь отмечаются продукты прошедшие и не прошедшие тестирование?

Косвенно -- количеством открытых отчетов в Bugzilla.

Автоматическое (см. sisyphus_check из пакета sisyphus, если
интересно) -- все, которые попали в "свежий сизиф".

Ручное -- скорее в обратном порядке: пакеты (сборки), в которых
майнтейнер не вполне уверен, обычно "специальнее" анонсируются в
списке рассылки sisyphus@.

> Просто не хотелось бы после очередного апдейта словить
> неоттестированный не работающий патч, и через неско часов его
> патчить заново..

Нет, с апдейтами как раз все довольно неплохо.  Вот только не
стоит путать с ними Sisyphus.

--- biz

Если для компании альт приемлем как технологическая платформа
практически всем, кроме недостаточной предсказуемости _небольшой_
части обновлений -- может иметь смысл рассмотреть три варианта:

- держать на системах, где в силу host policy обновления могут не
  производиться вообще (крайний случай, малоосмыслен);
- содержать в штате специалистов, которые занимаются проблемами
  безопасности и, в частности, при задержке обновления из
  официального источника и остроте проблемы способны создать,
  протестировать и опубликовать в корпоративном репозитории
  обновлений "фирменный" вариант (боюсь, применимо и в случае
  Debian -- см. письмо рядом);
- подписать контракт, указав в SLA:
  - требуемый состав пакетной базы, которая поддерживается в
    обязательном порядке;
  - сроки, в течение которых становятся доступными проверенные
    обновления для всех или различных категорий проблем
    безопасности (e.g. local root, remote code exec, info leak);
  - срок, в течение которого выпускаются обновления для заданного
    stable.

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

-- 
Michael Shigorin
EMT.Com.UA

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