diff --git a/docs/01_Architecture/Minisforum-MS-R1/Biest_Roadmap.md b/docs/01_Architecture/Minisforum-MS-R1/Biest_Roadmap.md new file mode 100644 index 00000000..6c62d647 --- /dev/null +++ b/docs/01_Architecture/Minisforum-MS-R1/Biest_Roadmap.md @@ -0,0 +1,25 @@ +# Roadmap: Finalisierung Gitea-Infrastruktur (MS-R1) + +## Phase 1: Konnektivität & Erreichbarkeit 🌐 +- [x] **Schritt 1: Cloudflare Tunnel (Tor zur Welt)** + - Ziel: Sicherer Zugriff über `git.mo-code.at` ohne Portfreigabe. + - Status: ABGESCHLOSSEN (siehe `Gitea-SSH-Setup.md`). +- [x] **Schritt 2: SSH-Key & Git-Client Setup** + - Ziel: Passwortloses "Push & Pull" über Port 2222. + - Status: ABGESCHLOSSEN (siehe `Gitea-SSH-Setup.md`). +- [x] **Schritt 2b: Erster erfolgreicher Push** + - Ziel: Validierung der gesamten Kette (Laptop → Cloudflare → Tunnel → Host → Container → Gitea). + - Status: ABGESCHLOSSEN. + +## Phase 2: Datensicherheit & Resilienz 🛡️ +- [ ] **Schritt 3: Die "Biest-Versicherung" (Automatisches Backup)** + - Ziel: Nächtliche Snapshots des LXC-Containers + SQLite-Dumps auf den Host-Speicher. + - Status: Ausstehend. + +## Phase 3: Kommunikation & Feinschliff ✉️ +- [ ] **Schritt 4: SMTP-Integration (Brieftaube)** + - Ziel: E-Mail Benachrichtigungen über mo-code.at Domain. + - Status: Ausstehend. +- [ ] **Schritt 5: Gitea-Update-Protokoll** + - Ziel: Dokumentation des Prozesses zum manuellen Tausch der Binary. + - Status: Ausstehend. diff --git a/docs/01_Architecture/Minisforum-MS-R1/Gitea-SSH-Setup.md b/docs/01_Architecture/Minisforum-MS-R1/Gitea-SSH-Setup.md new file mode 100644 index 00000000..3752ce9b --- /dev/null +++ b/docs/01_Architecture/Minisforum-MS-R1/Gitea-SSH-Setup.md @@ -0,0 +1,81 @@ +# 💻 Client-Setup: Arbeitsplatz an "Das Biest" anbinden + +Diese Anleitung beschreibt die Einrichtung eines lokalen Rechners, um via SSH und Cloudflare-Tunnel auf die +Gitea-Instanz (`git.mo-code.at`) zuzugreifen. + +## 1. SSH-Schlüssel generieren + +Falls noch kein Schlüssel vorhanden ist, erstelle einen modernen Ed25519-Key: + +```bash +ssh-keygen -t ed25519 -C "stefan.mo.co@gmail.com" +``` + +Bestätige die Pfade mit Enter. Den Inhalt des öffentlichen Schlüssels anzeigen: + +```bash +cat ~/.ssh/id_ed25519.pub +``` + +**Aktion:** Kopiere den Inhalt und füge ihn in der Gitea Web-UI (`https://git.mo-code.at`) unter **`Einstellungen` -> +`SSH / GPG Schlüssel` hinzu. + +## 2. Cloudflare Tunnel-Client installieren + +Der Rechner benötigt `cloudflared`, um den SSH-Traffic durch das Zero Trust Gateway zu "beamen". + +**Für Debian/Ubuntu:** + +```bash +curl -L --output cloudflared.deb [https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb](https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb) +sudo dpkg -i cloudflared.deb +``` + +## 3. SSH-Konfiguration anlegen (`~/.ssh/config`) + +Damit Git automatisch den richtigen Port (2222) und den Tunnel-Proxy nutzt, muss die lokale SSH-Config angepasst werden. + +1. Datei öffnen: nano ~/.ssh/config +2. Folgenden Block einfügen: + +```text +Host git.mo-code.at + HostName ssh.mo-code.at + User git + Port 2222 + ProxyCommand /usr/bin/cloudflared access ssh --hostname %h + IdentityFile ~/.ssh/id_ed25519 +``` + +> **Hinweis:** Prüfe mit `which cloudflared`, ob der Pfad `/usr/bin/cloudflared` korrekt ist und passe ihn ggf. an. + +## 4. Zero Trust Autorisierung (Einmalig) + +Bevor die erste Verbindung klappt, muss der Rechner bei Cloudflare angemeldet werden: + +```bash +cloudflared access login [https://ssh.mo-code.at](https://ssh.mo-code.at) +``` + +Es öffnet sich ein Browser. Logge dich mit deiner E-Mail ein und bestätige den Zugriff. + +## 5. Verbindungstest + +Teste die Verbindung zum Biest: + +```bash +ssh -T git@git.mo-code.at +``` + +> **Soll-Ergebnis:** `Hi there, grandmo! You've successfully authenticated...` + +--- + +### Was wir heute erreicht haben (Zusammenfassung für dein Archiv): + +* **Host (Biest):** Läuft stabil auf Debian 12 (ARM64), nutzt `iptables-legacy` für das Netzwerk. +* **Infrastruktur:** Incus-Container `infra-gitea` ist über interne Proxies für Port 3000 (Web) und 2222 (SSH) + erreichbar. +* **Sicherheit:** Cloudflare Tunnel schützt das System; SSH-Zugriff ist nur über eine autorisierte Zero Trust + Application möglich. +* **Gitea:** Konfiguriert auf `git.mo-code.at` mit SSH-Server-Aktivierung im Container. diff --git a/docs/01_Architecture/Minisforum-MS-R1/MS-R1_Konfiguration&Bedienung.md b/docs/01_Architecture/Minisforum-MS-R1/MS-R1_Konfiguration&Bedienung.md new file mode 100644 index 00000000..f974d87f --- /dev/null +++ b/docs/01_Architecture/Minisforum-MS-R1/MS-R1_Konfiguration&Bedienung.md @@ -0,0 +1,202 @@ +# Technisches Referenzhandbuch: MS-R1 "Das Biest" + +## 1. System-Übersicht & Architektur + +Das System "MS-R1" (interner Codename "Das Biest") ist ein High-End ARM64-Server auf Basis des CIX P1 SoC. + +### Hardware-Spezifikationen + +* **CPU:** ARM64 Architektur (CIX P1). +* **RAM:** 64 GB LPDDR. +* **Speicher:** NVMe-basiertes Root-Dateisystem. +* **OS:** Debian 12 (Bookworm). + +## 2. Design-Entscheidungen & Ausschlussverfahren + +### 2.1 Wahl des Betriebssystems + +**Entscheidung:** Debian 12 (Bookworm). +**Begründung:** Maximale Stabilität für Infrastruktur-Dienste. +**Ausschluss:** Ubuntu wurde aufgrund der Snap-Abhängigkeiten und Fedora aufgrund der kürzeren Release-Zyklen ausgeschlossen. + +### 2.2 Kernel- & Firewall-Management + +**Problem:** Der spezifische ARM-Kernel unterstützt bestimmte moderne `nftables`- und `iptables`-Module (wie `xt_CHECKSUM`) nicht. +**Lösung:** Umstellung auf `iptables-legacy`. +**Vorteil:** Ermöglicht die korrekte Paketverarbeitung für virtuelle Netzwerke, die sonst zu "Hängern" in der UI führen würden. + +## 3. Benutzer- und Sicherheitskonzept + +Um das System abzusichern, wurde eine strikte Bereinigung der Standard-User durchgeführt. + +* **Administrative Accounts:** `grandmo` (Haupt-Admin) und `mastermo` (Redundanz). +* **System-Accounts:** `git` (UID 101) für Anwendungsdienste ohne Sudo-Privilegien. + +## Benutzer-Management +Das System verfügt über eine strikte Trennung zwischen Administration und Diensten: + +* **grandmo:** Haupt-Administrator (Sudo-Rechte) +* **mastermo:** Backup-Administrator (Sudo-Rechte) +* **git:** System-User für Gitea-Dienste (keine Sudo-Rechte) + +## 4. Kritische Wartungsbefehle + +Da Incus die Firewall-Regeln aufgrund von Kernel-Einschränkungen nicht selbst injizieren kann (`firewall=false`), muss das NAT-Routing manuell persistiert werden: + +```bash +# Manuelles Aktivieren des Internet-Gateways für Container +sudo iptables -t nat -A POSTROUTING -s 10.0.6.0/24 ! -d 10.0.6.0/24 -j MASQUERADE +``` + +## Kernel- & Firewall-Besonderheiten + +Aufgrund der ARM64-Architektur und Kernel-Einschränkungen wurden folgende Anpassungen vorgenommen: + +* **Firewall-Modus:** Das System nutzt `iptables-legacy`, da moderne NFT-Module teilweise fehlen. +* **NAT-Regel:** Da Incus die Firewall nicht automatisch verwalten kann, muss der Internetzugriff für Container manuell maskiert werden: + `sudo iptables -t nat -A POSTROUTING -s 10.0.6.0/24 ! -d 10.0.6.0/24 -j MASQUERADE` + +## Wichtige Befehle + +* **Neustart erzwingen:** `sudo systemctl reboot` +* **Admin-Rechte prüfen:** `sudo whoami` (sollte 'root' ergeben) + +--- + +## 2. Incus_Konfiguration&Bedienungsanleitung.md + +# Infrastruktur-Dokumentation: Incus Virtualisierung + +## 1. Virtualisierungs-Strategie + +Einsatz von Incus (LXC-Fork) zur Bereitstellung isolierter System-Container. + +## 2. Netzwerk-Infrastruktur (`incusbr0`) + +### 2.1 Technische Konfiguration + +* **Subnetz:** 10.0.6.1/24. +* **Modus:** Managed Bridge. +* **Einschränkung:** `ipv4.firewall: "false"`. + +## Netzwerk-Konfiguration (`incusbr0`) +* **Subnetz:** 10.0.6.1/24 +* **Firewall-Management:** Deaktiviert (`ipv4.firewall=false`), um Kernel-Fehler (`xt_CHECKSUM`) zu umgehen. +* **Erstellung:** `incus network create incusbr0 ipv4.address=10.0.6.1/24 ipv4.nat=true ipv4.firewall=false ipv6.address=none` + +### 2.2 Analyse des Ausschlussverfahrens + +Ursprünglich schlug die Erstellung der Brücke fehl (`exit status 1: Extension CHECKSUM revision 0 not supported`). + +* **Versuch A (Standard):** Incus verwaltet Firewall. -> **Fehlgeschlagen** (Kernel-Modul fehlt). +* **Versuch B (Bypass):** Incus erstellt nur das Interface, Administrator verwaltet Firewall manuell. -> **Erfolgreich**. + +## 3. Port-Exposition via Proxy-Device + +Anstatt Ports instabil über die IP-Adresse des Hosts zu binden, nutzt das Biest das native Incus-Proxy-Gerät: + +```bash +incus config device add infra-gitea gitea-proxy proxy listen=tcp:0.0.0.0:3000 connect=tcp:127.0.0.1:3000 +``` + +Vorteil: Der Dienst ist unter localhost:3000 erreichbar, selbst wenn sich die interne Container-IP ändert. + +## 4. Administration der Web-UI + +* **URL:** https://localhost:8443. +* **Sicherheit:** Zugriff nur via TLS-Client-Zertifikat. Das Zertifikat muss im Browser-Keystore des Administrators hinterlegt sein. + +## Web-UI (Incus Dashboard) +* **Zugriff:** `https://localhost:8443` +* **Authentifizierung:** TLS-Zertifikate (Client-Zertifikat im Browser importiert). +* **Token-Management:** Falls ein neuer Browser verbunden werden muss: `incus config trust add [Name]`. + +## Proxy-Geräte (Port-Forwarding) +Um Dienste aus Containern auf dem Host verfügbar zu machen: +`incus config device add [Container] [Proxy-Name] proxy listen=tcp:0.0.0.0:[Host-Port] connect=tcp:127.0.0.1:[Container-Port]` + +--- + +## 3. Gitea_Konfiguration&Bedienungsanleitung.md + +# Anwendungs-Dokumentation: Gitea (MoCode) + +## 1. Instanz-Details + +* **Container-Name:** `infra-gitea`. +* **Software-Version:** 1.21.4 (ARM64 Binary). +* **Betriebs-User:** `git` (Heimatverzeichnis: `/home/git`). + +## Container-Setup +* **Name:** `infra-gitea` +* **Interne IP:** 10.0.6.159 +* **Betrieb als:** User `git` (UID 101) + +## 2. Speicher-Architektur & FHS-Konformität + +Um Datenverlust bei Updates zu vermeiden, werden alle persistenten Daten außerhalb des Programmverzeichnisses (`/usr/local/bin`) gespeichert: + +* **WorkPath (GITEA_WORK_DIR):** `/var/lib/gitea`. +* **Repositories:** `/var/lib/gitea/data/gitea-repositories`. +* **Datenbank:** SQLite3 (`/var/lib/gitea/data/gitea.db`). + +## 3. Prozess-Management ("Gradle-Style" Troubleshooting) + +Aufgrund der engen Kopplung zwischen Gitea und dem SSH-Daemon kann es zu blockierten Sockets kommen. +**Fehlersymptom:** `bind: address already in use`. +**Lösungsschritte (Hard Reset):** + +1. `pkill -9 -u git` (Beendet alle Instanzen des Users). +2. `fuser -k 3000/tcp` (Erzwingt Freigabe des Ports). +3. `systemctl restart gitea` (Sauberer Neustart via Systemd). + +## 4. Systemd-Service Konfiguration + +Der Dienst wird über eine spezialisierte Unit-Datei gesteuert, die den `WORK_DIR` Fehler umgeht: + +```ini +[Service] +Environment=GITEA_WORK_DIR=/var/lib/gitea +ExecStart=/usr/local/bin/gitea web --config /var/lib/gitea/custom/conf/app.ini +User=git +Restart=always +``` + +## 5. Sicherheits-Audit + +* **Registrierung:** Deaktiviert (Private Instanz). +* **Sichtbarkeit:** "Ansehen erfordert Anmeldung" ist aktiv. +* **SSH:** Port 2222 (Vermeidung von Kollisionen mit Host-Port 22). + +### Zusammenfassung der Architektur-Vorteile: + +Durch diese Konfiguration ist das System **"Biest-sicher"**: + +1. **Isolation:** Gitea kann das Host-System nicht kompromittieren. +2. **Pfad-Treue:** Updates der Binary beeinflussen die Datenbank nicht. +3. **Resilienz:** Dank Systemd startet Gitea nach jedem Absturz oder Reboot innerhalb von 2 Sekunden automatisch neu. + +## Pfade & Verzeichnisse (Wichtig!) +Daten werden konsequent unter `/var/lib/gitea` gespeichert, um System-Verzeichnisse sauber zu halten: +* **Programm:** `/usr/local/bin/gitea` +* **Konfiguration:** `/var/lib/gitea/custom/conf/app.ini` +* **Repositories:** `/var/lib/gitea/data/gitea-repositories` +* **Datenbank:** `/var/lib/gitea/data/gitea.db` (SQLite3) +* **LFS-Pfad:** `/var/lib/gitea/data/lfs` + +## Netzwerkzugriff +* **Web-Interface:** Port 3000 (auf Host gemappt via Incus-Proxy). +* **SSH-Port:** 2222 (um Konflikte mit Host-SSH zu vermeiden). + +## Systemd-Autostart +Gitea wird als Hintergrunddienst im Container verwaltet: +* **Service-Datei:** `/etc/systemd/system/gitea.service` +* **Besonderheit:** `GITEA_WORK_DIR=/var/lib/gitea` muss gesetzt sein, um Permission-Fehler in `/usr/local/bin` zu vermeiden. + +## Wartung & Fehlerbehebung +* **Status prüfen:** `systemctl status gitea` (im Container) +* **Hängende Prozesse killen:** `pkill -u git` oder `fuser -k 3000/tcp` +* **Gezielter Neustart:** `systemctl restart gitea` + + + diff --git a/docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Host_OS.md b/docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Host_OS.md index ee86e180..eaf75f89 100644 --- a/docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Host_OS.md +++ b/docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Host_OS.md @@ -1,194 +1,8 @@ # Setup Guide: Host OS (Minisforum MS-R1) -**Status:** DRAFT -**Date:** 2026-02-07 -**Target:** Pre-installed Debian 12 (Vendor OS) +**Status:** DEPRECATED / HISTORIC +**Date:** 2026-02-08 +**Note:** Dieses Dokument beschreibt einen alternativen Ansatz (Macvlan). Das produktive System läuft gemäß `MS-R1_Konfiguration&Bedienung.md` (Bridge + Proxy). -Dieses Dokument beschreibt die Schritte, um das vorinstallierte Betriebssystem des Minisforum MS-R1 für den Einsatz als **Meldestelle Home-Server** vorzubereiten. - -## 0. SSH Verbindung herstellen - -Da der Server bereits im Netzwerk ist, verbinden wir uns per SSH. - -### IP-Adresse finden -Wenn du die IP-Adresse des Servers nicht kennst: -1. Schaue im Router (FritzBox o.ä.) nach einem Gerät namens `debian`, `minisforum` oder ähnlich. -2. Oder schließe kurz Monitor & Tastatur an und tippe `ip a` ein. Suche nach `inet 192.168.x.x`. - -### Verbinden (von deinem Arbeitsrechner) -Öffne ein Terminal (PowerShell oder Bash) auf deinem Laptop/PC: - -```bash -# Syntax: ssh @ -# Der Standard-User bei Debian ist oft 'root' oder 'debian' oder 'user'. -# Das Passwort steht oft auf einem Zettel im Karton oder ist 'minisforum', 'password' oder leer. - -ssh user@192.168.178.XX # (Ersetze XX mit der echten IP) -``` - -*Falls der Login klappt, fahre mit Schritt 1 fort.* - ---- - -## 1. Bestandsaufnahme & Update - -Zuerst prüfen wir den Status des Systems und aktualisieren die Pakete. - -```bash -# System-Infos anzeigen (Kernel, Architektur) -uname -a -cat /etc/debian_version -lscpu - -# Prüfen, ob KVM (Virtualisierung) aktiv ist (Wichtig für Incus VMs!) -ls -l /dev/kvm -# Sollte crw-rw---- root kvm ... ausgeben. - -# Paketquellen aktualisieren und System upgraden -sudo apt update && sudo apt full-upgrade -y - -# Aufräumen -sudo apt autoremove -y -``` - -## 2. Basis-Tools installieren - -Wir benötigen einige Standard-Tools für die weitere Verwaltung. - -```bash -sudo apt install -y curl wget git htop vim nano ufw net-tools dnsutils -``` - -## 3. Sicherheit (Hardening) - -Da der Server im Netzwerk hängt, sichern wir den Zugang ab. - -### 3.1 Neuer Admin-User (falls noch nicht geschehen) -Vermeide die Nutzung von `root` oder Standard-Usern wie `admin`/`user`. - -```bash -# Ersetze 'meldestelle-admin' mit deinem Wunschnamen -sudo adduser meldestelle-admin -sudo usermod -aG sudo meldestelle-admin -``` - -### 3.2 SSH Absichern -*Hinweis: Führe dies erst aus, wenn du dich mit dem neuen User erfolgreich eingeloggt hast!* - -Editiere `/etc/ssh/sshd_config`: -```ssh -PermitRootLogin no -PasswordAuthentication yes # Später auf 'no' setzen, wenn SSH-Keys eingerichtet sind! -``` -Neustart: `sudo systemctl restart ssh` - -### 3.3 Firewall (UFW) -Wir erlauben vorerst nur SSH und später HTTP/HTTPS. - -```bash -sudo ufw default deny incoming -sudo ufw default allow outgoing -sudo ufw allow ssh -sudo ufw enable -``` - -## 4. Virtualisierung: Incus Installation - -Wir nutzen **Incus** (Community Fork von LXD) für Container und VMs. Da Debian 12 Incus nicht in den Standard-Repos hat, nutzen wir das Zabbly-Repository (Standard für Incus). - -### 4.1 Repository hinzufügen - -```bash -# Keyring Verzeichnis erstellen -sudo mkdir -p /etc/apt/keyrings/ - -# GPG Key herunterladen -sudo curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc - -# Repository hinzufügen -sudo sh -c 'cat < /etc/apt/sources.list.d/zabbly-incus-stable.sources -Enabled: yes -Types: deb -URIs: https://pkgs.zabbly.com/incus/stable -Suites: $(. /etc/os-release && echo ${VERSION_CODENAME}) -Components: main -Architectures: $(dpkg --print-architecture) -Signed-By: /etc/apt/keyrings/zabbly.asc - -EOF' -``` - -### 4.2 Installation - -```bash -sudo apt update -sudo apt install -y incus -``` - -### 4.3 User zur Gruppe hinzufügen - -Damit du `incus` ohne `sudo` nutzen kannst: - -```bash -sudo usermod -aG incus-admin meldestelle-admin -newgrp incus-admin -``` - -### 4.4 Initialisierung (Mit Workaround für Vendor Kernel) - -⚠️ **ACHTUNG:** Der Vendor-Kernel (`6.6.10-cix-build-generic`) scheint wichtige Firewall-Module (`nf_tables`) zu vermissen. Das Standard-Setup von Incus schlägt daher fehl. - -Wir müssen die Netzwerk-Brücke während der Initialisierung **deaktivieren** und später manuell konfigurieren. - -Führe `incus admin init` erneut aus und antworte wie folgt: - -```text -Would you like to use clustering? (yes/no) [default=no]: no -Do you want to configure a new storage pool? (yes/no) [default=yes]: yes -Name of the new storage pool [default=default]: default -Name of the storage backend to use (dir, truenas) [default=dir]: dir -Where should this storage pool store its data? [default=/var/lib/incus/storage-pools/default]: (Enter drücken) -Would you like to create a new local network bridge? (yes/no) [default=yes]: no <-- WICHTIG! -Would you like the server to be available over the network? (yes/no) [default=no]: no -Would you like stale cached images to be updated automatically? (yes/no) [default=yes]: yes -Would you like a YAML "init" preseed to be printed? (yes/no) [default=no]: no -``` - -### 4.5 Netzwerk Konfiguration (Macvlan) - -Da wir keine Bridge erstellen können, nutzen wir **Macvlan**. Das bedeutet, jeder Container bekommt eine eigene IP-Adresse direkt von deinem Router (FritzBox). Das ist für einen Home-Server oft sogar praktischer. - -1. **Kernel-Modul laden (WICHTIG):** - Der Vendor-Kernel lädt `macvlan` nicht automatisch. - ```bash - sudo modprobe macvlan - echo "macvlan" | sudo tee -a /etc/modules - ``` - -2. **Netzwerk-Interface finden:** - Führe `ip -br a` aus. Suche das Interface mit deiner IP (z.B. `eth0`, `enP4p1s0` o.ä.). Ignoriere `lo`, `docker0` etc. - -3. **Profil anpassen:** - Ersetze `` im folgenden Befehl mit dem Namen aus Schritt 2 (z.B. `eth0`). - - ```bash - # Füge das Netzwerk-Device zum default Profil hinzu - incus profile device add default eth0 nic nictype=macvlan parent= - ``` - -4. **Test:** - Starte einen Test-Container: - ```bash - incus launch images:debian/12 test-container - incus list - # Sollte eine IP aus deinem Heimnetz (192.168.178.xxx) haben. - ``` - -## 5. Nächste Schritte - -Nachdem der Host vorbereitet ist, werden wir gemäß Roadmap folgende Instanzen erzeugen: - -1. **Gitea Container:** `incus launch images:debian/12 infra-gitea` -2. **Docker Host VM:** `incus launch images:debian/12 docker-host-prod --vm` - -Bitte melde zurück, wenn Schritt 1-4 erfolgreich waren oder ob Fehler (z.B. fehlendes `/dev/kvm`) aufgetreten sind. +Bitte beziehe dich für die aktuelle Konfiguration auf: +`docs/01_Architecture/Minisforum-MS-R1/MS-R1_Konfiguration&Bedienung.md` diff --git a/docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Services.md b/docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Services.md index ee96ba14..73f66637 100644 --- a/docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Services.md +++ b/docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Services.md @@ -1,141 +1,8 @@ # Setup Guide: Infrastructure Services (Minisforum MS-R1) -**Status:** DRAFT -**Date:** 2026-02-07 -**Context:** Host OS (Debian 12 ARM64) ist vorbereitet, Incus läuft mit Macvlan. +**Status:** DEPRECATED / HISTORIC +**Date:** 2026-02-08 +**Note:** Dieses Dokument beschreibt einen alternativen Ansatz. Das produktive System läuft gemäß `MS-R1_Konfiguration&Bedienung.md`. -Dieses Dokument beschreibt die Installation der beiden Haupt-Komponenten: -1. **infra-gitea:** Ein leichtgewichtiger Git-Server (LXC Container). -2. **docker-host-prod:** Die Produktions-Umgebung für die Meldestelle-App (Incus VM). - ---- - -## 1. Gitea Container (`infra-gitea`) - -Wir nutzen einen LXC-Container, da Gitea sehr ressourcensparend ist. - -### 1.1 Container starten - -```bash -# Starten des Containers -incus launch images:debian/12 infra-gitea - -# Warten bis er eine IP hat -incus list infra-gitea -``` - -### 1.2 Gitea Installation - -Wir installieren Gitea manuell als Binary, um die volle Kontrolle zu haben. - -1. **In den Container einloggen:** - ```bash - incus shell infra-gitea - ``` - -2. **Abhängigkeiten installieren (im Container):** - ```bash - apt update && apt install -y git wget gnupg2 - ``` - -3. **Git-User anlegen:** - ```bash - adduser --system --shell /bin/bash --gecos 'Git Version Control' --group --disabled-password git - ``` - -4. **Gitea Binary herunterladen (ARM64):** - ```bash - wget -O /usr/local/bin/gitea https://dl.gitea.com/gitea/1.21.4/gitea-1.21.4-linux-arm64 - chmod +x /usr/local/bin/gitea - ``` - -5. **Verzeichnisse erstellen:** - ```bash - mkdir -p /var/lib/gitea/{custom,data,log} - chown -R git:git /var/lib/gitea/ - chmod -R 750 /var/lib/gitea/ - mkdir /etc/gitea - chown root:git /etc/gitea - chmod 770 /etc/gitea - ``` - -6. **Systemd Service anlegen:** - Erstelle die Datei `/etc/systemd/system/gitea.service`: - *(Inhalt siehe unten)* - - ```ini - [Unit] - Description=Gitea (Git with a cup of tea) - After=syslog.target - After=network.target - - [Service] - RestartSec=2s - Type=simple - User=git - Group=git - WorkingDirectory=/var/lib/gitea/ - ExecStart=/usr/local/bin/gitea web --config /etc/gitea/app.ini - Restart=always - Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea - - [Install] - WantedBy=multi-user.target - ``` - -7. **Service starten:** - ```bash - systemctl enable --now gitea - systemctl status gitea - ``` - -8. **Setup abschließen:** - Öffne im Browser: `http://:3000` - ---- - -## 2. Docker Host VM (`docker-host-prod`) - -Wir nutzen eine **VM** (Virtual Machine) statt eines Containers für Docker. Das bietet bessere Isolation und vermeidet Probleme mit "Docker-in-LXC" (Nesting, OverlayFS). - -### 2.1 VM starten - -*Hinweis: VMs brauchen etwas länger zum Starten als Container.* - -```bash -# Starten der VM (mit 4 vCPUs und 8GB RAM als Startwert) -incus launch images:debian/12 docker-host-prod --vm -c limits.cpu=4 -c limits.memory=8GiB - -# Warten bis sie eine IP hat (kann 1-2 Minuten dauern beim ersten Mal) -incus list docker-host-prod -``` - -### 2.2 Docker Installation - -1. **In die VM einloggen:** - ```bash - incus shell docker-host-prod - ``` - -2. **Docker installieren (Offizielles Skript):** - ```bash - curl -fsSL https://get.docker.com -o get-docker.sh - sh get-docker.sh - ``` - -3. **User-Rechte:** - Da wir in der Incus-Shell als `root` sind, passt das erst mal. Für später (SSH-Zugriff) sollte man einen User anlegen. - -4. **Test:** - ```bash - docker run --rm hello-world - ``` - ---- - -## 3. DNS / Erreichbarkeit (Optional aber empfohlen) - -Da wir Macvlan nutzen, haben die Instanzen IPs aus dem Heimnetz (z.B. `10.0.0.x`). -Es empfiehlt sich, im Router (FritzBox) einzustellen: -* "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen." -* Ggf. lokale DNS-Namen vergeben (z.B. `gitea.local`, `docker.local`). +Bitte beziehe dich für die aktuelle Konfiguration auf: +`docs/01_Architecture/Minisforum-MS-R1/MS-R1_Konfiguration&Bedienung.md`