Update Strategie

[Scplayer]

Moin Allerseits,

Wie ist eure Strategie bzgl. Updates ?.

- Führt Ihr die Updates manuell aus oder automatisch ?.
- Sofern Automatisch mit welcher Methode ?.

Momentan hab ich dafür bei der Ubuntu VM unattended-upgrades eingerichtet und beim Proxmox Host den Timer eingerichtet. Aber ich frag ich ob es da eine einfachere Methode gibts die ich beim Proxmox Host und allen VMs, Containern anwenden kann.

LG Jan

 

[UdoB]

Wie ist eure Strategie bzgl. Updates ?.

Das wichtigste scheint mir "häufig!" zu sein, nicht auf die lange Bank schieben. Bei mir bedeutet das "täglich!" Das ist die Regel, aber sie hat durchaus Ausnahmen. Nicht alle Systeme kann mal eben tagsüber mit einem neuen Kernel neu starten und nach Freitag Mittag kommt im Job direkt Montag Morgen.

• Security-Updates: am besten per unattended-upgrades
• Normale Updates auf unwichtigen Maschinen: möglichst vollautomatisch per unattended-upgrades
• Normale Updates auf wichtigen Maschinen: vollautomatisch vorbereiten lassen plus Alarm per Monitoring

Im Homelab macht natürlich jeder seine eigenen Regeln. Solange keinerlei Dienste von außen erreichbar sind, kann man das ja auch entspannt handhaben...

 

[ThoSo]

Patchdays einrichten und dann gezielt manuell aktualisieren.
Hat auch den Vorteil, wenn mal etwas Probleme macht, man nicht gleich bei den ersten damit ist. Aber nicht auf die lange Bank schieben. Von automatisch halte ich nichts, da ich dann plötzlich ein Problem haben kann, den ein Patch zuvor verursacht hat. So kann ich auch vor dem Einspielen ggf. noch ein Backup oder snapshot gezielt laufen lassen.

 

[Scplayer]

Moin Allerseits,

Ok verstehe gebe es aber nicht die möglichkeit das einheitlich für Proxmox und allen Linux basierten VMs / LXC basierten Container per Skript zu machen folgender maßen.

Es wird ein Python Skript beim Proxmox Host, VMs und LXC Container um 5:00 Uhr täglich durchgeführt. Sofern es Updates zu installieren gibt erhalte ich über mein selbst gehosteten Gotify Server eine benachrichtigungen.

Ist da so möglich ?.

LG Jan

 

[ivenae]

Auf dem Host via crontab jeden ersten Donnerstag im Monat

#!/bin/bash
apt update
zfs destroy rpool/ROOT/pve-1@update
zfs snapshot rpool/ROOT/pve-1@update
apt -yf dist-upgrade
apt-get -y --purge autoremove
apt-get autoclean
/usr/sbin/qm agent 100 fstrim
/usr/sbin/qm shutdown 100
shutdown -r now


Cron Eintrag:
55 03 * * 4 [ $(date +\%d) -le 07 ] && PATH="$PATH:/usr/sbin:/usr/local/bin/" /root/update.sh


Auf den LXC Containern oder VMs typischerweise unattended upgrades ohne Neustart (werden ja mit dem Host neu gestartet).
Warum kein unattended Upgrade auf dem Proxmox? Weil ich nicht weiß, wie es sich mit den Proxmox eigenen Quellen verhält.

Läuft seit sehr langer Zeit ohne Probleme.
Gab mal Probleme mit dem nächsten Neustart bei einiger Hardware, als Proxmox damals die Standardeinstellungen der IOMMU verändert hatte.
Seit dem habe ich vor der shutdown Zeile ein 'sleep 1d' auf allen Maschinen, außer den jeweils nächstgelegenen ersten einer jeden Hardwarecharge. Dann kommt wenigstens nur eine pro Hardwaretyp nicht mehr hoch, und das ist die, die in der Nähe sind.

Verbesserungen gerne. Kritik unerwünscht: Wer heilt hat recht.

Zum Thema: manuelle Patchday: Meine Erfahrung ist, dass Menschen mehr Fehler machen als Maschinen. Ich würde fast sagen, die Fehlerquote bei automatischen Updates ist geringer als bei manuellen.

 

[Johannes S]

s wird ein Python Skript beim Proxmox Host, VMs und LXC Container um 5:00 Uhr täglich durchgeführt. Sofern es Updates zu installieren gibt erhalte ich über mein selbst gehosteten Gotify Server eine benachrichtigungen.

Automatische Updates kann man bei Debian und seinen Varianten (wie ubuntu) wie von Udo erläutert mit unattended-upgrades einrichten. Standardmäßig alamiert das über mail, aber mittels mailrise kann man diese Mails auch an andere Benachrichtigugnsdienste wie gotify weiterleiten.

Für RedHat und SuSe gibt es mit Sicherheit einen ähnlichen Mechanismus, da weiß ich nur nicht, wie man den einrichtet

Bei bleeding-edge-Distributionen wie Arch würde ich dagegen davon die Finger lassen.

Wenn du zusätzlich die Möglichkeit haben willst bei deinen VMS und Container die Updates von Hand zu triggern, solltest du dir mal ansible anschauen. Das ist zwar ein ziemliches rabbit-hole, aber damit kannst du jederzeit nicht nur die Updates, sondern auch andere Taks zur Serverpflege anstoßen, ohne jeden Befehl einzeln eintippen zu müssen.

Zum Thema: manuelle Patchday: Meine Erfahrung ist, dass Menschen mehr Fehler machen als Maschinen. Ich würde fast sagen, die Fehlerquote bei automatischen Updates ist geringer als bei manuellen.

Dieses. Und man kann ja auch einen Backupjob so timen, dass der immer vor dem Cronjob losrennt. Oder im cronjob script das vorherige Backup antriggern. Wenn man ganz paranoid ist, auch gerne noch zusätzlich einen Snapshot vorher, den man dann beim nächsten Durchlauf des cronjobs wieder wegschmeißt Man sollte den bei LVM nur nicht zu lange aufbewahren, weil das dort auf Kosten der Performance geht. Bei ZFS ist das weniger problematisch, frisst aber irgendwann auch einfach unnötig Speicherplatz.

 

[Scplayer]

Moin Johannes S,

Ist Ansible nicht nur für Red Hat Linux oder deren derivate wie CentOS verfügbar ?

Oder lässt sich das auch über den Debian / Ubuntu Repos beziehen.

Also zusammengefasst sollte ich mir schon eine Seperate Lösung jeweils für Proxmox und Ubuntu / Debian Systemen überlegen beziehungsweise bin bei letzteren mit unattended-upgrades schon gut ausgestattet ?.

LG Jan

 

[Scplayer]

Auf dem Host via crontab jeden ersten Donnerstag im Monat

#!/bin/bash
apt update
zfs destroy rpool/ROOT/pve-1@update
zfs snapshot rpool/ROOT/pve-1@update
apt -yf dist-upgrade
apt-get -y --purge autoremove
apt-get autoclean
/usr/sbin/qm agent 100 fstrim
/usr/sbin/qm shutdown 100
shutdown -r now


Cron Eintrag:
55 03 * * 4 [ $(date +\%d) -le 07 ] && PATH="$PATH:/usr/sbin:/usr/local/bin/" /root/update.sh


Auf den LXC Containern oder VMs typischerweise unattended upgrades ohne Neustart (werden ja mit dem Host neu gestartet).
Warum kein unattended Upgrade auf dem Proxmox? Weil ich nicht weiß, wie es sich mit den Proxmox eigenen Quellen verhält.

Läuft seit sehr langer Zeit ohne Probleme.
Gab mal Probleme mit dem nächsten Neustart bei einiger Hardware, als Proxmox damals die Standardeinstellungen der IOMMU verändert hatte.
Seit dem habe ich vor der shutdown Zeile ein 'sleep 1d' auf allen Maschinen, außer den jeweils nächstgelegenen ersten einer jeden Hardwarecharge. Dann kommt wenigstens nur eine pro Hardwaretyp nicht mehr hoch, und das ist die, die in der Nähe sind.

Verbesserungen gerne. Kritik unerwünscht: Wer heilt hat recht.

Zum Thema: manuelle Patchday: Meine Erfahrung ist, dass Menschen mehr Fehler machen als Maschinen. Ich würde fast sagen, die Fehlerquote bei automatischen Updates ist geringer als bei manuellen.

Wofür sind denn diese Befehle in Skript:

zfs destroy rpool/ROOT/pve-1@update
zfs snapshot rpool/ROOT/pve-1@update
/usr/sbin/qm agent 100 fstrim
/usr/sbin/qm shutdown 100

Lässt sich das bei erfolgreichen ausführen als Benachrichtigung in Gotify setzen ?.

Bezüglich den Backup Jobs von Proxmox werde ich schon per Gotify benachrichtigt, daher ist das in der HInsicht unter Notification Targets schon eingebunden. Betreibe aber auf Proxmox oder in mein Heimnetzwerk kein Mailserver oder eine Domäne.

LG Jan

 

[ivenae]

Ich erstelle mir einen ZFS Snapshot, bevor ich ein Update mache.
Ich nehme aber immer den gleichen Namen für den Snapshot (ich benötige den nur, falls Proxmox nach dem Update nicht wieder hochfährt), also lösche ich erst den alten und erstelle dann den neuen.

"qm agent 100 fstrim" startet ein fstrim (Leeren freier SSD Blöcke) innerhalb der VM. In dem Fall list es eine Starface VM, die das selbst nicht auf die Kette bekommt. Normalerweise lasse ich das die VMs selbst erledigen und triggere das nicht von außen.

"qm shutdown 100" fährt die Starface VM runter, weil ja nach dem Update ein Neustart erfolgt.

Das war als Idee gedacht, nicht als 1:1 Übernahmevorlage. ;-)

 

[Johannes S]

Lässt sich das bei erfolgreichen ausführen als Benachrichtigung in Gotify setzen ?.

Bezüglich den Backup Jobs von Proxmox werde ich schon per Gotify benachrichtigt, daher ist das in der HInsicht unter Notification Targets schon eingebunden. Betreibe aber auf Proxmox oder in mein Heimnetzwerk kein Mailserver oder eine Domäne.

Auf jeden pve läuft auch ein postfix, aber das ist gar nicht der Punkt
Mailrise arbeitet als smtp-Gateway, dass Nachrichten per smtp entgegen nimmt und dann als notifications weiterleitet. Dass kann man sich also auch in einer VM oder einen LXC-Containern installieren, dann auf dem PVE dessen IP als SMTP-Server eintragen und dann können auch Systemmails so nach gotify geleitet werden:
https://github.com/YoRyan/mailrise

Ist Ansible nicht nur für Red Hat Linux oder deren derivate wie CentOS verfügbar ?

Nö: https://docs.ansible.com/projects/ansible/latest/installation_guide/installation_distros.html beschreibt das auch für SLES, Debian, Ubuntu, Arch und Windows. Für apt gibt es ein Modul, was Teil von ansible-core ist: https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/apt_module.html

Was korrekt ist, dass ansible vor allen bei Redhat entwickelt wird und darum teilweise bestimmte Sachen nur dort gehen. So kann man bei dem Modul für dnf auch die zu verwendenden Repositories per Parameter einschränken, das Feature fehlt beim apt-Modul. Im Homelab ist das aber ehrlich gesagt nicht so wirklich relevant, sofern man nur oft genug Backups der VM/LXC macht, dass man bei einen in die Hose gegangenen Update wieder zurückspringen kann. Im Unternehmenseinsatz würde ich mit aptly oder pulp einen eigenen apt-mirror aufbauen, sodass ich eine Art zeitversetztes Update implementieren kann ( test-> staging->production analog zu https://blog.uberspace.de/2024/07/ein-mirror-fuer-u8/ für Arch)