Назад | Перейти на главную страницу

Рекомендации по обновлению ранее не обслуживаемого сервера RHEL5.7

Недавно мне передали новый сервер RedHat EL5.6. Сразу очевидно, что в течение предыдущих 12 месяцев практически не уделялось внимания каким-либо обновлениям пакетов.

Обычно я придерживаюсь мнения, что если все в порядке - не чините. Однако после регистрации сервера в RHN, а также использования плагина yum-security для проверки обновлений безопасности доступно чуть более 1100 обновлений безопасности.

У кого-нибудь была подобная ситуация? Я не хочу просто обновлять все, так как мне нравится знать, что обновляется и может ли это повлиять на что-либо, работающее на коробке (это рабочий сервер). Однако, похоже, что следование этой практике потребовало бы от меня изучения 1100 ошибок пакета построчно. Есть ли более эффективное решение?

Вообще говоря, обновления безопасности считаются в некоторой степени безопасными, особенно для дистрибутива с такими целями, как RedHat. Их основная цель - создание согласованной операционной среды. Таким образом, сопровождающие обычно выбирают версии пакетов и остаются с ними надолго. Чтобы понять, что я имею в виду, посмотрите на версии таких пакетов, как kernel, python, perl, и httpd. Что они также делают, так это бэкпорт исправлений безопасности от разработчиков. Таким образом, если уязвимость безопасности обнаружена для всех версий Apache httpd 2.2.x, то Apache Foundation может выпустить версию 2.2.40 с исправлением, но RedHat запустит исправление локально и выпустит httpd-2.2.3-80 с исправлением.

Также имейте в виду, что в настоящее время вы говорите о системе RHEL5.7, текущая версия - 5.9. Некоторые поставщики программного обеспечения поддерживают только определенные дополнительные выпуски. Например, я недавно наткнулся на одно программное обеспечение, которое, по словам производителя, работает только на 5.4. Это не значит не будет работает на 5.9, но это может означать, что они не будут поддерживать его, если не работай.

Также есть опасения по поводу массовых обновлений системы, которая не была исправлена ​​в течение столь долгого времени. Самая большая проблема, с которой я столкнулся, на самом деле больше связана с проблемой управления конфигурацией, которая может только усугубиться большими обновлениями. Иногда файл конфигурации изменяется, но администратор никогда не перезапускает службу. Это означает, что конфигурация на диске никогда не тестировалась, и текущая конфигурация может больше не существовать. Поэтому, если служба будет перезапущена, что произойдет после применения обновлений ядра, она может не перезапуститься. Или это может действовать иначе один раз он перезапускается.

Мой совет: делайте обновления, но будьте осторожны.

  • Распланируйте это на период обслуживания. Если ничего другого сервер не потребует перезапуска, значит, было несколько обновлений ядра, и вам придется перезагрузиться, чтобы применить их.
  • Обязательно сделайте полную резервную копию, прежде чем что-либо делать. Это может быть моментальный снимок, если это виртуальная машина, запуск полного резервного копирования на любом вашем инструменте, резервирование / (в другую систему), взяв dd образ дисков, что угодно. Просто если это то, из чего вы можете восстановить.
  • Планировать как вы применяете обновления. Вы не хотите просто бросить yum update -y на это и уйти. За все хорошее, что делает ням, это делает не порядок, когда он применяет обновления в соответствии с зависимостями. Это вызывало проблемы в прошлом. Я всегда бегаю yum clean all && yum update -y yum && yum update -y glibc && yum update. Это, как правило, решает большинство потенциальных проблем с заказом.

Это также может быть прекрасным временем для смены платформы. У нас уже довольно давно есть RHEL6. В зависимости от того, что делает этот сервер, может иметь смысл просто позволить ему работать как есть, пока вы запускаете новый экземпляр параллельно. Затем, как только он будет установлен, вы можете скопировать все данные, протестировать службы и выполнить вырезку. Это также даст вам возможность узнать с нуля, что система стандартизирована, чиста, хорошо документирована и все такое прочее.

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

По моему опыту, RHEL не нарушает обратную совместимость в обновлениях одного выпуска.

это, однако, не будет распространяться ни на что, что было установлено извне до rpm.

Вы могли бы использовать rpm -qf чтобы найти файлы, которые, как вы подозреваете, скомпилированы извне, если он возвращает «не принадлежит ни одному пакету», то при обновлении могут возникнуть проблемы.

Я бы взял образ сервера и сделал обновление, но я немного более наплевательский, чем большинство.