В патчах Ubuntu против Windows нет ничего особенного, RHEL, CentOS, SuSE, debian и т. Д.
Основное состояние ума, в котором вы должны быть при разработке процедуры исправления, - предполагать, что что- то сломается.
Вот некоторые из основных рекомендаций, которые я склонен использовать при разработке установки патча:
- Всегда используйте локальную систему для внутренней централизации в вашей сети, где установлены исправления
Это может включать использование WSUS или зеркал <your_os_here>к внутренней машине управления исправлениями. Предпочтительный, который может централизованно запрашивать и сообщать вам о состоянии исправлений, установленных на ваших отдельных машинах.
- Предварительная установка - когда это возможно - на машинах.
Когда это возможно, по мере выхода исправлений центральный сервер копирует их на отдельные машины. Это действительно просто экономит время, так что вам не нужно ждать, пока они загрузятся и установятся, вы просто должны начать установку во время вашего окна патча.
- Получите окно отключения, чтобы установить исправления, возможно, вам придется перезагрузиться, и что-то, вероятно, сломается. Убедитесь, что заинтересованные лица для этих систем знают, что внедряются исправления. Будьте готовы к тому, что «это» не работает звонками.
В соответствии с моей основной теорией, что исправления ломают вещи, убедитесь, что у вас есть окно отключения, чтобы применять исправления достаточно долго для устранения критических проблем и, возможно, откатить исправление обратно. Вам не нужно, чтобы люди сидели там и тестировали патчи. Лично я сильно полагаюсь на свои системы мониторинга, чтобы сообщить мне, что все работает на самом минимальном уровне, с которым мы можем сойти с рук. Но также будьте готовы к тому, что по мере того, как люди добираются до работы, им нужно вызывать небольшие проблемы У вас всегда должен быть кто-то, кто будет готов ответить на телефонный звонок - предпочтительно не тот, кто до 3 часов чинил ящики.
- максимально автоматизировать
Как и все остальное в IT, сценарий, сценарий, а затем сценарий еще немного. Скрипт загрузки пакета, запуска установки, зеркала. По сути, вы хотите превратить патч-окна в задание по присмотру за детьми, которому просто нужен человек в случае поломки.
- Иметь несколько окон каждый месяц
Это дает вам возможность не исправлять некоторые серверы, если по какой-либо причине они не могут быть исправлены в «назначенную ночь». Если вы не можете сделать их в ночь 1, потребуйте, чтобы они были свободными в ночь 2. Также позволяет сохранить количество исправленных серверов в одно и то же время.
Самое главное не отставать от патчей! Если вы этого не сделаете, вы обнаружите, что должны сделать очень большие 10-часовые патч-окна, просто чтобы вернуться к точке, где вы попали в ловушку. Вводит еще больше моментов, когда что-то может пойти не так, и делает поиск патча более сложным.
Другая часть этой проблемы заключается в том, что идти в ногу с исправлениями - это «хорошо», но исправления выпускаются почти ежедневно. Сколько запланированных отключений нужно сделать, если каждый день будет доступно новое исправление безопасности?
Патчирование сервера один раз в месяц или раз в два месяца - ИМХО - очень достижимая и приемлемая цель. Более того, и вы будете постоянно вносить исправления в серверы, гораздо реже, и вы начинаете сталкиваться с ситуациями, когда вам нужно применять сотни исправлений для каждого сервера.
Сколько окон вам нужно в месяц? Это зависит от вашей среды. Сколько у вас серверов? Какое время требуется вашим серверам?
Меньшие среды, которые имеют размер 9x5, вероятно, могут обходиться без одного окна исправления в месяц. Большим магазинам 24х7 может понадобиться два. Для очень больших 24x7x365 еженедельное окно может потребоваться, чтобы каждую неделю обновлялся различный набор серверов.
Найдите частоту, которая работает для вас и вашего окружения.
Нужно иметь в виду, что достижение 100% -го уровня является невозможной целью - не позволяйте вашему отделу безопасности говорить вам иначе. Делай все возможное, не отставать слишком далеко.
Дела, которые необходимо сделать:
Что следует избегать:
источник
Еще одно замечание: если вы привыкли к Windows, вы удивитесь, что большинство обновлений Linux не требуют простоя или перезагрузки. Некоторые делают, например, обновления ядра. Но обновления, которые требуют перезагрузки или простоя, обычно помечаются как таковые и могут обрабатываться по отдельному расписанию.
источник
checkrestartочень полезна для определения того, какие процессы были обновлены, но все еще необходимо остановить и перезапустить, чтобы получить новый код.Наши машины с Ubuntu работают под управлением версий LTS.
Мы просто автоматически устанавливаем все обновления - конечно, это не «лучшая практика», но мы относительно небольшой магазин и не имеем среды тестирования / разработки / производства для каждого отдельного сервиса. Обновления LTS, как правило, достаточно хорошо протестированы и в любом случае минимально инвазивны.
Обновление до новой версии, очевидно, немного сложнее.
источник
Мы работаем с обновлениями следующим образом для систем Ubuntu LTS:
Следующим логическим шагом для нас является устранение информации о сеансах в памяти, чтобы мы могли просто повторно развертывать инфраструктуру каждый день или даже несколько раз в день, не влияя на клиентов, и исключить этап (2).
Этот подход требует минимального обслуживания и полностью исключает необходимость обслуживания окон.
источник
Одна вещь, которую я бы порекомендовал, это обработка откатов пакетов. Смотрите « Транзакции и откат с Debian», чтобы узнать, как это сделать, так как иногда вам нужно быстрое исправление для обновления, которое что-то ломает.
источник