Commit Graph
15 Commits
Author SHA1 Message Date
HitonabiandClaude Opus 5.5 0df593c05a homelab: nach dem Hochfahren des Hosts schon nach einer Minute wieder berichten
Der erste Bericht nach dem Neustart vom 25.09. kam 34 s nach dem Hochfahren –
Proxmox kannte die Gäste noch nicht („unknown“), und zehn Minuten lang zeigte die
Oberfläche jeden Gast als unbekannt. Enthält ein Bericht solche Gäste, folgt der
nächste nach 60 s. Der Grund steht jetzt auf Deutsch da.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-25 12:39:54 +02:00
HitonabiandClaude Opus 5.5 7a456c8efa homelab: alte Kernel per Knopf entfernen; Systemplatte des Proxmox-Hosts im Blick
User-Wunsch 25.09.: Auf dem Host lagen 25 Kernel (~23 GB), 20 davon hält apt für
entbehrlich (19,7 GB).
- Ausführer: host.kernel_alt/kernel_bleiben aus apt-get -s autoremove (nur
  Kernel, nie laufender, nächster oder festgepinnter), host.systemplatte;
  neue Aktion kernel_aufraeumen bestimmt die Liste selbst und purgt.
- Homelab-Teil: Lauf „kernel“ (Ergebnis aufgeraeumt), POST
  /api/homelab/ziele/pve/kernel-aufraeumen, Vorschlag mit Knopf, Wächter für die
  Systemplatte (80/90 %).
- Oberfläche: Kachel Systemplatte, Knopf „Alte Kernel entfernen“ mit Rückfrage.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-25 12:16:14 +02:00
HitonabiandClaude Opus 5.5 17d4ee3ea8 homelab: Images ohne Container sind kein Docker-Update; neuer Kernel heißt Neustart
Nach dem ersten echten „Alle aktualisieren“ (25.09., 8 Schritte grün):
- 9 veraltete Images, die kein Container benutzt (Basis-Images für Builds/CI),
  blieben für immer „neu“ – Arcanes Updater tauscht nur Container. Sie zählen
  jetzt nicht mehr, der Grund nennt sie als Aufräum-Hinweis.
- Proxmox legt bei Kernel-Updates kein /var/run/reboot-required an: 7.0.14-19
  war installiert, 7.0.14-12 lief, kein Neustart-Knopf. Der Ausführer vergleicht
  jetzt den neuesten installierten (oder festgepinnten) Kernel mit dem laufenden.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-25 11:46:26 +02:00
HitonabiandClaude Opus 5.5 903fbbfbb9 homelab: Speicherpool, NAS und Sicherungen überwachen – mit Empfehlungen, was Platz bringt
User-Wunsch 25.09.: Speicherpool im Wächter (gelb ab 80 %, rot bei 10 % frei)
samt Empfehlungen, dazu das NAS (Backup-Ziel, per NFS auf dem Proxmox-Host).
- Ausführer: Thin-Pools mit echter Belegung je Volume (lvs), ungenutzte und
  verwaiste Platten, VM-Belegung über den Gast-Agenten, Discard je VM,
  Netzlaufwerke (df mit Zeitlimit, hängender harter NFS-Mount hält nichts auf),
  Sicherungsaufträge und jüngste Sicherung je Gast.
- Homelab-Teil: services/homelab/speicher.py (Auswertung, Empfehlungen,
  Wächter pruefe_speicher, NAS-Erreichbarkeit per TCP), GET /api/homelab/speicher;
  Gast-Plattenwächter nennt jetzt auch VMs richtig.
- Oberfläche: Karte „Speicher und Sicherungen“ im Homelab-Cockpit.
- deploy.sh und ausfuehrer-einrichten.sh warten, solange im Homelab ein Update
  oder „Alle aktualisieren“ läuft (der Neustart bräche den Lauf ab).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-25 11:15:06 +02:00
HitonabiandClaude Opus 5.5 704c21d839 monitoring: Messwerte mit Verlauf fuer KI-Box und Homelab
- kern/messreihen.py: Minutenwerte als JSON-Zeilen je Quelle und Tag unter
  <Datenordner>/mc2-messwerte/, Anhaengen unter flock, Aufraeumen nach 8 Tagen,
  Lesen fuer 1h/24h/7d (60 s, 5-min- und 30-min-Mittel), Luecken bleiben null,
  kaputte Zeilen werden uebersprungen, Zaehler-Raten ohne Spruenge
- KI-Box: Taktgeber im Steward (services/messwerte.py) schreibt jede Minute
  cpu, ram, gpu, Temperaturen, platte, Netz in Bytes/s und Tokens pro Minute;
  GET /api/messwerte (nur Rolle box)
- Homelab: Der Ausfuehrer schickt jede Minute in einem eigenen Faden Host-Werte
  aus /proc und die Gaeste aus einem pvesh-Aufruf an
  POST /api/homelab/ausfuehrer/messwerte; services/homelab/messwerte.py rechnet
  die Zaehler in Bytes/s um (Neustarts und Spruenge ergeben null),
  GET /api/homelab/messwerte liefert Host und Gaeste wie im Inventar
- Waechter (homelab): gelb, wenn der Host 10 Minuten ueber 95 % RAM oder 90 °C liegt
- Aufraeumen der Modell-Platte bietet mc2-messwerte nie zum Loeschen an

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 22:41:53 +02:00
HitonabiandClaude Opus 5.5 c08a144006 homelab: Wächter und Geräteliste sehen volle Gastplatten (AdGuard stand bei 100 %)
Der Ausfuehrer schickt die Belegung der rootfs laufender Container mit; ab 85 % gelb, ab 95 % rot, in der
Geraeteliste als eigene Spalte und auf der Lampe des Geraets. Anlass: AdGuard (2 GB) war voll, das
Abfrageprotokoll schrieb nicht mehr und die Paketsuche scheiterte, ohne dass es eine Anzeige sagte.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 21:00:44 +02:00
Hitonabi 954a5e74bb Merge branch 'wartung/einstellungen-stand-altreste' into wartung/restarbeiten
# Conflicts:
#	deploy/deploy.sh
2026-09-24 20:47:53 +02:00
HitonabiandClaude Opus 5.5 3d8df1c6fd einstellungen: Zeitfenster, Radar-Schalter, Telegram-Test, Software-Stand und Altreste
Einstellungen, die etwas einstellen (services/einstellungen.py, /api/einstellungen):
- Update-Zeitfenster: Wochentag und Uhrzeit des Update-Laufs als Drop-in
  mc2-autoupdate.timer.d/zeitfenster.conf. Gegen die Nachhol-Falle von
  Persistent=true (24.09.): Timer vor dem daemon-reload stoppen, Stempel auf
  jetzt, dann starten. Bei Fehler zurück auf das alte Drop-in. Während eines
  Update-Laufs abgelehnt.
- Neustart nur im eingestellten Fenster (deploy/wartungsfenster.sh, drei
  Stunden ab der vollen Stunde des Beginns; Standard So 04:00-06:59).
- Radar an/aus: disable --now bzw. enable + Stempel + start (kein Nachholen).
  deploy.sh respektiert den Schalter und startet den Radar-Timer nur mit
  Stempel; das Zeitfenster-Drop-in fasst er nie an.
- Wächter: schläft der Timer eines Timer-Dienstes, ist ein alter Fehlschlag
  kein Befund mehr (der Dienst selbst ist static und schläft nie).
- Telegram-Test je Instanz (/api/einstellungen/telegram-test und
  /api/homelab/einstellungen/telegram-test) über notify.sh -d; Ergebnis und
  Grund aus dem Melde-Log. notify.sh schreibt jetzt auch den Grund des
  gescheiterten Zweitwegs in den FALLBACK-Eintrag.
- Einstellungsdatei mc2-einstellungen.json im Datenordner.

Software-Stand: deploy.sh und homelab/ausrollen.sh schreiben nach dem
Umschalten mc2-stand.json (deploy/stand-schreiben.py); /api/instanz liefert
den Stand, die Einstellungen zeigen beide Instanzen und warnen bei Abweichung.
Ohne Datei aus git, sonst unbekannt.

Aufräumen: Altreste neben dem Betrieb aus einer festen, auf der Box geprüften
Liste (Größe, Hinweis, nur was da und nicht in Gebrauch ist). Löschen nur per
Kennung und Klick mit Rückfrage; Worktrees mit git worktree prune, Alt-Units
mit daemon-reload, /opt/llamacpp notfalls mit sudo -n.

Tests: pytest mit einem systemd-Abbild samt Nachhol-Regel, echtem notify.sh
(Ersatz-Hermes, Tmp-Zugang, lokale Bot-API), Shell-Funktionen des
Wartungsfensters und von deploy.sh; vitest für die Rückfragen der Schublade.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 20:37:30 +02:00
HitonabiandClaude Opus 5.5 f2733f44fe homelab: Wartezeit nach Skriptaenderung, PBS mit Sicherung statt Snapshot, woechentliches Suchen
- karenz.py: ct/<app>.sh juenger als MC_HOMELAB_KARENZ_H (Standard 48 h) -> Baustein "neu" ohne Knopf,
  updates.starten lehnt mit demselben Satz ab (Berliner Zeit). GitHub stumm -> nicht blockieren, die
  Rueckfrage sagt es.
- Ausfuehrer: neue Aktionen sichern, sicherung_zurueck, sicherung_loeschen. vzdump auf den ersten lokalen
  Speicher mit Inhalt backup (oder sicherung_speicher aus /etc/mc2-ausfuehrer.json), nie auf pbs; vorher
  Platz pruefen (frei > belegt x 1,2); Notiz mc2-sicherung, nur solche werden zurueckgespielt/geloescht;
  Rueckweg: stoppen, pct restore --force auf den bisherigen rootfs-Speicher, starten. Bericht mit
  host.sicherung, sicherung_moeglich/_grund, eigenen Sicherungen und nur_lesen. Unerwartete Fehler werden
  beantwortet statt verschluckt; vzdump/restore beim Zeitlimit erst SIGTERM.
- updates.py: Sicherung, wo kein Snapshot geht; bei Rot zurueckspielen, nach Gruen aeltere Sicherungen
  weg. Scheitert Snapshot oder Sicherung, beginnt das Update nicht (nicht dringend gemeldet).
- pflege.py: "suchen" fuer Gaeste mit Paketlisten aelter als 7 Tage, nachts 02-05 Uhr (sonst nachholen),
  einmal je Gast und Tag, nie neben einem Update oder offenen Auftrag; gelber Waechter-Hinweis, wenn es
  zweimal hintereinander scheitert. Eine Registrierungszeile in waechter.py.
- kanal.py: Auftragsliste unter flock, weil jetzt auch der Steward Auftraege anlegt.
- inventar.py: Rueckweg und Rueckfrage fuer die Sicherung; Gaeste mitten im Update-Lauf nicht in der
  Webpruefung des Waechters (sonst zweiter Alarm beim Zurueckspielen).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 20:22:39 +02:00
HitonabiandClaude Opus 5.5 4a2b1723f4 homelab: Ausfuehrer erkennt die App auch am neuen /usr/bin/update (SCRIPT_SLUG), das Community-Scripts nach jedem Update schreibt
Nach dem ersten echten Update (Gitea 1.27.2 -> 1.27.3) stand Gitea nur noch als "gitea" ohne App-Baustein da.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 19:29:55 +02:00
HitonabiandClaude Opus 5.5 528198de60 homelab: Update-Weg je App (Knopf nur, wo das Community-Script die App wirklich aktualisiert), Version von PVE Scripts Local aus der App selbst
Nachgelesen in ct/<app>.sh: AdGuard und PVE Scripts Local verweisen auf ihren eingebauten Updater,
Gitea/NetBird/NPMplus aktualisieren wirklich, PBS ueber die Pakete. /root/.proxmoxve-local stand noch
auf 0.5.8, die App selbst schon auf der neuesten Veroeffentlichung (v1.2.1, untagged).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 19:20:04 +02:00
HitonabiandClaude Opus 5.5 83c33584e4 letzte Kanten: Hermes-Abruf 60 s statt 25 s, kein Pfeil auf dieselbe Version, Homelab-Container mit Sicherheitsupdates
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 19:05:56 +02:00
HitonabiandClaude Opus 5.5 39320b446d homelab: eigener Container nicht in der Geraeteliste, Geheimnis beim Einrichten richtig anstossen, Deploy zieht den Homelab-Teil mit
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 19:01:20 +02:00
HitonabiandClaude Opus 5.5 b452b5e672 ausfuehrer: Nur-Lesen-Modus (nur Bericht, jeder andere Auftrag abgelehnt), wahlweise bei der Einrichtung
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 18:52:36 +02:00
HitonabiandClaude Opus 5.5 5e9227c4a3 phase3+4: Homelab-Teil (Ausfuehrer, Ziele, Jetzt updaten mit Rueckweg) und Seite Homelab fuer alle Geraete
- deploy/homelab/ausfuehrer.py: laeuft als root auf dem Proxmox-Host, holt Auftraege beim Homelab-Teil
  ab (Pull, kein offener Port), feste Aktionsliste, prueft Etiketten selbst; Bericht gegen den echten
  Host erprobt (nur lesend). Kein Proxmox-Schluessel im Container noetig.
- services/homelab: Kanal mit gemeinsamem Geheimnis, App-Katalog, Inventar -> Ziele im gemeinsamen
  Modell (GitHub-Versionen, Webpruefung, alte Paketlisten = unklar), Jetzt updaten: Snapshot ->
  Update -> Pruefung -> bei Rot zurueck + dringende Meldung
- Waechter in der Rolle homelab: Ausfuehrer schweigt, Gaeste antworten nicht
- kern/github.py fuer beide Rollen (auch untagged Releases mit Version im Namen)
- Oberflaeche: Seite Homelab zeigt alle Geraete als Karten (KI-Box ueber /api/ziele, Homelab ueber
  /api/homelab/ziele) mit Stand, Rueckweg und Knopf samt Rueckfrage
- Einrichtung als Skripte (container-anlegen, ausrollen, ausfuehrer-einrichten, box-partner) — noch
  nicht ausgefuehrt, jeder Schritt braucht das User-OK
- frontend-bauen-box.sh: Frontend-Pruefung und Build auf der Box, wenn der PC keinen Speicher hat

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 18:39:59 +02:00