Edomi ProxMox- bzw. LXC-Template

[Amokd0c]

auf "local" läuft das Backup durch. Auf dem NFS bricht er ab... also ist der Container ansich ja in Ordnung.
kann das was mit der Dateiendung zu tun haben? .tmp zum Beispiel?

[Amokd0c]

ok habs!

in der vzdump.conf muss das /tmp Verzeichnis eingefügt werden. Dann läufts sauber auf NFS durch...

vzdump default settings


#tmpdir: DIR
tmpdir: /tmp
#dumpdir: DIR
#storage: STORAGE_ID
#mode: snapshot|suspend|stop
#bwlimit: KBPS
#ionice: PRI
#lockwait: MINUTES
#stopwait: MINUTES
#size: MB
#stdexcludes: BOOLEAN
#mailto: ADDRESSLIST
#maxfiles: N
#script: FILENAME
#exclude-path: PATHLIST
#pigz: N

[starwarsfan]

Hi

in der vzdump.conf muss das /tmp Verzeichnis eingefügt werden. Dann läufts sauber auf NFS durch...

Du schraubst händisch an irgendwelchen Konfigurationen herum? Zumindest an dieser Stelle musste ich das noch nie machen und alle Container werden sauber auf dem NAS gebackup. Zumindest kann ich mich im Moment nicht daran erinnern. Aber ich werde da zuhause nochmal genau schauen...

[Amokd0c]

Aber ich werde da zuhause nochmal genau schauen...

Du! Ich kann dir das nicht erklären, warum und wieso. Auch war ich der Meinung, da ich schon mal Edomi auf dieser Maschine habe laufen lassen, auch das Backup schon mal funktioniert hat. Sollte auch dein Image gewesen sein.
Habe danach alle VMs inkl. dem CT ein Backup nach Plan machen lassen. Läuft!
Die Lösung hab ich auch erstmal mit den richtigen Schlagworten suchen müssen.

Auch hatte anfangs der Emailversand nach dem Backup problemlos funktioniert. Der tut es aber auch nimmer, keine Ahnung wieso!

Grüße...

[Smarty]

Hallo Proxmox-Experten,

hier läuft seit geraumer Zeit Edomi 2.03 in Yves LXC-Container. Durch Zufall habe ich jetzt festgestellt, dass der sshd nach einem Neustart nicht mehr aktiv ist. Nach einem

systemctl start sshd

startet er wieder normal. Bei dieser Gelegenheit habe ich mal die Bootmeldungen durchgesehen (journalctl -b) und jede Menge Fehler entdeckt, hier ein Auszug:

Jun 15 15:31:08 edomi2 ntpd[1201]: 0.0.0.0 c615 05 clock_sync
Jun 15 15:31:08 edomi2 ntpd[1201]: ntp_adjtime() failed: Operation not permitted
Jun 15 15:32:08 edomi2 ntpd[1201]: ntp_adjtime() failed: Operation not permitted
Jun 15 15:34:23 edomi2 ntpd[1201]: ntp_adjtime() failed: Operation not permitted
Jun 15 15:35:26 edomi2 systemd[1]: user.slice: Failed to set invocation ID on control group /user.slice, ignoring: Operation not permitted
Jun 15 15:35:26 edomi2 systemd[1]: user-0.slice: Failed to set invocation ID on control group /user.slice/user-0.slice, ignoring: Operation not permitted
Jun 15 15:35:26 edomi2 systemd[1]: Created slice User Slice of root.
Jun 15 15:35:26 edomi2 systemd[1]: user.slice: Failed to set invocation ID on control group /user.slice, ignoring: Operation not permitted
Jun 15 15:35:26 edomi2 systemd[1]: user-0.slice: Failed to set invocation ID on control group /user.slice/user-0.slice, ignoring: Operation not permitted
Jun 15 15:35:26 edomi2 systemd[1]: user@0.service: Failed to set invocation ID on control group /user.slice/user-0.slice/user@0.service, ignoring: Operation not permitted
Jun 15 15:35:26 edomi2 systemd[1]: Starting User Manager for UID 0...
Jun 15 15:35:26 edomi2 systemd[1]: session-c1.scope: Failed to set invocation ID on control group /user.slice/user-0.slice/session-c1.scope, ignoring: Operation not permitted

Könnte es sein, dass sich das CentOS diverse Stati nicht merken kann und daher auch die Aktivierung des ssh-Servers durch

systemctl enable sshd

den Reboot nicht übersteht? Der Container ist unprivileged und nesting ist aktiviert.

Als Nicht-Experte in Sachen Proxmox hoffe ich da auf eure Inputs, um den Fehler eingrenzen zu können.

Besten Dank!

[starwarsfan]

Hallo miteinander,

eben habe ich einen neuen Thread zur RockyLinux-basierten neuen Template-Version aufgemacht. Bzgl. diesen neuen Templates weiter im dortigen Thread, hier nur noch zu den alten Versionen.

Danke und weiterhin viel Spass mit Edomi!

[trollmar]

Hi,

ich nutze für Edomi CT sporadisch die Proxmox Backup Funktion.
Alle meine anderen CT's und VM's gehen aber täglich auf einen Proxmox backup Server.

Meine Edomi CT Root Disk hat 48GB wobei diese z.Z 50% genutzt wird,

Im Januar hab ich im supspend Mode ein backup auf PBS gemacht das war 19Gb groß.
Wenn ich aktuell ein Backup mit Suspende auf meinen PBS machen dann wird das Backup 118GB groß 😎.

Die Disk ist wie gesagt 48GB ;-)



Hab dazu was gefunden aber noch nicht ausprobiert.

Was mit DD innerhalb des Conatiners.

dd if=/dev/zero of=zero bs=64k; sync; sync; sync; rm -f zero

Wobei ich hier jetzt erstmal nicht weis was /dev/zero hier sein soll.

Habt ihr sowas auch schonmal gehabt und wie umgehe ich das bzw wie habt ihr das gelöst?

[starwarsfan]

Hallo Sebastian,

mein Edomi-Container wird (wie alle anderen Container auch) regelmässig auf ein NAS gesichert. Das Problem hatte ich noch nie.

Mit dem Befehl schreibst Du in einem dauerhaften Stream NULL-Bytes, also \0 in die Datei "zero". Das wird vermutlich so lange laufen, bis die Disk des Systems voll ist. Danach macht er dreimal "sync", um dann zuletzt diese grosse Datei wieder zu löschen. Was das nun genau bewirkten soll, kann ich so aus dem Stehgreif auch nicht sagen. Vermutlich zielt das so in die Richtung, sämtlichen alten Datenmüll auf der "Platte" des Containers zu löschen, da dieser durch NULL komplett überschrieben wird. Eben bis die Disk voll ist. Unterm Strich eine heikle Operation an einem Produktivsystem. Wo hast Du den Hinweis denn gefunden?

[trollmar]

Hi,

Danke Yves das du mir das erklärt hast! Ja ist etwas heikel.



Ich finde dazu eigentlich immer das "Sparse Files" wohl schuld ist.
.
https://forum.proxmox.com/threads/so...-of-gbs.78881/
https://unix.stackexchange.com/quest...g-sparse-files

Nur da finde ich bei mir nichts bzw es ist so unübersichtlich mit "find" das ich es nicht erkenne.


Gut die Lösung

dd if=/dev/zero of=zero bs=64k; sync; sync; sync; rm -f zero

War dann eine Adaption von mir ;-)

Nur wie mach ich jetzt weiter?
Könnte natürlich sagen... gut ich steige mal auf Rocky von dir um ..aber ich will ja den Fehler finden 😀

[starwarsfan]

Kann es vielleicht sein, dass Du (incrementelle) Snapshots des Containers machst? Die sind dann beim Backup vermutlich auch dabei und das würde erklären, dass das Backup so gross ist...

[saegefisch]

Zum Thema Proxmox 6.x auf 7.2.11 eine Frage, weil ich im Vorfeld doof war und etwas nicht geprüft habe bzw. davon ausging (wie bei den anderen cgroup-Themen) dass ich die Änderungen auch nach dem Upgrade machen kann.
* Per Script täglich Backup vom PROD edomi (eigenen HW) auf NAS -> kein Problem
* per Proxmox täglich backup meiner edomi-LXCs (fallback-PROD,DEV) auf NAS -> kein Problem (technisch)

Nach dem Upgrade grade und etwas Justage laufen alle VM/LXCs wieder. Nur die beiden edomis nicht. Werden grün angezeigt, aber keine Konsole, kein SSH, nix. Die prod-fallback VM kann ich jederzeit neu aufbauen aus meinem Echt-System, aber vom DEV habe ich mir vorher schon länger kein edomi-Backup gemacht - weil ich Depp dachte, dass ich die Änderungen später machen kann und ja die täglichen Proxmox-Backups habe. Aber die laufen natürlich genauso wenig, wegen des cgroup2-Gedöns.

Das ist nicht wirklich schlimm, aber ein paar Sachen waren da schon, die ich gerne wieder hätte, weil ich die nur dort entwickelt hatte, aber noch nicht ins PROD gebracht habe und diverse Testszenarien für eigenen LBS. Hose runter! Ich weiß, ich sag's ja selber immer: Kein Backup, kein Mitleid!

Dennoch die Frage, ob man die /etc/systemd/system/edomi.service eines nicht laufenden LXC-Containers irgendwie ändern kann (gemäß Sebastians aka bas29 Hinweisen), um edomi doch wieder starten zu lassen? Wo (Pfad) findet man die auf dem proxmox-Server?

Alternativ: Kann man in einem Backup vzdump...tar.std die /etc/systemd/system/edomi.service direkt ändern und dann das geänderte Backup in Proxmox zurückspielen? Hat das schon jemand erfolgreich gemacht? Vermutlich std entpacken, dann die Zieldatei aus tar exrahieren, ändern, zurück in tar und das dann wieder std-komprimieren und in Proxmox zurückspielen...

[saegefisch]

Das ganze entwickelt sich zu einem Proxmox-Lehrstück...
Vielleicht hilft das ja grundsätzlich mal jemand anderem in einem anderen Proxmox-Kontext
LXE-Config findet man an 2 Stellen, den hier interessanten Mount-punkt in der 2.

/etc/pve/local/lxc/<container-ID>.conf​
/var/lib/lxc/<container-ID>/config.​

Damit einen Schritt weiter - theoretisch:
Ändern einer Datei im Container funktioniert per SSH vom gestoppten LXC:

sudo pct mount <container-ID>
sudo nano /var/lib/lxc/<container-ID>/rootfs/etc/systemd/system/edomi.service
sudo pct unmount <container-ID>

Aber das reicht nicht, LXC startet noch immer nicht sauber, weil der andere Hinweis war ja das Update von systemd unter CentOS7. Das sollte gehen mit:

sudo pct mount <container-ID>
sudo pct start <container-ID>
sudo pct enter <container-ID>
wget https://copr.fedorainfracloud.org/coprs/jsynacek/systemd-backports-for-centos-7/repo/epel-7/jsynacek-systemd-backports-for-centos-7-epel-7.repo -O /etc/yum.repos.d/jsynacek-systemd-centos-7.repo
yum update systemd
exit
sudo pct stop <container-ID>
sudo pct unmount <container-ID>

aber nach Start kommt

WARN: old systemd (< v232) detected, container won't run in a pure cgroupv2 environment! Please see documentation -> container -> cgroup version.
Task finished with 1 warning(s)!

und damit kein Netzwerk und damit funktioniert wget auch nicht. Daher wget auf host ausgeführt und an die richtige stelle des gemounteten edomi-LXC verschoben.
Aber natürlich will

yum update systemd

noch mal was laden, das repo enthält ja nur die Abhängigkeiten und Links - vermute ich, damit kenne ich mich nicht aus.

Frage: Was muss ich vorab herunter laden und in den LXC-Container wohin schieben, damit yum update systemd alles nötige findet und daher ohne Netzwerk funktioniert?

Nachtrag: Theoretisch wohl mit

yum update --downloadonly --downloaddir=/var/lib/lxc/<container-ID>/rootfs/var/cache/yum/x86_64/7/??? systemd

, aber der Proxmox-Host kennt kein yum. Und in welchen Pfad GENAU müsste es unter CentOS7 liegen, damit yum es dort ohne Netzwerk findet?

----
Nachtrag 05.10.2022: Wenn niemand mehr eine smarte Idee oder Antworten hat
A) welche Dateien ich (unter CentOS 7) für

yum update systemd

brauchen würde und wie ich
B) die unter Debian (Proxmox Host) herunterladen kann, um sie dann
C) in die edomi-VM zu schieben (welcher genau Pfad braucht yum dort?)
und dort eben yum update systemd offline ausführen zu können... werde ich mich wohl von meiner alten edomi-DEV verabschieden und mit einem frischen LXC anfangen...
Kein (richtiges) Backup, kein Mitleid mit mir selber...

[Timowald]

Hallo, gibt es irgendwo eine Schritt für Schritt Anleitung wie man Edomi auf Proxmox installiert? Bekomme es nicht zum laufen.

[starwarsfan]

Hi

gibt es irgendwo eine Schritt für Schritt Anleitung wie man Edomi auf Proxmox installiert?

Natürlich, erstes Posting in diesem Thread.

[mmarkus]

im ersten Beitrag von diesem Thread steht doch die Anleitung. Ansonnsten, was genau läuft nicht?