iris/Iris
1
0
Fork 0
Code Issues 23 Pull requests Projects Releases Packages Wiki Activity Actions

Eigener Forgejo auf jeder Iris-Installation (Git-Server) #112

New issue
Closed
opened 2026-10-20 09:24:30 +00:00 by alf · 45 comments
alf commented 2026-10-20 09:24:30 +00:00
Owner
Copy link

Jede Iris-Installation bringt standardmäßig einen eigenen, kleinen Forgejo (Git-Server) mit. Er löst das Henne-Ei-Problem des Vault-Syncs (iris/Iris#76: „Woher kommt der Forgejo bei einer Neuinstallation?“) und ist später der Test-Forgejo für das Plugin iris-dev. Ergebnis einer Grill-me-Runde am 2026-10-20; Entwurf und Hintergrund: Plan VAULT-SYNC.md §7a.

Grundidee und Rollen

  • Jede Installation hat einen eigenen Forgejo, immer installiert und dauernd laufend: Mac per Homebrew (brew install forgejo) als Hintergrunddienst (launchd), ohne Docker; Linux als weiterer Compose-Dienst forgejo (in docker-compose.yml und der Deploy-Vorlage).
  • Es gibt keine feste Rolle „Haupt-Rechner“. Das Vault zeigt auf das Ziel, das der Nutzer im Vault-Schritt wählt. Im Onboarding gilt (Entscheidung 2026-10-20): vier Wege (Neues Default-Vault, Neues Vault mit KI-Einrichtung, Aus Backup zurücklesen, Mit anderem Vault verbinden), der lokale Forgejo läuft immer, und nach dem Vault-Schritt ist Iris immer mit einem Forgejo verbunden (neu/zurückgelesen/vorhanden ohne Remote → automatisch lokal; nur „Mit anderem Vault verbinden“ → Forgejo remote). Das Sheet „Vault verbinden“ in den Einstellungen (vorhandenes Vault) bietet zwei Karten:
    • „Dieser Rechner“: ein Klick, Iris legt iris-vault an und veröffentlicht das Vault, ohne dass der Nutzer etwas eintippt.
    • „Anderer Forgejo“: das bisherige Formular (Adresse, Benutzer, Passwort, Repository wählen). Ein anderer Iris-Rechner und ein Forgejo im Internet sind dasselbe Formular.
  • Der Forgejo eines Rechners, der nicht Ziel des Vaults ist (z. B. des Notebooks), hat mit dem Vault-Sync nichts zu tun (Entwicklung, iris-dev, eigene Test-Repositories).

Zugang und Sicherheit

  • Iris erzeugt das Admin-Passwort und legt es ab (Mac: 0600-Datei Application Support/Iris/forgejo-admin.json, kein Schlüsselbund – keine automatisierten Schlüsselbund-Aufrufe; Linux: verschlüsselter Secret-Store). „Zugangsdaten anzeigen“ gibt es nur auf Knopfdruck, nie automatisch. (Abweichung: eine einmalige Anzeige bei der Einrichtung gibt es nicht.)
  • Erreichbarkeit: standardmäßig nur 127.0.0.1 (http://127.0.0.1:3300). Ein Schalter „Für andere Rechner freigeben“ stellt den Forgejo um auf HTTPS, alle Schnittstellen und die Adresse https://<rechnername>.local:3300 und zieht die Adresse des Vault-Remotes mit (gemessen: Forgejo schreibt die ROOT_URL fest in die LFS-Links, darum muss die Adresse zum erreichbaren Namen passen; Entscheidung des Nutzers „Umschalten + Adresse mitziehen“). Linux: Freigabe nur von Hand (Compose-Port), Route antwortet 409 sharing_unsupported.
  • Verschlüsselung: HTTPS mit einem Zertifikat der Iris-eigenen CA (Rechnername und IP). Beim ersten Verbinden zeigt Iris den Fingerabdruck zur Bestätigung (wie beim Koppeln der Iris-Server) und hinterlegt die CA nur für diese Adresse in git (http.<adresse>.sslCAInfo).
  • Jeder verbundene Rechner bekommt ein eigenes, nach dem Rechner benanntes Token („Iris Vault-Sync – ()“). In den Einstellungen: „Verbundene Rechner“ mit letzter Nutzung und „Zugang entziehen“ (widerruft das Token). Nur für den internen Forgejo; bei fremden Forgejos bleibt es beim Namen dort.

Oberfläche (erster Wurf: Iris und IrisClient, iOS später)

  • Neue Wire-Routen /forgejo/* (Bearer, auf beiden Servern gleich): Status, Freigabe an/aus, Zugangsdaten, verbundene Rechner, Widerruf, Einrichtung.
  • Einstellungen „Git-Server“: Status, Freigabe, Zugangsdaten anzeigen, Verbundene Rechner, Web-Interface eingebettet in Iris (Web-View). Anmeldung: Iris schickt den Anmelde-Aufruf von Forgejo selbst ab (Zugangsdaten aus dem Secret-Store, nur im Speicher) und gibt das Sitzungs-Cookie an die Web-View mit nicht persistentem Datenspeicher. Zertifikat wie bei der HTML-Vorschau (Fingerabdruck der Iris-CA).
  • Vault-Schritt im Onboarding und Sheet „Vault verbinden“ (Mac, Client, iOS): zwei Karten wie oben. iOS behält zunächst nur das bestehende „Vault verbinden“.
  • Nutzertexte ohne Git-Jargon: „Git-Server“, „Vault bereitstellen“, „Verbundene Rechner“.

Betrieb

  • Datenort: Mac ~/Library/Application Support/Iris/forgejo, Linux <IRIS_DOCKER_DIR>/data/forgejo. Vor dem Veröffentlichen prüft Iris den freien Platz gegen die Vault-Größe und warnt klar. In den Einstellungen verschiebbar (Mac: der Standardordner wird ein Verweis auf den neuen Ort; Linux: Compose-Volume).
  • Backup (Mac): der ganze Ordner forgejo (Datenbank, Repositories, LFS) ist ausgeschlossen – er enthielte das Vault ein zweites Mal; im Backup bleiben Zugangsdaten, Iris-CA, gemerkte CAs und der Marker „Vault liegt auf dem eigenen Git-Server“. Nach einer Wiederherstellung baut Iris den Git-Server neu auf und veröffentlicht das Vault neu; Zugänge anderer Rechner sind danach widerrufen. (Abweichung: Datenbank mit Konten/Tokens und andere Repositories werden nicht gesichert.) Linux: Daten des Git-Servers sind nie Teil der Backup-Einheiten.
  • Versionen: nicht festnageln. Mac: Homebrew-Formel (zum Zeitpunkt der Prüfung 16.0.6, Release 17.0.0, der Dev-Server läuft mit 15.0.9); Linux: Compose-Tag folgt einer Hauptversion. Beim Verbinden liest Iris GET /api/v1/version und lehnt Versionen unter einer Mindestversion mit klarer Meldung ab.
  • Bestandsinstallationen: Linux: „Iris-Server aktualisieren“ ergänzt den Dienst wie bisher bei neuen Compose-Diensten, ohne Rückfrage. Mac: nach dem App-Update einmaliger Hinweis „Iris hat jetzt einen eigenen Git-Server. Jetzt einrichten?“ mit dem Fortschritt der Homebrew-Installation; ohne Zustimmung wird nichts installiert.
  • Festlegungen ohne Rückfrage (änderbar): fester Standardport (z. B. 3300, nicht 3000 wegen des bestehenden Forgejo; ist er belegt, sucht Iris einen freien); SSH im Forgejo aus, nur HTTPS; keine Selbstregistrierung, kein Gravatar, keine Update-Prüfung nach außen, keine Actions und kein Runner; ein einziges Admin-Konto, ein Repository iris-vault pro Rechner.

Tests

Ein echter Wegwerf-Forgejo für Integrationstests (leerer Datenordner, eigener Port; Linux/Dev-Host: Docker-Container, Mac: das Homebrew-Binary mit temporärem Verzeichnis): Ersteinrichtung (Admin, Repository, Token), Anmeldung mit Passwort und Zwei-Faktor, Token-Rechte, Klon und Push mit LFS, Widerruf, 404 bei fehlendem Anhang. Die bestehenden Attrappen-Tests bleiben für den schnellen Lauf. Das schließt die Lücke „Token-Erzeugung mit Passwort, Zwei-Faktor-Header (X-GITEA-OTP) und Token-Rechte nie gegen einen echten Forgejo gesehen“ aus #76.

Meilensteine (in dieser Reihenfolge, jeweils lauffähig und getestet)

  • M1 Linux-Kern: Compose-Dienst, automatische Ersteinrichtung (Admin, Repository, Token), Wire-Routen, Integrationstest gegen echten Wegwerf-Forgejo auf dem Dev-Host

  • M2 Mac: brew install forgejo im Onboarding bei den Abhängigkeiten, Hintergrunddienst (launchd), Ersteinrichtung, Vault-Weg „Dieser Rechner“ (inkl. Platzprüfung)

  • M3 Freigabe und Verbinden: Schalter „Für andere Rechner freigeben“, Iris-CA-Zertifikat, Fingerabdruck-Bestätigung, ein zweiter Rechner verbindet sich (Karte „Anderer Forgejo“ mit Mindestversion-Prüfung)

  • M4 Verwaltung: Einstellungen „Git-Server“ (Status, Zugangsdaten, Verbundene Rechner, Widerruf), eingebettete Web-View mit Auto-Anmeldung

  • M5 Backup und Bestand: Backup ohne Vault-Repository (inkl. Neuveröffentlichen nach Wiederherstellung), Hinweis für Mac-Bestandsinstallationen, Linux-Update

  • Datenort verschieben (Mac)

Offen (Stand 2026-10-20; Einzelheiten im Plan VAULT-SYNC.md §7a „Offene Punkte zum Git-Server“)

  • Abnahme durch den Nutzer: keine Oberfläche wurde bedient (Karten im Sheet, Fingerabdruck-Bestätigung, Einstellungen „Git-Server“, Datenort, Weboberfläche, Onboarding-Abhängigkeit, Hinweis-Dialog).
  • Nicht über echte Wege geprüft: zwei echte Rechner im LAN (Freigabe, .local, Klon über HTTPS), echte Wiederherstellung aus einem Backup-Zip, „Iris-Server aktualisieren“ auf einem Bestandsserver, Datenort auf eine externe Platte mit großem Bestand, Zwei-Faktor (X-GITEA-OTP), Forgejo-Major-Update per brew upgrade.
  • Bekannte Lücken: Zertifikat wird nicht bei Ablauf (800 Tage) oder Netzwechsel erneuert; nach einer Wiederherstellung Zugänge widerrufen und Freigabe zurückgesetzt; Linux: Freigabe/Datenort nur von Hand; Weboberfläche nur auf demselben Mac; iOS ohne Verwaltung.
  • Aus #76: LFS-Objekte fehlen auf dem echten Forgejo (git lfs push --all wartet auf Okay); Testmaschine mac-vm noch nicht neu verbunden.

Bewusst ausgeklammert

iOS-Verwaltung (später), Verbindungscode oder Liste gekoppelter Iris-Server (später als Komfort denkbar), Forgejo-Verbund mit gegenseitigen Mirrors, GitHub/GitLab als Ziel, alles was iris-dev vom Forgejo braucht (mehrere Konten, Organisationen).

Abnahmekriterien

  1. Auf einem frisch installierten Mac und einem frischen Linux-Server läuft ohne eine Handlung des Nutzers ein Forgejo. (Linux: auf dem Dev-Host belegt; Mac: Kern getestet, frische Maschine nicht.)
  2. Im Vault-Schritt reicht ein Klick auf „Dieser Rechner“, um das Vault zu veröffentlichen; vorher prüft Iris den freien Platz.
  3. Standardmäßig ist der Forgejo von außen nicht erreichbar; nach „Freigeben“ verbindet sich ein zweiter Rechner per HTTPS mit bestätigtem Fingerabdruck.
  4. Der Nutzer kann Zugangsdaten ansehen und einem Rechner den Zugang entziehen.
  5. Das Web-Interface öffnet sich in Iris ohne Anmeldefenster.
  6. Das Backup enthält den Forgejo ohne das Vault-Repository; nach der Wiederherstellung ist das Vault wieder veröffentlicht.
  7. Integrationstests laufen gegen einen echten Wegwerf-Forgejo grün.

Verwandt

iris/Iris#76 (Vault-Synchronisation), Plan VAULT-SYNC.md §7a, Plugin iris-dev (später).

Jede Iris-Installation bringt standardmäßig einen eigenen, kleinen **Forgejo** (Git-Server) mit. Er löst das Henne-Ei-Problem des Vault-Syncs (iris/Iris#76: „Woher kommt der Forgejo bei einer Neuinstallation?“) und ist später der Test-Forgejo für das Plugin **iris-dev**. Ergebnis einer Grill-me-Runde am 2026-10-20; Entwurf und Hintergrund: Plan `VAULT-SYNC.md` §7a. ## Grundidee und Rollen - Jede Installation hat einen eigenen Forgejo, **immer installiert und dauernd laufend**: Mac per Homebrew (`brew install forgejo`) als Hintergrunddienst (launchd), **ohne Docker**; Linux als weiterer Compose-Dienst `forgejo` (in `docker-compose.yml` und der Deploy-Vorlage). - Es gibt **keine feste Rolle „Haupt-Rechner“**. Das Vault zeigt auf das Ziel, das der Nutzer im Vault-Schritt wählt. Im Onboarding gilt (Entscheidung 2026-10-20): **vier Wege** (Neues Default-Vault, Neues Vault mit KI-Einrichtung, Aus Backup zurücklesen, Mit anderem Vault verbinden), der lokale Forgejo läuft immer, und **nach dem Vault-Schritt ist Iris immer mit einem Forgejo verbunden** (neu/zurückgelesen/vorhanden ohne Remote → automatisch lokal; nur „Mit anderem Vault verbinden“ → Forgejo remote). Das Sheet „Vault verbinden“ in den Einstellungen (vorhandenes Vault) bietet **zwei Karten**: - **„Dieser Rechner“**: ein Klick, Iris legt `iris-vault` an und veröffentlicht das Vault, ohne dass der Nutzer etwas eintippt. - **„Anderer Forgejo“**: das bisherige Formular (Adresse, Benutzer, Passwort, Repository wählen). Ein anderer Iris-Rechner und ein Forgejo im Internet sind dasselbe Formular. - Der Forgejo eines Rechners, der nicht Ziel des Vaults ist (z. B. des Notebooks), hat mit dem Vault-Sync nichts zu tun (Entwicklung, iris-dev, eigene Test-Repositories). ## Zugang und Sicherheit - Iris erzeugt das Admin-Passwort und legt es ab (**Mac: 0600-Datei `Application Support/Iris/forgejo-admin.json`, kein Schlüsselbund** – keine automatisierten Schlüsselbund-Aufrufe; Linux: verschlüsselter Secret-Store). „Zugangsdaten anzeigen“ gibt es nur auf Knopfdruck, nie automatisch. *(Abweichung: eine einmalige Anzeige bei der Einrichtung gibt es nicht.)* - **Erreichbarkeit:** standardmäßig nur `127.0.0.1` (`http://127.0.0.1:3300`). Ein Schalter „Für andere Rechner freigeben“ stellt den Forgejo **um** auf HTTPS, alle Schnittstellen und die Adresse `https://<rechnername>.local:3300` und zieht die Adresse des Vault-Remotes mit (gemessen: Forgejo schreibt die ROOT_URL fest in die LFS-Links, darum muss die Adresse zum erreichbaren Namen passen; Entscheidung des Nutzers „Umschalten + Adresse mitziehen“). **Linux:** Freigabe nur von Hand (Compose-Port), Route antwortet `409 sharing_unsupported`. - **Verschlüsselung:** HTTPS mit einem Zertifikat der Iris-eigenen CA (Rechnername und IP). Beim ersten Verbinden zeigt Iris den Fingerabdruck zur Bestätigung (wie beim Koppeln der Iris-Server) und hinterlegt die CA nur für diese Adresse in git (`http.<adresse>.sslCAInfo`). - Jeder verbundene Rechner bekommt ein **eigenes, nach dem Rechner benanntes Token** („Iris Vault-Sync – <Rechnername> (<Datum>)“). In den Einstellungen: „Verbundene Rechner“ mit letzter Nutzung und „Zugang entziehen“ (widerruft das Token). Nur für den internen Forgejo; bei fremden Forgejos bleibt es beim Namen dort. ## Oberfläche (erster Wurf: Iris und IrisClient, iOS später) - Neue Wire-Routen `/forgejo/*` (Bearer, auf beiden Servern gleich): Status, Freigabe an/aus, Zugangsdaten, verbundene Rechner, Widerruf, Einrichtung. - Einstellungen **„Git-Server“**: Status, Freigabe, Zugangsdaten anzeigen, Verbundene Rechner, **Web-Interface eingebettet in Iris (Web-View)**. Anmeldung: Iris schickt den Anmelde-Aufruf von Forgejo selbst ab (Zugangsdaten aus dem Secret-Store, nur im Speicher) und gibt das Sitzungs-Cookie an die Web-View mit nicht persistentem Datenspeicher. Zertifikat wie bei der HTML-Vorschau (Fingerabdruck der Iris-CA). - Vault-Schritt im Onboarding und Sheet „Vault verbinden“ (Mac, Client, iOS): zwei Karten wie oben. iOS behält zunächst nur das bestehende „Vault verbinden“. - Nutzertexte ohne Git-Jargon: „Git-Server“, „Vault bereitstellen“, „Verbundene Rechner“. ## Betrieb - **Datenort:** Mac `~/Library/Application Support/Iris/forgejo`, Linux `<IRIS_DOCKER_DIR>/data/forgejo`. Vor dem Veröffentlichen prüft Iris den freien Platz gegen die Vault-Größe und warnt klar. In den Einstellungen verschiebbar (Mac: der Standardordner wird ein Verweis auf den neuen Ort; Linux: Compose-Volume). - **Backup (Mac):** der ganze Ordner `forgejo` (Datenbank, Repositories, LFS) ist ausgeschlossen – er enthielte das Vault ein zweites Mal; **im Backup bleiben** Zugangsdaten, Iris-CA, gemerkte CAs und der Marker „Vault liegt auf dem eigenen Git-Server“. Nach einer Wiederherstellung baut Iris den Git-Server neu auf und veröffentlicht das Vault neu; Zugänge anderer Rechner sind danach widerrufen. *(Abweichung: Datenbank mit Konten/Tokens und andere Repositories werden nicht gesichert.)* Linux: Daten des Git-Servers sind nie Teil der Backup-Einheiten. - **Versionen:** nicht festnageln. Mac: Homebrew-Formel (zum Zeitpunkt der Prüfung 16.0.6, Release 17.0.0, der Dev-Server läuft mit 15.0.9); Linux: Compose-Tag folgt einer Hauptversion. Beim Verbinden liest Iris `GET /api/v1/version` und lehnt Versionen unter einer **Mindestversion** mit klarer Meldung ab. - **Bestandsinstallationen:** Linux: „Iris-Server aktualisieren“ ergänzt den Dienst wie bisher bei neuen Compose-Diensten, ohne Rückfrage. Mac: nach dem App-Update einmaliger Hinweis „Iris hat jetzt einen eigenen Git-Server. Jetzt einrichten?“ mit dem Fortschritt der Homebrew-Installation; ohne Zustimmung wird nichts installiert. - **Festlegungen ohne Rückfrage (änderbar):** fester Standardport (z. B. 3300, nicht 3000 wegen des bestehenden Forgejo; ist er belegt, sucht Iris einen freien); SSH im Forgejo aus, nur HTTPS; keine Selbstregistrierung, kein Gravatar, keine Update-Prüfung nach außen, keine Actions und kein Runner; ein einziges Admin-Konto, ein Repository `iris-vault` pro Rechner. ## Tests Ein **echter Wegwerf-Forgejo** für Integrationstests (leerer Datenordner, eigener Port; Linux/Dev-Host: Docker-Container, Mac: das Homebrew-Binary mit temporärem Verzeichnis): Ersteinrichtung (Admin, Repository, Token), Anmeldung mit Passwort und Zwei-Faktor, Token-Rechte, Klon und Push mit LFS, Widerruf, 404 bei fehlendem Anhang. Die bestehenden Attrappen-Tests bleiben für den schnellen Lauf. Das schließt die Lücke „Token-Erzeugung mit Passwort, Zwei-Faktor-Header (`X-GITEA-OTP`) und Token-Rechte nie gegen einen echten Forgejo gesehen“ aus #76. ## Meilensteine (in dieser Reihenfolge, jeweils lauffähig und getestet) - [x] **M1 Linux-Kern:** Compose-Dienst, automatische Ersteinrichtung (Admin, Repository, Token), Wire-Routen, Integrationstest gegen echten Wegwerf-Forgejo auf dem Dev-Host - [x] **M2 Mac:** `brew install forgejo` im Onboarding bei den Abhängigkeiten, Hintergrunddienst (launchd), Ersteinrichtung, Vault-Weg „Dieser Rechner“ (inkl. Platzprüfung) - [x] **M3 Freigabe und Verbinden:** Schalter „Für andere Rechner freigeben“, Iris-CA-Zertifikat, Fingerabdruck-Bestätigung, ein zweiter Rechner verbindet sich (Karte „Anderer Forgejo“ mit Mindestversion-Prüfung) - [x] **M4 Verwaltung:** Einstellungen „Git-Server“ (Status, Zugangsdaten, Verbundene Rechner, Widerruf), eingebettete Web-View mit Auto-Anmeldung - [x] **M5 Backup und Bestand:** Backup ohne Vault-Repository (inkl. Neuveröffentlichen nach Wiederherstellung), Hinweis für Mac-Bestandsinstallationen, Linux-Update - [x] **Datenort verschieben** (Mac) ## Offen (Stand 2026-10-20; Einzelheiten im Plan `VAULT-SYNC.md` §7a „Offene Punkte zum Git-Server“) - **Abnahme durch den Nutzer:** keine Oberfläche wurde bedient (Karten im Sheet, Fingerabdruck-Bestätigung, Einstellungen „Git-Server“, Datenort, Weboberfläche, Onboarding-Abhängigkeit, Hinweis-Dialog). - **Nicht über echte Wege geprüft:** zwei echte Rechner im LAN (Freigabe, `.local`, Klon über HTTPS), echte Wiederherstellung aus einem Backup-Zip, „Iris-Server aktualisieren“ auf einem Bestandsserver, Datenort auf eine externe Platte mit großem Bestand, Zwei-Faktor (`X-GITEA-OTP`), Forgejo-Major-Update per `brew upgrade`. - **Bekannte Lücken:** Zertifikat wird nicht bei Ablauf (800 Tage) oder Netzwechsel erneuert; nach einer Wiederherstellung Zugänge widerrufen und Freigabe zurückgesetzt; Linux: Freigabe/Datenort nur von Hand; Weboberfläche nur auf demselben Mac; iOS ohne Verwaltung. - **Aus #76:** LFS-Objekte fehlen auf dem echten Forgejo (`git lfs push --all` wartet auf Okay); Testmaschine `mac-vm` noch nicht neu verbunden. ## Bewusst ausgeklammert iOS-Verwaltung (später), Verbindungscode oder Liste gekoppelter Iris-Server (später als Komfort denkbar), Forgejo-Verbund mit gegenseitigen Mirrors, GitHub/GitLab als Ziel, alles was iris-dev vom Forgejo braucht (mehrere Konten, Organisationen). ## Abnahmekriterien 1. Auf einem frisch installierten Mac und einem frischen Linux-Server läuft ohne eine Handlung des Nutzers ein Forgejo. *(Linux: auf dem Dev-Host belegt; Mac: Kern getestet, frische Maschine nicht.)* 2. Im Vault-Schritt reicht ein Klick auf „Dieser Rechner“, um das Vault zu veröffentlichen; vorher prüft Iris den freien Platz. 3. Standardmäßig ist der Forgejo von außen nicht erreichbar; nach „Freigeben“ verbindet sich ein zweiter Rechner per HTTPS mit bestätigtem Fingerabdruck. 4. Der Nutzer kann Zugangsdaten ansehen und einem Rechner den Zugang entziehen. 5. Das Web-Interface öffnet sich in Iris ohne Anmeldefenster. 6. Das Backup enthält den Forgejo ohne das Vault-Repository; nach der Wiederherstellung ist das Vault wieder veröffentlicht. 7. Integrationstests laufen gegen einen echten Wegwerf-Forgejo grün. ## Verwandt iris/Iris#76 (Vault-Synchronisation), Plan `VAULT-SYNC.md` §7a, Plugin iris-dev (später).
alf commented 2026-10-20 09:37:33 +00:00
Author
Owner
Copy link

PR #62 gemergt: feat(forgejo): eigener Git-Server im Linux-Server, Einrichtung und Routen /forgejo/* (iris/Iris#112)
iris/iris-linux-server#62

Commits:

  • feat(forgejo): eigener Git-Server im Linux-Server, Einrichtung und Routen /forgejo/* (iris/Iris#112)
PR #62 gemergt: feat(forgejo): eigener Git-Server im Linux-Server, Einrichtung und Routen /forgejo/* (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/62 Commits: - feat(forgejo): eigener Git-Server im Linux-Server, Einrichtung und Routen /forgejo/* (iris/Iris#112)
alf commented 2026-10-20 09:37:46 +00:00
Author
Owner
Copy link

PR #88 gemergt: docs(wire): Eigener Git-Server /forgejo/* (iris/Iris#112)
alf/2ndbrain#88

Commits:

PR #88 gemergt: docs(wire): Eigener Git-Server /forgejo/* (iris/Iris#112) https://forgejo.lewerken.duckdns.org/alf/2ndbrain/pulls/88 Commits: - docs(wire): Eigener Git-Server /forgejo/* (iris/Iris#112)
alf commented 2026-10-20 09:37:47 +00:00
Author
Owner
Copy link

M1 (Linux-Kern) fertig – PR iris/iris-linux-server#62, Wire-Doku im Root-Repo.

Befund/Änderung: Compose-Dienst forgejo (Image codeberg.org/forgejo/forgejo:16, kein Host-Port); app/forgejo_service.py richtet beim Start Administrator iris-admin (Zufallspasswort im Secret-Store) und privates Repository iris-vault ein, idempotent und selbstheilend. Routen GET /forgejo/status, POST /forgejo/setup, GET /forgejo/credentials, POST /forgejo/publish-vault. vault_forge.login kennt token_name und erkennt einen Forgejo mit REQUIRE_SIGNIN_VIEW (403 auf /api/v1/version).

Geprüft: 11 Unit-Tests (Attrappe) + 3 Integrationstests gegen einen echten Wegwerf-Forgejo 16.0.6 (Einrichtung, Passwort-Selbstheilung, Token per Passwort, Veröffentlichen mit LFS-Anhang, Klon durch Peer mit identischem Anhang); Sync-Suite (66) grün. Damit ist auch Token-Erzeugung per Basic-Auth und LFS-Batch gegen echten Forgejo belegt.

Grenzen/offen: nicht auf dem Dev-Host deployt (Platte 95 %, neuer Dienst startet beim nächsten up -d --build); Zwei-Faktor-Header weiter ungeprüft; Mac-Gegenstück (Swift-VaultForge-Versionscheck, Homebrew/launchd) = M2.

**M1 (Linux-Kern) fertig** – PR iris/iris-linux-server#62, Wire-Doku im Root-Repo. **Befund/Änderung:** Compose-Dienst `forgejo` (Image `codeberg.org/forgejo/forgejo:16`, kein Host-Port); `app/forgejo_service.py` richtet beim Start Administrator `iris-admin` (Zufallspasswort im Secret-Store) und privates Repository `iris-vault` ein, idempotent und selbstheilend. Routen `GET /forgejo/status`, `POST /forgejo/setup`, `GET /forgejo/credentials`, `POST /forgejo/publish-vault`. `vault_forge.login` kennt `token_name` und erkennt einen Forgejo mit REQUIRE_SIGNIN_VIEW (403 auf `/api/v1/version`). **Geprüft:** 11 Unit-Tests (Attrappe) + 3 Integrationstests gegen einen echten Wegwerf-Forgejo 16.0.6 (Einrichtung, Passwort-Selbstheilung, Token per Passwort, Veröffentlichen mit LFS-Anhang, Klon durch Peer mit identischem Anhang); Sync-Suite (66) grün. Damit ist auch Token-Erzeugung per Basic-Auth und LFS-Batch gegen echten Forgejo belegt. **Grenzen/offen:** nicht auf dem Dev-Host deployt (Platte 95 %, neuer Dienst startet beim nächsten `up -d --build`); Zwei-Faktor-Header weiter ungeprüft; Mac-Gegenstück (Swift-`VaultForge`-Versionscheck, Homebrew/launchd) = M2.
alf commented 2026-10-20 09:57:32 +00:00
Author
Owner
Copy link

PR #63 gemergt: fix(forgejo): eindeutiger Token-Name je Veröffentlichen (iris/Iris#112)
iris/iris-linux-server#63

Commits:

  • fix(forgejo): eindeutiger Token-Name je Veröffentlichen (iris/Iris#112)
PR #63 gemergt: fix(forgejo): eindeutiger Token-Name je Veröffentlichen (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/63 Commits: - fix(forgejo): eindeutiger Token-Name je Veröffentlichen (iris/Iris#112)
alf commented 2026-10-20 10:00:33 +00:00
Author
Owner
Copy link

PR #89 gemergt: docs(wire): Mac-Server bietet /forgejo/* (iris/Iris#112)
alf/2ndbrain#89

Commits:

PR #89 gemergt: docs(wire): Mac-Server bietet /forgejo/* (iris/Iris#112) https://forgejo.lewerken.duckdns.org/alf/2ndbrain/pulls/89 Commits: - docs(wire): Mac-Server bietet /forgejo/* (iris/Iris#112)
alf commented 2026-10-20 10:00:44 +00:00
Author
Owner
Copy link

PR #28 gemergt: feat(vault-sync): Karten „Dieser Rechner“ / „Anderer Forgejo“ im Sheet Vault verbinden (iris/Iris#112)
iris/2ndbrain-ios#28

Commits:

  • feat(vault-sync): Karten „Dieser Rechner“ / „Anderer Forgejo“ im Sheet Vault verbinden (iris/Iris#112)
PR #28 gemergt: feat(vault-sync): Karten „Dieser Rechner“ / „Anderer Forgejo“ im Sheet Vault verbinden (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/2ndbrain-ios/pulls/28 Commits: - feat(vault-sync): Karten „Dieser Rechner“ / „Anderer Forgejo“ im Sheet Vault verbinden (iris/Iris#112)
alf commented 2026-10-20 10:00:46 +00:00
Author
Owner
Copy link

PR #113 gemergt: feat(forgejo): eigener Git-Server auf dem Mac, Routen /forgejo/*, Onboarding und Karte „Dieser Rechner“ (iris/Iris#112)
#113

Commits:

  • feat(forgejo): eigener Git-Server auf dem Mac, Routen /forgejo/*, Onboarding und Karte „Dieser Rechner“ (iris/Iris#112)
PR #113 gemergt: feat(forgejo): eigener Git-Server auf dem Mac, Routen /forgejo/*, Onboarding und Karte „Dieser Rechner“ (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/113 Commits: - feat(forgejo): eigener Git-Server auf dem Mac, Routen /forgejo/*, Onboarding und Karte „Dieser Rechner“ (iris/Iris#112)
alf commented 2026-10-20 10:00:55 +00:00
Author
Owner
Copy link

M2 (Mac) fertig – PR iris/Iris#113 (Mac), IrisRemote-PR (iOS), Wire-Doku Root-Repo; Folgefix iris-linux-server#63.

Gebaut: ForgejoCore.swift (app.ini nur 127.0.0.1, Port ab 3300, launchd-Agent com.alflewerken.iris.forgejo mit KeepAlive, Administrator iris-admin + privates Repository iris-vault, Zugangsdaten in Application Support/Iris/forgejo-admin.json 0600 – bewusst kein Schlüsselbund), ForgejoController.swift, Routen /forgejo/{status,setup,credentials,publish-vault} im Mac-Server (Wire wie Linux), Start beim App-Start vor der Sync-Erkennung, Onboarding: Forgejo als Pflicht-Abhängigkeit (brew install forgejo, danach Einrichtung). Sheet „Vault verbinden“ beginnt mit den Karten „Dieser Rechner“ / „Anderer Forgejo" (Iris, IrisClient, IrisRemote). Swift-VaultForge.login erkennt Forgejo mit Pflicht-Anmeldung (Fix des alten Versionschecks) und nimmt einen Token-Namen.

Befunde: Das Homebrew-Binary (Forgejo 17.0.0) liest keine FORGEJO__…-Variablen – alles steht in der app.ini. Forgejo lehnt doppelte Token-Namen ab: ein zweites „Bereitstellen“ scheiterte (Linux und Mac); Name trägt jetzt Zeitpunkt + Zufallsanhang, Regressionstests in beiden.

Geprüft: scripts/test-forgejo-core.sh mit echtem Forgejo 17 (45 Prüfungen: Einrichtung, Idempotenz, Passwort-Selbstheilung, launchd laden/entfernen, Veröffentlichen mit LFS-Anhang, Klon mit echtem Anhang, Wiederholung); Linux 14 Tests (davon 3 gegen echten Forgejo), Linux-Dev-Host aktualisiert; Iris, IrisClient, IrisRemote bauen.

Grenzen/offen: Oberfläche und Onboarding auf frischer Maschine nie bedient; Platzprüfung vor „Dieser Rechner“ und Datenort verschieben noch nicht gebaut; startIfConfigured installiert nichts (Bestand → M5). Nächste: M3 (Freigabe für andere Rechner, HTTPS mit Iris-CA, Verbinden).

**M2 (Mac) fertig** – PR iris/Iris#113 (Mac), IrisRemote-PR (iOS), Wire-Doku Root-Repo; Folgefix iris-linux-server#63. **Gebaut:** `ForgejoCore.swift` (app.ini nur 127.0.0.1, Port ab 3300, launchd-Agent `com.alflewerken.iris.forgejo` mit KeepAlive, Administrator `iris-admin` + privates Repository `iris-vault`, Zugangsdaten in `Application Support/Iris/forgejo-admin.json` 0600 – bewusst kein Schlüsselbund), `ForgejoController.swift`, Routen `/forgejo/{status,setup,credentials,publish-vault}` im Mac-Server (Wire wie Linux), Start beim App-Start vor der Sync-Erkennung, Onboarding: Forgejo als Pflicht-Abhängigkeit (`brew install forgejo`, danach Einrichtung). Sheet „Vault verbinden“ beginnt mit den Karten „Dieser Rechner“ / „Anderer Forgejo" (Iris, IrisClient, IrisRemote). Swift-`VaultForge.login` erkennt Forgejo mit Pflicht-Anmeldung (Fix des alten Versionschecks) und nimmt einen Token-Namen. **Befunde:** Das Homebrew-Binary (Forgejo 17.0.0) liest keine `FORGEJO__…`-Variablen – alles steht in der `app.ini`. Forgejo lehnt doppelte Token-Namen ab: ein zweites „Bereitstellen“ scheiterte (Linux und Mac); Name trägt jetzt Zeitpunkt + Zufallsanhang, Regressionstests in beiden. **Geprüft:** `scripts/test-forgejo-core.sh` mit echtem Forgejo 17 (45 Prüfungen: Einrichtung, Idempotenz, Passwort-Selbstheilung, launchd laden/entfernen, Veröffentlichen mit LFS-Anhang, Klon mit echtem Anhang, Wiederholung); Linux 14 Tests (davon 3 gegen echten Forgejo), Linux-Dev-Host aktualisiert; Iris, IrisClient, IrisRemote bauen. **Grenzen/offen:** Oberfläche und Onboarding auf frischer Maschine nie bedient; Platzprüfung vor „Dieser Rechner“ und Datenort verschieben noch nicht gebaut; `startIfConfigured` installiert nichts (Bestand → M5). Nächste: M3 (Freigabe für andere Rechner, HTTPS mit Iris-CA, Verbinden).
alf commented 2026-10-20 10:22:41 +00:00
Author
Owner
Copy link

PR #64 gemergt: feat(forgejo): Vertrauen in die Iris-CA per Fingerabdruck, /forgejo/sharing (iris/Iris#112)
iris/iris-linux-server#64

Commits:

  • feat(forgejo): Vertrauen in die Iris-CA per Fingerabdruck, /forgejo/sharing (iris/Iris#112)
PR #64 gemergt: feat(forgejo): Vertrauen in die Iris-CA per Fingerabdruck, /forgejo/sharing (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/64 Commits: - feat(forgejo): Vertrauen in die Iris-CA per Fingerabdruck, /forgejo/sharing (iris/Iris#112)
alf commented 2026-10-20 10:22:43 +00:00
Author
Owner
Copy link

PR #90 gemergt: docs(wire): Freigabe und Vertrauen per Fingerabdruck (iris/Iris#112)
alf/2ndbrain#90

Commits:

  • docs(wire): Freigabe und Vertrauen per Fingerabdruck (iris/Iris#112)
PR #90 gemergt: docs(wire): Freigabe und Vertrauen per Fingerabdruck (iris/Iris#112) https://forgejo.lewerken.duckdns.org/alf/2ndbrain/pulls/90 Commits: - docs(wire): Freigabe und Vertrauen per Fingerabdruck (iris/Iris#112)
alf commented 2026-10-20 10:22:50 +00:00
Author
Owner
Copy link

PR #29 gemergt: feat(vault-sync): Fingerabdruck-Bestätigung für Server mit eigener Iris-CA (iris/Iris#112)
iris/2ndbrain-ios#29

Commits:

  • feat(vault-sync): Fingerabdruck-Bestätigung für Server mit eigener Iris-CA (iris/Iris#112)
PR #29 gemergt: feat(vault-sync): Fingerabdruck-Bestätigung für Server mit eigener Iris-CA (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/2ndbrain-ios/pulls/29 Commits: - feat(vault-sync): Fingerabdruck-Bestätigung für Server mit eigener Iris-CA (iris/Iris#112)
alf commented 2026-10-20 10:23:02 +00:00
Author
Owner
Copy link

PR #114 gemergt: feat(forgejo): Freigabe, HTTPS mit Iris-CA und Vertrauen per Fingerabdruck (iris/Iris#112)
#114

Commits:

  • feat(forgejo): Freigabe, HTTPS mit Iris-CA und Vertrauen per Fingerabdruck (iris/Iris#112)
PR #114 gemergt: feat(forgejo): Freigabe, HTTPS mit Iris-CA und Vertrauen per Fingerabdruck (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/114 Commits: - feat(forgejo): Freigabe, HTTPS mit Iris-CA und Vertrauen per Fingerabdruck (iris/Iris#112)
alf commented 2026-10-20 10:23:02 +00:00
Author
Owner
Copy link

M3 (Freigabe, HTTPS mit Iris-CA, Verbinden) fertig – Server-Seite; Oberfläche folgt mit M4.

Entscheidung nach Messung: Forgejo schreibt die ROOT_URL fest in die LFS-Links der Anhänge (per Probelauf bestätigt, unabhängig vom Host-Header). „Immer HTTPS unter Rechnername, nur Schnittstelle umschalten“ geht daher nicht (der eigene Rechner erreicht seinen Namen nicht, solange nur loopback lauscht). Mit dem Nutzer entschieden: Umschalten + Adresse mitziehen. Ungeteilt http://127.0.0.1:3300; „Freigeben“ → HTTPS, alle Schnittstellen, <rechnername>.local:3300; die Adresse des Vault-Remotes und der Token-Geltungsbereich ziehen automatisch mit, Zurückschalten ebenso.

Gebaut: ForgejoTLS.swift (Iris-CA EC P-256, Serverzertifikat mit SAN, Kette = Zertifikat + CA, Fingerabdruck SHA-256, gemerkte CAs je Adresse, URLSession-Delegate), ForgejoCore.setSharing, VaultSyncSetup.moveRemote, POST /forgejo/sharing, status mit shared/ca_fingerprint; forge/login mit trust_fingerprint und Fehler untrusted_certificate (Mac, Linux-Server); git/git-lfs bekommen die bestätigte CA nur für diese Adresse (http.<adresse>.sslCAInfo); Fingerabdruck-Bestätigung im Sheet „Anderer Forgejo“ (Iris, IrisClient, IrisRemote). Linux-Server: 409 sharing_unsupported (Container kann seinen Port nicht selbst veröffentlichen).

Geprüft: test-forgejo-core.sh gegen echten Forgejo 17: 67 Prüfungen (Freigabe an/aus, HTTPS, falscher/richtiger Fingerabdruck, Klon mit LFS-Anhang über HTTPS, Vault-Adresse umgezogen); Python test_forgejo_tls.py mit eigenem HTTPS-Server + CA; Sync-Suiten grün; alle drei Apps bauen. Falle: Python 3.13+ verlangt AKI/SKI in der Kette.

Offen: kein Schalter und keine Fingerabdruck-Anzeige in der Oberfläche (M4); echter Zweirechner-Test über das LAN; Linux-Freigabe nur per .env/Compose von Hand; Namensänderung des Rechners erneuert das Zertifikat nicht automatisch.

**M3 (Freigabe, HTTPS mit Iris-CA, Verbinden) fertig – Server-Seite; Oberfläche folgt mit M4.** **Entscheidung nach Messung:** Forgejo schreibt die ROOT_URL fest in die LFS-Links der Anhänge (per Probelauf bestätigt, unabhängig vom Host-Header). „Immer HTTPS unter Rechnername, nur Schnittstelle umschalten“ geht daher nicht (der eigene Rechner erreicht seinen Namen nicht, solange nur loopback lauscht). Mit dem Nutzer entschieden: **Umschalten + Adresse mitziehen**. Ungeteilt `http://127.0.0.1:3300`; „Freigeben“ → HTTPS, alle Schnittstellen, `<rechnername>.local:3300`; die Adresse des Vault-Remotes und der Token-Geltungsbereich ziehen automatisch mit, Zurückschalten ebenso. **Gebaut:** `ForgejoTLS.swift` (Iris-CA EC P-256, Serverzertifikat mit SAN, Kette = Zertifikat + CA, Fingerabdruck SHA-256, gemerkte CAs je Adresse, URLSession-Delegate), `ForgejoCore.setSharing`, `VaultSyncSetup.moveRemote`, `POST /forgejo/sharing`, `status` mit `shared`/`ca_fingerprint`; `forge/login` mit `trust_fingerprint` und Fehler `untrusted_certificate` (Mac, Linux-Server); git/git-lfs bekommen die bestätigte CA nur für diese Adresse (`http.<adresse>.sslCAInfo`); Fingerabdruck-Bestätigung im Sheet „Anderer Forgejo“ (Iris, IrisClient, IrisRemote). Linux-Server: `409 sharing_unsupported` (Container kann seinen Port nicht selbst veröffentlichen). **Geprüft:** `test-forgejo-core.sh` gegen echten Forgejo 17: 67 Prüfungen (Freigabe an/aus, HTTPS, falscher/richtiger Fingerabdruck, Klon mit LFS-Anhang über HTTPS, Vault-Adresse umgezogen); Python `test_forgejo_tls.py` mit eigenem HTTPS-Server + CA; Sync-Suiten grün; alle drei Apps bauen. Falle: Python 3.13+ verlangt AKI/SKI in der Kette. **Offen:** kein Schalter und keine Fingerabdruck-Anzeige in der Oberfläche (M4); echter Zweirechner-Test über das LAN; Linux-Freigabe nur per .env/Compose von Hand; Namensänderung des Rechners erneuert das Zertifikat nicht automatisch.
alf commented 2026-10-20 10:29:26 +00:00
Author
Owner
Copy link

PR #65 gemergt: feat(forgejo): Verbundene Rechner auflisten und entziehen (iris/Iris#112)
iris/iris-linux-server#65

Commits:

  • feat(forgejo): Verbundene Rechner auflisten und entziehen (iris/Iris#112)
PR #65 gemergt: feat(forgejo): Verbundene Rechner auflisten und entziehen (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/65 Commits: - feat(forgejo): Verbundene Rechner auflisten und entziehen (iris/Iris#112)
alf commented 2026-10-20 10:29:28 +00:00
Author
Owner
Copy link

PR #91 gemergt: docs(wire): Verbundene Rechner und Token-Namen (iris/Iris#112)
alf/2ndbrain#91

Commits:

PR #91 gemergt: docs(wire): Verbundene Rechner und Token-Namen (iris/Iris#112) https://forgejo.lewerken.duckdns.org/alf/2ndbrain/pulls/91 Commits: - docs(wire): Verbundene Rechner und Token-Namen (iris/Iris#112)
alf commented 2026-10-20 10:29:30 +00:00
Author
Owner
Copy link

PR #116 gemergt: feat(forgejo): Einstellungen Git-Server, verbundene Rechner, Weboberfläche (iris/Iris#112)
#116

Commits:

  • feat(forgejo): Einstellungen Git-Server, verbundene Rechner, Weboberfläche (iris/Iris#112)
PR #116 gemergt: feat(forgejo): Einstellungen Git-Server, verbundene Rechner, Weboberfläche (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/116 Commits: - feat(forgejo): Einstellungen Git-Server, verbundene Rechner, Weboberfläche (iris/Iris#112)
alf commented 2026-10-20 10:29:38 +00:00
Author
Owner
Copy link

M4 (Verwaltung + Weboberfläche) fertig – Server und Oberfläche gebaut, Oberfläche nicht bedient.

Gebaut: Einstellungen → „Git-Server …" (Iris und IrisClient): Status, Schalter „Für andere Rechner freigeben" mit Fingerabdruck, „Zugangsdaten anzeigen" nur auf Knopfdruck, „Verbundene Rechner" mit „Zugang entziehen". Routen GET /forgejo/tokens, DELETE /forgejo/tokens/{id} auf Mac und Linux (nur Token „Iris Vault…"; das eigene Token ist geschützt: 409 own_token). Token-Namen tragen den Rechnernamen („Iris Vault-Sync – ()"). Weboberfläche im eigenen Fenster (WKWebView, nicht persistenter Datenspeicher, Iris füllt das Anmeldeformular selbst aus, Zertifikat der Iris-CA wird geprüft).

Geprüft: Mac test-forgejo-core.sh 72 Prüfungen gegen echten Forgejo 17 (Zugang eines anderen Rechners sichtbar/entziehbar, eigener geschützt); Linux Attrappe + echter Forgejo; Iris und IrisClient bauen.

Grenzen: Weboberfläche nur, wenn der Client auf demselben Rechner wie der Server läuft (ungeteilt ist Forgejo nur über 127.0.0.1 erreichbar); iOS-Verwaltung ausgeklammert; Installation per Knopf (M5); keine Oberfläche bedient.

Nächste: M5 (Backup ohne Vault-Repository, Bestand: Linux automatisch beim Server-Update, Mac einmaliger Hinweis „Jetzt einrichten?", Datenort/Platzprüfung).

**M4 (Verwaltung + Weboberfläche) fertig – Server und Oberfläche gebaut, Oberfläche nicht bedient.** **Gebaut:** Einstellungen → „Git-Server …" (Iris und IrisClient): Status, Schalter „Für andere Rechner freigeben" mit Fingerabdruck, „Zugangsdaten anzeigen" nur auf Knopfdruck, „Verbundene Rechner" mit „Zugang entziehen". Routen `GET /forgejo/tokens`, `DELETE /forgejo/tokens/{id}` auf Mac und Linux (nur Token „Iris Vault…"; das eigene Token ist geschützt: 409 `own_token`). Token-Namen tragen den Rechnernamen („Iris Vault-Sync – <Rechner> (<Zeit>)"). Weboberfläche im eigenen Fenster (WKWebView, nicht persistenter Datenspeicher, Iris füllt das Anmeldeformular selbst aus, Zertifikat der Iris-CA wird geprüft). **Geprüft:** Mac `test-forgejo-core.sh` 72 Prüfungen gegen echten Forgejo 17 (Zugang eines anderen Rechners sichtbar/entziehbar, eigener geschützt); Linux Attrappe + echter Forgejo; Iris und IrisClient bauen. **Grenzen:** Weboberfläche nur, wenn der Client auf demselben Rechner wie der Server läuft (ungeteilt ist Forgejo nur über 127.0.0.1 erreichbar); iOS-Verwaltung ausgeklammert; Installation per Knopf (M5); keine Oberfläche bedient. Nächste: M5 (Backup ohne Vault-Repository, Bestand: Linux automatisch beim Server-Update, Mac einmaliger Hinweis „Jetzt einrichten?", Datenort/Platzprüfung).
alf commented 2026-10-20 10:37:09 +00:00
Author
Owner
Copy link

PR #66 gemergt: fix(docker): git safe.directory fuer das Vault im Container (iris/Iris#112)
iris/iris-linux-server#66

Commits:

  • fix(docker): git safe.directory fuer das Vault im Container (iris/Iris#112)
PR #66 gemergt: fix(docker): git safe.directory fuer das Vault im Container (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/66 Commits: - fix(docker): git safe.directory fuer das Vault im Container (iris/Iris#112)
alf commented 2026-10-20 10:37:09 +00:00
Author
Owner
Copy link

Echter Durchlauf auf dem Linux-Dev-Server (kleiner Bestand statt Studio-Vault): publish_vault mit dem Dev-Vault (257 MB, 339 LFS-Anhänge) gegen den mitgelieferten Forgejo.

Fund: erst scheiterte es mit „detected dubious ownership in repository at '/vault'" (Server läuft als root, Vault gehört dem Host-Nutzer). Fix: git config --system safe.directory '*' im Dockerfile (iris-linux-server).

Ergebnis danach: published, Sync-Status synced, ein zweiter Klon im Container liefert alle 339 Anhänge, geprüfter Anhang bytegleich (SHA-256). Das Studio-Vault wurde nicht angefasst.

**Echter Durchlauf auf dem Linux-Dev-Server (kleiner Bestand statt Studio-Vault):** `publish_vault` mit dem Dev-Vault (257 MB, 339 LFS-Anhänge) gegen den mitgelieferten Forgejo. **Fund:** erst scheiterte es mit „detected dubious ownership in repository at '/vault'" (Server läuft als root, Vault gehört dem Host-Nutzer). Fix: `git config --system safe.directory '*'` im Dockerfile (iris-linux-server). **Ergebnis danach:** `published`, Sync-Status `synced`, ein zweiter Klon im Container liefert alle 339 Anhänge, geprüfter Anhang bytegleich (SHA-256). Das Studio-Vault wurde nicht angefasst.
alf commented 2026-10-20 10:50:21 +00:00
Author
Owner
Copy link

PR #67 gemergt: feat(forgejo): Bestand und Platzpruefung auf dem Linux-Server (iris/Iris#112)
iris/iris-linux-server#67

Commits:

  • feat(forgejo): Bestand und Platzpruefung auf dem Linux-Server (iris/Iris#112)
PR #67 gemergt: feat(forgejo): Bestand und Platzpruefung auf dem Linux-Server (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/67 Commits: - feat(forgejo): Bestand und Platzpruefung auf dem Linux-Server (iris/Iris#112)
alf commented 2026-10-20 10:50:23 +00:00
Author
Owner
Copy link

PR #92 gemergt: docs(wire): Platzpruefung, Backup und Installation des Git-Servers (iris/Iris#112)
alf/2ndbrain#92

Commits:

  • docs(wire): Platzpruefung, Backup und Installation des Git-Servers (iris/Iris#112)
PR #92 gemergt: docs(wire): Platzpruefung, Backup und Installation des Git-Servers (iris/Iris#112) https://forgejo.lewerken.duckdns.org/alf/2ndbrain/pulls/92 Commits: - docs(wire): Platzpruefung, Backup und Installation des Git-Servers (iris/Iris#112)
alf commented 2026-10-20 10:50:25 +00:00
Author
Owner
Copy link

PR #30 gemergt: feat(vault-sync): Meldung bei zu wenig Platz fuer den Git-Server (iris/Iris#112)
iris/2ndbrain-ios#30

Commits:

  • feat(vault-sync): Meldung bei zu wenig Platz fuer den Git-Server (iris/Iris#112)
PR #30 gemergt: feat(vault-sync): Meldung bei zu wenig Platz fuer den Git-Server (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/2ndbrain-ios/pulls/30 Commits: - feat(vault-sync): Meldung bei zu wenig Platz fuer den Git-Server (iris/Iris#112)
alf commented 2026-10-20 10:50:27 +00:00
Author
Owner
Copy link

PR #117 gemergt: feat(forgejo): Backup ohne Git-Server-Daten, Wiederherstellung, Platzpruefung, Installation (iris/Iris#112)
#117

Commits:

  • feat(forgejo): Backup ohne Git-Server-Daten, Wiederherstellung, Platzpruefung, Installation (iris/Iris#112)
PR #117 gemergt: feat(forgejo): Backup ohne Git-Server-Daten, Wiederherstellung, Platzpruefung, Installation (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/117 Commits: - feat(forgejo): Backup ohne Git-Server-Daten, Wiederherstellung, Platzpruefung, Installation (iris/Iris#112)
alf commented 2026-10-20 10:50:35 +00:00
Author
Owner
Copy link

M5 (Backup, Bestand, Platzprüfung) fertig.

Backup/Wiederherstellung (Mac): iris-app-data schließt /forgejo aus (Datenbank, Repositories, LFS würden das Vault verdoppeln, bis 60 GB). Zugangsdaten, Iris-CA, gemerkte CAs und der Marker forgejo-vault.flag bleiben im Backup. Nach dem Zurücklesen baut rebuildAfterRestore den Git-Server neu auf (Administrator mit dem gesicherten Passwort, leeres iris-vault) und veröffentlicht das Vault neu. Zugänge anderer Rechner sind danach widerrufen (sie verbinden sich neu). Linux: Daten des Git-Servers gehören nie zu den Backup-Einheiten – nichts zu ändern.

Platzprüfung: vor „Dieser Rechner“ (Vault ohne .git × 1,1 + 1 GiB gegen freien Platz, 409 not_enough_space:<nötig>:<frei>, Klartext in allen Clients); entfällt, wenn das Vault schon ein Remote hat.

Bestand: Linux – der Dienst forgejo kommt beim „Iris-Server aktualisieren“ per syncMissingComposeServices; der Server findet den Container über das Compose-Label (auf dem Dev-Host geprüft). Mac – POST /forgejo/install / Knopf „Installieren und einrichten“ und einmaliger Hinweis „Eigenen Git-Server einrichten?“ 30 s nach dem Start (nur nach abgeschlossenem Onboarding).

Geprüft: Mac test-forgejo-core.sh 80 Prüfungen gegen echten Forgejo 17 (Platzmangel, Wiederherstellung: Daten weg → Administrator/Repository neu, gleiche Zugangsdaten); Linux 13 Tests + Dev-Host; Iris, IrisClient, IrisRemote bauen. Gefundener Fehler: launchctl bootout wartet nicht auf das Ende des Dienstes, direktes bootstrap scheitert → behoben.

Nicht gebaut: Datenort verschieben (Konfiguration enthält absolute Pfade) – auf Wunsch. Nie bedient: Oberfläche, Hinweis-Dialog, echte Wiederherstellung aus einem Backup-Zip, Server-Update eines Bestandsservers. Issue bleibt offen (Abnahme durch den Nutzer).

**M5 (Backup, Bestand, Platzprüfung) fertig.** **Backup/Wiederherstellung (Mac):** `iris-app-data` schließt `/forgejo` aus (Datenbank, Repositories, LFS würden das Vault verdoppeln, bis 60 GB). Zugangsdaten, Iris-CA, gemerkte CAs und der Marker `forgejo-vault.flag` bleiben im Backup. Nach dem Zurücklesen baut `rebuildAfterRestore` den Git-Server neu auf (Administrator mit dem gesicherten Passwort, leeres `iris-vault`) und veröffentlicht das Vault neu. Zugänge anderer Rechner sind danach widerrufen (sie verbinden sich neu). Linux: Daten des Git-Servers gehören nie zu den Backup-Einheiten – nichts zu ändern. **Platzprüfung:** vor „Dieser Rechner“ (Vault ohne .git × 1,1 + 1 GiB gegen freien Platz, `409 not_enough_space:<nötig>:<frei>`, Klartext in allen Clients); entfällt, wenn das Vault schon ein Remote hat. **Bestand:** Linux – der Dienst `forgejo` kommt beim „Iris-Server aktualisieren“ per `syncMissingComposeServices`; der Server findet den Container über das Compose-Label (auf dem Dev-Host geprüft). Mac – `POST /forgejo/install` / Knopf „Installieren und einrichten“ und einmaliger Hinweis „Eigenen Git-Server einrichten?“ 30 s nach dem Start (nur nach abgeschlossenem Onboarding). **Geprüft:** Mac `test-forgejo-core.sh` 80 Prüfungen gegen echten Forgejo 17 (Platzmangel, Wiederherstellung: Daten weg → Administrator/Repository neu, gleiche Zugangsdaten); Linux 13 Tests + Dev-Host; Iris, IrisClient, IrisRemote bauen. Gefundener Fehler: `launchctl bootout` wartet nicht auf das Ende des Dienstes, direktes `bootstrap` scheitert → behoben. **Nicht gebaut:** Datenort verschieben (Konfiguration enthält absolute Pfade) – auf Wunsch. **Nie bedient:** Oberfläche, Hinweis-Dialog, echte Wiederherstellung aus einem Backup-Zip, Server-Update eines Bestandsservers. Issue bleibt offen (Abnahme durch den Nutzer).
alf commented 2026-10-20 10:54:39 +00:00
Author
Owner
Copy link

PR #93 gemergt: docs(wire): Datenort des Git-Servers verschieben (iris/Iris#112)
alf/2ndbrain#93

Commits:

  • docs(wire): Datenort des Git-Servers verschieben (iris/Iris#112)
PR #93 gemergt: docs(wire): Datenort des Git-Servers verschieben (iris/Iris#112) https://forgejo.lewerken.duckdns.org/alf/2ndbrain/pulls/93 Commits: - docs(wire): Datenort des Git-Servers verschieben (iris/Iris#112)
alf commented 2026-10-20 10:54:41 +00:00
Author
Owner
Copy link

PR #118 gemergt: feat(forgejo): Datenort des Git-Servers verschieben (iris/Iris#112)
#118

Commits:

  • feat(forgejo): Datenort des Git-Servers verschieben (iris/Iris#112)
PR #118 gemergt: feat(forgejo): Datenort des Git-Servers verschieben (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/118 Commits: - feat(forgejo): Datenort des Git-Servers verschieben (iris/Iris#112)
alf commented 2026-10-20 10:54:41 +00:00
Author
Owner
Copy link

Datenort verschieben fertig (Mac). Der Standardordner …/Iris/forgejo wird nach dem Verschieben ein Verweis auf den neuen Ort; Konfiguration (absolute Pfade), launchd-Dienst und Backup bleiben unverändert. Ablauf: Platz am Ziel prüfen → Dienst anhalten → rsync → Umschalten → Dienst starten und prüfen → erst dann das Alte löschen; bei jedem Fehler Rollback. Auch „zurück an den Standardort". Route POST /forgejo/move-data, Abschnitt „Datenort" in Einstellungen → Git-Server (Ordnerwahl nur, wenn Iris und Server auf demselben Mac laufen). Linux: Volume in der Compose-Datei, nicht per Route.

Geprüft: test-forgejo-core.sh 91 Prüfungen gegen echten Forgejo 17 (hinaus, Anmeldung am neuen Ort, unzulässiges/nicht leeres Ziel abgelehnt, zurück, Altdaten entfernt); Iris und IrisClient bauen. Nicht bedient: Oberfläche, echtes Verschieben auf eine externe Platte mit großem Bestand.

**Datenort verschieben fertig (Mac).** Der Standardordner `…/Iris/forgejo` wird nach dem Verschieben ein Verweis auf den neuen Ort; Konfiguration (absolute Pfade), launchd-Dienst und Backup bleiben unverändert. Ablauf: Platz am Ziel prüfen → Dienst anhalten → rsync → Umschalten → Dienst starten und prüfen → erst dann das Alte löschen; bei jedem Fehler Rollback. Auch „zurück an den Standardort". Route `POST /forgejo/move-data`, Abschnitt „Datenort" in Einstellungen → Git-Server (Ordnerwahl nur, wenn Iris und Server auf demselben Mac laufen). Linux: Volume in der Compose-Datei, nicht per Route. **Geprüft:** `test-forgejo-core.sh` 91 Prüfungen gegen echten Forgejo 17 (hinaus, Anmeldung am neuen Ort, unzulässiges/nicht leeres Ziel abgelehnt, zurück, Altdaten entfernt); Iris und IrisClient bauen. **Nicht bedient:** Oberfläche, echtes Verschieben auf eine externe Platte mit großem Bestand.
alf commented 2026-10-20 17:19:57 +00:00
Author
Owner
Copy link

PR #119 gemergt: fix(onboarding): nach Dieser Rechner mit leerem Vault geht es weiter statt zu haengen (iris/Iris#112)
#119

Commits:

  • fix(onboarding): nach Dieser Rechner mit leerem Vault geht es weiter statt zu haengen (iris/Iris#112)
PR #119 gemergt: fix(onboarding): nach Dieser Rechner mit leerem Vault geht es weiter statt zu haengen (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/119 Commits: - fix(onboarding): nach Dieser Rechner mit leerem Vault geht es weiter statt zu haengen (iris/Iris#112)
alf commented 2026-10-20 17:24:01 +00:00
Author
Owner
Copy link

PR #120 gemergt: fix(onboarding): erst das Vault, dann der Git-Server; Vault von Forgejo holen statt verbinden (iris/Iris#112)
#120

Commits:

  • fix(onboarding): erst das Vault, dann der Git-Server; Vault von Forgejo holen statt verbinden (iris/Iris#112)
PR #120 gemergt: fix(onboarding): erst das Vault, dann der Git-Server; Vault von Forgejo holen statt verbinden (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/120 Commits: - fix(onboarding): erst das Vault, dann der Git-Server; Vault von Forgejo holen statt verbinden (iris/Iris#112)
alf commented 2026-10-20 17:46:10 +00:00
Author
Owner
Copy link

PR #121 gemergt: fix(onboarding): Weiche mit vier Wegen, nach dem Vault-Schritt immer mit einem Forgejo verbunden (iris/Iris#112)
#121

Commits:

  • fix(onboarding): Weiche mit vier Wegen, nach dem Vault-Schritt immer mit einem Forgejo verbunden (iris/Iris#112)
PR #121 gemergt: fix(onboarding): Weiche mit vier Wegen, nach dem Vault-Schritt immer mit einem Forgejo verbunden (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/121 Commits: - fix(onboarding): Weiche mit vier Wegen, nach dem Vault-Schritt immer mit einem Forgejo verbunden (iris/Iris#112)
alf commented 2026-10-20 18:37:34 +00:00
Author
Owner
Copy link

PR #68 gemergt: fix(deploy): Browser-Port je Instanz statt fest 8095, Server findet ihn ueber die Docker-API (iris/Iris#112)
iris/iris-linux-server#68

Commits:

  • fix(deploy): Browser-Port je Instanz statt fest 8095, Server findet ihn ueber die Docker-API (iris/Iris#112)
PR #68 gemergt: fix(deploy): Browser-Port je Instanz statt fest 8095, Server findet ihn ueber die Docker-API (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/68 Commits: - fix(deploy): Browser-Port je Instanz statt fest 8095, Server findet ihn ueber die Docker-API (iris/Iris#112)
alf commented 2026-10-20 18:37:35 +00:00
Author
Owner
Copy link

PR #124 gemergt: fix(deploy): freier Host-Port fuer den Browser-Dienst beim Erstellen eines Linux-Servers (iris/Iris#112)
#124

Commits:

  • fix(deploy): freier Host-Port fuer den Browser-Dienst beim Erstellen eines Linux-Servers (iris/Iris#112)
PR #124 gemergt: fix(deploy): freier Host-Port fuer den Browser-Dienst beim Erstellen eines Linux-Servers (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/124 Commits: - fix(deploy): freier Host-Port fuer den Browser-Dienst beim Erstellen eines Linux-Servers (iris/Iris#112)
alf commented 2026-10-20 19:19:06 +00:00
Author
Owner
Copy link

PR #69 gemergt: fix(hermes): venv-Aufbau von Skills mit langem Exec-Timeout statt 120 s (iris/Iris#112)
iris/iris-linux-server#69

Commits:

  • fix(hermes): venv-Aufbau von Skills mit langem Exec-Timeout statt 120 s (iris/Iris#112)
PR #69 gemergt: fix(hermes): venv-Aufbau von Skills mit langem Exec-Timeout statt 120 s (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/69 Commits: - fix(hermes): venv-Aufbau von Skills mit langem Exec-Timeout statt 120 s (iris/Iris#112)
alf commented 2026-10-20 19:37:50 +00:00
Author
Owner
Copy link

PR #125 gemergt: fix(vault-sync): Klon-Adresse aus der Anmeldung statt aus der clone_url des Forgejo (iris/Iris#112)
#125

Commits:

  • fix(vault-sync): Klon-Adresse aus der Anmeldung statt aus der clone_url des Forgejo (iris/Iris#112)
PR #125 gemergt: fix(vault-sync): Klon-Adresse aus der Anmeldung statt aus der clone_url des Forgejo (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/125 Commits: - fix(vault-sync): Klon-Adresse aus der Anmeldung statt aus der clone_url des Forgejo (iris/Iris#112)
alf commented 2026-10-20 19:37:52 +00:00
Author
Owner
Copy link

PR #71 gemergt: fix(vault-sync): Klon-Adresse aus der Anmeldung statt aus der clone_url des Forgejo (iris/Iris#112)
iris/iris-linux-server#71

Commits:

  • fix(vault-sync): Klon-Adresse aus der Anmeldung statt aus der clone_url des Forgejo (iris/Iris#112)
PR #71 gemergt: fix(vault-sync): Klon-Adresse aus der Anmeldung statt aus der clone_url des Forgejo (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/71 Commits: - fix(vault-sync): Klon-Adresse aus der Anmeldung statt aus der clone_url des Forgejo (iris/Iris#112)
alf commented 2026-10-20 21:02:15 +00:00
Author
Owner
Copy link

PR #126 gemergt: fix(forgejo): Freigabe nennt sich mit der IP, Adresse wird bei IP-Wechsel nachgezogen (iris/Iris#112)
#126

Commits:

  • fix(forgejo): Freigabe nennt sich mit der IP, Adresse wird bei IP-Wechsel nachgezogen (iris/Iris#112)
PR #126 gemergt: fix(forgejo): Freigabe nennt sich mit der IP, Adresse wird bei IP-Wechsel nachgezogen (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/126 Commits: - fix(forgejo): Freigabe nennt sich mit der IP, Adresse wird bei IP-Wechsel nachgezogen (iris/Iris#112)
alf commented 2026-10-20 21:25:13 +00:00
Author
Owner
Copy link

PR #127 gemergt: fix(deploy): Server komplett loeschen auch mit root-eigenen Dateien aus Containern (iris/Iris#112)
#127

Commits:

  • fix(deploy): Server komplett loeschen auch mit root-eigenen Dateien aus Containern (iris/Iris#112)
PR #127 gemergt: fix(deploy): Server komplett loeschen auch mit root-eigenen Dateien aus Containern (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/127 Commits: - fix(deploy): Server komplett loeschen auch mit root-eigenen Dateien aus Containern (iris/Iris#112)
alf commented 2026-10-20 21:54:51 +00:00
Author
Owner
Copy link

PR #72 gemergt: fix(hermes): Seed-Kopie atomar mit Marker, halb befuellte Instanz wird repariert (iris/Iris#112)
iris/iris-linux-server#72

Commits:

  • fix(hermes): Seed-Kopie atomar mit Marker, halb befuellte Instanz wird repariert (iris/Iris#112)
PR #72 gemergt: fix(hermes): Seed-Kopie atomar mit Marker, halb befuellte Instanz wird repariert (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/72 Commits: - fix(hermes): Seed-Kopie atomar mit Marker, halb befuellte Instanz wird repariert (iris/Iris#112)
alf commented 2026-10-20 22:22:15 +00:00
Author
Owner
Copy link

PR #128 gemergt: fix(onboarding): Assistent fuer eine neue Verbindung ersetzt ein offen gebliebenes Fenster (iris/Iris#112)
#128

Commits:

  • fix(onboarding): Assistent fuer eine neue Verbindung ersetzt ein offen gebliebenes Fenster (iris/Iris#112)
PR #128 gemergt: fix(onboarding): Assistent fuer eine neue Verbindung ersetzt ein offen gebliebenes Fenster (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/128 Commits: - fix(onboarding): Assistent fuer eine neue Verbindung ersetzt ein offen gebliebenes Fenster (iris/Iris#112)
alf commented 2026-10-20 22:28:09 +00:00
Author
Owner
Copy link

PR #129 gemergt: fix(onboarding): geschlossenes Assistenten-Fenster wird freigegeben, kein unsichtbares Altfenster mehr (iris/Iris#112)
#129

Commits:

  • fix(onboarding): geschlossenes Assistenten-Fenster wird freigegeben, kein unsichtbares Altfenster mehr (iris/Iris#112)
PR #129 gemergt: fix(onboarding): geschlossenes Assistenten-Fenster wird freigegeben, kein unsichtbares Altfenster mehr (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/129 Commits: - fix(onboarding): geschlossenes Assistenten-Fenster wird freigegeben, kein unsichtbares Altfenster mehr (iris/Iris#112)
alf closed this issue 2026-10-24 21:18:44 +00:00
alf commented 2026-10-28 09:13:16 +00:00
Author
Owner
Copy link

PR #212 gemergt: fix(git-server): Fehlermeldung nach Aktion bleibt sichtbar, z. B. abgelehnte Freigabe (#112)
#212

Commits:

  • fix(git-server): Fehlermeldung nach Aktion bleibt sichtbar, z. B. abgelehnte Freigabe (#112)

Stand: „Freigeben“ auf dem Linux-Server zeigte keine Rückmeldung

  • Befund: POST /forgejo/sharing antwortet auf dem Linux-Server absichtlich mit 409 sharing_unsupported (Docker, kein veröffentlichter Port). Der Fehlertext wurde gesetzt, aber vom refresh() direkt danach gelöscht, weil run() die Meldung zu Beginn leert. Der Schalter sprang zurück, sonst passierte nichts.
  • Geändert: refresh() behält die Meldung der vorangegangenen Aktion (keepMessage). Das betrifft alle Aktionen der Git-Server-Einstellungen (Freigabe, Einrichten, Installieren, Datenort), nicht nur die Freigabe.
  • Geprüft: Xcode-Build von Iris erfolgreich; Ursache im Code nachvollzogen.
  • Nicht geprüft: Nicht bedient, die Meldung wurde nicht gesehen.
  • Offen: Der Linux-Server kann sich weiterhin nicht freigeben; sein Forgejo ist nur im Docker-Netz erreichbar (http://forgejo:3300, kein Host-Port). Ob und wie das gebaut wird, ist noch nicht entschieden.
PR #212 gemergt: fix(git-server): Fehlermeldung nach Aktion bleibt sichtbar, z. B. abgelehnte Freigabe (#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/212 Commits: - fix(git-server): Fehlermeldung nach Aktion bleibt sichtbar, z. B. abgelehnte Freigabe (#112) --- **Stand: „Freigeben“ auf dem Linux-Server zeigte keine Rückmeldung** - **Befund:** `POST /forgejo/sharing` antwortet auf dem Linux-Server absichtlich mit 409 `sharing_unsupported` (Docker, kein veröffentlichter Port). Der Fehlertext wurde gesetzt, aber vom `refresh()` direkt danach gelöscht, weil `run()` die Meldung zu Beginn leert. Der Schalter sprang zurück, sonst passierte nichts. - **Geändert:** `refresh()` behält die Meldung der vorangegangenen Aktion (`keepMessage`). Das betrifft alle Aktionen der Git-Server-Einstellungen (Freigabe, Einrichten, Installieren, Datenort), nicht nur die Freigabe. - **Geprüft:** Xcode-Build von Iris erfolgreich; Ursache im Code nachvollzogen. - **Nicht geprüft:** Nicht bedient, die Meldung wurde nicht gesehen. - **Offen:** Der Linux-Server kann sich weiterhin nicht freigeben; sein Forgejo ist nur im Docker-Netz erreichbar (`http://forgejo:3300`, kein Host-Port). Ob und wie das gebaut wird, ist noch nicht entschieden.
alf commented 2026-10-28 09:31:25 +00:00
Author
Owner
Copy link

PR #106 gemergt: feat(forgejo): Freigabe des Git-Servers auch auf dem Linux-Server (iris/Iris#112)
iris/iris-linux-server#106

Commits:

  • feat(forgejo): Freigabe des Git-Servers auch auf dem Linux-Server (iris/Iris#112)

Stand (Linux-Server): „Für andere Rechner freigeben“ funktioniert jetzt auch auf dem Linux-Server

  • Befund: POST /forgejo/sharing lehnte auf Linux mit 409 sharing_unsupported ab; der Forgejo lief ohne Host-Port nur im Docker-Netz.
  • Geändert: Neues Modul app/forgejo_sharing.py. Freigegeben lauscht der server-Prozess auf Port 3300 (neu in docker-compose.yml am Dienst server veröffentlicht), spricht HTTPS mit einem Zertifikat der Iris-CA dieses Servers (Kette mit CA, Fingerabdruck = CA) und leitet an forgejo:3300 weiter. ROOT_URL/DOMAIN schreibt der Server in die app.ini des Forgejo und startet ihn neu (die beiden Umgebungsvariablen stehen nicht mehr in der Compose-Datei). Zustand in forgejo-sharing.json, Wiederaufnahme beim Serverstart, Rückfall bei Fehlern. Für die Anhang-Links der freigegebenen Adresse vertraut vault_git_sync der Iris-CA und meldet sich dort an (git-lfs wendet insteadOf nicht an; gefunden beim Test). Fehlercodes: compose_outdated, port_in_use, host_required.
  • Geprüft: Neue Tests test_forgejo_sharing.py (u. a. echte TLS-Weiterleitung, Kette, Rückfall, Neustart) plus die bestehenden Forgejo-/Sync-Tests grün (lokal). Live auf alf@iris-server per rsync-Deploy: Freigabe ein → TLS auf 3300 mit Kette Git-Server + CA, Fingerabdruck stimmt, /api/healthz mit der CA; LFS-Push und -Klon (2 MB) vom Mac über https://192.168.178.153:3300 mit gleichem Inhalt; LFS-Klon des Servers selbst über die freigegebene Adresse; Neustart des Servers nimmt die Weiterleitung wieder auf; Freigabe aus → Port zu, app.ini zurück auf intern. Danach wieder ausgeschaltet.
  • Nicht geprüft: Bedienung aus der Mac-App (Schalter in Einstellungen → Git-Server …); Verbinden eines zweiten Rechners über „Anderer Forgejo“; Deploy-Vorlage deployment/docker-compose.deploy.yml.template (hat Port 3300 nicht, mehrere Instanzen pro Host bräuchten je einen eigenen Port); Adresswechsel (DHCP) bei freigegebenem Server (Freigabe aus- und einschalten).
  • Auffall am Rande: Das Vault auf iris-server selbst meldet beim Sync cannot open '.git/FETCH_HEAD': Permission denied (Rechte im Vault-.git), unabhängig von der Freigabe; nicht angefasst.
PR #106 gemergt: feat(forgejo): Freigabe des Git-Servers auch auf dem Linux-Server (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/106 Commits: - feat(forgejo): Freigabe des Git-Servers auch auf dem Linux-Server (iris/Iris#112) --- **Stand (Linux-Server): „Für andere Rechner freigeben“ funktioniert jetzt auch auf dem Linux-Server** - **Befund:** `POST /forgejo/sharing` lehnte auf Linux mit 409 `sharing_unsupported` ab; der Forgejo lief ohne Host-Port nur im Docker-Netz. - **Geändert:** Neues Modul `app/forgejo_sharing.py`. Freigegeben lauscht der `server`-Prozess auf Port 3300 (neu in `docker-compose.yml` am Dienst `server` veröffentlicht), spricht HTTPS mit einem Zertifikat der Iris-CA dieses Servers (Kette mit CA, Fingerabdruck = CA) und leitet an `forgejo:3300` weiter. `ROOT_URL`/`DOMAIN` schreibt der Server in die `app.ini` des Forgejo und startet ihn neu (die beiden Umgebungsvariablen stehen nicht mehr in der Compose-Datei). Zustand in `forgejo-sharing.json`, Wiederaufnahme beim Serverstart, Rückfall bei Fehlern. Für die Anhang-Links der freigegebenen Adresse vertraut `vault_git_sync` der Iris-CA und meldet sich dort an (git-lfs wendet `insteadOf` nicht an; gefunden beim Test). Fehlercodes: `compose_outdated`, `port_in_use`, `host_required`. - **Geprüft:** Neue Tests `test_forgejo_sharing.py` (u. a. echte TLS-Weiterleitung, Kette, Rückfall, Neustart) plus die bestehenden Forgejo-/Sync-Tests grün (lokal). Live auf `alf@iris-server` per rsync-Deploy: Freigabe ein → TLS auf 3300 mit Kette Git-Server + CA, Fingerabdruck stimmt, `/api/healthz` mit der CA; LFS-Push und -Klon (2 MB) vom Mac über `https://192.168.178.153:3300` mit gleichem Inhalt; LFS-Klon des Servers selbst über die freigegebene Adresse; Neustart des Servers nimmt die Weiterleitung wieder auf; Freigabe aus → Port zu, `app.ini` zurück auf intern. Danach wieder ausgeschaltet. - **Nicht geprüft:** Bedienung aus der Mac-App (Schalter in Einstellungen → Git-Server …); Verbinden eines zweiten Rechners über „Anderer Forgejo“; Deploy-Vorlage `deployment/docker-compose.deploy.yml.template` (hat Port 3300 nicht, mehrere Instanzen pro Host bräuchten je einen eigenen Port); Adresswechsel (DHCP) bei freigegebenem Server (Freigabe aus- und einschalten). - **Auffall am Rande:** Das Vault auf iris-server selbst meldet beim Sync `cannot open '.git/FETCH_HEAD': Permission denied` (Rechte im Vault-`.git`), unabhängig von der Freigabe; nicht angefasst.
alf commented 2026-10-28 09:31:27 +00:00
Author
Owner
Copy link

PR #213 gemergt: feat(git-server): Meldungen der Freigabe auf dem Linux-Server, Handbuch (#112)
#213

Commits:

  • feat(git-server): Meldungen der Freigabe auf dem Linux-Server, Handbuch (#112)

Stand (App): Meldungen der Freigabe für den Linux-Server; Handbuch

  • Geändert: Neue Fehlertexte in den Git-Server-Einstellungen für compose_outdated, port_in_use, host_required; sharing_unsupported nicht mehr als Docker-Hinweis. Handbuchkapitel „Vault-Synchronisation“: Hinweis zur Compose-Datei und zum Adresswechsel statt „Linux kann nicht freigeben“. Server-Teil: iris-linux-server (eigener PR), Wire-Doku im Wurzel-Repo.
  • Geprüft: Xcode-Build von Iris erfolgreich.
  • Nicht geprüft: Bedienung des Schalters gegen den Linux-Server aus der App.
PR #213 gemergt: feat(git-server): Meldungen der Freigabe auf dem Linux-Server, Handbuch (#112) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/213 Commits: - feat(git-server): Meldungen der Freigabe auf dem Linux-Server, Handbuch (#112) --- **Stand (App): Meldungen der Freigabe für den Linux-Server; Handbuch** - **Geändert:** Neue Fehlertexte in den Git-Server-Einstellungen für `compose_outdated`, `port_in_use`, `host_required`; `sharing_unsupported` nicht mehr als Docker-Hinweis. Handbuchkapitel „Vault-Synchronisation“: Hinweis zur Compose-Datei und zum Adresswechsel statt „Linux kann nicht freigeben“. Server-Teil: iris-linux-server (eigener PR), Wire-Doku im Wurzel-Repo. - **Geprüft:** Xcode-Build von Iris erfolgreich. - **Nicht geprüft:** Bedienung des Schalters gegen den Linux-Server aus der App.
alf commented 2026-10-28 09:31:30 +00:00
Author
Owner
Copy link

PR #126 gemergt: docs(wire): Freigabe des Git-Servers auf dem Linux-Server (iris/Iris#112)
alf/2ndbrain#126

Commits:

  • docs(wire): Freigabe des Git-Servers auf dem Linux-Server (iris/Iris#112)
PR #126 gemergt: docs(wire): Freigabe des Git-Servers auf dem Linux-Server (iris/Iris#112) https://forgejo.lewerken.duckdns.org/alf/2ndbrain/pulls/126 Commits: - docs(wire): Freigabe des Git-Servers auf dem Linux-Server (iris/Iris#112)
alf commented 2026-10-28 09:55:19 +00:00
Author
Owner
Copy link

PR #109 gemergt: fix(forgejo): fehlende Dateien der Freigabe nachgereicht (iris/Iris#112)
iris/iris-linux-server#109

Commits:

  • fix(forgejo): fehlende Dateien der Freigabe nachgereicht (iris/Iris#112)

Nachtrag zu iris-linux-server#106: fehlende Dateien

  • Befund: PR #106 (Freigabe des Git-Servers auf dem Linux-Server) wurde ohne -a eingereicht. app/forgejo_sharing.py und tests/test_forgejo_sharing.py fehlten im Repository, während forgejo_routes.py und forgejo_service.py das Modul schon importierten. Ein Build aus main (z. B. über die Registry) wäre beim Start mit ImportError gescheitert. Der Dev-Host lief nicht betroffen, weil dort per rsync vom lokalen Stand deployt wurde.
  • Geändert: Beide Dateien nachgereicht, unverändert gegenüber dem deployten und getesteten Stand.
  • Geprüft: rsync -n zeigt keinen Unterschied zwischen lokalem Stand und iris-server.
  • Nicht geprüft: Ein frischer Build aus main wurde nicht gestartet.
PR #109 gemergt: fix(forgejo): fehlende Dateien der Freigabe nachgereicht (iris/Iris#112) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/109 Commits: - fix(forgejo): fehlende Dateien der Freigabe nachgereicht (iris/Iris#112) --- **Nachtrag zu iris-linux-server#106: fehlende Dateien** - **Befund:** PR #106 (Freigabe des Git-Servers auf dem Linux-Server) wurde ohne `-a` eingereicht. `app/forgejo_sharing.py` und `tests/test_forgejo_sharing.py` fehlten im Repository, während `forgejo_routes.py` und `forgejo_service.py` das Modul schon importierten. Ein Build aus `main` (z. B. über die Registry) wäre beim Start mit `ImportError` gescheitert. Der Dev-Host lief nicht betroffen, weil dort per rsync vom lokalen Stand deployt wurde. - **Geändert:** Beide Dateien nachgereicht, unverändert gegenüber dem deployten und getesteten Stand. - **Geprüft:** `rsync -n` zeigt keinen Unterschied zwischen lokalem Stand und iris-server. - **Nicht geprüft:** Ein frischer Build aus `main` wurde nicht gestartet.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
  
herkunft/alpha-feedback
Aus Rückmeldungen der Alpha-Tester

  
status
blockiert
 Wartet auf etwas anderes

  
status
zu-testen
 Gebaut, aber noch nicht im echten Einsatz geprüft

  
typ
bug
 Fehler

  
typ
docs
 Dokumentation

  
typ
enhancement
 Verbesserung einer vorhandenen Funktion

  
typ
feature
 Neue Funktion

  
typ
idea
 Idee, noch nicht entschieden

No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
iris/Iris#112
No description provided.