Forgejo im Alltag betreiben

Einleitung

Dieser Artikel beginnt dort, wo die eigentliche Installation aufhört: Forgejo läuft, der Reverse Proxy liefert HTTPS aus und der erste Administrator kann sich anmelden. Ab jetzt geht es um Benutzer, Projekte, Benachrichtigungen, Updates und die Frage, ob sich die Sicherung im Ernstfall tatsächlich wiederherstellen lässt.

Alle Domains, Adressen und Konten sind Beispiele. Der technische Aufbau der Instanz wird im getrennten Artikel Forgejo sicher mit PostgreSQL und Reverse Proxy betreiben beschrieben.

Administrator und Alltagskonto

Der bei der Installation angelegte Administrator eignet sich gut als Notfallkonto. Für die tägliche Arbeit ist ein normales persönliches Konto angenehmer und begrenzt nebenbei die Folgen eines gestohlenen Tokens oder einer unbedachten Aktion.

Für das Administratorkonto gehören ein langes, einmaliges Kennwort, MFA und die separat abgelegten Recovery-Codes zur Grundausstattung. Mindestens ein Wiederherstellungsweg sollte ohne Zugriff auf Forgejo funktionieren. Bei mehreren Administratoren ist außerdem klar festzuhalten, wem welches Konto gehört; gemeinsam verwendete Konten machen die spätere Nachvollziehbarkeit unnötig schwer.

Benutzer aufnehmen und entfernen

Auf einer geschlossenen Instanz bleibt die öffentliche Registrierung deaktiviert. Neue Benutzer werden durch einen Administrator angelegt und ändern beim ersten Login ihr Startkennwort. MFA wird direkt beim ersten Zugriff eingerichtet, die Recovery-Codes landen im persönlichen Passwortmanager.

Zum Onboarding gehören außerdem:

• ein persönlicher SSH-Schlüssel pro Gerät oder ein entsprechend eng begrenztes Zugriffstoken
• nur die Organisationen und Teams, die wirklich gebraucht werden
• ein kurzer Test von Clone und Push
• eine erreichbare Mailadresse für Benachrichtigungen und Kontowiederherstellung

Beim Offboarding werden Sitzungen, Tokens und SSH-Schlüssel widerrufen. Das Konto kann zunächst gesperrt werden, während Repositories und offene Aufgaben in Ruhe übertragen werden. Erst danach wird entschieden, ob es gelöscht werden soll.

Persönliche Projekte, Organisationen und Teams

Persönliche Repositories passen gut für Experimente, Notizen und Projekte mit nur einem Verantwortlichen. Sobald mehrere Personen dauerhaft zusammenarbeiten, ist eine Organisation übersichtlicher. Teams bilden darin Rollen wie Lesen, Entwickeln oder Verwalten ab, ohne jedes Repository einzeln freigeben zu müssen.

Ein paar einfache Regeln reichen meist aus:

• Repositories bleiben standardmäßig privat.
• Der Standardbranch ist gegen versehentliches Löschen und Force-Push geschützt.
• Releases und wichtige Tags dürfen nicht unbemerkt überschrieben werden.
• Administratorrechte sind selten; Schreibrechte werden über Teams vergeben.
• Actions, Packages und weitere Funktionen werden erst aktiviert, wenn es dafür einen konkreten Bedarf und ein passendes Sicherheitskonzept gibt.

Projekte von GitHub oder Codeberg übernehmen

Für einen einmaligen Umzug ist die Forgejo-Migration bequemer als ein manuelles Kopieren. Je nach Quelle können dabei Git-Historie, Branches, Tags, Issues, Releases und weitere Metadaten übernommen werden. Vorher lohnt sich ein Blick auf Git LFS, Submodule und externe Paketquellen, weil diese nicht immer vollständig im normalen Repository stecken.

Ein Zugriffstoken der Quellplattform bekommt nur die für die Migration nötigen Rechte und wird danach wieder widerrufen. Das Zielrepository wird zunächst privat angelegt und stichprobenartig geprüft: Branches, Tags, Issues, Releases, LFS-Dateien und ein frischer Clone gehören dazu.

Ein Mirror ist sinnvoll, wenn die alte Plattform noch eine Zeit lang führend bleiben soll. Für einen endgültigen Umzug ist ein klarer Umschalttermin meist leichter zu verstehen: Quelle schreibgeschützt setzen, letzte Änderung holen, Ziel prüfen und anschließend alle lokalen Remotes umstellen.

Zugriff per SSH und HTTPS

Git-over-SSH bleibt am besten auf interne Netze oder ein VPN begrenzt. Pro Gerät wird ein eigener ED25519-Schlüssel hinterlegt; dann lässt sich ein verlorenes Gerät sperren, ohne alle anderen Zugänge zu ändern.

Für HTTPS werden persönliche Zugriffstoken statt des Kontokennworts verwendet. Ein Token bekommt nur die benötigten Repository- und Paketberechtigungen, einen aussagekräftigen Namen und möglichst ein Ablaufdatum. Tokens gehören weder in Remote-URLs noch in Skripte oder Shell-Historien. Die Zugangsdatenverwaltung des Betriebssystems ist dafür der passendere Ort.

Obsidian in einem privaten Repository

Ein Obsidian-Vault lässt sich gut als privates Git-Repository führen. Git ist dabei Versionsverwaltung, aber keine konfliktfreie Echtzeitsynchronisation. Vor dem Wechsel zwischen Geräten sollte deshalb jeweils synchronisiert werden.

Meist werden lokale Arbeitsbereichsdateien ignoriert, beispielsweise:

.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/

Die übrigen Obsidian-Einstellungen können bewusst versioniert werden, wenn alle Geräte dieselben Plugins und Darstellungsoptionen verwenden sollen. Kennwörter, API-Schlüssel und andere Secrets gehören trotzdem nicht in den Vault. Große Anhänge können Git LFS sinnvoll machen; vorher sollte geprüft werden, ob alle verwendeten Mobil-Clients damit zuverlässig umgehen.

E-Mail und Benachrichtigungen

Ein funktionierendes Mailrelay ist für Einladungen, Benachrichtigungen und die Kontowiederherstellung wichtig. Das SMTP-Kennwort liegt in einer geschützten Secret-Datei und wird nicht direkt in die Compose-Datei geschrieben. Ein neutrales Beispiel verwendet smtp.example.com, SMTPS auf Port 465 und einen Absender wie forgejo@example.com.

Nach der Einrichtung wird aus der Administration eine Testmail an ein externes Postfach verschickt. Dabei werden Absender, Betreffpräfix, Spam-Einstufung und die Links in der Nachricht geprüft. Für eine eigene Absenderdomain sollten SPF, DKIM und DMARC beim Mailanbieter passend eingerichtet sein.

Updates ohne Überraschungen

Patch-Updates lassen sich regelmäßig einplanen. Vor einem Major-Upgrade werden die Forgejo-Hinweise gelesen und ein aktuelles, überprüfbares Backup erstellt. Nach dem Update reichen nicht nur grüne Containeranzeigen; mindestens Anmeldung, Clone, Push, LFS, Mailversand und Datenbank werden praktisch geprüft.

cd /srv/forgejo
sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps
sudo docker exec forgejo forgejo doctor check --all

Host-Updates laufen getrennt davon. Nach Kernel- oder systemd-Updates wird die VM in einem geplanten Fenster neu gestartet und derselbe kurze Funktionstest wiederholt.

Backup und Wiederherstellung

Zu einer vollständigen Sicherung gehören Forgejo-Daten, Git-Repositories, LFS, Releases, Packages, PostgreSQL, Compose-Datei und alle Secrets. Ein tägliches VM-Backup ist eine gute Grundlage. Zusätzliche PostgreSQL-Dumps sind praktisch, wenn nicht immer die vollständige VM zurückgeholt werden soll.

Wichtig ist der Restore-Test: In einer isolierten Umgebung werden Datenbank und Anwendung aus der Sicherung gestartet. Danach folgen Anmeldung, Repository-Clone, Push, LFS und MFA. Ein erfolgreich beendeter Backupjob allein beantwortet diese Fragen noch nicht.

Vor einem Restore wird geprüft, welchen Stand die Sicherung hat und welche Änderungen danach verloren gingen. Die Produktionsinstanz bleibt währenddessen gestoppt oder schreibgeschützt, damit keine zwei voneinander abweichenden Stände entstehen.

Speicher und Wachstum

Überwacht werden vor allem das Forgejo-Datenlaufwerk, Docker-Daten, Root-Dateisystem und Protokolle. Bei LVM kann eine weitere Platte als Physical Volume zur bestehenden Volume Group kommen; XFS wird anschließend zusammen mit dem Logical Volume online erweitert. Vor jeder Speicheränderung werden Gerätename, vorhandene Signaturen und das aktuelle Backup kontrolliert.

Warnschwellen sollten früh genug greifen, damit noch Zeit zum Aufräumen oder Erweitern bleibt. Besonders LFS, Releases, Packages und Containerlogs wachsen oft schneller als die eigentliche Git-Historie.

Regelmäßiger Kurzcheck

Ein monatlicher Blick auf diese Punkte hält den Aufwand überschaubar:

• Healthchecks und unerwartete Container-Neustarts
• freier Speicher und freie LVM-Extents
• fehlgeschlagene Anmeldung, auffällige Tokens und SSH-Schlüssel
• Mailqueue und fehlgeschlagene Zustellungen
• verfügbare Forgejo- und Betriebssystemupdates
• Ergebnis der letzten Sicherung und Termin des letzten Restore-Tests
• Benutzer, Organisationen und Teams, die nicht mehr gebraucht werden

Nach größeren Änderungen kommt ein kleiner Praxistest hinzu: anmelden, ein privates Repository klonen, eine Änderung pushen und eine Testmail senden. Damit werden die Wege geprüft, die im Alltag tatsächlich zählen.