Чи безпечно запускати оновлення apt-get щовечора?

Чи безпечно бігати apt-get update -yчерез cron на виробничому сервері?

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

Чи є у вас хороша система резервного копіювання, яка дозволить вам швидко відновити, якщо щось зламається?

Ви пересилаєте сервер виходити у віддалену систему, щоб, якщо поле з'явиться внизу, ви все одно будете знати, що сталося?

Чи готові ви прийняти можливість того, що щось може зламатися, і вам, можливо, доведеться зробити швидке відновлення / повернення до системи, якщо щось не вдасться?

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

Яка роль цієї системи? Це щось, що ледве не було б пропущено, якщо він загинув (наприклад, вторинний сервер DNS) або це основний фрагмент вашої інфраструктури (наприклад, сервер LDAP або основний файловий сервер).

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

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

Так, поки ви говорите про оновлення, а не оновлення . Apt навіть зробить це за вас, якщо ви поставите рядок:

APT::Periodic::Update-Package-Lists "1";

у файлі під /etc/apt/apt.conf.d/

Це, як правило, безпечно, але я не рекомендував би його з простої причини:

• Ви втрачаєте відомий стан.

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

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

Нічні оновлення роблять подібний аналіз неможливим або складнішим.

Я можу це зробити на стабільній або на Ubuntu, але не на нестабільній гілці або навіть на тестовій гілці.

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

Ми використовуємо стабільне та заплановане оновлення apt-get на вечір вівторка на більшості наших систем Debian (збігається з нашими оновленнями Microsoft "патч вівторок"). Це добре працює. У нас також усі події оновлення зареєстровані в Nagios, тому ми можемо бачити історію, коли оновлення востаннє проводилися на будь-якому сервері.

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

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

Я пам’ятаю, що робив це на попередній роботі; У мене виникли проблеми на виробничому сервері, оскільки оновлення переписало конфігураційний файл автоматично.

Тому я б радив вам контролювати оновлення.

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

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

Ви можете дізнатися більше про нього на наступних сторінках залежно від того, яку версію Ubuntu Server ви використовуєте.

• 8.10
• 9.04
• 9.10

EDIT: якщо припустити, що ви використовуєте Ubuntu. Хоча я б ставлю на те, що такі самі пакети і рішення доступні на Debian.

Погляньте на cron-apt. Він завантажує лише списки та файли пакунків за замовчуванням, але ви можете налаштувати його для надсилання електронної пошти чи навіть оновлення системи.

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

Оновлення баз даних я завжди пильно стежу.

Якщо у вас є файлова система, яка підтримує швидке зйомка, може бути дуже корисно зробити знімок системи, застосувати оновлення, а потім мати можливість відкосувати зміни, якщо щось жахливо піде не так.

Спробуйте з’ясувати, чому пакет оновляється? це виправлення помилок? виправлення безпеки? це локальна команда або послуга віддаленої мережі ?. Чи перевірено програмне забезпечення з новими оновленнями?

До оновлень ядра слід підходити більш обережно. Спробуйте і з’ясуйте, чому ядро ​​оновлюється? Вам справді потрібні ці зміни? чи вплине це на вашу заявку. Чи потрібно мені це застосувати для безпеки?

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