ubuntuusers.de

Hallo,

ich bin hier grade ziemlich am verzweifeln. Ich versuche jetzt seit tagen Gitlab auf meinem Ubuntu server ans laufen zu kriegen ohne das der apache server geblockt wird, da die anscheinend die selben Ports benutzen. Ich hab schon tonnen an tutorials durch aber irgendwie funktioniert das alles nicht.

Also kennt sich hier jemand mit Gitlab aus und kann mir da weiterhelfen?

Gruß Darman

Darman schrieb:

Ich hab schon tonnen an tutorials durch aber irgendwie funktioniert das alles nicht.

"Funktioniert nicht" ist keine Fehlerbeschreibung. "Tonnen an Tutorials" ist keine Quellenangabe. Siehe Richtig fragen.

Es gibt eine apache config direkt von gitlab: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache

also die tutorials die ich bisher gesehen habe wollen das so lösen, indem gitlab auf einen anderen port configuriert wird aber das funktioniert halt nicht. wenn ich dann auf den port zugreifen will passiert einfach nichts.

So ich hab jetzt nochmal die gitlab config runtergeladen

in der datei muss ich ja YOUR_SERVER_FQDN austauschen aber was genau ist die FQDN ich hab biser immer mydomain.org angegeben. ist das so richtig?

und wo sind die SSL keys bei ubuntu?

also ich hab das jetzt alles nochmal nach dem Tutorial hier gemacht: http://doc.gitlab.com/omnibus/settings/nginx.html#using-a-non-bundled-web-server und wenn ich reconfigure aufrufe am ende dann sagt der mir das der die ssl keys nicht findet.

Darman schrieb:

also die tutorials die ich bisher gesehen habe wollen das so lösen, indem gitlab auf einen anderen port configuriert wird aber das funktioniert halt nicht. wenn ich dann auf den port zugreifen will passiert einfach nichts.

Ist der Port nur lokal erreichbar? Ist der Port offen? Was sagt netstat -tulpen?

in der datei muss ich ja YOUR_SERVER_FQDN austauschen aber was genau ist die FQDN ich hab biser immer mydomain.org angegeben. ist das so richtig?

Der FQDN muss eindeutig sein und hat meist die Form hostname.domain.tld. Siehe auch https://en.wikipedia.org/wiki/Fully_qualified_domain_name

und wo sind die SSL keys bei ubuntu?

Die automatisch generierten (selbst-signierten) sind in /etc/ssl/private/ssl-cert-snakeoil.key resp. /etc/ssl/certs/ssl-cert-snakeoil.pem.

Darman schrieb:

also ich hab das jetzt alles nochmal nach dem Tutorial hier gemacht: http://doc.gitlab.com/omnibus/settings/nginx.html#using-a-non-bundled-web-server und wenn ich reconfigure aufrufe am ende dann sagt der mir das der die ssl keys nicht findet.

Bitte poste die ganze ausgabe, dann muss ich nicht herumraten.

service apache2 reload

• Reloading web server apache2 *

• The apache2 configtest failed. Not doing anything.

Output of config test was: AH00526: Syntax error on line 36 of /etc/apache2/sites-enabled/gitlab-omnibus-ssl-apache24.conf: SSLCertificateFile: file '/etc/httpd/ssl.crt/gitlab.erik-simon.org.crt' does not exist or is empty Action 'configtest' failed. The Apache error log may have more information.

Hier ist der fehler

Darman schrieb:

SSLCertificateFile: file '/etc/httpd/ssl.crt/gitlab.erik-simon.org.crt' does not exist or is empty

Was ist daran jetzt unverstaendlich? Entweder du korrigierst den Pfad in der Datei oder du erzeugst das Zertifikat an diesem Ort.

ja schon klar aber wie?

okay hab jetzt die ssl files aber wenn ich jetzt die gitlab subdomain aufrufe bekomm ich nen 503 errror

Auch bei nem 503er Fehler findet man wohl was in dem error.log vom Apache. Bitte verwende für die Ausgabe aus solchen Logfiles auch die Codeblöcke (das Symbol mit dem Papier und nem Zahnrad oberhalb vom Eingabefeld für Beiträge).

mfg Stefan Betz

[Sat Feb 13 22:06:29.491689 2016] [proxy:error] [pid 10901:tid 140350138009344] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8181 (*) failed
[Sat Feb 13 22:06:29.491726 2016] [proxy_http:error] [pid 10901:tid 140350138009344] [client 95.118.90.199:14891] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Sat Feb 13 22:06:29.491810 2016] [proxy:error] [pid 10901:tid 140350138009344] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8181 (*) failed
[Sat Feb 13 22:06:29.491820 2016] [proxy_http:error] [pid 10901:tid 140350138009344] [client 95.118.90.199:14891] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Sat Feb 13 22:06:29.610453 2016] [proxy:error] [pid 10900:tid 140350190458624] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8181 (*) failed
[Sat Feb 13 22:06:29.610499 2016] [proxy_http:error] [pid 10900:tid 140350190458624] [client 95.118.90.199:14892] AH01114: HTTP: failed to make connection to backend: 127.0.0.1, referer: http://gitlab.erik-simon.org/
[Sat Feb 13 22:06:29.610576 2016] [proxy:error] [pid 10900:tid 140350190458624] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8181 (*) failed
[Sat Feb 13 22:06:29.610585 2016] [proxy_http:error] [pid 10900:tid 140350190458624] [client 95.118.90.199:14892] AH01114: HTTP: failed to make connection to backend: 127.0.0.1, referer: http://gitlab.erik-simon.org/

Das steht im Gitlab error Log

Edit:

Okay ich kann jetzt auf gitlab zugreifen aber jetzt bekomm ich wenn ich einen benutzer anlegen will nen 422 Error.

Btw gibt's bei gitlab nen standard nutzer mit admin rechten oder muss ich einfach nen neuen erstellen?

Edit2:

Okay den error 422 bin ich auch los geworden aber jetzt verschickt gitlab die confirmation email nicht wenn ich mich registriere...

Verschickt es keine, oder bekommst du keine? Das kannst du in den Logs von deinem lokalem MTA auf dem System nachschauen.

mfg Stefan Betz

ähm welche log dateien?

Das kommt drauf an welchen MTA du verwendet, aber oft ist es die /var/log/mail.log bzw. /var/log/mail.err. Ein MTA verschickt ja nur Mails wenn er passend konfiguriert wurde, wenn du bisher damit keine Mails verschicken kannst wirst du auch keine Registry Validation Mail bekommen.

Die meisten Webanwendungen haben aber einen User der Admin Zugriff erlaubt, das sollte der Dokumentation von Gitlab zu entnehmen sein.

mfg Stefan Betz
PS: Ich hoffe ja stark das dies nicht auf nem öffentlich erreichbaren Server läuft…

hehe 😀 doch ist ein öffentlicher server

ich guck mal eben nach der log datei