Willemers Informatik Ecke: GitLab

Weitere Git-Themen:

GitLab bietet eine Benutzerverwaltung für Git mit integrierter Web-Oberfläche. Diese wiederum integriert eine Issues-Verwaltung und ein Wiki. Es können Repositories mit verschiedenen Öffentlichkeitseigenschaften versehen werden. Benutzer werden zu Gruppen zusammengefasst und erhalten verschiedene Rollen für die Repositories.

Vorbereitungen der Installation

Das Paket GitLab befindet sich nicht in den Linux-Distributionen, sondern muss als Fremdpaketquelle eingebunden werden. Die Installation erfolgte auf Basis eines Debian-Systems. Bei Ubuntu wird es feine Unterschiede geben.

Postfix und andere Pakete

Debian verwendet standardmäßíg Exim als Mail-System. Für GitLab wird allerdings Postfix eingesetzt. Darum sollte vor einer Installation von GitLab Postfix installiert. Wo man gerade dabei ist, werden auch noch ein paar andere Pakete installiert, die später gebraucht werden.

apt-get install curl openssh-server ca-certificates postfix

Während der Installation von Postfix wird einmal nach dem E-Mail-Namen gefragt. Hier wird gitlab eingegeben, ggf. gefolgt von dem Namen der Domain (DNS) des Rechners.

Darüber hinaus wird gefragt, in welcher Konfiguration Postfix arbeitet. Hier wurde Internet mit Smarthost angegeben.

Postfix-Konfiguration mit GMX-Konto

Natürlich wäre es am elegantesten, GitLab in das Mail-System der Domain einzubinden. Wenn es ein solches aber nicht gibt oder der Zugriff darauf nicht so einfach ist, tut es auch ein normales GMX-Konto.

Die Konfiguration erfolgt in der Datei /etc/postfix/main.cf. Darin werden folgende Einstellungen angepasst:

mydestination =

relayhost = mail.gmx.net:587

smtp_sasl_auth_enable = yes

smtp_sasl_password_maps = hash:/etc/postfix/sasl_password

Die Datei muss angelegt werden. Darin werden die Zugangsdaten für das Smarthost-E-Mail-Konto abgelegt. Der erste Begriff muss mit dem relayhost übereinstimmen. Es folgt Benutzer (bei GMX identisch zur kompletten E-Mail-Adresse), Doppelpunkt und Passwort

mail.gmx.net gitlabadresse@gmx.de:geheimespasswort

Nach jeder Änderung muss die Datei in eine db-Datei geändert werden:

postmap sasl_password

smtp_sasl_security_options = noanonymous

smtp_tls_security_level = encrypt

sender_canonical_maps = hash:/etc/postfix/sender_canonical

In der neuen Datei sender_canonical wird die Absende-Adresse umgebogen, da GMX nur Mails mit dem Absender der eigenen E-Mail-Adresse für den Versand akzeptiert, um Spam zu verhindern. Hier muss der Benutzer gitlab eingetragen werden, da dieser von GitLab als Absender für die Kontakte zu den Benutzern verwendet wird. Übrigens gibt es in der /etc/password keinen Eintrag für einen Benutzer gitlab.

gitlab gitlabadresse@gmx.de
linux gitlabadresse@gmx.de

Der zweite Eintrag ist nur für den Benutzer linux, der im Anschluss zum Testen der Postfix-Konfiguration benutzt wird.

Nach jeder Änderung muss die Datei in eine db-Datei geändert werden:

postmap sender_canonical

Nun muss Postfix die Konfiguration neu laden.

postfix reload

Test der Postfix-Umgebung

Für den Test wird ein Benutzer linux angelegt. Dieser sendet eine Testmail an eine Internet-Adresse.

su - linux
mail irgendeineadresse@web.de
Subject: testvongitlab
huhu
.
Cc:

Die Mail sollte nun beim Empfänger ankommen. Absender ist gitlabadresse@gmx.de. Sollte das nicht funktionieren, gibt die Datei /var/log/mail.log die Fehlermeldungen, die weiterhelfen. Meist ist das GMX-Konto mit dem Absender unzufrieden. Das muss dann in der Datei sender_canonical nachjustiert werden.

Installation über Fremdquelle

Die Seite www.gitlab.com bietet einen Skript an, der die Erweiterung der Paketquellen am Debian-System durchführt.

wget https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
chmod 775 script.deb.sh
./script.deb.sh

Alternativ kann aich in folgenden Schritten vorgegangen werden:

Die Zeilen

deb https://packages.gitlab.com/gitlab/gitlab-ce/debian stretch main
deb-src https://packages.gitlab.com/gitlab/gitlab-ce/debian stretch main

in der Datei /etc/apt/sources.list eintragen oder eine neue Datei mit diesen Zeilen im Verzeichnis /etc/apt/sources.d anlegen.

Den folgenden Befehl als root ausführen:

wget -qO - https://packages.gitlab.com/gpg.key | apt-key add -

Die Paketliste aktualisieren:
```
apt-get update
```

So verwendet Debian auch gitlab.com als Paketquelle. Nun kann GitLab über die üblichen Linux-Installationswerkzeuge geladen werden.

apt-get install gitlab-ce
gitlab-ctl reconfigure

Hostname

GitLab verwendet für die URLs, die es ausgibt, den Hostnamen des Rechners, auf dem es installiert ist. Da die URLs typischerweise von außen angesprochen werden, muss der interne Hostname auch im Netzwerk bekannt sein. Dazu muss dieser Namen entweder im lokalen DNS eingetragen sein oder von jedem Benutzer in der Host-Datei hinterlegt werden. Diese befindet sich bei Linux in /etc/hosts und bei Windows in C:/Windows/System32/drivers/etc/hosts.

Erstanmeldung des Administrators

Nun muss das Passwort für den GitLab-Administrator gesetzt werden. Dazu wird der Browser verwendet. In die Adresszeile wird der Name oder die IP-Adresse des PCs verwendet, auf dem GitLab installiert ist.

GitLab fragt sofort nach einem Passwort und lässt sich dieses bestätigen. Es muss mindestens acht Buchstaben umfassen. Direkt anschließend folgt eine Anmeldemaske, in der man als Benutzer root und als Passwort das eben definierte Passwort einträgt.

Mit diesem Administratorzugang kann man beliebige Benutzer anlegen, die selbst auch wieder Administratorrechte bekommen können.

Benutzer anlegen

Ein Administrator kann einen Benutzer anlegen. Dazu wird ein Benutzername und eine gültige E-Mail-Adresse benötigt.

Dem neuen Benutzer können verschiedene Rechte zugeordnet werden:

Der neue Benutzer kann Administrator werden.
Er kann das Recht bekommen, Gruppen anzulegen.
Es wird festgelegt, wie viele Projekte (Repositories) er anlegen darf.

Der neue Benutzer erhält eine Mail mit einer URL, über die er die Anmeldung vervollständigt. Er wird dann aufgefordert, ein Passwort anzugeben und dieses zu bestätigt.

Der neue Benutzer wird immer wieder aufgefordert, seinen SSH-Key anzugeben. Er kann das Eingabefeld für den SSH-Key auch in seinen Profile Settings festlegen, die er über das Menü neben seinem Avatar rechts oben findet. Der SSH-Key ermöglicht den Umgang mit GitLab ohne Passwort. Dazu öffnet der Benutzer die Datei id_rsa.pub im Verzeichnis .ssh und kopiert den Inhalt per Copy & Paste (Strg-C / Strg-V) in das Eingabefeld im Browser.

Einen SSH-Key erzeugt der Benutzer über den Befehl ssh-keygen aus der Shell bzw. Git-Shell.

Gruppen

Über das Menü mit den drei Streifen auf der linken Seite kann jeder Benutzer, dem dieses Recht zugeteilt wurde, eine Gruppe anlegen. Dazu wählt er den Menüpunkt Groups an und klickt dann auf den Button New Group.

Einer Gruppe können existierende Benutzer zugewiesen werden.
Ein Projekt kann eine Gruppe als Besitzer erhalten. Dadurch wird der Gruppenname zum Bestandteil der URL.
Eine Gruppe kann die gleichen Rollen (Guest bis Owner) für ein Projekt übernehmen wie Benutzer.

Projekt (Repository)

Direkt nach dem Anmelden erhält der Benutzer die Möglichkeit, ein neues Repository (Projekt) über den Button New Project anzulegen. Das Projekt bekommt einen Namen und eine Beschreibung (Project description). Mit der Angabe der Sichtbarkeit (Visibility Level) kann der Anleger den Zugriff begrenzen:

Private: Der Zugriff auf das Projekt muss anderen Benutzern explizit vom Besitzer zugewiesen werden.
Internal: Jeder im GitLab angemeldete Benutzer darf das Projekt clonen.
Public: Um einen Clone auf das Projekt zu erzeugen, reicht die Kenntnis der URL. Man muss nicht in GitLab angemeldet sein.

Dem Projekt können Gruppen und Benutzer zugewiesen werden, die verschiedene Rollen für das Projekt übernehmen.

Guest: Er kann die Issues und das Wiki zum Projekt lesen und darf Kommentare hinterlassen, kommt aber nicht an den Code heran.
Reporter: Er kann den Code des Projekts einsehen und die Commit-Kommentare lesen, kann aber am Projekt nichts verändern.
Developer: Er darf einen Push auf den Branch des Projekts setzen, sofern dieser nicht protected ist. Da der Branch master bei GitLab zunächst protected ist, muss der Master oder der Owner einen neuen Branch für die Bearbeitung der Developer anlegen.
Master: Er darf auch einen protected Branch per Push verändern oder einen neuen Branch von einem protected Branch erzeugen. Er ist auch dafür zuständig, einen fertigen Branch mit dem master per merge zu vereinen.
Owner: Er darf mit dem Projekt machen, was er will. Es ist seines.

GitLab

Vorbereitungen der Installation

Postfix und andere Pakete

Postfix-Konfiguration mit GMX-Konto

Test der Postfix-Umgebung

Installation über Fremdquelle

Hostname

Erstanmeldung des Administrators

Benutzer anlegen

Gruppen

Projekt (Repository)

Branch anlegen

Datensicherung

Sicherung der GitLab-Version selbst

Sicherung der Daten

Wiederherstellung der Daten

Wiederherstellung der GitLab-Version

Update

Links