Debian Lenny RC2: тестируем на стенде и готовим план перехода с Etch

Debian выпустил второй релиз-кандидат Lenny - это уже не бета, это финальная форма дистрибутива перед самим релизом. RC2 означает, что критических багов нет, набор пакетов зафиксирован, архив стабилизирован. Можно щупать всерьёз.

У нас стоит тестовый сервер, который обычно получает что-нибудь интересное раньше продовых машин. Туда и поехал Lenny RC2 - чистой установкой с нуля, без апгрейда с Etch. Апгрейд проверим отдельно, там своя механика.

Зачем нам Lenny сейчас

На нескольких машинах в сопровождаемом парке стоит Etch (4.0). Он вышел в 2007 году, поддержка его продолжается, но не вечно. Ubuntu Server у нас тоже есть - 8.04 LTS с пятилетним циклом, там спокойно. А вот Debian Etch попадает в другую ситуацию: как только Lenny станет стабильным, для Etch начнётся отсчёт времени до конца поддержки, и этот срок - год, максимум полтора. Не критично прямо сейчас, но планировать переход нужно уже.

Поэтому RC2 - хороший момент, чтобы понять, что именно нас ждёт, и не делать это в режиме аврала ближе к дедлайну.

Что изменилось в RC2 против Etch

OpenSSH 5.1. В Etch был 4.3. Разница заметная: новые алгоритмы обмена ключами, улучшенное логирование, синтаксис конфига местами поменялся. У нас есть скрипты, которые парсят sshd_config - придётся проверять. Сам демон работает, конфиг из Etch после правки директив поднялся без проблем, но несколько устаревших опций выдали warnings при запуске. Лучше разобраться заранее, чем обнаружить это при апгрейде в ночное окно.

Python 2.5 по умолчанию. В Etch стоял 2.4. Большинство скриптов переживут переход без изменений: некоторые вещи из __future__ в 2.4 теперь стали поведением по умолчанию, пара библиотек у нас тянула sets модуль, который в 2.5 объявлен deprecated. Не критично, но warnings в логах - это шум, который мешает заметить реальные проблемы.

Perl 5.10. В Etch был 5.8. Здесь у нас меньше своего кода, но есть несколько внешних скриптов мониторинга, которые нужно прогнать.

DRBD 8 в ядре. Это, пожалуй, самое интересное. Etch шёл с ядром 2.6.18, где DRBD был только через внешний модуль - DKMS, ручная сборка, зависимость от заголовков ядра. Неудобно, особенно при апгрейде ядра, когда модуль нужно пересобирать. В Lenny ядро 2.6.26 с DRBD 8 прямо в дереве. Настроили стенд с двумя нодами - поднялось чище. Нам это важно: мы строили HA-кластер на DRBD и Heartbeat летом, и там как раз боролись с внешним модулем.

Что на тестовом стенде

Установка с netinst-образа - 20 минут, ничего не зависло. Базовая система чистая, пакетный менеджер работает, репозитории поднялись. Из неожиданностей - tasksel предложил немного другой набор задач по умолчанию, и в профиле «стандартная система» появилось несколько пакетов, которых в Etch не было. Мелочь, но в автоматизированном provisioning это нужно учитывать.

Апгрейд с Etch мы пока не гоняли - только чистую установку. Апгрейд планируем проверить отдельно, по стандартной схеме через apt-get dist-upgrade, и сразу на реплике одного из продовых серверов, а не на синтетическом стенде.

Черновой план перехода

Для машин на Etch в нашем парке прикидываем следующее.

Первое - инвентаризация зависимостей. Составить список всего нестандартного: пакеты из сторонних репозиториев, собранные руками, скрипты с явной привязкой к версиям Python/Perl. Etch-машин немного, но у каждой своя история.

Второе - тестовый апгрейд на клоне. Не на стенде с нуля, а именно на снапшоте реального сервера. Снять образ, поднять на виртуалке, прогнать dist-upgrade, зафиксировать всё, что потребовало вмешательства.

Третье - окна обслуживания. Debian-апгрейд - не пятиминутная история. Планировать ночное окно 2-3 часа с возможностью отката. Для машин с DRBD - отдельная механика: сначала secondary, проверить репликацию, потом primary.

Четвёртое - обновить provisioning-скрипты. То, что работало для Etch, нужно адаптировать. Особенно касается путей к Python и конфигов SSH.

Состояние

RC2 на стенде работает стабильно. Финального релиза пока нет, но RC - это уже не площадка для экспериментов с API: то, что здесь, почти наверняка окажется в финале. Несколько недель покрутим стенд под нагрузкой, параллельно доводим план апгрейда до рабочего состояния.

Спешить некуда - Etch ещё поддерживается. Но и затягивать смысла нет: апгрейд без подготовки обходится дороже, чем с ней.