Benutzer-Werkzeuge

Webseiten-Werkzeuge


software:gitolite

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu dieser Vergleichsansicht

Both sides previous revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
software:gitolite [2012/10/08 15:46]
mhoffmann Ubuntu Info
software:gitolite [2012/10/11 10:23] (aktuell)
Zeile 1: Zeile 1:
-====== Gitolite Versionsverwaltungsserver ​mit GIT ======+====== ​Installation ​Gitolite Versionsverwaltungsserver ======
 Gitolite ist ein Versionsverwaltungsserver der auf GIT basiert und eine denkbar einfache Konfiguration besitzt. Gitolite ist ein Versionsverwaltungsserver der auf GIT basiert und eine denkbar einfache Konfiguration besitzt.
 Da die komplette Konfiguration über ein eigenes GIT-Repository läuft benötigt man kein Webinterface und hat sogar eine Versionsverwaltete Konfiguration. Da die komplette Konfiguration über ein eigenes GIT-Repository läuft benötigt man kein Webinterface und hat sogar eine Versionsverwaltete Konfiguration.
Zeile 7: Zeile 7:
 // //
 Für die Installation von Gitolite braucht man folgendes: Für die Installation von Gitolite braucht man folgendes:
-  - Server mit konfiguriertem SSH-Zugang (am besten über den Standardport und mit PublicKey-Authentifizierung). +  - Server mit konfiguriertem ​[[software:​ssh|SSH]]-Zugang (am besten über den Standardport und mit PublicKey-Authentifizierung). 
-  - GIT-Client auf dem lokalen Rechner+  - [[software:​git|GIT-Client]] auf dem lokalen Rechner
     - Unter Linux einfach über den Paketmanager installieren     - Unter Linux einfach über den Paketmanager installieren
     - Bei MacOS über Portierungsprogramme wie "​Homebrew"​ oder "​Macports"​ installieren     - Bei MacOS über Portierungsprogramme wie "​Homebrew"​ oder "​Macports"​ installieren
-    - Unter Windows am besten GIT mit GitBash installieren.+    - Unter Windows am besten ​[[http://​msysgit.github.com/​|GIT mit GitBash]] installieren.
   - SSH PublicKey des eigenen Rechners im richtigen Format (Mit Putty-PublicKeys funktioniert das nicht)   - SSH PublicKey des eigenen Rechners im richtigen Format (Mit Putty-PublicKeys funktioniert das nicht)
   - Ein bisschen Ahnung wie GIT funktioniert.   - Ein bisschen Ahnung wie GIT funktioniert.
Zeile 17: Zeile 17:
 Zunächst solltet ihr den PublicKey auf den Server ziehen und dort irgendwo im Homeverzeichnis ablegen, ein Eintrag in die Datei **/​home/​[USER]/​.ssh/​authorized_keys** reicht nicht! Zunächst solltet ihr den PublicKey auf den Server ziehen und dort irgendwo im Homeverzeichnis ablegen, ein Eintrag in die Datei **/​home/​[USER]/​.ssh/​authorized_keys** reicht nicht!
 Wie ihr SSH-Keys erstellt hängt vom Client ab, meistens jedoch kann man die SSH-Keys über die Shell (Bei Linux und Mac) mit dem Befehl ''​ssh-keygen''​ erstellen. Wie ihr SSH-Keys erstellt hängt vom Client ab, meistens jedoch kann man die SSH-Keys über die Shell (Bei Linux und Mac) mit dem Befehl ''​ssh-keygen''​ erstellen.
- 
 ===== Gitolite Installation ===== ===== Gitolite Installation =====
 Gitolite kann einfach mit dem Befehl ​ Gitolite kann einfach mit dem Befehl ​
Zeile 54: Zeile 53:
 git clone ssh://​[Gitoliteuser]@adresse.des.servers:​[SSHPort]/​gitolite-admin.git git clone ssh://​[Gitoliteuser]@adresse.des.servers:​[SSHPort]/​gitolite-admin.git
 </​code>​ </​code>​
 +
 +Das Admin-Repository hat zwei Verzeichnisse die für bestimmte Zwecke verwendet werden:
 +  * keydir: Hier werden alle SSH-keys abgelegt, die für die Zugangskontrolle gebraucht werden
 +  * config: Dieses Verzeichnis besitzt nur die Datei **gitolite.conf** die für die Verwaltung genutzt wird.
 ==== Verwaltung Nutzer ==== ==== Verwaltung Nutzer ====
 +Die Zugangsverwaltung für gitolite erfolgt wie für GIT üblich mit SSH-keys.
 +
 +Pro Nutzer können beliebig viele SSH-Schlüssel für verschiedene Computer eingetragen werden.
 +Die SSH-PublicKeys der Nutzer werden im Verzeichnis "​keydir"​ abgelegt.
 +
 +Das Konzept ist denkbar einfach: Man nehme an, dass der Nutzer "​**hans**"​ zwei keys hat, einen für den **Desktop**,​ einen für den **Laptop**. Die beiden Schlüssel werden dann im keydir als **hans@desktop** und **hans@laptop** abgelegt. ​
 +
 +**Achtung:​** Der key **admin** darf unter keinen Umständen gelöscht werden! Der Nutzer, der das gitolite-admin Repository verwaltet muss immer als **admin** in den anderen Repositories eingetragen werden. Ein zusätzliche Upload des gleichen Schlüssels unter anderem Namen ist nicht möglich und führt zu Fehlern!
 ==== Verwaltung Repos ==== ==== Verwaltung Repos ====
 +Hat man die Nutzer wie oben beschrieben angelegt kann man sich an die Konfiguration der repositories machen.
 +
 +Die Struktur des Konfigurationsfiles ist denkbar einfach und wird am Beispiel erklärt:
 +<​code> ​
 +#file gitolite.conf
 +
 +@projects projekt1 projekt 2         #1
 +@developers hans juergen ​            #2
 +
 +repo    gitolite-admin ​              #3
 +        RW+     ​= ​ admin       #4
 +
 +repo    testing ​                     #5
 +        RW+     ​= ​  ​@all ​            #6
 +
 +repo hans_pub ​                    #7
 + RW+ = hans ​        #8
 +        R       ​= ​      ​juergen ​     #9
 +
 +repo projects  ​            #10
 + RW+ = developers ​  #11
 +</​code>​
 +
 +Gitolite unterstützt Gruppen die entweder Nutzer oder Repositories zusammenfassen. Der Syntax ist der gleiche und erst bei der Nutzung in der Konfiguration zeigen sich die Unterschiede.
 +
 +  * Zeile 1 definiert eine Repository-Gruppe "​projects"​ mit den Repositories "​projekt1"​ und "​projekt2"​
 +  * Zeile 2 definiert eine Nutzer-Gruppe mit den Nutzern "​hans"​ und "​juergen"​
 +
 +Das Admin repository wird in den Zeilen #3 und #4 konfiguriert. Hier ist Vorsicht geboten, da man sich sonst schnell aussperrt! Zeile #5 und #6 definieren das von gitolite angelegt test-repo
 +
 +Danach erfolgt die Definition der Repositories:​
 +  * Zeile #7 - #9 definieren das repository "​hans_pub"​ in dem hans lesen und schreiben darf, juergen aber nur lesen darf.
 +  * Zeile #10 - #11 definieren die Repositorygruppe "​projects"​. Hierbei hat die Gruppe "​developers"​ vollen Zugriff.
 +
 +Die drei unterschiedlichen Lese- und Schreibrechte sind:
 +  - **R**: Nutzer darf nur lesen
 +  - **RW**: Nutzer darf lesen und schreiben
 +  - **RW+**: Nutzer darf lesen und schreiben und den Befehl ''​git push -f''​ nutzen.
 +
 +
 +
 +
 ==== Upload Config ==== ==== Upload Config ====
 +Hat man die Konfiguration angepasst und abgespeichert muss man sie committen und pushen:
 +
 +  - Mit ''​git status''​ pruefen ob alle keys vorhanden sind und die config geändert wurde. Hier sollte man auch prüfen ob nicht eventuell das Dateisystem unbeobachtet Dateien angelegt hat (bspw. Indexdateien),​ die man ignorieren sollte.
 +  - Mit ''​git add .''​ all Änderungen in den Index übernehmen
 +  - Mit ''​git commit -m [Nachricht]''​ die Änderungen versionieren
 +  - Mit ''​git push''​ die Änderungen auf den Server pushen
 +
 +Alle Änderungen werden sofort von Gitolite übernommen,​ neue Repositories und User werden angelegt.
 +
 +Neue Repositories kann man dann mit entsprechenden Nutzerrechten mit einem der beiden folgenden Befehle klonen:
 +<​code>​
 +git clone [Gitoliteuser]@adresse.des.servers:​[NameDesRepos].git ​ #für SSH auf Port 22
 +
 +git clone ssh://​[Gitoliteuser]@adresse.des.servers:​[SSHPort]/​[NameDesrepos].git ​ #SSH auf anderem Port
 +</​code>​
 +==== Löschen von Repositories ====
 +
 +Löscht man ein Repository oder einen Nutzer werden diese zwar gesperrt, verbleiben aber physikalisch auf dem Server! Dazu muss man im Verzeichnis der Gitolite Repositories manuell das Repository löschen.
  
 {{tag>​git versionsverwaltung}} {{tag>​git versionsverwaltung}}

Bei Verwendung dieses Wikis erklären Sie sich mit dem Haftungsausschluss, Nutzungsbedingungen und der Datenschutzerklärung dieses Wikis einverstanden. Impressum.

software/gitolite.1349703981.txt.gz · Zuletzt geändert: 2012/10/11 10:23 (Externe Bearbeitung)