mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

chore(docs): add detailed MS-R1 roadmap, SSH setup guide, and archive outdated setup docs

Browse Source 
- Added "Biest Roadmap" covering Gitea infrastructure phases and tasks.
- Documented SSH client setup for Gitea integration with Cloudflare Tunnel.
- Archived outdated host setup and service configuration guides (`Setup_Guide_Services.md`, `Setup_Guide_Host_OS.md`).
- Introduced a centralized configuration and operational guideline (`MS-R1_Konfiguration&Bedienung.md`).
This commit is contained in:
Stefan Mogeritsch
2026-02-09 00:35:41 +01:00
parent c50acd641e
commit f79b14348b
5 changed files with 318 additions and 329 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/01_Architecture/Minisforum-MS-R1/Biest_Roadmap.md
+25
View File
@@ -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.
docs/01_Architecture/Minisforum-MS-R1/Gitea-SSH-Setup.md
+81
View File
@@ -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.
docs/01_Architecture/Minisforum-MS-R1/MS-R1_Konfiguration&Bedienung.md
+202
View File
@@ -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`
docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Host_OS.md
+5 -191
View File
@@ -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 <user>@<ip-adresse>
# 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 <<EOF > /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 `<INTERFACE>` 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=<INTERFACE>
```
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`
docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Services.md
+5 -138
View File
@@ -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://<IP-VON-INFRA-GITEA>: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`