Linux обновление операционных систем

OTA обновление устройств с Linux

Вступление

Недавно у меня возникла задача обновлять удалённо некоторое двузначное число IoT-устройств с Linux через интернет. Задачу нужно было решить быстро. Времени и желания изобретать что-то своё не было совсем. Устанавливать обновления вручную по ssh — нереально. Автоматизировать установку по ssh тоже, устройства могут неожиданно выключаться или терять сеть.

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

end-to-end решение — клиент + сервер + инструменты

A/B обновление rootfs — на устройстве есть два одинаковых раздела rootfs A и B. Система загружается с активного раздела A, устанавливает обновление на раздел B, загружается с раздела B и в случае успеха делает его активным. В случае неудачного обновления активным остаётся раздел A.

работает с debian и yocto

не использует контейнеры

есть open-source версия под лицензией Apache v2

На сайте проекта можно почитать как всё это работает.

Кстати, Mender уже упоминался на хабре в статье @MooooM, но внедрить его тогда не получилось.

Workflow

Я продемонстрирую процесс обновления системы на примере Raspberry Pi 3B c Raspberry Pi OS. Карта памяти от 8 ГБ и выше.

В качестве сервера Mender будем использовать бесплатный демо-сервер hosted.mender.io (не более 10 устройств и 12 месяцев работы).

Подготовка образов будет производится на компьютере с Ubuntu 20.04.

В своей документации Mender рекомендуют примерно такой подход для устройств с debian:

Установка чистой ОС

Подготовка эталонного образа

Копирование эталонного образа на ПК

Преобразование эталонного образа при помощи mender-convert

Подготовка устройства (provisioning)

Подготовка пакета обновления (artifact)

Развёртывание обновления (deploy)

0. Сервер

1. Установка чистой ОС

Включаем последовательную консоль /boot/config.txt : enable_uart=1

2. Подготовка эталонного (golden) образа

Вставляем SD-карту в устройство(Raspberry Pi 3B) и подключаемся по uart при помощи minicom.

Меняем стандартный пароль при помощи raspi-config .

Настройте и проверьте подключение к интернету. Я подключил свою Raspberry по ethernet (не совсем over-the-air, знаю).

Создадим директорию /data , в которой будут храниться данные, которые должны сохраняться при обновлении образа системы.

Положим туда текстовый файл important_file.txt содержащий одну строку hello_habr .

3. Копирование эталонного образа

Выключаем устройство и вставляем SD-карту в компьютер:

Выводим список разделов:

Считываем образ с карты:

4. Преобразование эталонного образа при помощи mender-convert

Для подготовки образа нам понадобится mender-convert и Docker.

Проверяем ёмкость SD-карты, на которую будем устанавливать систему:

Переводим байты в мегабайты: 7910457344 / 1024 / 1024 = 7544 MB

Создаём файл с конфигурацией mender-convert ./configs/raspberrypi3_custom_config с вот таким содержимым:

MENDER_STORAGE_TOTAL_SIZE_MB — общий размер SD полученный ранее

MENDER_DATA_PART_SIZE_MB — размер раздела /data

MENDER_ADDON_CONNECT_INSTALL — флаг установки mender-connect (позволит запускать командную строку на удалённом устройстве и передавать файлы)

Создаём директорию ./rootfs_overlay/etc/mender . Это оверлей файловой системы который будет записан на наш эталонный образ при запуске mender-convert.

Создаём файл конфигурации mender-client ./rootfs_overlay/etc/mender/mender.conf :

TenantToken — токен который нужно посмотреть в hosted.mender.io (Settings->Organization and billing->Organization token).

Создаём файл конфигурации mender-connect ./rootfs_overlay/etc/mender/mender-connect.conf :

Создаём директорию ./input и кладём в неё образ golden-image-1.img полученный ранее.

MENDER_ARTIFACT_NAME — название релиза, которое будет отображаться в hosted.mender.io.

Дальше происходит магия:

в образ устанавливается U-Boot

в Raspberry OS доустанавливается mender-client и mender-connect

создаются A и B разделы rootfs исходя из общего размера SD-карты, а также размера раздела data

данные из директории /data автоматически переносятся на новый раздел, который не будет перезаписываться при обновлении системы

Подробнее можно посмотреть в ./logs/convert.log.XXXX .

На выходе получаем:

./deploy/golden-image-1-raspberrypi3-mender.img — преобразованный образ системы для записи на SD-карту

./deploy/golden-image-1-raspberrypi3-mender.mender — архив с обновлением, который загружается на сервер Mender(519МБ) и потом скачивается устройствами.

5. Подготовка устройства (provisioning)

Записываем образ golden-image-1-raspberrypi3-mender.img на SD-карту:

Теперь разделы выглядят так:

Вывод uart при загрузке (у нас теперь есть U-Boot):

6. Авторизация устройства

Через пару минут после включения устройства на главной странице hosted.mender.io должно появиться сообщение о том, что новое устройство ожидает аутентификации. После подтверждения статус устройства поменяется с pending на accepted.

Через раздел Troubleshoot можно запустить удалённый терминал на устройстве (работает через mender-connect). При этом, на устройстве не включен ssh-сервер. Есть возможность передавать файлы через вкладку File transfer.

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

7. Подготовка пакета обновления (artifact)

Возвращаемся к нашему эталонному образу (golden-image-1.img). Загружаем ОС и вносим необходимые изменения. Я, например, сделаю MQTT-клиента, который шлёт на брокер температуру процессора (под спойлером).

Создаём systemd таймер: /etc/systemd/system/mqtt.timer

Создаём сервис, который будет вызываться таймером mqtt.timer: /etc/systemd/system/mqtt.service

Скрипт, который будет вызываться сервисом mqtt.service: /home/pi/mosquitto_pub.sh

Делаем скрипт исполняемым:

После внесения изменений снова считываем образ с карты:

Преобразовываем образ при помощи mender-convert:

Загружаем в hosted.mender.io новый релиз golden-image-2-raspberrypi3-mender.mender. Заодно можно загрузить первый релиз, если захотим откатиться.

8. Deploy

Развёртывание (deploy) можно создать для отдельного устройства, группы устройств или сразу для всех. После создания развёртывания в течении пяти минут устройство проверит есть ли для него доступное обновление и начнёт загрузку.

После обновления проверим, начало ли устройство отправлять сообщения по MQTT (под спойлером):

Создайте подключение к mqtt://test.mosquitto.org, порт: 1883.

Подпишитесь на топик habr/#

Наблюдаем, как устройство остывает после недавнего апдейта:

Выводы

Mender позволяет довольно легко добавить функцию обновления образа системы по воздуху в существующее устройство.

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

Open-source версия Mender позволяет делать намного больше, чем показано в этой статье, например, state-scripts, identy и inventory устройств и т.д. Open-source версию сервера Mender можно самостоятельно развернуть в облаке используя Kubernetes.

Рекомендую внимательно изучить список фич доступных в open-source и коммерческих версиях. Open-source версия вполне работоспособна, но её может не хватить для того чтобы закрыть все потребности крупного проекта (нет автоматического перезапуска процесса обновления, дельта-апдейтов, мониторинга сервисов и т.д.).

Было бы интересно сравнить Mender c RAUC или swupdate в качестве клиента и hawkBit в качестве бэкенда.

Источник

Легкое обновление Linux

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

В этой статье мы рассмотрим как выполнять обновление Linux, а именно Ubuntu и Debian автоматически с помощью утилиты ucaresystem-core. Эта утилита сама стоит списки пакетов для обновления, обновляет всё необходимое, а также удаляет старые ядра и больше не нужные пакеты.

Установка ucaresystem-core

Первое что нужно сделать — это установить ucaresystem-core. Для этого можно использовать PPA репозиторий:

sudo add-apt-repository ppa:utappia/stable
sudo apt update

Затем установите саму программу:

sudo apt install ucaresystem-core

После установки программа готова к работе.

Обновление Linux в ucaresystem-core

Для запуска обновления просто выполните в терминале:

Сначала инструмент предупредит вас, что обновление пакетов linux начнется через 5 секунд. Затем начнется обновление списков пакетов, и непосредственно обновление системы. Во время работы утилита не требует каких-либо действий от пользователя, так что вы можете продолжить заниматься своими делами. Длительность обновления будет зависеть от количества пакетов, которые необходимо обновить, скорости вашей системы и скорости интернет соединения.

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

Если возможности листать вывод утилиты нет, то можно посмотреть содержимое лога /var/log/dpkg.log. Здесь будет сохранена вся информация об обновленных пакетах.

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

Автоматизация обновления Ubuntu

Поскольку утилите не нужен ввод пользователя чтобы обновить Linux, то обновление программ linux легко автоматизировать с помощью cron. Допустим, вы хотите запускать ucaresystem-core каждую ночь, в полночь. Для этого можно добавить такую инструкцию в crontab:

0 0 * * * /usr/bin/ucaresystem-core

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

Выводы

Вам будет трудно найти более простой способ держать свои системы Linux обновленными и без лишних пакетов чем ucaresystem-core. Конечно, если вы предпочитаете все делать вручную, это более надежный метод. Однако, если у вас не всегда есть время, ucaresystem-core может стать единственным отличным решением. Как часто вы выполняете обновление linux через терминал или в графическом интерфейсе? И каким способом? Напишите в комментариях!

Источник

Обновление ОС

Как правило, возможно обновление установленного дистрибутива ALT Linux до следующей версии без необходимости переустановки заново.

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

Само обновление производится путём указания требуемых репозиториев в файлах /etc/apt/sources.list.d/*.list , /etc/apt/sources.list и выполнения команд apt-get update && apt-get dist-upgrade

либо эквивалентными действиями в графической утилите synaptic ; после чего следует обновить и ядро командой update-kernel (не реализовано в Synaptic).

Если при попытке сделать apt-get dist-upgrade выводится ругань о неудовлетворённых зависимостях, то следует обновить сначала apt и rpm:

В любом случае рекомендуется перед apt-get dist-upgrade обновлять apt и rpm.

Содержание

В любом случае [ править ]

• не смешивайте репозитории различных версий (и особенно с нестабильным Sisyphus)!
• следует указывать один репозиторий (возможно, содержащий несколько компонент или архитектурных разделов)
  не забудьте проверить содержимое /etc/apt/sources.list.d/*.list , среди них несложно пропустить /etc/apt/sources.list.d/sources.list либо /etc/apt/sources.list.d/cdrom.list Как вариант, посредством apt-repo rm all отключить сразу все, это не удалит записи о репозиториях, а лишь закомментирует. После чего вручную подключить (раскомментировать, удалив # в строках) только нужные.
• для смены источника, начиная с p7, так же удобно использовать утилиту apt-repo .

• наиболее общим репозиторием для каждого дистрибутива, начиная с версии 3.0, является соответствующий бранч
• начиная с ветки 4.0, обязательно подключение не только архитектурно-зависимого (i586 или x86_64), но и межархитектурного (noarch) раздела соответствующего репозитория второй строкой
• если используется ПО со связанной ядерной/пользовательской частью (например, драйвер NVIDIA или VirtualBox) — необходимо также выполнить обновление ядра при помощи update-kernel .
• при существенном количестве кандидатов на удаление лучше отказаться от dist-upgrade, перепроверить конфигурацию репозиториев и посоветоваться в рассылке community@
• в ubuntu и ей подобных дистрибутивах принята другая последовательность команд (apt-get update; apt-get upgrade). В дистрибутивах ALT она в общем случае не работает, т.к. не отслеживает изменение зависимостей. Применение такой последовательности команд ведёт к возникновению неисправимых ошибок в зависимостях.

В пределах версии [ править ]

• обновления можно получать из соответствующего дистрибутиву бранча (например, p8/branch для Альт p8 или p5/branch для Альт Линукс Школьный 5.0)

Между версиями [ править ]

• не следует предпринимать «прыжки» дальше, нежели на соседний бранч!
  например, процедура по возможности безболезненного обновления с Server 4.0 на бранч t6 выглядит как цепочка обновлений между ветками: 4.0=>4.1=>5.0=>5.1=>t6 [1]
• перед попыткой перехода между бранчами следует накатить все доступные обновления из текущего (особенно rpm и apt — apt-get update; apt-get install rpm apt )
• подробности перехода уточняйте на соответствующих страничках для p9, p8 и т.д.

apt-get upgrade [ править ]

Несмотря на то, что команда upgrade существует, использовать её следует осторожно, либо не использовать вовсе (altbug #30867). Цитата из «ALT Linux Master 2.0. Руководство системного администратора»:

Для обновления всех установленных пакетов используется команда apt-get upgrade. Она позволяет обновить те и только те установленные пакеты, для которых в репозитариях, перечисленных в /etc/apt/sources.list, имеются новые версии; при этом из системы не будут удалены никакие другие пакеты. Этот способ полезен при работе со стабильными пакетами приложений, относительно которых известно, что они при смене версии изменяются несущественно.

Иногда, однако, происходит изменение в именовании пакетов или изменение их зависимостей. Такие ситуации не обрабатываются командой apt-get upgrade, в результате чего происходит нарушение целостности системы: появляются неудовлетворенные зависимости. Например, переименование пакета MySQL-shared, содержащего динамически загружаемые библиотеки для работы с СУБД MySQL, в libMySQL, отражая общую тенденцию к наименованию библиотек в дистрибутиве, не приводит к тому, что установка обновленной версии libMySQL требует удаления старой версии MySQL-shared. Для разрешения этой проблемы существует режим обновления в масштабе дистрибутива — apt-get dist-upgrade.

Источник