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

Безопасно ли запускать apt-get update -ycron на рабочем сервере?

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

У вас есть хорошая система резервного копирования, которая позволит вам быстро вернуться, если что-то сломается?

Перенаправляете ли вы серверные журналы в удаленную систему, чтобы, если коробка не работает, вы все равно знали, что произошло?

Готовы ли вы принять возможность того, что что-то может сломаться, и вам, возможно, придется быстро восстановить / восстановить систему в случае сбоя?

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

Какова роль этой системы? Является ли это чем-то, что едва ли будет пропущено, если он умрет (например, дополнительный 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 «вторник исправлений»). Это хорошо работает. У нас также есть все события обновления, зарегистрированные в Nagios, так что мы можем увидеть историю, когда обновления выполнялись в последний раз на любом сервере.

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

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

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

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

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

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

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

• 8,10
• 9,04
• 9,10

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

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

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

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

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

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

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

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