Zugegeben: Einen selbst gehosteten Git-Service auf einem RasPi einzurichten, erfordert einige Arbeit. Als Belohnung winkt ein ein leistungsfähiges Git-System für die kollaborative und verteilte Arbeit.

Dass sein Git (zu Deutsch: “Depp”) einmal im Handumdrehen die Welt erobern würde, darauf hätte sicherlich selbst Linus Torvalds nicht gewettet. Seit der große Meister 2005 aufgrund lizenzrechtlicher Änderungen am bis dahin für den Kernel genutzten VCS Bitkeeper kurzerhand seine eigene Software entwickelt hat, ist es (zumindest in meiner Bubble) sehr ruhig um die Konkurrenz geworden: Mercurial und Bazaar fristen heute eher ein Nischendasein, scheint es.

Um des Wusts aus Konfigurationsdateien, Vorlagen und beliebigen anderen Textdokumenten Herr zu werden, erschien mir stets die Idee verlockend, über ein eigenes Versionskontrollsystem (VCS) zu verfügen. Dass es außerdem unbedingt ein eigenes – sprich On-Premises – System sein sollte, war mir lange vor der Übernahme von Github klar.

Hardware

Für meine Zwecke sollten sich die Ansprüche an einen Git-Server sehr im Rahmen halten. Git selbst zeigt sich relativ genügsam, und viele gleichzeitig auf der Maschine agierende Nutzer erwarte ich ebenfalls nicht. Damit war die Entscheidung getroffen, dass ein brachliegender Raspberry Pi zum Einsatz kommen würde.

Im Rahmen dieses Artikels verwende ich einen Raspberry Pi 4, ein USB-C-Netzteil und eine SD-Karte mit 64 GByte Speicherplatz. Zum Kaufdatum waren das einmal Waren im Wert von ungefähr 80 Euro. Laufen sollte das Ganze durchaus auch auf einem Raspberry Pi 3B; zumindest liegen die Installationsdateien sowohl für die ARM7- als auch die ARM8-Architektur vor.

RasPi vorbereiten

Als Betriebssystem dient Raspberry Pi OS Lite, auf dem 4er-Modell in der 64-Bit-Variante. Das befördere ich mit dem Raspberry Pi Imager auf die SD-Karte (Abbildung 2). Selbstverständlich könnten Sie dazu alternativ Bordmittel wie Dd nutzen. Dagegen spricht allerdings, dass der Pi Imager diverse Einstellungen schon vorab zu setzen vermag: Man kann beim Schreiben des Abbilds direkt Systembenutzer anlegen, Public Keys hinterlegen und das Gerät direkt ins WLAN aufnehmen.

Abbildung 1: Mithilfe des Raspberry Pi Imagers übertragen Sie Raspberry Pi OS Lite komfortabel auf den RasPi.

Der Pi Imager erweist sich als ausgesprochen benutzerfreundlich. Die Auswahl des Betriebssystemabbilds und die entsprechenden Einstellungen sind schnell getroffen (Abbildung 2). Nach etwa 10 Minuten haben Sie eine bootfähige SD-Karte erzeugt und können direkt loslegen.

Abbildung 2: Die Voreinstellungen über den Pi Imager nehmen nur wenige Minuten in Anspruch.

Zusatzsoftware

Zunächst sollten Sie alle Pakete des Systems aktualisieren. Das funktioniert unter Debian-Abkömmlingen wie Raspberry Pi OS stets mithilfe des Befehls sudo apt update && sudo apt upgrade.

Die Entscheidung für den Git-Service fiel in meinem Fall auf Gogs [1]. Die Software arbeitet ressourcenschonend (nicht zuletzt wegen Go), bringt eine ansprechende, intuitive Oberfläche mit und bietet ein zentrales Management von Repositories. Selbstverständlich gelänge das auch mit Git allein, aber es geht mir hier ja speziell um die Oberfläche.

Prinzipiell läuft Gogs auch ohne Webserver; grundsätzlich genügt es, die Binärdatei auszuführen. Zudem benötigt man dank SQLite theoretisch keine dedizierte Datenbank. Einen Reverse Proxy – ich verwende Nginx – vor dem eigentlichen Dienst halte ich allerdings für unverzichtbar, insbesondere um bestimmte Filter zu ermöglichen. Etwa, dass das Admin-UI nur von bestimmten IP-Adressen überhaupt erreichbar sein darf.

SQLite mag für einfache Demosysteme ausreichen, ich möchte jedoch die Daten lieber in einer richtigen Datenbank wissen. Deshalb habe ich mich für PostgreSQL [2] entschieden. Zu guter Letzt brauchen wir noch die Git-Software. Das entsprechende Installationskommando sehen Sie in der ersten Zeile von Listing 1.

$ sudo apt-get install -y git postgresql postgresql-client libpq-dev nginx
$ wget https://github.com/gogs/gogs/releases/download/v0.13.0/gogs_0.13.0_linux_armv8.tar.gz
$ sudo tar -C /opt/ -xvzf gogs_0.13.0_linux_armv8.tar.gz
$ sudo adduser --disabled-login --uid 2000 --shell /bin/bash git
$ sudo -u postgres psql -d template1
[...]
template1=# CREATE USER gogs CREATEDB;
[...]
template1=# CREATE DATABASE gogs WITH OWNER=gogs;

Gogs-Binärpakete

Auf Github finden sich diverse Archive für Gogs. Für den Raspberry Pi 4 laden Sie via Wget den Tarball gogs_0.13.0_linux_armv8.tar.gz herunter (Listing 1, Zeile 2) und entpacken ihn direkt nach /opt (Zeile 3).

Damit haben Sie die Arbeiten bezüglich der Gogs-Binärpakete abgeschlossen und können sich dem Erstellen eines System-Users zuwenden. Wir werden sämtliche Dateien unter dem Benutzer Git einrichten (Zeile 4).

Datenbank einrichten

Als Nächstes erzeugen Sie einen Datenbankbenutzer (Abbildung 3). Initial verwenden Sie für die Anmeldung die PostgreSQL-Standard-Datenbank template1 (Listing 1, Zeile 5). Danach legen Sie den User mit zugehöriger Datenbank an (Zeile 7).

Abbildung 3: Der frisch erzeugte PostgreSQL-Benutzer bekommt direkt ein sicheres Passwort zugewiesen.

Dem Datenbankbenutzer weisen Sie via \password gogs ein sicheres Passwort zu. Nachdem es im konkreten Fall im Gogs-Setup-Assistenten tatsächlich Probleme mit bestimmten Sonderzeichen gab, empfehle ich, im Passwort auf Anführungszeichen (", ') zu verzichten. Scheinbar gibt es beim (De-)Escaping dieser Zeichen Probleme auf dem Weg von der Webseite bis in die Datenbank. Statt obskure Sonderzeichen einzubauen, setzen Sie besser auf ein längeres Passwort. Legen Sie eine leere Datenbank an und machen Sie den Gogs-User zum Eigentümer (Listing 1, Zeile 9).

Beim Login des PostgreSQL-Benutzers kann noch der Fehler FATAL: Peer authentication failed for user “postgres” auftauchen. In diesem Fall müssen Sie die Datei /etc/postgresql/13/main/pg_hba.conf anpassen. Ist hier kein Authentifizierungsschema für lokale Logins definiert, scheitert die Anmeldung [4]. Die Zeile local all all peer ändern Sie in local all all md5, was diesen Fehler beheben sollte. Damit erlauben Sie passwortgeschützte lokale Datenbank-Logins.

Reverse Proxy

Um Gogs halbwegs vernünftig nutzen zu können, benötigen Sie zumindest ein selbst signiertes Zertifikat. Falls keine eigene Domain vorhanden ist, erzeugen Sie es mittels OpenSSL in einem Rutsch (Listing 2). Das Zertifikat legen Sie in /etc/ssl/certs/ ab, den Key in /etc/ssl/private/.

$ openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout githorst.key -out githorst.crt -subj "/CN=githorst" -addext \
"subjectAltName=DNS:githorst.fritz.box,DNS:githorst,IP:192.168.178.33"
Generating a RSA private key
...................................................++++
............++++
writing new private key to 'githorst.key'
-----
$ sudo apt install certbot
$ sudo certbot -d git.horst.labs --manual --preferred-challenges dns \certonly
[...]
Please deploy a DNS TXT record under the name
_acme-challenge.git.horst.labs with the following value:
667drNmQL3vX6bu8YTquerbou7425234rjF1lSaUndc
Once this is deployed, Press ENTER to continue

Wesentlich sinnvoller ist es jedoch, durch Let’s Encrypt [5] ein richtiges Zertifikat ausstellen zu lassen. Dazu benötigen Sie allerdings eine eigene Domain. Let’s Encrypt kann keine Zertifikate für Subdomains wie http://git.fritz.box anlegen. Diese nutzen Fritzboxen zwar typischerweise für das jeweilige LAN, sie gehört aber der AVM Computersysteme Vertriebs GmbH. Eine Domain erstehen Sie schon für jährlich wenige Euros – umso besser, wenn Sie bereits eine besitzen.

In diesem Fall legen Sie sich einfach eine Subdomain für den Git-Server an, zum Beispiel http://git.horst.labs. Nachdem das ein paar Minuten dauern kann, haben Sie jetzt Zeit, den Let’s-Encrypt-Certbot zu installieren, der sich um das Erzeugen und Erneuern des Zertifikats kümmert (Listing 2, Zeile 9). Ihn weisen Sie anschließend an, ein neues Zertifikat für die eben angelegte Subdomain anzufordern (Zeile 10 und 11). Der Certbot fragt noch einige Informationen ab und gibt im Rahmen der Zertifikatsanforderung dann den Text aus den letzten vier Zeilen des Listings aus.

Danach wechseln Sie in die DNS-Verwaltung Ihres Domain-Providers und fügen für die Subdomain git.horst.labs einen TXT-Eintrag hinzu. Wichtig: Der Name des TXT-Records muss _acme-challenge.git.horst.labs (oder eben wie Ihre Subdomain) lauten. Als Wert dient die von Certbot ausgegebene Zeichenkette (Listing 2, Zeile 15).

Haben Sie den Eintrag gespeichert, sollten Sie kurz warten, bis er seinen Weg in die DNS-Server gefunden hat. Nach einigen Minuten Wartezeit drücken Sie in Certbot auf die Eingabetaste. Sofern der Eintrag sauber im DNS hinterlegt ist, installiert Certbot jetzt ein ordentliches Zertifikat und gibt die Pfade zum Server-Zertifikat, zur Zertifikatskette und zum Private Key aus. Je nachdem, ob Sie ein selbst signiertes oder ein Zertifikat von Let’s Encrypt verwenden, benötigen Sie den vollständigen Pfad zu den entsprechenden Daten im nachfolgenden Schritt.

Jetzt legen Sie noch eine Site in Nginx an: Unter /etc/nginx/sites-available/ erzeugen Sie die Datei gogs mit dem Inhalt aus Listing 3. Für diese Datei kreieren Sie einen Symlink in /etc/nginx/sites-enabled/ (Listing 4). Sie können die Einstellungen nun mittels sudo nginx -t testen. Im Erfolgsfall erhalten Sie die Rückmeldung …**test is successful.

server {
  listen 80;
  server_name git-horst;
  return 302 https://$server_name$request_uri;
}
server {
  listen 443 ssl;
  server_name git-horst;
  ssl_certificate /etc/ssl/certs/githorst.crt;
  ssl_certificate_key /etc/ssl/private/githorst.key;
  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://localhost:3000;
  }
}

$ sudo ln -s /etc/nginx/sites-available/gogs /etc/nginx/sites-enabled/gogs

Im letzten Schritt richten Sie einen Systemd-Service ein, sodass Gogs automatisch startet und stoppt. Dazu packen Sie den Inhalt aus Listing 5 in die Datei /etc/systemd/system/gogs.service. Den neuen Dienst starten Sie wie gewohnt (Listing 6, erste zwei Zeilen). Der letzte Handgriff vor dem initialen Setup von Gogs ist der Start von Nginx (letzte Zeile).

[Unit]
Description=Gogs
After=syslog.target
After=network.target
After=mariadb.service mysql.service mysqld.service postgresql.service memcached.service redis.service
[Service]
# Modify these two values and uncomment them if you have repos with
# lots of files and get an HTTP error 500 because of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535
Type=simple
User=git
Group=git
WorkingDirectory=/opt/gogs
ExecStart=/opt/gogs/gogs web
Restart=always
Environment=USER=git HOME=/home/git
# Some distributions may not support these hardening directives.
# If you cannot start the service due to an unknown option, comment
# out the ones not supported by your version of systemd.
ProtectSystem=full
PrivateDevices=yes
PrivateTmp=yes
NoNewPrivileges=true
[Install]
WantedBy=multi-user.target

$ sudo systemctl enable gogs.service
$ sudo systemctl start gogs.service
$ sudo systemctl start nginx

Haben Sie alles richtig gemacht und der DNS-Name wird im Heimnetz aufgelöst, erreichen Sie nun über die Subdomain oder den internen Namen die Konfigurationsmaske von Gogs (Abbildung 4). Sind Sie sich hier bei Themen wie dem E-Mail-Versand unsicher, deaktivieren Sie die entsprechenden Optionen zunächst. Alle Einstellungen lassen sich im Nachhinein noch in der Konfigurationsdatei /opt/gogs/custom/conf/app.ini anpassen.

Abbildung 4: Innerhalb der Gogs-Konfigurationsmaske tragen Sie unter anderem den Datenbanktyp, den Namen der Anwendung und den ausführenden Benutzer ein.

Bei Domain hinterlegen Sie bitte den FQDN des Git-Servers, also etwa git.fritz.box, git.horst.labs und so weiter. Beim HTTP-Port lassen Sie 3000 stehen. Hier versucht Nginx ja die Verbindung zu Gogs herzustellen. Als Anwendungs-URL verwenden Sie https://Domain:443/, wobei Sie für Domain den Inhalt von Domain einsetzen. Diese URL wird später die HTTPS-Links für den Git-Zugriff steuern.

Fazit und Ausblick

Wir haben jetzt den selbst gehosteten Git-Service Gogs auf einem Raspberry Pi installiert und grundkonfiguriert. Dabei galt es, in Form von SSL-Zertifikaten, Nginx als Reverse Proxy und dem ausgewachsenen, leistungsfähigen DBMS PostgreSQL einige Hürden zu nehmen.

Diese Mühen lohnen sich allerdings, haben wir doch nun ein leistungsfähiges Git-System zur Hand, in dem wir nicht nur unsere Shell- und Python-Skripte oder Go-Quellcodes ablegen können: Es lassen sich hier jegliche Art von Textdateien kollaborativ und verteilt bearbeiten, seien es nun Markdown-Notizen, Hausarbeiten oder Korrespondenz in LaTeX2e.

In Teil 2 sehen wir uns die unterschiedlichen Features und Konfigurationsmöglichkeiten von Gogs genauer an. Darüber hinaus kümmern wir uns um das Thema Backups. (csi)