Gitea Organisationen

Stand: 2026-05-20

Zweck

Die Gitea-Organisationen trennen interne Lanstyle-Repositories, private Repositories und Kundenprojekte voneinander. Das ist für MSP-Arbeit sinnvoll, weil Rechte, Deploy-Token, Webhooks und spätere Automationen pro Mandant sauber getrennt werden können.

Produktive Repositories sollten bevorzugt in Organisationen liegen. User-Repositories bleiben für persönliche Tests und Experimente.

Angelegte Organisationen

Slug	Anzeigename	Zweck
lanstyle	Lanstyle IT Solutions GmbH	interne Repositories, Infrastruktur, Automationen, Templates
tecmed-deutschland	TecMed Deutschland GmbH	Kundenorganisation
artis-immobilienverwaltung	ARTIS Immobilienverwaltung GmbH	Kundenorganisation
hauck	Hauck GmbH & Co. KG	Kundenorganisation
salzmannschule-schnepfenthal	Salzmannschule Schnepfenthal	Kundenorganisation
sportgymnasium-oberhof	Sportgymnasium Oberhof	Kundenorganisation
sportgymnasium-jena	Sportgymnasium Jena	Kundenorganisation
sportgymnasium-erfurt	Sportgymnasium Erfurt	Kundenorganisation
musikgymnasium-belvedere-weimar	Musikgymnasium Schloss Belvedere Weimar	Kundenorganisation
privat-eberhardt	Privat / Eberhardt	private Repositories
probefox	ProbeFox GmbH	Kundenorganisation
xam	XAM GmbH	Kundenorganisation
drk-muldenthal	Deutsches Rotes Kreuz Muldenthal	Kundenorganisation
fsg-energy	FSG Energy GmbH & Co. KG	Kundenorganisation
speed-clever-leben	Speed Clever Leben Versicherungsservice GmbH	Kundenorganisation

Basis-Repositories

Für jede Organisation wurde ein privates Repository dokumentation angelegt.

Dieses Repository ist der Startpunkt für OpenCode und enthält initial:

• AGENTS.md
• README.md
• Kunden-/Organisationskontext
• Quellenhinweise zu Gitea, Wiki, NetBox und Vaultwarden
• keine Secrets

Die lokalen OpenCode-Projektordner unter /Users/vinc32/Documents/OpenCode-Projekte/* sind jeweils mit dem passenden dokumentation-Repository als origin verbunden und auf Branch main gepusht.

Namenskonvention

• Slugs sind klein geschrieben.
• Umlaute und Sonderzeichen werden vermieden.
• Kundenorganisationen nutzen sprechende, stabile Namen.
• Repos sollten pro Organisation nach Funktion benannt werden, z. B. firewall-backup, dokumentation, powershell-automation.

Empfehlung

• lanstyle/infrastruktur-wiki sollte langfristig das zentrale Wiki-Repository werden.
• Kundenbezogene Repositories nicht unter dem User vinc32, sondern unter der jeweiligen Kundenorganisation anlegen.
• Pro Organisation eigene Teams für Owners, Maintainers und optional ReadOnly verwenden.
• Deploy-Token und Webhooks immer pro Organisation/Repo begrenzen.

Ziel-Berechtigungsmodell

• Maximilian Eberhardt: Owner/Maintainer auf allen Organisationen.
• Bestehende weitere Benutzer: nur eigene Unternehmen und explizit zugewiesene Repositories.
• Marcel Hampel: Schulorganisationen und TecMed.
• René Kulcsar: Schulorganisationen.
• Max Rothe: Schulorganisationen.

Team-Struktur

Am 2026-05-20 wurden nach Datenbank-Backup leere Teams vorbereitet:

• alle Organisationen: Maintainers
• alle Organisationen: ReadOnly
• Schulorganisationen: School Access
• TecMed: TecMed External

Die Teams enthalten noch keine neuen Benutzer. Es existiert aktuell nur der Gitea-Admin-User vinc32; weitere Benutzer werden erst mit E-Mail-Adresse und gewünschtem Usernamen angelegt.

Backup vor der Änderung:

• /var/lib/gitea/data/gitea.db.bak-YYYYMMDD-HHMMSS-before-team-structure

Schulorganisationen:

• salzmannschule-schnepfenthal
• sportgymnasium-oberhof
• sportgymnasium-jena
• sportgymnasium-erfurt
• musikgymnasium-belvedere-weimar

Die neuen Benutzer wurden noch nicht angelegt, weil E-Mail-Adressen und gewünschte Usernamen fehlen. Bis dahin werden keine Platzhalterkonten erzeugt.

Sicherheit

• Keine Kunden-Secrets in Repositories speichern.
• Pro Kunde eigene .gitignore-Vorlagen verwenden.
• Für produktive Automationen dedizierte Service-Accounts oder Repo-Tokens mit minimalen Rechten nutzen.
• Bei externem Zugriff auf Kundenorganisationen Rechte regelmäßig prüfen.