debmatic in systemd-nspawn container

Debian/Ubuntu basierte CCU

Moderator: Co-Administratoren

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

debmatic in systemd-nspawn container

Beitrag von ptweety » 09.11.2019, 19:35

Hallo zusammen,

hier schreibe ich mal meine Erfahrungen mit dem Aufsetzen von debmatic in einem systemd-nspawn container auf.

Warum aber das Ganze? In einem halbwegs aktuellen linux ist systemd meist der Standard für das Init-System und bringt "nativ" auch eine schöne Lösung zur Virtualisierung mit: systemd-nspawn und machinectl.
Im Vergleich zu Docker bekommt man damit im Tausch gegen etwas Komfort und Abstraktion dann mehr Kontrolle und Optionen für seine Container.

Übersicht:
  1. Software installieren, Bridge aufsetzten und feste IP für Host einrichten
  2. Container vorbereiten und mit fester IP einrichten
  3. debmatic im Container installieren


I. Software installieren, Bridge aufsetzten und feste IP für Host einrichten

Ausgehend von einem frischen Debian 10 / buster geht es nun los mit der benötigten Software

Code: Alles auswählen

$ sudo apt install bridge-utils systemd-container debootstrap
und der Einrichtung des Netzwerks:

Code: Alles auswählen

$ sudo mv /etc/network/interfaces /etc/network/interfaces.save
$ sudo systemctl enable systemd-networkd
$ 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
       ...
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 94:c6:91:18:ee:8b brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.3/24 brd 192.168.178.255 scope global eno1
       ...
Hier kommen nun die individuelle Teile. Bei mir wird es eine Bridge mit fester IP für den Host

Code: Alles auswählen

$ sudo tee /etc/systemd/network/br0.netdev << EOF
[NetDev]
Name=br0
Kind=bridge
EOF

Code: Alles auswählen

$ sudo tee /etc/systemd/network/br0.network << EOF
[Match]
Name=br0

[Network]
Address=192.168.178.3/24
Gateway=192.168.178.1
DNS=192.168.178.1
EOF

Code: Alles auswählen

$ sudo tee /etc/systemd/network/eno1.network << EOF
[Match]
Name=eno1

[Network]
Bridge=br0
EOF
Das wird aktiv nach dem nächsten Reboot:

Code: Alles auswählen

$ sudo systemctl reboot

II. Container vorbereiten und mit fester IP einrichten

Zuerst wird das Dateisystem für den künftigen Container erstellt. Anleitungen dazu gibt es einige wie etwa hier und hier. Am einfachsten ist es, wenn der Container gleich dem Host ist, dann muss man sich nicht umgewöhnen.

Als root geht es nun weiter:

Code: Alles auswählen

$ sudo -i

Code: Alles auswählen

# cd /var/lib/machines
# debootstrap --include=systemd,dbus,systemd-container,ssh,sudo,apt-transport-https buster buster http://deb.debian.org/debian
Das kann nun als Vorlage für alle weiteren Container dienen. Also wird die Vorlage geklont:

Code: Alles auswählen

# machinectl clone buster debmatic
Und schon kann der neue Container erstmalig genutzt werden. Eigentlich ist das eher wie ein chroot:

Code: Alles auswählen

# systemd-nspawn -D debmatic
Im nun laufenden Container geben wir dem Kind nun einen Namen und ebenso wie schon dem Host eine eigene feste IP:

Code: Alles auswählen

root@debmatic:~# echo 'debmatic' > /etc/hostname

Code: Alles auswählen

root@debmatic:~# tee /etc/systemd/network/host0.network << EOF
[Match]
Name=host0

[Network]
Address=192.168.178.4/24
Gateway=192.168.178.1
DNS=192.168.178.1
EOF
Dann noch einen neuen Nutzer anlegen (<user> ist im weiteren entsprechend zu ersetzen)

Code: Alles auswählen

root@debmatic:~# useradd -G cdrom,floppy,sudo,audio,dip,video,plugdev,systemd-journal,netdev -m -s /bin/bash <user>
root@debmatic:~# passwd <user>
Und wieder raus:

Code: Alles auswählen

root@debmatic:~# exit
Damit das jetzt auch immer schön automatisch funktioniert machen wir einen Service daraus, der auch einen ordentlichen Startvorgang absolviert und im Container die nötigen Dienste startet:

Code: Alles auswählen

# mkdir /etc/systemd/nspawn
# tee /etc/systemd/nspawn/debmatic.nspawn << EOF
[Exec]
Hostname=debmatic
PrivateUsers=no

[Network]
Bridge=br0

[Files]
#Bind=/sys/fs/cgroup
EOF

Code: Alles auswählen

# machinectl start debmatic
# machinectl enable debmatic
Vom Host aus können wir den laufenden Container verwalten:

Code: Alles auswählen

# machinectl status debmatic
# systemctl status systemd-nspawn@debmatic
Oder direkt eine shell aufrufen und ein paar Anpassungen vornehmen.
Nötig ist hier die Aktivierung des Netzwerks im Container:

Code: Alles auswählen

# machinectl shell debmatic
root@debmatic:~# systemctl start systemd-networkd
root@debmatic:~# systemctl enable systemd-networkd
Optional braucht der oben angelegte Nutzer kein Passwort mehr für sudo

Code: Alles auswählen

root@debmatic:~# tee /etc/sudoers.d/010_me-nopasswd << EOF
<user> ALL=(ALL:ALL) NOPASSWD:ALL
EOF
root@debmatic:~# exit
Wieder draußen kommen wir zukünftig an ein login so:

Code: Alles auswählen

# machinectl login debmatic
debmatic login: ^] ^] ^]
Root im Host braucht es nun auch nicht mehr

Code: Alles auswählen

# exit
Wer lieber ssh mag, der braucht vielleicht auch seinen key vom Host im Container:

Code: Alles auswählen

$ cd ~
$ ssh-copy-id -i .ssh/id_rsa.pub <user>@debmatic
$ ssh <user>@debmatic

III. debmatic im Container installieren

Im Prinzip folgen wir der Anleitung von Alex. Zuerst braucht der Host die Gerätetreiber:

Code: Alles auswählen

$ sudo apt install apt-transport-https
und:

Code: Alles auswählen

$ wget -q -O - https://www.debmatic.de/debmatic/public.key | sudo apt-key add -
$ sudo bash -c 'echo "deb https://www.debmatic.de/debmatic stable main" > /etc/apt/sources.list.d/debmatic.list'
$ sudo apt update
und:

Code: Alles auswählen

$ sudo apt install linux-headers-amd64
$ sudo apt install pivccu-modules-dkms
Die nötigen Module können m.E. bei Start des Host geladen werden:

Code: Alles auswählen

$ sudo tee /etc/modules-load.d/debmatic.conf << EOF
eq3_char_loop
rpi_rf_mod_led
ledtrig-default-on
ledtrig-timer
led_trigger_timer
hb_rf_usb
EOF
Der Container braucht die Rechte zum Zugriff auf die Geräte. Dazu ändern wir mit den bevorzugten Editor die Konfiguration des Service:

Code: Alles auswählen

$ sudo systemctl edit systemd-nspawn@debmatic
und brauchen diesem Inhalt:

Code: Alles auswählen

[Service]
DeviceAllow=char-usb_device rwm
DeviceAllow=char-eq3loop rwm
DeviceAllow=char-raw-uart rwm
DeviceAllow=char-gpiochip rwm
Mehr Geräte listet

Code: Alles auswählen

$ cat /proc/devices
Und nach dem obligatorischen Neustart geht es dann weiter:

Code: Alles auswählen

$ sudo systemctl reboot
Jetzt können wir im Container debmatic einrichten. Also zuerst login:

Code: Alles auswählen

$ sudo machinectl login debmatic
oder

Code: Alles auswählen

$ ssh <user>@debmatic
und dann installieren:

Code: Alles auswählen

$ sudo apt install gnupg wget git apt-transport-https
$ wget -q -O - https://www.debmatic.de/debmatic/public.key | sudo apt-key add -
$ sudo bash -c 'echo "deb https://www.debmatic.de/debmatic stable main" > /etc/apt/sources.list.d/debmatic.list'
$ sudo apt update

Code: Alles auswählen

$ sudo apt --no-install-recommends install debmatic

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 » 09.11.2019, 19:43

Kleine Ergänzung dazu:

Nach der selber Vorlage kann man sich natürlich auch einen Container für pi-hole basteln:

Code: Alles auswählen

machinectl clone buster pihole
Bei mir sieht das dann so aus:

Code: Alles auswählen

$ machinectl 
MACHINE  CLASS     SERVICE        OS     VERSION ADDRESSES     
debmatic container systemd-nspawn debian 10      192.168.178.4…
pihole   container systemd-nspawn debian 10      192.168.178.2…

2 machines listed.
Und netterweise läuft dann parallel auch Docker (und andere Virtualisierungslösung wie KVM/QEMU) friedlich nebeneinander:

Code: Alles auswählen

$ docker ps
CONTAINER ID        IMAGE                          COMMAND...
3e71db77be01        eclipse-mosquitto:latest
8e4372f314bd        portainer/portainer:latest
43ec305a5638        telegraf:alpine
e8f3943f06c4        radhifadlillah/shiori:latest
b9c1a92b462c        itzg/minecraft-server:latest
c1153a7ea499        containrrr/watchtower:latest
f709301b1aa3        chronograf:alpine
2cfffe56b3ce        influxdb:alpine
...

Benutzeravatar
deimos
Beiträge: 5383
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 950 Mal
Kontaktdaten:

Re: debmatic in systemd-nspawn container

Beitrag von deimos » 09.11.2019, 20:43

Hi,

sehr interessante Anleitung, vielen Dank dafür!

Viele Grüße
Alex

ThR
Beiträge: 66
Registriert: 05.09.2017, 03:14

Re: debmatic in systemd-nspawn container

Beitrag von ThR » 08.01.2020, 09:39

Hi,

danke für die Anleitung habe gestern auch debmatic im Systemd-nspawn Container installiert.

Läuft echt gut. Zwei Sachen habe ich noch anpassen müssen.

Zum einem musste einem Nameserver in die resolv.conf da der Container sonst keine Namesauflösung hinbekommen hat.

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ß
Gruß Thomas

ThR
Beiträge: 66
Registriert: 05.09.2017, 03:14

Re: debmatic in systemd-nspawn container

Beitrag von ThR » 09.01.2020, 18:02

Hi,

habe mal das neue Funkmodul RPI-RF-MOD über HP-RF-USB angeschlossen. Dabei ist mir aufgefallen das die LED nur gelb leuchtet.

Funktionieren tut es aber trotzdem.

Gruß
Gruß Thomas

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 » 09.01.2020, 22:08

Hi,

es kann sein, dass da noch ein device für den Container fehlt. Ich habe mit debmatic noch das alte Modul im Einsatz und kann das daher nicht testen.

Du kannst ja mal schauen, was dir cat /proc/devices mit den unterschiedlichen Modulen auswirft.

ThR
Beiträge: 66
Registriert: 05.09.2017, 03:14

Re: debmatic in systemd-nspawn container

Beitrag von ThR » 09.01.2020, 23:29

Hi,

hab ich gemacht. Kein Unterschied.

Gruß
Gruß Thomas

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 » 12.05.2020, 10:37

Vielen Dank für den tollen Beitrag, den ich gerade zufällig ausgegraben habe.

Ich persönlich arbeite aktuell meistens mit Docker, aber leider gibt es die CCU ja nicht als Docker Container. Da ich sowieso gerade dabei bin meine Docker Umgebung von der Synology auf eine VM zu verschieben, könnte ich natürlich auch hergehen und gleich das Thema OCCU mit verschieben und auf der gleichen VM neben Docker laufen lassen.

Daher meine Frage: Gibt es einige Leute, die diese Umgebung produktiv laufen haben? Oder gibt es welche, die es versucht haben, aber aufgrund von irgendwelchen Fehlern abgebrochen haben?

Last but not least noch eine Frage zu der Netzwerk Virtualisierung dieser Lösung. In meiner Docker Umgebung habe ich aktuell das bekannte Problem von macvlan, dass ich nicht auf das Hostsystem zugreifen kann - da das meine Synology ist und ich hier einfach extrem viele Schnittstellen habe, die zugreifbar sein müssten, laufe ich langsam in Probleme bei der weiteren Realisierung meines Projektes (daher auch der Plan die Dockerumgebung von Synology nativ auf eine VM auszulagern). Besteht das gleiche Problem bei systemd-nspawn auch oder kann das gebridgte Netzwerkinterface auf den Host zugreifen?

Benutzeravatar
deimos
Beiträge: 5383
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 950 Mal
Kontaktdaten:

Re: debmatic in systemd-nspawn container

Beitrag von deimos » 12.05.2020, 13:21

Hi,

ich habe es ja schon mehrfach erwähnt, aber gerne nochmal: Es kann kann keine generische Lösung für Docker geben, weil man spezielle Kernel Module laden muss und das geht einfach nur vom Host aus und das ist dann auf jedem Hosttyp etwas andets zu lösen.

Grade bei einem fertigen NAS (Synology, Qnap, etc) kommt dazu, dass es schwer werden dürfte, diese Kernel überhaupt zu bauen mangels Kernel Headern.

Viele Grüße
Alex

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 » 12.05.2020, 13:55

deimos hat geschrieben:
12.05.2020, 13:21
ich habe es ja schon mehrfach erwähnt, aber gerne nochmal: Es kann kann keine generische Lösung für Docker geben, weil man spezielle Kernel Module laden muss und das geht einfach nur vom Host aus und das ist dann auf jedem Hosttyp etwas andets zu lösen.

Grade bei einem fertigen NAS (Synology, Qnap, etc) kommt dazu, dass es schwer werden dürfte, diese Kernel überhaupt zu bauen mangels Kernel Headern.
Hi Alex,

vielen Dank für deine Antwort - aber sie passt nicht so ganz zu meiner Frage ;)
Dass die CCU aufgrund der Kernelanforderung niemals in einem generischen Docker Host laufen wird, ist mir völlig klar, das ist ja hier auch nicht das Ziel.
Meine Fragen beziehen sich ja ausschließlich auf die hier vorgestellte systemd-nspawn Lösung. Die angesprochenen Probleme im Dockerumfeld bezogen sich auf das macvlan meines iobrokers, ich möchte hier nur nicht das gleiche Problem mit einer systemd-nspawn Lösung produzieren. Eventuell war es etwas kompliziert und missverständlich ausgedrückt.
Daher meine explizite Nachfrage Richtung macvlan und auch die generelle Frage ob jemand _diese_ Lösung hier produktiv einsetzt.

Gruß und Danke
Sascha

Antworten

Zurück zu „debmatic“