CentOS 5 на production: Xen в ядре, SELinux без боли, три сервера живы

CentOS 5 вышел в апреле, но мы не торопились - сначала коллеги на Debian Etch отработали похожий путь с Xen, и мы смотрели на их опыт. В июле поставили стенд, в августе перевезли три production-сервера клиентов с CentOS 4. Живы все три, так что можно рассказать как было.

Зачем вообще уходить с CentOS 4

CentOS 4 основан на RHEL 4 - ядро 2.6.9, всё это работает, не падает, клиенты не жалуются. Проблема не в стабильности, а в том, что вокруг CentOS 4 всё больше ручной работы.

Xen мы тянули из отдельного репозитория, собранные ядра держали у себя, и при каждом security-патче на ядро это превращалось в маленький квест: собрать, протестировать, раскатить, проверить что dom0 поднялся с нужным ядром, а не со старым. Не критично, но накапливается.

SELinux на CentOS 4 существовал, но в permissive - реально его никто в enforcing не держал на production, потому что доля политик, которые нужно было дописывать руками, была пугающей. Проще отключить.

Что изменилось в пятёрке

Xen прямо в ядре. Ядро 2.6.18 в CentOS 5 идёт с Xen-патчами из коробки, Xen 3.0.3 в официальных репозиториях. Никакого самодельного dom0, никаких отдельных сборок. yum install xen - и через несколько минут стандартное ядро с поддержкой гипервизора. Это меняет обслуживание: security-обновления на ядро приходят через yum, тот же путь что и всё остальное.

SELinux в enforcing - и это реально работает. Тут главное слово - audit2allow. В RHEL 5 / CentOS 5 Red Hat довели инструментарий до состояния, когда SELinux в enforcing перестаёт быть тыкой в темноте. Схема простая: смотришь /var/log/audit/audit.log, видишь AVC-отказ, прогоняешь через audit2allow, получаешь модуль политики, компилируешь, загружаешь. Если отказ легитимный - модуль остаётся, если нет - разбираешься дальше. Не быстро, но понятно.

На CentOS 4 этот инструментарий существовал в зачаточном виде. Здесь уже нормально: audit2allow -a -M mypolicy && semodule -i mypolicy.pp - и большинство типичных отказов закрывается за полчаса.

Как переезжали

Три сервера выбрали по принципу «не самые критичные, но живые»: веб + PHP, почтовый релей и файловый сервер для одного клиента. Физические машины, не виртуалки - чтобы не смешивать переменные.

Сделали in-place upgrade через centos-upgrade - и пожалели. На одном сервере конфиг postfix после апгрейда требовал ручной правки из-за изменившегося синтаксиса в новой версии. На двух других прошло чище, но мы потратили время на проверку каждого сервиса. Вывод: если есть возможность поставить с нуля и восстановить данные - лучше так. Апгрейд на месте экономит час установки, но добавляет два часа разбирательств.

SELinux включали сразу в enforcing на новых установках. На апгрейднутых машинах сначала permissive, собирали логи недели две, потом переключали. Основные AVC-отказы пришлись на:

• Apache читает файлы вне стандартного httpd_sys_content_t - клиентский контент лежал не там, где ожидал SELinux.
• Postfix и нестандартный путь к очереди - один клиент держал очередь на отдельном разделе.
• Скрипты cron с широкими правами - несколько бэкап-скриптов обращались к /etc, что SELinux резонно не любил.

Всё решилось через restorecon, chcon или audit2allow в зависимости от случая. Суммарно - порядка дня работы на три сервера, включая тестирование.

Что получили

Xen теперь приходит через yum, обновляется вместе с системой, не требует отдельного контроля версий. SELinux в enforcing добавил уровень защиты, о котором не нужно специально думать - он просто работает. Аудит-лог пишется всегда, и если что-то пошло не так - есть запись.

Debian Etch мы тоже используем и менять не планируем - у разных клиентов разные предпочтения, и обе системы сейчас на ядре 2.6.18 с Xen из пакетов. Но для клиентов, которые исторически на RPM-инфраструктуре или имеют опыт с RHEL, CentOS 5 - очевидный выбор для новых серверов.

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