Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
09aaf1b2b5 | ||
|
|
337dbe85ac | ||
|
|
e462980dac | ||
|
|
79db6a8e49 | ||
|
|
25d1742d61 |
@@ -74,7 +74,7 @@ spec:
|
||||
image:
|
||||
registry: rohana.axion1337.de
|
||||
repository: sorb/threadnet-web
|
||||
tag: v0.2.1-elementcall-noquotavp9
|
||||
tag: v0.2.3-elementcall-h264
|
||||
ingress:
|
||||
host: axion1337.chat
|
||||
|
||||
|
||||
+26
-40
@@ -53,10 +53,21 @@ verankert. Was in dieser Session erledigt wurde:
|
||||
5. **NetworkPolicies** (Issue #10 ✅ geschlossen) — siehe "Network Security" Abschnitt unten.
|
||||
Zwei Live-Incidents beim Rollout (Port-Verwechslungen), beide binnen Minuten live gepatcht
|
||||
und danach committed. Nebenbei: `matrixRTC`-Authorisation-Service OOM-Fix (20Mi→128Mi).
|
||||
6. **Element Call Qualität nachgeschärft** — 720p-Zwischen-Simulcast-Layer ergänzt (sonst
|
||||
harter Sprung von 1440p auf blockiges 360p bei kleinsten Netzwerkschwankungen), und
|
||||
`video_codec: h264` statt VP8 (klassisches Simulcast wie VP8, kein SVC-Risiko wie bei
|
||||
VP9, oft hardwarebeschleunigt v.a. auf iOS). Live verifiziert: 7/8 Tracks nativ H.264,
|
||||
1 sauberer VP8-Fallback. Deployed als `v0.2.3-elementcall-h264`.
|
||||
7. **Backlog nach Gitea migriert** — restlicher offener Backlog (VP9-Retry, ThreadNet-Web-Bug,
|
||||
MAS-Template-Link, WAF und 17 weitere Security-/Infra-Punkte) als Issues #11–#31 angelegt,
|
||||
veraltete erledigte Punkte (Authentik Stage 2/E2E-Test/Invite-Links, Hetzner-Firewall,
|
||||
SSH-Hardening) aus dieser Datei entfernt bzw. als done markiert.
|
||||
|
||||
### Offene Punkte
|
||||
- **VP9-Retry**: Root Cause des Call-Ausfalls isolieren (Browser-Konsolen-Repro nötig), bevor
|
||||
wieder versucht wird — siehe Backlog "Element Call Enhancement".
|
||||
- **VP9-Retry**: vermutete Ursache jetzt bekannt (LiveKit nutzt SVC für vp9/av1, Fork-Code
|
||||
setzt aber immer Simulcast-Layer) — braucht einen Code-Fix in `buildPublishOptions()`
|
||||
(`src/livekit/options.ts`) bevor erneut versucht wird. Stattdessen H.264 probiert (siehe
|
||||
unten) — läuft gut, kein SVC-Risiko, hardwarebeschleunigt auf mehr Geräten.
|
||||
- **`ThreadNet-Web` Build-Bug**: `scripts/docker-link-repos.sh`/`docker-package.sh` nicht
|
||||
ausführbar committet + veralteter `matrix-js-sdk#develop`-Pin im Lockfile blockiert
|
||||
vollständigen Neu-Build des Web-Forks. Noch nicht gefixt, User hat noch nicht final
|
||||
@@ -259,31 +270,22 @@ verankert. Was in dieser Session erledigt wurde:
|
||||
- [x] **matrix-recovery Flow gebaut** – war komplett leer (0 Stages); Passwort-Reset funktioniert jetzt, verlinkt von der echten Login-Seite
|
||||
- [x] **Brand.default_application gesetzt** – behebt mehrere Dead-Ends, wenn eingeloggte User `/` ohne Ziel aufrufen
|
||||
- [x] **2FA/Passkey Selbst-Einrichtung** – Links zu `default-authenticator-totp-setup`/`-webauthn-setup` (2FA bleibt optional, `not_configured_action=skip`), dokumentiert unter `axion1337.chat/docs/setup/security.html`
|
||||
- [ ] **Backlog**: MAS Custom-Template-Override, um den 2FA/Passkey-Link direkt auf `account.axion1337.chat/account/` anzuzeigen (statt nur über die Doku-Seite) – erfordert Forken der MAS Tera/Askama-Templates via `templates.path`, höherer Aufwand/Risiko, bei MAS-Updates zu pflegen
|
||||
- [ ] **Backlog**: → **Issue #13** (MAS Custom-Template-Override für 2FA/Passkey-Link auf `account.axion1337.chat/account/`)
|
||||
|
||||
---
|
||||
|
||||
## 📋 Backlog (Weitere Aufgaben)
|
||||
|
||||
### Authentik Completion
|
||||
- [ ] **Finish Authentik Stage 2 – MAS Integration**
|
||||
- Prerequisites: Authentik OIDC Provider vollständig konfiguriert
|
||||
- Task: Update `mas-secret.yaml`, enable password login disable
|
||||
- Commit: `enable-authentik-oidc-integration-in-mas`
|
||||
- Est. Effort: 30 min (manual + scripted)
|
||||
|
||||
- [ ] **Test End-to-End Login Flow**
|
||||
- Element Web login → MAS → Authentik → Matrix User Creation
|
||||
- Create test users via Authentik
|
||||
- Verify password reset flow
|
||||
- Commit: (implicit in Stage 2)
|
||||
- Est. Effort: 20 min
|
||||
|
||||
- [ ] **Create Invite Links für neue User**
|
||||
- Authentik Admin UI → Invitations → Create
|
||||
- Set expiry dates (7d) + use limits
|
||||
- Document procedure
|
||||
- Est. Effort: 15 min
|
||||
**Ab 2026-07-28 in Gitea-Issues gepflegt statt hier** (eine Quelle der Wahrheit) — offene Issues:
|
||||
[#6](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/6) DB-Backup-Strategie,
|
||||
[#9](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/9) Externe PostgreSQL-Migration,
|
||||
[#11](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/11)–[#31](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/31)
|
||||
(VP9-Retry, ThreadNet-Web-Build-Bug, MAS-Template-Link, WAF, Media-PVC-Backups, Pod Security
|
||||
Admission, Federation-Allowlist, Mjolnir/Draupnir, Content-Scanner, External-Secrets,
|
||||
Renovate/Trivy, Security-Advisory-Monitoring, automountServiceAccountToken,
|
||||
unattended-upgrades, K3s-API-Security, auditd, Kernel-Hardening, Lynis, CrowdSec, Falco).
|
||||
Die detaillierten Beschreibungen unten sind das historische Original, aus dem die Issues
|
||||
entstanden sind — nicht mehr getrennt pflegen, stattdessen die Issues aktuell halten.
|
||||
|
||||
### Element Call Enhancement
|
||||
- [x] **Element Call Fork für Custom Constraints** (2026-07-28, Closes #8)
|
||||
@@ -448,24 +450,8 @@ verankert. Was in dieser Session erledigt wurde:
|
||||
## 🔒 Security Hardening (Host & Cluster Level)
|
||||
|
||||
### Host OS Layer (Ubuntu/Debian)
|
||||
- [ ] **Hetzner Cloud Firewall**
|
||||
- Default-Deny inbound
|
||||
- Allow: 80/443 (HTTP/HTTPS)
|
||||
- Allow: 22 (SSH) from your IP only (or via WireGuard/Tailscale)
|
||||
- Status: ✅ Can be done in Hetzner UI
|
||||
- Est. Effort: 30 min
|
||||
- Priority: **CRITICAL** (immediate, zero config cost)
|
||||
|
||||
- [ ] **SSH Hardening**
|
||||
- Disable password auth (key-only)
|
||||
- Disable root login
|
||||
- PermitRootLogin: no
|
||||
- PasswordAuthentication: no
|
||||
- MaxAuthTries: 3
|
||||
- Optional: Change SSH port (cosmetic, reduces log noise)
|
||||
- Optional: SSH hinter WireGuard/Tailscale (eliminates fail2ban für SSH)
|
||||
- Est. Effort: 2 hours
|
||||
- Priority: **HIGH** (immediate)
|
||||
- [x] **Hetzner Cloud Firewall** – Default-Deny inbound, siehe "Phase 7" oben. **Done.**
|
||||
- [x] **SSH Hardening** – Key-only, Root-Login disabled, Port 2248, siehe "Phase 7" oben. **Done.**
|
||||
|
||||
- [ ] **unattended-upgrades**
|
||||
- Enable automatic security updates
|
||||
|
||||
@@ -57,9 +57,16 @@
|
||||
LiveKits eigener Empfehlung für Mensch-zu-Mensch-Calls. Bewusst **kein** server-seitiges
|
||||
ML-Noise-Cancellation (siehe `docs/TASKS.md` Backlog).
|
||||
- **Incident (2026-07-28)**: Erster Versuch mit erzwungenem `video_codec: vp9` hat Calls
|
||||
komplett kaputt gemacht (kein Bild/Ton). Sofort zurückgerollt, dann ohne erzwungenen Codec
|
||||
(Standard VP8) mit denselben Auflösungswerten neu deployed — funktioniert, live bestätigt.
|
||||
VP9 vorerst zurückgestellt (Backlog).
|
||||
komplett kaputt gemacht (kein Bild/Ton). Sofort zurückgerollt. Vermutete Ursache: LiveKit
|
||||
nutzt für vp9/av1 SVC statt klassischem Simulcast, `buildPublishOptions()` im Fork setzt
|
||||
aber immer Simulcast-Layer — Code-Fix nötig, bevor vp9 erneut versucht wird (Backlog).
|
||||
- **720p-Zwischen-Layer ergänzt** (`simulcast_layers`) — ohne eigene Definition fiel die
|
||||
Übertragung bei kleinsten Netzwerkschwankungen direkt von 1440p auf blockiges 360p, jetzt
|
||||
sanftere Abstufung über 720p.
|
||||
- **H.264 statt VP8** (2026-07-28) — nutzt wie VP8 klassisches Simulcast (kein SVC-Risiko wie
|
||||
bei VP9), zusätzlich auf vielen Geräten (v.a. iOS/Safari) hardwarebeschleunigt. Live
|
||||
verifiziert: 7 von 8 Video-Tracks liefen über H.264, 1 fiel sauber auf den VP8-Backup-Codec
|
||||
zurück (kein Ausfall). Deployed als `v0.2.3-elementcall-h264`.
|
||||
- Deployt als `rohana.axion1337.de/sorb/threadnet-web:v0.2.1-elementcall-noquotavp9` — nur
|
||||
der `/app/widgets/element-call/`-Ordner im bestehenden `v0.1.0`-Image ausgetauscht, da
|
||||
`ThreadNet-Web` einen vorbestehenden Build-Bug hat (siehe unten).
|
||||
|
||||
Regular → Executable
+29
-1
@@ -75,4 +75,32 @@ flux get helmreleases -n matrix --watch
|
||||
# Zeigt, wie die Pods hochfahren:
|
||||
kubectl get pods -n matrix -w
|
||||
```
|
||||
Sobald alle Pods auf `Running` stehen und die Zertifikate über Let's Encrypt validiert wurden (`kubectl get certificate -n matrix`), ist dein Matrix-Stack unter `https://axion1337.chat` erreichbar.
|
||||
Sobald alle Pods auf `Running` stehen und die Zertifikate über Let's Encrypt validiert wurden (`kubectl get certificate -n matrix`), ist dein Matrix-Stack unter `https://axion1337.chat` erreichbar.
|
||||
|
||||
---
|
||||
|
||||
## 🔁 Recovery: lokalen age-Key wiederherstellen (Server läuft bereits)
|
||||
|
||||
Anders als Schritt 2 oben (neuen Key **erzeugen**) — falls der Server bereits läuft und nur der
|
||||
lokale Rechner den age-Key verloren hat (z.B. nach einer Neuinstallation), lässt sich der
|
||||
**bestehende** Private Key direkt aus dem Cluster zurückholen, ohne einen neuen zu generieren
|
||||
(das würde `.sops.yaml` und alle bereits verschlüsselten Secrets ungültig machen):
|
||||
|
||||
```bash
|
||||
mkdir -p ~/.age
|
||||
kubectl get secret sops-age -n flux-system -o jsonpath='{.data.age\.agekey}' | base64 -d > ~/.age/keys.txt
|
||||
chmod 600 ~/.age/keys.txt
|
||||
|
||||
# Public Key zur Kontrolle gegen .sops.yaml abgleichen:
|
||||
grep 'public key:' ~/.age/keys.txt
|
||||
grep 'age:' .sops.yaml
|
||||
```
|
||||
|
||||
Voraussetzung: laufender Kubeconfig-Zugriff auf den Cluster (siehe Schritt 1 oben — auch das
|
||||
ist reines Zurückkopieren, kein Neu-Erzeugen).
|
||||
|
||||
**Bekannte Schwachstelle**: Dieser Key existiert aktuell nur an zwei Orten — im
|
||||
`sops-age`-Secret selbst (auf demselben Server) und lokal bei wem auch immer ihn zuletzt
|
||||
zurückgeholt hat. Es gibt kein separates, offsite Backup. Fällt der Server komplett aus
|
||||
(nicht nur der lokale Rechner), sind alle SOPS-verschlüsselten Secrets im Repo unlesbar.
|
||||
Siehe Issue-Backlog für die Entscheidung, ob/wie das abgesichert wird.
|
||||
Reference in New Issue
Block a user