Рекомендации по обновлению ранее не обслуживаемого сервера 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, он не упорядочивает, когда применяет обновления в соответствии с зависимостями. Это вызывало проблемы в прошлом. Я всегда бегаю yum clean all && yum update -y yum && yum update -y glibc && yum update. Это имеет тенденцию заботиться о большинстве потенциальных проблем заказа.

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

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

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

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

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

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