IT News: Digital Camera, OS, Laptop, Smartphone, Smart TV, Sound...

The Author's Project by Valeri N.Kravchuk
Сайт проверен Dr.Web
Меню сайта
  • Главная страница
  • Информация о сайте
  • Дневник
  • Каталог файлов
  • Обратная связь
  • Каталог сайтов
  • FAQ
  • Доска объявлений
  • Форум
  • Фотоальбом
  • Категории раздела
    Автомобильные гаджеты, ремонт... [220]
    Безопасность IT [484]
    Блоки питания, Power Banks, зарядки... [489]
    Видеорегистраторы [220]
    Гаджеты для спорта и здоровья... [190]
    Гаджеты, аксессуары... [625]
    Измерительная техника, инструменты [444]
    Накопители данных [226]
    Нетбуки, Ноутбуки, Ультрабуки [679]
    Мультиварки, блендеры и не только... [158]
    Планшеты [758]
    Радар-детекторы [26]
    Роботы-пылесосы [37]
    Своими руками [353]
    Сети, сетевые технологии, оборудование... [267]
    Смартфоны [4964]
    Фотокамеры, объективы, искусство фотографии.. [542]
    Умный дом [47]
    Электронные книги [95]
    CB, LPD, PMR- связь... [169]
    DECT, IP-телефоны [18]
    Drones, boats, cars... [108]
    electric cars [35]
    GPS-навигаторы, трекеры... [51]
    Linux и не только [4380]
    mini computers и не только... [409]
    News IT, Это интересно, ликбез... [1112]
    Smart TV, UltraHD, приставки, проекторы... [414]
    Smart Watch [263]
    Sound: наушники, плееры, усилители... [616]
    Windows 10... [298]
    Windows 11 [28]
    Погода

  • Метеорадар БРЕСТ
  • Погода в Бресте от www.yr.no

    Яндекс.Погода БРЕСТ

  • Интересные ссылки

    COMPIZOMANIA

    Наш опрос
    Оцените мой сайт
    Всего ответов: 1338
    Статистика
    Анализ веб сайтов

    Яндекс.Метрика

    Рейтинг@Mail.ru Яндекс цитирования

    Russian America Top. Рейтинг ресурсов Русской Америки.

    eXTReMe Tracker

    Правильный CSS!


    Онлайн всего: 1
    Гостей: 1
    Пользователей: 0
    Locations of visitors to this page
    Форма входа
    Главная » 2017 » Июнь » 13 » Теория и практика unattended upgrades в Ubuntu
    07:48
    Теория и практика unattended upgrades в Ubuntu

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

     

    Автор: @DrDeimos
    Категория: Linux и не только | Просмотров: 449 | Добавил: laptop | Рейтинг: 0.0/0
    Всего комментариев: 0
    Добавлять комментарии могут только зарегистрированные пользователи.
    [ Регистрация | Вход ]
    Волк слабее льва и тигра, но в цирке волк не выступает!
    Волк слабее льва и тигра, но в цирке волк не выступает!
    Волк - единственный из зверей, который может пойти в бой на более сильного противника.
    Если же он проиграл бой, то до последнего вздоха смотрит в глаза противника. После этого умирает...

    Праздники сегодня

    Поиск
    Календарь
    «  Июнь 2017  »
    ПнВтСрЧтПтСбВс
       1234
    567891011
    12131415161718
    19202122232425
    2627282930
    Архив записей
    Друзья сайта
  • Официальный блог
  • JEEP - the best! Mercedes - the best! Автомобильный портал города Бреста: технические характеристики с фото, авторынок, автоспорт...
    Наша кнопка
    IT новости с моего лаптопа...

    Внимание!
    Администратор сайта laptop.ucoz.ru не несет ответственности за содержание рекламных объявлений. Все используемые на сайте зарегистрированные товарные знаки принадлежат своим законным владельцам! Используемая со сторонних источников информация публикуется с обязательными ссылками на эти источники.
    Copyright Valeri N.Kravchuk © 2007-2024