Sobald man im Team arbeitet, will man eigentlich immer gemeinsam an einem Datenbestand arbeiten. Git kann auf dem Server so eingerichtet werden, dass alle Team Mitglieder auf ein oder mehrere Repositories zugreifen können.
Git Repository einrichten
Hier zeige ich auf, wie man einen eigenen Git Server einrichtet. Was am Server installiert und konfiguriert werden muss, damit diese Vorgehensweise funktioniert.
Was muss das Repository für Teamarbeit erfüllen?
- Zugriff von allen Team-Mitglieder sollte immer möglich sein Ein Server muss zum Einsatz kommen, der 24h erreichbar ist. Dazu kann ein öffentlicher Server, ein firmen-interner Server verwendet werden.
- Authentifizierung Jedes Team-Mitglied benötigt eine eigene Kennung, damit nachvollziehbar ist, wer welche Änderungen durchgeführt hat. Zusätzlich ist es dadurch auch möglich den Zugriff auf das Repository nur für Team-Mitglieder freizugeben - alle anderen haben entweder gar keinen Zugriff oder nur Lesezugriff.
- Ein zentraler Server Git ist zwar ein dezentrales Versionierungssystem, aber was hält einen davon ab ein "Hauptrepository" zu bestimmen, welches gemeinsam von allen Team-Mitgliedern verwendet wird. Auf dieses Repository werden dann von allen Projektteilnehmern push und pull ausgeführt.
Server Konfiguration
Auf dem Server muss natürlich auch erst einmal Git installiert werden. Es gibt keine spezielle Version von Git für den Server (oder den Client), da jeder pull aus einem Repository das komplette Repository dupliziert, kann jedes Team-Mitglieder einen Server bereit stellen.
Hinweis: In der Beschreibung werde ich die Server Installation auf ein Debian System beziehen. Wird Ubuntu eingesetzt, muss man ein sudo vor den Anweisungen stellen, da diese Root-Rechte benötigen. Auch auf andere Linux Distributionen sollte die Anleitung leicht zu übertragen sein.
Für Debian:
apt-get install git-core python-setuptools
Für Ubuntu:
sudo apt-get install git-core python-setuptools
Für Centos und Fedora:
yum install git-core python-setuptools
Für Gentoo:
emerge git-core dev-python/setuptools
Die Python Setuptools werden für gitosis benötigt (siehe weiter unten).
Authentifizierung
Das bekannte Version Control System bietet mehrere Möglichkeiten zur Authentifizierung an:
- das eigene Git Protokoll - öffentlich (eigentlich keine Authentifizierung)
- Webserver Authentifizierung (Apache)
- SSH (Secure Shell)
Im folgenden wird die Authentifizierung über SSH beschrieben: Alle Teammitglieder werden auf ein Repository mit Schreibrechten Zugriff haben, alle anderen haben keinen Zugriff.
Wir setzen das Python Script gitosis für die Verwaltung der SSH Zugänge ein. Das besondere an gitosis ist, dass alle Zugänge nur einen einzigen Systemaccount benötigen. Ein Shell-Login über diesen globalen Account wird den Team-Mitgliedern auf dem Server selbst nicht möglich sein, sondern nur der Zugriff auf das GIT-Repository (dies wird über die command= Anweisung in der authorized_keys erreicht). Um dies zu bewerkstelligen verwendet gitosis einen genialen Trick: die Authentifizierung findet über den Namen des öffentlichen SSH Schlüssels statt. Jeder Benutzer sendet seinen öffentlichen Schlüssel an Verwalter des gemeinsamen Repositories. Die öffentlichen Schlüssel werden dann von gitosis automatisch in die Datei authorized_keys übernommen, welche den SSH Zugriff so für mehrere Benutzer möglich macht. Die Unterscheidung zwischen den einzelnen Mitgliedern wird über den Dateinamen des öffentlichen Schlüssels ermöglicht.
Zuerst holen wir uns den Quellcode mit:
cd /tmp
git clone git://eagain.net/gitosis
Nun installiert man gitosis mit:
cd gitosis
python setup.py install
Wurde keine Fehlermeldung dabei ausgegeben, kann das Verzeichnis /tmp/gitosis gelöscht werden (es wird nicht weiter benötigt).
Danach legen wir den Benutzer git an (es kann ein beliebiger Name sein; falls Du einen anderen verwenden willst, musst Du dies in der weiteren Anleitung berücksichtigen), über den alle Zugriff auf die GIT Repositories erfolgen:
adduser \
--shell /bin/sh \
--gecos 'git version control' \
--ingroup 'www-data' \
--disabled-password \
--home /srv/git \
git
Es ist wichtig, dass ein Shell angegeben wird, da sonst der SSH Zugang nicht funktionieren wird. Als Gruppe wird hier www-data verwendet, damit auch die Verwendung von gitweb möglich ist. Will man gitweb nicht verwenden, sollte man den Benutzer mit folgendem Befehl anlegen:
adduser \
--system
--shell /bin/sh \
--gecos 'git version control' \
--group \
--disabled-password \
--home /srv/git \
git
Dadurch wird für den Benutzer als primäre Benutzergruppe ‘nogroup’ verwendet.
Das Home-Verzeichnis des Benutzers git ist /srv/git. Darin befinden sich alle SSH Schlüssel zur Authentifizierung und auch alle Repositories, die man verwendet. Es sollte also viel Festplattenplatz für dieses Verzeichnis vorhanden sein (viele Projekte mit großen Repostiories benötigen viel Platz ;)).
Um gitosis zu initialisieren, wird ein SSH Schlüssel benötigt, den man auf seinen lokalen Arbeitsplatz anlegt.
ssh-keygen -t rsa -C 'Mein Name'
Dieser Befehl legt die Dateien ./ssh/id_rsa (privater Schlüssel) und ./ssh/id_rsa.pub (öffentlicher Schlüssel) an. Falls schon Schlüssel vorhanden sind, können selbstverständliche auch diese verwendet werden. Den öffentlichen Schlüssel überträgt man nun auf den Git Server ins Verzeichnis /tmp (dies ist die Voraussetzung für den nächsten Schritt; der öffentliche Schlüssel wird unter dem Pfad /tmp/benutzername.pub erwartet!) Die Übertragung des Schlüssels kann z.B. mit scp erfolgen:
scp .ssh/id_rsa.pub mein-server.de:/tmp/benutzername.pub
Hinweis: Der private SSH Schlüssel sollte niemals aus der Hand gegeben und auch nicht übers Netz übertragen werden.
Es empfiehlt sich die SSH Konfiguration für den Git Server (mit Git Server meine ich immer den Server, der als zentraler Teamserver verwendet werden soll) in die lokale ./ssh/config Datei aufzunehmen:
Host mein-git-server.de
User git
# falls man einen anderen Port verwendet, muss dieser hier gesetzt werden
# Port 22
IdentityFile ~/.ssh/id_rsa
Dadurch erspart man sich den Benutzer bei jeder Kommunikation mit dem GIT Server mit anzugeben. Auch kann man durch diese Konfigurationsdatei den Ort des privaten SSH Schlüssels angeben (falls dieser von dem Standard Schlüssel abweicht).
Nun kann gitosis initialisiert werden:
sudo -H -u git gitosis-init < /tmp/benutzername.pub
sudo chmod +x /srv/git/repositories/gitosis-admin.git/hooks/post-update # muss ausführbar sein!
Wenn alles glatt läuft, werden folgende Meldungen ausgegeben:
Initialized empty Git repository in ./
Initialized empty Git repository in ./
``` (2mal die gleiche Meldung, das ist kein Fehler)
Die weiteren Arbeitsschritte werden auf dem lokalen Rechner durchgeführt (nicht auf dem Server).
Zuerst holt man sich das Repository gitosis-admin mit:
cd /www # in das Verzeichnis wechseln, in dem man das Repository führen will git clone git@mein-git-server.de:gitosis-admin.git
Hierbei ist zu beachten, dass der Benutzername <em>git</em> immer verwendet wird, für alle Benutzer! gitosis unterscheidet die Benutzer durch den Dateinamen des öffentlichen SSH Schlüssels, welcher verwendet wird.
Es sollte folgende Meldung zu sehen sein:
Initialized empty Git repository in /Users/alex/gitosis-admin/.git/ remote: Counting objects: 146, done. remote: Compressing objects: 100% (145/145), done. remote: Total 146 (delta 43), reused 4 (delta 0) Receiving objects: 100% (146/146), 17.18 KiB, done. Resolving deltas: 100% (43/43), done.
<em>The hard part is over</em>, wie es in Kill Bill so schön heißt. Was jetzt noch fehlt ist die Konfiguration der einzelnen Repositories und die Zugriffsrechte dazu.
<h3>Testen des SSH Zugangs</h3>
Mit folgendem Test kannst Du verifizieren, ob der SSH Zugang für den Benutzer <em>git</em> richtig konfiguriert ist.
Der Befehl:
ssh mein-git-server.de
sollte folgendes ausgeben:
TY allocation request failed on channel 0 ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment. Connection to mein-git-server.de closed.
Erklärung: Die SSH Authentifizierung war erfolgreich. Ein Login ist allerdings nicht möglich, da dieser für den "git" Benutzer nicht gestattet ist. Diese Meldung bedeutet also, dass alles in bester Ordnung ist. Falls ein Login möglich ist, stimmt etwas nicht!
Sieht man folgende Fehlermeldung, stimmt etwas mit dem SSH Zugang nicht:
Permission denied (publickey).
(wenn die SSH Kennwortauthentifizierung aktiv ist, kann es hier auch zu einer Kennwortabfrage kommen, die nur dann kommt, wenn etwas schief läuft)
Mögliche Ursachen für diesen Fehler können sein:
<ul>
<li>Login wurde für den Benutzer git gesperrt (z.B. ungültige Shell in /etc/passwd eingetragen)</li>
<li>Öffentlicher Schlüssel des Benutzers wurde nicht hinterlegt</li>
<li>Fehlerhafte Konfiguration in gitosis.conf</li>
<li>Privater Schlüssel wurde nicht verwendet (oder vielleicht ein falscher Schlüssel)</li>
<li>Privater Schlüssel wurde anstelle des öffentlichen Schlüssels auf Server hinterlegt (dies ist leider auch schon aufgetreten, Namen nenne ich keine ;))</li>
<li>Ein Team-Mitglied benutzt nicht den Benutzernamen <em>git</em> für die SSH Authentifizierung</li>
</ul>
Des weiteren ist es ratsam einen Blick in die Datei /var/log/auth.log zu werfen (darin werden Authentifizierungsmeldungen protokolliert).
<h3>System absichern</h3>
Das Verzeichnis /srv/git sollte nur durch den Owner und den Gruppenmitgliedern eingesehen werden können. Dies erreicht man mit:
chmod 750 /srv/git chown git:www-data /srv/git
Da die SSH Authentifizierung über Schlüssel verwendet wird, sollte die Kennwort-Authentifizierung deaktiviert werden. Dazu ändert man in der Datei /etc/ssh/sshd_config die Zeile:
```html
#PasswordAuthentication yes
in
PasswordAuthentication no
und startet dann den SSH deamon neu mit
invoke-rc.d ssh restart
Wichtig: Bevor mal die SSH Kennwortauthentifizierung abschaltet, unbedingt vorher SSH Schlüssel für die System-Accounts einrichten, über die weiterhin ein SSH Login erforderlich ist.
Verwaltung der GIT Repositories
Die Verwaltung der Repositories erfolgt über das Repository gitosis-admin. Im Unterverzeichnis keydir werden alle öffentlichen Schlüssel der Benutzer abgelegt, die auf Repositories Zugriff haben. Der Dateiname stellt den Benutzernamen dar.
Hier ein Beispiel:
# ls -1 keydir/
alex.pub
andi.pub
claudi.pub
flobruit.pub
reinhard.pub
Die Konfiguration von Benutzergruppen und wer auf welches Repository zugreifen darf, erfolgt in der Datei gitosis.conf:
# gitosis example
[gitosis]
# team gitosis-admin, Administrators for repositories
[group gitosis-admin]
writable = gitosis-admin
members = alex
# team squatlabs
[group squatlabs]
writable = repos1 repos2 # repositories repos1 and repos2
members = alex claudi
# team devdays
[group devdays]
writable = devdays # repository devdays
members = flobruit andi reinhard @squatlabs
In dem Beispiel werden 3 Benutzergruppen definiert: gitosis-admin, squatlabs und devdays. Die Mitglieder der Benutzergruppe gitosis-admin haben Schreibzugriff auf das Repository gitosis-admin, welches die öffentlichen SSH Schlüssel und die gitosis.conf enthält. Die Benutzer in dieser Gruppe können somit die Verwaltung aller Repositories durchführen.
Die Gruppe squatlabs hat Zugriff auf die beiden Repositories repos1 und repos2. Mitglieder dieser Gruppe sind die Benutzer alex und claudi (es müssen also die beiden öffentlichen Schlüssel alex.pub und claudi.pub im Verzeichnis keydir vorhanden sein).
Die dritte Gruppe devdays hat Zugrif auf das Repository devdays. Es haben die 3 Benutzer flobruit, andi und reinhard Schreibrechte. Weiterhin haben auch alle Benutzer der Gruppe squatlabs Schreibrechte auf das Repository devdays.
Neues Repository anlegen
In der Datei gitosis.conf wird das neue Repository zu den gewünschten Benutzergruppen hinzugefügt. Sofort nach dem Commit dieser, kann von den Benutzern der Benutzergruppen mit Schreibrechten das neue Repository angelegt werden. Hierzu werden folgende Kommandos ausgeführt (auf dem Arbeitsplatzrechnern, nicht auf dem Server!):
mkdir mein_projekt
cd mein_projekt
git init
touch dummy.txt && git add dummy.txt && git commit -m 'dummy file'
git remote add origin git@mein-git-server.de:mein_projekt.git
git push origin master:refs/heads/master
Wichtig ist dabei, dass mindestens ein Commit durchgeführt wurde, bevor man den push ausführt (anderfalls wird eine Fehlermeldung erzeugt). Anstelle der dummy.txt Datei können natürlich auch bestehende Dateien in das Verzeichnis kopiert werden, die ins Repository übernommen werden sollen. Hier im Beispiel wird als Repository-Name mein_projekt verwendet, welches mit dem gleichen Namen in der gitosis.conf als writable für den Benutzer eingetragen sein muss.
Nach dem Push ist auf dem Git Server das Verzeichnis /srv/git/repositories/mein_projekt vorhanden.
Das Repository kann jetzt von allen Team Mitglieder mit folgenden Befehl verwendet werden:
git clone git@mein-git-server.de:mein_projekt
Wichtig: alle Team-Mitglieder müssen als Benutzername “git” verwenden (und nicht den Benutzernamen, der für den öffentlichen Schlüssel verwendet wurde).
Repository entfernen
Will man ein Repository entfernen, müssen alle Verweise auf dieses Repository aus der Datei gitosis.conf entfernt werden. Das Repository selbst kann nur auf dem Git Server gelöscht werden. Dazu löscht man das komplette Verzeichnis /srv/git/repositories/MEIN-REPOSITORY.git
Neues Team-Mitglied aufnehmen
In der Datei gitosis.conf den Benutzer in die gewünschten Gruppen hinzufügen, auf der dieser Zugriff bekommen soll. Weiterhin ist es erforderlich einen öffentlichen SSH Schlüssel im Verzeichnis keydir abzulegen, dessen Dateiname mit dem Benutzernamen übereinstimmt. Beispiel: für Benutzer alex muss eine Key mit dem Namen keydir/alex.pub existieren.
Team-Mitglied entfernen
In der Datei gitosis.conf den Benutzer aus der gewünschten Gruppe entfernen. Ist der Benutzer in keiner Gruppe mehr vorhanden, kann auch sein öffentlicher Schlüssel aus dem Verzeichnis keydir gelöscht werden.
Webfront zu den Repositories
Es gibt viele Webfronts für GIT, eines davon ist gitweb und wird mit Git ausgeliefert. Dieses werden wir nun so einrichtet, dass damit alle Repositories eingesehen werden können.
Folgender vhost muss dazu angelegt werden, z.B. in der Datei /etc/apache2/sites-available/git:
<VirtualHost *:80>
DocumentRoot /srv/git/repositories
ServerName mein-git-server.de
ErrorLog /var/log/apache2/git_error.log
CustomLog /var/log/apache2/git_access.log combined
Alias /gitweb.css /usr/share/gitweb/gitweb.css
Alias /git-logo.png /usr/share/gitweb/git-logo.png
Alias /git-favicon.png /usr/share/gitweb/favicon.ico
<Directory /srv/git/repositories>
AuthType Basic
AuthName "Projekt Team"
AuthUserFile /srv/git/.htpasswd
AllowOverride None
Order allow,deny
Allow from all
Require valid-user
AddHandler cgi-script cgi
DirectoryIndex gitweb.cgi
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
</Directory>
</VirtualHost>
Nun muss noch ein Benutzer angelegt werden, der Zugriff auf das Webfrontend bekommt:
htpasswd /srv/git/.htpasswd benutzer
Der Benutzer benutzer hat nun Zugriff aus das Webfrontend und kann ALLE Repositories einsehen. Falls ein Benutzer nur ein bestimmtes Repository einsehen darf, müssen dafür eigene Directory Anweisungen in der vhost Konfigurationsdatei gesetzt werden. Beachte: Wenn vertrauliche Daten in den Repositories vorhanden sind ist sehr genau darauf zu achten, wer Zugriff über das Webfrontend erhält, da standardmäßig alle Repositories eingesehen werden können.
Die Konfiguration für gitweb wird in der Datei /etc/gitweb.conf festgelegt. Hier ist es wichtig, dass folgende Zeile geändert wird:
$projectroot = "/home/git/repositories";
in
$projectroot = "/srv/git/repositories";
Als letzter Arbeitsschritt muss nun noch der vhost aktiv geschaltet werden und der Webserver neu gestartet werde:
a2ensite git
invoke-rc.d apache2 restart
Nun sollte im Webbrower unter dem verwendeten Hostname (im Beispiel mein-git-server.de) das Webfrontend aufzufinden sein.
Weitere Informationen
- gitosis README
- Hosting Git repositories, The Easy (and Secure) Way
- gitolite, als Alternative zu gitosis
Projektmanagement Services, Consulting und Coaching
Unser Projektmanagement Team aus München ist hervorragend ausgebildet und verfügt über die nötige Expertise, Erfahrung und das Augenmaß, wenn es darum geht in Kundenprojekten die richtigen Tools einzuführen, zu konfigurieren und bestehende Prozesse zu optimieren. Unser Ziel ist es für einen reibungslosen Projektverlauf zu sorgen. Kontaktieren Sie uns unverbindlich.