Tachtler's DokuWiki

Homepage | Kontakt | Rechtliche Informationen | Impressum

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen: • gitlab_archlinux
tachtler:gitlab_archlinux

Inhaltsverzeichnis

GitLab ArchLinux

GitLab ist ein, in der Community Edition unter einer MIT-Lizenz zur Verfügung gestelltes System, zur Verwaltung von Git-Repositorys im Browser, was den unentgeltlichen Betrieb auf einem eigenen Server ermöglicht.

Beschreibung Externer Link
Homepage https://gitlab.com/
Dokumentation https://docs.gitlab.com/
Versionsvergleich https://about.gitlab.com/install/ce-or-ee/
Installation https://wiki.archlinux.org/title/PostgreSQL
https://wiki.archlinux.org/title/Redis
https://wiki.archlinux.org/title/GitLab

Ab hier werden root-Rechte zur Ausführung der nachfolgenden Befehle benötigt. Um der Benutzer root zu werden, geben Sie bitte nachfolgenden Befehl ein: 

$ su -
Password:

Voraussetzungen

Als Voraussetzung für die hier, nachfolgend dargestellte Installation von GitLab Version 16.x sind folgende Komponenten erforderlich:

Optional

  • Lauffähiger LDAP-Server z.B. OpenLDAP
  • Lauffähiger E-Mail-Server (MTA) z.B. Postfix
    • Siehe auch den internen Link: FIXME

GitLab: Installation

Nachfolgend soll die Installation von GitLab durchgeführt werden.

Um GitLab betreiben zu können, muss das Paket

  • gitlab - ist im extra-Repository von ArchLinux enthalten

installiert werden.

Mit nachfolgendem Befehl, wird das Pakete gitlab installiert: 

# pacman --noconfirm -S gitlab

Installationsverlauf

:!: HINWEIS - Nachfolgende Hinweise bei der Installation sind zu beachten: 

warning: directory permissions differ on /var/lib/gitlab/
filesystem: 755  package: 750
Configure gitlab-shell in /etc/webapps/gitlab-shell/config.yml
Put a secret bytestring to /etc/webapps/gitlab-shell/secret
warning: directory permissions differ on /var/lib/gitlab/
filesystem: 755  package: 750
warning: directory permissions differ on /var/log/gitlab/
filesystem: 770  package: 755
Configure your /etc/webapps/gitlab/gitlab.yml
Set up your redis to run on /run/redis/redis.sock or configure gitlab to use redis TCP
Put a secret bytestring to /etc/webapps/gitlab/secret
Copy /usr/share/webapps/gitlab/config/secrets.yml.example to /etc/webapps/gitlab/secrets.yml and configure it
Setup the database:
$ (cd /usr/share/webapps/gitlab && sudo -u gitlab $(cat environment | xargs) bundle exec rake gitlab:setup)
Finally run the following commands to check your installation:
$ (cd /usr/share/webapps/gitlab && sudo -u gitlab $(cat environment | xargs) bundle exec rake gitlab:env:info)
$ (cd /usr/share/webapps/gitlab && sudo -u gitlab $(cat environment | xargs) bundle exec rake gitlab:check)

Mit nachfolgendem Befehl kann überprüft werden, welche Inhalte mit den Paket gitlab installiert wurden: 

# pacman -Qil gitlab

Installierte Dateien

:!: HINWEIS - Die Konfiguration erfolgt erst zu einem späteren Zeitpunkt, nachdem

zuvor installiert und Konfiguriert wurden!

Go: Installation

Nachfolgend soll die Installation von erfolgen, da GitLab mehrere in Go geschriebene Dienste/Daemons wie z.N. den GitLab-Runner hat, wird ein Go-Compiler benötigt.

Um Go nutzen zu können, muss das Paket

  • go - ist im extra-Repository von ArchLinux enthalten

installiert werden.

Mit nachfolgendem Befehl, wird das Pakete go installiert: 

# pacman --noconfirm -S go

Installationsverlauf

Mit nachfolgendem Befehl kann überprüft werden, welche Inhalte mit den Paket go installiert wurden: 

# pacman -Qil go

Installierte Dateien

GraphicsMagick: Installation

Nachfolgend soll die Installation von GraphicsMagick erfolgen, damit benutzerdefinierte Favicon-Ausgabe funktioniert, muss GraphicsMagick installiert sein.

Um GraphicsMagick nutzen zu können, muss das Paket

  • graphicsmagick - ist im extra-Repository von ArchLinux enthalten

installiert werden.

Mit nachfolgendem Befehl, wird das Pakete graphicsmagick installiert: 

# pacman --noconfirm -S graphicsmagick

Installationsverlauf

Mit nachfolgendem Befehl kann überprüft werden, welche Inhalte mit den Paket graphicsmagick installiert wurden: 

# pacman -Qil graphicsmagick

Installierte Dateien

PostgreSQL: Installation

Nachfolgend soll zuerst eine Installation einer lokalen PostgreSQL-Datenbank erfolgen, welche auf dem Server, auf dem auch GitLab installiert werden soll läuft. Die PostgreSQL-Datenbank soll nur via socket erreichbar sein und keine Netzwerk-Verbindungen nach ausserhalb des lokalen Servers haben.

Um die PostgreSQL-Datenbank betreiben zu können, muss das Paket

  • postgresql - ist im extra-Repository von ArchLinux enthalten

installiert werden.

Mit nachfolgendem Befehl, wird das Pakete postgresql installiert: 

# pacman --noconfirm -S postgresql

Installationsverlauf

Mit nachfolgendem Befehl kann überprüft werden, welche Inhalte mit den Paket postgresql installiert wurden: 

# pacman -Qil postgresql

Installierte Dateien

PostgreSQL: Konfiguration

PostgreSQL: Dienst/Daemon-Start einrichten

Um die PostgreSQL-Datenbank, welche als Dienst/Daemon als Hintergrundprozess läuft, auch nach einem Neustart des Servers zur Verfügung zu haben, soll der Dienst/Daemon mit dem Server mit gestartet werden, was mit nachfolgendem Befehl realisiert werden kann: 

# systemctl enable postgresql.service
Created symlink /etc/systemd/system/multi-user.target.wants/postgresql.service → /usr/lib/systemd/system/postgresql.service.

Eine Überprüfung, ob beim Neustart des Server der postgresql-Dienst/Daemon wirklich mit gestartet wird, kann mit nachfolgendem Befehl erfolgen und sollte eine Anzeige, wie ebenfalls nachfolgend dargestellt ausgeben: 

# systemctl list-unit-files --type=service | grep -e postgresql.service
postgresql.service                           enabled         disabled

bzw. 

# systemctl is-enabled postgresql.service
enabled

:!: HINWEIS - Der Dienst/Daemon soll noch nicht gestartet werden !

PostgreSQL: Benutzer postgres

Nach der erfolgreichen Installation von PostgreSQL-Datenbank, muss diese noch für die Verwendung mit GitLab entsprechend Konfiguriert werden.

Ab hier werden die Rechte des postgres-Benutzers zur Ausführung der nachfolgenden Befehle benötigt. Um der Benutzer postgres zu werden, geben Sie bitte nachfolgenden Befehl ein: 

# su - postgres
[postgres@server ~]$

Anschliessend kann mit nachfolgendem einfachen Befehl überprüft werden, ob die Installation funktionsfähig ist: 

[postgres@server ~]$ psql --version
psql (PostgreSQL) 16.2

PostgreSQL: Datenbank initialisieren

Jetzt soll die Datenbank initialisiert werden, was als Benutzer postgres mit nachfolgendem Befehl erfolgen soll: 

[postgres@server ~]$ initdb -D /var/lib/postgres/data
[postgres@server ~]$ initdb -D /var/lib/postgres/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgres/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Europe/Berlin
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    pg_ctl -D /var/lib/postgres/data -l logfile start

:!: ACHTUNG - Der Befehl pg_ctl -D /var/lib/postgres/data -l logfile start soll nicht ausgeführt werden, der Start der PostgreSQL-Datenbank erfolgt via systemd-service!

PostgreSQL: Erster Start

:!: WICHTIG - Mit dem nachfolgendem Befehl wird der Benutzer postgres wieder verlassen und zum Benutzer root zur Ausführung der nachfolgenden Befehle zurückgekehrt. Um der Benutzer root zu werden, geben Sie bitte nachfolgenden Befehl ein: 

[postgres@sever ~]$ exit
logout
#

Bevor weitere Konfigurationsschritte erfolgen, kann der ersten Start mit nachfolgendem Befehl durchgeführt werden: 

# systemctl start postgresql.service

:!: HINWEIS - Es erfolgen keine weiteren Ausgaben, wenn der Start erfolgreich war !

PostgreSQL: Überprüfung

Ob der PostgreSQL-Server, sprich der postgresql-Dienst/Deamon auch tatsächlich als Hintergrundprozess läuft, kann mit nachfolgendem Befehl überprüft werden: 

# ps auxwf | grep -E ^postgres
postgres    1993  0.0  0.6 216748 27648 ?        Ss   08:11   0:00 /usr/bin/postgres
-D /var/lib/postgres/data
postgres    1995  0.0  0.2 216888  9196 ?        Ss   08:11   0:00  \_ postgres: checkpointer 
postgres    1996  0.0  0.1 216880  6892 ?        Ss   08:11   0:00  \_ postgres: background writer 
postgres    1998  0.0  0.2 216880  9708 ?        Ss   08:11   0:00  \_ postgres: walwriter 
postgres    1999  0.0  0.2 218360  8172 ?        Ss   08:11   0:00  \_ postgres: autovacuum launcher 
postgres    2000  0.0  0.1 218336  7532 ?        Ss   08:11   0:00  \_ postgres: logical replication 
launcher

und nachfolgender Befehl: 

# ss -taubenp | grep postgres
tcp   LISTEN 0      200                         127.0.0.1:5432      0.0.0.0:*     users:
(("postgres",pid=1993,fd=7))
uid:970 ino:22159 sk:3 cgroup:/system.slice/postgresql.service <->            
tcp   LISTEN 0      200                             [::1]:5432         [::]:*     users:
(("postgres",pid=1993,fd=6))
uid:970 ino:22158 sk:6 cgroup:/system.slice/postgresql.service v6only:1 <->

bzw. nachfolgender Befehl: 

# systemctl status postgresql.service
● postgresql.service - PostgreSQL database server
     Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; prese>
     Active: active (running) since Wed 2024-03-20 08:11:51 CET; 6min ago
    Process: 1991 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGROOT}/data >
   Main PID: 1993 (postgres)
      Tasks: 6 (limit: 4653)
     Memory: 19.2M (peak: 22.1M)
        CPU: 269ms
     CGroup: /system.slice/postgresql.service
             ├─1993 /usr/bin/postgres -D /var/lib/postgres/data
             ├─1995 "postgres: checkpointer "
             ├─1996 "postgres: background writer "
             ├─1998 "postgres: walwriter "
             ├─1999 "postgres: autovacuum launcher "
             └─2000 "postgres: logical replication launcher "

Mar 20 08:11:51 server systemd[1]: Starting PostgreSQL database server...
Mar 20 08:11:51 server postgres[1993]: 2024-03-20 08:11:51.595 CET [1993] LOG: >
Mar 20 08:11:51 server postgres[1993]: 2024-03-20 08:11:51.595 CET [1993] LOG: >
Mar 20 08:11:51 server postgres[1993]: 2024-03-20 08:11:51.595 CET [1993] LOG: >
Mar 20 08:11:51 server postgres[1993]: 2024-03-20 08:11:51.598 CET [1993] LOG: >
Mar 20 08:11:51 server postgres[1997]: 2024-03-20 08:11:51.602 CET [1997] LOG: >
Mar 20 08:11:51 server postgres[1993]: 2024-03-20 08:11:51.605 CET [1993] LOG: >

Eine weitere Überprüfung, ob der erste Start erfolgreich war, kann durch Einsicht in die LOG-Ausgaben des systemd-journald erfolgen:

Ausgabe der LOG-Datei des systemd-journald kann mit nachfolgendem Befehl dargestellt werden: 

# journalctl -u postgresql
Mar 20 08:11:51 server systemd[1]: Starting PostgreSQL database server...
Mar 20 08:11:51 server postgres[1993]: 2024-03-20 08:11:51.595 CET [1993] LOG:  starting PostgreSQL 16.2->
Mar 20 08:11:51 server postgres[1993]: 2024-03-20 08:11:51.595 CET [1993] LOG:  listening on IPv6 address>
Mar 20 08:11:51 server postgres[1993]: 2024-03-20 08:11:51.595 CET [1993] LOG:  listening on IPv4 address>
Mar 20 08:11:51 server postgres[1993]: 2024-03-20 08:11:51.598 CET [1993] LOG:  listening on Unix socket >
Mar 20 08:11:51 server postgres[1997]: 2024-03-20 08:11:51.602 CET [1997] LOG:  database system was shut >
Mar 20 08:11:51 server postgres[1993]: 2024-03-20 08:11:51.605 CET [1993] LOG:  database system is ready >
Mar 20 08:11:51 server systemd[1]: Started PostgreSQL database server.
Mar 20 08:16:51 server postgres[1995]: 2024-03-20 08:16:51.701 CET [1995] LOG:  checkpoint starting: time
Mar 20 08:16:55 server postgres[1995]: 2024-03-20 08:16:55.873 CET [1995] LOG:  checkpoint complete: wrot>

Durch nachfolgenden Befehl, kann das Verzeichnis in dem die MariaDB-Datenbank standardmässig die Dateien der einzelnen Datenbanken ablegt, angezeigt werden. Die Ausgabe sollte in etwa wie nachfolgend gezeigt aussehen: 

# ls -la /var/lib/postgres/data/
total 68
drwx------ 19 postgres postgres  4096 Mar 20 08:11 .
drwxr-xr-x  3 root     root        18 Mar 20 07:32 ..
drwx------  5 postgres postgres    33 Mar 20 08:01 base
drwx------  2 postgres postgres  4096 Mar 20 08:14 global
drwx------  2 postgres postgres     6 Mar 20 08:01 pg_commit_ts
drwx------  2 postgres postgres     6 Mar 20 08:01 pg_dynshmem
-rw-------  1 postgres postgres  5711 Mar 20 08:01 pg_hba.conf
-rw-------  1 postgres postgres  2640 Mar 20 08:01 pg_ident.conf
drwx------  4 postgres postgres    68 Mar 20 08:16 pg_logical
drwx------  4 postgres postgres    36 Mar 20 08:01 pg_multixact
drwx------  2 postgres postgres     6 Mar 20 08:01 pg_notify
drwx------  2 postgres postgres     6 Mar 20 08:01 pg_replslot
drwx------  2 postgres postgres     6 Mar 20 08:01 pg_serial
drwx------  2 postgres postgres     6 Mar 20 08:01 pg_snapshots
drwx------  2 postgres postgres     6 Mar 20 08:11 pg_stat
drwx------  2 postgres postgres     6 Mar 20 08:01 pg_stat_tmp
drwx------  2 postgres postgres    18 Mar 20 08:01 pg_subtrans
drwx------  2 postgres postgres     6 Mar 20 08:01 pg_tblspc
drwx------  2 postgres postgres     6 Mar 20 08:01 pg_twophase
-rw-------  1 postgres postgres     3 Mar 20 08:01 PG_VERSION
drwx------  3 postgres postgres    60 Mar 20 08:01 pg_wal
drwx------  2 postgres postgres    18 Mar 20 08:01 pg_xact
-rw-------  1 postgres postgres    88 Mar 20 08:01 postgresql.auto.conf
-rw-------  1 postgres postgres 29719 Mar 20 08:01 postgresql.conf
-rw-------  1 postgres postgres    48 Mar 20 08:11 postmaster.opts
-rw-------  1 postgres postgres    99 Mar 20 08:11 postmaster.pid

PostgreSQL: Einstellungen

Nachfolgend werden einige Einstellungen für einen grundlegenden und sicheren Betrieb des PostgreSQL-Servers durchgeführt.

/var/lib/postgres/data/postgresql.conf

Nachfolgende Einstellungen in der Konfigurationsdatei /var/lib/postgres/data/postgresql.conf sollen wie folgt durchgeführt werden. 

# vim /var/lib/postgres/data/postgresql.conf
  • # Tachtler
# default: #listen_addresses = 'localhost'      # what IP address(es) to listen on;
listen_addresses = ''       # what IP address(es) to listen on;                                                      
                    # comma-separated list of addresses;
                    # defaults to 'localhost'; use '*' for all
                    # (change requires restart)

Deaktivieren des listen_addresses durch setzen auf einen leeren Inhalt, damit nur über eine socket-Verbindung lokal auf die PostgreSQL-Datenbank zugegriffen werden kann.

/var/lib/postgres/data/pg_hba.conf

Nachfolgende Einstellungen in der Konfigurationsdatei /var/lib/postgres/data/pg_hba.conf sollen wie folgt durchgeführt werden.

Die Standardeinstellung in der Konfigurationsdatei /var/lib/postgres/data/pg_hba.conf erlaubt jedem lokalen Benutzer, sich als beliebiger Datenbankbenutzer zu verbinden, einschliesslich des Superusers der Datenbank.

Um den globalen Zugriff auf den Benutzer postgres und generell auch via Netzwerk auch in dieser Konfigurationsdatei zu beschränken, sind nachfolgende Zeilen wie folgt abzuändern: 

# vim /var/lib/postgres/data/pg_hba.conf

Vorher: 

# TYPE  DATABASE        USER            ADDRESS                 METHOD
 
# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     trust
host    replication     all             127.0.0.1/32            trust
host    replication     all             ::1/128                 trust

Nachher 

# TYPE  DATABASE        USER            ADDRESS                 METHOD
 
# "local" is for Unix domain socket connections only
# Tachtler
# default: local   all             all                                     trust
local   all             postgres                                peer
local   all             gitlab                                  scram-sha-256
# IPv4 local connections:
# Tachtler
# disabled: host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
# Tachtler
# disabled: host    all             all             ::1/128                 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
# Tachtler
# default: local   replication     all                                     trust
local   replication     postgres                                 peer
# Tachtler
# disabled: host    replication     all             127.0.0.1/32            trust
# Tachtler
# disabled: host    replication     all             ::1/128                 trust

Legende:

trust = Die Verbindung bedingungslos zulassen. Diese Methode erlaubt es jedem Benutzer, der sich mit der PostgreSQL-Datenbank verbinden kann, sich als jeder beliebige PostgreSQL-Datenbank-Benutzer anzumelden, ohne dass ein Passwort oder eine andere Authentifizierung erforderlich ist.

peer = Ermitteln den Betriebssystem-Benutzernamen des Clients im lokalen Betriebssystem und prüft, ob er mit dem angeforderten Datenbank-Benutzernamen übereinstimmt. Dies ist nur für lokale Verbindungen möglich.

Weitere Zugriffsbeschränkung-Möglichkeiten sind unter nachfolgendem externen Link ersichtlich:

/var/lib/postgres/.psql_history

Nachfolgende Datei sollte mit nachfolgendem Befehl erstellt werden, da in dieser die Historie aller mittels mit dem Befehl psql eingegebenen Befehle und SQL-Statements gespeichert werden: 

# touch /var/lib/postgres/.psql_history

Anschliessend sind noch die entsprechenden Besitz- und Dateirechte wie folgt mit den nachfolgenden Beiden Befehlen zu setzen:

Besitzrechte: 

# chown postgres:postgres /var/lib/postgres/.psql_history

Dateirechte: 

# chmod 700 /var/lib/postgres/.psql_history

PostgreSQL: Neustart

Bevor weitere Konfigurationsschritte erfolgen, soll ein Neustart mit nachfolgendem Befehl durchgeführt werden: 

# systemctl restart postgresql.service

:!: HINWEIS - Es erfolgen keine weiteren Ausgaben, wenn der Start erfolgreich war !

Nachfolgender Befehl, sollte nun keine Ausgabe mehr erzeugen: 

# ss -taubenp | grep postgres

PostgreSQL: Benutzer gitlab erstellen

Nach der erfolgreichen Konfiguration der Einstellungen der PostgreSQL-Datenbank, muss diese noch für die Verwendung mit einem GitLab-Benutzer entsprechend Konfiguriert werden.

Ab hier werden die Rechte des postgres-Benutzers zur Ausführung der nachfolgenden Befehle benötigt. Um der Benutzer postgres zu werden, geben Sie bitte nachfolgenden Befehl ein: 

# su - postgres
[postgres@server ~]$

Nachfolgende Schritte sind nun erforderlich um einen Benutzer zur Verwendung durch GitLab gegenüber der PostgreSQL-Datenbank anzulegen, was mit nachfolgendem Befehl durchgeführt werden kann: 

[postgres@server ~]$ psql -d template1 -c "CREATE USER gitlab WITH PASSWORD 'geheim'"
CREATE ROLE

Anschliessen soll der GitLab-Benutzer auch Superuser-Rechte erhalten, da GitLab versucht, Erweiterungen zu installieren und diese nicht nur in dessen eigenen Benutzerbereich zu erstellen. Dies ist jedoch nur Superusern in PostgreSQL erlaubt: 

[postgres@server ~]$ psql -d template1 -c "ALTER USER gitlab SUPERUSER;"
ALTER ROLE

PostgreSQL: Datenbank gitlabhq_production erstellen

Abschliessend ist es noch erforderlich die Datenbank für GitLab zu erstellen, welche auch dem GitLab-Benutzer gehören soll: 

[postgres@server ~]$ psql -d template1 -c "CREATE DATABASE gitlabhq_production OWNER gitlab;"
CREATE DATABASE

PostgreSQL: Datenbank EXTENSIONS erstellen

:!: WICHTIG - Mit dem nachfolgendem Befehl wird der Benutzer postgres wieder verlassen und zum Benutzer root zur Ausführung der nachfolgenden Befehle zurückgekehrt. Um der Benutzer root zu werden, geben Sie bitte nachfolgenden Befehl ein: 

[postgres@sever ~]$ exit
logout
#

Anschliessen kann nun ein erster Verbindungstest durchgeführt werden, welcher gegen die PostgreSQL mit nachfolgenden Parametern erfolgen soll:

  • Datenbank: gitlabhq_production
  • Benutzer: gitlab
  • Passwort: geheim
# psql -d gitlabhq_production -U gitlab -W
Password: 
psql (16.2)
TYPE "help" FOR help.
 
gitlabhq_production=#

Nachfolgende PostgreSQL-Datenbank Extensions (Erweiterungen), sollten für die Benutzung von GitLab hinzugefügt werden:

  • pg_trgm - Unterstützung für die Ähnlichkeiten-Erkennung im Text mittels Trigramm-Matching
  • btree_gist - GiST-Operatorklassen mit B-Baum-Verhalten
  • plpgsql - PL/pgSQL - SQL-Prozedurale Sprache - sollte bereits existieren!
gitlabhq_production=# CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION
gitlabhq_production=# CREATE EXTENSION IF NOT EXISTS btree_gist;
CREATE EXTENSION

Eine Überprüfung, ob die Extensions (Erweiterungen)

  • pg_trgm - Unterstützung für die Ähnlichkeiten-Erkennung im Text mittels Trigramm-Matching
  • btree_gist - GiST-Operatorklassen mit B-Baum-Verhalten
  • plpgsql - PL/pgSQL - SQL-Prozedurale Sprache - sollte bereits existieren!

auch aktiviert sind, kann mit nachfolgendem SQL-Statements durchgeführt werden kann: 

gitlabhq_production=# SELECT TRUE AS enabled FROM pg_available_extensions WHERE name = 'pg_trgm' AND installed_version IS NOT NULL;
 enabled 
---------
 t
(1 ROW)
gitlabhq_production=# SELECT TRUE AS enabled FROM pg_available_extensions WHERE name = 'btree_gist' AND installed_version IS NOT NULL;
 enabled 
---------
 t
(1 ROW)
gitlabhq_production=# SELECT TRUE AS enabled FROM pg_available_extensions WHERE name = 'plpgsql' AND installed_version IS NOT NULL;
 enabled 
---------
 t
(1 ROW)

:!: HINWEIS - Es sollte immer eine Ausgabe mit t unterhalb der Spalte enabled erscheinen!

Das psql (PostgreSQL Interactive Terminal) kann wieder mit nachfolgendem Befehl \q verlassen werden: 

gitlabhq_production=# \q
#

Redis: Installation

Nachfolgend soll die Installation einer lokalen Redis-Datenstruktur-Server erfolgen, welche auf dem Server, auf dem auch GitLab installiert werden soll läuft. Der Redis-Datenstruktur-Server soll nur via socket erreichbar sein und keine Netzwerk-Verbindungen nach ausserhalb des lokalen Servers haben.

Um die Redis-Datenstruktur-Server betreiben zu können, muss das Paket

  • redis - ist im extra-Repository von ArchLinux enthalten

installiert werden.

Mit nachfolgendem Befehl, wird das Pakete redis installiert: 

# pacman --noconfirm -S redis

Installationsverlauf

Mit nachfolgendem Befehl kann überprüft werden, welche Inhalte mit den Paket redis installiert wurden: 

# pacman -Qil redis

Installierte Dateien

Redis: Konfiguration

Redis: Dienst/Daemon-Start einrichten

Um den Redis-Datenstruktur-Server, welche als Dienst/Daemon als Hintergrundprozess läuft, auch nach einem Neustart des Servers zur Verfügung zu haben, soll der Dienst/Daemon mit dem Server mit gestartet werden, was mit nachfolgendem Befehl realisiert werden kann: 

# systemctl enable redis.service
Created symlink /etc/systemd/system/multi-user.target.wants/redis.service → /usr/lib/systemd/system/redis.service.

Eine Überprüfung, ob beim Neustart des Server der redis-Dienst/Daemon wirklich mit gestartet wird, kann mit nachfolgendem Befehl erfolgen und sollte eine Anzeige, wie ebenfalls nachfolgend dargestellt ausgeben: 

# systemctl list-unit-files --type=service | grep -e redis.service
redis.service                                enabled         disabled

bzw. 

# systemctl is-enabled redis.service
enabled

:!: HINWEIS - Der Dienst/Daemon soll noch nicht gestartet werden !

Redis: Einstellungen

Nachfolgende Konfiguration in der Standard-Konfigurationsdatei /etc/redis/redis.conf des Redis-Datenstruktur-Server sind durchzuführen, damit ein Zusammenspiel mit GitLab gewährleistet werden kann.

/etc/redis/redis.conf

Nachfolgende Einstellungen in der Konfigurationsdatei /etc/redis/redis.conf sollen wie folgt durchgeführt werden. 

# vim /etc/redis/redis.conf
  • # Tachtler
# default: port 6379
port 0

Deaktivieren des port durch setzen auf den Wert 0, damit nur über eine socket-Verbindung lokal auf den Redis-Datenstruktur-Server zugegriffen werden kann. 

  • # Tachtler
# default: # unixsocket /run/redis.sock
unixsocket /run/redis/redis.sock

Einrichten eines socket für den Redis-Datenstruktur-Server. 

  • # Tachtler
# default: # unixsocketperm 700
unixsocketperm 770

Setzen der Dateirechte für den socket des Redis-Datenstruktur-Servers. 

  • # Tachtler
# default: pidfile /var/run/redis_6379.pid
pidfile /run/redis/redis.pid

Einrichten des Speicherorts für die PID-Datei für den Redis-Datenstruktur-Server, in dem auch der Redis-Datenstruktur-Server Schreibrechte besitzt.

Anschliessend muss noch das Verzeichnis, in dem die socket-Datei gespeichert werden soll, mit nachfolgendem Befehl erstellt werden: 

# mkdir /run/redis/

Anschliessend sind noch die entsprechenden Besitz- und Dateirechte wie folgt mit den nachfolgenden Beiden Befehlen zu setzen:

Besitzrechte: 

# chown -R redis:redis /run/redis/

Dateirechte: 

# chmod -R 770 /run/redis/

/etc/tmpfiles.d/redis.conf

:!: HINWEIS - Falls nicht bereits vorhanden, muss die Konfigurationsdatei /etc/tmpfiles.d/redis.conf neu erstellt werden!

Um Warnmeldungen wie „you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis„ („Sie haben die Unterstützung für Transparent Huge Pages (THP) in Ihrem Kernel aktiviert. Dies führt zu Latenz- und Speichernutzungsproblemen mit Redis“). Mit nachfolgender Konfiguration, kann diese Funktion dauerhaft deaktiviert werden: 

# vim /etc/tmpfiles.d/redis.conf
w /sys/kernel/mm/transparent_hugepage/enabled - - - - never
w /sys/kernel/mm/transparent_hugepage/defrag - - - - never

/etc/sysctl.d/99-sysctl.conf

:!: HINWEIS - Falls nicht bereits vorhanden, muss die Konfigurationsdatei /etc/sysctl.d/99-sysctl.conf neu erstellt werden!

Um Warnmeldungen wie „The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128“ („Die TCP-Backlog-Einstellung von 511 kann nicht erzwungen werden, da /proc/sys/net/core/somaxconn auf den niedrigeren Wert von 128 eingestellt ist“) zu beheben, kann der aktuellen Wert wie folgt erhöht werden: 

# vim /etc/sysctl.d/99-sysctl.conf
net.core.somaxconn=512

Um Warnmeldungen wie „overcommit_memory is set to 0! Background save may fail under low memory condition“ („overcommit_memory ist auf 0 gesetzt! Die Hintergrundspeicherung kann bei geringem Speicher fehlschlagen“) zu beheben, kann der aktuellen Wert wie folgt gesetzt werden: 

# vim /etc/sysctl.d/99-sysctl.conf
vm.overcommit_memory=1

/etc/group

Nachfolgend ist es noch erforderlich, das der GitLab-Benutzer in der Gruppe des Redis-Datenstruktur-Servers hinzugefügt wird, damit dieser Zugriff auf dessen hat, was mit nachfolgendem Befehl durchgeführt werden kann: 

# usermod -aG redis gitlab

Eine Überprüfung, ob dies erfolgreich war, kann mit nachfolgendem Befehl überprüft werden: 

# cat /etc/group | grep redis
redis:x:969:gitlab

Redis: Erster Start

Bevor weitere Konfigurationsschritte erfolgen, kann der ersten Start mit nachfolgendem Befehl durchgeführt werden: 

# systemctl start redis.service

:!: HINWEIS - Es erfolgen keine weiteren Ausgaben, wenn der Start erfolgreich war !

Redis: Überprüfung

Ob der Redis-Datenstruktur-Server, sprich der redis-Dienst/Deamon auch tatsächlich als Hintergrundprozess läuft, kann mit nachfolgendem Befehl überprüft werden: 

 ps auxwf | grep -E ^redis
redis       4712  0.2  0.4  69368 17876 ?        Ssl  13:15   0:00 /usr/bin/redis-server unixsocket:/run/
redis/redis.sock

und nachfolgender Befehl: 

# ss -taubenp | grep redis

:!: HINWEIS - Es sollte keine Ausgabe erfolgen !

bzw. nachfolgender Befehl: 

# systemctl status redis.service
● redis.service - Advanced key-value store
     Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; preset: di>
     Active: active (running) since Wed 2024-03-20 13:15:21 CET; 3min 18s ago
   Main PID: 4712 (redis-server)
     Status: "Ready to accept connections"
      Tasks: 5 (limit: 4653)
     Memory: 8.3M (peak: 8.6M)
        CPU: 532ms
     CGroup: /system.slice/redis.service
             └─4712 "/usr/bin/redis-server unixsocket:/run/redis/redis.sock"

Mar 20 13:15:21 server redis-server[4712]: 4712:C 20 Mar 2024 13:15:21.808 * Su>
Mar 20 13:15:21 server redis-server[4712]: 4712:C 20 Mar 2024 13:15:21.808 * oO>
Mar 20 13:15:21 server redis-server[4712]: 4712:C 20 Mar 2024 13:15:21.808 * Re>
Mar 20 13:15:21 server redis-server[4712]: 4712:C 20 Mar 2024 13:15:21.808 * Co>
Mar 20 13:15:21 server redis-server[4712]: 4712:M 20 Mar 2024 13:15:21.808 * mo>
Mar 20 13:15:21 server redis-server[4712]: 4712:M 20 Mar 2024 13:15:21.809 # Fa>
Mar 20 13:15:21 server redis-server[4712]: 4712:M 20 Mar 2024 13:15:21.809 * Ru>
Mar 20 13:15:21 server redis-server[4712]: 4712:M 20 Mar 2024 13:15:21.809 * Se>
Mar 20 13:15:21 server redis-server[4712]: 4712:M 20 Mar 2024 13:15:21.809 * Re>
Mar 20 13:15:21 server systemd[1]: Started Advanced key-value store.

Eine weitere Überprüfung, ob der erste Start erfolgreich war, kann durch Einsicht in die LOG-Ausgaben des systemd-journald erfolgen:

Ausgabe der LOG-Datei des systemd-journald kann mit nachfolgendem Befehl dargestellt werden: 

 journalctl -u redis
Mar 20 13:15:21 server systemd[1]: Starting Advanced key-value store...
Mar 20 13:15:21 server redis-server[4712]: 4712:C 20 Mar 2024 13:15:21.808 * Supervised by systemd. Pleas>
Mar 20 13:15:21 server redis-server[4712]: 4712:C 20 Mar 2024 13:15:21.808 * oO0OoO0OoO0Oo Redis is 0OoO0>
Mar 20 13:15:21 server redis-server[4712]: 4712:C 20 Mar 2024 13:15:21.808 * Redis version=7.2.4, bits=64>
Mar 20 13:15:21 server redis-server[4712]: 4712:C 20 Mar 2024 13:15:21.808 * Configuration loaded
Mar 20 13:15:21 server redis-server[4712]: 4712:M 20 Mar 2024 13:15:21.808 * monotonic clock: POSIX clock>
Mar 20 13:15:21 server redis-server[4712]: 4712:M 20 Mar 2024 13:15:21.809 * Running mode=standalone, por>
Mar 20 13:15:21 server redis-server[4712]: 4712:M 20 Mar 2024 13:15:21.809 * Server initialized
Mar 20 13:15:21 server redis-server[4712]: 4712:M 20 Mar 2024 13:15:21.809 * Ready to accept connections >
Mar 20 13:15:21 server systemd[1]: Started Advanced key-value store.

Apache HTTP Webserver: Installation

Nachfolgend soll ein Apache HTTPD Webserver zur Auslieferung von GitLab verwendet werden.

Dazu ist es erforderlich einen Apache HTTPD Webserver, wie unter nachfolgendem internen Link zu installieren:

Apache HTTP Webserver: /etc/httpd/conf/extra/gitlab.conf

Zusätzlich ist die Einrichtung eines virtuellen Host mit nachfolgender Konfiguration erforderlich. Die Konfigurationsdatei sollte unter nachfolgendem Verzeichnis mit nachfolgendem Namen wie folgt angepasst werden: 

# vim /etc/httpd/conf/extra/gitlab.conf

Der Inhalt der so angepasste Konfigurationsdatei für den virtuellen Host des Apache HTTPD Webserver könnte dann in etwa wie folgt aussehen: 

<VirtualHost *:80>
    ServerAdmin webmaster@tachtler.net
    ServerName gitlab.tachtler.net
    ServerPath /
 
    # ----------------------------------------------------------
    # Protocol settings
    # Enable protocol order and honor the client protocol order.
    # ----------------------------------------------------------
    <IfModule http2_module>
        Protocols h2 h2c http/1.1
        ProtocolsHonorOrder Off    
    </IfModule>
 
    # ----------------------------------------------------------
    # Rewrite settings
    # Rewrite the requestet URI - PERMANENT - to HTTPS and leave
    # this virtual Host to the HTTPS variant of it, but NOT when
    # request the Let's Encrypt .well-known/acme-challenge/ URI.
    # ----------------------------------------------------------
    <IfModule rewrite_module>
        RewriteEngine On
        RewriteCond "%{HTTPS}" "!=on"
        RewriteCond "%{REQUEST_URI}" "!^/\.well\-known/acme\-challenge/"
        RewriteRule "^(.*)$" "https://%{HTTP_HOST}%{REQUEST_URI}" [R=301,L]
    </IfModule>
 
    # ----------------------------------------------------------
    # Let's Encrypt settings
    # For creation of Let's Encrypt certificates following lines 
    # are necessary.
    # ----------------------------------------------------------
    <IfModule alias_module>
        Alias /.well-known/acme-challenge/ /srv/http/.well-known/acme-challenge/
    </IfModule>
 
    <Location /.well-known/acme-challenge/>
        Require all granted
        Satisfy Any
    </Location>
 
    # ----------------------------------------------------------
    # Logging settings
    # ----------------------------------------------------------
    <IfModule log_config_module>
        ErrorLog /var/log/httpd/gitlab.tachtler.net_error.log
        SetEnvIF User-Agent "HAProxy" dontlog=yes
        SetEnvIf X-Forwarded-For "^.*\..*\..*\..*" forwarded=yes
        <IfModule logio_module>
            CustomLog /var/log/httpd/gitlab.tachtler.net_access.log combined_deflate "expr=(reqenv('forwarded') != 'yes' && reqenv('dontlog') != 'yes')"
            CustomLog /var/log/httpd/gitlab.tachtler.net_access.log combined_deflate_proxypass "expr=(reqenv('forwarded') == 'yes' && reqenv('dontlog') != 'yes')"
        </IfModule>
    </IfModule>
</VirtualHost>
 
<VirtualHost *:443>
    ServerAdmin webmaster@tachtler.net
    ServerName gitlab.tachtler.net
    ServerPath /
 
    # ----------------------------------------------------------
    # Protocol settings
    # Enable protocol order and honor the client protocol order.
    # ----------------------------------------------------------
    <IfModule http2_module>
        Protocols h2 h2c http/1.1
        ProtocolsHonorOrder Off    
    </IfModule>
 
    # ----------------------------------------------------------
    # SSL settings
    # ----------------------------------------------------------
    <IfModule ssl_module>
        SSLEngine On
        SSLCertificateFile /etc/letsencrypt/live/tachtler.net/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/tachtler.net/privkey.pem
 
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
            SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory "/srv/http/cgi-bin">
            SSLOptions +StdEnvVars
        </Directory>
 
        BrowserMatch "MSIE [2-5]" \
            nokeepalive ssl-unclean-shutdown \
            downgrade-1.0 force-response-1.0
    </IfModule>
 
    # ----------------------------------------------------------
    # Rewrite settings
    # Rewrite the requestet URI - PERMANENT - to HTTPS and leave
    # this virtual Host to the HTTPS variant of it, but NOT when
    # request the Let's Encrypt .well-known/acme-challenge/ URI.
    # ----------------------------------------------------------
    <IfModule rewrite_module>
        RewriteEngine On
        RewriteCond "%{HTTPS}" "!=on"
        RewriteCond "%{REQUEST_URI}" "!^/\.well\-known/acme\-challenge/"
        RewriteRule "^(.*)$" "https://%{HTTP_HOST}%{REQUEST_URI}" [R=301,L]
        RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
        RewriteCond %{REQUEST_URI} ^/uploads/.*
        RewriteRule .* unix:/run/gitlab/gitlab-workhorse.socket|http://127.0.0.1%{REQUEST_URI} [P,QSA,NE]
        RequestHeader set X_FORWARDED_PROTO 'https'
        RequestHeader set X-Forwarded-Ssl on
    </IfModule>
 
    # ----------------------------------------------------------
    # Alias settings
    # ----------------------------------------------------------
    <IfModule alias_module>
        Alias / "/usr/share/webapps/gitlab/public/"
    </IfModule>
 
    # ----------------------------------------------------------
    # Header settings
    # ----------------------------------------------------------
    <IfModule headers_module>
        Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; preload"
    </IfModule>
 
    # ----------------------------------------------------------
    # Directory access settings
    # URL of https://servername/
    # ----------------------------------------------------------
    DocumentRoot "/usr/share/webapps/gitlab/public"
 
    <Directory "/usr/share/webapps/gitlab/public">
        Options -Indexes +FollowSymLinks +ExecCGI
        AllowOverride All        
        Require all granted
    </Directory>
 
    # ----------------------------------------------------------
    # Proxy settings
    # ----------------------------------------------------------
    <IfModule ssl_module>
        SSLProxyEngine On
    </IfModule>
 
    <IfModule proxy_module>
        <IfModule proxy_http_module>
            ProxyRequests Off
            ProxyPreserveHost On
 
            ProxyPass /.well-known/acme-challenge !
            ProxyPassReverse /.well-known/acme-challenge !
 
            AllowEncodedSlashes NoDecode
 
            <Location />
                ProxyPass unix:/run/gitlab/gitlab-workhorse.socket|http://127.0.0.1/
                ProxyPassReverse unix:/run/gitlab/gitlab-workhorse.socket|http://127.0.0.1/
            </Location>
 
            <Location /-/cable>
                ProxyPass unix:/run/gitlab/gitlab-workhorse.socket|ws://127.0.0.1/-/cable
                ProxyPassReverse unix:/run/gitlab/gitlab-workhorse.socket|ws://127.0.0.1/-/cable
            </Location>                
 
        </IfModule>
    </IfModule>
 
    # ----------------------------------------------------------
    # ErrorDocument settings
    # ----------------------------------------------------------
    ErrorDocument 404 /404.html
    ErrorDocument 422 /422.html
    ErrorDocument 500 /500.html
    ErrorDocument 503 /deploy.html
 
    # ----------------------------------------------------------
    # Compression settings
    # Enable compression for delivering the compressed site body
    # ----------------------------------------------------------
    <IfModule deflate_module>
        # Place filter 'DEFLATE' on all outgoing content
        SetOutputFilter DEFLATE
        # Exclude uncompressible browser via part of user-agent string
        BrowserMatch ^Mozilla/4 gzip-only-text/html
        BrowserMatch ^Mozilla/4\.0[678] no-gzip
        BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
        # Exclude uncompressible content via file type
        <IfModule setenvif_module>
            SetEnvIfNoCase Request_URI \.(?:png|jpe?g|gif|tar||gz|xz|zip)$ no-gzip
        </IfModule>
        <IfModule headers_module>
            # Properly handle requests coming from behind proxies
            Header append Vary User-Agent
        </IfModule>
    </IfModule>
 
    # ----------------------------------------------------------
    # Logging settings
    # ----------------------------------------------------------
    <IfModule log_config_module>
        ErrorLog /var/log/httpd/gitlab.tachtler.net_error.log
        SetEnvIF User-Agent "HAProxy" dontlog=yes
        SetEnvIf X-Forwarded-For "^.*\..*\..*\..*" forwarded=yes
        <IfModule logio_module>
            CustomLog /var/log/httpd/gitlab.tachtler.net_access.log combined_deflate_ssl "expr=(reqenv('forwarded') != 'yes' && reqenv('dontlog') != 'yes')"
            CustomLog /var/log/httpd/gitlab.tachtler.net_access.log combined_deflate_proxypass_ssl "expr=(reqenv('forwarded') == 'yes' && reqenv('dontlog') != 'yes')"
        </IfModule>
    </IfModule>
</VirtualHost>

Apache HTTP Webserver: /etc/httpd/conf/httpd.conf

Damit die zuvor unter

neu erstellte Konfigurationsdatei auch durch den Apache HTTPD Webserver eingelesen wird, ist nachfolgende Ergänzung in der bereits bestehnden Konfigurationsdatei

  • /etc/httpd/conf/httpd.conf

wie folgt innerhalb der Konfigurationsdatei zu ändern und 

# Tachtler
# default: #LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_module modules/mod_proxy.so
# Tachtler
# default: #LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_http_module modules/mod_proxy_http.so
# Tachtler
# default: #LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so

am Ende der Konfigurationsdatei hinzuzufügen: 

# Load *.conf files in the "conf/vhost" directory, if any.
Include conf/extra/gitlab.conf

Apache HTTP Webserver: Neustart

Bevor weitere Konfigurationsschritte erfolgen, sollte ein Neustart erfolgen, was mit nachfolgendem Befehl durchgeführt werden kann: 

# systemctl restart httpd.service

:!: HINWEIS - Es erfolgen keine weiteren Ausgaben, wenn der Start erfolgreich war !

GitLab: Konfiguration

Die Konfigurationsverzeichnisse und Dateien weichen von der originalen GitLab-Installation wie folgt ab:

Komponente originales Verzeichnis ArchLinux Verzeichnis
Application Code /home/git /usr/share/webapps/gitlab
Application Data /home/git /var/lib/gitlab
User (Home Directory) git (/home/git) gitlab (/var/lib/gitlab)
Configuration File GitShell /home/git/gitlab-shell/config.yml /etc/webapps/gitlab-shell/config.yml
Configuration File GitLab /home/git/gitlab/config/gitlab.yml /etc/webapps/gitlab/gitlab.yml
Logs /home/git/log /var/log/gitlab
Unix socket files/PID files /home/git/sockets /run/gitlab

/var/lib/gitlab/shared/pages

Damit später auch beim möglichen Backup von GitLab auftreten, ist es erforderlich, nachfolgendes Verzeichnis anzulegen, was mit nachfolgenden Befehlen durchgeführt werden kann: 

# sudo -u gitlab mkdir /var/lib/gitlab/shared/pages

Anschliessend sind nur noch die Dateirechte mit nachfolgendem Befehl wie folgt anzupassen: 

# chmod -R 750 /var/lib/gitlab/shared/pages

/var/lib/gitlab/shared/terraform_state

Damit später auch beim möglichen Backup von GitLab auftreten, ist es erforderlich, nachfolgendes Verzeichnis anzulegen, was mit nachfolgenden Befehlen durchgeführt werden kann: 

# sudo -u gitlab mkdir /var/lib/gitlab/shared/terraform_state

Anschliessend sind nur noch die Dateirechte mit nachfolgendem Befehl wie folgt anzupassen: 

# chmod -R 750 /var/lib/gitlab/shared/terraform_state

/var/lib/gitlab/shared/packages

Damit später auch beim möglichen Backup von GitLab auftreten, ist es erforderlich, nachfolgendes Verzeichnis anzulegen, was mit nachfolgenden Befehlen durchgeführt werden kann: 

# sudo -u gitlab mkdir /var/lib/gitlab/shared/packages

Anschliessend sind nur noch die Dateirechte mit nachfolgendem Befehl wie folgt anzupassen: 

# chmod -R 750 /var/lib/gitlab/shared/packages

/var/lib/gitlab/shared/ci_secure_files

Damit später auch beim möglichen Backup von GitLab auftreten, ist es erforderlich, nachfolgendes Verzeichnis anzulegen, was mit nachfolgenden Befehlen durchgeführt werden kann: 

# sudo -u gitlab mkdir /var/lib/gitlab/shared/ci_secure_files

Anschliessend sind nur noch die Dateirechte mit nachfolgendem Befehl wie folgt anzupassen: 

# chmod -R 750  /var/lib/gitlab/shared/ci_secure_files

/etc/webapps/gitlab/gitlab.yml

Die Konfigurationsdatei /etc/webapps/gitlab/gitlab.yml ist die Haupt-Konfigurationsdatei von GitLab.

Nachfolgende minimale Einstellungen sind für einen Betrieb erforderlich und sind im Bereich: 

production: &base
  #
  # 1. GitLab app settings
  # ==========================
 
  ## GitLab settings
  gitlab:

durchzuführen: 

  •     ## Web server settings (note: host is the FQDN, do not include http://)
    # Tachtler
    # default: host: localhost
    host: gitlab.tachtler.net

Beim Parameter host: ist anstelle von localhost ist der FQDN des noch später zu Konfigurierenden Apache HTTP Server (ohne http://// oder abschliessenden Schrägstrich) - zu setzen. 

  •     # Tachtler
    # default: port: 80 # Set to 443 if using HTTPS, see installation.md#using-https for additional HTTPS configuration details
    port: 443

Das setzen des Parameters port: kann verwirrend sein. Es handelt sich nicht um den Port, an dem der GitLab-Server (Puma) läuft, sondern um den Port, über den die Benutzer zunächst vom jeweiligen Browser aus zugreifen. 

  •     # Tachtler
    # default: https: false # Set to true if using HTTPS, see installation.md#using-https for additional HTTPS configuration details
    https: true

Beim Parameter https: ist dieser auf true zu setzen, da später eine Konfiguration des Apache HTTP Server mit SSL-Unterstützung erfolgt. 

  •     ## Date & Time settings
    # Uncomment and customize if you want to change the default time zone of GitLab application.
    # To see all available zones, run `bundle exec rake time:zones:all RAILS_ENV=production`
    # Tachtler                                                                                                                                                                                                                                
    # default: # time_zone: 'UTC'
    time_zone: 'Europe/Berlin'

Hier kann mit dem Parameter time_zone die Zeitzone gesetzt werden, wenn diese nicht in UTC angezeigt werden soll. 

  •   ## Uploads (attachments, avatars, etc...)
  uploads:
    # The location where uploads objects are stored (default: public/).
    # Tachtler
    # default: storage_path: /var/lib/gitlab/public/
    storage_path: /var/lib/gitlab/

Korrektur des Verzeichnisses für uploads, da dieses standardmässig unter einem anderen Pfad angelegt wird.

/etc/webapps/gitlab/secret

Die nachfolgende Konfigurationsdatei

  • /etc/webapps/gitlab/secret

muss neu erstellt werden, da diese nicht vorhanden ist.

Diese beinhaltet einen „geheimen“ Schlüssel, welcher zu Erstellung von Authentifizierungs-Tokens usw. genutzt wird.

:!: HINWEIS - Der Inhalt sollte vertraulich behandelt werden!

Nachfolgender Befehl erstellt die Konfigurationsdatei und füllt diese gleich mit einem zufällig erstellten Schlüssel, wie nachfolgend dargestellt: 

# hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom > /etc/webapps/gitlab/secret

Der Inhalt der Datei kann mit nachfolgendem Befehl zur Ansicht gebracht werden: 

# cat /etc/webapps/gitlab/secret
4388d0e25f80f2c1629f6252858d9906422c157b4ec036c10627dd81e84bdd77eb4d978c1d8facfe30ca9d679ac14276005b1f6d0c2d74c44eea04284b766c7c

/etc/webapps/gitlab-shell/secret

Die nachfolgende Konfigurationsdatei

  • /etc/webapps/gitlab-shell/secret

muss mit Inhalt gefüllt werden, da diese nur leer vorhanden ist.

Diese beinhaltet ebenfalls einen „geheimen“ Schlüssel, welcher zu Erstellung von Authentifizierungs-Tokens usw. genutzt wird.

:!: HINWEIS - Der Inhalt sollte vertraulich behandelt werden!

Nachfolgender Befehl erstellt die Konfigurationsdatei und füllt diese gleich mit einem zufällig erstellten Schlüssel, wie nachfolgend dargestellt: 

# hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom > /etc/webapps/gitlab-shell/secret

Der Inhalt der Datei kann mit nachfolgendem Befehl zur Ansicht gebracht werden: 

# cat /etc/webapps/gitlab-shell/secret
2cddd2099c173639359eb33ae83f12bdffcc052043d47c14bf15c7a538ae32d03e8faeca450ff93faee852ae4495695ca553ccfb7001f61dd4c827c03e6694ef

/etc/webapps/gitlab/secrets.yml

Die nachfolgende Konfigurationsdatei

  • /etc/webapps/gitlab/secrets.yml

muss neu erstellt werden, da auf diese bereits ein symbolischer Link verweist!

  • /usr/share/webapps/gitlab/config/secrets.yml → /etc/webapps/gitlab/secrets.yml

Diese beinhaltet ebenfalls einen „geheimen“ Schlüssel, welcher zu Erstellung von Authentifizierungs-Tokens usw. genutzt wird.

:!: HINWEIS - Der Inhalt sollte vertraulich behandelt werden!

Als Kopiervorlage kann hier die nachfolgende Beispiel-Konfigurationsdatei wie folgt kopiert werden: 

# cp -a /usr/share/webapps/gitlab/config/secrets.yml.example /etc/webapps/gitlab/secrets.yml

Anschliessend können mit nachfolgenden Befehlen, vier verschiedene Schlüssel wie folgt generiert werden, als Vorbereitung darauf, die dann in der richtigen Sektion in der zuvor neu erstellen Konfigurationsdatei zu hinterlegen: 

# echo -n "secret_key_base: "; hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom 
secret_key_base: 68abc8be12eacf623b404dfab844c6478fa72c080e34503f3564bb71b6be5d1e7e27e99e3040a3f51cf65fccdcd394b95212ca14c8b2fdb8330b729b979fbafc
echo -n "db_key_base: "; hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom 
db_key_base: f1d6ca1a7258f735aacfc68de036c2cce9f91834b807e364922d798e3278d187a1455cc2f9322834ec89ce5ecb2e1d7dd2880708441a57a76b85e07a8f49ccb1
# echo -n "otp_key_base: "; hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom 
otp_key_base: dd0f7238e2a060a62f0b414e378e9b59eb4d20616bc79a40f533080a4bf037ef6e7dd0f14bcb89c535df3f7150b06e851c498d7c8f9b4e3e2696ff7d95b8db43
# echo -n "openid_connect_signing_key: "; hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom 
openid_connect_signing_key: 7fa9960002957035e677f355c4833c57ae7840b793db87d1fbbf3ecaf327aa04d533de3bea8356d2d31dd9e4115073866f722992189767e7bb76bba013143a32

Diese sind dann wie folgt in die Konfigurationsdatei /etc/webapps/gitlab/secrets.yml zu integrieren, wie nachfolgende komplette Konfigurationsdatei zeigt: 

# vim /etc/webapps/gitlab/secrets.yml
production:
  # db_key_base is used to encrypt for Variables. Ensure that you don't lose it.
  # If you change or lose this key you will be unable to access variables stored in database.
  # Make sure the secret is at least 32 characters and all random,
  # no regular words or you'll be exposed to dictionary attacks.
  # db_key_base:
  secret_key_base: 68abc8be12eacf623b404dfab844c6478fa72c080e34503f3564bb71b6be5d1e7e27e99e3040a3f51cf65fccdcd394b95212ca14c8b2fdb8330b729b979fbafc
  db_key_base: f1d6ca1a7258f735aacfc68de036c2cce9f91834b807e364922d798e3278d187a1455cc2f9322834ec89ce5ecb2e1d7dd2880708441a57a76b85e07a8f49ccb1
  otp_key_base: dd0f7238e2a060a62f0b414e378e9b59eb4d20616bc79a40f533080a4bf037ef6e7dd0f14bcb89c535df3f7150b06e851c498d7c8f9b4e3e2696ff7d95b8db43
  openid_connect_signing_key: 7fa9960002957035e677f355c4833c57ae7840b793db87d1fbbf3ecaf327aa04d533de3bea8356d2d31dd9e4115073866f722992189767e7bb76bba013143a32

development:
  db_key_base: development

test:
  db_key_base: test

/etc/webapps/gitlab/resque.yml

Die nachfolgende Konfigurationsdatei

  • /etc/webapps/gitlab/resque.yml

muss ergänzt werden, da auf diese bereits ein symbolischer Link verweist!

  • /usr/share/webapps/gitlab/config/resque.yml → /etc/webapps/gitlab/resque.yml

Diese beinhaltet socket-Konfigurationen, welche zum Redis-Datenstruktur-Server eine Verbindung ermöglichen.

Die 'nderungen sind dann wie folgt in die Konfigurationsdatei /etc/webapps/gitlab/resque.yml zu integrieren, wie nachfolgende komplette Konfigurationsdatei zeigt: 

# vim /etc/webapps/gitlab/resque.yml
# If you change this file in a merge request, please also create
# a merge request on https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests
#
development:
  # Tachtler
  # default: url: redis://localhost:6379
  url: unix:/run/redis/redis.sock
  # ssl_params:
  #   ca_path: "/path/to/dir/with/certs"
  #   ca_file: "/path/to/ca.crt"
  #   cert_file: "/path/to/client.crt"
  #   key_file: "/path/to/client.key"
  # sentinels:
  #   -
  #     host: localhost
  #     port: 26380 # point to sentinel, not to redis port
  #   -
  #     host: replica2
  #     port: 26381 # point to sentinel, not to redis port
test:
  # Tachtler
  # default: url: redis://localhost:6379
  url: unix:/run/redis/redis.sock
production:
  # Redis (single instance)
  # Tachtler
  # default: url: unix:/var/run/redis/redis.sock
  url: unix:/run/redis/redis.sock
  ##
  # Redis + Sentinel (for HA)
  #
  # Please read instructions carefully before using it as you may lose data:
  # http://redis.io/topics/sentinel
  #
  # You must specify a list of a few sentinels that will handle client connection
  # please read here for more information: https://docs.gitlab.com/ee/administration/redis/index.html
  ##
  # url: redis://master:6379
  # sentinels:
  #   -
  #     host: replica1
  #     port: 26379 # point to sentinel, not to redis port
  #   -
  #     host: replica2
  #     port: 26379 # point to sentinel, not to redis port

/etc/webapps/gitlab/database.yml

Die nachfolgende Konfigurationsdatei

  • /etc/webapps/gitlab/database.yml

muss ergänzt werden, da auf diese bereits ein symbolischer Link verweist!

  • /usr/share/webapps/gitlab/config/database.yml → /etc/webapps/gitlab/database.yml

Diese beinhaltet socket-Konfigurationen, welche zur PostgreSQL-Datenbank eine Verbindung ermöglichen.

Die Änderungen sind dann wie folgt in die Konfigurationsdatei /etc/webapps/gitlab/database.yml zu integrieren, wie nachfolgende komplette Konfigurationsdatei zeigt: 

# vim /etc/webapps/gitlab/database.yml
#
# PRODUCTION
#
production:
  main:
    adapter: postgresql
    encoding: unicode
    database: gitlabhq_production
    username: gitlab
    # Tachtler
    # default: password: "secure password"
    password: "geheim"
    # Tachtler
    # default: host: localhost
    socket: /run/postgresql/.s.PGSQL.5432
    # load_balancing:
    #   hosts:
    #     - host1.example.com
    #     - host2.example.com
    #   discover:
    #     nameserver: 1.2.3.4
    #     port: 8600
    #     record: secondary.postgresql.service.consul
    #     interval: 300
  # Tachtler - NEW - 
  ci:
    adapter: postgresql
    encoding: unicode
    database: gitlabhq_production
    username: gitlab
    password: "geheim"
    socket: /run/postgresql/.s.PGSQL.5432
    database_tasks: false
 
#
# Development specific
#
development:
  main:
    adapter: postgresql
    encoding: unicode
    database: gitlabhq_development
    username: postgres
    password: "secure password"
    host: localhost
    variables:
      statement_timeout: 15s
    # Tachtler - NEW -
    database_tasks: false
 
#
# Staging specific
#
staging:
  main:
    adapter: postgresql
    encoding: unicode
    database: gitlabhq_staging
    username: gitlab
    password: "secure password"
    host: localhost
    # Tachtler - NEW -
    database_tasks: false
 
# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test: &test
  main:
    adapter: postgresql
    encoding: unicode
    database: gitlabhq_test
    username: postgres
    password:
    host: localhost
    prepared_statements: false
    reaping_frequency: nil
    variables:
      statement_timeout: 15s
    # Tachtler - NEW -
    database_tasks: false

:!: WICHTIG - Seit GitLab Version 15.9 ist die Konfigurationsatei /etc/webapps/gitlab/database.yml, wenn diese nur einen Abschnitt main: enthält, veraltet.

:!: ACHTUNG - Ab GitLab Version 17.0 müssen sich zwingend in der Konfigurationsdatei /etc/webapps/gitlab/database.yml zwei Abschnitte befinden! - : main: und ci:. Die ci:-Verbindung muss mit der gleichen Datenbank wie auch bei main: konfiguriert bestehen!

:!: HINWEIS - Die Abschnitte development, staging und test müssen deaktiviert werden! - Der Parameter database_tasks: false ist jeweils zu setzen!

GitLab: Datenbank erzeugen

redis.service: Status gestartet

Nachdem der Service Redis-Datenstruktur-Server

  • redis.service

bereist gestartet sein sollte, was mit nachfolgendm Befehl überprüft werden kann: 

# systemctl status redis.service
● redis.service - Advanced key-value store
     Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; preset: di>
     Active: active (running) since Wed 2024-03-20 13:34:01 CET; 4h 0min ago
   Main PID: 5253 (redis-server)
     Status: "Ready to accept connections"
      Tasks: 6 (limit: 4653)
     Memory: 7.7M (peak: 8.2M)
        CPU: 44.621s
     CGroup: /system.slice/redis.service
             └─5253 "/usr/bin/redis-server unixsocket:/run/redis/redis.sock"

Mar 20 13:34:01 server redis-server[5253]: 5253:M 20 Mar 2024 13:34:01.552 * mo>
Mar 20 13:34:01 server redis-server[5253]: 5253:M 20 Mar 2024 13:34:01.552 * Ru>
Mar 20 13:34:01 server redis-server[5253]: 5253:M 20 Mar 2024 13:34:01.552 * Se>
Mar 20 13:34:01 server redis-server[5253]: 5253:M 20 Mar 2024 13:34:01.552 * Lo>
Mar 20 13:34:01 server redis-server[5253]: 5253:M 20 Mar 2024 13:34:01.552 * RD>
Mar 20 13:34:01 server redis-server[5253]: 5253:M 20 Mar 2024 13:34:01.552 * RD>
Mar 20 13:34:01 server redis-server[5253]: 5253:M 20 Mar 2024 13:34:01.552 * Do>
Mar 20 13:34:01 server redis-server[5253]: 5253:M 20 Mar 2024 13:34:01.552 * DB>
Mar 20 13:34:01 server redis-server[5253]: 5253:M 20 Mar 2024 13:34:01.552 * Re>
Mar 20 13:34:01 server systemd[1]: Started Advanced key-value store.

gitlab-gitaly.service: Erster Start

Um die Datenbank für GitLab erzeugen zu können, ist es zum jetzigen Zeitpunkt der GitLab-Installation erforderlich den Dienst/Daemon

  • gitlab-gitaly.service

erstmals zu starten, was mit nachfolgendem Befehl durchgeführt werden kann: 

# systemctl start gitlab-gitaly.service

Ob der Start erfolgreich durchgeführt wurde, kann mit nachfolgendem Befehl überprüft werden: 

# systemctl status gitlab-gitaly.service
● gitlab-gitaly.service - Gitaly is a Git RPC service for handling all the git >
     Loaded: loaded (/usr/lib/systemd/system/gitlab-gitaly.service; disabled; p>
     Active: active (running) since Wed 2024-03-20 17:43:25 CET; 39s ago
   Main PID: 8022 (gitaly)
      Tasks: 7 (limit: 4653)
     Memory: 496.1M (peak: 496.6M)
        CPU: 3.498s
     CGroup: /system.slice/gitlab-gitaly.service
             └─8022 /usr/bin/gitaly /etc/gitlab-gitaly/config.toml

Mar 20 17:43:26 server gitlab-gitaly[8022]: time="2024-03-20T16:43:26.518Z" lev>
Mar 20 17:43:26 server gitlab-gitaly[8022]: time="2024-03-20T16:43:26.534Z" lev>
Mar 20 17:43:26 server gitlab-gitaly[8022]: time="2024-03-20T16:43:26.534Z" lev>
Mar 20 17:43:26 server gitlab-gitaly[8022]: time="2024-03-20T16:43:26.534Z" lev>
Mar 20 17:43:26 server gitlab-gitaly[8022]: time="2024-03-20T16:43:26.534Z" lev>
Mar 20 17:43:26 server gitlab-gitaly[8022]: time="2024-03-20T16:43:26.534Z" lev>
Mar 20 17:43:26 server gitlab-gitaly[8022]: time="2024-03-20T16:43:26.534Z" lev>
Mar 20 17:43:26 server gitlab-gitaly[8022]: time="2024-03-20T16:43:26.534Z" lev>
Mar 20 17:43:26 server gitlab-gitaly[8022]: time="2024-03-20T16:43:26.535Z" lev>
Mar 20 17:43:29 server gitlab-gitaly[8022]: time="2024-03-20T16:43:29.356Z" lev>

gitlab:setup: Ausführen

Anschliessend sollte mit nachfolgendem Befehl in das Verzeichnis /usr/share/webapps/gitlab gewechselt werden: 

# cd /usr/share/webapps/gitlab

Der nachfolgende Befehl, führt die Erzeugung der Datenbank für GitLab gegen die PostgreSQL-Datenbank aus: 

# sudo -u gitlab $(cat environment | xargs) bundle exec rake gitlab:setup
# sudo -u gitlab $(cat environment | xargs) bundle exec rake gitlab:setup
This will create the necessary database tables and seed the database.
You will lose any previous data stored in the database.
Do you want to continue (yes/no)? yes

Dropped database 'gitlabhq_production'
Created database 'gitlabhq_production'
INFO:  analyzing "public.p_ci_runner_machine_builds" inheritance tree
INFO:  analyzing "gitlab_partitions_dynamic.ci_runner_machine_builds_100"
INFO:  "ci_runner_machine_builds_100": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
INFO:  analyzing "gitlab_partitions_dynamic.ci_runner_machine_builds_101"
INFO:  "ci_runner_machine_builds_101": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
INFO:  analyzing "public.p_ci_job_annotations" inheritance tree
INFO:  analyzing "gitlab_partitions_dynamic.ci_job_annotations_100"
INFO:  "ci_job_annotations_100": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
INFO:  analyzing "gitlab_partitions_dynamic.ci_job_annotations_101"
INFO:  "ci_job_annotations_101": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
INFO:  analyzing "public.p_ci_builds_metadata" inheritance tree
INFO:  analyzing "public.ci_builds_metadata"
INFO:  "ci_builds_metadata": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
INFO:  analyzing "gitlab_partitions_dynamic.ci_builds_metadata_101"
INFO:  "ci_builds_metadata_101": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
INFO:  analyzing "public.p_ci_builds" inheritance tree
INFO:  analyzing "public.ci_builds"
INFO:  "ci_builds": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
INFO:  analyzing "gitlab_partitions_dynamic.ci_builds_101"
INFO:  "ci_builds_101": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows

== Seed from /usr/share/webapps/gitlab/db/fixtures/production/001_application_settings.rb
Creating the default ApplicationSetting record.

== Seed from /usr/share/webapps/gitlab/db/fixtures/production/002_admin.rb
Administrator account created:

login:    root
password: You'll be prompted to create one on your first visit.


== Seed from /usr/share/webapps/gitlab/db/fixtures/production/003_create_base_work_item_types.rb

OK

== Seed from /usr/share/webapps/gitlab/db/fixtures/production/004_add_security_training_providers.rb

OK

== Seed from /usr/share/webapps/gitlab/db/fixtures/production/010_settings.rb
Saved CI JWT signing key

== Seed from /usr/share/webapps/gitlab/db/fixtures/production/020_create_work_item_hierarchy_restrictions.rb

OK

== Seed from /usr/share/webapps/gitlab/db/fixtures/production/030_default_organization.rb

OK

== Seed from /usr/share/webapps/gitlab/db/fixtures/production/040_create_work_item_related_link_restrictions.rb

OK

gitlab:env:info: Ausführen

Falls nicht bereits geschehen, sollte mit nachfolgendem Befehl in das Verzeichnis /usr/share/webapps/gitlab gewechselt werden: 

# cd /usr/share/webapps/gitlab

Der nachfolgende Befehl, listet Informationen über die installierten Komponenten und deren Versionen von GitLab auf: 

# sudo -u gitlab $(cat environment | xargs) bundle exec rake gitlab:env:info
# sudo -u gitlab $(cat environment | xargs) bundle exec rake gitlab:env:info

System information
System:		
Current User:	gitlab
Using RVM:	no
Ruby Version:	3.0.6p216
Gem Version:	3.3.25
Bundler Version:2.5.4
Rake Version:	13.0.6
Redis Version:	7.2.4
Sidekiq Version:7.1.6
Go Version:	go1.22.1 linux/amd64

GitLab information
Version:	16.9.2
Revision:	8443896c867
Directory:	/usr/share/webapps/gitlab
DB Adapter:	PostgreSQL
DB Version:	16.2
URL:		https://gitlab.tachtler.net
HTTP Clone URL:	https://gitlab.tachtler.net/some-group/some-project.git
SSH Clone URL:	gitlab@gitlab.tachtler.net:some-group/some-project.git
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers: 

GitLab Shell
Version:	14.34.0
Repository storages:
- default: 	unix:/run/gitlab/gitlab-gitaly.socket
GitLab Shell path:		/usr/share/webapps/gitlab-shell

Gitaly
- default Address: 	unix:/run/gitlab/gitlab-gitaly.socket
- default Version: 	16.9.2
- default Git Version: 	2.44.0

GitLab: Repository - Dateirechte setzen

Zum Abschluss der GitLab-Konfiguration, müssen noch die Datei-rechte des Repository-Verzeichnisses

  • /var/lib/gitlab/repositories/

angepasst werden:

Nachfolgende Befehle müssen ausgeführt werden, um zu gewährleisten, dass

  1. der GitLab-Benutzer, und
  2. die GitLab-Gruppe

volle Zugriffsrechte haben und ohne das das SUID-bit gesetzte ist!

(Eine Datei mit SUID-bit wird immer als der Benutzer ausgeführt, der der Eigentümer der Datei ist, unabhängig davon, welcher Benutzer den Befehl ausgeführt hat.)

Datei-rechte setzen: 

# chmod -R ug+rwX,o-rwx /var/lib/gitlab/repositories/

und SUID-bit entfernen: 

# chmod -R ug-s /var/lib/gitlab/repositories

Eine Suche innerhalb des Verzeichnisses, nach einem gesetzten SUID-bit, kann mit nachfolgendem Befehl ausgeführt werden und sollte kein Ergebnis zum Vorschein bringen: 

# find /var/lib/gitlab/repositories/ -type d -print0 | xargs -0 chmod g+s

GitLab: Ziel/Target-Start einrichten

Um GitLab, welches als Ziel/Target als Hintergrundprozess läuft, auch nach einem Neustart des Servers zur Verfügung zu haben, soll der Dienst/Daemon mit dem Server mit gestartet werden, was mit nachfolgendem Befehl realisiert werden kann: 

# systemctl enable gitlab.target
Created symlink /etc/systemd/system/multi-user.target.wants/gitlab.target → /usr/lib/systemd/system/gitlab.target.

Eine Überprüfung, ob beim Neustart des Server der gitlab-Ziel/Target wirklich mit gestartet wird, kann mit nachfolgendem Befehl erfolgen und sollte eine Anzeige, wie ebenfalls nachfolgend dargestellt ausgeben: 

# systemctl list-unit-files --type=target | grep -e gitlab.target
gitlab.target                 enabled  disabled
bzw.
<code>
# systemctl is-enabled gitlab.target
enabled

GitLab: Erster Start

Mit nachfolgendem Befehl wird GitLab gestartet.

Dieser systemd-Start beinhaltet auch den Start alle anderen benötigten Komponenten bzw. Dienste/Daemons von GitLab. 

# systemctl start gitlab.target

Eine Überprüfung, ob der Start des Ziel/Target erfolgreich war, kann mit nachfolgendem Befehl überprüft werden: 

# systemctl status gitlab.target
● gitlab.target - GitLab - Self Hosted Git Management
     Loaded: loaded (/usr/lib/systemd/system/gitlab.target; enabled; preset: disabled)
     Active: active since Thu 2024-03-21 07:36:18 CET; 5s ago

Mar 21 07:36:18 server systemd[1]: Reached target GitLab - Self Hosted Git Management.

GitLab: Erste Anmeldung

Nach erfolgreichem Start von GitLab kann über einen Browser die nachfolgende URL aufgerufen werden, um die Startseite von GitLab zu erreichen:

Nachfolgender Bildschirm sollte beim ersten Aufruf von GitLab zu sehen sein. Es ist zwingend erforderlich für den Benutzer root ein Passwort zu setzen:

GitLab - Erste Anmeldung - Aufforderung zur Passwort Änderung

Nachdem das Passwort erfolgreich gesetzt wurde, wird dies am Bildschirm angezeigt und eine Anmeldung als Benutzer root sollte nun möglich sein:

GitLab - Erste Anmeldung - Passwort erfolgreich geändert

Feld Eingabe
Benutzername oder primäre E-Mail-Adresse root
Passwort [Aus dem vorherigem Dialog!]

Nachfolgender Bildschirm sollte nun nach der ersten erfolgreichen Anmeldung zum Vorschein kommen. Hier wird gleich nach einer wichtige Einstellung verlangt:

Check your sign-up restrictions Your GitLab instance allows anyone to register for an account, which is a security risk on public-facing GitLab instances. You should deactivate new sign ups if public users aren't expected to register for an account.

Überprüfen Sie Ihre Anmeldebeschränkungen Ihre GitLab-Instanz erlaubt es jedem, sich für ein Konto zu registrieren, was bei öffentlich zugänglichen GitLab-Instanzen ein Sicherheitsrisiko darstellt. Sie sollten neue Anmeldungen deaktivieren, wenn von öffentlichen Benutzern nicht erwartet wird, dass sie sich für ein Konto registrieren.

GitLab - Erste Anmeldung - Registrierung deaktivieren

Es sollte die Schaltfläche [Deactivate] mit der [linken Maustaste] gedrückt werden, wodurch sich der Bildschirminhalt wie folgt anpassen sollte:

GitLab - Erste Anmeldung - Administrations-Bereich - Registrierung deaktivieren

Hier kann nun die getroffene Entscheidung eingestellt werden. Als Beispiel sollen hier nachfolgende Einstellungen umgesetzt werden:

Auswahl Feld Beschreibung
[ ] Sign-up enabled
Anmeldung möglich 		Any user that visits https://gitlab.tachtler.net/users/sign_in can create an account.
Jeder Benutzer, der https://gitlab.tachtler.net/users/sign_in besucht, kann ein Konto erstellen.

Nachfolgender Bildschirm zeigt das deaktivierte Kästchen bei Sign-up enabled:

GitLab - Erste Anmeldung - Administrations-Bereich - Registrierung deaktiviert

Nachfolgend und in Abhängigkeit der jeweiligen Bildschirmgrösse, ist es ggf. erforderlich mit dem [Mausrad] oder mit der [linken Maustaste] und dem Browser-[Scrollbalken] nach unten in der Seite zu navigieren, um die zum Abschnitt gehörende Schaltfläche [Save changes] zu finden. Diese ist dann mit der [linken Maustaste] zu drücken, um die Änderungen zu speichern.

GitLab - Erste Anmeldung - Administrations-Bereich - Anmelde-Einstellungen - speichern

Wenn die geänderten Einstellungen erfolgreich gespeichert wurden, sollte nachfolgender Bildschirm erscheinen:

GitLab - Erste Anmeldung - Administrations-Bereich - Anmelde-Einstellungen - gespeichert

Zum Abschluss kann nun über das Administrations-Menü aus dem sich öffnenden Menü-Bereich der Menüpunkt [Sign out] mit der [linken Maustaste] ausgewählt und gedrückt werden, wie auf nachfolgendem Bildschirm dargestellt:

GitLab - Erste Anmeldung - Administrations-Bereich - Administrations-Menü - abmelden

Abschliessend nach erfolgreicher Abmeldung, sollte dann der nachfolgende Anmeldebildschirm wieder erscheinen, wie nachfolgende dargestellt:

GitLab - Erste Anmeldung - Anmeldebildschirm

GitLab: Erweiterte Konfigurationen

Nachfolgende interne Links führen der erweiterten Konfiguration von GitLab, welche da wären:

GitLab: LDAP-Konfiguration

Die erweiterten Konfiguration von GitLab befindet sich unter den nachfolgendem internen Link:

GitLab: Backup

Die erweiterten Konfiguration von GitLab befindet sich unter den nachfolgendem internen Link:

GitLab: Restore

Die erweiterten Konfiguration von GitLab befindet sich unter den nachfolgendem internen Link:

GitLab: Upgrade/Update

Die erweiterten Konfiguration von GitLab befindet sich unter den nachfolgendem internen Link:

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
tachtler/gitlab_archlinux.txt · Zuletzt geändert: 2024/03/23 18:56 von klaus