Thomas Stallinger 2190d6f403 feat(boot-medium): Tuxflotte-Nutzlast ins Boot-Medium einbauen (Phase 1)
scripts/ (installer.sh, lib/*, modules/00-99) und backends/mint-image/
(inkl. echtem postinstall.sh statt Symlink auf backends/mint/) werden ueber
config/includes.chroot/opt/tuxflotte/ ins Image kopiert - bewusst nur die
zur Laufzeit benoetigten Dateien, nicht die Build-Host-Werkzeuge
(build_customer_iso.sh, build_golden_image.sh, package_golden_image.sh,
lib/initrd.sh etc. bleiben aussen vor).

00_preflight.sh und backend_init() (backends/mint-image/backend.sh)
verlieren ihre Laufzeit-apt-get-Nachinstallation (jq, parted, dosfstools,
e2fsprogs, zstd, btrfs-progs, gettext-base, curl) - alles bereits in
Phase 0 vorinstalliert. Werden durch reine Assertions ersetzt, die frueh
und klar melden, falls die Paketliste doch mal luecken sollte.

backends/mint/postinstall.sh nach backends/mint-image/postinstall.sh als
echte Datei verschoben (war Symlink) - noetig, weil backends/mint/ in
Phase 4 komplett entfernt wird.

Live verifiziert in der enterprise-QEMU-VM: installer.sh von Hand
gestartet, Module 00/05/10/12/15/17 liefen sauber durch, inkl. echtem
Server-Kontakt zu anode und echter Geraeteregistrierung (Liebherr-Org),
Commit-Gate erschien interaktiv wie erwartet, kontrollierter Abbruch ohne
jede destruktive Aktion.
2026-08-31 13:52:38 +02:00

73 lines
3.5 KiB
Bash

#!/bin/bash
# Lesbare Referenzfassung des Agent-Bootstraps, den backend_generate_config()
# in backend.sh zur Laufzeit envsubst-auflöst und anschließend base64-kodiert
# in preseed.tpls ubiquity/success_command einsetzt (siehe backend.sh). Diese
# Datei selbst wird nie direkt ausgeführt - sie existiert, damit der Code
# lesbar bleibt statt nur als Base64-Blob im Preseed zu existieren.
#
# Inhaltlich das Bash-Pendant zu backends/fedora/kickstart.tpl %post: gleiche
# curl/jq-Aufrufe, nur eingebettet über ubiquity/success_command (in-target,
# chrooted) statt Kickstart %post.
tuxflotte_agent_fatal() {
echo "tuxflotte: Provisioning-Agent-Einrichtung fehlgeschlagen: $*" >> /var/log/tuxflotte-postinstall.log
exit 1
}
ANODE_URL="https://anode.tuxflotte.de"
AGENT_REPO_RAW="https://git.tuxflotte.de/admin/provisioning-agent/raw/branch/main"
install -d -m 0700 /etc/tuxflotte ||
tuxflotte_agent_fatal "Verzeichnis /etc/tuxflotte konnte nicht angelegt werden."
# Identifikation soll in beide Richtungen moeglich sein: die Geraeteliste
# zeigt den Fingerprint bereits an (siehe geraete_liste.html), aber bislang
# gab es auf dem installierten Geraet selbst keine Datei, um ihn mit einem
# einfachen "cat" gegenzupruefen - build_device_fingerprint() (10_hardware.sh)
# berechnet ihn nur einmalig waehrend des Live-Boots und haelt ihn sonst
# nirgends fest. Absichtlich Klartext, kein Secret - reiner Hardware-Hash,
# kein chmod 0600 noetig wie bei agent.credentials.
echo "${TUXFLOTTE_DEVICE_FINGERPRINT}" > /etc/tuxflotte/device_fingerprint ||
tuxflotte_agent_fatal "device_fingerprint konnte nicht abgelegt werden."
cat > /etc/tuxflotte/runtime_blueprint.json <<'RUNTIME_BLUEPRINT_EOF'
${TUXFLOTTE_BLUEPRINTS_JSON}
RUNTIME_BLUEPRINT_EOF
install -d /opt/tuxflotte/agent ||
tuxflotte_agent_fatal "Verzeichnis /opt/tuxflotte/agent konnte nicht angelegt werden."
curl --silent --show-error --fail --location \
--output /opt/tuxflotte/agent/agent.py \
"${AGENT_REPO_RAW}/agent.py" ||
tuxflotte_agent_fatal "agent.py konnte nicht von ${AGENT_REPO_RAW} geladen werden."
curl --silent --show-error --fail --location \
--output /etc/systemd/system/tuxflotte-agent.service \
"${AGENT_REPO_RAW}/tuxflotte-agent.service" ||
tuxflotte_agent_fatal "tuxflotte-agent.service konnte nicht von ${AGENT_REPO_RAW} geladen werden."
AGENT_BOOTSTRAP_RESPONSE="$(
curl --silent --show-error --fail --location \
--header 'Content-Type: application/json' \
--data-binary "{\"device_id\": \"${TUXFLOTTE_DEVICE_ID}\"}" \
"${ANODE_URL}/api/v1/agent/bootstrap"
)" ||
tuxflotte_agent_fatal "Bootstrap-Aufruf gegen ${ANODE_URL} ist fehlgeschlagen."
jq --exit-status '.success == true' <<<"${AGENT_BOOTSTRAP_RESPONSE}" >/dev/null ||
tuxflotte_agent_fatal "Server hat den Bootstrap abgelehnt: ${AGENT_BOOTSTRAP_RESPONSE}"
jq --null-input \
--arg device_id "${TUXFLOTTE_DEVICE_ID}" \
--argjson response "${AGENT_BOOTSTRAP_RESPONSE}" \
'{device_id: $device_id, agent_secret: $response.agent_secret}' \
> /etc/tuxflotte/agent.credentials ||
tuxflotte_agent_fatal "Credentials-Datei konnte nicht erzeugt werden."
chmod 0600 /etc/tuxflotte/agent.credentials
systemctl enable tuxflotte-agent.service ||
tuxflotte_agent_fatal "systemd-Dienst tuxflotte-agent konnte nicht aktiviert werden."
echo "tuxflotte: Runtime Blueprint unter /etc/tuxflotte/runtime_blueprint.json hinterlegt." >> /var/log/tuxflotte-postinstall.log
echo "tuxflotte: Provisioning-Agent installiert, registriert und für den ersten Boot aktiviert." >> /var/log/tuxflotte-postinstall.log