CentOS 5.2 на кластере: yum, EPEL и правильный порядок апгрейда

CentOS 5.2 вышел в июне, но мы не спешили. Кластер у нас небольшой - четыре узла с KVM, общий NFS-том, Pacemaker в зачаточном состоянии. Полигон не продовый, но и не игрушечный: на нём крутятся тестовые окружения нескольких клиентов. Торопиться с апгрейдом на свежий релиз, когда всё и так работает, - не наша практика.

В сентябре решили, что достаточно подождали. Обновились. И столкнулись ровно с тем, с чем сталкивается любой, кто держит EPEL подключённым на CentOS 5.x: зависимости начинают конфликтовать в самый неожиданный момент.

Предыстория: EPEL на 5.1

EPEL - Extra Packages for Enterprise Linux, репозиторий Fedora-сообщества для RHEL/CentOS - мы подключили ещё на 5.1. Нужен был rsyslog (в базовой поставке CentOS 5.1 его не было), плюс несколько сборок, которые в стандартном репозитории либо отсутствовали, либо были слишком старыми для наших задач. Централизованный rsyslog мы описывали отдельно.

При добавлении EPEL мы прописали его с низким приоритетом через yum-priorities - стандартная практика, чтобы EPEL не перекрывал базовые пакеты. Работало нормально. На 5.1 всё сосуществовало без жалоб.

Что случилось при апгрейде

yum update на первом узле завершился конфликтом зависимостей. Не сразу - сначала прошёл resolving, скачал несколько сотен мегабайт, а потом на этапе transaction check выдал примерно следующее:

Error: rsyslog conflicts with sysklogd
Error: libcurl conflicts with curl

Логика такая: RHEL 5.2 (и, соответственно, CentOS 5.2) обновил несколько пакетов, которые в CentOS 5.1 + EPEL жили рядом спокойно. В частности, базовый репозиторий CentOS 5.2 теперь включает rsyslog - он переехал из EPEL в основной дистрибутив. При этом версия в базовом репозитории отличается от версии в EPEL, и yum не может выбрать победителя без помощи администратора.

Вторая коллизия - curl/libcurl. EPEL держал более свежую libcurl, чем шла в CentOS 5.1. CentOS 5.2 поднял версию в базовом репо выше, чем в EPEL, но при этом имена пакетов чуть разошлись в том, что yum считает «тем же пакетом».

Как фиксировали

Метод грубой силы - yum update --skip-broken - не годится: пропускает проблемные пакеты и оставляет систему в несогласованном состоянии. Мы пошли другим путём.

Первое - отключить EPEL на время апгрейда. Не удалить репозиторий, а временно выключить:

yum-config-manager --disable epel
# или вручную: enabled=0 в /etc/yum.repos.d/epel.repo

После этого yum update обновил базовую систему до CentOS 5.2 без конфликтов. На это уходит большая часть времени - пакетов много.

Второе - отдельно разобраться с пакетами из EPEL. После того как base + updates установились, снова включаем EPEL и смотрим, что с ним теперь:

yum-config-manager --enable epel
yum check

yum check показывает все текущие конфликты и дубли. В нашем случае rsyslog теперь существовал в двух ипостасях: один из base (более старый, как ни странно), один из EPEL. Решение - явно зафиксировать нужную версию:

yum install rsyslog --enablerepo=epel --disablerepo=base

Либо, если устраивает версия из base CentOS 5.2, убираем EPEL-версию:

yum downgrade rsyslog

В нашем случае rsyslog из CentOS 5.2 base оказался новее, чем мы думали, и нас устроил. Мы убрали пакет из EPEL и оставили базовый.

Третье - curl/libcurl. Здесь проблема оказалась в приоритетах: EPEL-версия libcurl имела более высокий epoch, и yum-priorities это не перекрывал. Руками переключили на базовую версию и добавили exclude=curl libcurl в секцию EPEL-репозитория - чтобы не повторять разбирательство при следующем обновлении.

Порядок для повторяемости

Оставшиеся три узла обновляли уже по схеме:

1. yum-config-manager --disable epel - отключить EPEL
2. yum clean all - очистить кеш
3. yum update - обновить до CentOS 5.2 из base + updates
4. Перезагрузка (новое ядро)
5. yum-config-manager --enable epel
6. yum check - проверить конфликты
7. Разобраться с каждым конфликтом явно: либо исключить пакет из EPEL, либо переключить на нужную версию
8. Зафиксировать исключения в конфиге EPEL (exclude=)

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

Что узнали в процессе

EPEL и CentOS - не навсегда спокойные соседи. При каждом минорном релизе RHEL часть пакетов переезжает из EPEL в base. Это хорошо по сути, но конфликты при апгрейде - почти гарантированы, если EPEL подключён и не управляется явно.

exclude= в конфигах репозитория - ваш друг. Если пакет пришёл из EPEL и вы не хотите, чтобы base его перекрывал (или наоборот) - зафиксируйте явно. Неявные приоритеты работают, но не во всех случаях, и поведение при конфликтах epoch бывает нелогичным.

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

Сам CentOS 5.2 пока никаких нареканий не вызвал - ядро 2.6.18, ничего принципиально нового по сравнению с 5.1. KVM работает, NFS работает, сервисы поднялись без вопросов. В сопровождении инфраструктуры мы теперь делаем отдельный шаг «проверка EPEL-конфликтов» частью любого чеклиста апгрейда на RHEL/CentOS - пригодится.