Deconz-rest-plugin: Улучшение поддержки Headless в Linux (зависимости графического интерфейса)

@manup

Я абсолютно согласен с тем, что GUI и безголовые части нужно разделить на два пакета. На самом деле это уже непрерывный внутренний процесс в течение достаточно долгого времени. deCONZ в первые годы своего существования не разрабатывался с учетом безголовых, и теперь у него много смешанных классов, которые нелегко разделить. Этот рефакторинг происходит, но медленными темпами без ETA.

Сам Qt останется в качестве зависимости, но части, связанные с X11/Wayland, не потребуются для безголовой установки.

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

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

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

Я знаю, что существует официальный образ Docker, но, честно говоря, я предпочитаю контейнеры LXC или простые контейнеры systemd-nspawn вместо Docker, и у меня уже были другие контейнеры LXC на моем NAS, поэтому я попытался пойти с этим. В конце концов, эти технологии основаны на одних и тех же механизмах изоляции внутри ядра, поэтому они должны давать сопоставимые результаты — по крайней мере, я так думал.

Я установил контейнер Ubuntu 18.04 и строго следовал руководству по установке ConnBee в отношении установки deCONZ. Затем мне пришлось прыгнуть через несколько обручей, чтобы приложение заработало:

• переадресовать USB-устройство в контейнер LXC ( lxc.cgroup.devices.allow и lxc.mount.entry для узла устройства)
• синхронизируйте GID, чтобы правила udev хоста сделали устройство доступным для группы plugdev внутри контейнера
• удалить возможности из модуля systemd, так как я не хотел, чтобы они были в двоичном файле (в моей конфигурации они все равно не требуются), и LXC заблокировал их (исправимо с помощью lxc.cap.keep )

(OT: Я вижу возможности для улучшения упаковки. Вместо того, чтобы полагаться на жестко закодированный UID 1000, было бы гораздо лучше создать выделенного пользователя во время установки пакета, желательно с UID<1000 и его домашним каталогом ниже /var/lib , чтобы соответствовать тому, как настроены многие другие демоны. С удовольствием отправил бы для этого запросы на вытягивание.)

После этого приложение, похоже, заработало, т.е. оно не выдало никаких ошибок, и я смог настроить базовую конфигурацию шлюза в приложении Phoscon. Однако все, что касалось реального оборудования ConnBee, не работало. Phoscon показывал версию устройства, но не версию прошивки, и все свойства ZigBee (канал и т. д.) были обнулены. Я не мог привязать какие-либо датчики.

В итоге я прошил оставшийся Raspberry Pi 3 официальным _стабильным_ образом. Теперь все работает нормально, и я интегрировал все свои датчики в красивую панель управления Grafana.

(OT: Образ Pi имеет свои собственные глюки, например, в конфигурации по умолчанию он пытался запустить hostapd в бесконечном цикле, который производил около 700 МБ журналов в течение одной недели (бедная SD-карта!) ненужной нагрузки. Я был бы рад отправить пул-реквесты для улучшения настройки (я делаю образы для встроенных устройств в качестве своей дневной работы), но не нашел подходящего репо.)

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

Это была бы мечта