Теория и практика 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 % в безопасности этого действия и это никак не повлияет на продолжительность сна вас и ваших коллег.
    • +33
    • 15,4k
    • 9

    Флант

    337,00

    Специалисты по DevOps и высоким нагрузкам в вебе

    Поделиться публикацией
    Комментарии 9
      +2
      НЛО, магическим образом знает, что охота изучить на этой неделе. Автор — спасибо. Доходчиво.
        +5
        Можно хотя бы один пример security update, который выкатил новую версию, которая приводит к «иначе можно получить новую версию софта, которая больше не работает с опцией, добавленной вами в конфиг»?

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

        И то что вы говорите звучит так, как будто unattended updates сломаны, хотя это не так.

        Тяжёлые обвинения требуют серьёзных доказательств, а у вас они не приведены.
          0
          Нет тут тяжёлых обвинений. Цитата, которую вы приводите, не утверждает такого в контексте конкретно security updates — она про «вообще». В следующем после неё предложении написано: «Собирая или заимствуя пакет в свой репозиторий, помните…», — а не «Включая/оставляя unattended upgrades для security updates, помните…».
            0
            А где у вас про «security updates»? Вот у меня лично сложилось впечатление, что вы пишите это в контексте именно unattended updates.

            Более того, я просто не могу иначе интерпретировать написанное. Цитирую:

            Итак, какие возможности предоставляют unattended upgrades и к каким проблемам могут привести?



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


            Как это можно прочитать иначе, чем ругань на unattended я не понимаю.

            А ведь вся ваша ругань относится к «использовать не по назначению».
              0
              Про «security updates» у нас в самом начале, где рассказывается, что по умолчанию unattended upgrades настроен только на них.

              То, что вы называете руганью, таковой тоже не является — ну, я это так не воспринял, например, да и автор, думаю, тоже в виду не имел… Это предупреждение о том, что нужно учитывать, если использовать unattended upgrades не только по умолчанию. И уж точно не «тяжелое обвинение», если читать всё внимательно. В приведённой цитате вы опять упускаете из вида следующее предложение, на которое я уже указал и которое всё уточняет.

              На правах редактора исправил «Итак, какие возможности предоставляют…» на «Итак, какие дополнительные возможности предоставляют…». Надеюсь, это снимет возможную двусмысленность для тех, кто читает иначе.
          0

          Увы, не панацея: во-первых, некоторые пакеты при обновлении нагло рестартуют соответствующую службу, тот же nginx например, или что гораздо хуже — mysql. И это никак не отключается, потому что гвоздями прибито в postinst. Во-вторых, после обновления то же библиотеки надо рестартить использующий её софт, потому что в запущенных процессах всё ещё используется старая версия.


          Но штука безусловно полезная.

            0
            > Во-вторых, после обновления то же библиотеки надо рестартить использующий её софт, потому что в запущенных процессах всё ещё используется старая версия.

            Так если используется старая — это ещё хорошо :) Хуже, если файл меняется на ходу, а он используется как библиотека. Для основных бинарников это блокируется ядром, для библиотек — не везде. В результате получаем, например, такое (Firefox с обновлённой freetype):

            image

            Тут уже зависит от поведения менеджера пакетов.

            А необходимость рестарта хорошо отображает, например, zypper (из OpenSuSE). «zypper ps» показывает, кого надо перезапустить по мере возможности.
            Аналога для apt что-то не видно (из коробки).
              0
              needrestart
              0
              Да, про рестарт в статье написано ;-)
              [..] это обновления безопасности для PostgreSQL. В стандартной конфигурации Ubuntu Server [..] автоматическое обновление критичных уязвимостей в этой СУБД приводило к её рестарту в то время, когда не все этого ожидали.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое