v0.7.1

Fix:

Die Variable steht jetzt vor dem Befehl ohne --, also sudo -n DEBIAN_FRONTEND=noninteractive apt-get …. Diese Form verstehen sowohl das klassische sudo als auch sudo-rs.
Falls sudo das Setzen der Variable trotzdem ablehnt, läuft das Update einmal ohne die Variable weiter, statt abzubrechen. Das passiert z. B. bei der eng gefassten sudoers-Regel aus der README (nur /usr/bin/apt-get, ohne SETENV).

v0.7.0

Hinzugefügt
Neu konfigurieren: Host/IP, Port, Name, Benutzer, Passwort, privater Schlüssel, Passphrase und sudo-Einstellungen lassen sich über „Neu konfigurieren“ ändern, ohne den Server zu löschen. Leere Passwort-/Schlüsselfelder behalten die gespeicherten Werte; die Verbindung wird vor dem Speichern getestet.
Erneute Authentifizierung: Wird die Anmeldung abgelehnt oder hat sich der Hostschlüssel geändert, startet Home Assistant einen Reauth-Dialog, statt den Server nur als nicht verfügbar zu zeigen.
Sicherheit
SSH-Hostschlüssel werden jetzt geprüft. Bisher wurde jeder Hostschlüssel akzeptiert, wodurch ein Angreifer im Netzwerk (Man-in-the-Middle) Passwort und Sudo-Passwort hätte abgreifen können. Der Schlüssel wird beim ersten Verbinden gespeichert (bestehende Einträge beim ersten Abruf nach dem Update); ein geänderter Schlüssel muss mit angezeigtem Fingerabdruck ausdrücklich bestätigt werden, bevor Zugangsdaten gesendet werden.
SSH-Verbindungen nutzen nur noch die in der Integration hinterlegten Zugangsdaten – keine Schlüssel, kein SSH-Agent und keine ~/.ssh/config des Home-Assistant-Hosts.
Container-IDs, Image-Namen, Compose-Dateien/-Verzeichnisse und Compose-Dienstnamen (stammen aus Labels auf dem Zielserver) werden mit shlex.quote maskiert, statt in einfache Anführungszeichen gesetzt bzw. unmaskiert übernommen zu werden.
Registry-Auth-Endpunkte (WWW-Authenticate: realm) werden nur noch über HTTPS angefragt.
Behoben
Die Prüfung, ob Compose-Dateien existieren, lief bei mehreren Dateien nur für die erste mit sudo.
Optionsänderungen laden den Eintrag weiterhin neu, reine Datenänderungen (z. B. das Speichern des Hostschlüssels) nicht mehr.

v0.6.0

Hinzugefügt

• Button Neu starten pro Server (button.<server>_reboot): startet den Server neu, ohne vorher Updates einzuspielen – zusätzlich zu Aktualisieren und neu starten.
• Button Neu starten pro Docker-Container (button.<container>_restart): führt docker restart aus. Gibt es für jeden laufenden Container, auch für solche ohne update-Entität (z. B. lokal gebaute Images); diese bekommen dafür jetzt ebenfalls ein eigenes Gerät.
• Reparatur-Hinweis „Neustart erforderlich“ ist jetzt direkt behebbar: „Beheben“ unter Einstellungen → System → Reparaturen startet den Server nach Bestätigung neu.
• Kernel-Updates werden als Neustart-Grund erkannt, wenn unter /boot ein neuerer Kernel (gleicher Variante, z. B. -pve) liegt als der laufende. Dadurch erscheint der Reparatur-Hinweis jetzt auch auf Proxmox VE, das bei Kernel-Updates keine /var/run/reboot-required anlegt. Neue Attribute running_kernel und newest_kernel am reboot_required-Sensor.

Geändert

• Nach einem Neustart (Button, Aktualisieren und neu starten oder Reparatur-Hinweis) wird der Server nach ca. drei Minuten erneut geprüft, statt sofort – die sofortige Abfrage lief bisher gegen den gerade herunterfahrenden Server.

Hinzugefügt

• Neustart-Überwachung: Nach jedem Neustart-Befehl wird nach ca. drei Minuten und danach minütlich (bis 15 Minuten) geprüft, ob der Server erreichbar ist, einen neuen Startzeitpunkt hat und – auf Proxmox VE – alle Autostart-Gäste laufen. Andernfalls gibt es eine Fehlermeldung mit Grund.
• binary_sensor.<server>_reachable (Konnektivität, bleibt auch bei ausgefallenem Server verfügbar) und sensor.<server>_last_boot (letzter Start).
• Proxmox VE: binary_sensor.<server>_autostart_guests_stopped meldet Gäste mit „Beim Booten starten“, die nicht laufen (per pvesh). Das geordnete Herunterfahren der Gäste beim Neustart übernimmt weiterhin Proxmox VE selbst (pve-guests).
• needrestart: sensor.<server>_services_to_restart und Button Dienste neu starten für Dienste mit veralteten Bibliotheken – ohne Neustart des Servers. Kritische Dienste (dbus, systemd-, getty, docker, containerd, pve-guests, lxc, qemu-server, pve-ha-) werden dabei ausgelassen.
• Docker: Schalter Läuft pro Container (docker start/stop, mit Attributen state/status) und Server-Button Ungenutzte Images aufräumen (docker image prune -f). Gestoppte Container mit Neustart-Richtlinie (oder aus Home Assistant gestoppte) bleiben jetzt im Inventar.
• Wartungsaktion server_updater.run_maintenance für zeitgesteuerte Automationen: Paket-Updates, optional Container-Updates, Images aufräumen, Dienste neu starten, Neustart nie/bei Bedarf/immer – für alle oder ausgewählte Server, mit optionaler Zusammenfassung als Antwort.
• Ereignisse & Benachrichtigungen: Jede Aktion feuert server_updater_event mit Ergebnis; Fehler erzeugen zusätzlich eine Benachrichtigung in Home Assistant, die bei späterem Erfolg wieder verschwindet (in den Optionen abschaltbar).
• Automatisierte Tests (tests/) mit simuliertem Server, laufen in der CI.

Geändert

• Der Container-Laufzustand wird bei jeder regulären Abfrage mit einem docker ps -a per SSH gelesen (bisher nur Registry-Abfragen).
• Update-Fehler über die Buttons werden nicht mehr nur geloggt, sondern auch gemeldet (Ereignis/Benachrichtigung). Ein zweiter Update-Vorgang während eines laufenden wird mit Fehlermeldung abgelehnt statt still ignoriert.

v0.4.1

Geändert

Scheitert apt-get dist-upgrade am Herunterladen einzelner Pakete (z. B. 404 Not Found, weil der Mirror gerade synchronisiert), werden die Paketlisten nach 30 s erneut und ohne HTTP-Cache geladen und das Upgrade einmal wiederholt. Da apt bei fehlgeschlagenem Download nichts installiert, ist das gefahrlos. Scheitert auch der zweite Versuch, gibt es eine verständliche Fehlermeldung statt der reinen apt-Ausgabe.

v0.4.0

Hinzugefügt

• update-Entität „Systempakete“ pro Server: ausstehende Paket-Updates erscheinen unter Einstellungen → Updates. Versionshinweise listen alle Pakete (alt → neu); „Installieren“ führt apt-get dist-upgrade aus.
• Reparatur-Hinweis „Neustart erforderlich“ unter Einstellungen → System → Reparaturen.

Entfernt

• binary_sensor._updates_available (ersetzt durch die Systempakete-Entität; Registry-Eintrag wird automatisch aufgeräumt).

v0.3.1

Behoben

Installieren-Button erschien nie: Die com.docker.compose.*-Labels wurden aus den Image-Labels statt aus den Container-Labels gelesen, wodurch kein Compose-Container als installierbar erkannt wurde. Jetzt werden Image- und Container-Labels zusammengeführt.
Doppelte Container-Entitäten und -Geräte (update._2, _3, …): Entitäten waren an die Container-ID gebunden, die sich bei jedem Neuerstellen ändert. Sie sind jetzt an den Containernamen gebunden; verwaiste Entitäten/Geräte (auch aus älteren Versionen) werden nach jedem erfolgreichen Scan entfernt, bevor neue angelegt werden.
Für Container, deren Update-Stand nicht ermittelbar ist (z. B. lokal gebaute Images), wurde entgegen der Dokumentation trotzdem eine dauerhaft nicht verfügbare Entität angelegt. Entitäten entstehen jetzt erst, sobald der Abgleich mit der Registry einmal gelungen ist.
Geändert

Abhängigkeit asyncssh nicht mehr exakt auf 2.23.1 fixiert (>=2.23.1), da Home Assistant inzwischen selbst 2.24.0 mitbringt und der exakte Pin damit kollidiert (hassfest-Fehler).
update-Entitäten zeigen während einer laufenden Installation den Fortschrittszustand (in_progress) an.

0.3.0

Was neu ist: update-Entitäten für Docker-Compose-verwaltete Container bekommen jetzt einen echten Installieren-Button.

Erkennung läuft automatisch mit über die Labels, die Docker Compose v2 selbst auf jedem Container hinterlegt (com.docker.compose.service, com.docker.compose.project.config_files) — die habe ich schon bei der Inventarisierung eingesammelt, jetzt genutzt.
Vor jedem Rescan wird per SSH geprüft (test -f), ob die referenzierte Compose-Datei am hinterlegten Pfad noch existiert. Nur dann bekommt die Entität den Installieren-Button (UpdateEntityFeature.INSTALL).
Klick auf Installieren führt docker compose -f <config_files> [--project-directory <working_dir>] pull und danach ... up -d aus — für genau den einen Service, mit der originalen Compose-Datei als Quelle der Wahrheit für Volumes/Netzwerke/Env.
Nach erfolgreichem Update wird automatisch neu inventarisiert, damit der neue Digest sofort sichtbar ist.
Fehler beim Pull/Up landen als lesbare Fehlermeldung im Home-Assistant-Log und werden dem Frontend als HomeAssistantError gemeldet (Standard-Fehleranzeige im Update-Dialog).
Container ohne Compose-Labels oder mit verschwundener Compose-Datei bleiben unverändert rein informativ.

0.2.0

Neuer Button „Container neu inventarisieren" pro Server: läuft per SSH docker ps + docker inspect, ermittelt laufende Container und deren Image-Referenz/Digest. Läuft nur einmal beim Start der Integration und auf Knopfdruck
Für jeden gefundenen Container prüft Home Assistant bei jeder regulären Abfrage direkt gegen die Registry (Docker Hub, GHCR, oder jede andere Registry mit anonymem Docker-Registry-v2-Zugriff) per HTTP, ob sich der Manifest-Digest des laufenden Tags geändert hat — inklusive korrekter Behandlung von Multi-Arch-Images (Manifest-Listen).
Nur wenn dieser Abgleich zuverlässig gelingt, entsteht eine update.-Entität. Private Registries, auf einen Digest fixierte Images oder lokal gebaute Images ohne Registry-Herkunft werden zwar inventarisiert, bekommen aber bewusst keine Entität. Verschwindet ein Container beim nächsten Scan, wird seine Entität automatisch entfernt.
release_url wird automatisch aus dem OCI-Label org.opencontainers.image.source gefüllt, falls vorhanden (bei GitHub-Actions-Builds meist der Fall).

0.1.2

Gefundene und behobene Bugs (Commit 4d5f499, Version 0.1.2):

Port-Bug (Int or String expected): Der NumberSelector liefert vom HA-Frontend eine Fließkommazahl statt eines Integers, asyncssh verweigert das. Port wird jetzt im Schema per vol.Coerce(int) und zusätzlich defensiv an der Verbindungsstelle als int erzwungen.
Private-Key-Bug (Invalid private key): Copy-Paste aus dem Browser-Textfeld führt oft zu CRLF-Zeilenumbrüchen oder Leerzeichen am Zeilenende — beides bringt den PEM-Parser zu Fall. Der Schlüsseltext wird jetzt vor dem Parsen normalisiert (Zeilenenden, Whitespace).

UX-Verbesserungen (deine drei Punkte):

Config Flow ist jetzt eine einzige Seite statt vier Schritten ohne Zurück-Button — Name, Host, Port, User, Passwort, Key, Passphrase, Sudo alles zusammen.
Bei fehlgeschlagenem Verbindungstest bleiben alle eingegebenen Werte erhalten, du korrigierst nur das kaputte Feld und sendest erneut ab (kein Neuanfang mehr nötig).
Fehlermeldung zeigt jetzt die konkrete Ursache an (z. B. „Verbindung zu mserver.eth0.biz fehlgeschlagen: Connection refused") statt eines generischen „cannot_connect".
Beschreibungstext im Formular erklärt jetzt Schritt für Schritt, wie der private Schlüssel einzufügen ist (inkl. cat ~/.ssh/id_ed25519-Befehl, BEGIN/END-Zeilen, .pub vs. privat, authorized_keys-Hinweis).

0.1.1

Behoben

• Config Flow: Der Verbindungstest schlug beim Hinzufügen eines Servers
  mit „Nicht verbunden" fehl, unabhängig von den Zugangsdaten, weil
  die SSH-Verbindung vor dem Test nicht tatsächlich aufgebaut wurde.