Skip to content

Git-Repositories mit gitosis und gitweb (Debian Lenny)

Wie ich bereits schrieb, habe ich mich in den letzten Tagen etwas näher mit dem Versionskontrollsystem (VCS, oder auch SCM für "Source-Code-Management") git beschäftigt. Das macht natürlich nur bedingt Spaß - und Sinn -, wenn die Repositories nur auf dem heimischen Rechner liegen; um wirklich universal auf sie zugreifen zu können und auch die Zusammenarbeit mit anderen zu ermöglichen, sollten die Repositories irgendwo im Netz stehen, und eine nette Weboberfläche, die auch einen Zugriff über den Browser - ohne weitere Software - ermöglicht, um den aktuellen Stand der Bearbeitung zu sehen, Commits zu prüfen und ggf. einen Snapshot zu ziehen, wäre auch nicht schlecht.

Um mir die Anlage von Repositories und das Zusammenspiel mit den anderen Komponenten zu erleichtern und auch für erweiterte Anforderungen wie verschiedene Zugriffsrechte für die jeweiligen Repositories gerüstet zu sein, habe ich mich für die Verwaltung der Repositories für gitosis entschieden; als Weboberfläche will ich gitweb nutzen, und für den Zugriff via git dann git-daemon. Installiert habe ich dazu die jeweiligen Pakete aus Debian Lenny bzw. den Debian-Backports.

Die Installation und Konfiguration habe ich folgendermaßen durchgeführt:

1. gitosis

a) Vorüberlegungen

gitosis bietet die Möglichkeit, Benutzer und Repositories zu konfigurieren. Die entsprechenden Repositories werden dann angelegt; für jedes kann gesondert festgelegt werden, welcher Benutzer - lesen oder schreibend - darauf zugreifen kann. Die Zugriffe erfolgen über (git-über-)SSH; jeder Benutzer muß dazu seinen öffentlichen SSH-Schlüssel hinterlegen. Er verbindet sich dann unter dem Benutzernamen (Useraccount) "gitosis" per SSH mit dem Server, auf dem das Repository liegt; gitosis prüft dann, welcher SSH-Schlüssel für die Verbindung übergeben wird und identifiziert auf diese Weise den Benutzer.

Die Konfiguration von gitosis erfolgt gleichfalls über ein git-Repository, das zunächst ausgecheckt wird; danach kann man die Konfiguration ändern und bspw. neue Repositories und Benutzer anlegen (und im Falle eines neuen Benutzers auch dessen öffentlichen SSH-Schlüssel speichern) und die Änderungen committen. Beim Commit paßt gitosis über entsprechende Hooks die Konfiguration an. Das Konfigurations-Repository kann entweder auf denselben Rechner ausgecheckt werden oder auf einen beliebigen anderen Client; auch diese Verbindungen erfolgen über (git-über-)SSH, und auch dafür muß man (s)einen öffentlichen SSH-Key bei gitosis hinterlegen. Ich habe mich entschlossen, dafür einen eigenen Key anzulegen; man kann aber natürlich auch einfach (s)einen bestehenden SSH-Schlüssel verwenden.

Standardmäßig sieht das Debian-Paket von gitosis die Anlage der Repositories in /srv/gitosis an; das paßt allerdings nicht zur Partitionierung meines Mietservers, der - historisch und aus dem Image des Anbieters bedingt - platzmäßig eher knapp kalkulierte Partitionen bietet und den gesamten restlichen Plattenplatz in /home eingehängt hat. Daher möchte ich die Repositories auch in /home/gitosis liegen haben.

b) Installation (der Debian-Pakete) und Inbetriebnahme

Zunächst sind git selbst und gitosis zu installieren:

aptitude install git-core git-doc gitosis

Danach lege ich ein Home-Verzeichnis für gitosis in /home an, lösche /srv/gitosis und setze einen Symlink auf das Home-Verzeichnis:

mkdir /home/gitosis
chown gitosis:gitosis /home/gitosis
rmdir /srv/gitosis/
ln -s /home/gitosis /srv/gitosis

Dann ist entweder mit ssh-keygen ein neues Schlüsselpaar zu erzeugen oder der öffentliche Schlüssel eines bestehenden Schlüsselpaares in einer Datei bereitzulegen, bspw. in git-admin_rsa.pub. Den verfüttert man dann an gitosis:

sudo -H -u gitosis gitosis-init &lt; git-admin_rsa.pub<

Dann habe ich der Bequemlichkeit halber noch die Konfiguration des SSH-Clients angepaßt, um bei SSH-Verbindungen zu localhost - was in meinem Fall nur für git-über-SSH bei der Konfiguration von gitosis vorkommt - direkt den richtigen Schlüssel zu benutzen, und dazu in ~/.ssh/config folgendes eingefügt:

Host localhost
IdentityFile ~/.ssh/git-admin_rsa

Zur Konfiguration und Einrichtung der Benutzer muß das Konfigurations-Repository von gitosis jetzt erst einmal ausgecheckt werden (in meinem Falle geschieht das auf demselben Host, man kann aber natürlich auch von jedem anderen Host aus mit dem oben an gitosis übergebenen SSH-Schlüssel auf das Repository zugreifen):

git clone gitosis@localhost:gitosis-admin.git gitosis-admin

Damit wird das Repositoy in das Verzeichnis gitosis-admin ausgecheckt. Dort befindet sich dann die Datei gitosis.conf und das Verzeichnis keydir; in ersterer werden Benutzer und Repositories angelegt, in letzterem finden sich die öffentlichen SSH-Schlüssel der Benutzer.

c) Konfiguration und Einrichtung der ersten Benutzer und Repositories

Als erstes nehme ich mir die gitosis.conf vor und prüfe bzw. setze dort die globalen Einstellungen:

[gitosis]
## To override the default ~/repositories path
# repositories = repositories

## Allow gitweb to show all known repositories. If you want gitweb,
## you need either this or a [repo foo] section for each repository
## you want visible in gitweb.
gitweb = no

## Allow git-daemon to publish all known repositories. As with gitweb,
## this can be done globally or per-repository.
daemon = no

## Logging level, one of DEBUG, INFO, WARNING, ERROR, CRITICAL
loglevel = INFO

Die Optionen sind im Prinzip selbsterklärend. Ich habe mich entschieden, den Webzugriff und den Zugriff via git-daemon nicht generell freizugeben, sondern das per Repository zu steuern.

Als nächstes werden Benutzergruppen und deren Rechte festgelegt:

### groups #####---------------
[group gitosis-admin]
writable = gitosis-admin
members = admin@admin.host.example

[group friends]
writable = repo-eins projekt/projektrepo-eins
members = me@my.host.example he@his.host.example another@another.host.example

[group myself]
writable = private projekt/projektrepo-private
members = me@my.host.example

Zur Gruppe "gitosis-admin" gehört also der Benutzer, der über den SSH-Key "admin@admin.host.example" identifiziert wird; dieser hat Zugriff auf das Konfigurations-Repository "gitosis-admin". Zur Gruppe "friends" gehören neben mir ("me@my.host.example")  auch noch zwei andere, und diese Gruppe hat Zugriff auf zwei verschiedene Repositories; zur Gruppe "myself" gehöre nur ich mit Zugriff auf zwei weitere Repositories. Statt Lese- und Schreibzugriff ("writable") kann auch ein bloßer Lesezugriff vergeben werden.

Diese Repositories werden dann im Anschluss konfiguriert:

### repos #####----------------
[repo repo-eins]
## Oneline description of the project, mostly for gitweb.
description = Repository Number One
## Owner of this repository. Used in gitweb list of projects.
owner = John Doe
## Allow git-daemon to publish this repository.
daemon = yes
## Allow gitweb to show this repository.
gitweb = yes

[repo projekt/projektrepo-eins]
description = Repository for our project
owner = John Doe
daemon = yes
gitweb = yes

[repo private]
description = Private repository
owner = John Doe
daemon = no
gitweb = no

[repo projekt/projektrepo-private]
description = Another repository for our project
owner = John Doe
daemon = no
gitweb = no

Auch das sollte eigentlich selbsterklärend sein. Zu beachten ist, daß die Angaben unter "daemon" und "gitweb" nur steuern, ob gitosis eine entsprechende "magische" Datei git-daemon-export-ok für git-daemon anlegt bzw. das Repository in eine Projektdatei für gitweb aufnimmt. Ob die entsprechenden mit "yes" gekennzeichneten Repositories dann via gitweb oder git-daemon auch wirklich verfügbar sind (und vor allem die mit "no" gekennzeichneten nicht!), ist eine Frage der Konfiguration dieser beiden Programme.

Nunmehr müssen für die in der gitosis.conf definierten Benutzer noch jeweils deren öffentliche SSH-Key hinterlegt werden, und zwar in keydir, wobei für jeden Nutzer eine Datei mit dem Namen $nutzername.pub angelegt werden muß, die mindestens einen Schlüssel enthalten muß, aber auch mehrere Schlüssel enthalten darf. Der oder die Schlüssel des Nutzers "me@my.host.example" gehören also in die Datei me@my.host.example.pub.

Schließlich müssen die Dateien mit dem Schlüsseln mittels git add hinzugefügt und alle Änderungen mittes git commit -a committed werden; danach wird das Repository mittels git push an gitosis verfüttert. Voilà!

2. git-daemon

git-daemon ist recht einfach zu installieren:

aptitude install git-daemon-run

git-daemon-run verwendet allerdings nicht die gewohnten Scripts in /etc/init.d, sondern runit/runsv, so dass sich ein Symlink lohnt:

ln -s /usr/bin/sv /etc/init.d/git-daemon

Außerdem sollte /etc/sv/git-daemon/run noch entsprechend konfiguriert werden:

#!/bin/sh
exec 2&gt;&amp;1
echo 'git-daemon starting.'
exec chpst -ugitdaemon /usr/lib/git-core/git-daemon --verbose --enable=upload-pack --enable=upload-archive --base-path=/home/gitosis/repositories /home/gitosis/repositories

Statt "-ugitdaemon" wäre ggf. bei neueren Versionen des gitosis-Pakets in Debian "-ugitosis" zu verwenden; der Pfad /home/gitosis/repositories ist (zweimal) ggf. durch den Pfad zu den in gitosis angelegten Repositories zu ersetzen, im Falle des Debian-Paketes standardmäßig /srv/gitosis (den Grund für meine diesbezügliche Änderung habe ich weiter oben beschrieben).

Schließlich muß man sich noch entscheiden, welche Services der git-daemon bieten soll. "upload-pack" erlaubt den Zugriff via git fetch, git pull und git clone, "upload-archive" die Verwendung von git archive.

Das sollte es dann gewesen sein.

3. gitweb

Das gitweb-Paket aus Debian Lenny kann gleichfalls in wenigen Schritten installiert und konfiguriert werden; danach ist nur noch der Webserver - in meinem Fall Apache 2.2 - entsprechend anzupassen, wobei ich für gitweb einen eigenen vhost aufgesetzt habe.

a) gitweb

aptitude install gitweb

Dann kommt die /etc/gitweb.conf an die Reihe:

# path to git projects (&lt;project&gt;.git)
#$projectroot = "/var/cache/git";
$projectroot = "/home/gitosis/repositories/";

# directory to use for temp files
$git_temp = "/tmp";

# target of the home link on top of all pages
#$home_link = $my_uri || "/";

# html text to include at home page
$home_text = "indextext.html";

# file with project list; by default, simply scan the projectroot dir.
# $projects_list = $projectroot;

# Point to projects.list file generated by gitosis.
$projects_list = "/home/gitosis/gitosis/projects.list";

# stylesheet to use
$stylesheet = "/gitweb.css";

# logo to use
$logo = "/git-logo.png";

# the 'favicon'
$favicon = "/git-favicon.png";

# A list of base urls where all the repositories can be cloned from.
# Easier than having per-repository cloneurl files.
@git_base_url_list = ('git://git.host.example');

"$projectroot" ist hier der Pfad zu den von gitosis angelegten Repositories, standardmäßig /srv/gitosis/repositories; "$projects_list" umfasst die Repositories, die gitweb anzeigen soll, und ist entweder ein Verzeichnis (bspw. $projectroot), in dem die Repositories liegen, oder eine Datei mit einer Liste der Repositories. Wenn man hier die Funktionalität von gitosis nutzen will, in der gitosis.conf zu steuern, welche Repositories gitweb anzeigen soll, dann ist es wichtig, hier auf die von gitosis erzeugte Projektliste zu verweisen, wie im obigen Beispiel geschehen! Wenn man sicherstellen will, daß gitweb nicht nur die Anzeige der Repositories auf die in der Liste gezeigten beschränkt, sondern auch nur diese Repositories überhaupt zum Abruf über das Webinterface anbietet, muß die Konfiguration hier noch um

$strict_export = "true";

ergänzt werden. Schließlich können noch allgemeine Parameter wie "@git_base_url_list" gesetzt werden.

b) apache2 

Für den Webserver konfiguriere ich, wie einleitend beschrieben, einen eigenen vhost in /etc/apache2/sites-available/gitweb:

<VirtualHost *:80>
    ServerName git.host.example
    ServerAdmin webmaster@host.example

    HeaderName HEADER

    # bogus but safe DocumentRoot
    DocumentRoot /var/cache/git

    #Alias /robots.txt /var/www/cvs.robots.txt
    Alias /gitweb.css /usr/share/gitweb/gitweb.css
    Alias /git-favicon.png /usr/share/gitweb/git-favicon.png
    Alias /git-logo.png /usr/share/gitweb/git-logo.png
    ScriptAlias / /usr/lib/cgi-bin/gitweb.cgi
</VirtualHost>

Ich füge außerdem den Benutzer www-data, unter dem der Apache-Webserver läuft, noch in /etc/group zur Gruppe gitosis hinzu, damit er die Repositories lesen kann.

Danach aktiviere ich den zuvor angelegten vhost:

a2ensite gitweb
/etc/init.d/apache2 reload

Jetzt sollte unter http://git.host.example/ das Webinterface von gitweb mit den freigegebenen - und befüllten! - Repositories auftauchen.

Fertig! :-)

Trackbacks

Aus dem Leben eines Szlauszafs am : code.th-h.de

Vorschau anzeigen
Entsprechend der gestern hier vorgestellten Anleitung habe ich jetzt öffentlich verfügbare git-Repositories unter code.th-h.de angelegt und dort die (wenigen) von mir entworfenen / gepflegten Scripts hochgeladen sowie entsprechende Links auf meinen Downlo

Aus dem Leben eines Szlauszafs am : gitweb mit Passwortschutz

Vorschau anzeigen
gitweb ist, wie vorgestern beschrieben, eine schöne Sache - aber nicht immer will man seine Repositories jedermann zugänglich machen. Schön wäre es doch, wenn man die Möglichkeit hätte, auch den Zugriff auf gitweb an eine Anmeldung zu koppeln und so nur f

serversupportforum.de am : PingBack

Vorschau anzeigen

unki2aut.wordpress.com am : PingBack

Vorschau anzeigen

www.hirner.at am : PingBack

Vorschau anzeigen

www.hirner.at am : PingBack

Vorschau anzeigen

www.hirner.at am : PingBack

Vorschau anzeigen

helmut.hirner.at am : PingBack

Vorschau anzeigen

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

NoName am :

NoName

Hallo,

hänge leider an dem Punkt der mehren User. Kann man das nicht irgend wie mit Username/Passwort anstatt mit ssh Keys realisieren?

Wozu brauch ich den login für den gitosis, kann man da nicht einfach sagen login verboten?

Vielen dank für weitere Informationen.

Thomas Hochstein am :

Thomas Hochstein

QUOTE:
hänge leider an dem Punkt der mehren User. Kann man das nicht irgend wie mit Username/Passwort anstatt mit ssh Keys realisieren?

Nein.

Gitosis realisiert den SSH-Zugriff für verschiedene "virtuelle" User in der Weise, daß die SSH-Keys aller dieser "virtuellen" Benutzer in der authorized_keys-Datei des Benutzers gitosis (oder wie auch immer man den nennt) gesammelt werden, das einzige beim Login ausführbare Kommando aber "gitosis-serve" mit den passenden Parametern ist. Das ist nur beim Login mit SSH-Keys möglich.

QUOTE:
Wozu brauch ich den login für den gitosis, kann man da nicht einfach sagen login verboten?

Nein. Über den Login für gitosis greifen alle "virtuellen" Benutzer per SSH zu.

NoName am :

NoName

Wie realisiere ich es dann, wenn ich nur Windows Clients habe und somit keinen ssh key generieren kann?

Gibt es auch ein HowTo passend für eclipse?!

Thomas Hochstein am :

Thomas Hochstein

QUOTE:
Wie realisiere ich es dann, wenn ich nur Windows Clients habe und somit keinen ssh key generieren kann?

Auch unter Windows kann man ssh-Keys generieren (bspw. mit PuTTYgen aus dem putty-Paket; auch die meisten anderen SSH-Clients dürften entsprechende Tools enthalten). Alternativ kann man den unter Unix generierten Key unter Windows verwenden.

Es gibt abgesehen davon natürlich auch immer die Möglichkeit, statt gitosis zu verwenden einfach für jeden Nutzer einen eigenen Account anzulegen und - unter Erzeugung passender Gruppen - die Dateirechte passend zu setzen.

QUOTE:
Gibt es auch ein HowTo passend für eclipse?!

Google spuckt bspw. http://www.eclipse.org/egit/ aus, oder http://www.eclipse.org/resources/resource.php?id=528 - oder http://altdotperspective.blogspot.com/2009/07/sharing-git-repositories-with-gitosis.html - oder … oder … oder …

NoName am :

NoName

Noch eine letzte wahrscheinlich wieder dumme Frage, wenn ich mit Putty-Tools einen key generiere was trag ich dann in die conf ein? name@server Wie müsste das lauten?

NoName am :

NoName

Leider nimmt er wenn ich mich einloggen will, nie den Schlüssel an. Danach fragt er nach einem PW.

oete am :

oete

beim Versuch git clone gitosis@localhost:gitosis-admin.git gitosis-admin auszuführen bekomme ich leider

fatal: ‘gitosis-admin.git’ does not appear to be a git repository fatal: The remote end hung up unexpectedly

die Initialisierung scheint aber zu funktionieren, da nach

sudo -H -u gitosis gitosis-init < meinKey

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

erscheint. hat jemand das gleiche Problem? Und gelöst? vg

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Favatar, Pavatar, Twitter, Identica, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen
tweetbackcheck