chahinebrini d65ba84eb1 feat(binder): MDMClient, EnrollView improvements + supervise flow_backup
- MDMClient: error handling verbessert
- SuperviseRunner: robustere EOF-nach-Success Erkennung
- EnrollView: Enrollment-Status-Polling, Retry-Logik
- SuperviseView: UX-Verbesserungen
- ConfigureView: minor cleanup
- flow_backup.go: backup flow für supervise-magic

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-01 04:30:28 +02:00
..

ReBreak MDM — Projektübersicht

Was ist das

MDM steht für Mobile Device Management. Dieses Projekt setzt einen selbst-gehosteten MDM-Server (NanoMDM) auf, der ein iPhone dauerhaft unter Supervision halten kann — mit dem Ziel, dass der Nutzer (Chahine) eine Spiel-Blockade nicht ohne Aufwand umgehen kann.

Das Szenario: Chahine enrolled sein iPhone freiwillig in das MDM-Profil (self-binding). Das Profil kann er nicht selbst entfernen, weil dafür ein Admin-PIN oder die Zustimmung eines Trustees nötig ist. Die Trustees sind Olfa und Ina Wittek.

Kein Enterprise-MDM. Kein Firmenzweck. Kein App-Store-Management. Ausschließlich: Entfernung des MDM-Profils blockieren.

Warum getrennter VPS

Der MDM-Server läuft auf einem separaten Hetzner-VPS (rebreak-mdm, 178.105.101.137), getrennt von rebreak-server (49.13.55.22, Nuxt-App). Gründe:

  • Kein Crossover-Risiko: ein Deploy-Fehler auf dem App-Server betrifft nicht den MDM-Server
  • Unabhängige Uptime: MDM muss laufen auch wenn die App deployed wird
  • Klarere Verantwortung: MDM-Server hat keine App-Logik, nur nanomdm + postgres + nginx

Architektur

[Chahines iPhone]
     |
     |-- NEFilter (ReBreak iOS App, anderer Scope)
     |   Blockiert Gambling-Domains via Network Extension
     |
     |-- MDM-Profil (dieser Server)
         Verhindert Entfernung der App ohne Admin-Zustimmung
         |
         v
[mdm.rebreak.org] (178.105.101.137)
     |
     +-- nginx (443 SSL) --> nanomdm (127.0.0.1:9000)
                                  |
                                  v
                          postgres (127.0.0.1:5432)
                          DB: nanomdm, User: nanomdm

Apple-Push-Zertifikat-Flow:

[Server: push.csr]  -->  [identity.apple.com]  -->  [push.pem download]
                                                           |
                                                    [scp push.pem to server]
                                                           |
                                                    [nanomdm benutzt push.pem
                                                     um Apple APNS zu erreichen
                                                     = MDM-Befehle ans Gerät]

Trust-Modell

  • Chahine: Gerät-Owner, enrolled sich selbst. Hat keinen MDM-Admin-Zugriff (Sinn der Sache).
  • Olfa: Co-Admin. Hat Zugriff zu MDM-Credentials (in /opt/nanomdm/ auf dem Server).
  • Ina Wittek (ina.wittek@gmx.de): Trustee. Bekommt per Email einen Notfall-Schlüssel, mit dem sie das MDM-Profil entfernen kann falls Chahine z.B. das Gerät für dringende Arbeit braucht und weder er noch Olfa erreichbar sind.

Factory-Reset = nuclear option. Zerstört alle Daten. Sollte nur als letztes Mittel genutzt werden.

Status

  • Phase A Server-Bootstrap
  • Phase B TLS-Zertifikat
  • Phase C NanoMDM container + nginx
  • Phase D Apple Push CSR generiert — Benutzeraktion ausstehend
  • Phase E Email an Ina (blocked: Apple-cert + Resend-key fehlen)
  • Phase F Device-Enrollment (factory-reset + USB-Supervision + Profil-Installation)

Details in PHASES.md.