[Uneex] Предложение по теме семинара

[Yuri Ryazantsev]

Andrey Orlov wrote:

>>Еще раз повторюсь. Любое решение - не единственное. Чем больше решений 
>>известно, тем лучше.
> 
> Я это понял. Я сразу это отметил не как начало войны, а чбы вы были готовы в процессе
> дискуссии отвечать на вопросы в области сравнения именно этих альтернатив.

Если я что-то знаю, то озвучу, на основании того опыта, который 
накоплен. Изменить это накопление за три дня - нереально. Так, что если 
чего не знаю, то ответа не будет :-))

>>1. Отсутствие озвученного плана выхода дистрибутивов;
> 
> И его регулярный срыв.
> 
> 
>>2. Отсутствие feature-update для старых дистрибутивов;
> 
> 
> По крмре мне это не мешает, а в целом это наверно проблема не только менеджмента, но и размера
> команды, равно как востребованность. По моему личному опыту, по комплексу причин не имеющих
> отношения к дистрибутиву, полный апдейт оказываетчя более актуальным чем частичный. Тем более что многие проблмы apt
> реально решает.

Может быть сейчас ситуация изменилась. Но меня напрягало следующее:

- есть пакет программы XX, который в дистр вошел версией N;
- есть проблема, на которую я наткнулся, и которая решена в версии N+o 
(не security);
- версия N+o есть в Сизифе;

Далее я стою перед выбором:
1. Ждать, когда выйдет новый дистр с новым пакетом - может быть очень 
долго, особенно если предыдущий выход был недавно;
2. Собрать новый пакет для себя в окружении текущего используемого 
дистра - чаще всего так и делалось, но есть проблема, озвученная в 
вырезанном вами пункте 6 :-))
3. Переходить на Сизиф; но тогда см. пункт 5

> 
> 
> 
>>3. Сомнение в возможности remote update например с ALM2.1 -> ALM2.4, 
>>хотя это не очень далеко отстоящие друг от друга дистрибутивы.
> 
> 
> Во-1-ых, ALM2.1 вышел три года назад, кажется. Имел на борту, например, postgresql 7.2 и Zope2.5
> Бездумно проапггрейдить и то и другое до версий из ALM2.4 - означает массу гемороя на грани потери данных.
> Это только два примера, на самом деле их может быть больше. Как это решается в BSD?

Есть понятия не только package upgrade, но и migration data. Прежде чем 
что-либо делать на сервере необходимо иметь ясные ответы на следующие 
вопросы:
- зачем я это делаю, есть ли необходимость в этом;
- что получу в результате;
- что потеряю в результате;
- каким образом будет обеспечена работоспособность остальных на момент 
перехода;
- как будет восстановлена работоспособность после перехода;
- как будет восстановлена работоспособность если переход невозможно 
будет завершить;

Если нет ответа, хотя бы на один из этих вопросов, то ничего делать не надо.

> Во-2-ых, я собственно не знаю как делается такая миграция в BSD, поэтому мне тяжело сравнивать
> возможности такаого обновления, буду рад, если вы мне это объясните на уровне: "предполагаемая вами проблема - 
> то как она решается в BSD";
> 
> В-3-их, ну не надо же так запускать ;)

Это уже лучше не в рассылке, а при встрече. У меня был опыт перехода от 
2.2.8 -> 4.8 (тогда она была последней). Ну забыли на 4 года про сервер, 
и вспомнили про него, когда надо было что-то поменять :-)) Переход был 
осуществлен по сети, а для полного представления масштаба могу сказать, 
что ветка 4 - elf, а ветка 2 - a.out и про elf в ней ничего не было.

Вообще-то, в моем понятии, upgrade системы - это отдельный и достаточно 
продуманный процесс. И если этой продумкой занимались разработчики 
данной системы, то админу для этого потребуется меньше усилий. В 
противном случае, процесс upgrade превращается в "все снести и заново 
поставить". Это тоже решение, но не всегда возможное :-))

> 
> 
>>5. Идеальный вариант для использования - Сизиф,  но у него не знаю как 
>>взять целостный срез.
> 
> 
> Думаю, на этот вопрос лучше ответит ктонь\ть другой, но afaik тут нет проблемы.

Неужели. Тогда было бы неплохо это озвучить :-) Т.е. утверждается, что в 
любой момент времени Сизиф - работоспособный набор пакетов? Тогда же 
чего мучаться с выпуском нового дистра? В любой момент объявляешь срез 
Сизифа новым релизом :-)))

-- 
Yuri Ryazantsev <yuri на unix.ru>    | RIPE: YR1-RIPE
UNIX System Network Administrator | RIPN: YAR1-RIPN