Если вы запускаете автоматические обновления

Я использую производственные веб-серверы Centos. Я хочу знать, что является лучшей практикой для запуска обновлений. Должен ли я автоматизировать это с помощью yum-cron или yum-updatesd? Или существует опасность взлома обновлений сайтов, поэтому было бы лучше обновить на тестовом сервере, а затем запускать обновления вручную еженедельно?

Большинство серверов используют только официальные репозитории, но некоторые имеют атомарный репозиторий для модулей PHP, которые недоступны в противном случае. Что лучше в этом случае? я могу установить yum только для использования Atomic для модулей PHP? Я не хочу, чтобы все обновлялось до самых передовых технологий в Atomic, я скорее доверял бы Centos (или действительно Red Hat), чтобы мои серверы были стабильными и безопасными.

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

Вот несколько вещей для рассмотрения:

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

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

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

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

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

Я согласен на 100% с тем, что Калеб уже сказал. Еще несколько специфичных для CentOS надрезов от меня:

Дистрибутив основан на RedHat и его патчах. Эти патчи были протестированы очень хорошо, и за последние 4 года, когда мы использовали CentOS 5 с 50+ серверами, никогда не было плохих патчей.

НО: хотя мы ежедневно применяем все патчи автоматически к серверам, на которых выполняется только дистрибутив, мы загружаем производственные серверы (после обновления glibc или ядра) только после того, как наши тестовые системы работали в этой конфигурации пару дней.

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

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