Kalli Family

Kalli's way north

Drei Maschinen und ein Laptop, der schläft

Monatelang hatte ein guter Teil meiner Pannen eine einzige Ursache: Ein Job brauchte eine Maschine, die schlief. Wie ich geklärt habe, was wo läuft, und warum mein Code nur einen Ursprung hat.

Am Abend des 26. Juli und am Morgen danach haben Claude und ich geändert, wie meine Server mir Probleme melden. Der Commit nennt den Grund: „WhatsApp alerts depended on the Mac … bridge, … so they silently died whenever the laptop slept.“ Seit Ende Juni liefen die kritischen Warnmeldungen meines Heimservers über ein Brückenprogramm auf meinem Laptop Falcon*; so hatten Claude und ich die Meldungen gebaut. Sie kamen an, wenn ich mit offenem Deckel am Schreibtisch saß – also dann, wenn ich sie am wenigsten brauche.

Den Laptop aus allem herauszunehmen, was funktionieren muss, dauerte bis Oktober.

Eine Meldung, zwei Wege: bis zum 27. Juli über den Laptop, seitdem direkt vom Server.
Eine Meldung, zwei Wege: bis zum 27. Juli über den Laptop, seitdem direkt vom Server.

Ein Desktop, der wach sein musste

Im März lief mein System auf einem VPS in Helsinki, Bespin*, und meinem alten Windows-Desktop, Dagobah*, der die Grafikkarte für ein lokales Modell hatte. ADR-001 (Beitrag 2) sah die Journal-Routinen auf dem VPS vor, doch sie liefen bis zum 17. Mai über die Aufgabenplanung des Desktops. Dieselbe Notiz zeigt den Desktop als Maschine, die um 07:00 für die Arbeit des lokalen Modells „aufwacht“ („Desktop wakes“); war er aus, wartete diese Arbeit. Ab dem 22. Mai war ein neuer Laptop mein Hauptrechner; meine Juni-Notizen nennen den Desktop „powered off most of the time“.

Ein Heimserver in vier Tagen

Am 18. Juni bekam der Desktop eine zweite Aufgabe. Ich wollte meine Fotos von Google wegholen und ein lokales Sprachmodell betreiben; für beides war seine Grafikkarte das Beste, was ich hatte. Der Plan von diesem Tag zog eine Linie, die bis heute gilt: der VPS öffentlich und immer an, die Kiste zu Hause privat und für das Schwere. Am 22. Juni löschte ich, Schritt für Schritt mit Claude, Windows; die Maschine kam als Yavin* zurück, ein Linux-Server mit Docker und Immich für die Fotos. Am Tag darauf lief dort das lokale Modell, die Mail-Anreicherung nutzte es, und die Dokumentverarbeitung zog um. Dagobah* und Yavin* sind dieselbe Kiste: früher meistens aus, heute immer an.

Abgestellt, wo niemand hinkam

Am 24. Juni bauten Claude und ich eine Finanzplanungs-App mit ihrem Kern auf Yavin*. Am nächsten Tag erreichten meine Cloud-Sitzungen den Server nicht: Der Connector, über den ich ausrolle, zeigte auf eine Adresse in meinem Heimnetz. Noch am selben Tag zog die App auf Bespin* um, und eine Entscheidungsnotiz legte fest: standardmäßig der VPS, der Heimserver nur für das, was seinen Speicher oder lokale KI braucht. Im August kam die andere Hälfte: Was ohne mich läuft und keinen Bildschirm braucht, kommt auf Yavin*, damit der Laptop schlafen kann.

Wo die Arbeit lief: März, Mai, Juni, und die geplanten Jobs je Maschine am 10. Oktober.
Wo die Arbeit lief: März, Mai, Juni, und die geplanten Jobs je Maschine am 10. Oktober.

Per curl installiert

Am 26. Juni prüfte Claude den neuen Server und fand zwei Scan-Dienste, die denselben Ordner beobachteten. Den zweiten hatte eine frühere Build-Sitzung mit curl installiert (einem Befehl, der eine Datei direkt aus dem Netz lädt), statt ihn aus einem Repository zu klonen. Er kam dem echten in die Quere, lud in den Cloud-Speicher hoch, den ich gerade verließ, und sprach mit einem leeren zweiten Modellserver, den dieselbe Sitzung versehentlich gestartet hatte. Drei laufende Dienste dort lagen in keinem Repository.

Die Regel des Tages: GitHub ist der Ursprung; jede Maschine, die Code ausführt, hat einen Klon und holt nur ab. Am 2. Juli folgte eine tägliche Prüfung auf Abweichungen; seit dem 18. September blockiert ein Hook (eine Prüfung vor jedem Befehl einer KI-Sitzung) von Hand geschriebenen Code auf Servern, zumindest in Claude Code.

Das Muster

Was passieren muss, gehört auf das, was immer läuft; Code hat einen Ursprung, und die Server holen nur ab. Am 7. Juli zog die wöchentliche Wartung vom Laptop weg, aus Claudes Desktop-App in Timer auf den Servern. Am 2. Oktober schlief der Laptop um drei Uhr morgens; ein nächtlicher Secret-Scan lief deshalb nur teilweise, und eine Backup-Prüfung meldete ein fehlendes Protokoll. Am 5. Oktober erschien der Tagesfokus verspätet auf meiner Startseite, weil er über den Laptop lief.

Was ich gelernt habe: Drei Fragen bestimmen, wo ein Job läuft. Erreichen ihn meine Werkzeuge? Braucht er Speicher oder eine Grafikkarte? Muss er laufen, während ich weg bin? Auch Code braucht ein Zuhause, sonst baut eine KI-Sitzung eine zweite Kopie, wo immer sie steht. Nicht gelöst: 13 geplante Jobs laufen noch auf dem Laptop, soweit ich sehe, meist zu seiner eigenen Pflege, und ein paar Dinge, die ich dort bearbeite, warten, bis er aufwacht. Mehr in Beitrag 11.

Teil 4 von zwölf in der Serie darüber, wie ich mein AI OS gebaut habe. Der Anfang: das Vorwort.

Als Nächstes: eine Datenbank, an einem Tag gebaut, und die siebzehn Tage, bis sie richtig blieb.

* Rechnernamen sind geändert (hier: Falcon, mein Laptop; Bespin, mein VPS; Dagobah, mein alter Windows-Desktop; und Yavin, der Heimserver, der aus ihm wurde). Die echten stammen aus einer anderen Saga.

Anhang – für alle, die selbst bauen