Назад | Перейти на главную страницу

Безопасно ли запускать apt-get update каждую ночь?

Безопасно ли бежать 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, но не в нестабильной ветке или даже в тестовой ветке.

Хотя, когда я надеваю шляпу сисадмина, я считаю, что мне следует вручную применять все обновления, чтобы я мог поддерживать согласованность между серверами, а также чтобы, если однажды служба сломается, я знал, когда я последний раз обновлял это служба. Это то, что я мог бы не проверять, выполняются ли обновления автоматически.

Мы используем стабильную версию и планируем обновление с помощью apt-get на вечер вторника в большинстве наших систем Debian (совпадает с нашими обновлениями Microsoft "patch tuesday"). Это хорошо работает. У нас также есть все события обновления, зарегистрированные в Nagios, поэтому мы можем видеть историю последнего обновления на любом сервере.

Когда вы указываете, что это «производственный» сервер, означает ли это, что существуют также серверы разработки и тестирования? Если это так, исправления следует протестировать на этих системах перед установкой на производственную коробку.

Я бы не стал этого делать. Плохие патчи случаются, и я бы не хотел, чтобы система выходила из строя посреди ночи или пока я был недоступен. Их следует помещать в окно обслуживания, когда администратор доступен для наблюдения за обновлением.

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

Поэтому советую следить за обновлениями.

Если альтернативой является нерегулярное применение обновлений, вы не следите за обновлениями безопасности и используете стабильную версию Lenny, то автоматическое обновление, вероятно, повысит безопасность вашей машины, поскольку вы быстрее обновите известные дыры в безопасности.

У Ubuntu Server есть пакет, который позволит ему автоматически обновлять обновления безопасности. Это также позволяет вам занести в черный список определенные приложения. В нем также говорится об apticron, который отправит вам электронное письмо, когда для вашего сервера появятся обновления.

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

РЕДАКТИРОВАТЬ: Предполагая, что вы используете Ubuntu. Хотя я готов поспорить, что такие же пакеты и решения доступны в Debian.

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

Это зависит от вашей инфраструктуры. Если у меня одна машина, то обычно я просматриваю обновления и смотрю, что мне нужно или чего можно избежать. Если я использую кластер, я иногда выкатываю изменения на одной машине и смотрю, как они идут, а затем выкатываю их на другие машины, если все в порядке.

За обновлениями баз данных я всегда внимательно слежу.

Если у вас есть файловая система, поддерживающая моментальный снимок, может быть действительно полезно сделать снимок системы, применить обновления, а затем иметь возможность откатить изменения, если что-то пойдет не так.

Попробуйте узнать, почему пакет обновляется? это исправление ошибки? исправление безопасности? это локальная команда или удаленная сетевая служба ?. Тестировалось ли программное обеспечение с новыми обновлениями?

К обновлениям ядра следует подходить с большей осторожностью. Попробуй узнать, зачем обновляется ядро? Вам действительно нужны эти изменения? повлияет ли это на ваше приложение. Нужно ли мне применять это для безопасности?

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