CentOS 6.1 на новых серверах: upstart, ext4 и SELinux по умолчанию

Когда вышел CentOS 6.0, мы особо не торопились. Первый релиз шестой ветки - это всегда немного авантюра, лучше дать ему отстояться. CentOS 6.1 вышел в начале декабря, и вот тут уже решили: новые серверные проекты разворачиваем на шестёрке. Старые трогать не будем - CentOS 5 ещё живёт и здравствует - но новые стенды поднимаем только на 6.1.

Задокументируем что нашли за первые недели работы с ней на продакшн-серверах.

Init: прощай, SysV

Главное структурное отличие - замена SysV init на upstart. Все скрипты запуска сервисов, которые у нас накопились в /etc/init.d/, технически работают через слой совместимости. Но это именно костыль совместимости, а не полноценная интеграция.

Upstart работает через события: сервис стартует не потому что его номер в runlevel-папке, а потому что произошло событие started network. Звучит разумно, пока не начинаешь отлаживать зависимость между сервисами, которые написаны по-разному - один через нативный job-файл в /etc/init/, другой через старый SysV-скрипт.

Практически это означает: все кастомные init-скрипты пришлось проверить руками. Часть работала нормально через compatibility layer, часть вела себя странно с status и restart. У нас был скрипт запуска одного Java-демона, написанный четыре года назад, - он аккуратно не возвращал правильный exit code на status, и это никогда не мешало на CentOS 5. На шестёрке это вылезло сразу, потому что upstart ориентируется на exit codes.

Новые сервисы пишем сразу как upstart job-файлы. Это чище, чем SysV-скрипты, хотя синтаксис /etc/init/*.conf требует привыкания.

Файловая система: ext4 по умолчанию

CentOS 5 по умолчанию ставил ext3. В шестёрке ext4 из коробки, и это без вопросов правильное решение - журналирование delayed allocation, экстенты вместо блочных карт для больших файлов, fsck работает заметно быстрее на больших томах.

Проблем с ext4 не обнаружили. Единственный момент, который стоит помнить: если хотите XFS или что-то ещё - настраивайте партиционирование руками во время установки, по умолчанию инсталлятор разложит всё на ext4 без лишних вопросов. На KVM-гостях, где мы гибко управляем дисковыми томами, это вполне устраивает.

SELinux: включён и enforcing

Вот где начинается основной квест. В CentOS 5 SELinux был включён по умолчанию, но многие руководства по установке первым делом говорили его отключить - и большинство машин в парке так и жили с SELINUX=disabled. В CentOS 6 он снова включён в enforcing mode, и вот тут надо думать.

Первое, с чем столкнулись - nginx, собранный из исходников в нестандартный prefix, отказывался стартовать. SELinux блокировал попытку биндиться на порт, потому что бинарник не имел нужного контекста. ausearch -c nginx --raw | audit2allow - это теперь наш друг.

Что сделали в итоге. Решили не отключать SELinux - смысл его включения понятен, отключать значит потерять защитный слой. Вместо этого:

• Для стандартных пакетов из репозиториев проблем почти нет - SELinux-политики для них идут в комплекте.
• Для кастомных бинарников и нестандартных путей - аудитируем через audit2why, создаём локальные политики через audit2allow -M.
• Временный permissive режим на период первоначальной настройки, потом обратно в enforcing.

Занимает время, но не катастрофа. Один сервер с кастомным стеком занял полдня, чтобы привести SELinux в состояние, когда всё работает и ничего не блокируется без причины.

Puppet-манифесты: что пришлось поправить

Манифесты, которые мы описывали в посте про Puppet, потребовали правок в нескольких местах.

Управление сервисами. Puppet использует service { 'nginx': provider => 'redhat' } на CentOS 5, а на шестёрке для нативных upstart-сервисов нужен provider => 'upstart'. Для сервисов, которые остались через SysV-скрипты - всё то же самое, но проверять поведение status стоит явно.

SELinux-контексты. Добавили в манифесты управление контекстами через exec { 'restorecon': ... } там, где Puppet кладёт файлы в нестандартные места. Не идеально, но работает.

Firewall. В CentOS 5 все привыкли к iptables напрямую. В шестёрке появился firewalld... нет, это следующий RHEL. В 6.1 iptables на месте, просто конфигурация в /etc/sysconfig/iptables - всё привычно. Но пакет system-config-firewall-tui поменял поведение, так что кастомные правила лучше класть руками, а не через него.

Пакеты. Несколько пакетов переименованы или перемещены между группами. mysql-server теперь требует отдельного mysql как зависимость - это уже в манифесте задать явно, иначе Puppet ставит только серверный пакет без клиентских утилит.

Итог по итогу двух недель

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

Основные временные затраты - SELinux и upstart-скрипты. Оба момента решаемы, просто требуют аккуратности и не прощают подхода «скопировал конфиг с пятёрки и запустил».

Для клиентов на сопровождении серверной инфраструктуры начинаем проставлять 6.1 как базовую OS для новых деплойментов. Миграционный план для существующих машин - отдельный разговор, который пока не торопимся начинать.