Gogs hinter einem Reverse Proxy betreiben

Gogs ist ein Git-Service welcher eine ähnliche Funktionalität wie der bekannte Dienst GitHub zur Verfügung stellt. Standardmäßig läuft der Dienst auf dem Port 3000. Möchte man ihn über die normalen Ports für HTTP (80) bzw. HTTPS (443) erreichbar machen, kann man hierfür einen Reverse Proxy nutzen. Dafür eignen würde sich zum Beispiel Nginx, der im ersten Schritt auf dem Server installiert werden muss:

apt-get install nginx

Anschließend wird die Konfiguration angelegt:

nano /etc/nginx/sites-available/example

In diesem Fall befasst sich die Konfiguration mit der verschlüsselten Kommunikation per HTTPS und der Weiterleitung von unverschlüsselten Verbindung in Richtung der verschlüsselten Verbindung.

server {
        listen 80;
        listen [::]:80;

        server_name example.com;

        return 301 https://$host$request_uri$is_args$args;
}

server {
    listen 443;
    listen [::]:443 default_server;

    ssl on;
    ssl_certificate        /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key    /etc/letsencrypt/live/example.com/privkey.pem;

    server_name example.com;

    client_max_body_size 500m;

    location / {
        proxy_pass https://localhost:3000;
    }
}

Nachdem die Konfiguration für Nginx hinterlegt ist, wird die Standardkonfiguration entfernt und ein symbolischer Link für die neue Konfiguration erstellt. Anschließend wird Nginx neugestartet, damit die geänderte Konfiguration wirksam wird:

rm /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/example
service nginx restart

Nach der Anpassung der Nginx-Konfiguration, muss die app.ini (sie befindet sich im gogs/custom/conf/ Ordner) von Gogs angepasst werden und dort die neue ROOT_URL ohne zusätzlichen Port angegeben werden. Anschließend kann auf Wunsch, per Firewall, der Port 3000 für Zugriffe von außen gesperrt werden.

Aktivieren Sie JavaScript um das Video zu sehen.
Video-Link: https://seeseekey.net/archive/118039

Git Repository mit Submodulen klonen

In der Git Welt existieren sogenannte Submodule. Diese kann man dem Repository hinzufügen und damit ein Git Repository in ein anderes Git Repository einbetten. Nach dem klonen eines solchen Projektes mittels:

git clone :seeseekey/project.git

wird man feststellen das sich nur das Hauptprojekt auf der Festplatte befindet. Möchte man die Submodule ebenfalls mit klonen so muss der Parameter recursive zusätzlich übergeben werden:

git clone --recursive :seeseekey/project.git

Mit Hilfe des Parameters werden alle Submodule ebenfalls geklont und landen somit auf der Festplatte.

Git und „multiple stage entries“

Wenn man längere Zeit mit Git arbeitet, wird einem die eine oder andere seltenere Fehlermeldung über den Weg laufen. Eine dieser Fehlermeldungen ist:

fatal: multiple stage entries for merged file 'DBAdapter.cs'

Hintergrund bei diesem Problem ist das der Index, welcher die Änderungen und Dateien enthält mit welchem der nächste Commit erstellt wird, für eine Datei mehrere Einträge vorhält; was per Definition nicht der Fall sein sollte. Der Workaround für diese Problem besteht darin, den Index (bzw. die sogenannte Staging area) zu löschen, die Dateien erneut hinzuzufügen und das ganze mit einem Commit in Stein gießen:

rm .git/index
git add -A
git commit -a

Anschließend kann das Git-Repository wieder ohne Probleme genutzt werden.

Let’s Encrypt Zertifikate in nicht privilegierten Prozessen nutzen

Wenn man Let’s Encrypt Zertifikate erzeugt, so landen diese im Ordner /etc/letsencrypt/. Die Rechte sind dabei so gewählt das nicht privilegierte Prozesse auf diese Zertifikate nicht zugreifen können. Läuft nun z.B. ein Server mit solchen Rechten, so kann er das Zertifikat nicht ohne weiteres nutzen. Um diesem Umstand zu beseitigen sollte eine neue Nutzergruppe angelegt werden:

groupadd tls-certificates

Dieser Gruppe wird nun der Nutzer hinzugefügt, welcher den Serverdienst betreibt:

usermod -a -G tls-certificates git

Damit wird der Nutzer git der Gruppe tls-certificates hinzugefügt. Nun müssen nach der Zertifikatsgenerierung die Berechtigungen angepasst werden:

#!/bin/sh
service gogs stop
letsencrypt renew --agree-tos
chgrp -R tls-certificates /etc/letsencrypt
chmod -R g=rX /etc/letsencrypt
service gogs start

In diesem Skript wird im ersten Schritt der Service gestoppt. Anschließend werden neue Zertifikate erzeugt und die Berechtigungen angepasst. Damit kann die Gruppe tls-certificates auf die Zertifikate zugreifen. Danach wird der Service wieder gestartet, was nun dank Zugriff auf die Zertifikate ohne Probleme funktioniert.

Remote-Branch unter Git umbenennen

Um unter Git einen Branch umzubenennen nutzt man den entsprechenden Terminalbefehl:

git branch -m oldBranchname newBranchname

Damit wird der Branch im lokalen Repository umbenannt. Wenn dieser nun mittels git push auf den entfernten Remote übertragen wird, so entsteht dort ein neuer Branch. Um die Umbenennung auch auf dem Remote durchzuführen muss der alte Branch auf dem Remote gelöscht werden:

git push origin :oldBranchname

Damit wird der alte Branch auf dem Remote gelöscht und die Umbenennung ist abgeschlossenen.