Im ersten Teil des Git-Server-Projekts lag unser Fokus auf der Installation und der grundlegenden Konfiguration. Nun folgt ein grundlegender Blick auf Gogs als Versionskontrollsystem.
Wir haben Gogs hinter Nginx als Reverse Proxy gepackt und verwenden als Datenbank-Backend PostgreSQL statt SQLite. Um nun vernünftig mit dem System arbeiten zu können, sorgen wir zuerst einmal für die entsprechenden Rahmenbedingungen. Alle persönlichen Einstellungen finden Sie im Ausklappmenü des Programms oben rechts in der Menüleiste. Unter Ihre Einstellungen pflegen Sie Ihr Profil inklusive Profilbild, E-Mail-Adressen und so weiter ein (Abbildung 1).
Ein wichtige Rolle spielt dabei außerdem der SSH-Schlüssel. Git erlaubt eine Authentifizierung per Benutzername und Passwort. Allerdings erweist es sich schnell als lästig, bei jeder Interaktion mit dem Server die Zugangsdaten eintippen zu müssen. Deswegen ist es sinnvoll, sich ein kryptografisches Schlüsselpaar zu erzeugen. Dazu bietet Gogs einen Link [1] zur Github-Doku an.
Linux-Nutzer genießen dabei einen gewissen Komfort: Sie erzeugen mit dem simplen Kommando aus der ersten Zeile von Listing 1 ein Schlüsselpaar und laden den Public Key (er endet auf .pub) direkt in Gogs hoch (Abbildung 2). Windows-Nutzer müssen den Umweg über Puttygen [2] gehen und ihren Schlüssel im OpenSSH-Format exportieren. Prinzipiell empfiehlt es sich, den privaten Schlüssel stets mit einer hinreichend komplexen Passphrase zu schützen und den entsperrten Key per SSH-Agent zu cachen. Auf diese Weise ersparen Sie sich zahlreiche Passworteingaben.

Abbildung 2: Der Public Key lässt sich denkbar einfach über eine grafische Oberfläche in Gogs hinterlegen.
Listing 1
Anmeldung
$ ssh-keygen -t ed25519 -C "Adresse@Beispiel.de" $ git clone git@githorst.fritz.box:thomas/testrepo.git
Repos erzeugen und teilen
Nachdem dem Hinterlegen des Public Keys wenden Sie sich quasi der Inneneinrichtung des Git-Servers zu: Sie legen Ihr erstes Repository an. Das klappt am einfachsten über das Pluszeichen in der Menüleiste. Sie landen im Dialog Neues Repository und vergeben darin die relevanten Stammdaten für das Repository, vom Besitzer über den Repo-Namen bis hin zur Lizenz.
Sobald Sie das Repository erzeugt haben, gelangen Sie auf die zugehörige Detailseite, von der aus Sie zunächst per Klick auf SSH und einem anschließenden Klick auf den Copy-Button die entsprechende URL kopieren (Abbildung 3). Ab sofort können Sie sich das Repository lokal auf Ihre Workstation klonen und wie gewohnt mit Git arbeiten (Listing 1, zweite Zeile).
Backup einrichten
Backups mit Gogs lassen sich tatsächlich erfrischend einfach umsetzen. Im Wesentlichen müssen Sie lediglich ./gogs backup tippen (selbstverständlich im entsprechenden Verzeichnis). Manuelle Backups sind nett, automatisierte Backups aber noch besser – und idealerweise klappt zusätzlich ein Restore. Aus Bequemlichkeitsgründen habe ich mir zur Automatisierung ein kleines Bash-Skript angelegt und einen zugehörigen Cronjob erstellt (Listing 2).
Listing 2
gogs-backup.sh
#!/bin/bash
RETENTION=21
BKUP_DIR=/opt/gogs-backups
if [ ! -d "${BKUP_DIR}" ]; then
mkdir -p "${BKUP_DIR}"
chown -R git:root "${BKUP_DIR}"
chmod -R 750 "${BKUP_DIR}"
fi
find "${BKUP_DIR}" -maxdepth 1 -type f -name "gogs-backup-*" -mtime "+${RETENTION}" -delete
su - git -c "/opt/gogs/gogs backup --verbose --target ${BKUP_DIR}"
Backups halte ich 21 Tage vor (Listing 1, Zeile 2). Das Backup-Verzeichnis (Zeile 3) lässt sich beliebig auswählen. In den Zeilen 4 bis 8 generiert das Skript das Backup-Verzeichnis, falls es noch nicht existiert. Das Find-Kommando in Zeile 9 löscht im Backup-Verzeichnis alle veralteten Dateien. Abschließend erzeugt der Code in Zeile 10 das neue Backup.
In meinem Fall liegt das Backup-Skript im Unterordner custom/bin/ der Gogs-Installation. Das hat den großen Vorteil, dass es selbst durch den Befehl gogs backup mitgesichert wird. Eine dedizierte Cron-Tabelle für Gogs könnte deshalb so aussehen wie in Listing 3.
Listing 3
/etc/cron.d/gogs
SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command 04 06 * * * root /opt/gogs/custom/bin/gogs-backup.sh
Benötigen Sie lediglich ein Datenbank-Backup, beispielsweise zwecks Datenbankmigration (SQLite3 nach MariaDB nach PostgreSQL), dann verwenden Sie den Schalter --database-only (Listing 4, erste Zeile). Für diese portablen Backups setzt Gogs auf JSON-Dateien, wobei die Software eine Datei pro Datenbanktabelle erzeugt. Der Restore-Befehl weist darüber hinaus Flags auf, die angeben, ob ausschließlich die Datenbank oder alles im Backup-Archiv wiederhergestellt werden soll (zweite Zeile).
Listing 4
Backup & Restore
$ ./gogs backup --database-only $ ./gogs restore --database-only --from="gogs-backup-xxx.zip"
Stylesheet anpassen
Zum Customizing diverser Templates lesen Sie sich bitte anhand der wichtigsten Artikel aus der Gogs-Dokumentation ein [3]. Unglücklicherweise gingen dem Projektbetreuer im Rahmen einer Migration Teile der Wissensdatenbank verloren, sodass Sie diese bis zur Wiederherstellung nur über die Internet Archive Wayback Machine erreichen [4]. Der Projektverantwortliche schreibt dazu schlicht: “I am not clever enough to migrate and maintain such a complicated software that was used to run discuss.gogs.io, so I’ve broke it. Use Wayback Machine […]”.
Das Aussehen von Gogs lässt sich über ein eigenes CSS-Stylesheet anpassen. Das funktioniert ohne viel Aufwand: Die eigene Stylesheet-Datei richten Sie im Verzeichnis custom/public/css/ ein, etwa als custom.css, und hinterlegen darin die gewünschten CSS-Regeln. Erstellen Sie – falls noch nicht passiert – die Datei custom/templates/inject/head.tmpl und editieren Sie diese, indem Sie die Zeile <link rel="stylesheet" href="/css/custom.css"> hinzufügen.
Bei Anpassungen an Dateien im Ordner inject/ müssen Sie Gogs neu starten. Änderungen am persönlichen Stylesheet dagegen erfordern keine weiteren Neustarts mehr: Die Datei ist schließlich verlinkt und wird über den Webbrowser geladen. Das Favicon lässt sich auf dieselbe Weise anpassen. Es genügt, eine PNG-Datei mit dem Namen favicon.png im Ordner custom/public/img/ abzulegen.
Integration mit Webhooks
Über Git-Hooks können Sie sich in drei Events einklinken und auf den Ausgang von Push- oder Pull-Ereignissen Einfluss nehmen. Sie steuern den Ablauf über die Schnittstellen pre-receive, update und post-receive. Zudem können Sie zum Beispiel die Annahme von Commits durch einen Linter prüfen lassen.
Hinter Webhooks stecken Nachrichten, die durch Ereignisse ausgelöst und an Anwendungen geschickt werden. Technisch gesehen handelt es sich dabei um nichts anderes als HTTP-POST-Requests. Leser und Leserinnen, die mit Tools wie Jira, Hipchat, Slack o.ä. vertraut sind, kennen Chat-Kanäle, in denen beispielsweise Git Pull Requests auflaufen. Dahinter verbergen sich schlicht Webhooks.
Gogs ist ebenfalls in der Lage, Webhooks zu versenden und damit beispielsweise CI/CD-Umgebungen oder ähnliches aufzubauen. Die Software unterstützt derzeit vier Typen von Webhooks: Gogs, Slack, Discord und Dingtalk.
Authentifizierung
Neben der lokalen Anmeldung über die Applikation selbst beherrscht Gogs LDAP, SMTP, PAM und Github als Backends zur Authentifizierung. LDAP ist hier sicher die interessanteste Variante für den Einsatz in Unternehmen. Haben sie die entsprechenden Einträge korrekt ausgefüllt, insbesondere Host, Port oder BindDN, können Domain-Admins die Benutzer sehr flexibel über Gruppenzugehörigkeiten aus dem Active Directory oder sonstigen LDAP-basierten Verzeichnisdiensten steuern.
Das LDAP-Backend ist jedoch darauf angewiesen, dass Domain-User in Gogs tatsächlich als solche existieren. Bevor Domain-Benutzer sich also in Gogs anmelden können, muss der Administrator sie in der Verwaltungsoberfläche anlegen (Abbildung 4).
Fazit
Mit den berühmten Platzhirschen Github, Gitlab und Bitbucket mag Gogs in Sachen Feature-Umfang vermutlich nicht ganz mithalten können. Das stört allerdings insofern nicht weiter, dass Gogs vor allem in Sachen Ressourcenverbrauch punktet: Dank Go läuft die Software auf einem Raspberry Pi der vierten Generation für meine Zwecke überaus flüssig. Nicht nur Git via SSH überzeugt mit Geschwindigkeit und Stabilität, sondern vor allem auch die Weboberfläche.
Die Administration – hier spreche ich von Installation, Benutzerverwaltung, Aktualisierungen und Datensicherung – stellt keine große Herausforderung dar. Deswegen treffen gerade kleinere Teams, die eine On-Premises-Lösung aus verschiedenen Gründen bevorzugen, hier durchaus eine gute Wahl. (csi)
Der Autor
Thomas Reuß ist Linux- sowie SAP-Basis-Administrator und seit über 20 Jahren überzeugter Linux-User. In seiner Freizeit hört er Metal und betreibt mehrere private Server.
Infos
-
SSH-Schlüssel erzeugen: https://docs.github.com/de/authentication/connecting-to-github-with-ssh
-
“How to use PuTTYgen?”: https://www.puttygen.com/#How_to_use_PuTTYgen
-
Gogs-Dokumentation zu Custom-Templates (Web Archive): https://web.archive.org/web/20180521083825/https://discuss.gogs.io/t/how-to-backup-restore-and-migrate/991
-
Gogs-Dokumentation (Web Archive): https://web.archive.org/web/20200806063840/https://discuss.gogs.io/c/how-tos/8








