Server-Installation

Diese Seite beschreibt, wie der ThinForge-Server auf einem frischen Host in Betrieb genommen wird: das empfohlene Betriebssystem, der Netzwerkaufbau mit zwei Adaptern (Firmen-LAN und Client-VLAN) und die Installation per Bootstrap-Skript. Sobald der Server läuft, übernimmt der Setup-Assistent in der Web-Oberfläche die restliche Konfiguration.

Betriebssystem: Ubuntu Server (empfohlen)

Als Basis empfehlen wir Ubuntu Server 24.04 LTS („Noble Numbat") — das ist die getestete und unterstützte Plattform. ThinForge läuft fast vollständig in Docker-Containern; auf dem Host selbst werden nur Docker, ein paar Kernel-Module und die Zeitsynchronisation eingerichtet. Eine Minimal-Installation ohne Desktop genügt.

Ausgabe: Ubuntu Server 24.04 LTS, 64-Bit (amd64).
Umfang: Minimal-/Standard-Installation reicht — kein Desktop nötig. Den OpenSSH-Server mitinstallieren, damit der Host fernadministrierbar ist.
Virtualisierung: Die CPU-Virtualisierung (VT-x/AMD-V) sollte im BIOS/UEFI aktiv sein. Die Cloning-VM, in der die Images gebaut werden, läuft sonst nur langsam in reiner Emulation.

Hinweis: Debian wird grundsätzlich auch unterstützt, ist aber nur „best effort" — das Abhängigkeits-Skript ist auf die Ubuntu-Paketquellen abgestimmt. Wer auf Nummer sicher gehen will, nimmt Ubuntu 24.04 LTS.

Netzwerk: zwei Adapter

Der ThinForge-Server arbeitet am saubersten mit zwei Netzwerkadaptern. Der eine hängt im normalen Firmen-LAN, der andere bedient ein eigenes Netz, in dem sich die Clients befinden — typischerweise ein per VLAN abgetrenntes Client-Netz.

Adapter	Netz	Rolle
Management / Upstream	normales Firmen-LAN	Zugriff auf die Admin-Oberfläche, Internet für Updates und Image-Downloads, Anbindung an den Firmen-DNS. Diese Schnittstelle behält ihre vorhandene Adresse (DHCP oder statisch) — ThinForge ändert sie nicht.
Rollout / Client	Client-VLAN	Hier vergibt ThinForge per DHCP die IP-Adressen, liefert den PXE-Boot (TFTP) und die DNS-Auflösung an die Geräte. ThinForge legt auf diesem Adapter eine feste IP an und betreibt darüber die gesamte Geräte-Infrastruktur.

Die Trennung hat zwei Gründe. Erstens darf der DHCP-/PXE-Dienst nur im Client-Netz aktiv sein — ein zweiter DHCP-Server im Firmen-LAN würde mit dem dortigen DHCP kollidieren. Zweitens ist die Admin-Oberfläche nur über das Management-Netz erreichbar: Auf dem Client-Adapter liegt bewusst nur die Geräte-/Agent-Schnittstelle, nicht das Web-UI.

Wichtig zum VLAN: Das VLAN-Tagging übernimmt der Switch, nicht ThinForge. Der zweite Adapter wird an einen Access-/Untagged-Port des Client-VLANs angeschlossen und erscheint im Server als ganz normale Schnittstelle (z. B. enp2s0). Getaggte Sub-Interfaces wie eth1.20 innerhalb von ThinForge werden nicht unterstützt — die VLAN-Grenze endet am Switch-Port.

Der Betrieb mit nur einem Adapter ist möglich (Management- und Client-Netz fallen dann zusammen). Für eine saubere Trennung von Firmen- und Geräte-Verkehr ist die Zwei-Adapter-Variante aber die empfohlene.

Voraussetzungen

Ein Benutzer mit sudo-Rechten (nicht root). Das Installationsskript verweigert den Start als root und nutzt sudo, wo nötig.
git ist installiert: sudo apt-get install -y git.
Internet-Zugang über das Management-LAN — für Docker, die Container-Images und das Clonezilla-Abbild.
Eine korrekt gestellte Uhr. Das Skript richtet Zeitzone und NTP-Synchronisation ein (wichtig für TLS und den Agent-Heartbeat).

Installation per Bootstrap-Skript

Die komplette Einrichtung erledigt bootstrap-release.sh in einem Durchlauf. Das Skript ist Teil des öffentlichen Release-Repositorys und holt sich alles Weitere selbst — es sind keine Zugangsdaten nötig.

# Als sudo-fähiger Benutzer ausführen — NICHT als root
git clone https://git.thinforge.org/thinforge/ThinForge-Release.git ~/ThinForge-Release
cd ~/ThinForge-Release
./bootstrap-release.sh

Das Skript arbeitet drei Schritte ab:

Release holen — klont (oder aktualisiert) das öffentliche Release-Repository.
Abhängigkeiten (install-deps.sh) — installiert Docker samt Compose-Plugin, lädt die nötigen Kernel-Module, richtet Zeitzone/NTP ein und erzeugt die .env automatisch mit zufällig generierten Passwörtern. Für eine Standard-Installation muss nichts von Hand editiert werden.
Stack starten (deploy.sh) — lädt die fertigen Container-Images aus der Registry, erzeugt das TLS-Zertifikat und startet den kompletten Dienst-Stack.

Tipp: Per SSH am besten mit ssh -t verbinden — das Skript fragt mehrfach das sudo-Passwort ab und braucht ein echtes Terminal. Nach dem ersten Lauf wird der Benutzer der docker-Gruppe hinzugefügt; dafür einmal ab- und wieder anmelden (oder newgrp docker).

Erster Aufruf & Setup-Assistent

Nach dem Durchlauf ist die Oberfläche unter https://<server>/ erreichbar (das Skript zeigt die Adresse am Ende an). Das TLS-Zertifikat ist zunächst selbstsigniert — die Browser-Warnung einmal bestätigen.

Beim ersten Aufruf führt der Setup-Assistent durch die restliche Konfiguration. Im Netzwerk-Schritt werden genau die beiden oben beschriebenen Adapter zugeordnet:

Management-Schnittstelle — der Adapter im Firmen-LAN, über den die Oberfläche erreichbar ist, plus der Upstream-DNS des Servers.
Rollout-Schnittstelle — der Adapter ins Client-VLAN, mit fester Server-IP, DHCP-Bereich, Gateway und Lease-Zeit. Aus der Server-IP leitet der Assistent den passenden Adressbereich automatisch ab.

Zum Abschluss legt der Assistent das Administrator-Konto an (Benutzername, E-Mail, Passwort) — einen Standard-Login gibt es bewusst nicht. Danach meldet man sich mit diesen Daten an. Die Detail-Einstellungen zu DHCP, DNS und PXE sind später jederzeit unter Netzwerk erreichbar.

Konfiguration des Client-/Rollout-Netzes — Das Client-/Rollout-Netz: Server-IP, DHCP-Bereich, Gateway und Lease-Zeit — im Setup-Assistenten gesetzt, später unter „Netzwerk" anpassbar.