tuxflotte-installer/scripts/modules/25_installation_confirm.sh
Thomas Stallinger 108444ecf7 feat: Auto-Modus + prozentuale Partitionierung für Mint (Phase 2)
Auto-Modus (TUXFLOTTE_AUTO_MODE=true, über config/installer.conf als
exportierte Env-Var vor 05_network.sh gesetzt) überspringt alle drei
interaktiven Gates, die bei genauerem Hinsehen existierten (nicht nur
das eine ursprünglich im Plan genannte):
- 05_network.sh: nicht-interaktiver WLAN-Pfad über TUXFLOTTE_WIFI_SSID/
  TUXFLOTTE_WIFI_PSK, analog zum bestehenden TUXFLOTTE_ACTIVATION_CODE-
  Muster in 12_enrollment_auth.sh (unverändert, unterstützte das schon).
- 17_device_status.sh: "Provisionierung fortsetzen?"-Prompt übersprungen.
- 20_profile_selection.sh: "Vorlage auswählen?"-Prompt übersprungen,
  wählt automatisch die als is_default markierte Vorlage (echter
  Server-Hinweis via Enrollment Session erst mit Phase 3 möglich).
- 25_installation_confirm.sh: eigentliches Commit-Gate übersprungen.

Alle drei Auto-Modus-Zweige lokal verifiziert (Skripte direkt mit
TUXFLOTTE_AUTO_MODE=true und präparierten Eingabedateien ausgeführt,
kein Hängenbleiben an read -p, korrekte state.env/template.json-Ausgabe).

Partitionierung: installation_directives.partitioning von einfachem
String auf strukturiertes Objekt umgestellt ({"scheme": "single"|
"custom", "root_filesystem", "extra_partitions": [{"mountpoint",
"filesystem", "percent"}]}) - Vertrag, an den sich provisioning-server
in Phase 3 halten muss. backend_generate_config() baut daraus ein
partman-auto/expert_recipe (ersetzt die bisherige choose_recipe-
Fallunterscheidung mit nur "default"/"atomic"), Prozentangaben werden
anhand der realen Zieldatenträgergröße (lsblk/blockdev, erst live auf
dem Zielgerät bekannt) in feste MB-Größen umgerechnet.

Auf UEFI-Systemen wird zusätzlich eine EFI-System-Partition ins Recipe
aufgenommen (sonst verweigert/warnt der Installer, "No EFI System
Partition was found") - exakte Stanza-Syntax nicht aus der Erinnerung
geraten, sondern aus /usr/lib/partman/recipes-amd64-efi/30atomic auf
dem echten Live-Medium ausgelesen ($reusemethod{ } war der fehlende
Teil in einem ersten, geparsten aber nicht erkannten Versuch).

backend_init() installiert jetzt auch jq/envsubst(gettext-base)/cpio
bei Bedarf nach (vorbestehende Lücke neben dem schon in Phase 1
behobenen kexec-tools).

Real per QEMU verifiziert: eigene Ein-Datenträger-Erkennung musste
gehärtet werden (nbd/zram-Geräte mit Größe 0 wurden fälschlich vor dem
echten Datenträger gewählt - auf einer sauberen VM allein wäre das nicht
aufgefallen). Custom-Recipe mit ext4-Root + ext4-/home (20%) +
btrfs-/var (10%) auf 40GB-Testplatte: vollständige unbeaufsichtigte
Installation inkl. Paketinstallation durchlaufen lassen, danach von der
Festplatte (nicht der Live-CD) gebootet - Login-Bildschirm mit korrektem
Hostname erscheint, System bootet einwandfrei per UEFI/ESP.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-06 16:12:56 +02:00

120 lines
3.2 KiB
Bash
Executable File

#!/usr/bin/env bash
set -Eeuo pipefail
SCRIPT_NAME="$(basename "${BASH_SOURCE[0]}")"
readonly SCRIPT_NAME
readonly TEMPLATE_FILE="/run/tuxflotte/assignment/template.json"
readonly RUNTIME_DIR="/run/tuxflotte/installation"
readonly STATE_FILE="${RUNTIME_DIR}/state.env"
log() {
printf '[%s] %s\n' "${SCRIPT_NAME}" "$*" >&2
}
fatal() {
printf '[%s] FEHLER: %s\n' "${SCRIPT_NAME}" "$*" >&2
exit 1
}
require_root() {
if [[ "${EUID}" -ne 0 ]]; then
fatal "Das Installationsbestätigungsmodul muss als root ausgeführt werden."
fi
}
prepare_runtime() {
install -d \
--mode=0700 \
--owner=root \
--group=root \
"${RUNTIME_DIR}"
rm -f -- "${STATE_FILE}"
}
validate_template() {
[[ -r "${TEMPLATE_FILE}" ]] ||
fatal "Bereitstellungsvorlage nicht gefunden: ${TEMPLATE_FILE}"
jq --exit-status '
.schema_version == 1
and (.template | type == "object")
and (.template.id | type == "string")
and (.template.label | type == "string")
and (.template.workspace.name | type == "string")
and (.template.backend.name | type == "string")
and (.template.backend.version | type == "string")
' "${TEMPLATE_FILE}" >/dev/null ||
fatal "Bereitstellungsvorlage enthält keine gültige Auswahl."
}
show_installation_plan() {
local label
local workspace
local backend_name
local backend_version
label="$(jq -r '.template.label' "${TEMPLATE_FILE}")"
workspace="$(jq -r '.template.workspace.name' "${TEMPLATE_FILE}")"
backend_name="$(jq -r '.template.backend.name' "${TEMPLATE_FILE}")"
backend_version="$(jq -r '.template.backend.version' "${TEMPLATE_FILE}")"
printf '\n'
printf 'Geplanter Installationsvorgang\n'
printf '==============================\n\n'
printf 'Bereitstellungsvorlage: %s\n' "${label}"
printf 'Workspace: %s\n' "${workspace}"
printf 'Backend: %s %s\n' "${backend_name}" "${backend_version}"
printf '\n'
printf 'Die eigentliche Installation kann lokale Datenträger verändern.\n'
printf 'Bis zu dieser Bestätigung wurden keine destruktiven Installationsaktionen gestartet.\n'
printf '\n'
}
store_confirmation_state() {
local confirmed="$1"
umask 077
printf 'TUXFLOTTE_INSTALLATION_CONFIRMED=%s\n' \
"${confirmed}" >"${STATE_FILE}"
chmod 0600 "${STATE_FILE}"
}
confirm_installation() {
local answer
if [[ "${TUXFLOTTE_AUTO_MODE:-false}" == "true" ]]; then
store_confirmation_state true
log "Auto-Modus: Installation wird ohne Rückfrage gestartet."
return 0
fi
read -r -p "Installation jetzt starten? [j/N]: " answer
case "${answer}" in
j|J|ja|JA|Ja)
store_confirmation_state true
log "Installation wurde durch den Benutzer bestätigt."
;;
*)
store_confirmation_state false
log "Installation wurde durch den Benutzer abgebrochen."
log "Es wurden keine destruktiven Installationsaktionen gestartet."
;;
esac
}
main() {
require_root
prepare_runtime
validate_template
show_installation_plan
confirm_installation
}
main "$@"