Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

German

Git ist eine Software zur verteilten Versionsverwaltung von Dateien (engl. Distributed version control). Die Nutzung einer Versionsverwaltungssoftware macht es u.a. möglich, dass Änderungen an Dateien nachverfolgt werden können. Dies erleichtert die Zusammenarbeit mehrerer Personen an einem Projekt, da gleichzeitige Änderungen nicht zu Dateiüberschreibungen und damit zu Informationsverlusten führen, sondern mithilfe der Software zusammengeführt werden können. Versionsverwaltungssoftware wird häufig in der Softwareentwicklung eingesetzt, doch eignet sie sich beispielsweise auch zur Arbeit an wissenschaftlichen Texten wie Abschluss- und Doktorarbeiten, die mit der Textsatzsoftware LaTeX verfasst werden.

Mit GitLab bietet das LRZ einen web-basierten Dienst zur Verwaltung von Git-Repositories an. GitLab stellt neben den eigentlichen Repositories Werkzeuge wie Wikis und einen Issue-Tracker bereit. Mit "Merge Requests" gibt es ein Mittel, mit dem Code-Reviews kollaborativ und transparent durchgeführt werden können.

Im Folgenden finden Sie eine Übersicht über die wichtigsten Eckdaten. Weiterführende Informationen entnehmen Sie bitte den GitLab-FAQ.

Inhalt

Table of Contents
excludeInhalt

Aktuelles

05.08.2022

Ein Task zum Aufräumen alter unbenutzter Docker-Container aus der Container Registry wurde ausgeführt. Zwischen Do 4.8. um 16 Uhr und Fr 5.8. um 18 Uhr war damit zur Registry nur Lesezugriff möglich. Sonst konnte der Dienst normal benutzt werden.

04.08.2022

LRZ GitLab wurde zur Version 15.2 aktualisiert.

05.07.2022

LRZ GitLab wurde zur Version 15.1.1 aktualisiert.

09.06.2022

Die Betriebsysteme der GitLab-Server wurden aktualisiert und die neuesten Sicherheitsupdates der 14.10-Reihe installiert.

12.05.2022

LRZ GitLab wurde zur Version 14.10 aktualisiert.

08.04.2022

LRZ GitLab wurde zur Version 14.9 aktualisiert. Aufgrund einer Sicherheitslücke (die jetzt behoben ist, siehe GitLab Release Information) wurden an den GitLab-Konten verbundene interne Zufallspasswörter für alle von 3.2.2022 bis heute erstellten Kontos zurückgesetzt. Für das Einloggen erforderliche Passwörter in LDAP änderten sich nicht. Damit können alle betroffenen Nutzer:innen ganz normal einloggen und müssen nichts spezielles tun. Allerdings werden sie eine E-Mail über die Passwort-Änderung bekommen, die damit in diesem Fall ignoriert werden kann.

Es gibt keine Hinweise dass diese Sicherheitslücke ausgenutzt wurde, es handelt sich um eine Vorbeugemaßnahme.

10.03.2022

LRZ GitLab wurde zur Version 14.8 aktualisiert. Benutzer:innen, die CI-Runner verwenden, wird empfohlen, diese ebenfalls zu aktualisieren. Bitte beachten Sie:

  • Der Signaturschlüssel für GitLab und CI-Runner Linux-Pakete wurde am 2.3.2022 erneuert. Möglicherweise müssen Sie den neuen öffentlichen Schlüssel hinzufügen, bevor Sie die aktualisierten Pakete installieren.
  • Falls Sie einen automatisierten Prozess (Skripte, die den Wert des Registrierungstokens codieren) verwenden, um Ihre Runner zu registrieren, beachten Sie bitte die Informationen in dieser Sicherheitsrelease.
24.02.2022

Der GitInvited-Dienst wurde auf einem neuen Server migriert. Die Funktionalitäten für die Nutzer:innen haben sich bei der Migration nicht geändert.

10.02.2022

LRZ GitLab wurde zur neuesten Version der 14.7-Reihe aktualisiert.

03.02.2022

LRZ GitLab wurde zur Version 14.7 aktualisiert.

19.01.2022

Aktuell verfallen Job-Artefakte der CI/CD-Pipelines auf LRZ GitLab nie. Ab Mittwoch, 26.1.2022 beträgt die Standardablaufzeit 30 Tage (GitLab-Standardwert). Derzeit vorhandene Artefakte in bereits abgeschlossenen Jobs sind von der Änderung nicht betroffen. Die neuesten Artefakte für alle Jobs in den neuesten erfolgreichen Pipelines werden beibehalten (auch wenn sie älter als 30 Tage sind).

Weitere Informationen (in Englisch): https://gitlab.lrz.de/help/user/admin_area/settings/continuous_integration.html#default-artifacts-expiration 

14.01.2022LRZ GitLab wurde zur neuesten Version der 14.6-Reihe aktualisiert.
07.01.2022LRZ GitLab wurde zur Version 14.6 aktualisiert.

Nutzungsberechtigung

Zur Nutzung des LRZ-Dienstes GitLab berechtigt sind alle Mitglieder von TUM, LMU und sonstigen Münchner Hochschulen. Dazu ist eine LRZ-, TUM- oder LMU-Kennung nötig.

Sofern noch keine automatische Freischaltung erfolgt ist, können einzelne Benutzerkennungen vom verantwortlichen Master User über unser ID-Portal freigeschaltet werden. Falls dies nicht möglich ist, wenden Sie sich bitte an das LRZ Servicedesk.

Bitte beachten Sie, dass LRZ GitLab nur für nicht-kommerzielle Forschung und Lehre verwendet werden darf. Eine professionelle Nutzung in der IT-Abteilung und / oder die Verwendung für die institutionelle Verwaltung ist nicht erlaubt. Diese Begrenzung kommt aus der Bedingungen der GitLab for Education Programme. Detaillierte Information in Englisch finden Sie auf den folgenden GitLab-Seiten:

Sie brauchen sich nicht als Person oder Einrichtung in das Education Programm auf der GitLab-Seite zu registrieren. Das hat LRZ für die teilnehmende Universitäten bereits gemacht.

Speicherplatz

Da Git auf die Versionsverwaltung von Textdateien (Nur-Text-Format, Quellcode-Dateien etc.) ausgelegt ist, gilt generell, dass Git-Repositories relativ klein (< 1 GB) bleiben sollten

Für binäre Formate wie Bildarchive, Microsoft-Office-Dateien (.doc, .docx, .xls, .xlsx etc.), LibreOffice-/OpenOffice-Dateien (.odt, .ods etc.) oder sehr dynamische Daten wie Logs ist Git nicht gut geeignet. Für diesen Zweck unterstützt GitLab die Erweiterung Large File Storage (LFS). Wenn Sie binäre Dateien in ihrem Projekt haben, bitte von Anfang an LFS installieren und aktivieren. Eine spätere Migration der Dateien nach LFS ist deutlich komplizierter.

Im LRZ GitLab gelten die folgende Grenzwerte:

  • Maximale Dateigröße beim Upload: 2 GB
  • Maximale Größe des Repository inklusive LFS-Dateien: 10 GB

Die Größe des Repository ist als die Angabe "X MB Files" oben auf der Projektseite in GitLab zu finden. Die Angabe "Storage" zeigt die Gesamtgröße des Projekts inklusive der Artifacts, die den Grenzwert überschreiten dürfen. Bitte beachten Sie, dass die Werte gecached sind und daher möglicherweise nicht unmittelbar die tatsächliche Größe widerspiegeln, kurz nachdem Änderungen im Repository vorgenommen wurden.

Die maximale Größe des Repository kann bei Bedarf von den Administratoren für individuelle Projekte erhöht werden. Voraussetzung dafür ist eine ordnungsgemäße Nutzung von Git LFS. Bitte wenden Sie sich gegebenenfalls an den LRZ Servicedesk.

Um einen stabilen Betrieb sicherzustellen, werden wir im Januar 2021 ein Speicherplatzkontingent einführen. Neue Projekte können damit den Grenzwert nicht mehr überschreiten. Für bestehende größere Projekte, bei denen LFS ordnungsgemäß konfiguriert ist, werden wir automatisch ohne Rückfrage ein höheres Limit setzen. Eigentümer von zu großen Projekten ohne LFS werden kontaktiert und gebeten, ihre Repositories zu verkleinern. Eine Anleitung dafür ist in der GitLab-FAQ zu finden.

Projektlimit

Es dürfen höchstens 10 persönliche Projekte angelegt werden. Dieses Limit kann in begründeten Fällen angehoben werden. Bitte wenden Sie sich dazu an das LRZ Servicedesk. Als Alternative, bitte organisieren Sie Ihre Projekte in Gruppen (siehe unten).

Gruppen

Bei logisch zusammengehörigen Projekten bietet sich die Nutzung von GitLab-Gruppen an. Innerhalb einer GitLab-Gruppe ist die Projektanzahl nicht beschränkt. Eine Gruppe hat auch den Vorteil, dass die Rechteverwaltung für gewöhnlich erleichtert und übersichtlicher wird. Außerdem vererbt sich die Rolle eines Nutzers einer Gruppe zu allen Projekten in der Gruppe.

Sichtbarkeit der Projekte und Gruppen

In GitLab kann man bei Projekten und Gruppen die folgenden Stufen der Sichtbarkeit einstellen:

SichtbarkeitBedeutung / Auswirkung
Private 
  • Bei einem Projekt oder einer Gruppe muss man explizit festlegen, welche Nutzer:innen Zugriff haben. Die Rechte einer Person hängen von der GitLab-Rolle ab, die die Person bei dem Projekt oder der Gruppe besitzt. 
  • Bei einer Gruppe wird die Liste der berechtigten Personen (und ihre Rollen) auf die Projekte und Sub-Gruppen in der Gruppe vererbt.
  • Beim LRZ GitLab ist die Sichtbarkeit "Private" die Voreinstellung.
Internal
  • Wie bei "Private" kann man Rechte explizit vergeben.
  • (warning) Außerdem haben alle Nutzer:innen, die beim LRZ-GitLab eingeloggt sind, einen Lese-Zugriff:  Die eingeloggten Personen können die Projekte und Gruppen sehen und den Inhalt herunterladen. Davon sind nur diejenigen Personen ausgenommen, die mit GitInvited eingeladen wurden (weil sie den Status "external user" haben).
  • Als Eigentümer:in eines Projekts oder einer Gruppe kann man die Sichtbarkeit "Internal" selbst einstellen.
Public
  • Wie bei "Private" kann man Rechte explizit vergeben.
  • (warning) Außerdem haben beliebige Personen einen Lese-Zugriff (siehe "Internal").  Dazu muss man keine berechtigte Kennung besitzen und auch nicht eingeloggt sein.
  • Beim LRZ-GitLab kann nur das LRZ-GitLab-Team die Sichtbarkeit "Public" einstellen.  Wenn Sie Ihr Projekt veröffentlichen möchten, lesen Sie dazu bitte die Beschreibung im Abschnitt Öffentliche Projekte.

Alle Details zu den Stufen der Sichtbarkeit sowie zu den Rollen und Rechten finden Sie in den folgenden GitLab-Artikeln:  

Note
titleWichtige Sicherheitshinweise
  • Beim LRZ-GitLab können sich über 100.000 Personen einloggen! Dabei handelt es sich um alle Personen, die zur LMU, zur TUM und noch weiteren Münchner Hochschulen und wissenschaftlichen Einrichtungen gehören.
  • Bei einer so großen Anzahl von berechtigten Personen kann es vorkommen, dass eine oder mehrere Kennungen kompromittiert sind und unberechtigte Personen  (Kriminelle usw.) diese Kennungen nutzen. Diese unberechtigten Personen haben dann auch Lese-Zugriff auf alle Projekte und Gruppen mit der Sichtbarkeit "Internal".
  • Man kann von jedem Ort der Welt aus auf das LRZ-GitLab zugreifen.  Es gibt keine geographischen oder sonstigen Einschränkungen.

Fazit: Zu Ihrem eigenen Schutz sollten Sie die Sichtbarkeit "Internal" fast wie "Public" betrachten. 

Öffentliche Projekte

Es besteht die Möglichkeit, Projekte zu veröffentlichen, so dass sie ohne Login geklont werden können. Die benötigte Einstellung für das Projekt darf aus Sicherheitsgründen (s.u.) nur von den GitLab-Administratoren vorgenommen werden. Bitte geben Sie dazu den Projektnamen oder -pfad mit einer entsprechenden Nachricht an den LRZ Servicedesk weiter; bitte wählen Sie dabei die Methode "Selfservice", damit wir Ihre Berechtigung überprüfen können.

Wir empfehlen, alle öffentlichen Projekte in Gruppen einzuordnen, damit sie nicht von persönlichen GitLab-Kennungen abhängig sind. Wenn ein Projekt öffentlich sichtbar sein soll, dann muss auch die Gruppe, zu der das Projekt gehört, öffentlich sichtbar gemacht werden.

Bei öffentlichen Projekten sind die folgenden Informationen öffentlich sichtbar (allgemein zugreifbar):

  • Bei jedem Commit der Name und die E-Mail-Adresse, wie sie in der Konfiguration von Git hinterlegt wurden.
  • Bei GitLab der GitLab-Benutzername (Username), wie er bei den Benutzereinstellungen (User Settings) im Abschnitt "Konto" (Account) festgelegt wird. Der Benutzername ist bei persönlichen Projekten im Pfad sichtbar.

Bis Januar 2020 wurde beim ersten Anmelden der GitLab-Benutzername mit der eigenen Benutzerkennung initialisiert, die von der eigenen Einrichtung vergeben wird (LMU, TUM, HM, HSWT). Wir bitten alle betroffenen Mitglieder der öffentliche Projekte ihre GitLab-Benutzernamen zu ändern (Settings → Account → Change Username), so dass die eigene Benutzerkennung nicht allgemein sichtbar wird. Begründung:

  • Das LRZ muss die Benutzerkennung im Hinblick auf den Datenschutz vertraulich behandeln.
  • Die Benutzerkennung kann bei einem Social-Engineering-Angriff eingesetzt werden, um beim Opfer Vertrauen aufzubauen: <<Liebe Kundin, lieber Kunde mit der Kennung Abcxyz>>
  • Beim Angriff auf Passwörter gibt es mehrere Varianten. Beim "Online Attack Scenario" versucht der Angreifer, sich über den ganz normalen Zugang anzumelden. Dabei muss der Angreifer aber sowohl die Benutzerkennung als auch das dazugehörige Passwort kennen bzw. erraten.

Wenn Sie Ihren GitLab-Benutzernamen ändern, passt GitLab bei persönlichen Projekten die Web-Adressen und Repository-URLs automatisch entsprechend an. Bei Projekten, die zu einer Gruppe gehören, ändert sich nichts, weil in den betreffenden URLs kein Benutzername enthalten ist. Weitere Details zur Änderung des eigenen GitLab-Benutzernamens findet man in der GitLab-Dokumentation.

Continuous Integration / Continuous Delivery (CI/CD)

Die CI-/CD-Integration kann auf Projektebene aktiviert werden (Einstellungen/Settings → General → Permissions → Pipelines). Damit ist allerdings nur die Möglichkeit gegeben, die Kommunikation mit einem CI-Runner zu konfigurieren. Die CI-Runner selbst stellt das LRZ bis auf Weiteres nicht zur Verfügung. Sie müssen also selbst einen Runner aufsetzen und betreiben.

Mehr Information finden Sie in den folgenden Dokumenten:

GitLab Pages

Mit der GitLab-Pages-Funktionalität können statische Webseiten aus einem Repository erstellt und veröffentlicht werden. Alle Seiten der LRZ-GitLab-Pages liegen unter der Wildcard-Domain pages.gitlab.lrz.de. Alle Seiten von der LRZ-GitLab-Pages sind automatisch über eine sichere Verbindung (HTTPS) erreichbar.

Laut Standardeinstellung ist eine neue Pages-Seite nur mit Login und für Projekt-Mitglieder zugreifbar. Auf Wunsch kann die Seite allgemein öffentlich sichtbar gemacht werden (Settings → General → Pages access control → Everyone).

Die Benutzung der Pages-Funktionalität benötigt einen CI-Runner (siehe der Abschnitt CI/CD oben).

Die offizielle Dokumentation zu GitLab Pages stellt die Pages-Funktionalität ausführlich vor. Dort finden Sie u.a. eine detaillierte Beschreibung, wie die Adresse Ihrer Pages-Seite erstellt wird. (Bitte ersetzen Sie in den dort aufgeführten Beispielen die Domain example.io in gedanklich durch pages.gitlab.lrz.de.) Bitte beachten, dass für die Veröffentlichung der Seite muss der Inhalt in den Ordner public in ihrem Repository plaziert werden.

Die maximale Größe der Pages-Seiten ist aktuell 1 GB, kann aber in begründeten Fällen angehoben werden. Bitte wenden Sie sich dazu an das LRZ Servicedesk.

...

English

Git is a distributed version control system for software source code and other files. Using version management makes it possible to track changes made to files. It facilitates collaboration between multiple people on a project because concurrent changes cannot lead to accidental overwriting of files, hence preventing information loss. Changes made by multiple people can be merged using the Git software. Versioning of files is often used in software development, but it is also suitable for working on scientific texts such as graduation and doctoral theses that are often written using the LaTeX document preparation software.

With GitLab, LRZ offers a web-based service for managing Git repositories. In addition to the actual repositories where the files are stored, GitLab provides tools such as wikis and an issue tracker. With "Merge Requests", code reviews can be carried out collaboratively and transparently.

Below you will find an overview of the LRZ GitLab installation. Further information can be found in the GitLab-FAQ.

Table of Contents

Table of Contents
excludeTable of Contents

News

05.08.2022

A Container Registry cleanup task was executed to delete old unused Docker containers. Between Thu 4.8. at 4 pm and Fri 5.8. at 6 pm access to the registry was read-only. Other features of the GitLab service could be used normally.

04.08.2022

LRZ GitLab was upgraded to version 15.2.

05.07.2022

LRZ GitLab was upgraded to version 15.1.1.

09.06.2022

The operating systems of the LRZ GitLab Servers were upgraded and the most recent security patches of GitLab Version 14.10 installed.

12.05.2022

LRZ GitLab was upgraded to version 14.10.

08.04.2022

LRZ GitLab was upgraded to version 14.9. Related to a vulnerability (which is now fixed, see GitLab Release Information for more information) the internal randomized passwords were reset for all user accounts created after 3.2.2022 until today. The actual user passwords in LDAP were not changed. The affected users can log in normally and don't need to take any action. However, they will receive an E-Mail notification of the password change, which can in this case be ignored.

We have detected no evidence suggesting that this vulnerability would have been exploited. Resetting the passwords is a preventive measure. 

10.03.2022

LRZ GitLab was upgraded to version 14.8. Users who are operating CI runners are recommended to upgrade those as well. Please note:

  • The signing key for GitLab and CI-Runner Linux packages was renewed on 2.3.2022. You may need to add the new public key before installing the upgraded packages.
  • If you use an automated process (scripts that encode the value of the registration token) to register runners, please take account the information in this security release.
24.02.2022

The GitInvited service was moved to a new server. There is no change in the functionality from the user point of view.

10.02.2022

LRZ GitLab was upgraded to the most recent patchlevel of version 14.7.

03.02.2022

LRZ GitLab was upgraded to version 14.7.

19.01.2022

Currently job artifacts in CI/CD pipelines on LRZ GitLab never expire. Starting from Wed 26.1.2022 the default expiration time will be 30 days (GitLab default). Currently existing artifacts in already completed jobs will not be affected by the change. The latest artifacts for all jobs in the latest successful pipelines will be kept (also when they are older than 30 days).

More information: https://gitlab.lrz.de/help/user/admin_area/settings/continuous_integration.html#default-artifacts-expiration

14.01.2022LRZ GitLab was upgraded to the most recent patchlevel of version 14.6.
07.01.2022LRZ GitLab was upgraded to version 14.6.

Terms of service

All members of TUM, LMU and other Munich universities are entitled to use the LRZ GitLab service. This requires an LRZ, TUM or LMU user ID.

If no automatic activation has been made, individual user IDs can be activated by the responsible master user via our ID Portal. If this is not possible, please contact the LRZ Servicedesk.

Please note that LRZ GitLab can only be used for instructional-use or non-commercial academic research. IT professional use and/or use for institutional administration is not permitted under the educational license. Detailed information on the GitLab site:

You don't need to register as person or entity in the Education Program on the GitLab website. That has already been done by LRZ on behalf of the participating universities.

Storage space

Since Git is designed for versioning of text files (source code and other files in text format), Git repositories should remain relatively small (< 1 GB).

For binary formats such as image archives, Microsoft Office files (.doc, .docx, .xls, .xlsx etc.), LibreOffice / OpenOffice files (.odt, .ods etc.) or very dynamic data, GitLab supports the extension Large File Storage (LFS). If you have binary files in your project, please install and activate LFS from the beginning. A later migration of the files under LFS is much more complicated.

The limits in the LRZ GitLab are currently:

  • Maximum file size for upload: 2 GB
  • Maximum size of the repository including LFS files: 10 GB

The size of the repository can be found at the top of the project page in GitLab (value "X MB Files") . The value "Storage" shows the total size of the project including artifacts which are allowed to exceed the limit. Please note that the values are cached and may therefore not immediately reflect the actual size shortly after changes in the repository are made.

The maximum size of the repository can be increased by the administrators for individual projects if necessary. Proper use of Git LFS is a prerequisite for this. Please contact the LRZ Servicedesk.

In order to ensure stable operation, we will introduce an automatic storage space limitation (quota) in January 2021. New projects can thereafter no longer exceed the set limit. For existing larger projects where LFS is properly configured, we will automatically set a higher limit before enforcing the quota. Owners of oversized projects without LFS will be contacted and asked to reduce the size of their repositories. Instructions for this can be found in the GitLab-FAQ.

Project limit

10 personal projects may be created at most. This limit can be raised in justified cases. Please contact the LRZ Servicedesk. As an alternative, please organize your projects in groups (see below).

Groups

For logically related projects, the use of GitLab groups is recommended. Within a GitLab group, the number of projects is not limited. A group also has the advantage that rights management usually becomes easier and clearer. In addition, the role of a user of a group is inherited to all projects in the group.

Project and group visibility 

There are three levels of visibility for projects and groups in LRZ GitLab:

VisibilityMeaning / Impact
Private 
  • Access to the project or group must be granted explicitly to each user. The rights depend on the role which the person has in the project or the group. 
  • In case of a group, the list of authorized persons (and their roles) is inherited to all sub-groups and projects inside the group. 
  • In LRZ GitLab, the visibility "Private" is the default setting.
Internal
  • As with "Private", access rights can be granted explicitly.
  • (warning) In addition, all users who are logged in to the LRZ GitLab have read access: They can see the projects and groups and download the content. Only users who have been invited with GitInvited are excluded from this (due to their status "external user").
  • As a project or group owner you can set the visibility "Internal" yourself.
Public
  • As with "Private", access rights can be granted explicitly.
  • (warning) In addition, any person has read access (see "Internal"). They do not need to have a User ID and do not need to be logged in.
  • In LRZ GitLab only the LRZ-GitLab-Team can set the visibility "Public". If you want to publish your project, please read the description in the section Public projects.

Details about the levels of visibility as well as roles and rights can be found in the following GitLab articles: 

Note
titleWichtige Sicherheitshinweise
  • Over 100,000 people can log into the LRZ GitLab! This includes all persons who belong to the LMU, TUM and also some other Munich universities and scientific institutions.
  • With such a large number of authorized persons, it may happen that one or more user IDs are compromised and unauthorized persons (criminals, etc.) use these IDs. These unauthorized persons then also have read access to all projects and groups with the visibility "Internal".
  • LRZ GitLab can be accessed from anywhere in the world. There are no geographical or other restrictions.

Conclusion: For your own protection, consider the "Internal" visibility almost like "Public".

Public projects

It is possible to publish projects so that they can be cloned without logging in. The required setting for the project can only be made by the GitLab administrators. Please pass on the project name or path with a corresponding message to the LRZ Servicedesk and use the button "Selfservice" to make an authenticated request.

We recommend grouping all public projects into groups so that they are not dependent on personal GitLab identifiers. If a project is to be publicly visible, the group which the project belongs to must also be made public.

For public projects, the following information is publicly visible (generally accessible):

  • On every commit: The name and email address stored in the Git configuration
  • The GitLab username as defined in the User Settings in the Account section. For personal projects, the username is visible in the path of the project.

Until January 2020 the GitLab username was initialized at first login with the user's own user ID, which is assigned by their own institution (LMU, TUM, HM, HSWT). We ask all these members of public projects to change their GitLab username (Settings → Account → Change Username), so that the user ID will not become generally visible. Reasons in detail:

  • For privacy reasons, the LRZ must treat the user ID as confidential information.
  • The user ID can be used in a social engineering attack in order to build confidence in the victim: << Dear customer with the identifier Abcxyz >>
  • There are several variants of password attacks. In the "Online Attack" scenario the attacker attempts to gain access using the normal log procedure. However, the attacker must know or guess both the user ID and the associated password.

When the GitLab username is changed, GitLab automatically adjusts the web addresses and repository URLs of the user's personal projects accordingly. For projects that belong to a group, nothing changes because there is no username in those URLs. Further details on changing your own GitLab username can be found in the GitLab documentation.

Continuous Integration / Continuous Delivery (CI/CD)

The CI/CD integration can be activated at the project level (Settings → General → Permissions → Pipelines). However, you can only configure the communication with a CI runner. LRZ does not provide shared CI runners until further notice, which means you will have to set up and operate a CI runner yourself.

See the following GitLab documentation for more details:

GitLab Pages

The GitLab Pages feature makes it possible to create and publish static web pages directly from a repository. All LRZ GitLab Pages are served as subdomains under pages.gitlab.lrz.de. All LRZ GitLab Pages can be reached using a secure connection (HTTPS).

By default, a new GitLab Page is accessible only to project members who are logged in. However, the Page can also be made generally accessible (Settings → General → Pages access control → Everyone).

A CI runner is required for the Pages functionality (see the CI/CD section above).

The GitLab Pages documentation presents the Pages functionality in detail. There you will find for example a detailed description about how the address of your GitLab Page is formed. (The documentation uses example.io as an example domain which corresponds to pages.gitlab.lrz.de on the LRZ GitLab platform.) Please note that the contents of your Pages site must be placed in the directory public in your repository. 

The size of Pages sites is limited to 1 GB. This limit can be raised in justified cases. Please contact the LRZ Servicedesk.

...