Ich habe versucht, GitLab auf einem CentOS 7-Server einzurichten, den ich in meinem lokalen Netzwerk betreibe, damit ich während des kommenden Semesters irgendwo meine Dateien und Projekte speichern und synchronisieren kann. Ich habe die Installationsanweisungen für die Omnibus-Paketinstallation befolgt, die ich gefunden habeHier.
Jetzt, nach der Einrichtung, konnte ich mich nicht als Root-Benutzer anmelden. Ich habe inzwischen herausgefunden, dass ich Microsoft Edge zur Authentifizierung verwenden kann, aber Google Chrome funktioniert nicht. Ich habe festgestellt, dass das Verhalten ähnlich ist, unabhängig davon, ob ich die Site über IP oder Adresse (lokal zugewiesen im DNS-Server des Routers) aufrufe. Wenn ich versuche, mich mit Chrome anzumelden, hängt sich die Webanwendung auf und wird ständig geladen.
Ich habe gitlab-ctl verwendet, um die Protokolle von NGINX zu überprüfen, und es sieht so aus, als ob die POST-Anforderung einfach nicht durchgeht, wenn ich Chrome verwende. Hier ist eine Beispielausgabe:
==> /var/log/gitlab/nginx/gitlab_access.log <==
192.168.1.52 - - [18/Aug/2019:18:15:47 -0600] "GET / HTTP/1.1" 302 98 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:15:57 -0600] "POST /users/sign_in HTTP/1.1" 302 85 "http://192.168.1.2/users/sign_in" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:15:57 -0600] "GET / HTTP/1.1" 200 8684 "http://192.168.1.2/users/sign_in" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:16:03 -0600] "GET / HTTP/1.1" 200 8673 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:16:06 -0600] "GET /users/sign_out?nav_source=navbar HTTP/1.1" 302 97 "http://gitlab.lan/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:16:06 -0600] "GET /users/sign_in HTTP/1.1" 200 4718 "http://gitlab.lan/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:16:12 -0600] "POST /users/sign_in HTTP/1.1" 302 84 "http://gitlab.lan/users/sign_in" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
Ich habe versucht, den Browserverlauf/Cache/die Cookies zu löschen, in der Hoffnung, dass dadurch etwas behoben wird, das beim Konfigurieren von GitLab hängen geblieben sein könnte, aber nichts hat geholfen. Ich sollte erwähnen, dass ich über Firewall nur Port 80 geöffnet habe, nicht Port 443. Ich plane, GitLab nur über HTTP auszuführen. Der Erfolg von Microsoft Edge beim Zugriff auf die Site und der Authentifizierung bei ihr zeigt mir, dass die Konfiguration von GitLab auf diese Weise kein Problem darstellen sollte.
Weiß jemand, was das Problem sein könnte?
Ich laufe CentOS Linux release 7.6.1810 (Core), GitLab Version 12.1.6-ee Revision d05ee0a9c12undGoogle Chrome 76.0.3809.87 (Official Build) (64-bit)
Antwort1
Für alle, die ein ähnliches Problem haben, ich habe die Ursache gefunden:
Die Top-Level-Domain von gitlab.lan, .lan, ist nicht registriert unter denDie TLD-Datenbank der IANA. Anscheinend lassen einige Browser bestimmte Verbindungstypen (in diesem Fall ließ Chrome die POST-Methode nicht zu) zu Domänen nicht zu, wenn es sich bei der Domäne nicht um eine offizielle TLD handelt.
Nun, in meiner Frage sagte ich, dass der Zugriff über IP auch nicht funktionierte. Ich glaube, das Problem wurde verursacht, als ich GitLab konfigurierte und die Domäne angab, an die es angehängt werden sollte gitlab.lan. Ich gehe davon aus, dass GitLab Links zu sich selbst unter Verwendung dieser Adresse renderte. Auf diese Weise würde es versuchen, zu POSTen, gitlab.lanob der Benutzer die Site über IP oder Domäne aufgerufen hat.
Die Lösung bestand darin, anstelle von eine gültige TLD .lanfür die Website-Domäne ( .com, .net, usw.) zu verwenden.
In Bezug darauf, welche Browser Domain-TLDs validieren, bevor sie auf eine Website zugreifen, scheint Chrome ein Glücksspiel zu sein und Edge scheint überhaupt nicht zu validieren. Die Laufleistung scheint unterschiedlich zu sein und ich gehe davon aus, dass das Verhalten undefiniert ist oder sich regelmäßig ändert, daher werde ich hier nicht dokumentieren, welche Browser sich wie verhalten.