Автообновления безопасности на сервере: частые ошибки и решения

MAATRIX

Автообновления безопасности защищают сервер, но при неправильной настройке приносят свои сюрпризы: то не ставятся вовсе, то перезагружают сервер в разгар работы, то ломают нужный сервис. Разберём частые ошибки автообновлений безопасности на сервере по симптому, причине и решению с командами. Понимание этих граблей превратит автоматику из источника тревоги в надёжного помощника, который работает молча и предсказуемо.

Обновления не устанавливаются автоматически

Частая ситуация: вы установили unattended-upgrades, но обновления не ставятся, и сервер остаётся с уязвимыми пакетами. Причина обычно в том, что автоматика не активирована — пакет установлен, но периодический запуск не включён. Проверьте настройки расписания.

cat /etc/apt/apt.conf.d/20auto-upgrades
systemctl status unattended-upgrades

В файле 20auto-upgrades должны стоять единицы у параметров Update-Package-Lists и Unattended-Upgrade — они включают ежедневную проверку и установку. Если файла нет или значения нулевые, автоматика не работает. Выполните dpkg-reconfigure для unattended-upgrades и включите её, либо создайте файл вручную. Вторая причина — пустой или неверный список Allowed-Origins в файле 50unattended-upgrades: если источники обновлений не заданы или закомментированы все, ставить нечего. Проверьте, что security-репозитории в списке разрешённых. Прогоните тестовый запуск, чтобы увидеть, что попадает под обновление.

unattended-upgrade --dry-run --debug

Сервер сам перезагрузился в рабочее время

Неприятный сюрприз: сервер внезапно перезагрузился среди дня, оборвав работу сервисов и пользователей. Причина — включена автоматическая перезагрузка, но время задано неудачно или не задано вовсе, из-за чего перезагрузка происходит сразу после установки обновления ядра. Для круглосуточного сервиса это недопустимо.

Проверьте настройки перезагрузки в файле 50unattended-upgrades.

grep -i reboot /etc/apt/apt.conf.d/50unattended-upgrades

Если Automatic-Reboot стоит в true без указания безопасного времени, сервер перезагрузится, как только обновление этого потребует. Решений два. Первое — задать время перезагрузки в окно, когда простой приемлем, параметром Automatic-Reboot-Time, например на глубокую ночь. Второе, для сервисов без окна простоя, — отключить автоперезагрузку совсем, поставив Automatic-Reboot в false, и перезагружаться вручную в удобное время. Понять, что перезагрузка требуется, помогает наличие файла-флага, который система создаёт после обновления ядра.

ls -la /var/run/reboot-required

Обновление сломало рабочий сервис

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

Первым делом посмотрите, что именно обновилось, в логе автообновлений.

cat /var/log/unattended-upgrades/unattended-upgrades.log
grep " upgrade " /var/log/dpkg.log

Лог покажет, какие пакеты установились и когда, что помогает связать поломку с конкретным обновлением. Если проблема в свежем пакете, можно откатить его на предыдущую версию, если она есть в кэше apt, и временно зафиксировать через apt-mark hold, чтобы автоматика его больше не трогала до выяснения. На будущее — добавьте критичные для вашего приложения пакеты в список исключений Package-Blacklist в настройках unattended-upgrades, тогда они не будут обновляться автоматически, и вы проверите их обновление вручную. Баланс между безопасностью и стабильностью настраивается именно так.

Ошибка блокировки dpkg или незавершённые обновления

В логе автообновлений появляются ошибки о блокировке dpkg или о том, что предыдущая операция не завершена. Причина — конфликт с другой операцией apt: возможно, вы вручную ставили пакет одновременно с автоматикой, или прошлое обновление прервалось и оставило систему в незавершённом состоянии. Пакетный менеджер блокируется, чтобы две операции не мешали друг другу.

Проверьте и при необходимости завершите зависшую конфигурацию пакетов.

dpkg --configure -a
apt-get -f install

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

Нет уведомлений, и обновления идут вслепую

Автообновления работают, но вы не знаете, что и когда обновляется, — а значит, не заметите проблему вовремя. Это организационная ошибка: автоматику настроили и забыли, без обратной связи. Между тем unattended-upgrades умеет присылать отчёты на почту.

Настройте адрес для уведомлений в файле 50unattended-upgrades.

grep -i mail /etc/apt/apt.conf.d/50unattended-upgrades

Задайте параметр с адресом почты, и система будет присылать отчёт о выполненных обновлениях, а при желании — только при ошибках. Для отправки почты на сервере должен быть настроен способ доставки, хотя бы простой релей. Если почта не вариант, возьмите за правило периодически просматривать лог автообновлений — он хранит всю историю. Слепая автоматика опасна тем, что проблема может копиться незамеченной: вы узнаете о ней, только когда что-то сломается. Обратная связь превращает автообновления в контролируемый процесс.

Автообновления не переживают что-то после переустановки или клонирования

После разворачивания сервера из образа или клонирования автообновления вроде настроены, но не работают. Причина в том, что при клонировании могли не перенестись или сброситься файлы конфигурации, либо системный таймер, запускающий обновления, оказался отключён. Проверьте состояние таймеров systemd, отвечающих за периодические задачи apt.

systemctl list-timers | grep apt
systemctl status apt-daily.timer apt-daily-upgrade.timer

Периодические обновления на современных системах запускаются таймерами apt-daily и apt-daily-upgrade. Если они неактивны, включите их через systemctl enable с параметром запуска. Убедитесь также, что файлы 20auto-upgrades и 50unattended-upgrades на месте и корректны — при клонировании их содержимое стоит перепроверить. После разворачивания нового сервера всегда стоит убедиться, что автообновления реально активны, а не просто числятся установленными, иначе вы будете считать сервер защищённым, а он останется без свежих патчей.

Частые вопросы