© Liliya Filakhtova / 123RF.com

Nichts ist für die Ewigkeit, selbst ein Git-Server nicht. Nach dem Aufkauf von Github durch Microsoft haben viele Nutzer ihre Repos auf andere Server umgezogen. Ich betreibe einen ursprünglich auf Gogs basierenden privaten Git-Server. Nachdem das Projekt verwaist scheint, habe ich mir mit Gitea eine neue Heimstatt gesucht.

Wer sich mit Git beschäftigt, erkennt schnell den wahren Wert der Versionsverwaltung. Im Gegensatz zu Veteranen wie CVS oder Subversion ist Git keine Client-Server-Anwendung, sondern ein verteiltes System. Das bedeutet, dass kein Teilnehmer anderen gegenüber bevorzugt oder benachteiligt ist. Git erlaubt es jedem Repository, als Server zu agieren. Das wiederum erleichtert Umzüge: Man muss lediglich dafür sorgen, dass die Working Copies sämtliche Branches und Tags des Origins enthalten.

Origin bezeichnet im Git-Umfeld einen lokalen Alias auf ein ganz bestimmtes entferntes Repository. Er sorgt dafür, dass Sie nicht bei jeder Fetch-, Pull- oder Push-Operation die vollständige URL angeben müssen. Tatsächlich könnte ich den Alias ebenso per »git remote rename origin Ursprung« in »Ursprung« umbenennen. Viel schwerer als solche Namen wiegt im Rahmen eines Server-Umzugs, dass alle Daten des bisherigen Origins nur lokal vorliegen. So könnte es beim Löschen des bisherigen Servers vorkommen, dass beispielsweise Entwicklungs-Branches verlorengehen.

Vollständigkeit prüfen

Wenn Sie Ihre Repositories umziehen möchten, sollten Sie sie zuallererst vollständig lokal vorliegen haben. Dementsprechend kam ich nicht umhin, sämtliche nur remote vorhandenen Repos zunächst über den Befehl »git clone« lokal verfügbar zu machen. Sobald das erledigt war, konnte ich pro Repo die Branches und Tags prüfen. Für jedes einzelne Repository musste ich alle Branches und Tags lokal auf dem aktuellsten Stand haben. Dafür erleichterte ich mir mit einigen Git-Kommandos und ein wenig Shell-Skripting die Arbeit.

Listing 1 zeigt, wie Sie für ein Repository sämtliche Branches auschecken. Das Kommando »git branch -a« aus der ersten Zeile liefert die Namen sämtlicher Äste im Repo. Für die Migration interessieren mich vor allem die Branches, die eben noch nicht lokal vorliegen, daher filtere ich mit »grep« die Remote-Branches heraus. Daraufhin entferne ich die Zeile, die meine »HEAD«-Referenz markiert, also den aktuell aktiven Ast. Diese Referenz wird durch einen Pfeil »->« markiert.

for mybranch in $(git branch -a | grep -o -E '(remote.*)' | grep -v ' -> ' | cut -f3 -d'/')
do
  git checkout "${mybranch}"
  git pull
done

Die For-Schleife iteriert nun über die gefundenen Äste und führt den Befehl »git checkout« (Zeile 3) mit dem Namen aus, sodass der entsprechende Ast lokal verfügbar wird. Dieses Vorgehen wiederhole ich für sämtliche Tags (»git fetch –tags«).

In den Ausgaben 06/2023 [1] und 07/2023 [2] habe ich gezeigt, wie Sie mit einem Raspberry Pi und der Software Gogs einen eigenen Git-Server mit allerhand Features aufbauen. Allerdings tut sich mittlerweile kaum noch etwas im Gogs-Repository, Releases erscheinen lediglich halbjährlich und bringen zudem kaum Neuerungen. Das bringt mich zu der Annahme, dass die Software vermutlich nicht mehr lange überlebt.

Unglücklicherweise fiel mir der wenig gesunde Zustand von Gogs erst auf, als ich schon auf Versionen unterwegs war, für die es keinen einfachen Migrationspfad mehr zu Gitea gibt. Beide Projekte haben sich seit dem Fork bereits zu weit voneinander entfernt. Obendrein brauchte es auf meinem RasPi einen Release-Wechsel des Betriebssystems, denn inzwischen liegt Raspbian basierend auf Debian 12 vor.

Alles ist eine Datei

Getreu meinem Motto “ein fauler Admin ist ein guter Admin” oder “wenn du kannst, dann lass den Computer für dich arbeiten”, überlegte ich, wie eine Migration am einfachsten zu bewerkstelligen sei. Werfen wir zuerst einen Blick auf das Betriebssystem. Eine der größten Stärken freier Software, also auch von Linux, besteht für mich darin, dass praktisch alles, was das System ausmacht, als Datei vorliegt. Das mag zunächst trivial klingen, wird aber vermutlich klarer, wenn Sie überlegen, was im Rahmen eines Server-Umzugs alles zu tun ist.

Es beginnt mit der Git-Software, die sich allerdings ändern wird, dem Reverse Proxy, in meinem Fall Nginx, dem Mailserver Exim4 sowie diversen Shell-Skripten, Cron-Tabellen und so weiter. Systemweite Cron-Tabellen lege ich ausnahmslos im Verzeichnis »/etc/cron.d/« ab, systemweite Shell-Skripte unter »/usr/local/bin«, distributionsfremde Software ausschließlich unter »/opt/«. Damit lässt sich ein Backup aller relevanten Dateien auf diesem System mit einem Einzeiler wie dem aus Listing 2 bequem anlegen. Das so erzeugte Archiv enthält die erforderlichen Dateien, um auf der künftigen Hardware wieder dieselben Funktionen wie bisher bereitzustellen.

$ sudo tar -vzcf /home/thomas/githorst.tar.gz /etc/ /opt/ /usr/local/bin/

Im nächsten Schritt bespielte ich die SD-Card mit dem neuen Raspbian-Image, was sich mit Pi Imager ausgesprochen komfortabel gestaltet. Nach dem Booten des neuen Systems gilt es, Software zu installieren. Mit einem simplen »sudo apt install postgres exim4 nginx« brachte ich das flott hinter mich. Anschließend kopierte ich die notwendigen Konfigurationsdateien (Nginx, Exim4 und Gogs) nach »/etc/«.

Das Installieren von Gitea inklusive Setup eines Systemd-Services ging dank der guten Dokumentation [3] zügig von der Hand. Zu erreichen ist der Dienst über Port 3000. Da ich die Konfiguration meiner bestehenden Gogs- in die neue Gitea-Instanz weitestgehend übernehmen wollte, musste ich einige Anpassungen an der zentralen Konfigurationsdatei »app.ini« vornehmen. Hier erweist sich einmal mehr Vim als Allzweckwaffe, denn mit »vimdiff« ist es – Erfahrung mit Vim vorausgesetzt – ein Leichtes, entsprechende Unterschiede zwischen der ehemaligen und der jetzigen Konfigurationsdatei zu finden und sie nach Bedarf zu mergen.

Haben Sie die Konfiguration wunschgemäß umgesetzt, empfehle ich, eine Test-Mail zu versenden, um die Einstellungen des Mailservers zu prüfen. Dazu finden Sie in den Administratoreinstellungen (Abbildung 1) im Menü Konfiguration (Abbildung 2) die wichtigsten Server-Einstellungen und können unter Angabe einer E-Mail-Adresse eine Test-Mail verschicken (Abbildung 3)

Abbildung 1: Über das persönliche Menü erreichen Admins die Administratoreinstellungen.

Abbildung 2: Die wichtigsten Server-Einstellungen finden sich im Menü Konfiguration.

Abbildung 3: In der Mailer-Konfiguration lassen sich Test-Mails verschicken.

Generell kann ich Ihnen das Gitea Configuration Cheat Sheet [4] nur wärmstens ans Herz legen. Der Spickzettel enthält jede Einstellung und jedes Flag, das in der Datei »app.ini« vorkommen kann. Unbedingt empfehlen kann ich aber schon hier, das Logging anzupassen. Standardmäßig loggt Gitea offensichtlich ausschließlich auf die Konsole, was im Server-Betrieb wenig Sinn ergibt. Darum rate ich dazu, in der Log-Section entsprechende Einstellungen für das Logging in Dateien vorzunehmen (Listing 3).

[log]
#MODE = console
MODE              = file
LEVEL             = Warn
ROOT_PATH         = /opt/gitea/log
LOG_ROTATE        = true
DAILY_ROTATE      = true
MAX_DAYS          = 7
COMPRESS          = true
COMPRESSION_LEVEL = -2

Mit dem Zusammenführen der Einstellungen und dem erneuten Setup von Nginx als Reverse Proxy mithilfe der alten Konfiguration läuft nun eine saubere, leere Gitea-Instanz. Das ging tatsächlich sogar leichter von der Hand als ursprünglich gedacht.

Jetzt stand noch die eigentliche Migration an, also der Umzug der bestehenden Repositories auf den neuen Server. Mein Gitea-Server besitzt denselben FQDN wie das ehemalige Gogs. Doch nicht nur das: Gitea hat sogar dieselben Let’s-Encrypt-Zertifikate vorliegen. Das war genau der Plan, den ich beim Sichern des Originalsystems im Sinn hatte. Für einen gewöhnlichen Umzug eines Repos auf einen neuen Server gibt es bewährte Vorgehensweisen, auf die ich später eingehe. In meinem Fall bleiben alle Server-Settings gleich, nur, dass es dort bislang keine Repositories gibt.

Naiv war mein erster Ansatz eines schlichten »git push« – mehr als schiefgehen konnte es nicht. Tatsächlich lag ich damit gar nicht so falsch und erhielt eine sehr aufschlussreiche Fehlermeldung. Abbildung 4 zeigt die konkrete Meldung Gitea: Push to create is not enabled for organizations, die mich zur Gitea-Dokumentation führte. Ganz klar heißt es dort: “In the app.ini file, set ENABLE_PUSH_CREATE_USER to true and ENABLE_PUSH_CREATE_ORG to true if you want to allow users to create repositories in their own user account and in organizations they are a member of respectively. Restart Gitea for the changes to take effect. You can read more about these two options in the Configuration Cheat Sheet”. Voilà – genau die Information, die ich brauche.

Abbildung 4: Die Fehlermeldung bringt mich auf die richtige Spur und führt mich zur Dokumentation.

Ich aktivierte also in der Datei »app.ini« im Abschnitt »[repository]« die beiden Flags »ENABLE_PUSH_CREATE_USER = true« und »ENABLE_PUSH_CREATE_ORG = true«. Nach einem Neustart des Gitea-Services versuchte ich erneut mein Glück, diesmal mit Erfolg. Wie Abbildung 5 unschwer erkennen lässt, akzeptiert Gitea das Pushen inklusive Create sowohl für Benutzer-Repos als auch für Repos, die Organisationen gehören. Angesichts der Befürchtung, der Umzug könnte in ein wahres Großprojekt ausarten, bin ich doch sehr begeistert.

Abbildung 5: Nachdem ich die Konfiguration angepasst habe, funktioniert das Pushen inklusive Create wunschgemäß.

Klassische Migrationen

Die meisten Umzüge von Git-Repos dürften sich deutlich von meinem Sonderfall unterscheiden. Üblicherweise gilt es, von SERVER_1 auf SERVER_2 umzuziehen. Die konkreten Schritte dabei lesen Sie in Listing 4 nach.

In der ersten Zeile klone ich das Repository vom bisherigen Server nach »LOCAL_REPO«. Daraufhin wechsle ich in der zweiten Zeile in das Verzeichnis der neuen Working Copy »LOCAL_REPO«. Über »git branch -a« (Zeile 3) lasse ich mir alle Branches auflisten, um sie dann allesamt auszuchecken (Zeile 5). Zeile 6 sorgt dafür, dass sämtliche Tags des Repos in meiner Working Copy vorhanden sind.

Mit den Tags befinden sich jetzt alle Daten des Remote-Repositorys auf dem lokalen System. Das Kommando »git remote rm origin« in Zeile 9 kappt die Verbindung zum bisherigen Server, um daraufhin in Zeile 10 die URL des neuen Servers als Origin zu erhalten. Abschließend werden in Zeile 11 und Zeile 12 die Inhalte und Tags ins neue Heim gepusht.

git clone ORIGIN-URL LOCAL_REPO
cd LOCAL_REPO
git branch -a
for current_branch in $(git branch -a | grep -o -E '(remote.*)' | grep -v ' -> ' | cut -f3 -d'/') ; do
  git checkout "${current_branch}";
  git pull;
done
git fetch --tags
006 git remote rm origin
git remote add origin NEW_ORIGIN_URL
git push origin --all
git push --tags

Fazit

Mit geringem Risiko und überschaubarem Aufwand gelingt es, innerhalb einiger Stunden eine potenzielle Legacy-Software loszuwerden. Es mag durchaus sein, dass Gogs weiterlebt und irgendwann wieder an Dynamik zulegt. Darauf möchte ich mich allerdings nicht verlassen. Nicht zuletzt seit den Ereignissen um die XZ Utils und Systemd halte ich es für umso wichtiger, etwas so Grundlegendes wie Versionskontrolle nicht dem Zufall zu überlassen. Im Rahmen dieses Umzugs wurde mir einmal mehr bewusst, wie durchdacht und mächtig Git wirklich ist. Es scheint fast so, als hätte Linus Torvalds bei der Entwicklung all die Anwendungsfälle antizipiert. (csi)