Як часто я повинен оновлювати наш сервер Linux?

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

Тож мені цікаво, як люди, які знають, що роблять, справляються з цим? Як часто ви виконуєте оновлення на своїх серверах? Чи відрізняється процес оновлення між тестом та виробництвом? Чи завжди ви завжди оновлюєте будь-які тестові сервери? А ви робите повне оновлення всього програмного забезпечення чи просто встановлюєте вибрані оновлення?

Запускаю apt-get update -qq; apt-get оновлення -duyq щодня. Це дозволить перевірити наявність оновлень, але не робити їх автоматично.

Тоді я можу запускати оновлення вручну під час перегляду і можу виправити все, що може піти не так.

Окрім проблем безпеки щодо підтримання виправленої системи, я вважаю, що якщо я залишаю її занадто довго між патчами, я закінчую цілою купою пакетів, які хочуть оновити, і це лякає мене набагато більше, ніж просто оновлення однієї або два щотижня або близько того. Тому я, як правило, оновлюю свої оновлення щотижня, або якщо вони є пріоритетними, щодня. Це має додаткову перевагу - знати, який пакет зламав вашу систему (тобто, якщо ви лише оновлюєте пару одночасно)

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

Зважаючи на це, я думаю, що оновлення щось зламало лише один-два рази за останні 4 роки, і це було на високоіндивідуальній системі - так що вам не доведеться бути параноїком TOO :)

Зверху на попередні відповіді - ще кілька конкретно речей Debian: вам слід підписатися на debian-security-оголосити та debian-оголосити та / або перевірити сторінку Debian Security .

Якщо припустити, що ви працюєте з стабільним випуском Debian, більшість патчів будуть пов'язані з безпекою або помилками, що повинно означати, що не буде занадто багато великих змін між версіями будь-якого пакета. Згідно з політикою debian patch, патчі також повинні були проходити тестування протягом певного часу, перш ніж їх перенести в стабільну гілку обслуговувачем. Очевидно, що це не зупинить поломки під час виправлення, але повинно запобігти їх у більшості випадків.

Було б доцільно стежити за тим, щоб ваш тестовий термін постійно оновлювався, а будь-які пакети, які мають помилки, що впливають на вас і ваші сервери, повинні бути в курсі оновлень. Усі пакети, які мають рекомендації щодо безпеки, повинні бути оновлені, як тільки ви знайдете, що виправлення стабільне.

Debian, як правило, дуже стабільна ОС, і не ви повинні надто перейматися поломками, проте завжди читайте те, що буде оновлено, перш ніж оновитись, і слідкуйте за тим, що здається дивним. Я також використовую VCS на своєму / etc / dir, щоб гарантувати, що будь-які зміни конфігураційного файлу можна побачити за допомогою команди "git diff".

Я роблю сухий пробіг (перший), щоб побачити, що буде оновлено. Іноді бібліотеки (давайте назвемо це libfoo для цього прикладу) змінюють свій API, який порушує програми, які ми писали / встановлювали самі. Якщо якась критична бібліотека оновлюється, я захоплюю джерело і намагаюся відновити наші матеріали проти нього до оновлення.

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

Якщо ви системний адміністратор, вам слід перетягувати RSS-канали з таких сайтів, як Secunia , що повинно повідомити вас заздалегідь, якщо ваш дистрибутив буде натискати деякі виправлення.

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

Там, де я працюю, у нас є досить обширний процес, який передбачає використання програмного забезпечення під назвою PatchLink для сповіщення нас про найважливіші оновлення, пов’язані з безпекою, і ми застосовуємо їх після тестування, пакет за пакетом. Однак у нас є тисячі серверів.

Якщо у вас є лише два сервери, процес повинен бути набагато простішим. Хоча я не вважаю, що найкраща ставка для "оновлення / оновлення".

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

Оскільки у вас є тестовий сервер, очевидно, завжди перевіряйте оновлення перед їх застосуванням.

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

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

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

В ідеальній установці у вас можуть бути наступні:

• Засіб начебто комутації серверів (A / B або тик-так). Це означає, що ви оновлюєте його, поки він знаходиться на лавці, а потім просто поміняєте трафік з поточного на новий. Це може бути складніше для таких служб, як бази даних.
• Можливість тестувати оновлення. У вас повинні бути тестові сервери, які практично є клонами виробництва (але без підключення до яких-небудь виробничих послуг). Це дозволить вам спробувати спочатку оновлення.
• Хороша стратегія резервного копіювання, додаткова ідеальна. Ти ніколи не дізнаєшся. Завжди краще бути в безпеці, ніж шкодувати.
• Будьте в курсі, які часи мають найбільшу активність і який рівень простою є допустимим.
• Знайте, як відкатати оновлення чи певний пакет.
• Майте власні дзеркала пакетів, щоб оновлення були послідовними та передбачуваними на всіх серверах. Це перший крок до гідної системи без догляду, якій можна довіряти. Це означає, що ви можете оновити дзеркало, запустити оновлення на одній або декількох тестових машинах, тоді, якщо це добре, нехай воно виходить автоматично. Я чудово провів час, влучно керуючи приблизно 800 машинами EPOS.
• Хороший рівень узгодженості, щоб ви могли знати, що якщо щось тут буде працювати, воно буде працювати там.

Деякі з них можуть бути в різній мірі для невеликих налаштувань, але це слід пам’ятати.

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

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

Мені подобається cron-apt для автоматизації цього процесу, але, як @dinomite вказав на інше питання щодо оновлень, налаштувати його спеціально для автоматизації оновлень, пов’язаних із безпекою, дуже розумна ідея - ви можете вручну оновити те, що вам потрібно. Я використовував cron-apt для всіх оновлень, але насправді змінив це, грунтуючись на його відповіді. Якщо вам це подобається, ви, ймовірно, повинні проголосувати його відповідь, а не за цю.

На debian я встановлюю cron-apt і редагую його файл конфігурації, щоб надіслати мені повідомлення, якщо є якісь зміни. таким чином я отримую сповіщення, якщо є оновлення для моєї системи, і я роблю оновлення вручну

У відповідності з тим же рядком, що і cron-apt, ви повинні подивитися на пакет без нагляду оновлень http://packages.debian.org/lenny/unattended-upgrades .

Його дуже просто налаштувати, і ви зможете автоматично завантажувати та застосовувати оновлення безпеки, але залишати інші оновлення для оновлення вручну (або на ваш розсуд оновити все!).

Офіційний посібник сервера Ubuntu має досить детальний розділ, що охоплює використання пакету без нагляду оновлень https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html

Примітка: залежно від рівня обережності / параноїї, ви можете спочатку здійснити постійне оновлення на групі тестових серверів, потім, якщо проблем немає, дозвольте оновити виробничі коробки, хоча я особисто не стикався з проблемами з оновленнями безпеки. поки що руйнує хаос (стук по дереву) ...

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

Я особисто вимикаю автоматичні оновлення і не регулярно здійснюю будь-яке оновлення пакетів на серверах у моїх середовищах, якщо: (a) є важлива рекомендація CERT щодо одного з пакетів у моїй системі; (b) мені потрібно оновити окремі пакети з конкретних причин; (c) ОС або пакети закінчують цикл, вони більше не підтримуються, і нам потрібно продовжувати підтримувати. Моє міркування полягає в тому, що оновлення, не знаючи, що змінюється або чому залишає занадто багато місця для того, щоб щось зламалося. Я робив подібні речі вже 14 років, і це добре працює.

Окрім речей, про які згадується, ви повинні використовувати якийсь інструмент моніторингу (Nagios або будь-який інший плаваючий човен), щоб попередити вас про оновлення.

Щодо того, як часто йде: Як тільки з’явиться оновлення!