Froschs Blog

Computer und was das Leben sonst noch so zu bieten hat

Zur Website | Impressum

gitweb auf nginx

18. April 2016 um 18:45 Uhr von Atari-Frosch

Hey, endlich mal wieder ein Artikel mit IT-Bezug! 😉 Gestern habe ich von Dr. Michael Stehmann, dem Autor der Anwaltssoftware Canzeley, eine ausführliche und gute Einführung in git incl. einer lokalen Installation von gitweb (unter apache2) bekommen. Nochmals vielen Dank dafür! Heute wollte ich das ganze mal so in die Praxis umsetzen, wie es für mich am sinnvollsten erscheint.

Ziel: Der Git-Server soll auf dem neueren meiner beiden Server laufen, und zwar mit gitweb als grafischem Browser, damit ich meine Projekte auf Dauer auch anderen zugänglich machen kann. Weil ich dort keinen Apachen mehr betreibe, sondern eben nginx, habe ich mir da einen V-Host für gitweb eingerichtet und (mit Hilfe des WWW) nginx erklärt, wie er mit diesem umgehen soll.

Der Haken ist nämlich: gitweb kann man völlig schmerzfrei mit apt-get install installieren, wenn der darunterliegende Webserver ein apache2 ist. Denn die dafür nötige Konfigurationsdatei kommt direkt mit, die Weboberfläche läuft somit „out of the box“. Bei anderen Webservern wird's ein wenig komplizierter.

Erstmal ein paar Begriffe, damit es nicht zu Mißverständnissen kommt:

  • „Server“ bezeichnet den Rechner, auf dem die Git-Repos zukünftig gehostet werden sollen. Bei mir ist das ein solcher, der öffentlich zugänglich im Internet steht.
  • „Client“ bezeichnet einen Rechner, mit dem man sich zum Git-Repo verbinden will, sowohl zur Verwaltung der Repos als auch, um auf die grafische Oberfläche von gitweb zu gelangen.
  • Begriffe, die ich $solcherart schreibe, sind Platzhalter-Bezeichnungen, die entsprechend ersetzt werden müssen.
  • „example.com“ ist ein Beispiel für eine Domain, auch die muß natürlich entsprechend angepaßt werden.

Der Server läuft in diesem Fall unter Debian GNU/Linux 7 (Wheezy; derzeit oldstable) und hat keine Backports eingebunden. nginx läuft bereits. Trotzdem muß root zur Vorbereitung erstmal ein paar Dinge tun:

:~$ apt-get install git gitweb fcgiwrap
:~$ mkdir /srv/$gitdir
:~$ adduser --home /srv/$gitdir git
:~$ chown -v git:git /srv/$gitdir
:~$ chmod g+rw /srv/$gitdir
:~$ chmod g+s /srv/$gitdir
:~$ usermod -aG git $user

$user ist Platzhalter für einen bereits vorhandenen lokalen User-Account.

Was habe ich hier gemacht? Zunächst habe ich die Pakete git, gitweb und fcgiwrap installiert. Letzteres braucht später der nginx, um mit gitweb reden zu können. Dann habe ich ein Verzeichnis angelegt, in welchem die Repos gespeichert werden sollen.

Außerdem wird für git ein eigener User-Account benötigt. Der bekommt zwar ein Paßwort und alles, aber das wichtigste daran ist in diesem Fall die Gruppe, die damit angelegt wird; über diese Gruppe können User, wie mit dem letzten Befehl aus diesem Block geschehen, berechtigt werden, Repos anzulegen und zu verwalten.

Damit die Rechteverwaltung so auch funktioniert, muß das angelegte Verzeichnis für die Repos die User- und Gruppenrechte für git bekommen. Außerdem muß die Gruppe das Verzeichnis lesen und schreiben dürfen; das g+rw ist allerdings mehr eine Sicherheitsmaßnahme, da Verzeichnisse meist sowieso mit Schreib- und Leserechten für die Gruppe angelegt werden. Die weitere Änderung bei den Zugriffsrechten für das Verzeichnis, g+s, bewirkt, daß darin neu angelegte Dateien oder Unterverzeichnisse derselben Gruppe gehören, der auch das Verzeichnis selbst gehört (statt der Gruppe, zu der der erstellende User primär gehört).

Schließlich bekommt mindestens ein normaler User-Account, der Projekte in dieses git einspielen und editieren darf, die Gruppenrechte für git.

Nachdem diese Vorbereitungen abgeschlossen sind, möchte ich den ersten Eintrag in der Datei /etc/gitweb.conf editieren, denn das Root-Verzeichnis für die Projekte soll hier anders heißen als dort ursprünglich vorgesehen (das kann man machen, muß aber nicht; wenn nicht, müssen weiter unten die Pfade entsprechend angepaßt werden):

$projectroot = "/srv/$gitdir";

Nun muß der nginx lernen, was er da ausliefern soll und wie:

:~$ cd /etc/nginx/sites-available

In diesem Verzeichnis wird eine neue Datei für gitweb angelegt, die ich hier mit dem Platzhalter $sitename bezeichne. Diese Datei bekommt folgenden Inhalt:

server {
        root /srv/$gitdir;
        server_name git.example.com;

        location /index.cgi {
                root /usr/share/gitweb/;
                include fastcgi_params; 
                gzip off;
                fastcgi_param SCRIPT_NAME $uri;
                fastcgi_param GITWEB_CONFIG  /etc/gitweb.conf;
                fastcgi_pass  unix:/var/run/fcgiwrap.socket;  
        }

        location / {
                root /usr/share/gitweb/;
                index index.cgi;
        }

        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
                root /usr/share/nginx/www;
        }

        access_log /var/log/nginx/$sitename/access.log;
        error_log /var/log/nginx/$sitename/error.log;  
}

Ich habe in diesem Fall eine Subdomain zu einer bestehenden Domain angelegt. Hier sieht man auch, warum ich anfangs das Paket fcgiwrap installiert habe: ohne dieses würde das Ganze nicht funktionieren.

Natürlich ist es auch möglich, gitweb stattdessen in ein Unterverzeichnis eines bestehenden Webangebots zu packen. Dann müssen die Pfade weiter oben entsprechend angepaßt werden. Auch der Betrieb auf einem anderen als dem Standard-Port ist möglich; in diesem Fall muß der nginx auf diesem geänderten Port lauschen. Auf diese beiden Möglichkeiten und darauf, was dafür anders gemacht werden muß, gehe ich hier aber nicht weiter ein.

Zu den Log-Pfaden: Das ist Geschmackssache. Ich lege für jede Site ein Unterverzeichnis an; andere lassen vielleicht alles in ein Logfile laufen oder haben überhaupt nur eine Site, so daß sich eine Unterteilung nicht lohnt. Die Pfade müßten dementsprechend angepaßt werden. Falls gar keine Logs gewünscht sind, läßt man diese beiden Zeilen einfach weg; für den Anfang und bis alles läuft sind sie allerdings schon sinnvoll.

So! Nachdem jetzt alles konfiguriert sein sollte, kann das Ganze aktiviert werden:

:~$ cd sites-enabled
:~$ ln -s ../sites-available/$sitename .
:~$ cd /srv/$gitdir
:~$ ln -s /usr/share/gitweb .
:~$ service nginx restart

Zunächst wird ein SymLink in die aktivierten V-Hosts gesetzt, damit nginx weiß, daß er diesen V-Host auch tatsächlich benutzen soll und der nicht einfach nur so da rumsteht. Dann wird das Script-Verzeichnis von gitweb per SymLink in das Verzeichnis gelinkt, das ich weiter oben der gitweb-Konfiguration als projectroot eingetragen habe. Schließlich muß nginx neu gestartet werden, damit er die Änderungen auch mitbekommt.

Nun kommt es noch darauf an, ob die Subdomain, die ich gerade nginx vorgegeben habe, im DNS bekannt ist (oder überhaupt bekannt sein soll); wenn ja, ist jetzt schon alles in Butter. Wenn nicht, muß man seinem Client noch ein bißchen „DNS zu Fuß“ beibringen und – als root – die Datei /etc/hosts editieren. Sie bekommt an passender Stelle eine zusätzliche Zeile, die etwa so aussieht:

10.0.0.5 git.example.com

10.0.0.5 ist dabei natürlich durch die echte IP-Adresse des Servers und git.example.com durch den tatsächlichen Namen zu ersetzen.

Rein theoretisch sollte die Site jetzt mit einem Browser unter http://git.example.com ansprechbar sein und anzeigen, daß noch keine Projekte vorhanden sind. Wenn nicht, heißt es Logfiles lesen 🙂

(Darauf, wie man das Ganze auch mit https verfügbar machen kann, gehe ich hier nicht ein.)

Ja, und jetzt kann endlich das erste git-Repository angelegt werden. Auf dem Client, auf dem natürlich auch git installiert sein muß, geht man also als User in sein Projektverzeichnis und git-ifiziert ein Projekt, falls noch nicht geschehen. An dieser Stelle gehe ich davon aus, daß unterhalb des Projektverzeichnisses ein Verzeichnis namens „test“ existiert, in welchem mindestens eine Datei steht.

:~$ cd /home/$user/projekte/test
:~$ git init
:~$ git add .
:~$ git commit -am "initial message"
:~$ cd ..
:~$ git clone --bare test test.git
:~$ scp -r test.git $user@git.example.com:/srv/$gitdir

Wenn das Projekt lokal bereits mit git verwaltet wird, sind die ersten drei git-Befehle natürlich überflüssig; aber in dem Fall gehe ich sowieso davon aus, daß der Anwender mit git bereits ein wenig umgehen kann.

Nun sollte das Projekt „test“ bei einem neuen Aufruf der gitweb-Site angezeigt werden.

Damit das in Zukunft ein bißchen einfacher geht, erklären wir dem git auf dem Client jetzt noch, wo das externe Repo liegt:

:~$ git remote add origin $user@git.example.com:/srv/$gitdir/test.git
:~$ git remote -v

Mit dem zweiten Befehl wird nur nachgesehen, ob der Server erfolgreich hinzugefügt wurde. Nach einem Commit kann man nun dem git auf dem Client einfach sagen:

:~$ git push origin master

Das Paßwort muß man natürlich trotzdem jedesmal eingeben. 😉

–––––––
Quellen:

Kommentieren

Bitte beachte die Kommentarregeln!

XHTML: Du kannst diese Tags verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>