Der erste Lauf auf der Pilotkunden-VM endete Failed, sichtbar war nur
needrestarts Abschlussmeldung aus dem apt-Lauf - also die Stelle, an der die
Pakete fertig installiert waren. Zwischen apt-mark hold und docker --version
gibt das Skript nichts aus; aus dem Protokoll liess sich deshalb nicht lesen,
wo der Lauf stehen geblieben ist.
Zwei Aenderungen: Die lange Ausgabe des apt-Laufs wird aufgefangen und nur im
Fehlerfall gezeigt (letzte 30 Zeilen) - sie verdraengt sonst den Bericht am
Ende, dasselbe Problem wie der Pull-Fortschritt bei ESPO-03. Und die stumme
Strecke bekommt vier knappe Standmeldungen, sodass die letzte Zeile der
Ausgabe immer verraet, wie weit der Lauf gekommen ist.
Ausserdem tragen jetzt alle Abbrueche des Hauptskripts die Zeile
ESPO02_ERGEBNIS: FEHLER - der Script Monitor sucht danach.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der haengende ScreenConnect-Client wird ueber die Default-Policies geloest, damit
er gar nicht erst installiert wird - nicht im Skript. ESPO-01 ist damit wieder
auf seine neun Schritte zurueck, ESPO-02 auf die knappe Fehlerzeile.
Aus der offiziellen Docker-Doku bleibt, was dorthin gehoert: das Entfernen
konkurrierender Pakete vor der Installation und ca-certificates/curl vor dem
Schluessel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei apt-Fehler ohne eine einzige Zeile aus dem Skript liessen offen, ob
ueberhaupt die Repo-Fassung gelaufen ist. Die Standzeile beantwortet das
kuenftig in der ersten Ausgabezeile.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Abgleich mit docs.docker.com/engine/install/ubuntu zeigte eine fehlende
Vorstufe: Die Doku verlangt, docker.io, docker-compose, docker-doc,
docker-buildx, podman-docker sowie containerd und runc zu entfernen, bevor
installiert wird - containerd.io buendelt containerd und runc und steht mit
beiden in Conflicts. Genau das passt zum Symptom "unerfuellte Abhaengigkeiten".
Ausserdem wie in der Doku ca-certificates und curl vor dem Schluessel. Die
deb822-Quelle entspricht bereits woertlich der Doku; beim Pinning bleiben wir
strenger als sie (sie pinnt nur docker-ce und docker-ce-cli).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die vier gepinnten Versionen existieren im Docker-Repo fuer noble (geprueft
gegen den Packages-Index), die Ursache liegt also woanders. Statt zu raten
gibt das Skript jetzt im Fehlerfall die Simulation von apt (mit der konkreten
unerfuellten Abhaengigkeit), die verfuegbaren Versionen inklusive iptables und
nftables, die bereits installierten Docker-Pakete und haengende Installationen
aus. Ausserdem -q statt -qq, damit apt ueberhaupt etwas sagt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Task entscheidet per If/Then auf espo_zustand, ob er laufen darf; die
Skripte brauchen den Wert dann nicht mehr. ESPO-01 nimmt nur noch den
Kundennamen, ESPO-02 kein Argument, ESPO-03 fqdn und ring.
In ESPO-03 bleibt die Pruefung auf eine vorhandene Instanz - sie beruht auf
Tatsachen auf der VM, nicht auf einem Feldwert, und verhindert eine Migration
ohne geprueftes Backup.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Statt lokaler Merkmale steuert das Custom Field espo_zustand zentral, was laufen
darf. Jedes der drei Skripte nimmt den Wert als Argument und bricht ohne
Aenderung ab, wenn er nicht NEU ist.
In ESPO-03 bleibt die Pruefung auf eine vorhandene Instanz als Rueckfall
erhalten: Der Zustand im RMM ist von Hand aenderbar, eine laufende Instanz ist
es nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Vorlage ist fuer alle Kunden identisch und traegt genau einen Platzhalter
(__FQDN__); bin/espo-compose-rendern setzt ihn ein und schreibt
/srv/espo/docker-compose.yml. Keine .env mehr: alles ausser den Geheimnissen
steht in der Compose selbst.
Inhalt der Vorlage: Bind-Mounts unter /srv/espo, Datei-Secrets fuer die beiden
MariaDB-Passwoerter, Record-IDs als uuid4/36 ueber configs (in allen drei
EspoCRM-Diensten, weil configs nicht ueber volumes_from vererbt werden),
adminUpgradeDisabled, WebSocket ueber wss://<fqdn>/wss, Healthchecks mit
Startfenstern fuer den Migrationslauf.
ESPO-02 setzt keine abweichende Bindeadresse mehr - die Ports muessen fuer den
Reverse Proxy erreichbar sein. Stattdessen beschraenkt eine DOCKER-USER-Regel
den Zugang auf das eigene Subnetz, das die VM selbst ermittelt; eine
systemd-Unit setzt sie nach jedem Docker-Start neu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
