debmatic in systemd-nspawn container

Debian/Ubuntu basierte CCU

Moderator: Co-Administratoren

Südwind
Beiträge: 2
Registriert: 17.05.2020, 13:34
System: Alternative CCU (auf Basis OCCU)

Re: debmatic in systemd-nspawn container

Beitrag von Südwind » 17.05.2020, 13:54

Hallo,
ich bin neu in der Homematic- Welt und damit auch hier :-)

Meine Versuche nach der obigen Anleitung (danke dafür!) Debmatic zu installieren sind bisher gescheitert.
Nach dem Starten des Containers bekomme ich

Code: Alles auswählen

sw@debmatic:~$ sudo systemctl status debmatic
...
Mai 17 13:21:08 debmatic systemd[1]: Starting debmatic...
Mai 17 13:21:40 debmatic initsystem.sh[6534]: grep: /sys/bus/usb-serial/drivers/cp210x/new_id: Datei oder Verzeichnis nicht gefunden
Mai 17 13:21:40 debmatic initsystem.sh[6534]: /usr/share/debmatic/bin/detect_hardware.inc: Zeile 123: /sys/bus/usb-serial/drivers/cp210x/new_id: Datei oder Verzeichnis nicht gefunden
Mai 17 13:22:11 debmatic systemd[1]: Started debmatic.  
Allerdings wird der Homematic USB Stick (Ich benutze den HmIP-RFUSB Stick im Container gefunden:

Code: Alles auswählen

sw@debmatic:~$ usb-devices 
...
T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1b1f ProdID=c020 Rev=01.00
S:  Manufacturer=Silicon Labs
S:  Product=eQ-3 HmIP-RFUSB
S:  SerialNumber=3014F711A061A7C00010CECF
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) 
Ich vermute ich muss den Hinweis von "ThR"
ThR hat geschrieben:
08.01.2020, 09:39
...
Und das systemd-nspawn@.service Unit File habe ich um die folgenden Abhängikeiten erweitert. Da der Container sonst das Funkmodul nicht erreicht hat.

Code: Alles auswählen

After=pivccu-dkms.service systemd-modules-load.service
...
Gruß
Leider habe ich noch nicht die Stelle gefunden wo ich die Zeile eintragen muss?!
Kann mir evtl. jemand helfen?

Schöne Grüße aus dem Norden
Daniel

Südwind
Beiträge: 2
Registriert: 17.05.2020, 13:34
System: Alternative CCU (auf Basis OCCU)

Re: debmatic in systemd-nspawn container

Beitrag von Südwind » 17.05.2020, 15:49

Hallo nochmal,

ich will auch berichten welche weiteren Probleme ich hatte und wie ich sie gelöst habe:
  • Der Container hat zwei IP Adressen auf dem Interface "host0" bekommen. Im ArchWiki habe ich dazu einen Tip gefunden.
    Meine /etc/systemd/nspawn/debmatic.nspawn sieht daher so aus:

    Code: Alles auswählen

    [Exec]
    Hostname=debmatic
    PrivateUsers=no
    
    [Network]
    Bridge=br0
    VirtualEthernet=no  # <= verhindert eine 2. IP Adresse
    
    [Files]
    Bind=/var/cache/apt/archives  # <= verhindert doppeltes herunterladen und speichern der Debian- Pakete
    #Bind=/sys/fs/cgroup
    
  • Der Container hat nicht die zugewiesene IP- Adresse aus /etc/systemd/network/host0.network übernommen sondern sich eine Adresse per DHCP vom Router geholt.
    Ebenfalls im ArchWiki habe ich dazu den Tip gefunden:
    on container

    First, we shall get rid of the system /usr/lib/systemd/network/80-container-host0.network file, which provides a DHCP configuration for the default network interface of the container. To do it in a permanent way (e.g. even after systemd upgrades), do the following on the container. This will mask the file /usr/lib/systemd/network/80-container-host0.network since files of the same name in /etc/systemd/network take priority over /usr/lib/systemd/network. Keep in mind that this file can be kept if you only want a static IP on the host, and want the IP address of your containers to be assigned via DHCP.

    Code: Alles auswählen

    # ln -sf /dev/null /etc/systemd/network/80-container-host0.network
Für die Profis ist das sicherlich nicht so schwierig zu beheben, ich habe aber lange gebraucht um die Fehler (mit denen man sicherlich auch leben kann) zu beheben. Vielleicht hilft es ja jemand?!

Gruß
Daniel

srunschke
Beiträge: 213
Registriert: 10.01.2018, 12:44
Hat sich bedankt: 3 Mal
Danksagung erhalten: 13 Mal

Re: debmatic in systemd-nspawn container

Beitrag von srunschke » 18.05.2020, 23:24

Südwind hat geschrieben:
17.05.2020, 13:54
Ich vermute ich muss den Hinweis von "ThR"
ThR hat geschrieben:
08.01.2020, 09:39
...
Und das systemd-nspawn@.service Unit File habe ich um die folgenden Abhängikeiten erweitert. Da der Container sonst das Funkmodul nicht erreicht hat.

Code: Alles auswählen

After=pivccu-dkms.service systemd-modules-load.service
...
Gruß
Leider habe ich noch nicht die Stelle gefunden wo ich die Zeile eintragen muss?!
Kann mir evtl. jemand helfen?
Der Eintrag kommt in folgende Datei:

/etc/systemd/system/machines.target.wants/systemd-nspawn@debmatic.service , welche ein Symlink auf /lib/systemd/system/systemd-nspawn@.service ist.

After= ist ein Parameter für die [Unit] Sektion.
Du kannst ihn einfach ans Ende der Sektion hängen, auch wenn schon ein After= Eintrag enthalten ist, da After= mehrmals verwendet werden darf.

S

ranseyer
Beiträge: 67
Registriert: 17.01.2019, 16:22
Hat sich bedankt: 7 Mal

Re: debmatic in systemd-nspawn container

Beitrag von ranseyer » 29.09.2020, 18:36

Vielen Dank für den sehr gut dokumentieren Beitrag...
Das Konzept gefällt mir für einen Raspi bisher sehr sehr gut...

Ausgehend von einem frischen Debian 10 / buster
Du meinst damit also kein Raspbian ? (Sondern ein Image von hier https://raspi.debian.net/tested-images/ ? )
Denn dort läuft die Netzwerkerei wohl etwas anders als bei Debian. Die ganzen Tutorials die mir über den Weg gelaufen sind beziehen sich auf die /etc/dhcpcd.conf ...

...dachte bisher ein Image von der Raspberry-Pi Foundatotion wäre besser wegen diversen Raspi Tools und GPIO Modulen falls doch mal nötig...

Deinstallieren des DHCP Daemons scheint mir äußerst ungesund wegen Abhängigkeiten, ...

Frage: Ist die Empfehlung also ein Image von Debian zu nehmen und bei Bedarf die Raspi Tools nachzuinstallieren?

ptweety
Beiträge: 522
Registriert: 07.01.2017, 16:48
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 48 Mal
Danksagung erhalten: 66 Mal

Re: debmatic in systemd-nspawn container

Beitrag von ptweety » 29.09.2020, 18:56

Ich denke, man kann das ähnlich auch auf Raspbian umsetzen. Allerdings ist auf dem Pi doch eher PiVCCU3 empfehlenswert.

ranseyer
Beiträge: 67
Registriert: 17.01.2019, 16:22
Hat sich bedankt: 7 Mal

Re: debmatic in systemd-nspawn container

Beitrag von ranseyer » 30.09.2020, 08:07

Meine Schwierigkeit zum Start ist wie ich den Raspi dazu bringe das Netzwerk über systemd zu konfigurieren anghand deiner Doku.

Ich würde mal versuchen den DHCP Daemon abzschalten oder das LAN Interface von DHCP auszunehmen...

ptweety
Beiträge: 522
Registriert: 07.01.2017, 16:48
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 48 Mal
Danksagung erhalten: 66 Mal

Re: debmatic in systemd-nspawn container

Beitrag von ptweety » 30.09.2020, 10:23

Wenn du mit englischer Doku umgehen kannst, dann ist dieser Artikel sehr gut. Du musst dann nur noch die Konfiguration auf das bridged networking umstellen. -> Link <-

ranseyer
Beiträge: 67
Registriert: 17.01.2019, 16:22
Hat sich bedankt: 7 Mal

Re: debmatic in systemd-nspawn container

Beitrag von ranseyer » 30.09.2020, 17:40

Danke für den Link, genau den hatte ich in der Zwischenzeit auch entdeckt und oh Wunder, ... Die Kiste ist noch immer im Netzwerk erreichbar.
...und ohne eine solche Doku hätte ich das nie hinbekommen (wenn wir annehemen dass alle der Schritte genau so nötig sind).


Wenn man dann deine Doku durchzieht und "eno1" durch "eth0" ersetzt kann es mit Deiner Doku weitergehen...

Ich wollte an der Stelle meinen (plus deinen) Erfolg huldingen...
Muss aber zugeben dass ich von Netzwerk per systemd noch weniger Ahnung haben als von den alten Methoden...

Mein Ziel war es eine IP Adresse im lokalen Netz zu bekommen. Ich war der Annahme falls ein Netzwerkgerät gibt welches "host0" enthält dass ich dann die pivccu oder ggf. debmatic unter 192.168.1.11 erreichen kann.

Code: Alles auswählen

root@raspberrypi:/home/pi# mcmachinectl login pivccu
root@pivccu:/etc/systemd/network# cat host0.network
[Match]
Name=host0

[Network]
Address=192.168.1.11/24
Gateway=192.168.1.1
DNS=192.168.1.1

(Inhalt des Root-FS kommt aus deinem Beispiel Buster von Debian.org)

Code: Alles auswählen

debootstrap --include=systemd,dbus,systemd-container,ssh,sudo,apt-transport-https buster buster http://deb.debian.org/debian



Das klappt aber nicht, mir scheint dass trotz meiner Config versucht wird eine IP Adresse per DHCP zu bekommen.

Code: Alles auswählen

root@pivccu:/etc/systemd/network# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: host0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 56:f6:ba:24:39:f4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.124.249/16 brd 169.254.255.255 scope link host0
       valid_lft forever preferred_lft forever
    inet 10.0.0.6/28 brd 10.0.0.15 scope global dynamic host0
       valid_lft 3308sec preferred_lft 3308sec
    inet6 fe80::54f6:baff:fe24:39f4/64 scope link
       valid_lft forever preferred_lft forever
Falls du noch einen spontanen Tipp hättest was ich hier übersehe ?

ptweety
Beiträge: 522
Registriert: 07.01.2017, 16:48
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 48 Mal
Danksagung erhalten: 66 Mal

Re: debmatic in systemd-nspawn container

Beitrag von ptweety » 30.09.2020, 18:16

Hast du denn im Container auch schon

Code: Alles auswählen

systemctl enable systemd-networkd
systemctl start systemd-networkd
als root durchgeführt?

ranseyer
Beiträge: 67
Registriert: 17.01.2019, 16:22
Hat sich bedankt: 7 Mal

Re: debmatic in systemd-nspawn container

Beitrag von ranseyer » 30.09.2020, 21:26

Ja, hatte ich (und habe ich nochmals laufen lassen). Ergebnis (Achtung: IP sollte statisch 192.* sein...) :

Code: Alles auswählen

root@pivccu:/home/pivccu# systemctl status systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-09-30 19:35:07 BST; 46min ago
     Docs: man:systemd-networkd.service(8)
 Main PID: 23 (systemd-network)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-networkd.service
           └─23 /lib/systemd/systemd-networkd

Sep 30 19:35:07 pivccu systemd[1]: Starting Network Service...
Sep 30 19:35:07 pivccu systemd-networkd[23]: Enumeration completed
Sep 30 19:35:07 pivccu systemd[1]: Started Network Service.
Sep 30 19:35:07 pivccu systemd-networkd[23]: host0: Gained carrier
Sep 30 19:35:07 pivccu systemd-networkd[23]: host0: DHCPv4 address 10.0.0.6/28 via 10.0.0.1
Sep 30 19:35:09 pivccu systemd-networkd[23]: host0: Gained IPv6LL
Sep 30 19:35:37 pivccu systemd-networkd[23]: host0: Configured
root@pivccu:/home/pivccu# systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/systemd-resolved.service.d
           └─resolvconf.conf
   Active: active (running) since Wed 2020-09-30 19:35:07 BST; 46min ago
     Docs: man:systemd-resolved.service(8)
           https://www.freedesktop.org/wiki/Software/systemd/resolved
           https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
           https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
  Process: 49 ExecStartPost=/bin/sh -c [ ! -e /run/resolvconf/enable-updates ] || echo "nameserver 127.0.0.53" | /sbin/resolvconf -a systemd-resolved (code=exited, sta
 Main PID: 38 (systemd-resolve)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-resolved.service
           └─38 /lib/systemd/systemd-resolved

Sep 30 19:35:07 pivccu systemd[1]: Starting Network Name Resolution...
Sep 30 19:35:07 pivccu systemd-resolved[38]: Positive Trust Anchors:
Sep 30 19:35:07 pivccu systemd-resolved[38]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Sep 30 19:35:07 pivccu systemd-resolved[38]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Sep 30 19:35:07 pivccu systemd-resolved[38]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20
Sep 30 19:35:07 pivccu systemd-resolved[38]: Using system hostname 'pivccu'.
Sep 30 19:35:07 pivccu systemd[1]: Started Network Name Resolution.
lines 1-22/22 (END)

wobei ich denke ich hätte es "fast richtig" gemacht...

Code: Alles auswählen

root@pivccu:/home/pivccu# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: host0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 56:f6:ba:24:39:f4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.124.249/16 brd 169.254.255.255 scope link host0
       valid_lft forever preferred_lft forever
    inet 10.0.0.6/28 brd 10.0.0.15 scope global dynamic host0
       valid_lft 2513sec preferred_lft 2513sec
    inet6 fe80::54f6:baff:fe24:39f4/64 scope link
       valid_lft forever preferred_lft forever

root@pivccu:/home/pivccu# cat /etc/systemd/network/host0.network
[Match]
Name=host0

[Network]
Address=192.168.1.11/24
Gateway=192.168.1.1
DNS=192.168.1.1
root@pivccu:/home/pivccu#

Antworten

Zurück zu „debmatic“