Gitblit – Erste Versuche

Ein neuer Stern am Git-Himmel ward geboren: Gitblit – die all in one Lösung schlechthin. Oder so. Mein Fazit nach einem ersten Blick.


Gitblit

Ein neuer Stern am Git-Himmel ward geboren: Gitblit – die all in one Lösung schlechthin. Oder so.

Zu beziehen ist die Software unter http://gitblit.com unter der Apache Lizenz Version 2.0. Der Source wird gehostet auf Google Code (dort finden sich auch die Issues) aber auch auf Github (wieso eigentlich nicht auf Gitblit? :D) und entwickelt es wurde von James Moger.

Ich habe mir den Git Repositorymanager mit inkludierter Weboberfläche mal genauer angesehen und am eigenen Homeserver ausprobiert. Ansich nicht übel. Kann man lassen, ehrlich. Ein paar kleine Fallstricke beim Aufsetzen haben sich ergeben, aber grundsätzlich gefällt mir Gitblit ganz gut.

Ohne SSH Key fühlt es sich fremd an

01 (161)
by Victor1558

Die ganze Gitwelt basierte für mich bisher auf SSH Keys. Github, Gitolite, Gitosis – sie alle ziehen zur Authentification den SSH Key des Users heran. Da bin ich nun wahrscheinlich ein Gewohnheitstier und fürs erste fühlt es sich falsch an, beim Push einen Usernamen und ein Passwort einzugeben. Aber genauer drüber nachgedacht passt es. Das Repository ist eingeschränkt auf einen(oder mehrere) Benutzer, und über einen Post Aufruf werden diese Daten an das rein auf HTTP und HTTPS Basierte System übergeben. Das sagt dann „JA ICH WILL“ und schon wird gepushed. Was mich aber gleich zu einem wichtigen Punkt bringt:

HTTP??? Bloss nicht.

Hier wird alles über HTTP Requests abgewickelt. Passwörter & plain/text! Wer hier kein https verwendet ist selbst schuld wenn seine Security wankt.

Menüpunkt Log: Commitlog zu … ja zu was denn?

Richtet man sich ein Repository ein, kann man den default-Branch festlegen. Dieser wird dann für Log und Co herangezogen. Nur über die Repository Startseite kann man den Stand eines anderen Branches betrachten. Dass das auf der Log Seite nicht switchbar ist, ist eigentlich kein Problem. Nur hätte ich mir die Anzeige des Branches etwas prominenter gewünscht. Im Tableheader hatte ich ihn bei den ersten Versuchen einfach übersehen.

Ein eigener Server, sehr gut Sir!

Ja, all in one Lösung heißt hier wirklich alles. In Gitblit (Variante GO) ist ein Jetty Server inkludiert, der theoretisch ohne Erstconfiguration auf dem Localhost funktioniert. Somit durchaus etwas für den USB Stick, fein!

Ein eigener Server, wir haben ein Problem Sir!

Energy Shieldz!
by Collin Harvey

All in one, all in one … ich möchte aber eigentlich keinen eigenen Port für Gitblit öffnen! Kein Problem, denn dank mod_prody kann Apache die Zugriffe an den Jetty Server weiterleiten. Oder noch besser, wenn bereits ein Servlet Container wie z.B. Apache Tomcat läuft kann Gitblit dort direkt als WAR deployed werden.

Ich habe mich für mod_proxy entschieden, wobei bei mir (vermutlich) das Zusammenspiel mit den Zertifikaten zwischen Apache und Jetty nicht funktioniert hat.
Ein Auszug aus dem error.log

[Wed Aug 01 22:16:19 2012] [error] [client 10.0.0.1] (20014)Internal error: proxy: error reading status line from remote server localhost:8443
[Wed Aug 01 22:16:19 2012] [error] [client 10.0.0.1] proxy: Error reading from remote server returned by /gitblit

Wer mir hier Hinweise geben mag, bitte in den Kommentaren posten. Ich werd auf alle Fälle noch nachforschen, viell. kann mir ja auch in der Google Group geholfen werden.

Mein Quickfix war tatsächlich auf den, von mir ein paar Absätze höher verpönten, nicht sicheren, normalen http Port auszuweichen (bzw auf 8082 in meinem Testszenario). Ich selbst werde mir das verzeihen, ist der Server doch von außen nicht erreichbar. Für ein ordentliches Produktionssystem wär das natürlich untragbar.

Der vollständigen Information halber: die richtigen Module wie folgt geladen:

# cd /etc/apache2/mods-enabled/
# ln -s ../mods-available/proxy.load
# ln -s ../mods-available/proxy_http.load

Der Autor lädt in seiner Setup Dokumentation noch ein paar Module mehr rein, die bei mir nur zu Warnings führten, von wegen mod_proxy sei bereits geladen.
Dannach das Snippet, welches auch vom Autor bereitgestellt wird, als Apache2Site einsielen um auf /gitblit zu reagiern. Hier ist auf der Autorenseite ein Fehler vorhanden, nicht auf /etc/apache2/conf.d/gitblit sollte das Snippet gespielt werden, sondern nach /etc/apache2/site-available/gitblit. Danach mit „a2ensite gitblit“ aktivieren und sich freuen. (Die passenden Änderungen im Script und in gitblit.properties vorrausgesetzt)

Zum Schluss noch einen eigenen gitblit User erstellt und per

# update-rc.d gitblit defaults

noch das mitgelieferte Service Script gitblit-ubuntu aktiviert, und schon läuft gitblit bei jedem Start des Systems mit an. (nicht vergessen, dem Script noch per

# chmod 755 /etc/init.d/gitblit

die richtigen Zugriffsrechte verpassen)

Hooks ohne Peter, ohne Krokodil, total Groovy!

Hooked
by Beta-J

Äh ja, die Möglichkeit über Groovy Hook Scripts auf Pushes reagieren zu können begeistert mich sehr. Eine Integration mit einem Jenkins Server steht damit nichts im Wege. Genaueres bleibt aber noch auszutesten. In den Groups habe ich unter anderem die Idee gefunden über pre-push hooks zB zu verifizieren ob der Committer auch der selbe ist wie der der, das Ergebnis pushed. Hier kommts wohl auf den Einzelfall an. Mir würde schon Jenkins reichen ;)

Oberfläche, ich hasse Oberfläche …

Ja, der Autor hat sich Mühe gegeben, aber ich finde die Administrationsseiten (User und Repositorys) immer noch unübersichtlich. Könnte auch der Notwendigkeit zu scrollen geschuldet sein, und der Rechtezuweisung von einer Liste per Pfeiltaste in die andere Liste. Geschmackssache, aber hier sehe ich usabilitytechnisch Verbesserungspotential. Für später dann, low-prio.

Failed to add team

Ja wie jetzt? Failed? Aber in der Übersicht dennoch angelegt? Kleinere Bugs sind wohl nie ganz auszuschließen, das Projekt ist noch jung. Wer nicht selbst fixen kann und einen Patch einschicken (Yeah, Open Source Baby!) könnte zumindest mit einem Ticket im Issue Tracker dafür sorgen, dass dem Entwickler der Fehler nicht durch das Keyboard geht!

Zu meinem Fehler bleibt zu sagen: Selbst Schuld, der Benutzer mit dem ich Gitblit als ein Service startete hatte keine Rechte auf die Gitblit Files, so konnte das Team nicht hinterlegt werden. Der Entwickler half mir bei der Problemlösung, und hat für die nächste Version hier Verbesserungen in der Fehlermeldung und der Darstellung der Teamansicht eingepflegt. Super! Hier das Ticket zu dem Fehler: Issue 118

Dateiansicht und Branchwechsel unmöglich? allowEncodedSlashes

Tjo die Details machens bekanntlich. Diese wurden mir zuerst nicht angezeigt. Läuft Gitblit hinter einem Apache2 Server mit mod_proxy werden URL Requests nicht richtig encodiert und decodiert. Die Intepretation von slashes \ bzw %2F muss dazu vom Proxy nicht angerührt werden. Dies scheint jedoch standardmäßig der Fall zu sein. Man kann nun entweder auf schöne URLs verzichten und über Parameter auf alles zugreifen (dazu in der gitblit.parameters web.mountParameters=false setzen) oder man versucht es über die Configuration von mod_proxy und setzt allowencodedslashes. Ich selbst habe dies nicht ausprobiert sondern zwecks Test mit den nicht so schönen URLs vorlieb genommen. Mein Dank gilt hierbei dem Autor der Software der darauf in der FAQ hinweist.

Einbahn – access restriction

One Way, No Left Turn
by taberandrew

Leider kann man bei Repos nur zwei Typen von Usern unterscheiden, Autorisierte und Andere. Allen Autorisierten muss man dann die selben Rechte geben, wobei einem die Wahl gelassen wird zwischen:

anonymous view, clone & push
authenticated push
authenticated clone & push
authenticated view, clone & push

Das ist zuwenig, ich will zum Beispiel der einen Gruppe Clone und Push rechte geben, der andere nur View, und alle anderen sollen nicht mal wissen, dass es das Repository gibt!

Gitblit – mein Fazit

Eine tolle Weboberfläche für die zentralen Git-Repos ist mit bisherigen Mitteln ein Gefrimmel aus mehreren Werkzeugen gewesen. Wenn der Autor an seiner Lösung dran bleibt, wird er eine tolle Alternative schaffen, die auch noch gut aussieht und angenehm zu bedienen ist. Das Rechtemanagement steckt zwar noch in den Kinderschuhen, zu stark differenzieren kann man nicht, aber das Spiel: „Wer darf was sehen?“ beherrscht es bereits. Ein Key-Feature für mich und der Grund warum ich es mir überhaupt angesehen habe. Das bisschen gepushe das ich privat nun mit Gitblit probiert habe reicht jedoch noch nicht um fixe Aussagen über Geschwindigkeit und Benutzungskomfort treffen zu können. Es wirkt jedoch vielversprechend.

Nicht ausreichend betrachtet habe ich Logging und ein korrektes HTTPS Setup.

Ähnliche Artikel:

  • Noch keine vorhanden.

Autor: Thomas Pummer

Thomas Pummer ist Softwareentwickler an der Universität Wien. In seiner Freizeit betreut er das Open Source Projekt TrayRSS und werkt an diversen anderen kleinen Projekten. Er ist sehr interessiert an Open Source und Webentwicklung und testet gern neue Programmiersprachen.

2 Gedanken zu „Gitblit – Erste Versuche“

  1. Damit Zertifikate vernünftig erstellt werden können, ist X11 wegen der Swing-Komponente notwendig. Ein No-Go für den reinen Server-Betrieb.

  2. Leider bekomme ich es nicht hin den service mit dem gitblit user zu starten. Ich bin jetzt auch kein Linux Profi, finde aber auch kein errorlog oder sonst irgendeine Fehlermeldung um heraus zu finden woran es liegt. Mit root klappt es. Vielleicht könnt Ihr mir ja weiterhelfen. :)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*