Conbee/deCONZ im Proxmox LXC-Container (Tutorial) - Versionsgeschichte

Benni am 20. Januar 2022 um 20:44 Uhr

2022-01-20T20:44:45Z

← Nächstältere Version		Version vom 20. Januar 2022, 22:44 Uhr
Zeile 5:		Zeile 5:
	Optional wird im Rahmen des Tutorials die Sicherung und Wiederherstellung der deCONZ-Konfiguration am Beispiel eines Umzugs von einem Raspberry PI auf den LXC-Container gezeigt.		Optional wird im Rahmen des Tutorials die Sicherung und Wiederherstellung der deCONZ-Konfiguration am Beispiel eines Umzugs von einem Raspberry PI auf den LXC-Container gezeigt.

	~~Weiterhins~~ wird in diesem Tutorial der deCONZ-Dienst im LXC-Container im Kontext eines dediziert für diesen Dienst angelegten User ("deconz") ohne besondere Berechtigungen eingerichtet. Auch dieser Teil ist optional.		Weiterhin wird in diesem Tutorial der deCONZ-Dienst im LXC-Container im Kontext eines dediziert für diesen Dienst angelegten User ("deconz") ohne besondere Berechtigungen eingerichtet. Auch dieser Teil ist optional.

	== Verwendete Hard-/Software ==		== Verwendete Hard-/Software ==
Zeile 41:		Zeile 41:
	Benötigt wird ein unprivilegierter LXC-Container mit kleiner Ausstattung (1024 RAM / 2GB Disk) und aktiviertem nesting.		Benötigt wird ein unprivilegierter LXC-Container mit kleiner Ausstattung (1024 RAM / 2GB Disk) und aktiviertem nesting.
	Als Betriebssystem wird Debian 10 (Buster) aus dem entsprechenden Proxmox-Image vorgeschlagen.		Als Betriebssystem wird Debian 10 (Buster) aus dem entsprechenden Proxmox-Image vorgeschlagen.
	Debian 10 deshalb, da die deconz-Unterstützung derzeit offiziell nur bis zu dieser Version ~~angegben~~ wird. Grundsätzlich sollte das aber auch unter Debian 11 (Bullseye) so funktionieren.		Debian 10 deshalb, da die deconz-Unterstützung derzeit offiziell nur bis zu dieser Version angegeben wird. Grundsätzlich sollte das aber auch unter Debian 11 (Bullseye) so funktionieren.

	== Einrichten des Systems auf dem LXC-Container ==		== Einrichten des Systems auf dem LXC-Container ==
Zeile 92:		Zeile 92:
	</syntaxhighlight>		</syntaxhighlight>

	== Sicherung der bestehenden deCONZ-~~Kofiguration~~ (Optional) ==		== Sicherung der bestehenden deCONZ-Konfiguration (Optional) ==

	<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">pi@RasPi </span>		<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">pi@RasPi </span>
Zeile 150:		Zeile 150:
	Das ist derzeit leider nicht mit der Pxoxmox-VE Verwaltung im Web-UI machbar, sondern muss durch manuelle Anpassung der Container-Konfigurationsdatei erfolgen.		Das ist derzeit leider nicht mit der Pxoxmox-VE Verwaltung im Web-UI machbar, sondern muss durch manuelle Anpassung der Container-Konfigurationsdatei erfolgen.

	=== Benötigte USB-Informationen ~~zum~~ ermitteln ===		=== Benötigte USB-Informationen ermitteln ===

	Die im folgenden ermittelten Informationen werden benötigt, um das USB-Gerät an den LXC-Container durchreichen zu können und diesem Zugriff darauf zu gewähren.		Die im folgenden ermittelten Informationen werden benötigt, um das USB-Gerät an den LXC-Container durchreichen zu können und diesem Zugriff darauf zu gewähren.
Zeile 226:		Zeile 226:
	=== Anpassung der Container-Konfiguration ===		=== Anpassung der Container-Konfiguration ===

	Für die Anpassung der Container-~~Konfigurtion~~ muss direkt die Container-~~Konfig-Datei~~ editiert werden. Dazu wird die Container-ID des LXC benötigt, die man am einfachsten aus der Proxmox-Verwaltung liest.		Für die Anpassung der Container-Konfiguration muss direkt die Container-Konfigurationsatei editiert werden. Dazu wird die Container-ID des LXC benötigt, die man am einfachsten aus der Proxmox-Verwaltung liest.

	<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@Node </span>		<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@Node </span>

	Die ~~Konfig-Datei~~ des LXC-Containers befindet sich unter		Die Konfigurationsdatei des LXC-Containers befindet sich unter

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
Zeile 260:		Zeile 260:
	* In der 4. Zeile wird das USB-Serial-Device ttyUSB0 unter demselben Pfad im LXC-Container gemountet.		* In der 4. Zeile wird das USB-Serial-Device ttyUSB0 unter demselben Pfad im LXC-Container gemountet.

	Bei den beiden Mount-Angaben ist der erste Teil immer die Quelle, also der Pfad auf dem Node und der zweite Teil das Ziel, also der Pfad im LXC-Container. Die Devices können bei Bedarf und Wunsch also auch unter anderen Bezeichnungen im LXC-Container verfügbar gemacht werden.		Bei den beiden Mount-Angaben ist der erste Teil immer die Quelle, also der Pfad auf dem Node und der zweite Teil das Ziel, also der Pfad im LXC-Container. Die Devices können bei Bedarf und Wunsch also auch unter anderen Bezeichnungen im LXC-Container verfügbar gemacht werden.

	<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>		<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>
Zeile 297:		Zeile 297:
	=== Anpassung der Berechtigungen auf dem Node ===		=== Anpassung der Berechtigungen auf dem Node ===

	Die letzte Ausgabe ist von zusätzlichem Interesse, denn Dort kann man sehen, dass nur der Eigentümer und die Gruppe Zugriff auf das Gerät haben, alle anderen (other) aber nicht. Leider sind als Eigentümer der User "nobody" und die Gruppe "nogroup" angegeben. Das liegt daran, Die User/Gruppen und Berechtigungen vom Host-System nicht ohne Weiteres an einen (unprivilegierten) Container weitergegeben werden können. Es gibt zwar die Möglichkeit dies durch ein entsprechendes Mapping der uid und gid in der ~~Konfig-Datei~~ des Containers zu erreichen.		Die letzte Ausgabe ist von zusätzlichem Interesse, denn Dort kann man sehen, dass nur der Eigentümer und die Gruppe Zugriff auf das Gerät haben, alle anderen (other) aber nicht. Leider sind als Eigentümer der User "nobody" und die Gruppe "nogroup" angegeben. Das liegt daran, Die User/Gruppen und Berechtigungen vom Host-System nicht ohne Weiteres an einen (unprivilegierten) Container weitergegeben werden können. Es gibt zwar die Möglichkeit dies durch ein entsprechendes Mapping der uid und gid in der Konfigurationsdatei des Containers zu erreichen.
	Einfacher ist es aber, auf dem Node auch "allen anderen" (other) den Zugriff auf das Device zu erlauben. Temporär erreicht man das durch ganz normale Rechteanpassung:		Einfacher ist es aber, auf dem Node auch "allen anderen" (other) den Zugriff auf das Device zu erlauben. Temporär erreicht man das durch ganz normale Rechteanpassung:

Zeile 318:		Zeile 318:
	Genau so soll es sein! Das Device darf nun von jedem gelesen und beschrieben werden.		Genau so soll es sein! Das Device darf nun von jedem gelesen und beschrieben werden.

	Die Rechte müssten auch direkt auf dem Container entsprechend erweitert worden sein. Auch das kann man ~~überprüfuen~~		Die Rechte müssten auch direkt auf dem Container entsprechend erweitert worden sein. Auch das kann man überprüfen

	<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>		<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>
Zeile 338:		Zeile 338:


	Es wird die Datei mit dem ~~Edior~~ angelegt		Es wird die Datei mit dem Editor angelegt

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
Zeile 405:		Zeile 405:
	</syntaxhighlight>		</syntaxhighlight>

	Die genannten Änderungen finden sich in den ersten beiden Zeilen ~~in der Seciton~~ [Service] Beim User stand ursprünglich die uid des Users drin, es ~~sollte aber~~ auch mit dem Usernamen ~~funktionieren~~. Falls nicht, dann gegen die gewünschte uid austauschen.		Die genannten Änderungen finden sich in den ersten beiden Zeilen im Abschnitt [Service] Beim User stand ursprünglich die uid des Users drin, es funktioniert allerdings auch mit dem Usernamen. Falls nicht, dann gegen die gewünschte uid austauschen.

	Nach dem Speichern der Datei muss systemctl dazu aufgefordert werden, die Änderungen zu übernehmen:		Nach dem Speichern der Datei muss systemctl dazu aufgefordert werden, die Änderungen zu übernehmen:
Zeile 462:		Zeile 462:
	</syntaxhighlight>		</syntaxhighlight>

	Jetzt kann man sich wie gewohnt, mit dem Browser an der Phoscon-App auf dem LXC-Container anmelden. Dort sollte dann das "alte" ~~Gatewas~~ zur Auswahl stehen und nach Anmeldung am Gateway sollten auch alle Gruppen, Lichter, Schalter, .... vorhanden und bedienbar sein.		Jetzt kann man sich wie gewohnt, mit dem Browser an der Phoscon-App auf dem LXC-Container anmelden. Dort sollte dann das "alte" Gateway zur Auswahl stehen und nach Anmeldung am Gateway sollten auch alle Gruppen, Lichter, Schalter, .... vorhanden und bedienbar sein.

	== Anpassungen in FHEM (Optional) ==		== Anpassungen in FHEM (Optional) ==

Benni: Die Seite wurde neu angelegt: „Conbee/deCONZ im Proxmox LXC-Container (Tutorial) In diesem Tutorial wird gezeigt, wie sich ein Conbee ZigBee-Gatewas an einen unprivilegierten LXC-Container…“

2022-01-20T19:19:37Z

Die Seite wurde neu angelegt: „Conbee/deCONZ im Proxmox LXC-Container (Tutorial) In diesem Tutorial wird gezeigt, wie sich ein Conbee ZigBee-Gatewas an einen unprivilegierten LXC-Container…“

Neue Seite

Conbee/deCONZ im Proxmox LXC-Container (Tutorial)

In diesem Tutorial wird gezeigt, wie sich ein Conbee ZigBee-Gatewas an einen unprivilegierten LXC-Container in einer Proxmox-VE einrichten und vewenden lässt.

Optional wird im Rahmen des Tutorials die Sicherung und Wiederherstellung der deCONZ-Konfiguration am Beispiel eines Umzugs von einem Raspberry PI auf den LXC-Container gezeigt.

Weiterhins wird in diesem Tutorial der deCONZ-Dienst im LXC-Container im Kontext eines dediziert für diesen Dienst angelegten User ("deconz") ohne besondere Berechtigungen eingerichtet. Auch dieser Teil ist optional.

== Verwendete Hard-/Software ==
(Stand: 18.01.2021)

Conbee (1+2) an unprivilegiertem Proxmox LXC-Container

Proxmox-Version: 7.1.8

deCONZ-Vesion: 2.13.04

== Bezeichnungen und Darstellung ==
Im Tutorial werden zur Kennzeichnung der einzelnen Rechnersysteme, auf denen die jeweiligen Arbeiten durchgeführt werden folgende Rechnerbezeichnungen verwendet:

* "RasPi" - Der Rechner mit der ursprünglich aktiven deCONZ-Installation (war ein Raspberry Pi)
* "LXC" - Der LXC-Container auf den die Neuinstallation von deCONZ kommt
* "Node" - Der Proxmox Node (Hardware) auf dem der LXC-Container betrieben wird und an dem letztendlich der Conbee angesteckt wird.

Im folgenden wird immer angegeben auf welchem Rechner mit welchem User gearbeitet wird unter Angebe von user@host. Wenn also bspw. auf dem neuen Container (LXC) mit dem User "myadmin" gearbeitet werden soll, dann steht zu beginn des entsprechenden Abschitts myadmin@LXC. Das heißt, immer wenn im folgenden Text eine solche Angabe kommt ist der User und/oder der Host entsprechend zu wechseln.

Im wesentlichen werden alle Aktionen ausschließlich auf der Kommmandozeile der jeweiligen Systeme durchgeführt, es sei denn es ist explizit anders angegeben.

In der Regel wird für die Anmeldung an den einzelnen Rechnern ssh verwendet. Bei der Anmeldung als root am Proxmox-Node wird das Shell-Fenster, das über die Proxmox-Verwaltung geöffnet werden kann gearbeitet. Genauso wird für die root-Anmeldung am LXC das Console-Fenster des Containers in der Proxmox-Verwaltung verwendet. In beiden Fällen ist eine Remote-Anmeldung von root per ssh ohne weitere Konfiguration nämlich nicht möglich. Das ist gut und soll auch so bleiben!
Generell spricht natürlich nichts dagegen auch bei der Arbeit mit anderen Usern auf dem LXC das Console-Fenster der Proxmox-Verwaltung zu nutzen.

Der RasPi, also das "Altsystem" ist eine Quasi-Standard-Installation mit Raspian, von daher gibt es dort auch den Standard-User "pi" mit dem dort gearbeitet wird.

Alle im Folgenden dargestellten Ausgaben von Befehlen werden weiß auf schwarz dargestellt und sind grundsätzlich beispielhaft zu verstehen.
Eventuell darin enthaltene Bezeichnungen und IDs können auf einem anderen System anders lauten. Es ist jeweils erklärt, welche Information in der Ausgabe wichtig ist. Dort dann also bitte die individuellen Informationen der eigenen Systeme für die weitere Verarbeitung notieren.

== Anlegen des LXC-Container in der Proxmox PVE ==

Die Erstellung des Containers selbst in der Proxmox-VE ist nicht Teil dieses Tutorials.

Benötigt wird ein unprivilegierter LXC-Container mit kleiner Ausstattung (1024 RAM / 2GB Disk) und aktiviertem nesting.
Als Betriebssystem wird Debian 10 (Buster) aus dem entsprechenden Proxmox-Image vorgeschlagen.
Debian 10 deshalb, da die deconz-Unterstützung derzeit offiziell nur bis zu dieser Version angegben wird. Grundsätzlich sollte das aber auch unter Debian 11 (Bullseye) so funktionieren.

== Einrichten des Systems auf dem LXC-Container ==

root@LXC 

Folgende Pakete, die nicht mit dem Proxmox-Debian-Image kommen werden im weiteren Verlauf benötigt und müssen installiert werden:

<syntaxhighlight lang="bash">
apt install sudo lsb-release gpg usbutils
</syntaxhighlight>

Auf dem Container werden 2 User eingerichtet, einen für die Administration (myadmin / uid=1000) und einen für den Betrieb von deconz (deconz / uid=1001).

<syntaxhighlight lang="bash">
adduser deconz
adduser myadmin
</syntaxhighlight>

Der myadmin-User bekommt per sudo allumfassende Berechtiung ohne Passwort auf alles. Dazu muss die sudoers-Datei mit folgendem Befehl zur Bearbeitung geöffnet:

<syntaxhighlight lang="bash">
visudo
</syntaxhighlight>

folgende Zeile muss in die Datei eintragen werden

<syntaxhighlight lang="bash">
myadmin ALL=(ALL:ALL) NOPASSWD: ALL
</syntaxhighlight>

Ab jetzt kann für die weitere Einrichtung auf dem LXC-Container der User myadmin verwendet werden.

== Installation von deCONZ im LXC-Container ==

myadmin@LXC 

deCONZ wird nach Anleitung bei dresden-elektronik mittels apt installiert (s.a.: https://phoscon.de/en/conbee/install#ubuntu)

Wichtig! Wenn deCONZ so installiert wird, ist anschließend der deconz-Dienst noch nicht aktiviert und läuft folglich auch noch nicht. Das wird im späteren Verlauf nachgeholt.

Der deconz-User soll laut der deCONZ-Installationsanleitung (s.w.u.) der Gruppe dialout hinzugefügt werden.
Für den Betrieb auf dem LXC-Container sollte das aber egal sein. Die Rechte auf das USB-Device werden im späteren Verlauf außerhalb der Containers auf dem Proxmox-Node zugewiesen.

Nichts desto trotz:

<syntaxhighlight lang="bash">
sudo gpasswd -a deconz dialout
</syntaxhighlight>

== Sicherung der bestehenden deCONZ-Kofiguration (Optional) ==

pi@RasPi 

Für die Übertragung der deCONZ-Konfiguration wird vom Altsystem die Datei "zll.db" gesichert. In diesem Datenbank-File sind alle relevanten Informationen für deCONZ enthalten, inkl. Geräte, Gruppen, etc.

Die Datei befindet sich in einem Ordner Home-Verzeichnis des Users, unter dem der deCONZ-Dienst auf dem RasPi läuft. Das ist im Normalfall ebenfalls der User "pi"

Prüfen kann man das wie folgt:

<syntaxhighlight lang="bash">
sudo ps aux|grep deCONZ
</syntaxhighlight>

Ausgabe ist dann sowas in der Art

<pre style="color:#c0c0c0;background-color:black;">
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
</pre>

Interessant ist hier die mittlere Zeile, das ist der deCONZ-Dienst und wie man ganz vorne in der Zeile sieht, läuft er unter dem User "pi".

Die Datei befindet sich also im Ordner

<syntaxhighlight lang="bash">
~/.local/share/dresden-elektronik/deCONZ
</syntaxhighlight>

Wie gesagt wird von dort eigentlich nur die Datei zll.db benötigt. Es kann aber nichts schaden, sich eine Sicherung des kompletten Ordners "dresden-elektronik" zu machen.

Das alte System wird im weiteren Verlauf nicht mehr benötigt, dort kann also der deconz-Dienst beendet werden:

<syntaxhighlight lang="bash">
sudo systemctl stop deconz
</syntaxhighlight>

Weiterhin kann man auch gleich noch die zugehörigen deCONZ-Update- und -WiFi-Dienste beenden:

<syntaxhighlight lang="bash">
sudo systemctl stop deconz-update
sudo systemctl stop deconz-wifi
</syntaxhighlight>

Am besten deaktiviert man im Anschluss die Dienste generell, damit sie bei einem Neustart RasPi nicht automatisch wieder aktiv werden.

<syntaxhighlight lang="bash">
sudo systemctl deacitvate deconz
sudo systemctl deacitvate deconz-update
sudo systemctl deacitvate deconz-wifi
</syntaxhighlight>

== Durchreichen des Conbee-Stick an den LXC-Container ==

Damit der LXC-Container den Conbee-Stick, der physikalisch am Proxmox-Nodet angeschlossen ist, überhaupt verwenden kann, muss zum einen der Container auf die zugehörigen Device-Dateien des Nodes zugreifen dürfen und zum anderen müssen sie auf dem Container auch erst verfügbar gemacht werden.
Das ist derzeit leider nicht mit der Pxoxmox-VE Verwaltung im Web-UI machbar, sondern muss durch manuelle Anpassung der Container-Konfigurationsdatei erfolgen.

=== Benötigte USB-Informationen zum ermitteln ===

Die im folgenden ermittelten Informationen werden benötigt, um das USB-Gerät an den LXC-Container durchreichen zu können und diesem Zugriff darauf zu gewähren.

root@Node 

Bevor nun der Conbee am Proxmox-Node angeschlossen wird, lässt man sich am besten einmal die aktuell vorhandenen USB-Geräte anzeigen, das erleichtert im nächsten Schritt die Identifikation der verwendeten USB-Systemgeräte.

<syntaxhighlight lang="bash">
lsusb
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
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
</pre>

<syntaxhighlight lang="bash">
ls /dev/ttyUSB*
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1
</pre>

Jetzt wird der Conbee am Proxmox-Node eingesteckt und die beiden gerad ausgeführten Befehle nochmals wiederholt

<syntaxhighlight lang="bash">
lsusb
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
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)
</pre>

Die letzte Zeile ist neu hinzugekommen, also muss das der Conbee sein!

Folgende Informationen aus dieser Zeile werden für die weitere Konfiguration benötigt:

* Die BUS-Geräte-Informationen, Sprich die USB-Bus-Nummer (im Beispiel die 001) und die Device-Nummer auf dem Bus (im Beispiel die 007)
* Vendor- und die Product-ID des Gerätes. Das steckt im Beispiel in dieser Zahlenkombination 0403:6015. Der Teil vor dem Doppelpunkt ist die Vendor-ID ist (0403) und der Teil nach dem Doppelpunkt ist die Product-ID (6015)

<syntaxhighlight lang="bash">
ls /dev/ttyUSB*
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
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
</pre>

ttyUSB0 ist gegenüber dem vorherigen Aufruf hinzugekommen, dann gehört das Device zum Conbee. Auch der Datei-Zeitstempel passt zum Zeitpunkt des Anschließens am Node

Die relevante Information ,die aus dieser Ausgabe benötigt wird ist die 188. Das ist die (Major-)Nummer des Treibers, der für das Gerät zuständig ist.

Nun werden die zuvor notierten Bus- und Device-Nummer benötigt. Damit listet man sich das entsprechende USB-Bus-Device auf:

<syntaxhighlight lang="bash">
ls -l /dev/bus/usb/001/007
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-r-- 1 root root 189, 6 Jan 18 17:11 /dev/bus/usb/001/007
</pre>

Die relevante Information dieser Ausgabe ist auch hier die Treibernummer (189).

=== Anpassung der Container-Konfiguration ===

Für die Anpassung der Container-Konfigurtion muss direkt die Container-Konfig-Datei editiert werden. Dazu wird die Container-ID des LXC benötigt, die man am einfachsten aus der Proxmox-Verwaltung liest.

root@Node 

Die Konfig-Datei des LXC-Containers befindet sich unter

<syntaxhighlight lang="bash">
/etc/pve/local/lxc/
</syntaxhighlight>

und ist nach folgendem Schema benannt: <CONTAINER-ID>.conf das <CONTAINER-ID> ist natürlich mit der zuvor ermittelten Container-ID zu ersetzen

Die Datei mit der entsprechenden Container-ID wird nun editiert

<syntaxhighlight lang="bash">
nano <CONTAINER-ID>.conf
</syntaxhighlight>

Am Ende der Datei werden entsprechend der zuvor gesammelten Informationen folgende Zeilen am Ende eingefügt:

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

Zur Erinnerung: Die genannten Werte sind nur Beispielhaft und müssen durch die zuvor, individuell ermittelten Werte aus 5. ersetzt werden!

* In die 1. Zeile kommt die 189 (die aus der Ausgabe von ls -l /dev/bus/usb/001/007 kommt). Damit wird dem Container der Zugriff auf USB-Bus-Devices gestattet.
* In der 2. Zeile kommt 2 mal der Bus-Device-Pfad, genau so, wie er auch beim ls verwendet wurde. Damit wird das Bus-Device des Node im Container genau unter dem selben Pfad gemountet.
* In der 3. Zeile wird dem Container der Zugriff auf USB-Serial-Devices eingerichtet. (die 188 kommt aus dem ls -l /dev/ttyUSB*)
* In der 4. Zeile wird das USB-Serial-Device ttyUSB0 unter demselben Pfad im LXC-Container gemountet.

Bei den beiden Mount-Angaben ist der erste Teil immer die Quelle, also der Pfad auf dem Node und der zweite Teil das Ziel, also der Pfad im LXC-Container. Die Devices können bei Bedarf und Wunsch also auch unter anderen Bezeichnungen im LXC-Container verfügbar gemacht werden.

myadmin@LXC 

Nach dem Speichern der Änderungen muss der LXC-Container (!) einmal neu gestartet werden:

<syntaxhighlight lang="bash">
sudo reboot now
</syntaxhighlight>

myadmin@LXC 

Überprüfen, ob die Änderunge erfolgreich für im LXC-Container übernommen und angewendet wurden:

<syntaxhighlight lang="bash">
ls -l /dev/bus/usb/001/007
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-r-- 1 nobody nogroup 189, 6 Jan 18 16:11 /dev/bus/usb/001/007
</pre>

Das ist die erwartete Ausgabe!

<syntaxhighlight lang="bash">
ls -l /dev/ttyUSB*
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw---- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0
</pre>

Auch das ist die erwartete Ausgabe.

=== Anpassung der Berechtigungen auf dem Node ===

Die letzte Ausgabe ist von zusätzlichem Interesse, denn Dort kann man sehen, dass nur der Eigentümer und die Gruppe Zugriff auf das Gerät haben, alle anderen (other) aber nicht. Leider sind als Eigentümer der User "nobody" und die Gruppe "nogroup" angegeben. Das liegt daran, Die User/Gruppen und Berechtigungen vom Host-System nicht ohne Weiteres an einen (unprivilegierten) Container weitergegeben werden können. Es gibt zwar die Möglichkeit dies durch ein entsprechendes Mapping der uid und gid in der Konfig-Datei des Containers zu erreichen.
Einfacher ist es aber, auf dem Node auch "allen anderen" (other) den Zugriff auf das Device zu erlauben. Temporär erreicht man das durch ganz normale Rechteanpassung:

root@node 

<syntaxhighlight lang="bash">
chmod o+rw /dev/ttyUSB0
</syntaxhighlight>

Ob die Änderungen wirksam sind, sieht man mittels

<syntaxhighlight lang="bash">
ls -l /dev/ttyUSB0
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-rw- 1 root dialout 188, 0 Jan 18 19:15 /dev/ttyUSB0
</pre>

Genau so soll es sein! Das Device darf nun von jedem gelesen und beschrieben werden.

Die Rechte müssten auch direkt auf dem Container entsprechend erweitert worden sein. Auch das kann man überprüfuen

myadmin@LXC 

<syntaxhighlight lang="bash">
ls -l /dev/ttyUSB0
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-rw- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0
</pre>

Man sieht, auch im Container kann nun jeder lesend und schreibend auf das Gerät zugegriffen werden. Genau so wird das auch benötigt.

Wie schon erwähnt ist die gerade durchgeführte Rechteanpassung nur temporär. Sprich wird der Pxoxmox-Node neu gestartet, sind die Schreib-/Leserechte für other auf das Device wieder verloren. Damit diese Rechtezuweisung auf dem Proxmox-Node auch über einen Systemneustart erhalten bleibt, genauer gesagt dann wieder automatisch eingerichtet wird, wird nun eine entsprechende udev-Regel auf dem Proxmox-Node eingerichtet.

root@Node 

Es wird die Datei mit dem Edior angelegt

<syntaxhighlight lang="bash">
nano /etc/udev/rules.d/50-lxcusb.rules
</syntaxhighlight>

Folgende Zeile wird dort eingetragen:

<syntaxhighlight lang="bash">
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", GROUP="users", MODE="0666"
</syntaxhighlight>

Hier sind natürlich wieder die oben ermittelten individuellen Werte für Vendor- und Product-ID einzutragen.
Durch diese Regel werden die Rechte für das, durch Product- und Vendor-ID identifizierte Device beim Systemstart auf den in MODE eingestellten wert (0666 -> rw-rw-rw) festgelegt.

Damit ist die USB-Geräteeinrichtung abgeschlossen.

{{Hinweis|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.}}

{{Hinweis|Wenn der LXC-Container auf einen anderen Proxmox-Node migriert wird, muss natürlich der Conbee am neuen angesteckt angesteckt werden und entsprechend durchgereicht werden.}}

== Einrichtung und Konfigurieren des deCONZ-Dienstes ==

Jetzt erst wird der Dienst im LXC-Container aktiviert

myadmin@LXC 

<syntaxhighlight lang="bash">
sudo systemctl enable deconz
</syntaxhighlight>

Bevor der Dienst nun gestartet wird, wird zunächst das Services-File an die gewünschten gegebenheiten angepasst (optional!)
Zum einen wird der User angepasst, unter dem der deconz-Service laufen soll und zum anderen wird dem deconz dienst beim Aufruf mitgeteilt, wo er den Conbee findet (/dev/ttyUSB0)

Bei der Aktivierung des Dienstes wurde der Dateipfad, bzw. der erzeugte Symlink auf die Service-Datei ausgegeben.

<pre style="color:#c0c0c0;background-color:black;">
/etc/systemd/system/multi-user.target.wants/deconz.service -> /lib/systemd/system/deconz.service
</pre>

Es ist jetzt egal, ob über den symlink oder die Datei direkt editiert wird. Editiert werden muss allerdings mit root-Rechten (sudo)

<syntaxhighlight lang="bash">
sudo nano /etc/systemd/system/multi-user.target.wants/deconz.service
</syntaxhighlight>

Nach der Änderung sollte die Datei so aussehen

Die Service-Datei sieht bei mir nach Änderung so aus:

<syntaxhighlight lang="bash">
[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service deconz-update.service
StartLimitIntervalSec=0

[Service]
User=deconz
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
</syntaxhighlight>

Die genannten Änderungen finden sich in den ersten beiden Zeilen in der Seciton [Service] Beim User stand ursprünglich die uid des Users drin, es sollte aber auch mit dem Usernamen funktionieren. Falls nicht, dann gegen die gewünschte uid austauschen.

Nach dem Speichern der Datei muss systemctl dazu aufgefordert werden, die Änderungen zu übernehmen:

<syntaxhighlight lang="bash">
sudo systemctl daemon-reload
</syntaxhighlight>

Dann kann der Dienst endlich gestartet werden

<syntaxhighlight lang="bash">
sudo systemctl start deconz
</syntaxhighlight>

Überprüfen kann man das am einfachsten indem man sich den entsprechenden Prozess aus der Prozessliste filtert:

<syntaxhighlight lang="bash">
sudo ps aux|grep deCONZ
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
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
myadmin 10727 0.0 0.0 3088 816 pts/3 S+ 20:36 0:00 grep deCONZ
</pre>

Man sieht in der Ausgabe, der Dienst läuft unter dem gewünschten User "deconz" und auch das ttyUSB0 wurde beim Start korrekt übergeben.

Damit ist die grundsätzliche Einrichtung von deCONZ auf dem LXC-Container mit durchgereichtem Conbee abgeschlossen.

== Wiederherstellen der vorherigen deCONZ-Konfiguration (Optional) ==

Wenn die deCONZ-Konfiguration samt Conbee von einem bestehenden System in den Container "umziehen" soll muss nun noch lediglich die in Punkt 5. gesicherte Datei "zll.db" in das deCONZ-Verzeichnis unter dem User deCONZ kopiert werden:

 myadmin@LXC 

Dazu muss der Dienst zunächst gestoppt werden

<syntaxhighlight lang="bash">
sudo systemctl stop deconz
</syntaxhighlight>

Dann kann die Datei aus der vorherigen Sicherung vom Altsystem übertragen werden
Ziel ist in diesem Beispiel dann im Home-Verzeichnis des Users deconz:

<syntaxhighlight lang="bash">
/home/deconz/.local/share/dresden-elektronik/deCONZ
</syntaxhighlight>

Jetzt muss der Dienst nur wieder gestartet werden.

<syntaxhighlight lang="bash">
sudo systemctl start deconz
</syntaxhighlight>

Jetzt kann man sich wie gewohnt, mit dem Browser an der Phoscon-App auf dem LXC-Container anmelden. Dort sollte dann das "alte" Gatewas zur Auswahl stehen und nach Anmeldung am Gateway sollten auch alle Gruppen, Lichter, Schalter, .... vorhanden und bedienbar sein.

== Anpassungen in FHEM (Optional) ==

Wenn der Conbee bisher in FHEM als HUE-IO verwendet wurde muss im entsprechenden FHEM-Device (Bspw.: "deCONZ") im DEF die IP-Adresse des LXC-Containers eingetragen werden.

== Anmerkungen ==

* Die Einrichtung zum Durchreichen von USB-Serial-Devices an unprivilegierte LXC-Container ist grundsätzlich auch für andere USB-Devices anwendbar. Auf gleiche Art und Weise lässt sich bspw. ein Volkszähler USB-Lesekopf am Proxmox-Node anschließen und an einen LXC-Container durchreichen.

* Die Sicherung und Wiederherstellung der deCONZ-Konfiguration lässt sich so natürlich auch bei einem System-Upgrade oder einer geplanten System-Neuinstallation anwenden.

[[Kategorie:ZigBee]]