.png)
Ich habe versucht, GitLab auf einem kleinen persönlichen Server zu installieren und so zu konfigurieren, dass es auf einer Plesk WebAdmin-Subdomain funktioniert. Ich habe GitLab normal über das Omnibus-Paket installiert. Ich habe die folgenden Einstellungen in der Datei gitlab.rb geändert:
nginx['enable'] = false
web_server['external_users'] = ['www-data', 'PLESK_USER']
web_server['group'] = 'psacln'
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"
wobei PLESK_USER der mit dieser Plesk-Subdomäne verknüpfte Benutzer ist.
Ich habe HTTP auf der Subdomain auf HTTPS umgeleitet, was funktioniert, das SSL-Zertifikat funktioniert auch.
In Plesk habe ich unter „zusätzliche Anweisungen für HTTPS“ den Text von dieser Seite in das <VirtualHost *:443>Tag eingefügt.
https://gitlab.com/gitlab-org/gitlab-recipes/blob/master/web-server/apache/gitlab-omnibus-ssl-apache24.conf
und ich habe YOUR_SERVER_FQDN sowie die 3 SSLCertificateFile-Zeilen ersetzt (mit denen, die ich unter /var/www/vhosts/system/fqdn/conf/last_nginx.conf gefunden habe
Beim Besuch meiner Domain erhalte ich sofort einen 500-Fehler. Und das, bevor ich überhaupt einen Root-Benutzer erstellt habe. Die Nachricht scheint GitLab-spezifisch zu sein, da sie das GitLab-Logo und den entsprechenden Text enthält. Daher glaube ich, dass die Weiterleitung zu GitLab selbst zu funktionieren scheint.
Im Produktionsprotokoll erhalte ich für jeden Site-Besuch lediglich die folgende Ausgabe:
Started GET "/-/metrics" for 127.0.0.1 at 2019-05-27 11:59:44 +0000
Processing by MetricsController#index as HTML
Completed 200 OK in 2ms (Views: 0.4ms | ActiveRecord: 0.0ms | Elasticsearch: 0.0ms)
und mit gitlab-ctl tail
==> /var/log/gitlab/gitlab-rails/production.log <==
Started GET "/-/metrics" for 127.0.0.1 at 2019-05-27 12:01:29 +0000
Processing by MetricsController#index as HTML
Completed 200 OK in 2ms (Views: 0.4ms | ActiveRecord: 0.0ms | Elasticsearch: 0.0ms)
==> /var/log/gitlab/gitlab-rails/production_json.log <==
{"method":"GET","path":"/-/metrics","format":"html","controller":"MetricsController","action":"index","status":200,"duration":2.64,"view":0.41,"db":0.0,"time":"2019-05-27T12:01:29.670Z","params":[],"remote_ip":null,"user_id":null,"username":null,"ua":null,"queue_duration":null,"correlation_id":"98970bd1-9618-41ea-85a2-5f59b26fd16b"}
Diese Meldungen werden sofort und genau einmal für jede meiner Browseranfragen angezeigt.
sudo gitlab-rake gitlab:check --traceoffenbart ebenfalls keine weiteren fehlenden Informationen. Das Fehlen konkreter Fehlermeldungen lässt mich vermuten, dass ein Problem mit der Verknüpfung zwischen Plesk und GitLab und nicht mit der GitLab-Installation selbst vorliegt, aber ich kann dieses konkrete Problem nirgendwo anders finden und mir gehen wirklich die Ideen aus, was ich überprüfen könnte.
Ich bin für jede Hilfe dankbar.
Bearbeiten: Beim Überprüfen des Protokolls in /var/log/gitlab/gitlab-workhorse/current werden beim Start der Anwendung (nach jedem Neustart) die folgenden Fehlermeldungen angezeigt
2019-05-27_13:11:49.39615 time="2019-05-27T13:11:49Z" level=error msg="unknown error" error="keywatcher: pubsub receive: EOF"
2019-05-27_13:11:49.39617 time="2019-05-27T13:11:49Z" level=info msg="redis: dialing" address=/var/opt/gitlab/redis/redis.socket network=unix
2019-05-27_13:11:49.39617 time="2019-05-27T13:11:49Z" level=error msg="unknown error" error="keywatcher: dial unix /var/opt/gitlab/redis/redis.socket: connect: no such file or directory"
Da ich allerdings über die eingangs genannten Einstellungen hinaus keine Änderungen vorgenommen habe, kann ich keinen wirklichen Zusammenhang zu meiner konkreten Konfiguration feststellen.
Antwort1
Ich habe dieses Problem jetzt gelöst.
In meiner Plesk-Oberfläche unter „Tools & Einstellungen“ – „Apache Web Server“ war das Modul „proxy_http“ nicht aktiviert. Das Aktivieren des Moduls löst das Problem mit der obigen Konfiguration perfekt! Hoffentlich kann dies in Zukunft jemandem mit demselben Problem helfen.