Теория и практика unattended upgrades в Ubuntu

Unattended upgrades — это родной для Debian/Ubuntu (и других основанных на них дистрибутивов GNU/Linux) механизм автоматических обновлений. По умолчанию он включён в системе благодаря наличию установленного пакета unattended-upgrades и конфигурационного файла /etc/apt/apt.conf.d/50unattended-upgrades, а настроен на обновления пакетов только из security-репозитория, куда попадают, например, критичные исправления для пакета libssl, которые выходят в результате очередного пополнения базы уязвимостей CVE.

Примечание: здесь и далее рассматриваются unattended upgrades в контексте серверных редакций Ubuntu, что скорее всего применимо «как есть» и к другим дистрибутивам, но могут встречаться свои особенности, оставшиеся вне рамок статьи.

Итак, какие дополнительные возможности предоставляют unattended upgrades (помимо включённых по умолчанию security updates) и к каким проблемам они могут привести?

Слово «unattended» в названии этого механизма действительно важно в его буквальном переводе — «без присмотра». Почему так? Достаточно вспомнить, что пакеты при установке генерируют файлы .dpkg-new, в которых оказывается новый конфиг для пакета (если контрольная сумма конфига в устанавливаемой пакете отличается от контрольной суммы конфига в системе). Это обстоятельство стоит учитывать, потому что иначе можно получить новую версию софта, которая больше не работает с опцией, добавленной вами в конфиг, и после установки пакета сервис/приложение просто не запустится. Поэтому, собирая или заимствуя пакет в свой репозиторий, помните, что установка такого пакета не обновит конфиги сама, так что, например, если конфиги версий не совместимы (что актуально в случае более значимого обновления, чем исправление в безопасности), может получиться очень неприятная ситуация, когда все давно уже спят, а ваш пакет выкатился на куче серверов и «Всё сломалось, шеф!».

К слову о времени срабатывания unattended upgrades пакетов: проверка обновлений и их установка в системах Ubuntu/Debian определяется в /etc/cron.daily/apt. Файл запускается из /etc/crontab, в котором по умолчанию задано раннее утро (06:25).

Применение для репозитория/PPA

Перейдём к практике. У нас была следующая проблема: один пакет устанавливался на все серверы, но не в родной его версии, а с определенными модификациями. Что делать? Очевидные варианты:

• «Давайте проклянём на несколько часов одного из стажёров и пусть себе выкатывает!» — возможно, это и окажется полезным для стажёра, но только на этапе обучения работы с системой и при условии, что он совсем не умеет работать apt. Дальше это действительно превратится в проклятие. Вдобавок, получаемый результат будет больше зависим от человеческого фактора, чем хотелось бы.
  
  
• «Выкатить везде с Chef/Puppet/Ansible/…!» — отличная мысль, но не наш случай на тот момент и в той ситуации. Ради одного пакета пришлось бы победить дракона, т.е. завести множество машин в выбранную систему управления конфигурациями.
  
  
• Поскольку статья посвящена unattended upgrades, легко догадаться, что именно этот механизм и предлагает иной способ решить задачу, не потратив на неё множество человекочасов…

Действительно: конфигурация unattended upgrades позволяет активировать автоматическое получение всех обновлений какого-либо пакета для выбранного репозитория — например, вашего собственного или PPA, которому вы имеете основания очень доверять. Чтобы вся эта автомагия заработала на минимальном уровне, достаточно на целевой машине создать конфиг /etc/apt/apt.conf.d/51unattended-upgrades-custom, в котором будут всего три строки:

Unattended-Upgrade::Allowed-Origins {
  "Origin:Suite";
};

Если у вас свой репозиторий, то слова Origin и Suite должны как минимум вызывать ассоциации из разряда «Где-то я уже это видел…». Подскажу, что такие параметры можно увидеть у репозитория на самой машине, где должен обновляться пакет, в файле *_InRelease. Иллюстрация для хорошо известной ppa:nginx/stable:

$ head -10 /var/lib/apt/lists/ppa.launchpad.net_nginx_stable_ubuntu_dists_trusty_InRelease 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Origin: LP-PPA-nginx-stable
Label: NGINX Stable
Suite: trusty
Version: 14.04
Codename: trusty
Date: Sat, 11 Feb 2017 21:55:33 UTC
Architectures: amd64 arm64 armhf i386 powerpc ppc64el

Видим два параметра:

• Origin — «происхождение» репозитория, что может указывать на имя мейнтейнера или самого репозитория;
• Suite — ветка дистрибутива; например, stable, testing для Debian или trusty, xenial для Ubuntu.

Примечание: Более подробную документацию по файлам Release/InRelease и используемым в них параметрах см. на wiki.debian.org.

Таким образом, если у вас свой репозиторий пакетов, нужно добавить эти параметры. В результате, для данного примера с PPA nginx/stable конфигурация, разрешающая unattended upgrades для всех пакетов из него, будет выглядеть следующим образом:

Unattended-Upgrade::Allowed-Origins {
  "LP-PPA-nginx-stable:trusty";
};

Эти настройки логично автоматизировать (тем методом, который вам наиболее близок и/или уже используется), создавая все необходимые конфигурационные файлы при разворачивании новых инсталляций ОС. А проверить, как себя поведёт очередной запуск unattended upgrades, можно следующим образом:

$ unattended-upgrade -v --dry-run

Флаги здесь простые: -v — быть более многословным, а --dry-run — не применять изменения. При пробном запуске мы сразу увидим, что у этого решения могут быть обратные стороны:

• Если установка пакета требует интерактивности, т.е. вмешательства пользователя (особенно актуально, если вы делаете масштабное обновление системы, поскольку уже давно этого не делали) — unattended upgrades просто ничего не будут делать.
  
  
• Пример с автоматическим обновлением nginx из PPA не стоит проверять в реальной жизни production, если только вы не хотите прослыть «грязным Гарри» обновления пакетов. Ещё раз вспомните название утилиты и запомните, что обновлять так можно только то, что действительно не требует никакого присмотра. Например, библиотеки (хотя даже тут бывают подводные камни, если вспомнить хотя бы недавние танцы Ubuntu с libc и сломанным DNS resolver) и софт, не требующий конфигурации и запускающийся по требованию (atop, htop и подобные).

Ещё один «обратный» пример, который даже не относится к добавлению специфичных PPA в unattended upgrades, но с которым мы не раз сталкивались на практике, — это обновления безопасности для PostgreSQL. В стандартной конфигурации Ubuntu Server (т.е. установки только обновлений безопасности через unattended upgrades) автоматическое обновление критичных уязвимостей в этой СУБД приводило к её рестарту в то время, когда не все этого ожидали. Если такое поведение может оказаться неожиданным (нежелательным) и для вашего случая — см. опцию Package-Blacklist ниже.

Дополнительные возможности

В /etc/apt/apt.conf.d/50unattended-upgrades можно увидеть, что ещё умеют unattended upgrades. Настроек не так много, но некоторые из них полезны:

• Package-Blacklist — список пакетов, которые запрещено обновлять подобным способом. Тут же нам в примере сразу предлагают это сделать для libc, а выше описан другой пример — с PostgreSQL. Но помните, что на другой чаше весов: откладывая критичные исправления, вы рискуете безопасностью.
• AutoFixInterruptedDpkg — если последний процесс установки/обновления не смог завершиться по каким-либо причинам, вероятно, вам приходилось исправлять ситуацию вручную. То же самое делает и эта опция, т.е. вызывает dpkg --force-confold --configure -a. Обратите внимание, что здесь указана опция --force-confold — она означает, что будут сохранены старые версии конфигов, если возникнут конфликты.
• MinimalSteps — выполнять обновления минимально возможными частями. Позволяет прервать обновление отправкой SIGUSR1 процессу unattended-upgrade.
• InstallOnShutdown — устанавливать обновления перед выключением компьютера. Лично мне кажется плохой идеей, т.к. не хотелось бы получить труп после плановой перезагрузки сервера.
• Mail и MailOnlyOnError — кому отправлять письма об обновлениях и/или проблемах с ними. Письма отправляются через стандартный MTA sendmail (используется переменная окружения SENDMAIL_BINARY). К сожалению, только письма, а выполнять curl к какому-то API здесь нельзя.
• Automatic-Reboot — перезагружать автоматически после окончания установки, если есть файл /var/run/reboot-required. Сам файл появляется, например, после установки пакета ядра Linux, когда срабатывает правило /etc/kernel/postinst.d/update-notifier. В общем, ещё одна опция из набора «грязного Гарри».
• Automatic-Reboot-Time — если вы хотите сделать свои тёмные дела ночью, пока никто не видит… задаёт конкретное время автоматической перезагрузки.
• Acquire::http::Dl-Limit — это уже из общего набора параметров apt. Ограничивает скорость загрузки обновлений, чтобы не забить канал.

Выводы

Unattended upgrades — инструмент автоматической установки обновлений, встроенный в дистрибутивы на базе Debian и Ubuntu. Обычно его используют для установки обновлений безопасности (security updates) из соответствующего репозитория, но легко расширить применение и на любые другие репозитории. Инструмент будет полезен для поддержки простых в установке и обновлении программ и скриптов, собранных в пакеты, — для реализации требуется лишь собственно репозиторий и несколько строк в конфиге на обновляемой машине.

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