Обновления затирают конфиги

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

приложен диагностический архив, доступен только сотрудникам поддержки
(179,5 КБ)

# dpkg --configure -a
Setting up zigbee2mqtt (1.32.1-wb101) ...

Configuration file ‘/mnt/data/root/zigbee2mqtt/data/configuration.yaml’
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.

*** configuration.yaml (Y/I/N/O/D/Z) [default=N] ?

--- /mnt/data/root/zigbee2mqtt/data/configuration.yaml  2023-07-29 19:11:40.469159486 +0300
+++ /mnt/data/root/zigbee2mqtt/data/configuration.yaml.dpkg-new 2023-07-25 11:32:48.000000000 +0300
@@ -1,192 +1,15 @@
-homeassistant: true
+homeassistant: false
 permit_join: false
 mqtt:
   base_topic: zigbee2mqtt
-  server: mqtt://localhost
+  server: 'mqtt://localhost'
 serial:
-  port: /dev/ttyUSB0
-  adapter: auto
-frontend:
-  port: 8081
-  host: 0.0.0.0
+  port: /dev/ttyMOD4

Предыдущая инсталляция:

Start-Date: 2023-07-23  16:25:20
Commandline: apt install zigbee2mqtt
Install: nodejs:armhf (16.18.1-deb-1nodesource1, automatic), zigbee2mqtt:armhf (1.32.1), wb-zigbee2mqtt:armhf (1.3.1, automatic), libatomic1:armhf (10.2.1-6, au
tomatic)
End-Date: 2023-07-23  16:26:04

Текущая:

Start-Date: 2023-07-30  10:43:16
Commandline: apt upgrade
Install: python3-pycares:armhf (3.1.1-1+b3, automatic), python3-cffi-backend:armhf (1.14.5-1, automatic), python3-idna:armhf (2.10-1, automatic)
Upgrade: python3-mqttrpc:armhf (1.2.1, 1.2.2), docker-compose-plugin:armhf (2.19.1-1~debian.11~bullseye, 2.20.2-1~debian.11~bullseye), python3-wb-diag-collect:armhf (1.6.1, 1.7.1), docker-ce-cli:armhf (5:24.0.4-1~debian.11~bullseye, 5:24.0.5-1~debian.11~bullseye), wb-mqtt-homeui:armhf (2.75.1, 2.75.3), wb-nm-helper:armhf (1.27.6, 1.29.1), python3-wb-common:armhf (2.1.1, 2.1.2), wb-configs:armhf (3.18.4, 3.18.7), wb-update-manager:armhf (1.3.1, 1.3.2), python3-wb-update-manager:armhf (1.3.1, 1.3.2), wb-mqtt-serial:armhf (2.91.1, 2.93.2), u-boot-wb7:armhf (2:2021.10+wb1.5.2, 2:2021.10+wb1.6.0), wb-device-manager:armhf (1.5.5, 1.5.6), python3-wb-nm-helper:armhf (1.27.6, 1.29.1), docker-buildx-plugin:armhf (0.11.1-1~debian.11~bullseye, 0.11.2-1~debian.11~bullseye), docker-ce:armhf (5:24.0.4-1~debian.11~bullseye, 5:24.0.5-1~debian.11~bullseye), modbus-utils-rpc:armhf (1.2.1, 1.2.2), wb-essential:armhf (1.17.2, 1.17.3), docker-ce-rootless-extras:armhf (5:24.0.4-1~debian.11~bullseye, 5:24.0.5-1~debian.11~bullseye), wb-utils:armhf (4.11.2, 4.12.0), wb-diag-collect:armhf (1.6.1, 1.7.1), zigbee2mqtt:armhf (1.32.1, 1.32.1-wb101), u-boot-tools-wb:armhf (2:2021.10+wb1.5.2, 2:2021.10+wb1.6.0), wb-release-info:armhf (1.0-testing~wb7+bullseye~20230721073418, 1.0-testing~wb7+bullseye~20230728100032), wb-rules:armhf (2.18.3, 2.18.4), wb-suite:armhf (1.17.2, 1.17.3), python3-wb-test-suite-deps:armhf (1.17.2, 1.17.3), wb-mqtt-logs:armhf (1.4.2, 1.4.3), wb-mcu-fw-updater:armhf (1.8.1, 1.8.2), wb-zigbee2mqtt:armhf (1.3.1, 1.3.2), python3-wb-mcu-fw-updater:armhf (1.8.1, 1.8.2)

Предыдущий раз такое было с wb-mqtt-serial.conf и тоже было связано с добавлением /dev/ttyMOD4
image_2023-07-02_15-02-00

приложен диагностический архив, доступен только сотрудникам поддержки
(199,0 КБ)

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

С уважением.

Добрый день.
То есть apt спрашивает что делать с конфигом

и при выборе “оставить” все равно меняесть на тот что из пакета?

Если нажать N, то оставит, разумеется. Проблема в том, что можно нажать Y, и придётся всё переписывать с нуля.

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

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

Это не user-friendly. Ладно я в линухах понимаю и из бэкапа старый конфиг достану. В чате вон предлагают сделать кнопку “обновить всё и не спрашивать”, которая станет выстрелом себе в голову.

Этак мы к концепции SprutHub придем, когда система лучше знает что нужно ее админу.
Но в мануал добавить неплохо, да: "перед выполнением потенциально опасных операций выполните Резервное копирование настроек контроллера — Wiren Board

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

Вот на днях обновлялся Debian 10 ->12. Система вежливо спрашивала что делать с очередным конфигом - заменить/оставить и прочие варианты. Ну не может разработчик за пользователя решать что с конфигом сделать. Коэн выпустит отличающийся настройками пакет - и?

Эта тема была автоматически закрыта через 7 дней после последнего ответа. В ней больше нельзя отвечать.