Tag 0 — Server-Grundlagen

Debian, Partitionierung, Docker, Nginx und eine reproduzierbare Basis, damit der KM0-Stack auditierbar und betriebsfähig bleibt.

Einleitung

Tag 0 widmet sich den Grundlagen: ohne ein reproduzierbares Betriebssystem und eine funktionierende Umgebung wäre jeder spätere Stack fragil und schwer auditierbar.

Das Ziel ist, den Tag mit stabilem Debian, geordnetem Speicher, minimalen aber ausreichenden Werkzeugen und einer Shell abzuschließen, die dazu einlädt, jede Änderung zu dokumentieren.

Infrastruktur

Technischer Bootstrap-Plan

KM0 zielt auf Infrastruktur ab, die das Team ohne undurchsichtige proprietäre Panels betreiben kann. Das vollständige Bootstrap-Bild umfasst:

  • System: VPS mit aktuellem Debian und Partitionen, die System und Daten bei Bedarf trennen (klarere Snapshots und Backups).
  • Zusammenarbeit: OpenCloud als Microservices auf einem offiziellen OpenCloud.eu-Image, mit stabilen Volumes (COMPOSE_PROJECT_NAME), unabhängig vom Compose-Arbeitsverzeichnis.
  • Perimeter: Nginx als einziger HTTPS-Front; Docker veröffentlicht HTTP nur auf 127.0.0.1.
  • Kommunikation: Dockerisierter Astro auf einem weiteren Loopback-Port; separate Vhosts für km0digital.com und cloud.km0digital.com.
  • Beobachtbarkeit: rotierte Logs (json-file), Runbooks mit docker compose ps, logs, pull und komprimierten Volume-Backups.
  • Evolution: Produktions-TLS intern, automatisierte Backups und Fail2ban pro spezifischen Jails.

Speicher und System

VPS-Bereitstellung und Partitionen

Debian wurde wegen vorhersehbarer Pakete und praxisnaher Dokumentation gewählt — ohne verpflichtende Control Panels. Der erste Schritt war die Prüfung des Speicherlayouts:

  • Projektdaten vom Root-Dateisystem trennen, wenn Backup auf Volume-Ebene nötig ist.
  • Mounts bewusst definieren: /var/lib/docker kann je nach VPS-Größe OpenCloud-I/O konzentrieren.
  • Konventionen dokumentieren, um persistente Mounts vom Betriebssystem zu unterscheiden.
Exakte Partitionierungspläne hängen vom Anbieter und der gebuchten Größe ab. Sie müssen im Projekt-Wiki oder Runbook stehen — nicht nur in diesem Blog — für die Disaster Recovery.

Basispakete

Basissoftware

Ein vernünftiges Minimum für sichere Remote-Administration und Docker wurde installiert, ohne Ballast:

  • Gängige Utilities: curl, Editoren, Netzwerk und Diagnose.
  • Docker Engine mit rotierten Logs in /etc/docker/daemon.json.
  • Nginx aus Systempaketen als stabiler Front.
  • Certbot und TLS phasenweise (HTTP-01 oder selbstsigniertes Zertifikat im Lab).

Jedes Stück hat eine beobachtbare Rolle: systemctl status, nginx -t, docker compose ps.

Konsole

Shell-Ergonomie

Für konsistente SSH-Sitzungen wurde der Wiki-Leitfaden initialConfiguration angewendet:

  • Lesbarer Bash-Prompt (Pfad, Befehlsstatus, visuelle Hinweise).
  • History und sichere Defaults, die wiederholte Fehler reduzieren.
  • Aliases und PATH ausgerichtet auf Compose und Git unter /opt/....

Diese Basis, außerhalb des Servers dokumentiert, ermöglicht dasselbe Template auf anderen VPS-Instanzen ohne Improvisation.

Werkzeuge

cursor-agent

Kommandozeilen-Unterstützung

cursor-agent wurde installiert, um die tägliche Arbeit näher an einen assistierten Entwicklungsfluss zu bringen: Reviews, Hilfsskripte und schrittweise Dokumentation von der Konsole aus.

Er ersetzt weder menschliche Reviews noch Team-Kontrollen, senkt aber die Reibung bei wiederholbaren Aufgaben (Compose-Overlays, Nginx vor Reload validieren usw.).

Tagesende

Stand am Ende von Tag 0

Am Ende des Tages erfüllt der Server drei Eigenschaften:

  1. Auditierbar: bekanntes Speicherlayout und Pakete.
  2. Reproduzierbar: Hauptschritte verknüpft mit Wiki und Runbooks.
  3. Bereit für Docker, ohne Services zu früh öffentlich freizugeben.

Nächster Schritt

Tag 1

Tag 1 bringt OpenCloud, den Proxy-Virtual-Host und die KM0-Website über TLS hoch. In der Zwischenzeit: die veröffentlichten Services erkunden oder Kontakt aufnehmen, wenn Sie mitarbeiten möchten.