Personal tools
You are here: Home Howtos Debian GNU/Linux Zentrales Git Repository unter Debian GNU/Linux 5.0 "Lenny" Howto
Debian Howtos
 

Zentrales Git Repository unter Debian GNU/Linux 5.0 "Lenny" Howto


Einleitung

In einem anderen Howto haben wir bereits die Installation eines einfachen lokalen Git-Repositories erläutert. Diese Einfachheit und die dezentralistische Art und Weise, wie Git seine Repositories verwaltet, sind auch die Stärken dieses Code Management Systems. Dennoch möchte man inbesondere in größeren Arbeitsumgebungen ein zentrales Git-Repository verwenden, das bspw. unterschiedliche Zugriffsverfahren ermöglicht (Filesystem, HTTP(S), SSH etc.).

In diesem Howto erläutern wir die Installation eines zentralen Git-Repositories, das sowohl per SSH als auch per HTTP(S) angesprochen werden kann und das eine Weboberfläche anbietet, um innerhalb des Repositories via Browser navigieren zu können. Da wir das Tool gitosis verwenden, können wir auch beliebig viele Git-Repositories innerhalb kürzester Zeit deployen. Zudem wird jede Nacht ein Snapshot des Repositories erstellt, das bspw. zu Archivierungs- und Distributionszwecken verwendet werden kann.

Lokales vs. zentrales Git-Repository

Bei Git handelt es sich zwar um ein verteiltes Code Management System, jedoch bietet es sich an, zusätzlich zu den bei den Entwicklern vorliegenden lokalen Instanzen des Repositories eine zentrale Instanz von Git aufzusetzen, die die o.g. Aufgaben erfüllt (unterschiedliche Transportprotokolle, Snapshots, Commit Mails etc.). Von daher streben wir das im Folgenden beschriebene Szenario an.

Jeder Entwickler besitzt eine Kopie des Git-Repositories, die er bspw. via git clone lokal erstellt hat. Auf dieser Datenbasis fährt er mit seiner Arbeit fort (Änderungen von bestehenden Dateien, Hinzufügen neuer Dateien etc.). Möchte er diese Änderungen nun in das zentrale Repository einpflegen, benutzt er das Kommando git commit`.

Installation von Git

Zunächst installieren wir die Basis von Git:

# aptitude install git-core

Installation von gitosis

Durch die dezentrale Art und Weise, wie Git die einzelnen Repositories verwaltet, findet man vorwiegend Howtos, die diesen Aspekt aufgreifen. Da wir uns jedoch einer zentralen Lösung zum Hosting von Git-Repositories zuwenden wollen, verwenden wir an dieser Stelle das speziell dafür geschaffene Tool gitosis. Das Tool ermöglicht u.a. die Verwendung von Git-Benutzern, die keinen Shell-Account auf dem Server benötigen. Alle Git-User, die keinen solchen Account haben, werden automatisch auf einen zentralen Useraccount gemappt, der keinerlei Systemrechte besitzt.

Zunächst installieren wir das Tool gitosis mittels:

# aptitude install gitosis

Neben gitosis selbst wird hierbei eine Vielzahl von Abhängigkeiten installiert, wie bspw. die gesamte Python-Umgebung. Zudem wird automatisch ein neuer Benutzer gitosis erstellt und ihm das ebenfalls bei der Installation erstellte Home-Verzeichnis /srv/gitosis zugewiesen. Dies ist auch das Verzeichnis, das später unsere Git-Repositories aufnehmen wird.

Konfiguration von gitosis

Gitosis verwendet von sich aus die schlüsselbasierte SSH-Authentifizierung, um Clients beim Server zu authentifizieren. Daher benötigt der Server, auf dem die Git-Repositories gehostet werden, zunächst die entsprechenden öffentlichen RSA-Schlüssel der einzelnen Workstations, die Zugriff auf das Repository erhalten sollen.

Wir erzeugen zunächst ein neues Verzeichnis /etc/gitosis/sshkeys, in das wir später die öffentlichen SSH-Schlüssel der einzelnen Clients einfügen werden und ordnen dieses Verzeichnis dem Benutzer und der Gruppe gitosis zu:

# mkdir -p /etc/gitosis/sshkeys

# chown -R gitosis:gitosis /etc/gitosis/sshkeys

Generierung des RSA-Schlüsselpaares (Client)

Nun benötigen wir auf dem Clientrechner ein RSA-Schlüsselpaar, das aus dem privaten und öffentlichen Teil des Schlüssels besteht. Dieses generieren wir für jeden Benutzer, der später den Zugriff auf das Git-Repository erhalten soll mittels:

$ ssh-keygen -t rsa

Das Kommando fragt uns nach dem Namen der Datei, unter dem es den Schlüssel speichern soll. Wir speichern diesen unter der Vorgabe ~/.ssh/id_rsa:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/ctp/.ssh/id_rsa): <---- ENTER drücken

Nun fragt uns das obige Kommando nach einer Passphrase, mittels derer es den privaten Teil des Schlüssels selbst verschlüsseln würde. Da wir eine automatische Authentifizierung ohne Passwortabfrage benötigen, geben wir hier kein Passwort an:

Enter passphrase (empty for no passphrase): <---- ENTER drücken
Enter same passphrase again: <---- ENTER drücken

Zuletzt erhalten wir eine Statusmeldung und einen Fingerprint des Schlüsselpaares und finden anschließend den öffentlichen Teil der Schlüssels in der Datei ~/.ssh/id_rsa.pub.

Kopieren des öffentlichen RSA-Schlüssels für Admin

Nun kopieren wir den öffentlichen Teil unseres RSA-Schlüssels (Client Rechner) auf den Server in das von uns erstellte Verzeichnis /etc/gitosis/sshkeys:

$ scp ~/.ssh/id_rsa.pub root@10.0.1.3:/etc/gitosis/sshkeys/ctp

Anmerkung: unser Server, der die Git-Repositories hosten wird, besitzt in unserem Fall die IP-Adresse 10.0.1.3. Diese muss an die eigene Netzwerkumgebung angepasst werden! Zudem verwenden wir für jeden öffentlichen RSA-Schlüssel eine eigene Schlüsseldatei im Verzeichnis /etc/gitosis/sshkeys, die wir nach dem Benutzernamen benennen (in unserem Fall also ctp).

Diesen Schritt führen wir für alle Hosts/Clients durch, die administrativen Zugriff auf die Git-Repositories erhalten sollen (und nur für diese!). Anschließend ordnen wir alle öffentlichen Schlüssel dem Benutzer und der Gruppe gitosis zu:

# chown -R gitosis:gitosis /etc/gitosis/sshkeys

Initialisierung des Git-Repositories

Nun initialisieren wir das administrative Git-Repository:

# su gitosis

$ gitosis-init < /etc/gitosis/sshkeys/ctp

Daraufhin erhalten wir die folgende Statusmeldung:

Initialized empty Git repository in /srv/gitosis/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /srv/gitosis/repositories/gitosis-admin.git/

Initiales Auschecken des Repositories

Da wir das Git-Repository mittels unseres öffentlichen RSA-Schlüssels initialisiert haben, können wir nun den dessen Inhalt, der die gesamte Git-Konfiguration trägt, auf dem lokalen Rechner auschecken via:

$ git clone gitosis@10.0.1.3:gitosis-admin.git

Mit dem Auschecken erhalten wir sowohl eine lokale Kopie des RSA-Schlüsselverzeichnisses der Benutzer, die Zugriff auf das Git-Repository erhalten sollen, als auch eine Kopie der Git-Konfiguration gitosis-admin/gitosis.conf

Anlegen weiterer Repositories

Bis hierhin haben wir als Administrator Zugriff auf das administrative Repository gitosis-admin. Nun wollen wir ein weiteres Repository namens projektrepo erstellen, das wir als gewöhnliches Entwickler-Repository verwenden wollen. Dazu modifizieren wir die Datei gitosis-repo/gitosis.conf, die wir ausgecheckt haben (keine direkten Änderungen auf dem Server!) und fügen ihr die folgende Definition hinzu:

[group projektrepo]
writable = projektrepo
members = ctp@hilbert

Anschließend speichern wir die Änderungen der Konfigurationsdatei, indem wir diese in das administrative Git-Repository gitosis-admin committen:

$ git commit -a -m "Added new repository 'projektrepo'"

$ git push

Nun erstellen wir auf dem lokalen PC das neue Repository 'projektrepo':

$ mkdir projektrepo

$ cd projektrepo

$ git init

Nun fügen wir alle Dateien dem Verzeichnis projektrepo hinzu, die später unter die Versionskontrolle gestellt werden sollen und führen anschließend die folgenden Kommandos aus:

$ git add .

$ git remote add origin gitosis@10.0.1.3:projektrepo

$ git commit -a -m "Initial commit"

$ git push --all

Git Web-Interface cgit

Möchte man schnell via Webbrowser auf sein Git-Repository zugreifen, um bspw. den Status des Projekts einzusehen, benötigt man ein entsprechendes Web-Interface. Ein solches einfaches und performantes Interface bietet uns cgit.

Zunächst einmal benötigen wir einen Webserver. Da wir ein schlankes und performantes System anstreben, wählen wir in unserem Fall Lighttpd als Webserver. Ein entsprechendes Howto zur Installation von Lighttpd unter Debian GNU/Linux 5.0 (aka "Lenny") haben wir bereits an dieser Stelle veröffentlicht. Daher setzen wir zuallererst dem Howto folgend Lighttpd auf (Grundinstallation ohne CGI/FastCGI) und kehren anschließend hierhin zurück.

Da es sich bei cgit um eine CGI-Applikation handelt, aktivieren wir das CGI-Modul mittels:

# lighty-enable-mod cgi

Nun fügen wir eine entsprechende vhost-Definition an das Ende der Hauptkonfigurationsdatei des Webservers /etc/lighttpd/lighttpd.conf an:

$HTTP["host"] == "git.asconix.lan" {
  server.document-root = "/var/www/cgit"
  index-file.names     = ( "cgit.cgi" )
  cgi.assign = ( "cgit.cgi" => "" )
  url.rewrite-once = (
    "^/([^?/]+/[^?]*)?(?:\?(.*))?$" => "/cgit.cgi?url=$1&$2",
  )
}

Da wir in unserer obigen Konfiguration URL-Rewriting verwenden, müssen wir ebenfalls in der Konfigurationsdatei /etc/lighttpd/lighttpd.conf das entsprechende Modul mod_rewrite laden. Dies tun wir, indem wir der Sektion server.modules die folgende Definition hinzufügen:

server.modules = (
        ...
        "mod_rewrite"
)

Damit haben wir bereits den Webserver soweit konfiguriert, dass dieser das CGI-Skript cgit hosten kann.

Anschließend installieren wir einige Pakete und Bibliotheken, die wir später zum Kompilieren von cgit benötigen werden:

# aptitude install build-essential libssl-dev

Nun checken wir die Sourcen des Projekts via Git aus:

# cd /usr/local/src

# git clone git://hjemli.net/pub/git/cgit

Anschließend wechseln wir in das Verzeichnis /usr/local/src/cgit und initialisieren bzw. updaten darin das Git Submodul:

# cd /usr/local/src/cgit

# git submodule init

# git submodule update

Nun passen wir noch das Makefile /usr/local/src/cgit/Makefile an. Zunächst passen wir darin den Document-Root für die Webapplikation an (Zeile 3):

CGIT_SCRIPT_PATH = /var/www/cgit

Ebenfalls passen wir den Konfigurationspfad an (Zeile 5):

CGIT_CONFIG = /usr/local/etc/cgitrc

Anschließend kompilieren wir die Sourcen des Projekts mittels:

# make && make install

Nun müssen wir noch die Konfigurationsdatei /usr/local/etc/cgitrc anlegen. In unserem Fall sieht diese folgendermaßen aus:

virtual-root=/

css=/cgit.css
logo=/cgit.png

repo.url=projektrepo
repo.path=/srv/gitosis/repositories/projektrepo.git
repo.desc=My first project repository

Zuletzt müssen wir die Zugriffsrechte reglementieren. Da die Git-Repositories dem Benutzer bzw. der Gruppe gitosis gehören, der Webserver jedoch unter der UID/GID www-data läuft und dennoch auf die Repository-Verzeichnisse unterhalb von /srv/gitosis/repositories zugreifen soll, fügen wir den Benutzer www-data der Gruppe gitosis hinzu:

# usermod -a -G gitosis www-data

Die Wirkung des obigen Kommandos überprüfen wir mittels:

# id www-data

Als Ausgabe erhalten wir hierbei:

uid=33(www-data) gid=33(www-data) groups=33(www-data),104(gitosis)
Document Actions

Kleinere Probleme

Avatar Posted by Marcus at Mar 03, 2010 03:24 PM
Vielen Dank für das gute Tutorial. Was mich auch freut, dass hier auf einen anderen Weg eingegangen wird. sämtliche andere Tutotials zu gitosis sind zwar ähnlich, aber doch irgendwie komplizierter, obwohl sie das selbe Ergebnis liefern. Einige Probleme habe ich jedoch noch gehabt. Auf meinem Hauptserver habe ich eine saubere Verbindung leider noch nicht zu Stande bekommen. Auf einem Testserver, den ich frisch eingerichtet hatte, lief jedoch alles reibungslos.

Was ist bei meinem Hauptserver das Problem?
Erstens arbeite ich über einen geänderten SSH PORT. Leider habe ich keine Informationen gefunden, wie man mit einem abweichenden PORT von 22 den clone ausführen könnte. Evtl. habt ihr ja hier eine Lösung für mich. Auch im Manuell konnte ich dazu nichts finden. Möglich müsste es ja sein. Komischerweise scheint mein Schlüssel ebenfalls nicht akzeptiert zu werden. Wenn ich versuche mich von meinem Client auf den Server zu verbinden, werde ich immer nach eine Passwort gefragt. Das bekomme ich jedoch hin. Einmal hatte ich den Server bereits so weit, dass ich ohne Probleme eine Verbindung herstellen konnte (über PORT 22), jedoch funktionierte der clone Befehl danach nicht ganz sauber und der Server brach die Verbindung nach einigen Sekunden wieder ab. Das Repro. wurde also nicht sauber geklont und anschließend wieder entfernt. Ein Verbindungsfehler meinerseits, oder doch eine Einstellung auf dem Server? Vielleicht könnt ihr mir ja dabei helfen. Ansonsten danke ich euch nochmals für das wirklich gute Tutorial.

Eine Frage kommt mir dann doch noch auf. Wenn ich weitere User einem neuen Team hinzufügen möchte, schreibe ich diese dann einfach mit einem Komma getrennt hinter Members?

P.s.: Es heißt übrigens writable und nicht writeable :)

Re: Kleinere Probleme

Avatar Posted by Christoph Pilka at Mar 11, 2010 11:28 AM
Hallo Marcus,

erstmal, schön so positives Feedback zu bekommen ;-) Nun zu deinem Problem: leg mal bei dir auf dem Client eine Konfigdatei ~/.ssh/config an mit folgendem Inhalt:

Host git.deinserver.deinedomain
Port dein_port

Die andere mit deinem Schlüssel: du hast eine Datei keydir/dein_nick@dein_host.pub auf dem git Server? Wichtig ist die Endung .pub, da Gitosis die Schlüssel der Reihe nach einliest. Ist dieser Schlüssel dann auch zu sehen bei einem:

cat ~gitosis/.ssh/authorized_keys

? Normalerweise wird er dort beim Initilisieren von Git als solcher eingetragen. Erst dann wirst du per Key authorisiert.

Weitere Benutzer fügst du einfach hinter "members" ein, allerdings einfach durch ein Space getrennt.

By the way: writable ist nun writable ;-)

Gruss,
Chris

Kleinere Probleme

Avatar Posted by Marcus at Mar 19, 2010 12:45 PM
Hallo Christoph,

vielen Dank, das mit der Config hat wunderbar funktioniert. Leider noch nicht das mit dem Klonen der Admin Config. Auf meinem Testserver läuft weiterhin alles Einwand frei. Auf meinem Hauptserver leider nicht. Dort werde ich weiterhin nach einem Passwort gefragt. Habe nun auch beide Server miteinander verglichen und es gibt hier, was gitosis angeht, keine Unterschiede. Beide Server haben die gleiche Key Datei im Verzeichnis etc. pp. Bin auch alles noch einmal durch gegangen. Keine Chance. Der unterschied der beiden Server ist nur, dass auf dem Hauptserver noch die ganzen Webdienste laufen wie Apache MySQL etc. Der Testserver ist eine reine minimal Installation.

Zu Testzwecken werde ich gitosis am Wochenende mal komplett entfernen und das ganze Thema noch einmal von vorne aufrollen. Vielleicht hilft es ja.

Ein anderes Problem hat sich jedoch noch aufgetragen. Ich wollte die Teamarbeit mit einem Kollegen testen, jedoch stellte sich heraus, dass er ein Ö in seinem benutzernamen hatte. Die Erstellung des SSH Keys stellte sich also als Problem dar. Leider saß ich nicht neben ihm und konnte mir den Ablauf nicht ansehen. Da er auch kaum bis keine Ahnung von Servern hat, war er auch ziemlich demotiviert bei unserem Test. Gibt es hier auch einen kleinen Trick, womit man diesen Schlüssel erzeugen kann, wenn es sich um einen Umlautnamen handelt?

Re: Kleinere Probleme

Avatar Posted by Christoph Pilka at Mar 19, 2010 12:50 PM
Hallo Marcus,

versuch echt nochmal alles nach und nach aufzusetzen. Vermutlich ist irgendwo der Wurm drin und Murphy's Gesetze haben wieder zugeschlagen ;-)

Hmhm, das mit dem Benutzernamen und Ö: würde ich persönlich niemals machen. Das fängt ja schon an mit: versuch mal eine Mail an müller@localhost zuzustellen. Die Auswirkungen von Sonderzeichen in Benutzernamen sind mir im Detail nicht klar, aber es ist klar, dass man eine Batterie von Problemen damit auslöst (Terminal-Einstellungen, Interpretation seitens der Dienste (s. Mail müller@, etc.)

Gruss,
Christoph

Gehts weiter?

Avatar Posted by chris at Mar 07, 2010 12:15 AM
Beinahe ein super Tutorial, allerdings könnte man besser ausführen, wie das mit mehreren Usern funktioniert.
Als Tipp fand ich den hier schonmal besser:
"Don't forget the members section is the name of your public key file without the .pub at the end. If your key was named XYZ.pub then your member line would have XYC here."
(gefunden hier: http://www.howtoforge.net/setting-up-gitosis-on-ubuntu)

Es geht ja bei einem Zentralen GitServer vermutlich immer darum mehrere User, oder wie ich hier Büros und Laptops unabhängiger zu machen und doch besser zu verknüpfen.

Re: Gehts weiter

Avatar Posted by Christoph Pilka at Mar 07, 2010 12:17 AM
Hallo Namensvetter,

solche Hinweise nehme ich gern auf und werde sicherlich die kommende Zeit ein wenig ausbauen ;-)

Gruss,
Chris

Updates für cgit

Avatar Posted by Hans at Jun 11, 2010 07:08 PM
Hallo,

gibt es einen Weg wie man Updates von cgit mitbekommt?

Ich möchte ja ungern eine Version mit Sicherheitslücken laufen haben, und Debianpakete die das für mich machen gibt es ja leider noch nicht.

Add comment

You can add a comment by filling out the form below. Plain text formatting.

(Required)
Bitte geben Sie Ihren Namen ein.
(Required)
(Required)
(Required)
Enter the word