# Flatpak-Mirror (Test-Setup mit Docker Compose)

Kuratiertes Flatpak-Repo: spiegelt nur die in `config/apps.yaml` freigegebenen
Apps von Flathub und stellt sie über nginx bereit. Kein flat-manager nötig.

## Schnellstart (lokale apps.yaml, ohne Git)

```bash
docker compose up -d --build
```

- `sync`-Container klont/pullt nichts von Git (solange `GIT_REPO_URL` leer ist),
  sondern liest direkt `config/apps.yaml` (read-only gemountet).
- Beim ersten Lauf: OSTree-Repo wird angelegt, Flathub-Remote eingerichtet,
  die drei Beispiel-Apps werden gepullt. Das kann je nach App-Größe einige
  Minuten dauern (Firefox, LibreOffice sind groß).
- Logs verfolgen: `docker compose logs -f sync`
- Repo ist danach erreichbar unter `http://localhost:8080`

## Mit Git-Repo für die apps.yaml

1. `.env.example` nach `.env` kopieren:
   ```bash
   cp .env.example .env
   ```
2. In `.env` mindestens `GIT_REPO_URL` setzen (öffentliches Repo reicht das
   schon aus). `GIT_BRANCH` bei Bedarf anpassen (Standard: `main`).
3. **Nur bei privaten Repos:** zusätzlich `GIT_USERNAME` und `GIT_TOKEN`
   setzen. Als `GIT_TOKEN` ein Personal Access Token verwenden (nicht das
   echte Account-Passwort!) – erzeugbar unter den Account-Einstellungen von
   Gitea/GitHub/GitLab, idealerweise mit nur Lese-Rechten auf das eine Repo.

`.env` wird per `.gitignore` von Git ignoriert – nie versehentlich committen.
Das Repo braucht im Root eine `apps.yaml` mit der gleichen Struktur wie in
`config/apps.yaml`. Der `./config`-Mount kann dann entfernt werden (oder
bleibt einfach ungenutzt, `GIT_REPO_URL` hat Vorrang).

**Sicherheitshinweis zum Token:** Es wird nie in die Git-URL eingebettet
(`https://user:token@host/...`), da URLs in Logs auftauchen können. Stattdessen
übergibt `sync.sh` das Token über `GIT_CONFIG_*`-Umgebungsvariablen an git,
sodass es auch nicht als Kommandozeilenargument sichtbar ist (z. B. über
`ps aux` auf dem Docker-Host). Es steht dennoch im Container-Environment und
in `.env` im Klartext – Zugriff auf den Docker-Host und die `.env`-Datei
entsprechend absichern (Dateiberechtigungen, kein Checkout in ein öffentlich
lesbares Verzeichnis).

## Client testen

Auf einer Test-Maschine mit Flatpak installiert:

```bash
flatpak remote-add --no-gpg-verify test-repo http://<server-ip>:8080
flatpak install test-repo org.mozilla.firefox
```

`--no-gpg-verify` ist nur für den lokalen Test ok — die Original-Signaturen
von Flathub werden zwar mitkopiert, aber ohne den Flathub-Key im Client ist
Verifizierung sonst nicht möglich. Für den Produktivbetrieb solltest du
`ostree remote add` bzw. `flatpak remote-add` mit dem echten Flathub-GPG-Key
konfigurieren, statt `--no-gpg-verify` zu verwenden.

## Apps hinzufügen/entfernen

Einfach `config/apps.yaml` (oder die Datei im Git-Repo) bearbeiten. Der
Sync-Container prüft alle `SYNC_INTERVAL_SECONDS` (Standard: 900 = 15 Min.)
erneut und pullt neue Einträge bzw. löscht entfernte Refs automatisch.

Für einen sofortigen Testlauf, statt zu warten:

```bash
docker compose restart sync
```

## Nächste Schritte für den Produktivbetrieb

- Sync über Webhook statt reinem Interval-Polling triggern
- Shared Volume durch echtes Kubernetes-PVC (ReadWriteMany) oder S3 ersetzen
- Monitoring/Alerting auf Sync-Fehler
- Bei Bedarf später flat-manager vor dieses Repo setzen (siehe Chat-Verlauf)