NEWS
Proxmox Update 6.x --> 7.x
-
@wal sagte in Proxmox Update 6.x --> 7.x:
wieso sollte ich iobroker neu aufsetzen
weil über die Zeit sich ggf soviel ansammelt was man mal installiert hatte, es auch nach einer Deinstallation zu "Restbeständen" kommt, die nicht entfernt wurden, oder oder oder
dafür hat man ein "blankes" Iobroker Backup, der sich seine Adapter bei einer Neuinstallation wieder neu zieht und somit einen "sauberen" iobroker vorfindet.
Hatte selbst vor langer Zeit, trotz Proxmox backups meinen iobroker neu installiert, nachdem so viel gebastelt wurde, weil Probleme erst Tage später aufgetaucht sind und sich das wie ein Rattenschwanz durchgezogen hatte. -
@liv-in-sky
folgendes, damit host und client auf denselben datensatz zugreifen können müssen beide dieselben berechtigungen uber diesen ordner haben.Auf dem Host:
addgroup --gid 101000 iobroker-backups
chgrp -R iobroker-backups /DatenNAS/BACKUP-IOBROKER
chmod -R 2775 /DatenNAS/IOBROKER-BACKUP
setfacl -Rm g:101000:rwx,d:g:101000:rwx /DatenNAS/IOBROKER-BACKUP
Im Container:
addgroup --gid 1000 iobroker-backups
usermod -aG iobroker-backups iobroker
chown -R iobroker:iobroker /opt/iobroker/backups
Ich bin leider gerade nur am Handy, so sollte es zumindest in der Theorie klappen.
-
@crunkfx ich werde das thema morgen weiter bearbeiten
ich danke dir für deinen "handy support" und werde das mal studierenund mich dann wieder melden
-
@liv-in-sky Kein Problem, es könnte sein dass du vor dem letzten step auch noch dem root User ,als der du ja im Container angemeldet bist dieselben rechte geben musst:
usermod -aG iobroker-backups root
-
@crunkfx nur noch kurz - das wird wilder - und heute geht nix mehr
es gibt dafür ein id_map im config file des containers - das genau das machen soll, was du vorschlägst - die id wird gemapped bzw durchgereicht
-
@liv-in-sky Ich finde id mapping völlig unübersichtlich, deshalb hab ich das direkt mit Gruppen gemacht. Vielleicht ist es ja einen Versuch wert.
-
@crunkfx stimme dir voll zu - ich muss das erstmal genauer lesen - ist voll verwirrend
wenn ich es nicht checke, werde ich mal deine lösung probieren
-
bis jetzt habe ich es nur geschafft, dass alle ordner unter /opt/iobroker nobody/nogroup haben - beim anwenden eines idmap's
-
@liv-in-sky Hast du es nach meiner Anleitung versucht? Ich bin jetzt wieder am PC
-
@crunkfx war reifenwechseln - werde erst jetz weiter testen
-
wollte mich nochmal bei dir für deine hilfe bedanken und nochmal daran erinnern, dass du die lösung posten wolltest
es geht um : rechte in einem unpriviligierten container auf einen mountpoint
ich versuche mal das nochmal zusammenzufinden - falls falsch bitte mitteilen
HOST
addgroup --gid 101001 iobroker-backups1
chgrp -R iobroker-backups1 /DatenNAS/BACKUP-IOBROKER
chmod -R 2775 /DatenNAS/BACKUP-IOBROKER
setfacl -Rm g:101001:rwx,d:g:101001:rwx /DatenNAS/BACKUP-IOBROKER
war das hier der wichtige teil?
chown 101001:101001 /DatenNAS/BACKUP-IOBROKER
LXC
und weißt du noch den link dafür - wollte ich auch gerne aufheben
was muss dann noch auf dem lxc gemacht werden ? eigentlich nix - ode übersehe ich da was
-
@liv-in-sky Hi, ich hatte etwas Stress
So wie bei dir beschrieben ist es korrekt.
Auf dem Client musste nichts geändert werden.Die beiden verwendeten Quellen sind: https://gist.github.com/ajmassi/e6862294d114467b46f9b7f073921352
und: https://pve.proxmox.com/wiki/Unprivileged_LXC_containers#Using_local_directory_bind_mount_pointsLG
-
und nochmal ein dankeschön
-
@liv-in-sky Kein Thema
-
Edit: Update ist durchgelaufen. Scheint ohne Probleme zu laufen.
@crunkfx zum Thema "cgroup". Ich habe mal mit
pve6to7 --full
geschaut und es gibt nur eine Warnung zu meinem ioBroker CT100:
WARN: The following CTs have 'lxc.cgroup' keys configured, which will be ignored in the new default unified cgroupv2: CT 100 Often it can be enough to change to the new 'lxc.cgroup2' prefix after the upgrade to Proxmox VE 7.x
Ist das einfach einzustellen nach dem Update auf 7?
-
-
Hab ich nun ein update gemacht oder nicht? pve-Manager müsste doch auch 7.x sein, oder?
proxmox-ve: 7.1-1 (running kernel: 5.13.19-1-pve) pve-manager: 6.4-13 (running version: 6.4-13/9f411e79) pve-kernel-5.13: 7.1-4 pve-kernel-helper: 7.1-4 pve-kernel-5.4: 6.4-7 pve-kernel-5.13.19-1-pve: 5.13.19-3 pve-kernel-5.4.143-1-pve: 5.4.143-1 pve-kernel-4.15: 5.4-6 pve-kernel-4.15.18-18-pve: 4.15.18-44 pve-kernel-4.15.17-1-pve: 4.15.17-9
-
-
@meister-mopper in der Tat läuft das Upgrade nicht durch bei mir obwohl er sehr viele Updates findet.
Ist die sources.list korrekt?#deb http://ftp.debian.org/debian bullseye main contrib #deb http://ftp.debian.org/debian bullseye-updates main contrib # PVE pve-no-subscription repository provided by proxmox.com, # NOT recommended for production use deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription deb http://ftp.de.debian.org/debian bullseye main contrib deb http://ftp.de.debian.org/debian bullseye-updates main contrib # security updates deb http://security.debian.org bullseye-security main contrib #deb http://deb.debian.org/debian-security bullseye-security main
apt update:
root@proxmox:/# apt update Hit:1 http://download.proxmox.com/debian/pve bullseye InRelease Hit:2 http://security.debian.org bullseye-security InRelease Hit:3 http://download.proxmox.com/debian/pve buster InRelease Hit:4 http://ftp.de.debian.org/debian bullseye InRelease Hit:5 http://ftp.de.debian.org/debian bullseye-updates InRelease Reading package lists... Done Building dependency tree... Done Reading state information... Done 193 packages can be upgraded. Run 'apt list --upgradable' to see them. root@proxmox:/#
apt upgrade:
root@proxmox:/# apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages have been kept back: .............. 0 upgraded, 0 newly installed, 0 to remove and 193 not upgraded.
-
@lobomau
hast Du das nach der Anleitung gemacht ?