Der late-command, der /root/ERSTINBETRIEBNAHME.txt erzeugte, ist entfernt (11 statt 12 late-commands). Auf der VM wird nichts gelesen, und eine mitgelieferte Anleitung altert dort: ab dem zweiten Kunden stehen auf den Maschinen verschiedene Staende, die niemand nachzieht. Die Handgriffe stehen jetzt im Runbook des internen Repositorys (espo-fleet-ops/docs/runbooks/erstinbetriebnahme-kunden-vm.md); der Seed nennt es in einer Kommentarzeile, autoinstall/README.md verweist darauf. Dabei mitgezogen: Abschnitt "Ablageort" nannte noch die Zwischenkopie gordon.zimm/ubuntu-autoinstall (O-26 ist seit 23.09.2026 entschieden), und drei Links zeigten auf docs/, das es in diesem Repo nicht gibt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.1 KiB
Autoinstall-Seed für die EspoCRM-Kunden-VM
user-data und meta-data bilden eine NoCloud-Quelle. Das Verzeichnis ist öffentlich abrufbar – es enthält deshalb
keine Geheimnisse (kein benutzbares Passwort, kein RMM-Token; siehe ADR 0004 im internen Repository espoCRM/espo-fleet-ops).
Ablageort
Entschieden am 23.09.2026 (O-26): Der Installer ruft ohne Anmeldung ab; dieses Repo ist deshalb der Ablageort des Seeds. Boot-Zeile:
autoinstall ds=nocloud-net\;s=https://gitea.subcura.net/EspoCRM_Public/espo-deploy/raw/branch/main/autoinstall/
Dieses Verzeichnis ist die Kopie, die der Installer abruft. Geändert wird im internen Repository
espoCRM/espo-fleet-ops unter autoinstall/; user-data ist hier byteidentisch.
Hintergrund zur Wahl (O-26)
Der Installer ruft die Dateien ohne Anmeldung ab. Dieses Repo liegt in der Organisation espoCRM, die nicht öffentlich
sichtbar ist: Ein anonymer Abruf von
https://gitea.subcura.net/espoCRM/espo-fleet-ops/raw/branch/main/autoinstall/user-data liefert 404, obwohl das Repo
selbst als „nicht privat“ geführt wird (geprüft am 22.09.2026; dasselbe gilt für espoCRM/espo-dev).
Anonym erreichbar ist dagegen gordon.zimm/ubuntu-autoinstall.
Solange das nicht entschieden ist, kommt der Seed dort hin, wo er abrufbar ist. Kandidaten:
| Variante | Boot-Zeile | Bemerkung |
|---|---|---|
| Unterverzeichnis im bestehenden öffentlichen Repo | autoinstall ds=nocloud-net\;s=https://gitea.subcura.net/EspoCRM_Public/espo-deploy/raw/branch/main/autoinstall/ |
schnellster Weg, stört den bestehenden Seed im Wurzelverzeichnis nicht |
eigenes öffentliches Repo, z. B. gordon.zimm/espo-autoinstall |
… ds=nocloud-net\;s=…/gordon.zimm/espo-autoinstall/raw/branch/main/ |
klar abgegrenzt, ein Zweck |
Organisation espoCRM auf „öffentlich“ stellen |
… ds=nocloud-net\;s=…/espoCRM/espo-fleet-ops/raw/branch/main/autoinstall/ |
macht auch espoCRM/espo-dev für jeden lesbar – nicht empfohlen |
| Seed auf der Installationsmedium-Seite (zweites CIDATA-Image) | keine URL nötig | für die Flotte die sauberste Lösung, in Phase 3 zu prüfen |
Das Semikolon muss maskiert werden
In der GRUB-Kommandozeile trennt ; zwei GRUB-Befehle. Unmaskiert bekommt der Kernel nur autoinstall ds=nocloud-net,
die Seed-URL fällt weg – der Installer startet dann ganz normal interaktiv. Deshalb \; schreiben (so steht es auch
in der README von ubuntu-autoinstall). Gleichwertig: die ganze Angabe in Anführungszeichen setzen,
autoinstall "ds=nocloud-net;s=https://…/espocrm/".
Nach dem Booten der Ubuntu-Server-24.04-ISO im GRUB-Menü e drücken, die gewählte Zeile vor --- einfügen, Strg+X.
Die Installation läuft ohne Rückfragen durch und schaltet die VM am Ende aus. Vor dem nächsten Start das ISO trennen,
sonst startet die Installation erneut.
Nach dem ersten Start (einmal je VM)
Die Handgriffe von der leeren VM bis zur laufenden Instanz stehen im Runbook des internen Repositorys
espoCRM/espo-fleet-ops, Datei docs/runbooks/erstinbetriebnahme-kunden-vm.md – Passwortwechsel,
Agent-Installation samt Token-Übergabe, Einstellungen am Gerät, die drei Tasks, Abschlussprüfung.
Der Seed legt dazu keine Datei auf der VM ab: gepflegt wird an einer Stelle, nicht auf jeder Maschine.
Was der Seed einrichtet
| Bereich | Wert |
|---|---|
| Sprache/Tastatur/Zeitzone | de_DE.UTF-8, de, Europe/Berlin |
| Netz | erste Ethernet-Schnittstelle (match: e*), DHCPv4, kein DHCPv6 |
| Konto | administrator, Passwort je VM zufällig, Wechsel beim ersten Anmelden erzwungen |
| SSH | Server installiert, Passwortanmeldung erlaubt (ADR 0003) |
| Pakete | linux-cloud-tools-virtual (Hyper-V-Integrationsdienste), curl, bzip2 |
| Platten | / 20 GiB, swap 4 GiB, /var/lib/docker 20 GiB, /srv der gesamte Rest minus 10 GiB; die 10 GiB bleiben in der VG frei als Platz für einen LVM-Snapshot vor einem Update |
| Zum Schluss | vollständiges apt full-upgrade, autoremove, clean, dann poweroff |
Hintergrund zur Aufteilung: docs/entwuerfe/plattenlayout-erlaeuterung.md im internen Repository.