Benutzer-Werkzeuge

Webseiten-Werkzeuge


tachtler:gitlab_centos_7

GitLab CentOS 7

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.

Gitlab gibt es ebenfalls in einer kostenpflichtigen Enterprise Edition

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 sind folgende Komponenten erforderlich:

Nachfolgende rpm-Pakete sind als Abhängigkeit erforderlich und werden ebenfalls benötigt:

  • curl - ist im base-Repository von CentOS enthalten und normalerweise bereits installiert
  • sshd - ist im base-Repository von CentOS enthalten, normalerweise bereits installiert und standardmäßig gestartet
  • postfix - ist im base-Repository von CentOS enthalten, normalerweise bereits installiert und standardmäßig gestartet

iptables Regel

Damit der Gitlab-Server auch erreichbar ist und nicht die Web-Anfragen vom Paketfilter iptables blockiert werden, müssen nachfolgende Regeln zum iptables-Regelwerk hinzugefügt werden.

Um die aktuellen iptables-Regeln erweitern zu können, sollten diese erst einmal aufgelistet werden, was mit nachfolgendem Befehl durchgeführt werden kann:

# iptables -L -nv --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out   source       destination         
1     1562 1266K ACCEPT     all  --  *      *     0.0.0.0/0    0.0.0.0/0      state RELATED,ESTABLISHED 
2        0     0 ACCEPT     icmp --  *      *     0.0.0.0/0    0.0.0.0/0           
3        0     0 ACCEPT     all  --  lo     *     0.0.0.0/0    0.0.0.0/0           
4        1    60 ACCEPT     tcp  --  *      *     0.0.0.0/0    0.0.0.0/0      state NEW tcp dpt:22 
5       39  1248 REJECT     all  --  *      *     0.0.0.0/0    0.0.0.0/0      reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out   source       destination         
1        0     0 REJECT     all  --  *      *     0.0.0.0/0    0.0.0.0/0      reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out   source       destination

Nachfolgender Befehl, fügt folgende iptables-Regeln dem iptables-Regelwerk nach der Position 5 hinzu, ohne das der Paketfilter angehalten werden muss:

  • -A INPUT -p tcp --dport 80 -j ACCEPT
  • -A INPUT -p tcp --dport 443 -j ACCEPT

und hier die Befehle:

# iptables -I INPUT 5 -p tcp --dport 80 -j ACCEPT
# iptables -I INPUT 5 -p tcp --dport 443 -j ACCEPT

Eine erneute Abfrage des iptables-Regelwerts, sollte dann nachfolgend dargestellte Ausgabe ergeben, was mit folgendem Befehl durchgeführt werden kann:

# iptables -L -nv --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out   source       destination         
1       70  5752 ACCEPT     all  --  *      *     0.0.0.0/0    0.0.0.0/0      state RELATED,ESTABLISHED 
2        0     0 ACCEPT     icmp --  *      *     0.0.0.0/0    0.0.0.0/0           
3        0     0 ACCEPT     all  --  lo     *     0.0.0.0/0    0.0.0.0/0           
4        0     0 ACCEPT     tcp  --  *      *     0.0.0.0/0    0.0.0.0/0      state NEW tcp dpt:22 
5        0     0 ACCEPT     tcp  --  *      *     0.0.0.0/0    0.0.0.0/0      tcp dpt:80
6        0     0 ACCEPT     tcp  --  *      *     0.0.0.0/0    0.0.0.0/0      tcp dpt:443  
7        0     0 REJECT     all  --  *      *     0.0.0.0/0    0.0.0.0/0      reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out   source       destination         
1        0     0 REJECT     all  --  *      *     0.0.0.0/0    0.0.0.0/0      reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out   source       destination

Die neuen Zeilen ist an Position 5 (INPUT) und Position 6 (INPUT) zu sehen, hier nachfolgend zur Verdeutlichung noch einmal dargestellt (nur relevanter Ausschnitt):

...
5        0     0 ACCEPT     tcp  --  *      *     0.0.0.0/0    0.0.0.0/0      tcp dpt:80
6        0     0 ACCEPT     tcp  --  *      *     0.0.0.0/0    0.0.0.0/0      tcp dpt:443
...

Um diese iptables-Regel dauerhaft, auch nach einem Neustart des Server, weiterhin im iptables-Regelwerk zu speichern, muss nachfolgend dargestellter Befehl abschließend noch ausgeführt werden:

# /usr/sbin/iptables-save > /etc/sysconfig/iptables 

Vorbereitung

Die Installation kann auf zwei Wegen erfolgen

  1. Manuelle Auswahl und Installation des herunterzuladenden Pakets unter nachfolgendem externen Link:
  2. Herunterladen eines für CentOS in der Version 7.x vorbereiteten Installations-Skripts, mit direkter Ausführung in einem Befehl (Nachfolgend der Speicherort des Installations-Skripts)
    1. Es wird automatisch eines neues Repository unter /etc/yum.repos.d mit dem Namen gitlab_gitlab-ce.repo erstellt
    2. Die automatische Installation, erfolgt dann aus diesem neu eingebundenen Repository - gitlab_gitlab-ce.repo

:!: WICHTIG - Zur Installation mit der Variante 2 wird eine Internet-Verbindung des Servers benötigt!

Installation

Nachfolgend soll eine Installation von Gitlab via Herunterladen eines für CentOS in der Version 7.x vorbereiteten Installations-Skripts, mit direkter Ausführung in einem Befehl - auch Gitlab CE Omnibus“-Installation genannt, durchgeführt werden.

Nachfolgende Schritte, werden durch das Skript script.rpm.sh zur Installation von Gitlab durchgeführt:

  1. Ermittlung des Betriebssystems
  2. Überprüfung der Befehl curl vorhanden ist (ggf. unnötig, da curl schon beim Befehlsaufruf verwendet wird), ggf. wird curl installiert
  3. Ermittlung des Host-Namens
  4. Einrichten eines neuen Repositorys unter etc/yum.repos.d/gitlab_gitlab-ce.repo
  5. Installation des rpm-Paktes pygpgme, welches zur Überprüfung von GPG-Signaturen benötigt wird
  6. Installation des rpm-Paktes yum-utils, welches zur Verwaltung von rpm-Paketen benötigt wird
  7. Erstellen von cache-Informationen für das neu Installierte Repository unter etc/yum.repos.d/gitlab_gitlab-ce.repo

Nachfolgender Befehl, kann dann zur Installation von Gitlab ausgeführt werden:

# curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash

Ausführung:

# curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  5095    0  5095    0     0   4013      0 --:--:--  0:00:01 --:--:--  4021
Detected centos version 7... 
Checking for curl...
Detected curl...
Getting the hostname of this machine...
Found hostname: serverC8.tachtler.net
Downloading repository file: https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/config_file.repo?os=centos&dist=7&name=serverC8.tachtler.net&source=script
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   499    0   499    0     0    386      0 --:--:--  0:00:01 --:--:--   387
done.
Installing pygpgme to verify GPG signatures...
Loaded plugins: changelog, priorities
gitlab_gitlab-ce-source/signature                        |  836 B     00:00     
Retrieving key from https://packages.gitlab.com/gpg.key
Importing GPG key 0xE15E78F4:
 Userid     : "GitLab B.V. (package repository signing key) <packages@gitlab.com>"
 Fingerprint: 1a4c 919d b987 d435 9396 38b9 1421 9a96 e15e 78f4
 From       : https://packages.gitlab.com/gpg.key
gitlab_gitlab-ce-source/signature                        |  951 B     00:00 !!! 
gitlab_gitlab-ce-source/primary                            |  175 B   00:02     
65 packages excluded due to repository priority protections
Package pygpgme-0.3-9.el7.x86_64 already installed and latest version
Nothing to do
Installing yum-utils...
Loaded plugins: changelog, priorities
65 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package yum-utils.noarch 0:1.1.31-29.el7 will be installed
--> Processing Dependency: python-kitchen for package: yum-utils-1.1.31-29.el7.noarch
--> Running transaction check
---> Package python-kitchen.noarch 0:1.1.1-5.el7 will be installed
--> Processing Dependency: python-chardet for package: python-kitchen-1.1.1-5.el7.noarch
--> Running transaction check
---> Package python-chardet.noarch 0:2.2.1-1.el7_1 will be installed
--> Finished Dependency Resolution

Changes in packages about to be updated:


Dependencies Resolved

================================================================================
 Package               Arch          Version               Repository      Size
================================================================================
Installing:
 yum-utils             noarch        1.1.31-29.el7         base           112 k
Installing for dependencies:
 python-chardet        noarch        2.2.1-1.el7_1         updates        227 k
 python-kitchen        noarch        1.1.1-5.el7           base           267 k

Transaction Summary
================================================================================
Install  1 Package (+2 Dependent packages)

Total download size: 606 k
Installed size: 2.8 M
Downloading packages:
warning: /var/cache/yum/x86_64/7/updates/packages/python-chardet-2.2.1-1.el7_1.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
Public key for python-chardet-2.2.1-1.el7_1.noarch.rpm is not installed
(1/3): python-chardet-2.2.1-1.el7_1.noarch.rpm             | 227 kB   00:00     
Public key for python-kitchen-1.1.1-5.el7.noarch.rpm is not installed
(2/3): python-kitchen-1.1.1-5.el7.noarch.rpm               | 267 kB   00:00     
(3/3): yum-utils-1.1.31-29.el7.noarch.rpm                  | 112 kB   00:00     
--------------------------------------------------------------------------------
Total                                              1.6 MB/s | 606 kB  00:00     
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Importing GPG key 0xF4A80EB5:
 Userid     : "CentOS-7 Key (CentOS 7 Official Signing Key) <security@centos.org>"
 Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5
 Package    : centos-release-7-1.1503.el7.centos.2.8.x86_64 (@anaconda)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : python-chardet-2.2.1-1.el7_1.noarch                          1/3 
  Installing : python-kitchen-1.1.1-5.el7.noarch                            2/3 
  Installing : yum-utils-1.1.31-29.el7.noarch                               3/3 
  Verifying  : python-chardet-2.2.1-1.el7_1.noarch                          1/3 
  Verifying  : python-kitchen-1.1.1-5.el7.noarch                            2/3 
  Verifying  : yum-utils-1.1.31-29.el7.noarch                               3/3 

Installed:
  yum-utils.noarch 0:1.1.31-29.el7                                              

Dependency Installed:
  python-chardet.noarch 0:2.2.1-1.el7_1   python-kitchen.noarch 0:1.1.1-5.el7  

Complete!
Generating yum cache for gitlab_gitlab-ce...
Importing GPG key 0xE15E78F4:
 Userid     : "GitLab B.V. (package repository signing key) <packages@gitlab.com>"
 Fingerprint: 1a4c 919d b987 d435 9396 38b9 1421 9a96 e15e 78f4
 From       : https://packages.gitlab.com/gpg.key

Zur Installation von Gitlab wird nachfolgendes Paket benötigt:

  • gitlab-ce - ist im gitlab_gitlab-ce-Repository des Drittanbieters Gitlab enthalten

Mit nachfolgendem Befehl, wird das Pakete gitlab-ce installiert:

# yum install gitlab-ce
Loaded plugins: changelog, priorities
65 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package gitlab-ce.x86_64 0:7.13.4-ce.0.el7 will be installed
--> Finished Dependency Resolution

Changes in packages about to be updated:


Dependencies Resolved

================================================================================
 Package        Arch        Version                 Repository             Size
================================================================================
Installing:
 gitlab-ce      x86_64      7.13.4-ce.0.el7         gitlab_gitlab-ce      321 M

Transaction Summary
================================================================================
Install  1 Package

Total download size: 321 M
Installed size: 889 M
Is this ok [y/d/N]: y
gitlab-ce-7.13.4-ce.0.el7.x86_64.rpm                       | 321 MB   00:46     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : gitlab-ce-7.13.4-ce.0.el7.x8 [############################ ] 1/1
  Installing : gitlab-ce-7.13.4-ce.0.el7.x86_64                             1/1 
gitlab: Thank you for installing GitLab!
gitlab: To configure and start GitLab, RUN THE FOLLOWING COMMAND:

sudo gitlab-ctl reconfigure

gitlab: GitLab should be reachable at http://serverC8.tachtler.net
gitlab: Otherwise configure GitLab for your system by editing /etc/gitlab/gitlab.rb file
gitlab: And running reconfigure again.
gitlab: 
gitlab: For a comprehensive list of configuration options please see the Omnibus GitLab readme
gitlab: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md
gitlab: 
It looks like GitLab has not been installed yet; skipping the upgrade script.
  Verifying  : gitlab-ce-7.13.4-ce.0.el7.x86_64                             1/1 

Installed:
  gitlab-ce.x86_64 0:7.13.4-ce.0.el7                                            

Complete!

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

(Gekürzter Ausschnitt):

# rpm -qil gitlab-ce
Name        : gitlab-ce
Version     : 7.13.4
Release     : ce.0.el7
Architecture: x86_64
Install Date: Wed 12 Aug 2015 03:48:04 PM CEST
Group       : default
Size        : 931955017
License     : unknown
Signature   : (none)
Source RPM  : gitlab-ce-7.13.4-ce.0.el7.src.rpm
Build Date  : Fri 07 Aug 2015 11:11:12 AM CEST
Build Host  : centos7-4-omnibus.gitlap.com
Relocations : / 
Packager    : GitLab B.V.
Vendor      : Omnibus <omnibus@getchef.com>
URL         : https://about.gitlab.com/
Summary     : GitLab Community Edition and GitLab CI (including NGINX, Postgres,
 Redis)
Description :
GitLab Community Edition and GitLab CI (including NGINX, Postgres, Redis)
/opt/gitlab
/opt/gitlab/bin
/opt/gitlab/bin/chef-apply
...
...
...
/opt/gitlab/etc
/opt/gitlab/etc/gitlab.rb.template
/opt/gitlab/init
/opt/gitlab/service
/opt/gitlab/sv
/opt/gitlab/version-manifest.json
/opt/gitlab/version-manifest.txt

Nach der Installation, muss zur Erstellung weiterer Konfigurationen nachfolgender Befehl ausgeführt werden:

(Gekürzte Ausschnitt):

# gitlab-ctl reconfigure
Starting Chef Client, version 12.4.0.rc.2
resolving cookbooks for run list: ["gitlab"]
Synchronizing Cookbooks:
  - package
  - runit
  - gitlab
Compiling Cookbooks...
Recipe: gitlab::default
  * directory[/etc/gitlab] action create
    - change mode from '0755' to '0775'
...
...
...
Running handlers:
Running handlers complete
Chef Client finished, 172/194 resources updated in 105.332061711 seconds
gitlab Reconfigured!

Folgender Benutzer wurde ebenfalls angelegt, was mit folgendem Befehl überprüft werden kann:

# cat /etc/passwd | grep git
gitlab-www:x:400:400::/var/opt/gitlab/nginx:/bin/false
git:x:399:399::/var/opt/gitlab:/bin/sh
gitlab-redis:x:398:398::/var/opt/gitlab/redis:/bin/nologin
gitlab-psql:x:397:397::/var/opt/gitlab/postgresql:/bin/sh

Desweiteren wurden auch folgende Gruppen angelegt, was mit folgendem Befehl überprüft werden kann:

# cat /etc/group | grep git
gitlab-www:x:400:
git:x:399:
gitlab-redis:x:398:
gitlab-psql:x:397:

Um das Starten von Gitlab auch nach einem System-(re)-start auch in Zukunft dauerhaft zu realisieren, wurden nachfolgende systmed-Services während der Installation angelegt, was mit nachfolgendem Befehl überprüft werden kann:

# systemctl list-unit-files -t service | grep git
gitlab-runsvdir.service                enabled

Nachfolgende Dienste sind nun gestartet, welche mit nachfolgenden Befehlen abgefragt werden können:

# systemctl status gitlab-runsvdir.service
gitlab-runsvdir.service - GitLab Runit supervision process
   Loaded: loaded (/usr/lib/systemd/system/gitlab-runsvdir.service; enabled)
   Active: active (running) since Wed 2015-08-12 16:02:40 CEST; 11min ago
 Main PID: 2589 (runsvdir)
   CGroup: /system.slice/gitlab-runsvdir.service
           ├─2589 runsvdir -P /opt/gitlab/service log: ......................................................................................................
           ├─2609 runsv redis
           ├─2610 svlogd -tt /var/log/gitlab/redis
           ├─2611 /opt/gitlab/embedded/bin/redis-server 127.0.0.1:0
           ├─2690 runsv postgresql
           ├─2691 svlogd -tt /var/log/gitlab/postgresql
           ├─2692 /opt/gitlab/embedded/bin/postgres -D /var/opt/gitlab/postgresql/data
           ├─2696 postgres: checkpointer process   
           ├─2697 postgres: writer process   
           ├─2698 postgres: wal writer process   
           ├─2699 postgres: autovacuum launcher process   
           ├─2700 postgres: stats collector process   
           ├─2748 runsv unicorn
           ├─2749 svlogd -tt /var/log/gitlab/unicorn
           ├─2750 /bin/bash /opt/gitlab/embedded/bin/gitlab-unicorn-wrapper
           ├─2781 unicorn master -D -E production -c /var/opt/gitlab/gitlab-rails/etc/unicorn.rb /opt/gitlab/embedded/service/gitlab-rails/config.ru
           ├─2784 runsv sidekiq
           ├─2785 svlogd -tt /var/log/gitlab/sidekiq
           ├─2786 sidekiq 3.3.0 gitlab-rails [0 of 25 busy]
           ├─2799 runsv nginx
           ├─2800 svlogd -tt /var/log/gitlab/nginx
           ├─2801 nginx: master process /opt/gitlab/embedded/sbin/nginx -p /var/opt/gitlab/nginx
           ├─2802 nginx: worker process
           ├─2803 nginx: worker process
           ├─2810 postgres: gitlab gitlabhq_production [local] idle
           ├─2811 unicorn worker[0] -D -E production -c /var/opt/gitlab/gitlab-rails/etc/unicorn.rb /opt/gitlab/embedded/service/gitlab-rails/config.ru
           ├─2813 unicorn worker[1] -D -E production -c /var/opt/gitlab/gitlab-rails/etc/unicorn.rb /opt/gitlab/embedded/service/gitlab-rails/config.ru
           ├─2817 unicorn worker[2] -D -E production -c /var/opt/gitlab/gitlab-rails/etc/unicorn.rb /opt/gitlab/embedded/service/gitlab-rails/config.ru
           ├─2826 runsv logrotate
           ├─2827 svlogd -tt /var/log/gitlab/logrotate
           ├─2828 /bin/sh ./run
           ├─2829 sleep 600
           ├─2848 postgres: gitlab gitlabhq_production [local] idle
           ├─2882 postgres: gitlab gitlabhq_production [local] idle
           └─3534 sleep 1

Aug 12 16:02:40 serverC8.tachtler.net systemd[1]: Started GitLab Runit supervision process.

bzw.

# netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address        Foreign Address    State       User    Inode      PID/Program name    
tcp        0      0 127.0.0.1:8080       0.0.0.0:*          LISTEN      399     19123      2781/unicorn master 
tcp        0      0 0.0.0.0:80           0.0.0.0:*          LISTEN      0       19097      2801/nginx: master  
tcp        0      0 0.0.0.0:22           0.0.0.0:*          LISTEN      0       14990      861/sshd            
tcp        0      0 127.0.0.1:25         0.0.0.0:*          LISTEN      0       15889      1841/master         
udp        0      0 192.168.0.200:123    0.0.0.0:*                      38      15990      637/ntpd            
udp        0      0 127.0.0.1:123        0.0.0.0:*                      0       14567      637/ntpd

Update durchführen

:!: HINWEIS - Nach einer neuen Installation sind keine Updates zu installieren !.

Aber im laufe der Zeit wird es Updates geben. Bei einem Update sind jedoch weitere Arbeiten durchzuführen, welche normalerweise bei sonstiges Updates von rpm-Paketen nicht durchzuführen sind.

Anhand nachfolgendem Update, soll eine möglicher Update-Prozess beispielhaft durchgeführt werden.

Mit nachfolgendem Befehl kann überprüft werden, ob Updates für Gitlab verfügbar sind, was sich von anderen rpm-Paket Updates noch nicht unterscheidet:

# yum check-update
Loaded plugins: changelog, priorities
65 packages excluded due to repository priority protections

gitlab-ce.x86_64                7.13.5-ce.0.el7                 gitlab_gitlab-ce

Wie nach oben gezeigtem Befehl zu sehen ist, ist ein Update verfügbar.

Mit nachfolgendem Befehl kann nun das Update, wie auch bei anderen rpm-Paketen, durchgeführt werden:

# yum update
Loaded plugins: changelog, priorities
65 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package gitlab-ce.x86_64 0:7.13.4-ce.0.el7 will be updated
---> Package gitlab-ce.x86_64 0:7.13.5-ce.0.el7 will be an update
--> Finished Dependency Resolution

Changes in packages about to be updated:

gitlab_gitlab-ce/x86_64/other                            | 1.1 kB     00:00     
** No ChangeLog for: gitlab-ce-7.13.5-ce.0.el7.x86_64


Dependencies Resolved

================================================================================
 Package        Arch        Version                 Repository             Size
================================================================================
Updating:
 gitlab-ce      x86_64      7.13.5-ce.0.el7         gitlab_gitlab-ce      321 M

Transaction Summary
================================================================================
Upgrade  1 Package

Total download size: 321 M
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
gitlab-ce-7.13.5-ce.0.el7.x86_64.rpm                       | 321 MB   04:44     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
gitlab preinstall: Backing up GitLab SQL database (excluding Git repositories, uploads)
Dumping database ... 
Dumping PostgreSQL database gitlabhq_production ... [DONE]
Compressing database ... [DONE]
done
Dumping repositories ...
[SKIPPED]
Dumping uploads ... 
[SKIPPED]
Creating backup archive: 1439452033_gitlab_backup.tar ... done
Uploading backup archive to remote storage  ... skipped
Deleting tmp directories ... done
done
Deleting old backups ... skipping
  Updating   : gitlab-ce-7.13.5-ce.0.el7.x86_64                             1/2 
gitlab: Thank you for installing GitLab!
gitlab: To configure and start GitLab, RUN THE FOLLOWING COMMAND:

sudo gitlab-ctl reconfigure

gitlab: GitLab should be reachable at http://serverC8.tachtler.net
gitlab: Otherwise configure GitLab for your system by editing /etc/gitlab/gitlab.rb file
gitlab: And running reconfigure again.
gitlab: 
gitlab: For a comprehensive list of configuration options please see the Omnibus GitLab readme
gitlab: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md
gitlab: 
  Cleanup    : gitlab-ce-7.13.4-ce.0.el7.x86_64                             2/2 
Shutting down all GitLab services except those needed for migrations
ok: down: logrotate: 0s, normally up
ok: down: nginx: 1s, normally up
ok: down: postgresql: 0s, normally up
ok: down: redis: 0s, normally up
ok: down: sidekiq: 0s, normally up
ok: down: unicorn: 1s, normally up
ok: run: postgresql: (pid 6635) 0s
ok: run: redis: (pid 6637) 0s
run: postgresql: (pid 6635) 0s; run: log: (pid 2691) 64046s
run: redis: (pid 6637) 0s; run: log: (pid 2610) 64058s
Reconfiguring GitLab to apply migrations
[2015-08-13T09:50:33+02:00] INFO: Started chef-zero at chefzero://localhost:8889 with repository at /opt/gitlab/embedded
  One version per cookbook

[2015-08-13T09:50:33+02:00] INFO: Forking chef instance to converge...
[2015-08-13T09:50:33+02:00] INFO: *** Chef 12.4.0.rc.2 ***
[2015-08-13T09:50:33+02:00] INFO: Chef-client pid: 6661
[2015-08-13T09:50:35+02:00] INFO: HTTP Request Returned 404 Not Found: Object not found: chefzero://localhost:8889/nodes/serverC8.tachtler.net
[2015-08-13T09:50:35+02:00] INFO: Setting the run_list to ["recipe[gitlab]"] from CLI options
[2015-08-13T09:50:35+02:00] INFO: Run List is [recipe[gitlab]]
[2015-08-13T09:50:35+02:00] INFO: Run List expands to [gitlab]
[2015-08-13T09:50:35+02:00] INFO: Starting Chef Run for serverC8.tachtler.net
[2015-08-13T09:50:36+02:00] INFO: Running start handlers
[2015-08-13T09:50:36+02:00] INFO: Start handlers complete.
[2015-08-13T09:50:36+02:00] INFO: HTTP Request Returned 404 Not Found: Object not found: 
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:36+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:37+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:37+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:37+02:00] WARN: Cookbook 'local-mode-cache' is empty or entirely chefignored at /opt/gitlab/embedded/cookbooks/local-mode-cache
[2015-08-13T09:50:37+02:00] INFO: Loading cookbooks [gitlab@0.0.1, runit@0.14.2, package@0.0.0]
[2015-08-13T09:50:37+02:00] WARN: Cloning resource attributes for directory[/var/opt/gitlab] from prior resource (CHEF-3694)
[2015-08-13T09:50:37+02:00] WARN: Previous directory[/var/opt/gitlab]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb:43:in `from_file'
[2015-08-13T09:50:37+02:00] WARN: Current  directory[/var/opt/gitlab]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/users.rb:23:in `from_file'
[2015-08-13T09:50:37+02:00] WARN: Cloning resource attributes for cron[gitlab-ci schedule builds] from prior resource (CHEF-3694)
[2015-08-13T09:50:37+02:00] WARN: Previous cron[gitlab-ci schedule builds]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/cron.rb:19:in `from_file'
[2015-08-13T09:50:37+02:00] WARN: Current  cron[gitlab-ci schedule builds]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/cron.rb:24:in `from_file'
/sbin/init: unrecognized option '--version'
-.mount                                                           loaded active mounted   /
[2015-08-13T09:50:37+02:00] WARN: Selected systemd because systemctl shows .mount units
[2015-08-13T09:50:38+02:00] WARN: Cloning resource attributes for directory[/var/opt/gitlab/gitlab-rails/etc] from prior resource (CHEF-3694)
[2015-08-13T09:50:38+02:00] WARN: Previous directory[/var/opt/gitlab/gitlab-rails/etc]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/gitlab-rails.rb:41:in `block in from_file'
[2015-08-13T09:50:38+02:00] WARN: Current  directory[/var/opt/gitlab/gitlab-rails/etc]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/definitions/unicorn_config.rb:21:in `block in from_file'
[2015-08-13T09:50:38+02:00] WARN: Cloning resource attributes for service[unicorn] from prior resource (CHEF-3694)
[2015-08-13T09:50:38+02:00] WARN: Previous service[unicorn]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb:88:in `block in from_file'
[2015-08-13T09:50:38+02:00] WARN: Current  service[unicorn]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/runit/definitions/runit_service.rb:191:in `block in from_file'
[2015-08-13T09:50:38+02:00] WARN: Cloning resource attributes for execute[sysctl] from prior resource (CHEF-3694)
[2015-08-13T09:50:38+02:00] WARN: Previous execute[sysctl]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/postgresql.rb:84:in `from_file'
[2015-08-13T09:50:38+02:00] WARN: Current  execute[sysctl]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/unicorn.rb:39:in `from_file'
[2015-08-13T09:50:39+02:00] WARN: Cloning resource attributes for service[sidekiq] from prior resource (CHEF-3694)
[2015-08-13T09:50:39+02:00] WARN: Previous service[sidekiq]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb:88:in `block in from_file'
[2015-08-13T09:50:39+02:00] WARN: Current  service[sidekiq]: /opt/gitlab/embedded/cookbooks/cache/cookbooks/runit/definitions/runit_service.rb:191:in `block in from_file'
[2015-08-13T09:50:40+02:00] INFO: file[/opt/gitlab/embedded/service/gitlab-rails/db/schema.rb] owner changed to 399
[2015-08-13T09:50:40+02:00] INFO: remote_file[/var/opt/gitlab/gitlab-rails/VERSION] backed up to /opt/gitlab/embedded/cookbooks/local-mode-cache/backup/var/opt/gitlab/gitlab-rails/VERSION.chef-20150813095040.373785
[2015-08-13T09:50:40+02:00] INFO: remote_file[/var/opt/gitlab/gitlab-rails/VERSION] updated file contents /var/opt/gitlab/gitlab-rails/VERSION
[2015-08-13T09:50:40+02:00] INFO: execute[chown -R root:root /opt/gitlab/embedded/service/gitlab-rails/public] ran successfully
[2015-08-13T09:50:40+02:00] INFO: execute[Guard resource] ran successfully
[2015-08-13T09:50:42+02:00] INFO: remote_file[/var/opt/gitlab/gitlab-rails/VERSION] sending run action to bash[migrate gitlab-rails database] (delayed)
[2015-08-13T09:50:57+02:00] INFO: bash[migrate gitlab-rails database] ran successfully
[2015-08-13T09:50:57+02:00] INFO: remote_file[/var/opt/gitlab/gitlab-rails/VERSION] sending run action to execute[clear the gitlab-rails cache] (delayed)
[2015-08-13T09:51:09+02:00] INFO: execute[clear the gitlab-rails cache] ran successfully
[2015-08-13T09:51:09+02:00] INFO: Chef Run complete in 33.265348544 seconds
[2015-08-13T09:51:09+02:00] INFO: Running report handlers
[2015-08-13T09:51:09+02:00] INFO: Report handlers complete
gitlab Reconfigured!
Restarting previously running GitLab services
ok: run: logrotate: (pid 6976) 0s
ok: run: nginx: (pid 6979) 1s
ok: run: postgresql: (pid 6635) 48s
ok: run: redis: (pid 6637) 48s
ok: run: sidekiq: (pid 6985) 0s
ok: run: unicorn: (pid 6988) 1s

Upgrade complete! If your GitLab server is misbehaving try running

   sudo gitlab-ctl restart

before anything else. If you need to roll back to the previous version you can
use the database backup made during the upgrade (scroll up for the filename).
  Verifying  : gitlab-ce-7.13.5-ce.0.el7.x86_64                             1/2 
  Verifying  : gitlab-ce-7.13.4-ce.0.el7.x86_64                             2/2 

Updated:
  gitlab-ce.x86_64 0:7.13.5-ce.0.el7                                            

Complete!

Wie schon im Update-Prozess beschrieben sind nachfolgende Befehle zum Abschluss des Updates durchzuführen:

  • erneutes Konfigurieren von Gitlab - sudo gitlab-ctl reconfigure
  • Neustart von Gitlab - sudo gitlab-ctl restart

Nachfolgend der Befehl zum erneuten Konfigurieren:

(Gekürzter Ausschnitt):

# gitlab-ctl reconfigure
Starting Chef Client, version 12.4.0.rc.2
resolving cookbooks for run list: ["gitlab"]
...
...
...
Running handlers:
Running handlers complete
Chef Client finished, 1/161 resources updated in 6.099624773 seconds
gitlab Reconfigured!

Nachfolgend der Befehl zum Neustart:

# gitlab-ctl restart
ok: run: logrotate: (pid 9230) 0s
ok: run: nginx: (pid 9233) 0s
ok: run: postgresql: (pid 9240) 0s
ok: run: redis: (pid 9250) 0s
ok: run: sidekiq: (pid 9257) 0s
ok: run: unicorn: (pid 9267) 1s

Erster Aufruf

Nach der erfolgreich abgeschlossenen Installation, kann durch Eingabe, hier - nachfolgender URL, Gitlab zum ersten mal aufgerufen werden:

Eine Bildschirmanzeige, wie in etwa nachfolgende, sollte dann zum Vorschein kommen:

Gitlab - Erster Aufruf

Durch Eingabe nachfolgender Anmeldedaten, kann die Nutzung von Gitlab erfolgen:

Feld Eingabe
Username or Email root
Password 5iveL!fe

Konfiguration: Basis

Konfigurationen unter Gitlab werden entweder

  • in der Web-Oberfläche druchgeführt oder
  • in der Konfigurationsdatei - /etc/gitlab/gitlab.rb

Nachfolgende Konfigurationen stellen eine grundlegende Basiskonfiguration dar.

Änderungen an Konfiguration, werden mit einem vorangestellten Kommentar, wie nachfolgend dargestellt, gekennzeichnet:

# Tachtler

external_url

Damit Gitlab und auch die sich darin befindlichen Repositorys, unter korrekten clone Links erreichbar ist bzw. sind, welcher auch den Benutzer angezeigt wird, ist es erforderlich, die nachfolgende Zeile in der Konfigurationsdatei

  • /etc/gitlab/gitlab.rb

zu bearbeiten:

(Nur relevanter Ausschnitt):

## Url on which GitLab will be reachable.
## For more details on configuring external_url see:
## https://gitlab.com/gitlab-org/omnibus-gitlab/blob/629def0a7a26e7c2326566f0758d4a27857b52a3/README.md#configuring-the-external-url-for-gitlab
# Tachtler
# default: external_url 'http://serverC8.tachtler.net'
external_url 'http://gitlab.tachtler.net'

Die ursprüngliche URL - http://serverC8.tachtler.net, soll auf eine etwas zutreffendere URL, Namens http://gitlab.tachtler.net abgeändert werden.

(Nur relevanter Ausschnitt):

gitlab_rails['gitlab_restricted_visibility_levels'] = ['private', 'internal', 'public'] # to restrict public and internal: ['public', 'internal']

Damit „normale“ Benutzer auch die Sichtbarkeit von neuen Projekten, welche durch diese angelegt werden, selbst bestimmen können, ist vorhergehende Änderung der Restriktionen erforderlich.

Neukonfiguration

Nach einer Änderung an der Konfigurationsdatei /etc/gitlab/gitlab.rb, ist nachfolgender Befehl auszuführen:

(Gekürtzer Ausschnitt):

# gitlab-ctl reconfigure
Starting Chef Client, version 12.4.0.rc.2
resolving cookbooks for run list: ["gitlab"]
...
...
...
Running handlers:
Running handlers complete
Chef Client finished, 8/165 resources updated in 19.031775408 seconds
gitlab Reconfigured!

damit die Änderungen übernommen werden.

Konfiguration: HTTPS

Nachfolgende Konfigurationen ermöglichen die Nutzung eines verschlüsselten Zugriffs auf Gitlab.

Änderungen an Konfiguration, werden mit einem vorangestellten Kommentar, wie nachfolgend dargestellt, gekennzeichnet:

# Tachtler

external_url

Um einen Wechsel auf einen verschlüsselten Zugriffs auf Gitlab zu realisieren, muss zuerst der Parameter - external_url - nochmals angepasst werden, dazu ist es erforderlich, die nachfolgende Zeile in der Konfigurationsdatei

  • /etc/gitlab/gitlab.rb

zu bearbeiten:

(Nur relevanter Ausschnitt):

## Url on which GitLab will be reachable.
## For more details on configuring external_url see:
## https://gitlab.com/gitlab-org/omnibus-gitlab/blob/629def0a7a26e7c2326566f0758d4a27857b52a3/README.md#configuring-the-external-url-for-gitlab
# Tachtler
# default: external_url 'http://serverC8.tachtler.net'
external_url 'https://gitlab.tachtler.net'

Die ursprüngliche URL - http://gitlab.tachtler.net, soll auf einen verschlüsselten Zugriff mittels HTTPS auf https://gitlab.tachtler.net abgeändert werden.

nginx['ssl_certificate'] und nginx['ssl_certificate_key']

Zusätzlich muss mindestens dem integrierten Web-Server nginx von Gitlab mitgeteilt werden, wo dieser den Schlüssel des Zertifikats und das zum Schlüssel gehörende Zertifikat im Dateisystem findet.

Nachfolgende Befehle sind zur Einrichtung der Einbindung eines Zertifikats notwendig.

Zuerst soll hier die Konfigurationsdatei

  • /etc/gitlab/gitlab.rb

weiter angepasst werden.

Standardmäßig erwartet der Web-Server nginx von Gitlab den Schlüssel des Zertifikats und das dazugehörige Zertifikat im Verzeichnis:

  • /etc/gitlab/ssl

und die nachfolgenden Namen

  • für den Schlüssel des Zertifikats - {node['fqdn']}.key - Beispiel: gitlab.tachtler.net.key
  • für das Zertifikats - {node['fqdn']}.crt - Beispiel: gitlab.tachtler.net.crt

:!: HINWEIS - Falls von der Namenskonventionen abgewichen werden soll, ist nachfolgende zusätzliche Konfiguration erforderlich!

In nachfolgender Konfiguration, soll vom Standard, welchen nginx von Gitlab erwartet, wie folgt abgewichen werden.

Zuerst sollen zwei Verzeichnisse erstellt werden

  • /etc/pki/gitlab/certs - in dem das Zertifikat abgelegt werden soll
  • /etc/pki/gitlab/private - in dem der Schlüssel für das dazugehörige Zertifikat abgelegt werden soll

was mit nachfolgenden Befehl durchgeführt werden kann:

# mkdir -p /etc/pki/gitlab/{certs,private}

Jetzt kann der Schlüssel des Zertifikats und das dazugehörige Zertifikat in die gerade neu erstellten Verzeichnisse kopiert werden.

Kopieren des Zertifikats:

# cp -a /tmp/tachtler.net.crt /etc/pki/gitlab/certs

Kopieren des Schlüssels des Zertifikats:

# cp -a /tmp/tachtler.net.key /etc/pki/gitlab/private

Nachfolgend sind die Dateirechte des Schlüssel des Zertifikats und für das dazugehörige Zertifikat, wie folgt noch anzupassen:

# chmod 644 /etc/pki/gitlab/certs/tachtler.net.crt
# chmod 400 /etc/pki/gitlab/private/tachtler.net.key

Nachfolgend sind die Besitzrechte des Schlüssel des Zertifikats und für das dazugehörige Zertifikat, wie folgt noch anzupassen:

# chown -R root:root /etc/pki/gitlab

Nachfolgende Einträge müssen dann in der Konfigurationsdatei, entsprechend anpasst werden, wenn die Namen für den Schlüssel des Zertifikats und das dazugehörige Zertifikat, nicht dem Standard entsprechen sollen:

(Nur relevanter Ausschnitt):

# Tachtler
# default: # nginx['ssl_certificate'] = "/etc/gitlab/ssl/#{node['fqdn']}.crt"
nginx['ssl_certificate'] = "/etc/pki/gitlab/certs/tachtler.net.crt"
# Tachtler
# default: # nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/#{node['fqdn']}.key"
nginx['ssl_certificate_key'] = "/etc/pki/gitlab/private/tachtler.net.key"

nginx['redirect_http_to_https']

:!: WICHTIG - In dem Moment, in dem nginx von Gitlab für HTTPS konfiguriert wurde, lauscht nginx nicht mehr auf Port: 80

Um weiterhin bequem die URL - http://gitlab.tachtler.net eingeben zu können und trotzdem auf Verschlüsselung nicht verzichten zu müssen, kann der nachfolgende Parameter, wie folgt gesetzt werden:

(Nur relevanter Ausschnitt):

# Tachtler
# default: # nginx['redirect_http_to_https'] = false
nginx['redirect_http_to_https'] = true

nginx von Gitlab lauscht weiterhin zusätzlich auf Port: 80 und führt einen „redirect“ (Umleitung) bei auf Port: 80 eintreffenden Anfragen standardmäßig, auf Port: 443 um.

nginx['ssl_ciphers']

Die Standardeinstellungen zur Verwendung der Cipher-Suiten, können mit nachfolgendem Parameter verändert werden:

(Nur relevanter Ausschnitt):

# Tachtler
# default: # nginx['ssl_ciphers'] = "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256"
nginx['ssl_ciphers'] = "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA"

nginx['ssl_dhparam']

Die Standardeinstellungen zur Verwendung der Diffie-Hellman-Paramter, können mit nachfolgendem Parameter verändert werden, da diese auf nil (nicht genutzt) stehen und angepasst werden sollten.

Dazu ist es allerdings vorab erforderlich, mit folgendem Befehl, eine Datei in nachfolgendem Verzeichnis mit nachfolgendem Namen zu erstellen, welche als Inhalt die neuen Diffie-Hellman-Parameter enthält:

# openssl dhparam -out /etc/gitlab/dhparams.pem 2048
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
...

Anschließend kann dann der Parameter entsprechend gesetzt werden:

(Nur relevanter Ausschnitt):

# Tachtler
# default: # nginx['ssl_dhparam'] = nil # Path to dhparams.pem, eg. /etc/gitlab/ssl/dhparams.pem
nginx['ssl_dhparam'] = "/etc/gitlab/dhparams.pem" # Path to dhparams.pem, eg. /etc/gitlab/ssl/dhparams.pem

Neukonfiguration

Nach einer Änderung an der Konfigurationsdatei /etc/gitlab/gitlab.rb, ist nachfolgender Befehl auszuführen:

(Gekürtzer Ausschnitt):

# gitlab-ctl reconfigure
Starting Chef Client, version 12.4.0.rc.2
resolving cookbooks for run list: ["gitlab"]
...
...
...
Running handlers:
Running handlers complete
Chef Client finished, 7/165 resources updated in 19.491422566 seconds
gitlab Reconfigured!

damit die Änderungen übernommen werden.

Erster HTTPS-Aufruf

Nach der erfolgreich abgeschlossenen HTTPS-Konfiguration, kann durch Eingabe, hier - nachfolgender URL, Gitlab zum ersten mal aufgerufen werden:

:!: HINWEIS - Auf die Eingabe von https://gitlab.tachtler.net wurde verzichtet, da hier ein „redirect“ (Umleitung) von HTTP auf HTTPS erfolgt!

Eine Bildschirmanzeige, wie in etwa nachfolgende, sollte dann zum Vorschein kommen:

Gitlab - Erster HTTPS-Aufruf

Durch Eingabe nachfolgender Anmeldedaten (falls diese nicht bereits geändert wurden), kann die Nutzung von Gitlab erfolgen:

Feld Eingabe
Username or Email root
Password 5iveL!fe

Konfiguration: LDAP(S)

Nachfolgende Konfigurationen ermöglichen die Nutzung eines Verzeichnisdienstes, hier LDAP genauer gesagt OpenLDAP in Verbindung mit Gitlab.

Änderungen an Konfiguration, werden mit einem vorangestellten Kommentar, wie nachfolgend dargestellt, gekennzeichnet:

# Tachtler

gitlab_rails['ldap_enabled']

Bevor mit der eigentlichen Konfiguration von LDAP begonnen werden kann, muss LDAP in Gitlab durch setzen des nachfolgenden Parameters aktiviert werden:

(Nur relevanter Ausschnitt):

# Tachtler
# default: # gitlab_rails['ldap_enabled'] = false
gitlab_rails['ldap_enabled'] = true

gitlab_rails['ldap_servers']

Nachfolgende Konfiguration des Parameters

  • gitlab_rails['ldap_servers']

wirkt auf den ersten Blick etwas unübersichtlich.

Nachfolgende Punkte sind dabei wichtig:

  1. main: muss ein kommentiert werden
  2. secondary ist nur in der Gitlab Enterprise Edition verfügbar
  3. EOS am Ende des Konfigurationsblocks - muss ein kommentiert werden

Nachfolgend nun eine Mögliche Konfiguration als Beispiel:

# Tachtler
# default: # gitlab_rails['ldap_servers'] = YAML.load <<-'EOS' # remember to close this block with 'EOS' below
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS' # remember to close this block with 'EOS' below
   main: # 'main' is the GitLab 'provider ID' of this LDAP server
     label: 'LDAP'
     host: 'ldap.tachtler.net'
     port: 636
     uid: 'uid'
     method: 'ssl' # "tls" or "ssl" or "plain"
     bind_dn: 'cn=Ersatzbenutzer,dc=tachtler,dc=net'
     password: 'geheim'
     active_directory: false
     allow_username_or_email_login: false
     block_auto_created_users: true
     base: 'dc=tachtler,dc=net'
     user_filter: '(|(uid=klaus)(uid=petra))'
     verify_certificates: true     
#     ## EE only
#     group_base: ''
#     admin_group: ''
#     sync_ssh_keys: false
#
#   secondary: # 'secondary' is the GitLab 'provider ID' of second LDAP server
#     label: 'LDAP'
#     host: '_your_ldap_server'
#     port: 389
#     uid: 'sAMAccountName'
#     method: 'plain' # "tls" or "ssl" or "plain"
#     bind_dn: '_the_full_dn_of_the_user_you_will_bind_with'
#     password: '_the_password_of_the_bind_user'
#     active_directory: true
#     allow_username_or_email_login: false
#     block_auto_created_users: false
#     base: ''
#     user_filter: ''
#     ## EE only
#     group_base: ''
#     admin_group: ''
#     sync_ssh_keys: false
EOS

Anmerkungen zu einigen Parametern:

  •      port: 389
         method: 'plain' # "tls" or "ssl" or "plain"

LDAP

  •      port: 389
         method: 'tls' # "tls" or "ssl" or "plain"

LDAP mit STARTTLS

  •      port: 636
         method: 'ssl' # "tls" or "ssl" or "plain"

LDAPS

Voranstehend sind die Kombinationen aufgeführt, welche zur LDAP(S)-Kommunikation verwendet werden können.

  • block_auto_created_users: true

Verhindert, das Benutzer, welche automatisch angelegt wurden, auch gleichzeitig aktiv sind. Dies Benutzer befinden sich nach dem „Sign in“ (Anmeldung) automatisch im Status „blocked“ (blockiert).

  • user_filter: '(|(uid=klaus)(uid=petra))'

Dies ist eine Besonderheit: Wenn im LDAP eine Gruppe aus mehreren Objekten z.B. vom Typ inetOrgPerson besteht (z.B. Personen wie: klaus, petra, lena, luis), aber nicht alle Zugriff auf Gitlab erhalten sollen, sich aber kein weiteres Unterscheidungsmerkmal innerhalb der LDAP-Gruppe anbietet, kann hier eine regex basierte Eingrenzung vorgenommen werden. Nachfolgend hätten nur die Personen klaus und petra Zugriff auf Gitlab.

  • verify_certificates: true

Ab der Gitlab Version 9.5 wird die Überprüfung von Zertifikaten standardmäßig aktiviert, deshalb wird dieser Parameter gesetzt um die verwendeten Zertifikate durch Gitlab überprüfen zu lassen. Falls der Parameter nicht gesetzt wird, erscheint nachfolgender HINWEIS in nachfolgendem LOG - /var/log/gitlab/gitlab-rails/production.log:

LDAP SSL certificate verification is disabled for backwards-compatibility.
Please add the "verify_certificates" option to gitlab.yml for each LDAP
server. Certificate verification will be enabled by default in GitLab 9.5.

Self-Signed Certificates

Falls der der SSL geschützte Zugriff auf den OpenLDAP-Server mit einem

  • self-signed certificate - Selbst er/ausgestelltes Zertifikat

erfolgt, ist es zusätzlich erfolrderlich, das das

  • ROOT-Zertifikat der eigenen CA

unter nachfolgendem Verzeichnis in Gitlab abgelegt wird.

  • /etc/gitlab/trusted-certs

Der Inhalt des Verzeichnisses könnte (hier schon nach der Neukonfiguration und einem Neustart) wie folgt aussehen:

# ls -l /etc/gitlab/trusted-certs
total 268
lrwxrwxrwx 1 root root     10 Jul 29 11:49 5ad8a5d6.0 -> ROOT-CA-cert.pem
lrwxrwxrwx 1 root root     15 Jul 29 11:49 bab86804.0 -> ROOT-CA-LDAP.pem
-rwxr-xr-x 1 root root   4554 Jul 29 11:48 ROOT-CA-LDAP.pem
-rwxr-xr-x 1 root root 263781 Jul 28 15:51 ROOT-CA-cert.pem

Neukonfiguration

Nach einer Änderung an der Konfigurationsdatei /etc/gitlab/gitlab.rb, ist nachfolgender Befehl auszuführen:

(Gekürtzer Ausschnitt):

# gitlab-ctl reconfigure
Starting Chef Client, version 12.4.0.rc.2
resolving cookbooks for run list: ["gitlab"]
...
...
...
Running handlers:
Running handlers complete
Chef Client finished, 5/164 resources updated in 19.498504169 seconds
gitlab Reconfigured!

damit die Änderungen übernommen werden.

Erster LDAP-Aufruf

Nach der erfolgreich abgeschlossenen LDAP-Konfiguration, kann durch Eingabe, hier - nachfolgender URL, Gitlab zum ersten mal aufgerufen werden:

:!: HINWEIS - Auf die Eingabe von https://gitlab.tachtler.net wurde verzichtet, da hier ein „redirect“ (Umleitung) von HTTP auf HTTPS erfolgt!

Eine Bildschirmanzeige, wie in etwa nachfolgende, sollte dann zum Vorschein kommen:

Gitlab - Erster LDAP-Aufruf

Durch Eingabe nachfolgender Anmeldedaten - im Bereich Standard - (falls diese nicht bereits geändert wurden), kann die Nutzung von Gitlab erfolgen:

Feld Eingabe
Standard
Username or Email root
Password 5iveL!fe

Durch Eingabe der LDAP-Anmeldedaten - im Bereich LDAP, kann die Nutzung von Gitlab nun ebenfalls erfolgen:

Feld Eingabe
LDAP
LDAP Login LDAP: [uid]
Password LDAP: [password]

Konfiguration: E-Mail

Nachfolgende Konfigurationen ermöglichen die Nutzung eines SMTP-e-Mail-Servers zur Zustellung von e-Mails in Verbindung mit Gitlab.

Änderungen an Konfiguration, werden mit einem vorangestellten Kommentar, wie nachfolgend dargestellt, gekennzeichnet:

# Tachtler

Nachfolgendes Schaubild soll verdeutlichen, wie der e-Mail-Versand, hier durchgeführt werden soll:

 +============================+     +==================+     +------------------+     +---------------------+
 | Gitlab:                    |     | Postfix: (lokal) |     | Postfix: (relay) |     | Internet: (e-Mail)  |
 | e-Mail wird lokal erstellt | --> | relay der e-Mail | --> | sende die e-Mail | --> | empfängt die e-Mail |
 | https//gitlab.tachtler.net |     |   127.0.0.1:25   |     | mx1.tachtler.net |     |     im Postfach     |
 +============================+     +==================+     +------------------+     +---------------------+

Die Konfiguration soll demnach so gestaltet werden, dass Gitlab die e-Mail nur an den lokal laufenden Postfix via SMTP abgibt und dieser dann für die weitere Zustellung verantwortlich ist.

gitlab_rails['gitlab_email_from']

Nachfolgender Konfigurationsparameter setzt den Absender (from:) der e-Mail und kann wie folgt abgeändert werden:

# Tachtler
# default: # gitlab_rails['gitlab_email_from'] = 'example@example.com'
gitlab_rails['gitlab_email_from'] = 'gitlab@tachtler.net'

gitlab_rails['gitlab_email_display_name']

Nachfolgender Konfigurationsparameter setzt den Absendernamen der e-Mail. Dieser Parameter kann z.B. wie folgt gesetzt werden:

# Tachtler
# default: # gitlab_rails['gitlab_email_display_name'] = 'Example'
gitlab_rails['gitlab_email_display_name'] = 'gitlab.tachtler.net'

gitlab_rails['gitlab_email_reply_to']

Nachfolgender Konfigurationsparameter setzt den Empfänger_ für mögliche Antwort e-Mails. Falls ekine Antworten auf System seitige e-Mails, erwünscht sind, kann hier eine noreply-e-Mail-Adresse, wie nachfolgendes Beispiel zeigt, verwendet werden:

# Tachtler
# default: # gitlab_rails['gitlab_email_reply_to'] = 'noreply@example.com'
gitlab_rails['gitlab_email_reply_to'] = 'noreply@tachtler.net'

:!: HINWEIS - Wie in der oben gezeigten Konstellation, kann das in Postfix ebenfalls enthaltene und standardmäßig zum Einsatz kommende Programm sendmail verwendet werden, anstelle die e-Mails direkt an einen weiteren (zentralen) e-Mail-SMTP-Server zuzustellen!

Die e-Mails haben dann z.B. im Header der e-Mail als erste Received Station folgende Angabe (postdrop - maildrop -pickup):

(Nur relevanter Ausschnitt)

...
Received: by gitlab.tachtler.net (Postfix, from userid 397)
        id 5BF9E24A5F93; Fri, 14 Aug 2015 11:52:05 +0200 (CEST)
...

Neukonfiguration

Nach einer Änderung an der Konfigurationsdatei /etc/gitlab/gitlab.rb, ist nachfolgender Befehl auszuführen:

(Gekürtzer Ausschnitt):

# gitlab-ctl reconfigure
Starting Chef Client, version 12.4.0.rc.2
resolving cookbooks for run list: ["gitlab"]
...
...
...
Running handlers:
Running handlers complete
Chef Client finished, 5/164 resources updated in 19.498504169 seconds
gitlab Reconfigured!

damit die Änderungen übernommen werden.

Konfiguration: SMTP


:!: WICHTIG - Nachfolgende Konfiguration ist nur dann durchzuführen, wenn kein sendmail zum Einsatz kommen soll!


:!: HINWEIS - Wie in der oben gezeigten Konstellation, kann auch die e-Mail Zustellung an Postfix via SMTP auf 127.0.0.1 (localhost) erfolgen, was nachfolgend gezeigte Konfiguration erfordert, anstelle die e-Mails direkt an einen weiteren (zentralen) e-Mail-SMTP-Server zuzustellen!

Die e-Mails haben dann z.B. im Header der e-Mail als erste Received Station folgende Angabe (smtpd):

(Nur relevanter Ausschnitt)

...
Received: from localhost.localdomain (localhost [127.0.0.1])
        by gitlab.tachtler.net (Postfix) with ESMTP id 54F9324A5F9C
        for <klaus@tachtler.net>; Fri, 14 Aug 2015 12:09:13 +0200 (CEST)
...

gitlab_rails['smtp_enable']

Bevor mit der eigentlichen Konfiguration von SMTP begonnen werden kann, muss SMTP in Gitlab durch setzen des nachfolgenden Parameters aktiviert werden:

(Nur relevanter Ausschnitt):

# Tachtler
# default: # gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_enable'] = true

gitlab_rails['smtp_address']

Nachfolgender Konfigurationsparameter setzt die IP-Adresse oder den FQDN des e-Mail-Server an den Gitlab die e-Mail einliefern soll, nachfolgend soll das - hier, genau wie bei der Verwendung von sendmail, der lokale Postfix sein:

(Nur relevanter Ausschnitt):

# Tachtler
# default: # gitlab_rails['smtp_address'] = "smtp.server"
gitlab_rails['smtp_address'] = "127.0.0.1"

gitlab_rails['smtp_port']

Nachfolgender Konfigurationsparameter setzt den Port: 25 des e-Mail-Server an den Gitlab die e-Mail einliefern soll, nachfolgend soll das - hier der Standard Port: 25 für die Einlieferung von e-Mail beim lokalen Postfix sein:

(Nur relevanter Ausschnitt):

# Tachtler
# default: # gitlab_rails['smtp_port'] = 456
gitlab_rails['smtp_port'] = 25

:!: HINWEIS - Port: 25 deswegen, da Postfix in der Grundkonfiguration keine Verschlüsselung anbietet!

gitlab_rails['smtp_authentication']

Nachfolgender Konfigurationsparameter deaktiviert die Verwendung eines Authentifikationsmechanismuses, da bei der Einlieferung auf Port: 25 (Server ↔ Server-Kommunikation) standardmäßig keine Authentifizierung statt findet:

(Nur relevanter Ausschnitt):

# Tachtler
# default: # gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_authentication'] = false

gitlab_rails['smtp_enable_starttls_auto']

Nachfolgender Konfigurationsparameter deaktiviert die Verwendung von STARTTLS (Verschlüsselung nach erfolgreichem unverschlüsselten Verbindungsaufbau), da Postfix in der Grundkonfiguration keine Verschlüsselung anbietet:

(Nur relevanter Ausschnitt):

# Tachtler
# default: # gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_enable_starttls_auto'] = false

Neukonfiguration

Nach einer Änderung an der Konfigurationsdatei /etc/gitlab/gitlab.rb, ist nachfolgender Befehl auszuführen:

(Gekürtzer Ausschnitt):

# gitlab-ctl reconfigure
Starting Chef Client, version 12.4.0.rc.2
resolving cookbooks for run list: ["gitlab"]
...
...
...
Running handlers:
Running handlers complete
Chef Client finished, 5/163 resources updated in 19.498504169 seconds
gitlab Reconfigured!

damit die Änderungen übernommen werden.

Konfiguration: IPv6

Standardmäßig wird ab der Gitlab Version 8.14.0 IPv6 aktiviert. Falls keine IPv6 Interfaces zu Verfügung stehen, weil diese Funktionalität deaktiviert wurde, würde dies zu nachfolgender Fehlermeldung führen, wenn der nginx gestartet wird:

(Nur relevanter Ausschnitt)

# gitlab-ctl tail nginx
==> /var/log/gitlab/nginx/current <==
2016-11-23_03:28:53.20741 2016/11/23 04:28:53 [emerg] 10276#0: socket() [::]:80 failed (97: Address family not supported by protocol)
...

Um den nginx innerhalb der Gitlab-Installation nur auf IPv4 Adressen lauschen zu lassen, ist nachfolgender Parameter in der Konfigurationsdatei /etc/gitlab/gitlab.rb zu setzen.

nginx['listen_addresses']

Nachfolgender Konfigurationsparameter deaktiviert die Nutzung von IPv6:

# Tachtler - disable ipv6 -
# default: # nginx['listen_addresses'] = ['*']
nginx['listen_addresses'] = ["0.0.0.0"]

Neukonfiguration

Nach einer Änderung an der Konfigurationsdatei /etc/gitlab/gitlab.rb, ist nachfolgender Befehl auszuführen:

(Gekürtzer Ausschnitt):

# gitlab-ctl reconfigure
Starting Chef Client, version 12.4.0.rc.2
resolving cookbooks for run list: ["gitlab"]
...
...
...
Running handlers:
Running handlers complete
Chef Client finished, 5/164 resources updated in 19.498504169 seconds
gitlab Reconfigured!

damit die Änderungen übernommen werden.

Erster Anmeldung

Nach den erfolgreich abgeschlossenen vorhergehenden Konfigurationen, kann durch Eingabe, hier - nachfolgender URL, Gitlab zum ersten mal aufgerufen werden:

:!: HINWEIS - Auf die Eingabe von https://gitlab.tachtler.net wurde verzichtet, da hier ein „redirect“ (Umleitung) von HTTP auf HTTPS erfolgt!

Eine Bildschirmanzeige, wie in etwa nachfolgende, sollte dann zum Vorschein kommen:

Gitlab - Erste Anmeldung

Durch Eingabe nachfolgender Anmeldedaten - im Bereich Standard - (falls diese nicht bereits geändert wurden), kann die Anmeldung als Administrator von Gitlab erfolgen:

Feld Eingabe
Standard
Username or Email root
Password 5iveL!fe

Anschließend sollte dann nachfolgender Bildschirm erscheinen, welcher zur Änderung des Standardpasswortes auf ein individuelles Passwort für den Benutzer root auffordert:

Gitlab - Erste Anmeldung - Benutzer: root - Passwort Änderung

Nach erfolgreicher Passwortänderung, erfolgt eine automatische Abmeldung und der ursprüngliche Anmeldebildschirm erscheint:

Gitlab - Erste Anmeldung nach Paswortänderung

Durch Eingabe der neuen Anmeldedaten - im Bereich Standard - (nachdem das Passwort geändert wurde), kann die Anmeldung als Administrator von Gitlab erfolgen:

Feld Eingabe
Standard
Username or Email root
Password [individuelles Passwort]

Abschließend sollte nun nachfolgender Willkommen zu Gitlab Bildschirm des Benutzers root erscheinen:

Gitlab - Erste Anmeldung - Willkommen zu Gitlab

Erweiterungen & Plugins

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_centos_7.txt · Zuletzt geändert: 2018/01/28 13:31 von klaus