Обновление на несколько релизов

[PbI6A]

Ребята, подскажите такую весчь Есть дебиан 7, который, как я понимаю, уже какое-то время discontinued Надо обновить его до oldstable. Сервак на продакшне, вырубать его или перегружать чем меньше, тем лучше - юзвери сразу начинают орать
Суть вопроса. Можно ли обновить его на 2 релиза 7->8->9 не перегружая в промежуточной версии 8? Я так понимаю, что 7->9 без промежуточной 8 обновлять не желательно?

[qupl]

Пропускать 8 точно нельзя. Получится ли без перезагрузки? Не факт. Там же переход на systemd был.

[PbI6A]

В 9 же тоже systemd есть. То есть обновление с 8 до 9 не должно быть для загрузочного процесса шоком. Или нет?

[Gamliel]

Сервак на продакшне, вырубать его или перегружать чем меньше, тем лучше - юзвери сразу начинают орать

Мне кажется, самый надёжный вариант — поставить Debian Buster на аппаратно более-менее такую же машину, скопировать туда конфиги и контент со старого сервера и подключить новый сервер взамен старого. После чего использовать освободившуюся старую машину для того, для чего была приготовлена новая. Или, если нет свободной машины с сопоставимым железом, можно арендовать похожую машину на один день, скопировать туда всю файловую систему, подключить временную машину вместо основного сервера, а на основном сервере всё снести, поставить Debian Buster с нуля и скопировать туда конфиги и контент, после чего обратно подключить сервер.

Если для замены сервера туда-обратно не дёргать кабели, а менять IP-адрес, то можно полностью избежать дайнтайма. При этом, чтобы избежать рассинхронизации, лучше на время переключения (два раза по несколько минут) делать сервер ридонли.

[ogost]

Пропускать 8 точно нельзя.

Согласен, нельзя.

То есть обновление с 8 до 9 не должно быть для загрузочного процесса шоком.

не должно, но перезагружать всё равно придётся - ядро несколько раз уже обновлялось. Можно конечно подсунуть новое ядро без перезагрузки, но я так не делал и вам не советую. Проще и быстрее перезагрузиться.

[endru]

Тут без остановки сервисов не обойтись - в любом случае будут проблемы как с подгрузкой нового ядра, так и с конфигами ПО.
Вариант с минимальными остановками только один - заменить рабочий сервер на новый.
Ну либо делать всё в не рабочее время.

[PbI6A]

Поимел множество гемора с виртуальником, на котором кружатся инетовские серваки. Начиная с того, что развалился mdadm и не хотел автоматом собирать массив raid1(!!!), на котором стоял корпоративный прокси сервер, и заканчивая тем, что после обновления системы ядро оказалось старое 3.2 и на нём не захотел стартовать модуль аппаратной виртуализации kvm_intel. По итогу простой до 11-30 местного и запуск в ручном режиме, включая запуск ядра с sysvinit и ручным стартом kvm_intel Вроде, разобрался и с тем, и с другим, и с третьим, но ещё не перегружал, чтобы убедиться, что всё хорошо - хочу вообще переставить этот кривой виртуальник.

Теперь вот думаю, как бы так его поставить, чтобы потом как более долго не устраивать себе проблемы с обновлениями. Может быть, сразу поставить версию testing, обновиться до текущего состояния, а потом нарисовать в конфиге apt обновляться со stable? В принципе, stable и testing ещё не бесконечно далеко разошлись, должно нормально быть? Или я потом аналогичные проблемы поимею?

[S_Paul]

Мне кажется, самый надёжный вариант — поставить Debian Buster на аппаратно более-менее такую же машину, скопировать туда конфиги и контент со старого сервера и подключить новый сервер взамен старого. После чего использовать освободившуюся старую машину для того, для чего была приготовлена новая. Или, если нет свободной машины с сопоставимым железом, можно арендовать похожую машину на один день, скопировать туда всю файловую систему, подключить временную машину вместо основного сервера, а на основном сервере всё снести, поставить Debian Buster с нуля и скопировать туда конфиги и контент, после чего обратно подключить сервер.

Если для замены сервера туда-обратно не дёргать кабели, а менять IP-адрес, то можно полностью избежать дайнтайма. При этом, чтобы избежать рассинхронизации, лучше на время переключения (два раза по несколько минут) делать сервер ридонли.

Поддержу. Один нюанс есть - если серверы у провайдера, но при смене у IP "хозяина" может понадобиться очистка ARP-таблиц в маршрутизаторе. Сталкивался.

[S_Paul]

Может быть, сразу поставить версию testing, обновиться до текущего состояния, а потом нарисовать в конфиге apt обновляться со stable? В принципе, stable и testing ещё не бесконечно далеко разошлись, должно нормально быть? Или я потом аналогичные проблемы поимею?

Тестинг целиком в продакшн лучше на ставить. Максимум - отдельные пакеты. Ну или когда  релиз не за горами хотя бы.

[endru]

Тестинг целиком в продакшн лучше на ставить.

Ой не надо этих заявлений. Проблемы есть в любой версии ПО хоть в стабильной хоть в тестируемой. Нужно выбирать под задачи, в какой есть нужный набор функций ту и ставить и не гнаться за словом "стабильность". Знаю много людей и компаний которые сидят на ПО из тестинга и спокойно работают.

[S_Paul]

Так никто и не отрицает что такие проблемы есть. Но тестинг, на то и тестинг.

[PbI6A]

У меня разделены серверы по назначению - на виртуальном только libvirt и ssh, остальное не важно, на проксе - squid и ssh, на почтовике - postfix, dovecot, clamav и ssh. Не собираюсь наставлять разного ненужного.