LXC: Container von Außen nicht erreichbar

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

LXC: Container von Außen nicht erreichbar

Beitrag von buhtz » 10.05.2021 21:41:16

Ich habe mich an die Wiki-Anleitung gehalten und einen unpriviligierten Container (foobar) mit einer Host-shared bridge erzeugt.

Ziel ist es, dass der Container im gesamten lokalen Netzwerk, d.h. gleichwertig zum Host sichtbar ist.
Aktuell schafft es der Container zwar ins Internet (per ping), aber im Router taucht der Container nicht auf, sondern nur sein host. Evtl. hab ich den Begriff Host-shared bridge falsch verstanden?

Das ip address im Host erscheint mir recht unübersichtlich. ;)

Code: Alles auswählen

$ ip address
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: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:19:82:de brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.27/24 brd 192.168.178.255 scope global dynamic enp0s3
       valid_lft 862113sec preferred_lft 862113sec
    inet6 fe80::a00:27ff:fe19:82de/64 scope link 
       valid_lft forever preferred_lft forever
3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:43:04:71 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:43:04:71 brd ff:ff:ff:ff:ff:ff
6: veth4350LM@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UP group default qlen 1000
    link/ether fe:d9:07:b0:a8:8d brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::fcd9:7ff:feb0:a88d/64 scope link 
       valid_lft forever preferred_lft forever
Das ip address im Container:

Code: Alles auswählen

# ip address
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
5: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:d4:bb:40 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.122.143/24 brd 192.168.122.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fed4:bb40/64 scope link 
       valid_lft forever preferred_lft forever
Mir ist schon klar, dass es (in meinem Fall) nicht viel Sinn ergibt, wenn die Clients im "echten" lokalen Netzwerk sich im Bereich 192.168.178.* bewegen und der Container aber die IP 192.168.122.143 besitzt.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: LXC: Container von Außen nicht erreichbar

Beitrag von buhtz » 12.05.2021 16:41:49

Es gibt da wohl einen router mode mit lxc.net.0.veth.mode = router (release news) ab Version 3.2.1. Debian stable steht aber bei 3.0.3. Bin aber auch unsicher, ob das überhaupt das ist, was ich suche.

EDIT: Von DebianVirtualBox bin ich es gewohnt, die Art der Netzwerk-Config in einem Drop-Down Menu auszusuchen. Fertig und läuft. Ich muss keine Router, Bridges oder Firewall-Regeln einrichten. Bin etwas verwirrt darüber, wo ich jetzt bei LXC ansetzen muss.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: LXC: Container von Außen nicht erreichbar

Beitrag von buhtz » 13.05.2021 13:28:00

OK, lassen wir das LXC Kram mal weg. Es geht hier um ne Bridge.

3171

Ja, das ist keinen Bridge. Wollte nur die Logik klar machen, von dem was ich mir wünsche. Der Container soll mit allen physischen Clients im (von der Fritz.Box verwalteten) Netzwerk gleichberechtigt sein.

Verstehe ich das richtig?
  • Im Host erzeuge ich eine Bridge.
  • Diese Host-Bridge bekommt die physische LAN-Schnittstelle enp2s0 (ehm. eth0) und die Schnittstelle des Containers als Port?
  • Frage: Wie kommt dann die Fritz.Box (also das lokale Netzwerk incl. Internetz-Zugang) hier ins Spiel?
  • Frage: Wie sieht eine Container-Schnittstelle von Außen aus bzw. wie ist sie benannt? Mit ip addres sehe ich ja normalerweise die interne Repräsentation der Netzwerkschnittstellen (LAN, WLAN, ...) meines PCs. Also "Innen" ist enp2s0 und "Außen" ist das LAN1 (da wo ich das RJ45-LAN-Kabel reinstecke). Wie ist das "Innen" und "Außen" bei einem Container?
  • Im Container muss ich gar nix konfigurieren?
Durch die vielen Optionen und Varianten im Wiki, hab ich nun vermutlich meine Bridge schon zerkonfiguriert. debian ist der Host und foobar der Container.

Der Host (ist eigentlich eine VirtualBox VM)

Code: Alles auswählen

root@debian# bridge -d link
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 master virbr0 virbr0
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 master virbr0 state disabled priority 32 cost 100 
    hairpin off guard off root_block off fastleave off learning on flood on mcast_flood on neigh_suppress off vlan_tunnel off isolated off virbr0-nic
8: lxcbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 master lxcbr0 lxcbr0
10: vethQPYDS1@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master virbr0 state learning priority 32 cost 2 
    hairpin off guard off root_block off fastleave off learning on flood on mcast_flood on neigh_suppress off vlan_tunnel off isolated off vethQPYDS1
Und der LXC-Container

Code: Alles auswählen

root@foobar# ip address
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
9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:d4:bb:40 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.122.143/24 brd 192.168.122.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fed4:bb40/64 scope link 
       valid_lft forever preferred_lft forever
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: LXC: Container von Außen nicht erreichbar

Beitrag von bluestar » 13.05.2021 14:23:17

buhtz hat geschrieben: ↑ zum Beitrag ↑
13.05.2021 13:28:00
Verstehe ich das richtig?
Im Host erzeuge ich eine Bridge.
Diese Host-Bridge bekommt die physische LAN-Schnittstelle enp2s0 (ehm. eth0) und die Schnittstelle des Containers als Port?
Das ist soweit richtig und diese Bridge arbeitet wie ein Switch/Hub auf halt als Software.... Auf dem Host konfigurierst du deine IP-Adresse auf dem Bridge-Device.
buhtz hat geschrieben: ↑ zum Beitrag ↑
13.05.2021 13:28:00
Frage: Wie kommt dann die Fritz.Box (also das lokale Netzwerk incl. Internetz-Zugang) hier ins Spiel?
Die Bridge leitet allen Traffic wie ein Switch weiter. Deine Fritzbox sieht deinen Host ganz normal und sie sieht alle Container genauso im gleichen Subnetz.
buhtz hat geschrieben: ↑ zum Beitrag ↑
13.05.2021 13:28:00
Frage: Wie sieht eine Container-Schnittstelle von Außen aus bzw. wie ist sie benannt? Mit ip addres sehe ich ja normalerweise die interne Repräsentation der Netzwerkschnittstellen (LAN, WLAN, ...) meines PCs. Also "Innen" ist enp2s0 und "Außen" ist das LAN1 (da wo ich das RJ45-LAN-Kabel reinstecke). Wie ist das "Innen" und "Außen" bei einem Container?
Im Container ist "innen" das eth0-Device im Container und "außen" auf dem Host heißt das passende Ende "vethXXXXXX".
buhtz hat geschrieben: ↑ zum Beitrag ↑
13.05.2021 13:28:00
Im Container muss ich gar nix konfigurieren?
Wenn deine Fritzbox DHCP macht, dann holt sich dein Container auch über DHCP eine IP.


Letztlich sieht das so aus die Netzwerkkonfiguration für deinen Host so aus bei DHCP:

Code: Alles auswählen

iface br0 inet dhcp
    bridge_ports enp2s0
Und deine Container lässt du alle an br0 binden:

Code: Alles auswählen

lxc.net.0.type = veth
lxc.net.0.link = br0
lxc.net.0.flags = up
innerhalb des Containers steht eth0 dann auch auf DCHP:

Code: Alles auswählen

iface eth0 inet dhcp
Wahlweise kannst du auf dem Host (br0) bzw. deine Container auch mit festen IPs betreiben. Wichtig dabei ist lediglich alles liegt in einem Subnetz (Fritzbox Standard: 192.168.178.0/24), DNS-Server und Gateway sind die Fritzbox sowohl für Host als auch für die Container.

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: LXC: Container von Außen nicht erreichbar

Beitrag von buhtz » 15.05.2021 23:02:18

Hab ich es richtig verstanden, dass ich hier eine "Independent bridge" will?

OK, ich versuche deine Anleitung mit dem obigen Wiki-Artikel in Einklang zu bringen und bin gerade an einer bestimmten stelle verwirrt. Habe das Debian nochmal ganz frisch installiert.

Was ich bisher gemacht habe.

Habe eine Bridge im Host hinzugefügt und den Host "eingesteckt". Hier sind jetzt drei neue Zeilen am Ende von /etc/network/interfaces:

Code: Alles auswählen

$ cat /etc/network/interfaces
source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp0s3
iface enp0s3 inet dhcp

auto br0
iface br0 inet dhcp
  bridge_ports enp0s3
Der Output von ip a ist wie erwartet.

Dann habe ich, mit deinen Änderungen, dass Independent bridge setup durchgeführt.
Die betreffenden Dateien sehen jetzt so aus.

Code: Alles auswählen

$ cat /etc/default/lxc-net
USE_LXC_BRIDGE="true"

$ cat /etc/lxc/default.conf
lxc.net.0.type = veth
lxc.net.0.link = br0
lxc.net.0.flags = up
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
Meinem Verständnis nach, passt nun aber der Output von ip a nicht mehr. Nach dem service lxc-net restart (steht so im Wiki!) habe ich zwei bridges im Host.

Code: Alles auswählen

$ 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: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 08:00:27:84:a4:c3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.36/24 brd 192.168.178.255 scope global dynamic enp0s3
       valid_lft 862440sec preferred_lft 862440sec
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 08:00:27:84:a4:c3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.38/24 brd 192.168.178.255 scope global dynamic br0
       valid_lft 862439sec preferred_lft 862439sec
    inet6 fe80::a00:27ff:fe84:a4c3/64 scope link 
       valid_lft forever preferred_lft forever
4: lxcbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.1/24 scope global lxcbr0
       valid_lft forever preferred_lft forever
Wo kommt lxcbr0 her? Hab ich nicht konfiguriert. Warum ist das da? Brauch ich das? Laut lxc-ls gibt es noch keinen Container.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: LXC: Container von Außen nicht erreichbar

Beitrag von bluestar » 15.05.2021 23:09:35

buhtz hat geschrieben: ↑ zum Beitrag ↑
15.05.2021 23:02:18
Hab ich es richtig verstanden, dass ich hier eine "Independent bridge" will?
Nein eigentlich willst du das genaue Gegenteil, du willst eine SimpleBridge, genauer eine host-shared bridge. Eine Independent Bridge basiert genau darauf, dass dort eben kein physikalisches Device enthalten ist sondern das zugewiesene IP-Netz ausschließlich über Routing auf die Host-IP erreichbar ist.
buhtz hat geschrieben: ↑ zum Beitrag ↑
15.05.2021 23:02:18
Habe eine Bridge im Host hinzugefügt und den Host "eingesteckt". Hier sind jetzt drei neue Zeilen am Ende von /etc/network/interfaces:

Code: Alles auswählen

$ cat /etc/network/interfaces
source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp0s3
iface enp0s3 inet dhcp

auto br0
iface br0 inet dhcp
  bridge_ports enp0s3
Wenn du enp0s3 in die Bridge aufnimmst, dann solltest du die Zeile iface enp0s3 inet dhcp weglassen.

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: LXC: Container von Außen nicht erreichbar

Beitrag von buhtz » 15.05.2021 23:27:41

bluestar hat geschrieben: ↑ zum Beitrag ↑
15.05.2021 23:09:35
Wenn du enp0s3 in die Bridge aufnimmst, dann solltest du die Zeile iface enp0s3 inet dhcp weglassen.
OK, erledigt.

Code: Alles auswählen

$ 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: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 08:00:27:84:a4:c3 brd ff:ff:ff:ff:ff:ff
3: lxcbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.1/24 scope global lxcbr0
       valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 08:00:27:84:a4:c3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.38/24 brd 192.168.178.255 scope global dynamic br0
       valid_lft 863950sec preferred_lft 863950sec
    inet6 fe80::a00:27ff:fe84:a4c3/64 scope link 
       valid_lft forever preferred_lft forever
Ich will also https://wiki.debian.org/LXC/SimpleBridg ... _as_bridge ?

Haben wir hier ein Benennungsproblem? Ist die lxcbr0 im Wiki das, wass in deiner Erklärung und meinem Output br0 ist?

Aber ansonsten passt mein Setup IMHO zu dem was im Wiki beschrieben wird. Aber ich muss auch zugeben, dass ich bei beiden Bridge-Formen (host shared & independent) an der config keinen großen Unterschied sehe. Vielleicht ist das mein Problem ? :D

Aber wo kommt jetzt die zweite Bridge (lxcbr0) bei mir her?
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: LXC: Container von Außen nicht erreichbar

Beitrag von bluestar » 15.05.2021 23:33:55

buhtz hat geschrieben: ↑ zum Beitrag ↑
15.05.2021 23:27:41
Haben wir hier ein Benennungsproblem? Ist die lxcbr0 im Wiki das, wass in deiner Erklärung und meinem Output br0 ist?
Eigentlich nicht:
* lxbr0 ist eine Independent Bridge, die hat einen anderen ganz eigenen IP-Bereich.
* br0 ist eine host-shared Bridge.
buhtz hat geschrieben: ↑ zum Beitrag ↑
15.05.2021 23:27:41
Aber ansonsten passt mein Setup IMHO zu dem was im Wiki beschrieben wird. Aber ich muss auch zugeben, dass ich bei beiden Bridge-Formen (host shared & independent) an der config keinen großen Unterschied sehe. Vielleicht ist das mein Problem ? :D
Der Unterschied zwischen br0 (enthält dein physikalisches Interface enp0s3) und die lxbr0 enthält nunmal kein physikalisches Interface. lxbr0 hat ja einen ganz eigenen IP-Bereich 10.0.3.0/24 und nutzt nicht das IP-Netz von deiner Fritzbox (192.168.178.0/24)

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: LXC: Container von Außen nicht erreichbar

Beitrag von buhtz » 16.05.2021 00:10:09

bluestar hat geschrieben: ↑ zum Beitrag ↑
15.05.2021 23:33:55
Der Unterschied zwischen br0 (enthält dein physikalisches Interface enp0s3) und die lxbr0 enthält nunmal kein physikalisches Interface. lxbr0 hat ja einen ganz eigenen IP-Bereich 10.0.3.0/24 und nutzt nicht das IP-Netz von deiner Fritzbox (192.168.178.0/24)
Das verstehe ich schon, weil das ja auch im Output von ip a so steht.
Aber warum existiert lxcbr0 überhaupt? Ich habe es nicht konfiguriert - z.B. in die interfaces-Datei geschrieben.
Außerdem benötige ich doch keine zweite Bridge, oder?

Die Container werden doch alle zu br0 mit eingestöpselt, damit sie die FritzBox sehen und die FritzBox sie. Oder?
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: LXC: Container von Außen nicht erreichbar

Beitrag von bluestar » 16.05.2021 00:15:05

buhtz hat geschrieben: ↑ zum Beitrag ↑
16.05.2021 00:10:09
Aber warum existiert lxcbr0 überhaupt? Ich habe es nicht konfiguriert - z.B. in die interfaces-Datei geschrieben.
Schau dir die Dokumentatino an https://wiki.debian.org/LXC/SimpleBridge#Using_lxc-net Die Bridge lxbr0 wird von lxc-net automatisch angelegt.
buhtz hat geschrieben: ↑ zum Beitrag ↑
16.05.2021 00:10:09
Außerdem benötige ich doch keine zweite Bridge, oder?
Korrekt.

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: LXC: Container von Außen nicht erreichbar

Beitrag von buhtz » 16.05.2021 00:25:23

OK, jetzt verstehe ich, wo die bridge herkommt. Aber wir sind uns auch einig, dass ich diese eigentlich nicht benötige?

Was nun?

Das Wiki ist (für mich) wirklich wenig hilfreich. Wenn ich das Wiki richtig verstehe, wird (weil default) die lxcbr0 immer angelegt, egal ob ich den "independet" oder "host shared" Weg aus dem Wiki gehe.

Kann man verstehen, dass ich verwirrt bin? ;)
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: LXC: Container von Außen nicht erreichbar

Beitrag von bluestar » 16.05.2021 00:43:21

buhtz hat geschrieben: ↑ zum Beitrag ↑
16.05.2021 00:25:23
Was nun?
Trag in /etc/default/lxc-net folgende Zeile ein:

Code: Alles auswählen

USE_LXC_BRIDGE="false"
Dann startest du den Rechner einmal neu und lxbr0 sollte verschwunden sein.

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: LXC: Container von Außen nicht erreichbar

Beitrag von buhtz » 16.05.2021 09:56:52

OK, wir kommen der Sache näher. Aber bevor ich hier alles rate und wieder zerkonfigiere, frage ich lieber (blöd).

Kreation eines unprivilegierten Containers schlägt jedoch fehl - mit verständlichen, aber unerwarteten Fehlermeldungen. Vermutlich auch ein Problem des Wikis/Wiki-Lesers (suchts euch aus).

Code: Alles auswählen

user@spielwiese$ lxc-create -n foobar -t debian
lxc-create: foobar: parse.c: lxc_file_for_each_line_mmap: 100 No such file or directory - Failed to open file "/home/user/.config/lxc/default.conf"
lxc-create: foobar: conf.c: chown_mapped_root: 3150 No uid mapping for container root
lxc-create: foobar: lxccontainer.c: do_storage_create: 1288 Error chowning "/home/user/.local/share/lxc/foobar/rootfs" to container root
lxc-create: foobar: conf.c: suggest_default_idmap: 4777 You must either run as root, or define uid mappings
lxc-create: foobar: conf.c: suggest_default_idmap: 4778 To pass uid mappings to lxc-create, you could create
lxc-create: foobar: conf.c: suggest_default_idmap: 4779 ~/.config/lxc/default.conf:
lxc-create: foobar: conf.c: suggest_default_idmap: 4780 lxc.include = /etc/lxc/default.conf
lxc-create: foobar: conf.c: suggest_default_idmap: 4781 lxc.idmap = u 0 100000 65536
lxc-create: foobar: conf.c: suggest_default_idmap: 4782 lxc.idmap = g 0 100000 65536
lxc-create: foobar: lxccontainer.c: do_lxcapi_create: 1869 Failed to create (none) storage for foobar
lxc-create: foobar: tools/lxc_create.c: main: 327 Failed to create container foobar
Im Wiki wird die Notation .config/lxc/default.conf verwendet. Hab ich nie zuvor gesehen. Würde behauptet, dass ist nicht standard konform. Ich konnte hier nur raten. Ich wählte /etc/lxc/default.conf.

Damit hat lxc nun offensichtlich ein Problem, wenn ich als nicht-root einen Container erzeugen will. Ich kann nicht nachvollziehen, warum lxc nicht (global) in /etc nach einer config-Datei sucht, wenn es im User-home keine findet. Ist doch gängiges Verhalten. Das ist auch im Wiki nicht explizit beschrieben, bei welcher Art von Container ich die config wo erzeugen muss.

Zweites Problem scheint das uid-mapping zu sein. Den Grundgedanken davon hab ich verstanden. Was ich nicht verstehe ist, warum das hier ein Problem ist. Ich habe kein mount hin zum host-Dateisystem angegeben. Ein uid-mapping ist also nicht nötig. Zumal im Wiki bis zum Punkt lxc-create ... davon auch keine Rede ist.

Wenn das uid-mapping mandatory ist, kann doch lxc das auch selbstständig per default einrichten. Warum muss ich das tun? Daher geh ich davon aus, dass es auch ohne gehen müsste.

Also wie reagiere ich jetzt auf diese Fehlermeldungen? Evtl. verstehe ich sie ja auch falsch?
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

Antworten