GIT Server
Die IRB stellt für Studenten und Mitarbeiter einen Git(lab) Server zur Verfügung.
Die Verwaltung und Konfiguration von Repositories findet über die Weboberfläche des GIT-Server statt und kann von Mitarbeitern und Studenten selbst durchgeführt werden. Dazu kann man sich mit dem ZIM-Login auf der Weboberfläche einloggen. Dort können dann neue Repositories erstellt und weitere Mitglieder hinzugefügt werden, sowie Repositories konfiguriert werden.
Wichtiger Hinweis: Um einem Benutzer Zugriff auf ein Repository geben zu können, muss sich dieser bereits einmal auf der Weboberfläche des Git-Servers eingeloggt haben.
Wichtiger Hinweis: Aus technischen Gründen empfehlen unseren dedizierten Wiki Servers an Stelle von den in Gitlab eingebauten Wikis.
Zugriffs Informationen
Auf ein Repository kann über die folgenden Methoden von innerhalb und außerhalb der Uni zugegriffen werden. Die genauen URIs werden auch auf der Übersichtsseite Ihres Repositories angezeigt.
SSH: 'ssh://irb-git@git.cs.upb.de:2222/<benutzer>/<repo-name>.git'
Um SSH zu verwenden (was stark empfohlen ist) müssen sie den eigenen SSH-Public-Key in den Profileinstellungen auf GIT-Server hinterlegen. Bei der Verwendung wird dann nur das Passwort Ihres lokalen SSH-Private-Keys benötigt, sofern dieser passwortgeschützt ist (was auch empfohlen wird).
HTTPS: 'https:// git.cs.upb.de/<benutzer>/<repo-name>.git'
Für den HTTPS Zugriff werden nur die ZIM Zugangsdaten benötigt, welche aber bei jedem Zugriff eingegeben werden müssen.
Weiteren Benutzern können Sie den Zugriff auf Ihr Repository selbst in den Einstellungen dessen erlauben. Diese müssen sich vorher aber schon einam am Git server eingeloggt haben, damit die nötigen Daten hinterlegt sind.
Zugang zum GitLab Server für Uni-externe Projektpartner ist möglich. Bitte beantragen sie einen Gast Account beim ZIM für jede Person die Zugriff haben soll.
Die Beantragung eines ZIM Gast Accounts ist im ZIM Wiki Dokumentiert. Sie müssen dann ggf noch die "IT-Dienste der Informatik" für jeden Gast Account freischalten, was hier dokumentiert ist.
Auch solche Gast Accounts müssen sich einmalig am Git Server anmelden bevor sie zu Projekten hinzugefügt werden können.
Serverweite Änderungen
Zeitpunkt der Ankündigung: 8. Mai 2024
Zeitpunkt der Umstellung: 22. Juni 2024
Kontext
Nach Rücksprache mit dem Firewall-Team des IMT und Blick auf die Sicherheitsrichtlinien des Bundesamtes für Sicherheit in der Informationstechnik (BSI) werden wir zukünftig den Zugriff auf Git-Repositories per SSH nicht über den Standardport 22 anbieten können. Stattdessen werden wir aber den Zugriff über Port 2222 ermöglichen.
Was ist zu tun
Das bedeutet für euch, dass ihr auf allen Endgeräten auf denen ihr ein Repository geklont habt die URL bzw. den Port anpassen müsst. In der Kommandozeile könnt ihr dies mit `git remote set-url origin` (Dokumentation) tun. Mit `git remote get-url origin` (Dokumentation) könnt ihr euch eure aktuelle URL anzeigen lassen.
Ihr müsst dann eure aktuelle URL anpassen. Ganz zu Anfang müsst ihr ein 'ssh://' hinzufügen und nach dem 'git.cs.uni-paderborn.de:' muss '2222/' ergänzt werden.
Beispielhaft:
alt: irb-git@git.cs.uni-paderborn.de:nutzername/repository.git
neu: ssh://irb-git@git.cs.uni-paderborn.de:2222/nutzername/repository.git
Wann ist zu handeln
Seit der Ankündigung per Mail am 8. Mai sind sowohl der Port 22 als auch der Port 2222 aktiv und nehmen Verbindungen entgegen. Ab dem 22. Juni wird nur noch der Port 2222 zur Verfügung stehen.
Aktualisiert eure git URLs daher sobald wie möglich.
Zeitpunkt der Ankündigung: 13. Mai 2025
Zeitpunkt der Umstellung: 22. Mai 2025
Kontext
Aktuell benutzen wir einen RSA-Schlüssel mit einer Länge von 2048 bits. Bei Schlüsseln mit dieser Länge sind Angriffe potenziell möglich, weshalb wir die Länge erhöhen auf 4096 bits. Dieser Prozess resultiert in einer anderen Schlüsselsignatur, welche von Geräten, die sich bereits einmal mit dem Server über SSH verbunden hatten, bemerkt wird und in der Verweigerung des Verbindungsaufbaus resultiert. Dies ist der Fall, da die nutzerseitige Anwendung sich die Signatur jedes Servers merkt und bei jedem erneuten Verbindungsaufbau auf Korrektheit prüft.
Je nach System und Einstellungen kann auch keine Warnung angezeigt werden, da der Server zwei Arten von Host-Schlüsseln nutzt, sowohl RSA als auch Ed25519. Moderne Systeme präferieren oft letzteren, weshalb eine Rotation des RSA-Schlüssels womöglich nicht einmal auffällt.
Was ist zu tun
Sollte ab dem Stichtag des 22. Mai eine Warnung über Änderung der Signatur angezeigt werden, so gilt es die neue Signatur zu überprüfen. Angezeigt werden sollte exakt folgende RSA Signatur:
SHA256:hGMKxHiX9ruS7EkelZuaC0kzPXbyuIjuptJ4RQLxAeA
Es ist außerdem möglich, dass ihr Gerät einen anderen Schlüssel anzeigt. Der Server nutzt zudem die folgende, ebenfalls valide Ed25519 Signatur (unverändert):
SHA256:6EIQkoN4YmmWoqzonvl6ra4Onsu61vLZGUuSLcf0h0U
Sollte Ihr angezeigter Schlüssel anders aussehen, prüfen Sie bitte Folgendes:
- Sie nutzen den Git-Sever der Informatik unter git.cs.uni-paderborn.de
- Sie nutzen Port 2222 bzw. die Klon-URL enthält :2222 nach dem Severnamen
- Das Datum vom 22. Mai 2025 liegt in der Vergangenheit
Abhängig von der genutzten Software kann das Akzeptieren des neuen Schlüssels anders ablaufen. Auf Systemen mit der Git-CLI kann der alte Schlüssel mittels folgendem Kommando entfernt werden:
ssh-keygen -R “[git.cs.uni-paderborn.de]:2222”.
Wann ist zu handeln
Frühstens ab dem 22. Mai.
Die Umstellung findet im Laufe des Tages statt. Nach erfolgreicher Umstellung wird eine Serverweite Anmerkung auf https://git.cs.upb.de geschaltet.
Zeitpunkt der Ankündigung: 06. April 2026
Zeitpunkt der Umstellung: 13. April 2026
Kontext
Der IRB betreibt für den Git-Server der Informatik Instanz-weite CI Runner unter dem "shared"-Tag für die Nutzung von GitLab Pipelines. Jeder ausgeführte Auftrag bzw. Job wird von einer temporären virtuellen Maschine (VM) ausgeführt. Die vorinstallierte Docker-Version auf dieser VM ist aktuell nicht mehr mit der neusten Version von Docker (29) kompatibel, sodass Jobs, die Docker-Images erzeugen, bislang manuell auf eine ältere Version zurückgreifen mussten.
Mit dieser Umstellung aktualisieren wir das Basissystem der VMs. Damit wird ebenfalls die Docker Version auf die neuste Version angehoben, sodass keine manuellen Anpassungen mehr erforderlich sind.
Zudem bieten wir unter dem "shared-legacy"-Tag die vorherige Konfiguration weiterhin für einen begrenzten Zeitraum an, sodass Pipelines, welche von der Umstellung beeinträchtigt sind, auch ohne Anpassung weiterhin genutzt werden können.
Was ist zu tun?
In den meisten Fällen ist kein Einschreiten erforderlich. Pipelines, welche keine Docker-Builds durchführen, sollten nicht betroffen sein.
Pipelines, welche Docker-Builds auf den shared Runnern des IRB durchführen, benötigen eine Anpassung.
Durch die Umstellung auf Docker 29 auf den Runnern wird nun mindestens die Docker API-Version v1.44 (Docker v25) erforderlich.
Wenn Sie in Ihren Pipelines manuell die "DOCKER_API_VERSION" herabgesetzt haben, so muss ab dem 13.04 mindestens die Version 1.44 angezielt werden.
Zudem sollten Sie sichergehen, dass Sie in Ihrer Pipeline mindestens Docker in der Version 25 einsetzten. Ältere Version von Docker können nicht die API-version 1.44 erreichen.
Wie kann ich mich vorbereiten?
Runner mit dem Tag "shared-dev" laufen derzeit schon mit der neuen Konfiguration. Diese Runner sind nicht für einen längerfristigen Einsatz gedacht und sollten nur Testweise eingesetzt werden, bis am 13.04. die regulären Runner umgestellt werden.
Wir empfehlen Ihnen, sofern Sie von Docker-Builds Gebrauch machen, Ihre Pipeline in einem separaten Branch auf die Runner des Tags "shared-dev" umzustellen, und ggf. das Image Ihrer Build-Jobs auf `docker:29-cli` festzulegen. Sollten
Ich benötige mehr Zeit für die Umstellung
Wir werden die bislang genutzte Konfiguration weiterhin bereitstellen, um die Umstellung zu vereinfachen.
Sollten Ihre Pipelines nach dem 13.04. nicht mehr funktionieren, so können die von dem Tag "shared" auf "shared-legacy" Umstellen. Wir planen diese Möglichkeit für die Dauer des aktuellen Sommersemesters anzubieten.
Ich nutze eigene Runner (self-hosted)
Sie nicht von der Umstellung betroffen.