Вообще говоря, обновления безопасности считаются в некоторой степени безопасными, особенно для распространения с такими целями, как 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 уже довольно давно. В зависимости от того, что делает этот сервер, возможно, имеет смысл просто позволить этому работать как есть, пока вы параллельно запускаете новый экземпляр. Затем, после установки, вы можете скопировать все данные, протестировать сервисы и выполнить вырезку. Это также даст вам возможность с самого начала узнать, что система стандартизирована, чиста, хорошо документирована и все такое прочее.
Независимо от того, что вы делаете, я чувствую, что очень важно, чтобы вы перешли на текущую систему. Вам просто нужно убедиться, что вы делаете это так, чтобы вы доверяли своей работе и готовому продукту.