После двух лет разработки доступен (https://www.mender.io/blog/announcing-the-production-ready-m...) первый стабильный релиз проекта Mender (https://www.mender.io/), в рамках которого развивается система для организации OTA-обновления (over-the-air) встраиваемых решений и потребительских устройств на базе различных Linux-окружений. Выпуск Mender 1.0 позиционируется как первый, готовый для внедрения в реальных проектах. Код клиентской и серверной частей системы написан на языке Go и поставляется (https://github.com/mendersoftware/) под лицензией Apache 2.0. Целью проекта является упрощение развёртывания инфраструктуры для доставки и установки OTA-обновлений, что даёт возможность разработчикам прошивок сосредоточится на создании продукта, не отвлекаясь на решение задач по распространению обновлений.Mender предоставляет разработчикам серию компонентов, позволяющих развернуть серверы для доставки и сборки атомарно устанавливаемых обновлений, при которых система обновляется целиком. Разработчик формирует обновлённый образ прошивки и добавляет его на управляющий сервер Mender. Предоставляемый проектом инструментарий для сборки обновлений оптимизирован для работы со встраиваемыми дистрибутивами на базе платформы Yocto (http://www.yoctoproject.org/), но он также может быть адаптирован (https://mender.io/blog/porting-mender-to-a-non-yocto-build-s...) для любых других систем сборки дистрибутивов. В качестве примеров доступны два эталонных сценария для платы BeagleBone Black и для виртуального устройства vexpress-qemu. Поддерживается как интерфейс командной строки, так и web-интерфейс для управления распространением обновлений.
На потребительские устройства устанавливается специальный клиентский компонент, который периодически опрашивает сервер и при наличии обновления загружает его. Взаимодействие с сервером осуществляется только по HTTPS, аутентификация сервера выполняется на основе проверки TLS-сертификата, интегрированного в прошивку. Обновление включает полноценный образ корневой файловой системы. Для экономии трафика и сокращения времени загрузки в будущем планируется обеспечить поддержку delta-обновлений, включающих только изменения, относительно прошлого обновления.
Для организации атомарного обновления всей системы на накопителе создаётся два идентичных корневых раздела - активный и пассивный. Новое обновление устанавливается в пассивный раздел, никак не влияя на работу активного. После перезагрузки разделы меняются местами - раздел с новым обновлением становится активным, а прошлый активный раздел переводится в пассивный режим и ожидает установки следующего обновления. Если после обновления что-то пошло не так, осуществляется откат на прошлый вариант прошивки.
URL: https://www.mender.io/blog/announcing-the-production-ready-m...
Новость: http://www.opennet.me/opennews/art.shtml?num=46109
Отличный управляемый ботнет ОС
> аутентификация сервера выполняется на основе проверки TLS-сертификата, интегрированного в прошивку
Значит сначала ждём утечки того самого единственного ключа.
Мастер ключ может быть подписан другим ключем ждем утечки :)
> Отличный управляемый ботнет ОСок, ок
Писал аналогиную штуку для внутреннего употребления. Итог был вот таким (правда требует libcurl):text data bss dec hex filename
14376 500 284 15160 3b38 updaterИнтересно что у хипсторов с их go получилось.
У хипстеров - получилось с открытым кодом
и требуеще покупки нового смарта с 98 ядрами и 2Т оперативки?
Вы на смарте собрались сервер обновлений разворачивать?
Для AVR бутлоадеры пишут с обновлением через например CAN. Размером в байты. Так что ты тоже хипстор со своим libcurl.
>Клиент на Go
>Не поддерживает IGMP
>Не умеет дельта-обновленияДа это просто эталонное ненужно
Зачем дельты обновления на холодильнике? Может вы еще btrfs предложите со снапшотами и шифрованием? Лишь бы чего здриснуть в комментариях.
дристанул и ушел
Традиционно надо добавить, ключевой целью разработки является обеспечение высокой скорости разработки. Производительности уделяется второстепенная роль.