Ubuntu 8.04 LTS: обновляем первый production-сервер через do-release-upgrade

Ubuntu 8.04 LTS официально вышла 24 апреля. Мы ждали этого релиза с марта и успели поработать с RC-сборками на стенде. Теперь - первый реальный production-сервер под управлением сопровождения инфраструктуры.

Обновление прошло не безупречно, но без катастроф. Фиксируем детали, пока они свежие.

Какой сервер обновляли

Веб-сервер среднего клиента: Apache 2.2, MySQL 5.0, несколько виртуальных хостов, минимальный трафик - около дюжины запросов в секунду в пиковые часы. База - Ubuntu 6.06 LTS (Dapper Drake), которой больше двух лет. Ядро 2.6.15, OpenSSH 4.2p1.

Именно этот сервер выбрали первым по нескольким причинам: он не несёт критичных бизнес-транзакций, резервный стенд готов, и Apache с MySQL на нём - самая типичная конфигурация из нашего парка. Если что-то пойдёт не так, восстановление занимает около получаса.

do-release-upgrade: что происходит на самом деле

Команда do-release-upgrade появилась ещё в Dapper, и мы её видели раньше только в описаниях. На практике инструмент оказался внятным: сначала предупреждает что именно изменится, показывает список пакетов к удалению, замене и добавлению, и ждёт подтверждения. Никаких сюрпризов на этапе планирования.

Сам процесс занял около сорока минут. Большая часть времени - загрузка и распаковка пакетов. Примечательно, что инструмент самостоятельно переключает SSH на резервный порт на время обновления - на случай если основное SSH-соединение упадёт в процессе. Мы об этом читали, но видеть в деле приятно: ни разу не потеряли соединение, хотя прерывания были.

Ядро и OpenSSH: что изменилось

Ядро перешло с 2.6.15 на 2.6.24. Разница существенная - почти три года разработки. На конкретном сервере разницу в поведении пока не поймали, но новый планировщик ввода-вывода CFQ заметен: дисковая активность во время резервного копирования стала чуть ровнее, без характерных провалов на запись.

OpenSSH вырос с 4.2p1 до 4.7p1. Для нас это в первую очередь означает закрытие нескольких уязвимостей, которые накопились за два года в Dapper. Конфигурация /etc/ssh/sshd_config после обновления была сохранена, но do-release-upgrade предложил diff с новым дефолтом - пара параметров изменила значения по умолчанию. Мы приняли новые дефолты: UseDNS no теперь выключен из коробки, что немного ускоряет аутентификацию на серверах без обратных DNS-записей.

AppArmor: сюрприз в хорошем смысле

В Hardy AppArmor включён по умолчанию и поставляется с готовыми профилями для Apache и MySQL. В Dapper его не было совсем - это принципиальное изменение в подходе к безопасности.

После обновления профили оказались в режиме complain - то есть нарушения логируются, но не блокируются. Это разумно: сразу переводить в enforce без проверки значит получить сюрприз в самый неподходящий момент.

Мы прошли по логам /var/log/syslog через день после обновления и нашли несколько обращений, которые профиль отметил как потенциально подозрительные:

MySQL пытался обратиться к файлу за пределами /var/lib/mysql - оказалось, у нас datadir был переопределён в /srv/mysql по старой привычке. Профиль пришлось отредактировать, добавив эту директорию.

Apache по умолчанию ограничен в доступе к /etc/. Один из виртуальных хостов использовал .htpasswd файл именно там - пришлось либо перенести файл, либо расширить профиль. Перенесли файл: это чище.

Перевели оба профиля в enforce после двух дней наблюдения. Пока проблем нет.

Что не понравилось

Две вещи заслуживают отдельного упоминания.

Первое - конфиги Apache. do-release-upgrade не трогает конфигурацию Apache, что в целом правильно. Но несколько директив, которые работали в 2.2.3 из Dapper, в 2.2.8 из Hardy повели себя иначе. В частности, Options FollowSymLinks в некоторых <Directory> блоках начал генерировать предупреждение при старте - не критично, но надо почистить.

Второе - MySQL 5.0.51. Версия изменилась с 5.0.22 до 5.0.51. Для большинства запросов - прозрачно. Но один клиентский скрипт, который использовал GROUP BY с неагрегированными полями в режиме не-ANSI, начал возвращать результаты в другом порядке. MySQL 5.0.51 стал строже в этом месте. Час на диагностику, пятнадцать минут на исправление скрипта.

Где сейчас

Сервер работает третий день. Nagios зеленый, приложение отвечает, клиент не написал. Следующий кандидат на обновление - файловый сервер на том же Dapper, там нет ни Apache, ни MySQL, зато есть Samba. Там свои нюансы - оставим на следующую неделю.

AppArmor в enforce-режиме пока держим под наблюдением: два дня - не срок. Если за следующую неделю ничего не всплывёт, будем считать конфигурацию рабочей и переносить подход на остальные серверы парка.