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 % в безопасности этого действия и это никак не повлияет на продолжительность сна вас и ваших коллег.
Комментарии (8)
amarao
12.06.2017 15:07+5Можно хотя бы один пример security update, который выкатил новую версию, которая приводит к «иначе можно получить новую версию софта, которая больше не работает с опцией, добавленной вами в конфиг»?
За все годы своего администрирования я ни разу не видел в Debian security-фикса, который бы приводил к тому, что софт больше не понимает опцию в конфиге.
И то что вы говорите звучит так, как будто unattended updates сломаны, хотя это не так.
Тяжёлые обвинения требуют серьёзных доказательств, а у вас они не приведены.shurup
12.06.2017 15:58Нет тут тяжёлых обвинений. Цитата, которую вы приводите, не утверждает такого в контексте конкретно security updates — она про «вообще». В следующем после неё предложении написано: «Собирая или заимствуя пакет в свой репозиторий, помните…», — а не «Включая/оставляя unattended upgrades для security updates, помните…».
amarao
12.06.2017 16:08А где у вас про «security updates»? Вот у меня лично сложилось впечатление, что вы пишите это в контексте именно unattended updates.
Более того, я просто не могу иначе интерпретировать написанное. Цитирую:
Итак, какие возможности предоставляют unattended upgrades и к каким проблемам могут привести?
…
Это обстоятельство стоит учитывать, потому что иначе можно получить новую версию софта, которая больше не работает с опцией, добавленной вами в конфиг, и после установки пакета сервис/приложение просто не запустится.
Как это можно прочитать иначе, чем ругань на unattended я не понимаю.
А ведь вся ваша ругань относится к «использовать не по назначению».shurup
12.06.2017 16:17Про «security updates» у нас в самом начале, где рассказывается, что по умолчанию unattended upgrades настроен только на них.
То, что вы называете руганью, таковой тоже не является — ну, я это так не воспринял, например, да и автор, думаю, тоже в виду не имел… Это предупреждение о том, что нужно учитывать, если использовать unattended upgrades не только по умолчанию. И уж точно не «тяжелое обвинение», если читать всё внимательно. В приведённой цитате вы опять упускаете из вида следующее предложение, на которое я уже указал и которое всё уточняет.
На правах редактора исправил «Итак, какие возможности предоставляют…» на «Итак, какие дополнительные возможности предоставляют…». Надеюсь, это снимет возможную двусмысленность для тех, кто читает иначе.
selivanov_pavel
13.06.2017 21:15Увы, не панацея: во-первых, некоторые пакеты при обновлении нагло рестартуют соответствующую службу, тот же nginx например, или что гораздо хуже — mysql. И это никак не отключается, потому что гвоздями прибито в postinst. Во-вторых, после обновления то же библиотеки надо рестартить использующий её софт, потому что в запущенных процессах всё ещё используется старая версия.
Но штука безусловно полезная.
netch80
14.06.2017 08:59> Во-вторых, после обновления то же библиотеки надо рестартить использующий её софт, потому что в запущенных процессах всё ещё используется старая версия.
Так если используется старая — это ещё хорошо :) Хуже, если файл меняется на ходу, а он используется как библиотека. Для основных бинарников это блокируется ядром, для библиотек — не везде. В результате получаем, например, такое (Firefox с обновлённой freetype):
Тут уже зависит от поведения менеджера пакетов.
А необходимость рестарта хорошо отображает, например, zypper (из OpenSuSE). «zypper ps» показывает, кого надо перезапустить по мере возможности.
Аналога для apt что-то не видно (из коробки).
shurup
14.06.2017 12:07Да, про рестарт в статье написано ;-)
[..] это обновления безопасности для PostgreSQL. В стандартной конфигурации Ubuntu Server [..] автоматическое обновление критичных уязвимостей в этой СУБД приводило к её рестарту в то время, когда не все этого ожидали.
houk
НЛО, магическим образом знает, что охота изучить на этой неделе. Автор — спасибо. Доходчиво.