Gitea auf vServer mit Plesk

2017-01-29 // Tags:

Theoretisch habe ich auf meinem Synology DS416play bereits einen Git-Server laufen. Doch finde ich den etwas zu spartanisch. Alleine das initialisieren neuer Repositories ist etwas sperrig, wenngleich auch kein Hexenwerk. Aber auf der Arbeit verwenden wir Gitlab und durch andere Anbieter wie Github oder Bitbucket war ich dann doch schon etwas verwöhnt. Entsprechend war es naheliegend, dass ich auf meinem neuen vServer auch einen etwas komfortableren Git-Server installiere.

Ebenso naheliegend wäre die Wahl von Gitlab gewesen. Doch ein Blick in die Anforderungen haben meinen kleinen Server schnell als unzureichend herausgestellt. Die Suche nach Alternativen brachte mich schnell auf Gogs. Ein schneller, schlanker Git-Server, der mir adhoc sehr gut gefallen hat. Etwas weitere Recherche brachten mich dann aber wiederum auf einen Fork von Gogs: Gitea. Ebenso schlank, aber scheinbar mit einer besseren Community dahinter.

Allgemeine Installation von Gitea

Die Installation von Gitea ist denkbar einfach:

  • Runterladen der ca. 26MB großen Binary wget https://dl.gitea.io/gitea/1.0.1/gitea-1.0.1-linux-amd64 -O gitea
  • Binary ausführbar machen chmod +x gitea
  • Starten der Binary ./gitea web

Und schon kann man Gitea über die Adresse http://localhost:3000 im Browser erreichen. Ein paar Konfigurations-Angaben und man kann loslegen.

Ich habe mich übrigens für die sqlite-Datenbank entschieden, weil ich eh nur alleine mit einer Hand voll Repositories arbeiten werde.

Installation auf dem vServer

Grundlegend ist die Installation auf dem vServer genau so einfach, wie eine lokale Test-Installation.

Ich habe mir in Plesk eine dedizierte Subdomain für Git angelegt. Anschließend per SSH auf dem Server zum entsprechenden Benutzer für die Domain gewechselt und die allgemeinen Schritte ausgeführt. Schon lief Gitea, wenngleich auch nur innerhalb der aktuellen SSH-Session und nicht von außen erreichbar.

Gitea im Hintergrund starten

Damit Gitea auch weiter läuft, wenn ich die SSH-Session beende, habe ich das Programm einfach im Hintergrund gestartet:

nohup ./gitea web &

Proxy der Subdomain auf Gitea

Die Subdomain nimmt alle Anfragen auf Port 80 (http) oder 443 (https) entgegen. Gitea läuft hingegen auf Port 3000. Also muss ein Proxy eingerichtet werden, ähnlich wie bei der Node.js-Anwendung Ghost.

Dazu geht man in Plesk in die Verwaltung von “Websites & Domains” zur entsprechenden Subdomain und in die “Einstellungen für Apache und ngix”.

Da ich bereits mein Zertifikat für Let’s Encrypt eingerichtet habe und von Plesk alle HTTP-Anfragen auf HTTPS weiterleiten lasse, musste ich nur einen Proxy-Eintrag für HTTPS hinzufügen:

<Location />
	ProxyPass http://127.0.0.1:3000/
	ProxyPassReverse http://127.0.0.1:3000/
</Location>

Und schon konnte ich auf die Admin-Oberfläche von Gitea zugreifen.

Bestehende Probleme mit Gitea unter Plesk

Soweit, so gut. Ich konnte in Gitea ein neues Repository einrichten und dies dann lokal über https klonen. Dazu muss ich allerdings meine Login-Daten für Gitea jedes mal bei git-Operationen eingeben. Schöner wäre es, wenn ich per SSH mit einem hinterlegten Key arbeiten könnte.

Doch da bin ich leider an die Grenzen von Gitea unter Plesk gestoßen.

Gegeben sei die folgende Struktur:

  • Die Haupt-Domain liegt unter /var/www/vhosts/<domain>
  • Die Subdomain für Git liegt unter /var/www/vhosts/<domain>/<subdomain>
  • Unter der Subdomain wollte ich aufräumen und habe weiter unterteilt:
    • Gitea mit dem Webserver liegt unter /var/www/vhosts/<domain>/<subdomain>/web
    • Die Repositories selber liegen parallel dazu unter /var/www/vhosts/<domain>/<subdomain>/gitea-repos

Wenn ich nun in Plesk dem Webseiten-Benutzer - der leider für die Hauptdomain wie auch die Subdomains gilt - den SSH-Login verweiger, kann ich per SSH gar nicht erst auf den Server. Wenn ich dem Webseiten-Benutzer den Login mit CHROOT erlaube, findet er git nicht in seinem $PATH, was jedwede Git-Operation unterbindet. Natürlich kann man weitere Programme der CHROOT-Umgebung hinzufügen. Doch das führt dann zu weiteren Problemen:

Gitea offeriert eine Pull/Clone-URL im folgenden Format:

ssh://<domainuser>@<subdomain>:<port>:/<giteauser>/<repository>.git

Da die Subdomain aber im Kontext des Domain-Users läuft, und sich dessen CHROOT-Umgebung auf die Domain bezieht, landet der Nutzer nach SSH-Login unter /var/www/vhosts/<domain>. Dort sucht er dann nach dem Verzeichnis <giteauser>/<repository>.git um daraus zu klonen. Das wird natürlich nicht gefunden, weil das ja unter <subdomain>/gitea-repos/<giteauser>/<repository>.git liegt.

Lösungs-Idee

Mein erster Ansatz war, dass ich einfach die Repositories als Symlink direkt in die CHROOT-Umgebung lege. Anschließend muss ich Gitea nur beibringen, dass er den Pfad zum Pull/Clone eine andere URL angeben soll.

Symlink-Anlegen:

cd /var/www/vhosts/<domain>
ln -s <subdomain>/gitea-repos repos

Anschließend habe ich diverse Ansätze versucht. Unter /var/www/vhosts/<domain>/<subdomain>/web/custom/conf/app.ini liegt eine Konfigurationsdatei, wo ich diverse Parameter versucht habe zu ändern.

DOMAIN und ROOT_URL in der Sektion [server] habe ich jeweils um /repos erweitert. Doch das hatte lediglich zur Folge, dass Gitea gar nicht mehr richtig funktionierte. Scheinbar haben Javascript und CSS-Dateien dann versucht über <URL>/repos zu laden, wo sie allerdings nichts finden.

Natürlich könnte ich einfach immer der Klon-URL manuell ein /repos hinzufügen, aber das ist wahrscheinlich für ein Zukunfts-Ich immer noch verwirrend. Deswegen habe ich SSH für Gitea erstmal deaktiviert und führe alle Operationen über HTTPS aus - so schade es aktuell ist.

(Gänzlich davon abgesehen, dass ich es nicht schön finde, dass die SSH-Operationen im Kontext des Domain-Users stattfinden und nicht für einen dedizierten User der Subdomain. Aber das ist ein anderes Thema.)

Falls hier jemand eine Lösung hat, wäre ich dankbar für Ideen und Ansätze per Mail.