Gordon Zimm f75c62224f ESPO-13-Secrets-setzen, ESPO-30-Extension-Installieren, espo_extensions

ESPO-13 legt Secrets unter /srv/espo/secrets ab (vorerst
gitea_package_token). Je Secret ein Parameter; leer oder woertlicher
Platzhalter laesst den Bestand. Erst Format und Funktion aller Werte
pruefen (Probeabruf der Registry), dann atomar schreiben - ein falscher
Token ersetzt keinen funktionierenden. Getestet: gesetzt, unveraendert,
falsches Format, abgelehnter Token.

ESPO-30 holt <extension> <version> aus der Package Registry
EspoCRM_Packages: SHA-256 gegen die Registry, Name und Version gegen das
Manifest, kein Rueckschritt, Snapshot srv-vor-update vor dem Download,
Installation per command.php als www-data, Neustart und Warten auf
healthy, Nachweis ueber --list. Danach liegt keine ZIP mehr auf der VM -
auch EspoCRMs eigene Archive in data/upload/extensions werden entfernt;
Update und Deinstallation brauchen sie nicht (Quelle 10.0.8).

ESPO-20 misst espo_extensions ("Name Version; ...", "none" wenn leer) und
beschreibt den Leseweg der Version wieder richtig. Ring 0 sperrt den
Extension-Upload in der Oberflaeche. README: Nummernkreise nachgezogen,
verrutschte Zeilen der Verzeichnistabelle zurueckgeholt.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-09-30 13:58:35 +02:00

2.6 KiB

Raw Blame History

espo-deploy

Öffentliche, geheimnisfreie Artefakte für EspoCRM-Kunden-VMs. Alles hier wird von den VMs ohne Anmeldung abgerufen – es steht deshalb kein Passwort, kein Token und keine Kundenangabe in diesem Repository.

Verzeichnis	Inhalt
`autoinstall/`	NoCloud-Seed für die Basis-VM (`user-data`, `meta-data`)
`rmm-tasks/`	Skripte, die als Task im ConnectWise RMM hinterlegt sind (Quelle für Änderungen)
`bin/`	Skripte, die auf der VM unter `/srv/espo/bin/` liegen und von Tasks aufgerufen werden
`docker/`	je Ring ein Ordner mit dem Stand dieses Rings: `docker-compose.yml` und `config-override.php`

Nummernkreise der Tasks

Kreis	Bedeutung	bisher
`0x`	von der leeren VM zur laufenden Instanz	`01` Grundeinrichtung, `02` Docker, `03` First-Deploy
`1x`	aktualisieren	`10` Update, `11` Snapshot verwerfen, `12` Snapshot wiederherstellen, `13` Secrets setzen
`2x`	Betrieb und Überwachung	`20` Inventar, `21` Backup-Prüfung (geplant)
`3x`	Extensions	`30` Extension installieren

Ein Kreis beginnt bei x0. Die Liste im RMM sortiert alphabetisch, die Reihenfolge stimmt damit.

Konzept, Entscheidungen und Runbooks liegen im internen Repository espoCRM/espo-fleet-ops.

Autoinstall

autoinstall ds=nocloud-net\;s=https://gitea.subcura.net/EspoCRM_Public/espo-deploy/raw/branch/main/autoinstall/

Das Semikolon muss maskiert werden – in GRUB trennt ein unmaskiertes ; zwei Befehle.

Compose und Ringe

Ordner	Ring	Inhalt
`docker/0 - intern/`	0	der aktuelle Stand, hier wird entwickelt und getestet
`docker/1 - Pilotkunde/`	1	freigegebener Stand für Pilotkunden
`docker/2 - Produktivkunde/`	2	freigegebener Stand für den Regelbetrieb

Jeder Ordner enthält den vollständigen Stand dieses Rings: eine docker-compose.yml mit genau einem Platzhalter (__FQDN__) und die config-override.php mit den EspoCRM-Grundeinstellungen. Eine Freigabe ist das Kopieren dieser Datei in den nächsten Ordner – damit steht in jedem git diff, welche Instanzen den neuen Stand bekommen.

bin/espo-compose-rendern <fqdn> <ring> holt den Stand des Rings, setzt den FQDN ein und schreibt /srv/espo/docker-compose.yml. Diese Datei auf der VM ist ein Erzeugnis – sie wird bei jedem Lauf neu geschrieben, Änderungen von Hand gehen verloren. Geändert wird im Repository.

Kundenspezifisches

Gehört nicht hierher, sondern in die Custom Fields des RMM (FQDN, Ring, Wartungsfenster). Geheimnisse entstehen auf der VM (/srv/espo/secrets/, 0600) und verlassen sie nicht.