GIT-Server auf Linux Ubuntu

Bisher haben wir im Studium all unsere Projekte mithilfe eines SVN-Repositorys (eingebunden in eine Trac-Webumgebung) entwickelt, dokumentiert und versioniert. Nun wurde uns das VCS Git näher gebracht, was mir persönlich besser gefällt 🙂

Da ich mich gerne damit beschäftige, wie man solch tolle Systeme für mehrere Benutzer bereitstellen kann, hier ein kleines How-To, wie man einen GIT-Server aufsetzen kann…

HINWEIS

Ich habe dieses How-To NICHT während des Ausprobierens, sondern NACHDEM alles Beschriebene funktionierte, verfasst. Soll heißen, dass Zwischenschritte fehlen können. Also BITTE hinterlasst mir einen Kommentar, wenn dies der Fall sein sollte. Danke 🙂

Vorbereitung

Um nicht meinen produktiven Server eventuell zu beschädigen, habe ich mir ein kleines VM-Netzwerk zusammengeschraubt. Zur Einrichtung dessen brauchst du lediglich ~20GB freien Speicherplatz, den VMware Player und eine Ubuntu-ISO-Datei.

VM-Netzwerk

Erste VM einrichten

Nachdem die Installation vom Player abgeschlossen ist, kann sofort damit begonnen werden die erste VM zu erstellen (wie geht das?). Den Netzwerk-Adapter habe ich auf „Bridged“ gestellt, damit jede VM eine andere IP-Adresse bekommt.

Nach Installation des Ubuntu-OS empfiehlt es sich die VMware Tools zu installieren.

Anschließend die VM starten, einloggen und alle Updates einspielen:

sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade

Nach einem Neustart kann Git installiert werden:

sudo apt-get install git

Dann herunterfahren und ausschalten, damit sie im nächsten Schritt kopiert werden kann.

VM kopieren & starten

Ein großer Vorteil des VMware Players ist, dass alle zu einer VM gehörenden Dateien in einem Verzeichnis liegen (Virtual Machines in Documents). Ich habe mir von der obigen VM 3 Kopien angelegt. Nach jeder Kopie solltest du sofort den Verzeichnisnamen (im Dateisystem) und den VM-Namen (im Player) ändern. Meine VMs haben z.B. nun folgende Namen:

  1. GIT-Server
  2. GIT-Client-1
  3. GIT-Client-2
  4. Ubuntu-1204-CLEAN (als Sicherung)

Jetzt können, Stück für Stück, die VMs gestartet werden. Beim ersten Start wird gefragt, ob die VM verschoben oder kopiert wurde. Dabei das zweitere auswählen!

Clients

Bei der späteren Kommunikation mit dem GIT-Server kommen die Protokolle Git+SSH zum Einsatz. Diese Methode ist verdammt sicher, da der Datenaustausch über Schlüsselpaare stattfindet. Diese müssen wir auf den Clients erstellen:

ssh-keygen -t rsa -C 'Dein Name'

… erzeugt den privaten Schlüssel id_rsa und den öffentlichen id_rsa.pub in .ssh im Homeverzeichnis. Der private sollte niemals aus der Hand gegeben werden!!!

Der öffentliche Schlüssel kann schon zu späteren Verwendung auf den Server bzw. Client-1 übertragen werden.

Von Client-1 auf Server:

user@client1:~/.ssh$ scp id_rsa.pub user@server:/tmp/user1.pub
user@server's password:
id_rsa.pub                                     100%  402     0.4KB/s   00:00

Von Client-2 auf Client-1:

user@client2:~/.ssh$ scp id_rsa.pub user@client1:/tmp/user2.pub
user@client1's password:
id_rsa.pub                                     100%  402     0.4KB/s   00:00

Hier sei schonmal vorgemerkt, dass der Schlüssel von Client-1 der „Admin“-Zugang sein wird!

Server

weitere Pakete

sudo apt-get install git-core git-doc apache2

Zitat von Alexander Meindl: Authentifizierungs-Prinzip von gitolite

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.

Hier ist zwar die Rede von gitosis, aber gitosis wurde mehr oder weniger durch gitolite ersetzt und das Prinzip der Authentifizierung ist gleich geblieben!

gitolite installieren

sudo apt-get install gitolite

Während der Installation werden folgende Angaben gefragt:

  1. System-Account für gitolite: gitolite
  2. Pfad zu den Repositories: /var/lib/gitolite
  3. SSH-Key für Admin-Zugang: /tmp/user1.pub

Sollten die Angaben nicht abgefragt werden, so erledigt es ein reconfigure im Nachhinein:

sudo dpkg-reconfigure gitolite

Es wird ein Benutzer ‚gitolite‘ erstellt, sein Home-Verzeichnis ist gleichzeitig der Pfad zu den Repos und Konfigurationen an gitolite darf nur user1 durchführen.

Konfiguration

ACHTUNG/HINWEIS!

Zur Einrichtung/Erstellung/Änderung von Repositories, Benutzern und weiteren Einstellungen sollten ausschließlich die unten aufgeführten Methoden verwendet werden!

Repositories, Benutzer und Rechte

Dreh- und Angelpunkt dieser Geschichte ist die Konfigurationsdatei conf/gitolite.conf im gitolite-admin-Repository. Es ist immens wichtig zu beachten, dass diese nicht direkt am Server geändert wird!

Konfiguration durch Client-1

gitolite.conf

Wie bereits erwähnt, ist der SSH-Schlüssel von Client-1 der Admin-Zugang, der als einziger Zugriff auf das Admin-Repo hat. Dieses holen wir uns jetzt:

user@client1:~$ git clone gitolite@server:gitolite-admin.git
Cloning into 'gitolite-admin'...
remote: Counting objects: 52, done.
remote: Compressing objects: 100% (50/50), done.
remote: Total 52 (delta 10), reused 0 (delta 0)
Receiving objects: 100% (52/52), 5.10 KiB, done.
Resolving deltas: 100% (10/10), done.

… und schauen uns die, schon geänderte, Konfigurationsdatei an bzw. ändern sie zum Test so ab:

cd gitolite-admin/
cat conf/gitolite.conf
repo    gitolite-admin
        RW+     =   admin

repo    testing
    testing    =   "Test repository"
        RW+     =   @all

repo    foo
    foo    =   "Repository for User 1"
    RW+    =   user1

repo    bar
    bar    =   "Repository for User 2"
    RW+    =   user2
    R    =   user1

# give read access for gitweb and daemon
repo    testing foo bar
    R    =   gitweb daemon

Eigentlich ganz einfach, oder?

  • ‚user1‘ + ‚user2‘ haben Vollzugriff auf das Repo testing.
  • ‚user1‘ hat Vollzugriff auf foo und Leseberechtigung auf bar
  • ‚user2‘ hat Vollzugriff auf bar
  • und ‚admin‘, also ‚user1‘, hat Vollzugriff auf gitolite-admin

Die letzten 3 Zeilen sind wichtig für die Benutzung von ‚gitweb‘ (später!).

Hier gibt es mehr zu Benutzerrechten. Es können auch Gruppen definiert werden!

SSH-Schlüssel importieren

Wir haben in der Konfigurationsdatei den ‚user2‘ angegeben. Der Server braucht für diesen noch den gleichnamigen öffentlichen Schlüssel, welcher in den ersten Schritten auf Client-1 kopiert wurde. Auch der ‚admin‘-Schlüssel muss kopiert werden, sonst ist ‚user1‘ unbekannt:

cp /tmp/user2.pub keydir/user2.pub
cp keydir/admin.pub keydir/user1.pub

Änderungen auf Server übertragen

Änderungen lokal bekannt machen:

git add conf/
git add keydir/
git commit -m 'first repos und users created'

Ausgabe (in etwa):

[master 2347401] first repos und users created
... ... ...
 1 file changed, 5 insertions(+), 1 deletion(-)

Und auf Server übertragen:

git push

Ausgabe (in etwa):

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 466 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: creating foo...
remote: Initialized empty Git repository in /var/lib/gitolite/repositories/foo.git/
To gitolite@server:gitolite-admin.git
   b56dec8..2347401  master -> master

Was ist hier passiert?
Der Server hat gemerkt, dass die Konfiguration geändert wurde und hat die neuen Repos und Benutzer automatisch erstellt/eingerichtet. Nun sollte die Wichtigkeit des HINWEISes klar sein 😉

Testen

Was haben wir bereits?

Systeme

  • Server
  • Client-1 mit SSH-Schlüssel für user1
  • Client-2 mit SSH-Schlüssel für user2

Benutzer

  • user1 = admin
  • user2 = ’normaler‘ Benutzer

Repositories

  • testing (RW+ = @all)
  • foo (RW+ = user1)
  • bar (RW+ = user2 | R = user1)

und gitosis-admin, aber das brauchen wir jetzt nicht zum testen!

Repositories initialisieren

Die Repos wurden komplett leer erstellt, also müssen wir sie für die „richtige Verwendung“ initialisieren.

Für Repo foo muss das von Client-1 erfolgen:

git clone gitolite@server:foo.git

Ausgabe:

Cloning into 'foo'...
warning: You appear to have cloned an empty repository.
touch README
git add README
git commit -m 'README file created'
git push origin master

Ausgabe:

Counting objects: 3, done.
Writing objects: 100% (3/3), 233 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To gitolite@server:foo.git
 * [new branch]      master -> master

Für Repo bar muss das von Client-2 erfolgen…

Zugriffe testen

Die Initialisierung hat schon gezeigt, dass die Vollzugriffe funktionieren. Aber darf ‚user2‘ denn auch wirklich nicht auf foo zugreifen? Und darf ‚user1‘ in bar auch wirklich nur lesen?

Von Client-2:

git clone gitolite@server:foo.git

Ausgabe:

Cloning into 'foo'...
R access for foo DENIED to user2
(Or there may be no repository at the given path. Did you spell it correctly?)
fatal: The remote end hung up unexpectedly

Von Client-1:

git clone gitolite@server:bar.git

Ausgabe:

Cloning into 'bar'...
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.

Datei verändern und neue erstellen:

cd bar
nano README
touch hello-world.java
git add README hello-world.java
git commit -m 'This commit MUST NOT send to the git server!!!'
git push

Ausgabe für push:

W access for user1 DENIED to bar
(Or there may be no repository at the given path. Did you spell it correctly?)
fatal: The remote end hung up unexpectedly

Damit hätten wir das wohl auch geklärt 🙂

Zugriffsrechte auflisten

Mit

ssh gitolite@server info

kann man jederzeit prüfen, auf welche Repos man welche Rechte hat.

Ausgabe für Client-1:

hello admin, this is gitolite 2.2-1 (Debian) running on git 1.7.9.5
the gitolite config gives you the following access:
     R   W     foo
     R         bar
     R   W     gitolite-admin
    @R_ @W_    testing

Abschließende Worte

Mit dieser Konfiguration hat man nun eine gute Basis weitere Projekte zu entwickeln. Im nächsten Artikel wird ‚gitweb‘ beschrieben, mit dem es auf einer Web-Oberfläche möglich ist, alle Commit’s, Branches, etc. in allen Repos anzuschauen.

Ich habe dieses How-To NICHT während des Ausprobierens, sondern NACHDEM alles Beschriebene funktionierte, verfasst. Soll heißen, dass Zwischenschritte fehlen können. Also BITTE hinterlasst mir einen Kommentar, wenn dies der Fall sein sollte. Danke 🙂

Share

10 Kommentare von "GIT-Server auf Linux Ubuntu"

  1. Hendrik's Gravatar Hendrik
    5. März 2013 - 07:15 | Permalink

    Vielen Dank für diese Anleitung, nach der ich gitolite installiert habe. Ein Problem habe ich aber noch. Dieser Schritt:
    cp keydir/admin.pub keydir/user1.pub
    führt ja dazu, dass admin und user1 mit dem selben key identifiziert werden. Wie können sie denn dann unterschieden werden? Bei mir scheint es auf jeden Fall nicht zu funktionieren, ich werde immer als admin und nie als user1 identifiziert, habe dementsprechend nicht die gewünschten Zugriffsrechte auf die repositories.

    • Frank's Gravatar Frank
      1. April 2013 - 18:21 | Permalink

      … bei mir die selbe Problematik wie bei Hendrik 🙁

      • Hendrik's Gravatar Hendrik
        1. April 2013 - 18:43 | Permalink

        Ich habe es mit zwei verschiedenen Keys gelöst, einen für den Admin, einen für mich als User. Umschalten tue ich dann unter Verwendung einer SSH Konfigurationsdatei:
        http://nerderati.com/2011/03/simplify-your-life-with-an-ssh-config-file/
        ’ssh-add -l‘ zeigt Dir alle registrierten Schlüssel.

        • Frank's Gravatar Frank
          6. April 2013 - 18:28 | Permalink

          Ich kann die Lösung von Hendrik bestätigen. Ich habe mir auch einen 2. User (adm_user1) mit eigenem ssh-key angelegt und damit klappt es.

          Auch gitweb läuft inzwischen…

  2. 23. Oktober 2012 - 11:11 | Permalink

    Hey!
    Schön zu sehen das immer mehr Leute die Vorzüge von GIT schätzen lernen. 😉

    Gutes How-To!

  3. Arne Kühn's Gravatar Arne Kühn
    6. Oktober 2012 - 09:46 | Permalink

    Hallo Chrises!
    Super mal ein aktuelles How-To zu finden!
    … das auch noch funktioniert 😉

    Danke für deine Mühe und bis Bald

    Arne

Kommentar verfassen

1 Trackback von "GIT-Server auf Linux Ubuntu"

  1. am 28. September 2012 um 11:16