Взагалі кажучи, оновлення безпеки, говорячи, вважаються дещо безпечними, особливо для дистрибуції з такими цілями, як 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, але це може означати, що вони не нададуть йому жодної підтримки, якщо не працює.
Також є проблеми з масовим оновленням системи, яка не була виправлена за такий довгий час. Найбільша, з якою я стикався, насправді - це більше проблема управління конфігурацією, яку можна просто посилити великими оновленнями. Іноді конфігураційний файл змінюється, але адміністратор ніколи не перезапускає службу. Це означає, що конфігурація на диску ніколи не була протестована, а запущена конфігурація може більше не існувати. Тож якщо служба перезапуститься, що станеться, коли ви застосуєте оновлення ядра, він може насправді не перезапуститись. Або він може діяти по-різному після його перезавантаження.
Моя порада, було б робити оновлення, але будьте уважні до цього.
- Плануйте це під час вікна технічного обслуговування. Якщо сервер нічого не потребуватиме перезавантаження, було оновлено декілька ядер, і вам доведеться перезавантажити їх, щоб застосувати їх.
- Обов’язково візьміть повну резервну копію, перш ніж робити що-небудь. Це може бути знімком, якщо це VM, запускає повне резервне копіювання будь-якого інструменту, орієнтуючись
/(на іншу систему), знімаючи ddдиски, що завгодно. Тільки до тих пір, поки це щось, з чого можна відновити.
- Сплануйте, як застосувати оновлення. Ви не хочете просто кинути
yum update -yна це і піти геть. На всі хороші речі, які робить yum, він не замовляє, коли застосовує оновлення відповідно до залежностей. Це викликало проблеми в минулому. Я завжди бігаю yum clean all && yum update -y yum && yum update -y glibc && yum update. Це, як правило, опікується більшістю потенційних питань замовлення.
Це також може бути чудовим часом для переформатування. Зараз у нас був RHEL6 досить довго. Залежно від того, що робить цей сервер, може бути доцільним просто дозволити цьому запуститись так, як є, поки ви паралельно створюєте новий екземпляр. Потім після її встановлення ви зможете скопіювати всі дані, протестувати послуги та виконати надрізання. Це також дасть вам змогу знати з самого початку, що система є стандартизованою, чистою, добре документованою та всім цим джазом.
Незалежно від того, чим ви займаєтесь, я вважаю, що це досить важливо, щоб ви отримали навичку до існуючої системи. Вам просто потрібно переконатися, що це зробити так, щоб ви могли довіряти своїй роботі та готовому продукту.