Gordon Zimm 75de1540b1 Seed legt keine Anleitung mehr auf der VM ab
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>
2026-09-25 09:48:00 +02:00
..
2026-09-23 10:15:16 +02:00

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.