Restore von CT Backup funktioniert nicht

Nicht nur die Anbieter, sondern (vor allen) die Betreiber. Auf der Arbeit haben wir mittlerweile neben den Ubuntu-Mirror bestimmt 20 3rd-party-Repositories, weil irgendwelche Entwickler unbedingt die neueste Version von docker oder ihrer Lieblingsdatenbank verwenden wollen. Sobald da ein Upgrade einen breaking change reinbringt, hat man dann das Vergnügen. Da wäre mir die Variante mit den Containern doch deutlich lieber: Damit machen die Entwickler nur ihre eigene Spielwiese kaputt, nicht die vom Rest.
Je mehr unixoide Clients virtualisiert sind, desto mehr Charme entwickelt eine Containerisierung.
Aber auch heutzutage sind leider 95% aller virtualisierten Umgebungen immer noch nicht unixoid, sofern wir nicht von Hyperscalern sprechen. Damit ist ist meistens schon Essig mit Containern.

Zentrale Systeme hingegen, sind in meinem Umfeld fast ausschließlich unixoid, aber trotzdem alle virtualisiert. Da fummelt auch keine umtriebige Horde von Entwicklern drauf rum. Also wieder kein Grund diese zu containerisieren statt zu virtualisieren.

[OT]
Beim Zugriff auf unixoide Desktop-Clients nervt z.B. der Remotezugriff an sich viel mehr.
Entweder man nutzt extrem nerviges VNC oder schlägt sich mit RDP rum.
Letzteres funktioniert prinzipiell zwar sehr gut, war aber schon immer fummelig. Seit Aussterben von X11 ist es in letzter Zeit jedoch kaum mehr nutzbar. Ich hoffe diese Entwicklung ändert alsbald die Richtung.
Der Zugriff auf die gottgleiche, beste aller Zeiten Plattform des Weltmarktführers funktioniert ganz gut.
Von Unterstützung aufstrebender Plattformen wie ARM etc. will ich gar nicht erst anfangen.
/[OT]

Ich will Container keinesfalls verteufeln. Sie machen meine reale Umgebung nur nicht effizienter.

Wollte ich nur mal darlegen, damit kein falscher Eindruck meines Standpunkts bzgl. Containern entsteht.

P.S.:
Bei Containern ist auch immer die Frage, welche Geschmacksrichtung es denn sein darf.
Parallels, LXC, Kubertnetes, Docker, Snap, Flatpak etc.?
Meistens gibt es die duften Dinger immer nur in einem Format, dass mein Host gerade nicht unterstützt.
Da entwickelte sich in meinen Augen unfassbar viel in die falsche Richtung.
Diese absurde Vielfalt gibt es bei KVM nicht.
 
Last edited:
Die aktive Diskussionskultur im Thread kann man auf jeden Fall nicht abstreiten. Die meisten Beträge haben jedoch leider sehr wenig mit den originalen Fragen von mir oder mit diesbezüglichen Klärungsversuchen dazu zu tun.
Falls weiterhin der Bedarf besteht die Unterschiede oder Feinheiten zwischen CT und VM zu diskutieren, dann würde ich mir stark wünschen, dass dafür ein eigenen Thread aufgemacht wird.
Vielen Dank!


Hi Johannes S,

ich habe jetzt zwei Container erstellt und versuche ein Minimal Viable Container zu erstellen, damit ich das Problem besser nachstellen bzw. dokumentieren kann.
In den ersten paar Tests konnte ich das Verhalten bisher leider noch nicht nachstellen. Die beiden Container aber genau 1:1 herstellen wie der original CT 110 wird ein bisschen brauchen.

Bezüglich der OpenVPN bzw. Wireguard Frage verstehe ich nicht ganz was genau das mit der Fragenstellung zu tun hat. Ich habe weder ein Problem noch Schmerzen beim Aufsetzen oder Handeln von OpenVPN oder Wireguard. Mein Problem ist der unerfolgreiche Restore eines CT in Proxmox. Was genau übersehe ich hier aus deiner Sicht?
 
Last edited:
  • Like
Reactions: Johannes S
Die aktive Diskussionskultur im Thread kann man auf jeden Fall nicht abstreiten. Die meisten Beträge haben jedoch leider sehr wenig mit den originalen Fragen von mir oder mit diesbezüglichen Klärungsversuchen dazu zu tun.
Falls weiterhin der Bedarf besteht die Unterschiede oder Feinheiten zwischen CT und VM zu diskutieren, dann würde ich mir stark wünschen, dass dafür ein eigenen Thread aufgemacht wird.
Vielen Dank!


Hi Johannes S,

ich habe jetzt zwei Container erstellt und versuche ein Minimal Viable Container zu erstellen, damit ich das Problem besser nachstellen bzw. dokumentieren kann.
In den ersten paar Tests konnte ich das Verhalten bisher leider noch nicht nachstellen. Die beiden Container aber genau 1:1 herstellen wie der original CT 110 wird ein bisschen brauchen.

Bezüglich der OpenVPN bzw. Wireguard Frage verstehe ich nicht ganz was genau das mit der Fragenstellung zu tun hat. Ich habe weder ein Problem noch Schmerzen beim Aufsetzen oder Handeln von OpenVPN oder Wireguard. Mein Problem ist der unerfolgreiche Restore eines CT in Proxmox. Was genau übersehe ich hier aus deiner Sicht?
Gerade an den hier entflammten Diskussionen könntest du schon profitieren.
Du rufst aber eher mit "ich will, ich will" nach Mami.
Zusätzlich lieferst du unterirdische und willenlose "Informationen", die keine Sau reliabel beantworten kann.
Vielleicht hat irgendwer noch den Nerv, dir aus dem Bettchen zu helfen.
Das Ganze offenbar noch auf deinem persönlichen Spielplatz.
Dabei wünsche ich Dir Erfolg.
 
In den ersten paar Tests konnte ich das Verhalten bisher leider noch nicht nachstellen. Die beiden Container aber genau 1:1 herstellen wie der original CT 110 wird ein bisschen brauchen.

Hmpf, schade. Ich war halt am Überlegen, ob es vielleicht aus unklaren Gründen irgendeine Besonderheit beim piVPN-Setup gibt, die dann beim Restore den Fehler triggert. Das kann man dann wohl ausschließen.

Bezüglich der OpenVPN bzw. Wireguard Frage verstehe ich nicht ganz was genau das mit der Fragenstellung zu tun hat. Ich habe weder ein Problem noch Schmerzen beim Aufsetzen oder Handeln von OpenVPN oder Wireguard. Mein Problem ist der unerfolgreiche Restore eines CT in Proxmox. Was genau übersehe ich hier aus deiner Sicht?
Vergiss es, das liegt daran, dass ich in der Nebendebatte den Faden verloren habe, was eigentlich dein Problem war ;)
 
Moin,
sorry für die späte Antwort. Ich habe mir den stacktrace jetzt erst angeschaut.

Code:
1893 [pid 16113] openat(AT_FDCWD, "/run/user/0", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 EACCES (Permission denied)                                                               
1894 [pid 16113] ioctl(0, TCGETS, {c_iflag=ICRNL|IXON, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}     ) = 0
1895 [pid 16113] ioctl(0, TCGETS, {c_iflag=ICRNL|IXON, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}     ) = 0                                                                                                           
1896 [pid 16113] ioctl(1, TCGETS, 0x7ffd32f897b0) = -1 ENOTTY (Inappropriate ioctl for device)

Er beschwert sich da ja an der Stelle, dass er nicht auf "/run/user/0" zugreifen kann und an anderer Stelle, das er nicht auf /var/log/journal zugreifen kann. Mit dem lxc-usernsexec sollte er seine priviledges auch bereits direkt am Anfang droppen und dann fehlen ihm ggf. Rechte.
Das S tarten als privilegierter Container, wie bereits vorgeschlagen, hätte das eigentlich fixen können.

Allerdings gibt es ja in dem Container ja noch den VPN-User - theoretisch ist die Nutzung kein wirklicher Sicherheitsgewinn, falls dieser dazu verwendet wird um Prozesse mit separierten Berechtigungen zu starten. Denn die Verwendung eines unprivilegierten Containers, sorgt mittels des UID/GID mappings ja bereits dafür das den Prozessen root berechtigungen simuliert werden, während sie auf dem eigentlichen Container Host in einem anderen Usercontext laufen.

Du hattest ja geschrieben, dass das Journalctl erst nachträglich in Verwendung genommen wurde.
Hast du noch einen Backupstand von davor? /var/log/journal hat nämlich erweiterte Filesystem ACLs und ich bin mir nicht sicher,
ob das kompatibel ist mit der Konfiguration des LXC UID/GID Mappings.

Ist die Fehlermeldung bzw. der Stacktrace, wenn der als Privilegierter Container wiederhergestellt wird, dieselbe?

BG, Lucas