Inhaltsverzeichnis
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
Beschreibung | Externer Link |
---|---|
Homepage | https://gitlab.com/ |
Dokumentation | https://about.gitlab.com/documentation/ |
Omnibus Doku. | https://docs.gitlab.com/omnibus/ |
Installation | https://about.gitlab.com/downloads/ |
Versionsvergleich | https://about.gitlab.com/features/#compare |
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:
- Lauffähiger LDAP-Server z.B. OpenLDAP
- Siehe auch den internen Link: LDAP CentOS 7
Nachfolgende rpm
-Pakete sind als Abhängigkeit erforderlich und werden ebenfalls benötigt:
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
- Manuelle Auswahl und Installation des herunterzuladenden Pakets unter nachfolgendem externen Link:
- 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)
- Es wird automatisch eines neues Repository unter
/etc/yum.repos.d
mit dem Namengitlab_gitlab-ce.repo
erstellt - 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:
- Ermittlung des Betriebssystems
- Überprüfung der Befehl
curl
vorhanden ist (ggf. unnötig, dacurl
schon beim Befehlsaufruf verwendet wird), ggf. wirdcurl
installiert - Ermittlung des Host-Namens
- Einrichten eines neuen Repositorys unter
etc/yum.repos.d/gitlab_gitlab-ce.repo
- Installation des
rpm
-Paktespygpgme
, welches zur Überprüfung von GPG-Signaturen benötigt wird - Installation des
rpm
-Paktesyum-utils
, welches zur Verwaltung vonrpm
-Paketen benötigt wird - Erstellen von
cache
-Informationen für das neu Installierte Repository unteretc/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:
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:
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:
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:
main:
muss ein kommentiert werdensecondary
ist nur in der Gitlab Enterprise Edition verfügbarEOS
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:
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:
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:
Nach erfolgreicher Passwortänderung, erfolgt eine automatische Abmeldung und der ursprüngliche Anmeldebildschirm erscheint:
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: