Включить отключение автоматических обновлений в ubuntu3 мин для чтения

Обновление Ubuntu до новой версии через Менеджер обновлений

Внимание: Процесс обновления Ubuntu до новой версии очень простой. Не пугайтесь количества скриншотов и текста ниже

Мы приводим возможные сообщения, которые могут появиться в процессе обновления.

Шаг 1. Настройки обновления системы

Откройте Лаунчер, нажав сочетание клавиш Super+A, и запустите утилиту Программы и обновления (Software & Updates).

Откроется утилита Программы и обновления. Перейдите на вкладку Обновления и проверьте, что в пункт Уведомлять меня о выходе новой версии Ubuntu (Notify me of a new Ubuntu version) установлен в состояние При доступности любой новой версии (For any new version), если нет, то выберите этот пункт. После этого закройте окно.

Шаг 2. Обновление пакетов (по необходимости)

Запустите Менеджер обновлений Ubuntu. Его можно запустить из Лаунчера (нажав Super+A) и выбрав иконку «Обновление приложений». Перед тем, как обновлять сам дистрибутив до новой версии, может потребоваться обновить пакеты в системе. Поэтому сначала может появиться следующее окно, с предложением обновить пакеты. Нажмите кнопку Установить сейчас, чтобы начать обновление пакетов.

Появится окно для ввода пароля пользователя. Введите пароль. После этого начнется процесс обновления пакетов.

После того, как процесс обновления пакетов завершится, может появиться сообщение о необходимости перезагрузить компьютер. В таком случае перезагрузите компьютер.

Шаг 3. Обновление Ubuntu до новой версии

Снова, как и на предыдущем шаге, запустите Менеджер обновлений Ubuntu (Обновление приложений).

Примечание: Если вдруг снова появилось окно с предложением обновить пакеты, то это означает, что требуется обновить еще некоторые пакеты. Обновите их.

Если вышла новая версия дистрибутива Ubuntu, и ваша система может обновиться до нее, то появится следующее окно. Сообщение вида «Доступен выпуск Ubuntu 19.04 (сейчас установлен 18.10)» информирует вас о том, до какой версии Ubuntu будет обновлена текущая система. Нажмите кнопку Обновить (Upgrade).

Появится запрос на ввод пароля пользователя. Введите пароль и нажмите кнопку Подтвердить.

Появится окно с информацией о версии, до которой будет обновлена текущая система. Нажмите кнопку Обновить.

Начнется подготовка к обновлению системы.

В процессе подготовки может появиться сообщение, информирующее вас о том, что будут отключены некоторые PPA-репозитории (скорее всего вы их добавляли, когда устанавливали какие-нибудь программы). Вы сможете их включить после установки.

Откроется информационное окно, в котором будет показано сколько пакетов будет обновлено и установлено, и сколько мегабайт данных требуется загрузить в процессе обновления. На данном этапе рекомендуется закрыть все открытые программы. Нажмите кнопку Начать обновление.

Появится еще одно информационное сообщение. Ознакомьтесь с информацией и закройте его.

Начнется процесс обновления Ubuntu до новой версии. Процесс может занимать довольно долгое время.

Почти в конце обновления может появиться следующее окно. В нем указано, что будут удалены некоторые пакеты, которые больше не нужны. Нажмите кнопку Удалить.

Когда обновление будет выполнено, появится окно с сообщением о необходимости перезагрузить компьютер. Нажмите кнопку Перезагрузить сейчас.

Начнется перезагрузка компьютера. После перезагрузки вы попадете в новую версию Ubuntu.

Origins Patterns

Origins Pattern is a more powerful alternative to the Allowed Origins option used in previous versions of unattended-upgrade.

Pattern is composed from specific keywords:

• ,, – e.g. , ()
• , – e.g. , , ()
• , – e.g. , ,
• , – e.g. , ,
• , – e.g. , , (this is only supported with >= 0.80)
• – e.g.

You can review the available repositories using and debug your choice using command on a target system.

Additionally unattended-upgrades support two macros (variables), derived from :

• – Installed distribution name, e.g. or .
• – Installed codename, e.g. or .

Using should be preferred over using or as a selected, as once moves to , no security updates will be installed at all, or worse, package from a newer distro release will be installed by accident. The same goes for upgrading your installation from to , if you forget to change this in your origin patterns, you may not receive the security updates for your newer distro release. With , both cases can never happen.

Настройте «автоматические обновления» в Ubuntu

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

sudo dpkg-reconfigure -plow unattended-upgrades

После запуска команды dpkg-reconfigure в терминале появится фиолетовое окно графического интерфейса. В этом окне вы увидите сообщение «автоматически загружать и устанавливать стабильные обновления?» С помощью клавиши Enter выберите «Да». Выбор этой опции включит автоматические обновления в вашей системе Ubuntu Linux.

Настроить подтверждение по электронной почте

Хотя это и не требуется, функцию «автоматических обновлений» можно легко настроить так, чтобы она отправляла электронное письмо перед каждым обновлением, сообщая вам, что ваша система Ubuntu Linux обновляется, и подробно описывая, какие пакеты были обновлены, и т. Д.

Настройка этой функции начинается с запуска окна терминала и открытия файла конфигурации «50unattended-updates». Используя команду ниже, запустите файл конфигурации в текстовом редакторе Nano.

sudo nano -w /etc/apt/apt.conf.d/50unattended-upgrades

В текстовом редакторе Nano найдите Unattended-Upgrade :: Mail и добавьте свой адрес электронной почты, чтобы ваш компьютер с Ubuntu Linux мог отправлять отчет по электронной почте. Конфигурация должна выглядеть точно так, как в примере ниже.

Unattended-Upgrade::Mail ""

Затем найдите Unattended-Upgrade :: MailOnlyOnError и измените его с «true» на «false».

Примечание. Возникли проблемы с поиском Unattended-Upgrade :: Mail в файле конфигурации? Нажмите Ctrl + W, чтобы вызвать функцию поиска в Nano, введите Unattended-Upgrade :: Mail, и курсор переместится прямо к ней!

После настройки вашего адреса электронной почты в файле конфигурации сохраните изменения, нажав Ctrl + O. Закройте Nano с помощью Ctrl + X. Затем откройте «listchanges.conf» и добавьте свой адрес электронной почты в этот файл.

sudo nano -w /etc/apt/listchanges.conf

Еще раз сохраните с помощью Ctrl + O и выйдите с помощью Ctrl + X.

Настроить автоматическую перезагрузку

В Ubuntu Linux для некоторых обновлений программного обеспечения требуется перезагрузка всей системы. К сожалению, перезапуск Ubuntu после обновления утомителен и требует много времени, поэтому, если вы хотите максимально использовать автоматические обновления в Ubuntu, настройка автоматического перезапуска имеет решающее значение.

Предупреждение: настройка автоматической перезагрузки означает, что ваша система будет перезагружаться в любой момент, когда это потребуется, без запроса вашего подтверждения. Если вам неудобно, что ваша машина Ubuntu делает это, пропустите этот раздел.

Настройка автоматического перезапуска в Ubuntu Linux означает повторное редактирование файла конфигурации «50unattended-updates». В терминале откройте файл конфигурации win Nano с помощью приведенной ниже команды.

sudo nano -w /etc/apt/apt.conf.d/50unattended-upgrades

Внутри файла конфигурации найдите «Unattended-Upgrade :: Automatic-Reboot» и измените его с «False» на «True». Затем сохраните изменения в файле конфигурации в текстовом редакторе Nano, нажав Ctrl + O на клавиатуре. Закройте Nano, нажав Ctrl + X.

Тестирование автоматических обновлений Ubuntu

Теперь, когда Ubuntu Linux настроен на автоматическую установку обновлений программного обеспечения на ваш компьютер с Linux, неплохо было бы протестировать его. Чтобы запустить тест, откройте окно терминала и выполните команду unattended-upgradedes с переключателем командной строки «dry-run». Имейте в виду, что этот тест ничего не обновит. Это моделирование, показывающее, как работает система автоматического обновления.

sudo unattended-upgrades --dry-run

Проверка должна занять несколько минут. Когда это будет сделано, проверьте свою электронную почту, чтобы получить отчет.

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

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

очень

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

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

обратные стороны

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

рестарту

3: Обновление и исправление ядра

Ядро системы нужно обновлять реже, чем остальные пакеты. В Linux ядро содержит (почти) все работающие аппаратные драйверы и отвечает за большинство низкоуровневых системных взаимодействий. Обновления ядра обычно необходимы только в том случае, если на сервере обнаружена известная уязвимость, которую необходимо устранить, если вам нужно добавить новую функцию ядра или если ядро ​​ настолько устарело, что появляется больший риск накопления ошибок и уязвимостей.

Универсального метода автоматического планирования обновлений ядра Linux не существует. Это связано с тем, что обновления ядра исторически требовали полной перезагрузки системы, а планирование перезагрузки невозможно без сведений о среде. Как правило, мы ожидаем, что сервер будет обеспечивать круглосуточную доступность, насколько это возможно, а перезагрузка может занять неизвестное количество времени или потребовать ручного вмешательства.

Если ваше приложение готово терпеть некоторое время простоя, обновить ядро ​​несложно: автоматическое обновление apt можно настроить на установку и подготовку новых ядер вместе с другими пакетами, а после перезагрузки ваш сервер должен автоматически использовать новое ядро. В большинстве производственных развертываний требуется дополнительный уровень перезагрузки, чтобы обеспечить доступность сервиса. Например, вы можете использовать балансировщик нагрузки для автоматического перенаправления трафика на серверы, которые могут обеспечить идентичную функциональность в горизонтально масштабируемом развертывании – такие серверы могут перезагружаться последовательно, по отдельности, чтобы избежать простоя.

Включение Livepatch

Чтобы избежать простоев во время обновления ядра, вы можете использовать функцию ядра Linux под названием Livepatch. Эта функция позволяет выполнять обновления ядра без перезагрузки. Есть два основных мейнтейнера: Canonical Livepatch Service для Ubuntu и KernelCare, которая поддерживает Ubuntu в дополнение к большинству других основных дистрибутивов Linux. Использовать обе можно только с регистрацией. Сервис Canonical является бесплатным для индивидуального использования.

Вы можете зарегистрироваться для получения ключа Livepatch здесь. После регистрации вы можете установить пакет canonical-livepatch. Snap — еще один менеджер пакетов Ubuntu, который работает вместе с apt.

Вы можете включить canonical-livepatch с помощью однострочной команды, используя ключ с их веб-сайта:

Выходные данные должны содержать сообщение Successfully enabled device. С этого момента сервис должен работать в фоновом режиме без какого-либо вмешательства, и вы можете проверить его статус, используя команду:

last check: 55 seconds ago
kernel: 5.4.0-26.30-generic
server check-in: succeeded
patch state: ✓ all applicable livepatch modules inserted
patch version: 84.1
tier: updates (Free usage; This machine beta tests new patches.)
machine id: d56589e7fa994005a266d4caf9b9dcf7

Итак, вы настроили автоматическое обновление ядра сервера, а это означает, что больше не нужно перезагружаться, чтобы поддерживать безопасную и актуальную среду.

Why should I use them?

Well, it all depends on your environment and your patching behaviour and probably your (enterprise) processes. I had some discussions with friends and customers of ours, and this is what I’ve heard so far:

Pros for unattended upgrades

• You want your systems always to be up-to-date
• You want your systems always to have the latest security patches
• You don’t want to patch them regularly by hand
• Even if you miss the info of a new vulnerability, you want it to be patched

Cons for unattended upgrades

• You can’t do it, because your enterprise company says you only have a few specific patch windows
• You know your application breaks if you update it automatically
• You want to do everything by hand, or at least invoke an automated upgrade process by hand, so you’ve everything under control
• You’ve a proper vulnerability management and do security upgrades based on this

Never trust a human

I’m more the let’s-do-it-unattended-guy, because IMHO this is the much better option than the rest. I’ve also my issues with the reasons I’ve heard for the cons.

Let me start with the (in my opinion) most obvious problem in refusing unattended upgrades – the human being. We’re bad in doing things properly 100% of the time. We’re humans and this is part of our nature – we’re not perfect and we make mistakes, this is how we learn and evolve. But even more important, we might have bad days, we’re under stress, we’ve a lot of work, we go on vacation and we forget things. Now, what happens if there’s a new vulnerability and you’re just missed or forgot it? What happens if you’re on vacation, or you’ve way too much work to even check into the latest vulnerability? It probably won’t get patched (in time), and I think we all agree that this is really bad! So just having faith in a human operator is a bad decision

Enterprise companies and their policies

As mentioned before, enterprise companies tend to define patch windows, which basically means you can only upgrade a certain server / service in a specific time window. That isn’t very agile, is it? You need to understand the motivation behind this management decisions. A lot of people, especially in management, are afraid of IT issues, such as downtimes. Because of that, they’re scared of changes, and they start to refuse them. Never touch a running system, right?

But what if you can use that fear for your own advantage? What if you show them the downside of this decision? What if you use their fear against them? What if you say them something like:

Just to be clear here, IMHO option A (in general) is the retarded option and only makes sense in some exceptions. You should definitly aim for option B.

Exceptions

Of course, not every environment is as black & white as described here. I just tried to keep it a bit witty. Still, you should try to avoid humans and do it automatically. Regardless of your decision, there might always be some exceptions. But that doesn’t mean you can’t do unattended upgrades for the majority of servers, services or packages.

Getting it up & ready

Installation

Debian already has a nice documentation about unattended upgrades. The documentation is nice and I used it to get it up & running. However, this is just for the basic setup and I had to figure out the deets by myself.

So let’s start by installing the required packages:

apt-get install unattended-upgrades apt-listchanges

• unattended-upgrades is doing the unattended upgrades (obvious, huh?)
• apt-listchanges shows or mails the changes of a package before installing it

Configuration

The configuration files in question are the following:

/etc/apt/apt.conf.d/20auto-upgrades
/etc/apt/apt.conf.d/50unattended-upgrades
/etc/apt/listchanges.conf

First of all the 20auto-upgrades file:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

This basically says do an apt-get update and apt-get upgrade every day, thus the number 1 (n-days) as value.

Next up, the 50unattended-upgrades file:

Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
};

Unattended-Upgrade::Package-Blacklist {
};

Now, in this file you’ve the choice which packages should be upgraded. Debian already explains a lot in the default configuration, which is:

// Lines below have the format format is "keyword=value,...".  A
// package will be upgraded only if the values in its metadata match
// all the supplied keywords in a line.  (In other words, omitted
// keywords are wild cards.) The keywords originate from the Release
// file, but several aliases are accepted.  The accepted keywords are:
//   a,archive,suite (eg, "stable")
//   c,component     (eg, "main", "contrib", "non-free")
//   l,label         (eg, "Debian", "Debian-Security")
//   o,origin        (eg, "Debian", "Unofficial Multimedia Packages")
//   n,codename      (eg, "jessie", "jessie-updates")
//     site          (eg, "http.debian.net")
// The available values on the system are printed by the command
// "apt-cache policy", and can be debugged by running
// "unattended-upgrades -d" and looking at the log file.
//
// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}            Installed origin.
//   ${distro_codename}      Installed codename (eg, "jessie")

Last but not least, the listchanges.conf file:

frontend=pager
confirm=false
email_address=root
save_seen=/var/lib/apt/listchanges.db
which=news

Running it

unattended-ugprades is running automatically and is called via cronjob. You don’t need to install apticron or alike, as mentioned in several other posts.

If you want to debug it, you can easily run it on the CLI via:

unattended-upgrades -d

Logging

If you want to know what was going on, check the logfile located here:

/var/log/unattended-upgrades/

You can also add the following configuration to send you mails when an upgrade occured:

Unattended-Upgrade::Mail "root";
Unattended-Upgrade::MailOnlyOnError "false";

Обновление программ в Ubuntu через менеджер обновлений

В Ubuntu предусмотрен механизм обновления через менеджер обновлений. Это графическая программа, которая запускается время от времени и предлагает обновить систему если были выпущены новые обновления.

Менеджер обновлений Ubuntu довольно прост и вы можете запустить его через главное меню:

Сразу после запуска программа обновит списки программ из репозиториев, чтобы понять есть ли новые версии пакетов:

Если не возникло никаких ошибок связи с сетью или источниками программного обеспечения, вы увидите такое окно:

Программа говорит, сколько обновлений было найдено и сколько данных нужно скачать через интернет.

Осталось нажать кнопку Установить сейчас и начнется обновление пакетов Ubuntu:

Вы можете посмотреть более подробную информацию о процессе обновления:

После завершения обновления программ в ubuntu менеджер обновлений Ubuntu уведомит вас, что все пакеты были обновлены успешно.

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

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

Обновление системы Ubuntu с помощью менеджера обновлений может показаться простым, и это так и есть, пока не возникли ошибки. А при возникновении ошибок нам нужно попытаться обновить систему через терминал, чтобы получить больше информации о проблеме.

Другие инструменты работы с обновлениями

Собственно, Менеджер обновлений — это крайне простой и удобный инструмент, однако как всегда все необходимые действия можно сделать ещё несколькими способами. Во-первых, обновить пакеты можно через Менеджер пакетов Synaptic, помните, я говорил про две кнопочки на панели инструментов?

При нажатии на «Обновить» будут скачаны все изменившиеся с последней проверки индексы репозиториев, таким образом, будет проверено наличие новых обновлений. При нажатии на «Отметить для обновления» будут отмечены для обновления все пакеты, для которых доступны новые версии. Помните, что Synaptic применяет все изменения не сразу? Поэтому для фактического запуска процесса обновления нужно будет нажать на кнопку «Применить».

Кроме того, как всегда всё можно сделать через терминал. Для обновления индексов репозиториев используйте команду

sudo aptitude update

А для непосредственной установки всех доступных обновлений команду

sudo aptitude safe-upgrade

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

Итак, надеюсь теперь вы разобрались в вопросах управления программным обеспечением в Ubuntu. В следующей статье я расскажу поподробней про управление репозиториями:

Репозитории

На самом деле новые версии программ появляются только в сторонних репозиториях, а в стандартные добавляются только обновления безопасности для текущих версий. Чуть подробней про это я расскажу в статье про PPA.

Строго говоря, это не совсем верно. Менеджер обновлений запускается автоматически только при наличии важных обновлений безопасности.

Modifying download and upgrade schedules (on systemd)

Because Debian is using the  systemd  system, it has timers defined for APT use, these files are provided by the apt package.The relevant files are:

• Used for downloads: /lib/systemd/system/apt-daily.timer

  gets overridden by /etc/systemd/system/apt-daily.timer.d/override.conf

• Used for upgrades: /lib/systemd/system/apt-daily-upgrade.timer

  gets overridden by /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf

The canonical steps to create and edit these overrides for these settings are for downloads

# sudo systemctl edit apt-daily.timer
# sudo systemctl restart apt-daily.timer
# sudo systemctl status apt-daily.timer (optional, you can check the next trigger time with this)
or for upgrades
# sudo systemctl edit apt-daily-upgrade.timer
# sudo systemctl restart apt-daily-upgrade.timer
# sudo systemctl status apt-daily-upgrade.timer (optional, you can check the next trigger time with this)

Here is an example of how to override the download time to 1AM by adding the following via sudo systemctl edit apt-daily.timer :

OnCalendar=
OnCalendar=01:00
RandomizedDelaySec=

Line #2 above is needed to reset (empty) the default value shown below in line #5.Line #4 above is needed to prevent any random delays coming from the defaults.

The current default values for downloads are /lib/systemd/system/apt-daily.timer is (at moment of this writing):

Description=Daily apt download activities


OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h
Persistent=true


WantedBy=timers.target

CategoryPackageManagement CategorySystemAdministration

Requirements

The role requires unattended-upgrades version 0.70 and newer, which is available since Debian Wheezy and Ubuntu 12.04 respectively. This is due to usage; if this is not available on your system, you may use the first version of the role.

Automatic Reboot

If you enable automatic reboot feature (), the role will attempt to install package, which is required on some systems for detecting and executing reboot after the upgrade. You may optionally define a specific time for rebooting ().

This feature was broken in Debian Jessie, but eventually was rolled into the unattended-upgrades package; see the discussion in #6 for more details.

Configuration

After installing, it is time to configure the package. Although there aren’t many things to configure, the configuration file is named /etc/apt/apt.conf.d/50unattended-upgrades. By default, only security upgrades will be installed, which is what most people want.

Next step is to configure the package:

Select that you want to have stable packages installed.

Interactive usage

First time when testing the package, use the -v parameter. This will the actions on screen.

Unattended-upgrade in action

Logging

By default all actions are logged to /var/log/unattended-upgrades/unattended-upgrades.log. Information is also available per day, when actual upgrades are found and installed. In this case data is logged to the /var/log/unattended-upgrades directory, with a name similar to unattended-upgrades-dpkg_2015-03-09_18:17:39.573099.log.

Log rotation

Log are rotated via the logrotate service. Usually no action is needed to ensure that the files are rotated as well. It is still advised to check /etc/logrotate.d/unattended-upgrades for more details and confirm things are properly configured.

Rebooting

Although software packages are maintained this way, we still need to reboot systems. The package does actually enable the possibility to reboot the system for you:

If you rather do it manually, use the file /var/run/reboot-required, to determine if a reboot is needed.

Or if you want to know why a reboot is needed, check /var/run/reboot-required.pkgs. Often a reboot is needed due to updates to the Linux kernel, functions (libraries) or other software, which is integrated closely with the kernel.

See our related blog post: how to check for a required reboot for Debian, Ubuntu, and others.

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

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

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

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

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

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

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

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

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

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

• Если установка пакета требует интерактивности, т.е. вмешательства пользователя (особенно актуально, если вы делаете масштабное обновление системы, поскольку уже давно не этого не делали) — unattended upgrades просто ничего не будут делать.

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

Обновление пакетов Ubuntu через Synaptic

Обновлять пакеты Ubuntu можно не только с помощью стандартных пакетных менеджеров. Также есть и сторонние программы. Например Synaptic. Если он у вас еще не установлен, это легко исправить:

Запустить программу можно из главного меню:

Главное окно программы выглядит вот так:

Программа работает не совсем привычным образом. Чтобы выполнить операции над пакетами, необходимо их сначала отметить, а затем уже применить нужную операцию. Такая же ситуация с обновлением.

Но давайте обо всем по порядку, сначала необходимо обновить списки пакетов из репозиториев, чтобы программа узнала, есть ли новые версии, это аналогичное действие команды apt update или, тому что выполняется при старте стандартного менеджера обновлений, так сказать проверка обновлений ubuntu. Откройте меню правка и выберите Обновить сведения о пакетах:

Дальше обновление системы Ubuntu. Как я и сказал, нужно сначала отметить пакеты, с которыми будем работать. Поскольку обновляем все, перейдите на вкладку состояние, установленные и нажмите кнопку Отметить все. Программа сама определит, что для данных пакетов есть обновления и если кроме обновления пакетов ubuntu нужно выполнять дополнительные действия, она покажет их:

Можно пойти другим путем, на той же вкладке нажать Ctrl+A, чтобы отметить все пакеты, затем в контекстном меню выбрать Отметить для обновления:

Независимо от способа, дальше нажимаем Применить:

Программа опять покажет, какие изменения будут внесены в систему, нажмите Apply:

Только теперь начнется загрузка пакетов:

×

После завершения установки обновлений программа выдаст сообщение, что все прошло успешно.

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

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

— список пакетов, которые запрещено обновлять подобным способом. Тут же нам в примере сразу предлагают это сделать для libc, а выше описан другой пример — с PostgreSQL. Но помните, что на другой чаше весов: откладывая критичные исправления, вы рискуете безопасностью.

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

Обратите внимание, что здесь указана опция — она означает, что будут сохранены старые версии конфигов, если возникнут конфликты.

— выполнять обновления минимально возможными частями. Позволяет прервать обновление отправкой SIGUSR1 процессу unattended-upgrade

— устанавливать обновления перед выключением компьютера. Лично мне кажется плохой идеей, т.к. не хотелось бы получить труп после плановой перезагрузки сервера.

и — кому отправлять письма об обновлениях и/или проблемах с ними. Письма отправляются через стандартный MTA sendmail (используется переменная окружения ). К сожалению, только письма, а выполнять curl к какому-то API здесь нельзя.

— перезагружать автоматически после окончания установки, если есть файл . Сам файл появляется, например, после установки пакета ядра Linux, когда срабатывает правило . В общем, ещё одна опция из набора «грязного Гарри».

— если вы хотите сделать свои тёмные дела ночью, пока никто не видит… задаёт конкретное время автоматической перезагрузки.

— это уже из общего набора параметров apt. Ограничивает скорость загрузки обновлений, чтобы не забить канал.

Выводы

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

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