A propos "Dazulernen" ....
... habe die letzten Tage einiges neu dazugelernt und habe nun also meinen Conbee vom "alten" RasPi auf einen unprivilegierten LXC-Container auf meiner Proxmox VE umziehen können: Folgendes war dazu notwendig:
Einrichten eines unprivilegierten LXC-Containers (nesting=1) mit debian und minimal-Ausstattung auf diesem habe ich, wie weiter oben schon mal beschrieben deconz mittels apt installiert (s.a.:
https://phoscon.de/en/conbee/install#ubuntu)
Folgende Pakete musste ich bei mir zuvor noch installieren:
sudo,
lsb-release und
gpg. Weiterhin hat glaube ich initial noch
usbutils gefehlt, was später noch gebraucht wird.
Die Debian-Version ist bei mir jetzt noch eine Buster-Version, da die deconz-Unterstützung derzeit offiziell nur bis Buster angegeben wird.
Wichtig! Wenn deconz so installiert wird, ist anschließend der deconz-Dienst noch nicht aktiviert und läuft auch noch nicht. Das ist ok, das machen wir erst viel später!
Auf dem Container habe ich mir 2 User eingerichtet, einen für mich selbst (benni / uid=1000) und einen für den Betrieb von deconz (deconz / uid=1001).
Meinem User habe ich per visudo (
sudo visudo) sudo-Rechte ohne Passwort auf alles eingerichtet:
benni ALL=(ALL:ALL) NOPASSWD: ALL
Den user deconz-User habe ich der Gruppe dialout hinzugefügt, obwohl das im Falle des Betriebs auf dem LXC-Container egal sein dürfte, da die Rechte auf das USB-Device für den Conbee nachher außerhalb der Containers auf dem Proxmox-Node erfolgt.
sudo gpasswd -a deconz dialout
Vom alten Rechner habe ich mir die Config für den Conbee geholt.
Auf dem alten System habe ich übrigens alles unter dem User pi durchgeführt, der dort ebenfalls sudo rechte hat.
Die anscheinend einzige relevante Datei ist hier die Datei
zll.db unter
.local/share/dresden-elektronik/deConz im Home-Verzeichnis des Users, unter dem deconz dort läuft. Bei mir war das ganz klassisch der user pi (lief auf einem "Standard"-RasPi).
Rausfinden kann man das aber im Zweifelsfall mittels
sudo ps aux|grep deCONZ
Ausgabe ist dann sowas in der Art
root 87 0.0 0.2 3872 2940 ? Ss 17:03 0:00 /bin/bash /usr/bin/deCONZ-update2.sh
pi 88 0.0 4.6 402472 48436 ? Ssl 17:03 0:13 /usr/bin/deCONZ -platform minimal --http-port=80
pi 2860 0.0 0.0 3088 880 pts/3 S+ 17:54 0:00 grep deCONZ
Interessant ist die mittlere Zeile, das ist der deCONZ-Dienst und wie man vorne in der Zeile sieht, läuft der unter dem user pi.
Wie auch immer, ich habe mir die zll.db auf meinen lokalen Client kopiert. Eventuell ist es eine gute Idee, sich eine Sicherung des gesamten dresden-elektronik Ordners zu ziehen. Man weiß ja nie
Nach der Sicherung benötigen wir das alte System nicht mehr, zumindest was deconz anbelangt, also das alte System herunterfahren, bzw. den deconz service auf dem alten System herunterfahren und deaktivieren.
sudo systemctl stop deconz
Am besten dann kurz prüfen, ob die Phoscon - App noch erreichbar ist.
Weiterhin habe ich auch die zugehörigen update und wifi Dienste, die bei mir dazu aktiv waren, heruntergefahren:
sudo systemctl stop deconz-update
sudo systemctl stop deconz-wifi
Die Dienste habe ich dann auch direkt deaktiviert, damit sie nicht bei einem eventuellen reboot des RasPi wieder aktiv werden und möglicherweise dazwischen-funken:
sudo systemctl deacitvate deconz
sudo systemctl deacitvate deconz-update
sudo systemctl deacitvate deconz-wifi
So weit so gut!
Bevor wir weitermachen gehen wir erst mal auf die Shell des Prodxmox-Node (am besten als root), an dem der Conbee nachher angeschlossen werden soll. Dort führen wir einmal lsusb aus um eine Liste der USB-Devices zu haben, bevor der Conbee dran ist, dann lässt sich der nämlich leichter identifizieren.
lsusb
Ergebnis sieht dann in etwa so aus:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Weiterhin schauen wir uns an welche ttyUSB* - Devices wir aktuell unter /dev haben
ls /dev/ttyUSB*
Ergebnis sah bei mir so aus:
crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1
Dann den Conbee vom alten Rechner abziehen und an einen beliebigen USB-Port am Proxmox-Node anschließen und die letzten beiden Schritte wiederholen:
lsusb
Ergebnis sieht dann in etwa so aus:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 007: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Die letzte Zeile ist neu hinzugekommen, also muss das der Conbee sein (bei mir ein Conbee 1, kann sein dass es beim Conbee 2 anders aussieht)
Folgende Informationen benötigen wir für die weitere Konfiguration:
Zum einen die USB-Bus - Informationen, Sprich die USB-Bus-Nummer und die Device-Nummer auf dem Bus. Das ist in obigem Beispiel Der Bus 001 und dort das Device 007 -> Notieren! Brauchen wir nachher noch!
Zum anderen sehen wir hier auch die Vendor-Id und die Product-Id des Conbee das ist in der obigen Ausgabe in der letzten Zeile die 0403:6015, wobei der Teil vor dem Doppelpunkt die Vendor-ID ist (hier als die 0403) und der Teil nach dem Doppelpunkt ist die Product-Id (also die 6015) -> Notieren! Brauchen wir später!
Nun schauen wir an, welchen ttyUSB der Stick belegt, dazu
crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 0 Jan 18 19:15 /dev/ttyUSB0
Aha! In meinem Fall ist also /dev/ttyUSB0 dazugekommen, das wird dann schätzungsweise zum eben neu eingestöpselten Conbee gehören (das legt übrigens auch der Zeitstempel nahe!)
Interessant ist außerdem die 188 -> Notieren! ....
Mit der weiter oben notierten Bus- und Device-Nummer (in meinem Beispiel 001 und 007) lassen wir uns das entsprechende Gerät unter dev noch auflisten
ls -l /dev/bus/usb/001/007
Ausgabe müsste in etwa so aussehen:
crw-rw-r-- 1 root root 189, 6 Jan 18 17:11 /dev/bus/usb/001/007
Interessant ist dabei vor allem die 189 in der Ausgabe. -> Notieren! ....
Wenn wir gerade sowieso auf dem Proxmox-Node sind, passen wir dort nun die Konfigurationsdatei von unserem deconz-Container an.
Dazu benötigen wir die Container-ID, da die den Namen der Konfigurationsdatei darstellt. (Mein Container hat die ID 104 folglich heißt die Datei bei mir 104.conf)
Die Datei findet sich auf dem Node unter
/etc/pve/local/lxc/<CONTAINER-ID>.conf
Editieren mit dem Lieblingseditor (nano / vim.tiny / ...)
Und nun fügen wir folgende Zeilen am Ende ein:
lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/001/007 dev/bus/usb/001/007 none bind,optional,create=file
lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
Wichtig: Diese Zeilen sind nur für mein Beispiel passend. Hier müssen nun die notierten Werte aus den oben Erzeugten Ausgaben übernommen werden.
In die erste Zeile kommt die 189 (die aus der Ausgabe von ls -l /dev/bus/usb/001/007 kommt). Damit erlauben wir dem Container den Zugriff auf USB-Bus-Devices
In der 2. Zeile kommt 2 mal der Bus-Device-Pfad, genau so, wie er beim ls verwendet wurde, damit mounten wir das Bus-Device im Container genau unter den selben Nummern
In der 3. Zeile erlauben wir dem Container den Zugriff auf ttyUSB-Devices (die 188 kommt aus dem ls -l /dev/ttyUSB*)
In der 4. Zeile Mounten wir das ttyUSB0-Device unter demselben Namen im LXC-Container.
Die Änderungen speichern und den LXC-Container (nicht den Proxmox-Node) einmal neu Starten.
Jetzt überprüfen wir im LXC-Container, ob wir den Stick dort auch so Verfügbar haben, wie wir das in der Config-Datei angegben haben. Dazu melden wir uns auf der Konsole/Shell des Containers an und schauen, ob das Bus-Device dort vorhanden ist:
ls -l /dev/bus/usb/001/007
crw-rw-r-- 1 nobody nogroup 189, 6 Jan 18 16:11 /dev/bus/usb/001/007
Sieht gut aus!
Dann ist hoffentlich auch das ttyUSB-Device da:
ls -l /dev/ttyUSB*
crw-rw---- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0
Sieht ziemlich gut aus!
Aber wir sehen hier, dass nur der Eigentümer und die Gruppe Zugriff haben, alle anderen (other) nicht. Leider ist der Eigentümer "nobody" und die Gruppe "nogroup". Das liegt daran, Die User/Gruppen und Berechtigungen vom Host-System nicht an den (unprivilegierten) Container weitergegeben werden können. Man könnte nun recht aufwändig die User und Gruppen mappen um das zu erreichen.
Einfacher ist es aber, auf dem Host-System auch "allen anderen" (other) den Zugriff zu erlauben. Das erreichen wir erst mal durch eine einfache Rechteanpassung auf dem entsprechenden Proxmox-Node:
chmod o+rw /dev/ttyUSB0
Mal sehen, ob das auf dem Proxmox-Noder auch korrekt übernommen wurde:
ls -l /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1
crw-rw-rw- 1 root dialout 188, 0 Jan 18 19:15 /dev/ttyUSB0
Sehr schön, ttyUSB0 darf nun von jedem gelesen und beschrieben werden. Im Moment ist das nur der Fall, so lange der Proxmox-Node nicht neu gestartet wird. Nach einem Reboot hätten wir wieder die alten rechte, also ohne Berechtigung für other.
Schauen wir kurz mal im Container nach, ob das dort durchgeschlagen hat:
ls -l /dev/ttyUSB0
crw-rw-rw- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0
Ta-daa! Prima, jetzt kann auch jeder User im Container von ttyUSB0 lesen und darauf schreiben. Brauchen wir für den Conbee beides
Damit diese Rechtezuweisung auf dem Proxmox-Node auch bei einem Systemneustart erhalten bleibt, bzw. dann wieder automatisch angepasst wird, habe ich eine udev-Regel eingerichtet.
Dazu habe ich auf dem Node Eine Datei unter
/etc/udev/rules.d/
angelegt. Bei mir heißt die Datei schlicht 50-bbusb.rules mit folgendem Inhalt:
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", GROUP="users", MODE="0666"
In der Zeile müssen die weiter oben Ermittelten IDs für die Vendor-Id und die Produckt-Id eingetragen werden.
Damit werden die Rechte für das Device beim Systemstart auf den in Mode eingestellten wert (0666 -> rw-rw-rw).
Damit ist der Conbee dauerhaft an den Container durchgereicht.
Wichtig zu wissen: Wenn der Stick irgendwann umgesteckt wird, teilweise auch nur, wenn er aus und wieder neu eingesteckt wird, ändert sich u.U. die Device-Nummer (007) ggf. auch die Bus-Nummer (001). In diesem Fall muss die LXC-Container-Konfigurationsdatei entsprechend angepasst werden.
So jetzt erst aktivieren und starten wir im LXC-Container den deconz-Dienst:
sudo systemctl enable deconz
sudo systemctl start deconz
jetzt müsste der Dienst laufen und zwar unter dem User mit der uid=1000 (bei mir ist das der User benni)
sudo ps aux|grep deCONZ
root 87 0.0 0.2 3872 2940 ? Ss 17:03 0:01 /bin/bash /usr/bin/deCONZ-update2.sh
benni 88 0.0 4.6 402472 48436 ? Ssl 17:03 0:50 /usr/bin/deCONZ -platform minimal --http-port=80
benni 9779 0.0 0.0 3088 880 pts/3 S+ 20:17 0:00 grep deCONZ
Dienst läuft, unter dem erwarteten User.
Jetzt habe ich in der Service-Datei des deconz-Dienstes 2 Dinge angepasst.
Zum einen die user-Id unter der der Dienst laufen soll. Bei den allermeisten Installationen dürfte der Standardwert mit 1000 passen. Auf einem RasPi ist das i.d.R der user pi.
Die 2. Anpassung war, dass ich das USB-Device, unter dem deconz den Conbee verwenden soll explizit angegeben habe, da die Autoerkennung einfach nicht funktioniert hatte.
Bei oben genannter aktivierung des Dienstes wird der Speicherort der Service-Datei ausgegeben:
/etc/systemd/system/multi-user.target.wants/deconz.service -> /lib/systemd/system/deconz.service
Es ist egal, ob über den symlink oder die Datei direkt editiert wird. Editiert werden muss allerdings mit root-Rechten (sudo)
Die Service-Datei sieht bei mir nach Änderung so aus:
[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service deconz-update.service
StartLimitIntervalSec=0
[Service]
User=1001
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyUSB0
Restart=on-failure
RestartSec=30
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME
[Install]
WantedBy=multi-user.target
Die genannten Änderungen finden sich in den ersten beiden Zeilen in der Seciton [Service]
Um die Änderungen für systemctl zu übernehmen muss jetzt einmal
sudo systemctl daemon-reload
ausgeführt werden.
Jettzt kann der Dienst neu gestartet werden
sudo systemctl restart deconz
Bei mir müsste der Dienst nach der Änderung nun unter dem User deconz (uid=1001) laufen
sudo ps aux|grep deCONZ
root 87 0.0 0.2 3872 2940 ? Ss 17:03 0:01 /bin/bash /usr/bin/deCONZ-update2.sh
deconz 88 0.0 4.6 402472 48436 ? Ssl 17:03 0:55 /usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyUSB0
benni 10727 0.0 0.0 3088 816 pts/3 S+ 20:36 0:00 grep deCONZ
Das sieht gut aus und auch die device-Angabe (dev=...) wurde beim Aufruf übergeben.
Der Dienst wird nun nochmal gestopt:
sudo systemctl stop deconz
Jetzt spielen wir die, vom Altsystem gesicherte zll.db im Container bei dem User ein, unter dem deconz läuft. Bei mir also kommt bei mir die Datei nach
/home/deconz/.local/share/dresden-elektronik/deCONZ
So nun wird der Dienst wieder gestartet
sudo systemctl start deconz
Das sollte es fast gewesen sein.
Wir können uns nun wie gewohnt auf der Phoscon-App auf Container per Browser anmelden.
Alle devices sollten dort sicht- und schaltbar sein.
Als letztes musste ich nun nur noch in meinem FHEM im deCONZ-Device in der DEF die IP-Adresse des LXC-Containers angeben.
Fertig!
Erfolgreich vom Pi nach LXC umgezogen, ohne dass irgendwas neu angelernt werden musste.
Btw.: Ich verwende ausschließlich die Headless-Variante von deconz. Die Gui-Variante habe ich noch nie benutzt oder benützen müssen.
Der Text ist nun doch etwas länger geworden, als ursprünglich gedacht. Es ist ja auch fast schon ein Tutorial geworden und wäre wahrscheinlich auch im Wiki gut aufgehoben. Mal sehen, mache ich vielleicht die Tage auch noch.
Jetzt bin ich jedenfalls erst mal meine Erkenntnisse losgeworden.
Die eigentliche Quint-Essenz für den Thread hier ist: die deconz-Config steckt in der zll.db
Vielleicht ist der Rest auch jemandem nützlich.
gb#
