updates bei proxmox

[LucasKer]

Hi,
ich bin mir unsicher wie ich mit Updates umgehen soll oder welche Erfahrungen jemand schon gemacht hat.

Geh ich auf Updates bei den Knoten sind dort jetzt 64 items in debian und 17 items in proxmox. Kann ich im laufenden Betrieb mit etliche vms das Update bedenkenlos ausführen? Hat jemand schon schlechte erfahrungen gemacht? Weil die vms dürfen nicht ausfallen

 

[Abby2017]

Guten Morgen,
als erstes solltest du ein vernünftiges Backup deiner VMs haben, dann wäre ein evtl. Ausfall deines PVE schon mal nicht sehr kritisch.
Dann ist die Frage, ob du ein no-subscription oder eine Enterprice subscription hast.
Natürlich kann es immer zu Problemen führen, ich kann nur von meiner Ausstattung sagen, hatte ich noch "toi toi toi" noch keine Probleme nach einem Update.
Die Updates sollten schon aus Security Sicht regelmäßig durchgeführt werden ;-)

 

[UdoB]

Hat jemand schon schlechte erfahrungen gemacht?

Die einzige Überraschung, die bei mir in den letzten Jahren auftrat, war beim angeforderten Restart vom "watchdog-mux.service". Auf einigen Dell-Maschinen löst das bei mir ein "fencing" aus, also einen brutalen Neustart. Im billigen Homelab ist mir das noch nie passiert.

Aber in jedem Fall: Updates zu verzögern sehe ich nicht als akzeptabel an. Security-Updates lasse ich (teilweise) sogar von "unattended-upgrades" automatisch einspielen und um normale Updates kümmere ich mich mindestens mehrmals pro Woche.

Weil die vms dürfen nicht ausfallen

Für "mission critical" VMs sollte man einen Cluster haben. Dann kann man die Dienste vor einem potentiell problematischem Update einfach "live", also ohne jeglichen Ausfall, verschieben - entweder manuell oder (bei aktivem HA) einfach per ha-manager crm-command node-maintenance enable <node>. Das mache ich mittlerweile immer so.

Weiter gehende Redundanz ist vielschichtig und oft zu umfangreich, um sie "mal eben" aufzubauen: Stromversorgung, Nodes, Storage, Netzwerk, ...

Viel Erfolg!

 

[Johannes S]

Schon wegen Securityupdates: Regelmäßig updaten, ebenso regelmäßig ( am Besten automatisiert per Backup-Job) Backups machen. Restore der Backups am besten such von Zeit zu Zeit testen

 

[LucasKer]

Macht das nichts wenn die vms ständig verschoben werden hin und her ? Weil Kernel Updates kommen ja sehr häufig und da müsste ich ja gefühlt jeden Monat ein Reboot ausführen und die vms migrieren.

 

[Johannes S]

Macht das nichts wenn die vms ständig verschoben werden hin und her ? Weil Kernel Updates kommen ja sehr häufig und da müsste ich ja gefühlt jeden Monat ein Reboot ausführen und die vms migrieren.

Warum sollte das was ausmachen? Der Witz an der Live-Migration von vms ist ja, dass man das innerhalb der gleichen ProxmoxVE-Version und nach oben ( also z.B. von Version 8 auf Version 9 während man den Cluster upgraded ) unterbrechungsfrei machen kann, ohne dass die User der VM das mitkriegen. Wenn das nicht klappt, ist was faul, gehen sollte es und tut es normalerweise auch. Und was bitte soll die Alternative sein: Nicht upgrade und hoffen, dass sich schon kein Angreifer daran versuchen wird?

 

[TErxleben]

Macht das nichts wenn die vms ständig verschoben werden hin und her ? Weil Kernel Updates kommen ja sehr häufig und da müsste ich ja gefühlt jeden Monat ein Reboot ausführen und die vms migrieren.

Debian und das darauf basierende Proxmox-Universum ist glücklicherweise kein Windows. Man muss nur nach Kernelupdates neu starten. Die sind ja eher selten. Noch seltener sind Kernelupdates, die sicherheitsrelevante Änderungen enthalten. So kann man den nötigen Neustart entspannt in Zeiträume legen, die nicht weh tun. Zumal PVEs i.d.R. nicht öffentlich erreichbar sind.

 

[Johannes S]

Zumal PVEs i.d.R. nicht öffentlich erreichbar sind.

Die VMs aber teilweise schon und es gibt ja auch Sicherheitslücken, die dann einen Ausbruch daraus auf den Host erlauben. Allzu lange sollte man also auch nicht warten, am Besten plant man regelmäßiges Wartungsfenster ein, wo man dann die Knoten der Reihe nach hochzieht. Sicherheitsexperten wie Bruce Schneier empfehlen sämtliche Updates innerhalb von 24 Stunden einzuspielen, danach fangen die Bösewichte an die auszunutzen.

 

[TErxleben]

Die VMs aber teilweise schon und es gibt ja auch Sicherheitslücken, die dann einen Ausbruch daraus auf den Host erlauben. Allzu lange sollte man also auch nicht warten, am Besten plant man regelmäßiges Wartungsfenster ein, wo man dann die Knoten der Reihe nach hochzieht. Sicherheitsexperten wie Bruce Schneier empfehlen sämtliche Updates innerhalb von 24 Stunden einzuspielen, danach fangen die Bösewichte an die auszunutzen.

Komm auf den Teppich. Selbstverständlich gehören Sicherheitslücken immer zeitnah geflickt.
Aber die Dinger sind z.T. jahrelang unentdeckt vorhanden. Da braucht man sich nicht in die Hose machen, nur weil man nach Kernelupdates eines internen Server selbigen erst nach zwei Wochen neu startet.
Das ist die Kategorie: "Nur weil ich unter Verfolgungswahn leide, bedeutet das nicht, dass mich keiner verfolgt."

 

[Johannes S]

Dass in der gelebeten Praxis sich oft (aus diversen Gründen, seien es service-level-agreements, seien es politische Gründe (man lebt mit dem Risiko, weil Fachbereiche sich aufregen, wenn ihre dusseligen Bescheide mal einen Tag später rausgeschickt werden) nicht an die Empfehlung gehalten wird, stimmt, das macht diese gelebte Praxis aber trotzdem nicht gut Gerade weil man mit einen Cluster (oder meinetwegen zwei single-nodes und den Datacenter-Manager) ja problemlos vor den jeweiligen Upgrade die Workloads unterbrechungsfrei migrieren kann.

Und im Heimnetz (wie beim OP) muss man ja keine Rücksicht auf solche Patch-Verhinderungs-Maßnahmen wie "Change-Management" und "Vulnerability-Management" nehmen. Da kann man die Updates doch bequem auf Zeitpunkte verschieben, wo keiner die Dienste benutzt.