Щоб оновити оновлення? Чи ні?

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

По-перше, я не системдмін, і мій досвід роботи з Linux дещо обмежений.

Близько 3-4 місяців тому я з різних причин налаштував сервер CentOS на роботу. Ми використовуємо його як сервер розробки для веб-сайтів (до яких мають клієнти доступ), підривного сервера, і ми розміщуємо там вікі для внутрішнього спілкування, тому він став досить важливим інструментом для нас. (Напевно, важливіше, ніж ми думали, що це буде, коли я його встановив!)

Мені подобається, що Yum хоче оновити близько 250 пакетів до останніх версій репо.

Оскільки сервер працює для нас нормально, чи варто ризикувати оновленням цих пакетів? Чи переважує ризик безпеки ризик зламання сервера, коли я все оновлюю?

Я мушу зазначити, що, хоча у мене є резервне копіювання всього, знадобиться час, щоб все налаштувати так, як це є зараз, і у мене зараз не так багато вільного часу на роботі!

Якщо порада стосується оновлення, чи є найкращі практики, які можна передати, щоб зробити процес максимально безпечним?

Заздалегідь дякую за будь-яку пораду.

ОНОВЛЕННЯ - Дякуємо за всі відповіді. Якби у мене було достатньо представників, які б схвалили всіх, я б. ;) Я вирішив привидів жорсткий диск та оновити. На жаль, одержати системний адміністратор на повний або неповний робочий день на даний момент не є можливим, тому мені просто доведеться розібратися з цим питанням, наскільки я можу!

Швидке та брудне (тобто. Battlefield Administrator) рішення:

1. Візьміть систему в автономному режимі (я сподіваюся, що зможете) і зробіть резервну копію NortonGhost (або щось подібне) на 2-му жорсткому диску.

2. Завантажте другий жорсткий диск (щоб переконатися, що ваша резервна копія справді працює) та зробіть обновку на цьому диску.

3. Якщо все працює ... вітаємо!

4. Якщо він щось накрутить ... продовжуйте і введіть свій ОРИГІНАЛЬНИЙ привід і придумайте "План B".

ОНОВЛЕННЯ:

Я просто подумав, що я згадаю, що справжня проблема полягає в тому, "чи я оновлюю свою застарілу систему, і ризикую її зіпсувати?" чи "Я залишаю свою ідеально хорошу робочу систему незавершеною і ризикую її зламати / зламати?"

Відповідь ... як тільки ви будете виправлені вашою системою через вищезазначені кроки ... спробуйте залишитися на вершині, часто створюючи резервну копію І часто виправляючи її.

Тоді у вас буде найкраще з обох світів. ;-)

Так, оновлення.

RHEL (і, отже, CentOS) дбають про те, щоб не оновлювати версії до чогось несумісного, натомість вони підтримують помилки та виправлення безпеки, тому фактичні зміни пакетів є мінімальними та, ймовірно, не викликають проблем із сумісністю.

Якщо будь-які конфігураційні файли змінилися, пакунки повідомлять вам про створений файл .rpmorig або .rpmnew. Це залежить від конфігурації самого RPM. Ви можете шукати попередження про будь-який із створених і повернути старий конфігурацію назад (" cp foo foo.bak; cp foo.rpmorig foo") або переглянути файли .rpmnew та включити будь-які зміни до своєї конфігурації.

Проблема менш помітна, якщо ви регулярно оновлюєтесь.

У нас багато систем, які оновлюються щоквартально (кожні 3 місяці); і дуже рідко виникають проблеми з оновленнями пакунків. (за винятком систем, які виконують дивні речі з ядром для доступу до LUN з SAN)

Хоча так, на оновлення знадобився б час. І в тій самій садибі знадобиться час, щоб відновити, якщо щось пішло не так. Скільки болю / страждань було б, якби дані з цієї системи були видалені за допомогою експлуатації / злому?

Здебільшого оновлення базових сховищ CentOS безпечні для встановлення. Єдиний раз, коли у мене виникли проблеми з оновленням CentOS, це коли я запускаю / або потрібно використовувати зовнішнє сховище (DAG, RPMForge, Ect тощо).

Кращі настройки для такого роду речей , щоб мати можливість гарячої заміни сервер готовий, так що ви можете перевірити оновлення на ньому , перш ніж розгортати їх на сервер.

Звучить так, що вам потрібен справжній системний адміністратор, щоб зайняти пару годин, щоб переглядати вашу систему, оновити її та переконатися, що все запускається заново. В ідеалі ви хотіли б, щоб ця людина приїжджала і робила це для вас кілька разів на місяць. Сервер - це не річ встановлення "раз і забудь-про-це"; воно потребує регулярного обслуговування.

Якщо ця система настільки важлива, то оновлення безпеки стають все більш важливими. Розглянемо наслідки, якщо цю систему потрібно зняти для відновлення, якщо (коли?) Застарілий пакет дозволяє зробити системний компроміс. В ідеалі, у вас був би тестовий сервер, налаштований аналогічно, який ви могли б оновити спочатку, і перевірте, чи щось зламається.

Застосовуючи оновлення, потрібно переконатися в кількох речах:

1. Час оновлення оприлюднюється для всіх, хто використовує систему
2. У вас є план щодо оновлення та тестування кожної програми
3. У вас є план, як скасувати оновлення, якщо (коли?) Оновлення програє програму
4. І поточні резервні копії існують у випадку, якщо щось піде не так

Хороший сисадмін мав би досвід у такій роботі, і все-таки повинен робити усі ці речі. Якщо у вашої організації є такі, то, можливо, настав час скинути адміністрування системи на них. Або якщо ви нервуєте це робити самостійно, то подумайте про те, щоб найняти когось за контрактом для виконання такого рутинного обслуговування. У будь-якому випадку оновлення повинні відбуватися, оскільки ви відкриваєте себе в набагато гіршій ситуації.

Ось чому сьогодні я майже ніколи не запускаю жодної виробничої системи на реальному обладнання. Я запускаю їх у віртуальних машинах. Тоді під час швидкого простою (5 хвилин) я запускаю знімок із самого ESX, або якщо я використовую власну настройку Xen / Solaris / OpenVZ, роблю знімок LVM зображення сервера. Потім я завантажую оригінал резервного копіювання, і тепер у мене є копія, з якою я можу робити, як мені подобається.

Це було сказано, почніть з оновлення ядра та apache, а потім працюйте звідти назад. Вам не доведеться брати повний список пакетів, про який ви повідомляєте, але верхніми векторами атаки повинні бути ті, які ви переправляєте.

Кожен раз, коли у мене була зламана система Linux, це тому, що я залишив апаш, opensh або саме ядро ​​без виправлення.

Я б просто оновив пов'язані з безпекою пакети.

У мене з'явилася точна річ рік і близько тому ... Я зробив оновлення yum у вікні CentOS, працюючи на апаратному забезпеченні Dell, і встановив ядро, яке не завантажуватиметься. У коробці ще нічого не було завантажено (інакше я був би обережніший). Ви витратили багато часу з цим возитися, і, здається, є якась несумісність між ядрами CentOS / Linux, які я одержали новіше, і цим ящиком Dell. Будьте дуже обережні зі своїми оновленнями. Я все-таки рекомендую оновити, оскільки це правильно робити, але будьте готові до відновлення зі зруйнованої системи!