Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

Was fehlt?

Es liegt in der Natur der Sache: Ein Wiki ist niemals fertig. Wir geben uns große Mühe, mit der Entwicklung Schritt zu halten; lassen Supportanfragen direkt in neue Artikel einfließen … aber auch wir sind nicht perfekt. Wenn du hier nicht fündig wirst: Nicht schmollen - Bescheid sagen! Unter hallo@uberspace.de steht dir unser Team gerne bereit. Hand drauf!

cool:gitolite

Git-Repos für mehrere User verwalten

Dein Uberspace ist bereits von Haus aus mit Git-Unterstützung ausgestattet. Möchtest du als einzelner User ein Git-Repo auf deinem Uberspace verwalten (und ggf. zusätzlich öffentlich per HTTP(S) exportieren), so sind die dortigen Informationen völlig ausreichend.

Dieses Dokument hier bezieht sich auf einen erweiterten Einsatz von Git, nämlich auf die Situation, dass du mit mehreren Usern gemeinsam an einem auf deinem Uberspace gehosteten Repository arbeiten möchtest. Normalerweise wäre das nur möglich, in dem du allen betreffenden Usern deinen SSH-Zugang bereitstellst, in dem du deren SSH-Keys in deiner .ssh/authorized_keys hinterlegst - aber ein solcher Vollzugriff soll ja vermutlich nicht sein, jedenfalls nicht dann, wenn du in dem Uberspace noch andere Dinge betreibst. Hier kommt gitolite ins Spiel: Ein zusätzliches Tool, das es ermöglicht, mehrere Git-Repos unter einem Systemuser (also auf einem Uberspace) zu verwalten - und zwar für mehrere Benutzer. Der Clou ist, dass du den Benutzern dazu auch noch unterschiedliche Rechte vergeben kannst, sprich, wer welches Repository schreibend oder nur lesend nutzen darf.

Voraussetzungen

gitolite setzt für die Authentifizierung von Usern vollständig auf SSH-Keys. Eine Authentifizierung via Passwort ist nicht möglich. Das ist nicht zuletzt deshalb so, weil man bei Authentifizierung via Passwort nicht sehen kann, welche Person sich da gerade angemeldet hat - bei SSH-Keys hingegen schon, weil da ja jeder seinen eigenen hat.

Sowohl du als auch alle anderen User, die mit den auf deinem Uberspace gehosteten Git-Repos arbeiten sollen, müssen also zwingend SSH-Keys besitzen als auch dazu in der Lage sein, sie zu benutzen. Das funktioniert unter allen gängigen Betriebssystemen, nicht nur unter Linux. In unserer SSH-Doku findest du mehr Informationen zu SSH allgemein und auch zum Einsatz von SSH-Keys.

Einrichtung

(Solltest du bereits mit gitolite gearbeitet haben und dabei auf den Umstand, dass der gitolite-Admin, also du, normalerweise zwei SSH-Keys braucht, nämlich einen für die Shell und einen für gitolite: Wir lösen das hier anders, nämlich über den Kniff giving shell access to gitolite users. Wenn du nicht weißt, wovon wir hier in diesem Absatz reden: Macht gar nichts; lies dann einfach weiter.)

Für die Einrichtung muss zunächst dein eigener SSH-Key (also - natürlich nur der öffentliche Teil des Schlüsselpaars) als Datei vorliegen. Es spielt hierbei keine Rolle, ob er schon in der .ssh/authorized_keys steht oder nicht. Solltest du noch gar keinen haben, musst du dir zunächst auf deinem lokalen System ein Schlüsselpaar generieren:

[someuser@somehost ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/someuser/.ssh/id_rsa.
Your public key has been saved in /home/someuser/.ssh/id_rsa.pub.
[...]

Den public key dieses Schlüsselpaars musst du nun auf deinen Uberspace hochladen (wir nehmen mal an, du bist erna auf unserem Host eridanus), wobei es sinnvoll ist, dem Schlüssel einen „sprechenden“ Namen zu geben; du wirst gleich sehen, warum - hier nennen wir die Kopie des Schlüssels erna.pub:

[someuser@somehost ~]$ scp ~/.ssh/id_rsa.pub erna@eridanus.uberspace.de:erna.pub

Nun musst du gitolite auf deinem Uberspace initialisieren. Logge dich dazu erstmal per SSH ein. Hast du git auf deinem Uberspace bisher noch nie benutzt und entsprechend auch noch nie bekanntgemacht, wer du bist, führe bitte diese beiden Schritte mit deinen eigenen Daten aus (das ist jetzt nicht spezifisch für gitolite; das braucht git allgemein):

[erna@eridanus ~]$ git config --global user.email "erna@eridanus.uberspace.de"
[erna@eridanus ~]$ git config --global user.name "Erna Hatsvolldrauf"

Fertig? Prima, dann kannst du jetzt gitolite selbst initialisieren:

[erna@eridanus ~]$ gl-setup erna.pub
The default settings in the rc file (/home/erna/.gitolite.rc) are fine for most
people but if you wish to make any changes, you can do so now.

hit enter...

Wenn du nun Enter drückst, wird dir die angelegte Konfigurationsdatei .gitolite.rc zur Kontrolle und ggf. Bearbeitung angezeigt. Bitte ändere hier nichts. Den gestarteten vi-Editor kannst du durch Eingabe von :q wieder verlassen.

Wir nehmen an, dass du, wenn du schon mit SSH-Schlüsseln hantierst, den Key auch für den ganz normalen SSH-Zugang benutzen willst - das richten wir im nächsten Schritt ein.

Wenn du deinen SSH-Key schon vorher in deiner .ssh/authorized_keys eingetragen hast, musst du ihn zunächst entfernen und den folgenden Schritt trotzdem zwingend durchführen. Er wird deinen Schlüssel gleich wieder autorisieren, aber - und das ist hier der Knackpunkt - sowohl für den Shell-Zugang als auch für den gitolite-Zugang:

bei CentOS-5-Hosts

[erna@eridanus ~]$ gl-tool shell-add erna.pub 
--- /home/erna/.ssh/authorized_keys	2011-04-11 11:06:02.000000000 +0200
+++ /home/erna/.ssh/authorized_keys.new	2011-04-11 11:06:04.000000000 +0200
...
If the above diff looks ok, press enter. Else press Ctrl-C.

Du kannst hier die Ausgabe einfach mit Enter bestätigen.

bei CentOS-6-Hosts

[erna@eridanus ~]$ gl-tool add-shell-user erna.pub 

Solltest du schon vorher deinen SSH-Schlüssel manuell eingetragen, hier nochmal der Hinweis, dass du ihn dann spätestens jetzt entfernen musst. Du wirst sonst nur den SSH-Zugang nutzen können, aber nicht gitolite.

Ein Wort der Mahnung

Das während der Ausführung von gl-setup angelegte Verzeichnis .gitolite in deinem Home-Verzeichnis ist strikt tabu für jegliche manuelle Bearbeitung. Das gilt auch für die darin liegenden Repos, die reine Bare-Repos sind, die nur via git clone, git pull, git push etc. angesprochen werden sollten. Der Grund dafür besteht hauptsächlich darin, dass Änderungen speziell von gitolite angelegte Hooks auslösen - beispielsweise, um einen neu hinzugefügten SSH-Key automatisch in die .ssh/authorized_keys zu installieren. You've been warned!

Konfiguration

Die Konfiguration von gitolite umfasst zwei Dinge: Einerseits das Hinzufügen und Entfernen von SSH-Keys; andererseits die Bearbeitung der Konfigurationsdatei, in der du angibst, welche Repos es gibt und welche Benutzer auf welche Repos lesend und schreibend Zugriff haben dürfen.

Praktischerweise befindet sich die Konfiguration selbst ebenfalls in einem Git-Repo - auf das standardmäßig nur du selbst Zugriff hast. (Das war der Grund, warum du deinen Key nochmal extra als Datei mit sprechendem Namen bereitstellen musstest: Erstens muss gitolite wissen, wie du heißt, und extrahiert das aus deinem Dateinamen; zweitens werden dem Inhaber jenes Schlüssel automatisch Rechte auf dem Repo gitolite-admin verliehen.)

Um nun Benutzer und Repos zu verwalten, solltest du das Repo gitolite-admin, das durch gl-setup automatisch angelegt wurde, auf deinen lokalen Rechner klonen. So geht's:

[someuser@somehost ~]$ git clone erna@eridanus.uberspace.de:gitolite-admin
Cloning into gitolite-admin...
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.

Du wirst nun in deinem lokalen Klon von gitolite-admin die Verzeichnisse conf und keydir vorfinden, mit einer Default-Konfiguration und deinem vorhin hochgeladenen SSH-Key. So sollte das aussehen:

[someuser@somehost ~]$ ls -l gitolite-admin/*
gitolite-admin/conf:
insgesamt 4
-rw-rw-r-- 1 someuser someuser 91 11. Apr 11:18 gitolite.conf

gitolite-admin/keydir:
insgesamt 4
-rw-rw-r-- 1 someuser someuser 604 11. Apr 11:18 erna.pub

Gleich noch einen Blick auf die Konfiguration werfen:

[someuser@somehost ~]$ cat gitolite-admin/conf/gitolite.conf 
repo    gitolite-admin
        RW+     =   erna

repo    testing
        RW+     =   @all

Was also ist zu tun?

Benutzer verwalten

Um einen Benutzer zu verwalten, brauchst du zwei Schritte:

  1. Du musst den SSH-Key des betreffenden Benutzers im Verzeichnis keydir ablegen. Verwende bitte auch hier einen „sprechenden“ Namen, damit du den Benutzer darüber referenzieren kannst. Die Datei muss die Endung .pub erhalten.
  2. Du musst in der conf/gitolite.conf eintragen, auf welche Repos der User Zugriff bekommen soll. Dabei kann zwischen Leserechten (R) und Schreibrechten (RW) unterschieden werden. Die Ergänzung RW+ ermöglicht dem User darüberhinaus, Rewinds durchzuführen, was normalen Usern in der Regel nicht gestattet sein dürfte.

Hast du die gewünschten Änderungen vorgenommen, gilt es, sie zu committen und zurück zu gitolite zu pushen. Verschaffen wir also exemplarisch dem Benutzer lisa Leserechte auf dem gitolite-admin-Repo. Die Hinterlegung des Schlüssels überlassen wir dabei deiner Phantasie. Bearbeite die conf/gitolite.conf mit einem Editor deiner Wahl, so dass sie so aussieht:

repo    gitolite-admin
        RW+     =   erna
        R       =   lisa

repo    testing
        RW+     =   @all

Nun committe die Änderungen:

[someuser@somehost gitolite-admin]$ git add conf keydir
[someuser@somehost gitolite-admin]$ git commit -m "provide lisa with read access"
[someuser@somehost gitolite-admin]$ git push

Fertig! Wenn du auf deinem Uberspace in der .ssh/authorized_keys nachschaust, wirst du sehen, dass dort nun Lisas SSH-Key hinterlegt ist. An der Angabe command=„…“ kannst du ersehen, dass sie aber keinen Shell-Zugang bekommen hat, sondern ausschließlich gitolite nutzen kann.

Wichtig für's Verständnis: Du bist nicht deshalb Admin der gitolite-Konfiguration, weil dir der Uberspace gehört, sondern deshalb, weil du via conf/gitolite.conf Schreibrechte im Repo gitolite-admin hast. Gibst du weiteren Usern darauf schreibenden Zugriff, so haben diese bezogen auf gitolite genau die gleichen Rechte wie du.

Wenn Lisa nun mittels git per SSH auf die auf deinem Uberspace gehosteten Repos zugreifen will, muss sie sich entsprechend mit deinem Usernamen am entsprechenden Uberspace-Host anmelden (denn es gibt ja nur diesen einen Systemuser für deinen Uberspace). gitolite wird dann anhand ihres SSH-Keys erkennen, dass ihr kein voller SSH-Zugang zur Verfügung steht, sondern nur ein eingeschränkter Zugang, mit dem sie ausschließlich mittels gitolite mit den für sie freigeschalteten Repos arbeiten kann.

Repos verwalten

Nichts leichter als das: Trage einfach ein neues Repo (mit den gewünschten Zugriffsrechten) in deine conf/gitolite.conf ein, committe und pushe die Änderung auf deinen Uberspace. gitolite wird dabei automatisch das Repo mit dem von dir gewählten Namen als leeres Bare-Repo anlegen.

Möchtest du bereits bestehende der Kontrolle von gitolite übergeben, findest du entsprechende Dokumentation im Abschnitt moving pre-existing repos into gitolite der Original-Dokumentation.

Logging

Die Historie eines mit Git verwalteten Repos lässt sich ja via git log jederzeit einsehen. gitolite führt darüberhinaus aber auch noch ein eigenes Logfile, in dem es ausführt, wer wann was durchgeführt hat. Das git clone … des gitolite-admin-Repos sowie das Pushen der Änderung (Lesezugriff für lisa) stellt sich beispielsweise so dar:

[erna@eridanus ~]$ cat ~/.gitolite/logs/gitolite-2011-04.log 
2011-04-11.11:18:27	erna	2001:470:1f0a:738::2	git-upload-pack 'gitolite-admin'
2011-04-11.11:58:29	erna	2001:470:1f0a:738::2	git-receive-pack 'gitolite-admin'
2011-04-11.11:58:29	erna	2001:470:1f0a:738::2	git-receive-pack 'gitolite-admin'	W	d981da1ef84ecc	4db66d05336005	gitolite-admin	refs/heads/master	refs/.*

Auf diese Weise sind Commits auch unabhängig von git log im gitolite-Logfile nachvollziehbar. Übrigens: Wenn du dich selbst per SSH-Shell einloggst, wird dieser Login ebenfalls hier geloggt - denn faktisch zwingt command=„…“ ja auch deinen eigenen Key zunächst zum Aufruf des gitolite-Wrappers gl-auth-command, der dir dann (aufgrund des vorhin via gl-tool shell-add … hinzugefügten Flags -s) eine echte Shell verschafft. Ermöglichst du mehreren Usern auf diesem Weg nicht nur gitolite-, sondern auch Shell-Zugang, kannst du damit also auch nachvollziehen, wer sich wann auf der Shell eingeloggt hat. (Eine Sicherheitsmaßnahme ist aber aber natürlich nicht; wer vollständigen Shell-Zugriff hat, kann schließlich auch das Logfile kompromittieren - Vertrauen ist hier also in jedem Fall gefragt, wenn du einem anderen User Shell-Zugang zu deinem Uberspace freischaltest.)

gitolite-Repos per HTTP veröffentlichen

Einer unserer User hat eine Dokumentation erstellt, wie sich gitolite-Repos per HTTP veröffentlichen lassen. Danke, Lucas!

Deinstallation

Du brauchst/willst Gitolite nicht mehr? Die installierten Dateien und Verzeichnisse sind übersichtlich:

  • ~/.gitolite.rc ist die primäre Konfigurationsdatei
  • in ~/.gitolite/ liegen die public keys, Logs etc.
  • in ~/repositories/ liegen die Git-Repositories

Willst du alles löschen? Dann tut's ein einfaches …

[erna@eridanus ~]$ rm -rf ~/.gitolite.rc ~/.gitolite ~/repositories

Anschließend solltest du noch deine ~/.ssh/authorized_keys überarbeiten - entferne einfach den mit # gitolite start und # gitolite end markierten Abschnitt, der dort von Gitolite eingefügt wurde. Solltest du mit gl-tool shell-add bzw. gl-tool add-shell-user gitolite-User zusätzlich auch für den Shell-Zugang freigeschaltet haben, solltest du diese Zeilen dann entweder ebenfalls entfernen (wenn den Usern der Zugriff per SSH entzogen werden soll) oder wenn die User SSH-Zugang behalten sollen, das command=… entfernen, so bis nur noch der Key selbst beginnend mit ssh-rsa oder ssh-dss in der jeweiligen Zeile steht. Fertig!

cool/gitolite.txt · Zuletzt geändert: 2016/09/13 11:50 von uber