Gitolite

• Gitolite hostet Git-Repositories auf einem zentralen Server und ermöglicht eine feingranulare Zugriffskontrolle pro Repository
• Bei der Installation über einen Paketmanager wird häufig der Name gitolite3 verwendet, und der Quellcode ist auf Codeberg und GitHub verfügbar
• Wer mit Unix und SSH vertraut ist, kann die Schnellinstallationsdokumentation nutzen; wer eine Schritt-für-Schritt-Anleitung braucht, folgt dem vollständigen Dokumentationsablauf oder der narrensicheren Installationsanleitung
• Installations- und Konfigurationsfehler sowie verlorene Schlüssel werden in der Dokumentation zu emergencies behandelt; Sicherheitsprobleme sollten direkt per E-Mail gemeldet werden, für allgemeinen Support gibt es eine Mailingliste
• Die Software wird unter GPL v2 vertrieben; für die separat gepflegte Dokumentation gilt grundsätzlich Creative Commons BY-NC-SA 3.0

---

Installations- und Betriebsdokumentation

• Gitolite richtet Git-Repositories auf einem zentralen Server ein und ermöglicht eine feingranulare Zugriffskontrolle
  • Als alternatives Quellcode-Repository kann auch GitHub genutzt werden
  • Der Paketname in Paketmanagern lautet häufig gitolite3
• Wenn du mit Unix und SSH vertraut bist, kannst du die Schnellinstallation nutzen
• Wenn du Schritt-für-Schritt-Unterstützung brauchst, folge der narrensicheren Installationsanleitung genau; für allgemeine Aufgaben nach der Installation helfen die Beispiele im cookbook
• emergencies behandelt Installations- und Konfigurationsprobleme, die Wiederherstellung verlorener Schlüssel, allgemeine oder seltene Fehler sowie nicht standardmäßige Konfigurationen, die problematisch sein können

Support-Kanäle und Lizenzen

• Sicherheitsprobleme sollten direkt an [e-mail] gemeldet werden
• Für allgemeinen Support und Diskussionen wird die Google-Groups-Mailingliste genutzt
  • Die erste E-Mail neuer Mitglieder wird zurückgehalten, bis sie freigegeben ist; weitere E-Mails von derselben Adresse werden jedoch nicht zurückgehalten
  • Zusätzlich gibt es eine separate, wenig frequentierte Einweg-Mailingliste für Releases und Sicherheitsankündigungen
• IRC-Support ist im Channel #gitolite auf libera.chat verfügbar; auch im Git-Channel #git gibt es Nutzer, die mit Gitolite vertraut sind
• Die Gitolite-Software wird unter GPL v2 vertrieben
  • Für die Dokumentation gilt grundsätzlich Creative Commons BY-NC-SA 3.0, externe Beiträge können jedoch pro Datei mit einer eigenen Lizenz gekennzeichnet sein
  • Codebeispiele in der Dokumentation und zugehörige Kommentare können als GPL v2 betrachtet werden, wenn sie nach Einschätzung nicht unter Fair Use fallen
• GIT ist eine Marke der Software Freedom Conservancy, und die Bezeichnung Gitolite wird gemäß der Lizenz verwendet

[GN⁺]

Meinungen auf Lobste.rs

• 2013 wurde an der Cambridge University ein Git-Server auf Basis von gitolite und gitweb aufgebaut. Die Wahl fiel darauf, weil der Verwaltungsaufwand deutlich geringer zu sein schien als bei frühem GitLab oder Gitorious, und in der Praxis war das im Großen und Ganzen auch so.
  gitolite hatte eine ungewöhnliche Struktur: Befehle wurden per SSH ausgeführt und Zugriffsrechte über ausgefeilte Konfigurationsdateien verwaltet. Weil es keine Web-Administrationskonsole gab, war die Einstiegshürde hoch. Es wurde eine Einführung erstellt, sie war aber nur für technisch versierte Nutzer geeignet.
  Da für den Git-Dienst keinerlei Personal eingeplant war, entstand in privater Zeit ein provisorischer Dienst, um Nachfrage nachzuweisen und Budget zu bekommen. Lokale Änderungen an Open-Source-Software in SVN abzulegen oder Git-Repositories in Home-Verzeichnissen zu haben, die niemand findet, war schwer akzeptabel. Im Verhältnis zum Bedarf an wissenschaftlicher Programmierung an der Universität gab es zu wenig Unterstützung für Software Engineering, und zentrale IT-Services sollten nicht nur intern genutzt werden, sondern Lehre und Forschung der ganzen Universität unterstützen.
  Mit der Funktion zur Delegation der Nutzerverwaltung wurden Kontenverwaltung und Support fast vollständig an Fachleute in den jeweiligen Forschungsgruppen oder Fachbereichen abgegeben. Gerade weil das Werkzeug sperrig war, zog es die beabsichtigten professionellen Early Adopters an; es gab recht viele Nutzer, aber kaum Support-Anfragen. Auch Projekte mit Beteiligten mehrerer Universitäten konnten unterstützt werden, weil der Zugriff nicht auf Cambridge-Mitglieder beschränkt wurde.
  Die größte Fehleinschätzung war, nicht zu erwarten, dass der provisorische Dienst rund 8 Jahre bestehen würde; später wurde er durch ein von dediziertem Personal betriebenes GitLab ersetzt. Am meisten Zeit kostete die Verbesserung der Resilienz, und die Architektur, Git-Repositories nahezu in Echtzeit an einen anderen Standort zu replizieren, war vermutlich komplexer als nötig.

  • Als dieser Dienst übernommen wurde, sollte er eigentlich auf eine Software Forge umziehen, die kontinuierliche Integration, Paket-Repositories und Ähnliches bietet. Da der Wert von Software als Forschungsergebnis allmählich anerkannt wurde, gab es auch eine Stimmung, Budget in einen zentralen Universitätsdienst zu stecken.
    Genau zu dieser Zeit übernahm Microsoft GitHub, und erstmals wurde der Niedergang von GitHub vorhergesagt; interessant, wie sich Geschichte wiederholt. GitLab bot eine Lizenz zu sehr günstigen Konditionen an, und intern brauchte man auch eine Demo, um Kubernetes und Infrastructure as Code auf Cloud-Services anzuwenden. Ich bin inzwischen nicht mehr an der Universität, aber GitLab läuft weiterhin unter https://gitlab.developers.cam.ac.uk/.
  • 2012–2013 wurde gitolite in einem Fachbereich einer regionalen Universität betrieben und vor allem von Studierenden des Software Engineering genutzt. Gemessen an der Nutzerzahl war es überdimensioniert, aber dank seiner Einfachheit und der fein granulierten Zugriffskontrolllisten eignete es sich gut, Teams und Berechtigungen für mehrere Projekte im Fachbereich zu verwalten.
    Einige Jahre später gab es niemanden mehr, der den Betrieb übernehmen konnte, und als GitHub stark in Mode kam, wanderten die Nutzer vom internen Universitätsdienst zu externem Hosting ab. Ich dachte, das Projekt sei verschwunden, daher ist es erfreulich zu sehen, dass es weiterhin gepflegt wird.

• Mit den fein granulierten Zugriffskontrolllisten von gitolite konnte man bestimmten Schlüsseln nur das Klonen erlauben und Pushes verbieten, oder Pushes erlauben, aber Force-Pushes untersagen. Es war leichtgewichtig und praktisch; heute würde ich wohl https://github.com/djmdjm/gitlimit ausprobieren.

  • Gitlimit wirkt vom Quellcode her einfach, sodass sich Funktionen wie benutzerdefinierte Befehle offenbar leicht erweitern lassen.

• Für persönliche Projekte eignet sich auch Fossil. Es bringt in einem kleinen Binary einen Webserver mit und lässt sich unkompliziert bereitstellen; bei Bedarf kann es auch mit einem übergeordneten Git-Repository zusammenarbeiten.

  • gitolite ist ein Werkzeug für viele Nutzer mit komplexer Zugriffskontrolle und zum Hosting mehrerer Repositories.

• Auch bei NRAO wurde gitolite eine Zeit lang als Übergangslösung eingesetzt. Das offiziell unterstützte Werkzeug war damals Subversion, aber der Gruppenleiter installierte es für interne Nutzer, die Git wollten. Es hatte nicht viele Funktionen, erledigte aber das Nötige ausreichend gut.
  Inzwischen gibt es eine GitLab-Installation, die vom gesamten Observatorium genutzt wird; ein Umzug zu GitHub oder GitLab ist ebenfalls möglich, aber die endgültige Entscheidung kenne ich nicht. Ich verbringe viel Zeit damit, Systeme für Continuous Integration und Deployment zu überarbeiten, und mir fällt keine Möglichkeit ein, das mit gitolite zu unterstützen oder Pull-/Merge-Request-Workflows umzusetzen. Vielleicht wird der Nutzen solcher Funktionen aber auch überschätzt.

• Ich nutze fugit (https://github.com/cbdevnet/fugit), das auf extreme Einfachheit ausgelegt ist, und verwalte die Konfigurationsdateien über ein Nix-Modul. Es ist simpel und effektiv; gitolite war immer etwas umständlich in der Nutzung.