GitLab - Apache: HTTPS
Currently, the production environment uses HTTP for the connection to apache. In order to work with GitLab runners, we should change this setting to HTTPS. In the development environment, this was already successfully tested and applied.
-
Version 1 (latest) Michael Breu
Child items
...Activity
changed milestone to %2021 Februar Sprint Sharing Plattform
assigned to @lukas.kaltenbrunner and unassigned @Michael.Breu
Wurde umgestellt und in https://sharing-codeability.uibk.ac.at/sharing/codeability-sharing-platform/-/wikis/technical/setup/https dokumentiert.
Bitte testen und ggf. schliessen.
Thank you for the documentation.
In general, I think it should work as documented. However, I guess there was/is some configuration issue.
For example, if you click on clone on any project the domain is wrong (https://sharing.codeability.uibk.ac.at/....)
Furthermore, I noticed that Link in the notification emails are also wrong and the url differs once more?!
Administrator commented: Wurde umgestellt und in https://sharing-codeability.uibk.ac.at/sharing/codeability-sharing-platform/-/wikis/technical/setup/https dokumentiert. Bitte testen und ggf. schliessen. -- View it on GitLab: https://sharing.codeability-austria.uibk.ac.at/sharing/codeability-sharing-platform/-/issues/54#note_658 You're receiving this email because of your account on sharing.codeability-austria.uibk.ac.at.I am referring to the url: https://sharing.codeability-austria.uibk.ac.at/sharing/codeability-sharing-platform/-/issues/54#note_658
assigned to @Michael.Breu and unassigned @lukas.kaltenbrunner
assigned to @dancraz and unassigned @Michael.Breu
@dancraz : Die IP Nummer des Containers ist leider in der Apache Reverse Proxy Definition "hard-coded". Wie können wir das gegen Wechseln der IP-Nummer absichern?
Anstatt IP-Nummer könnte man den Host-URL + container_port verwenden (z.B.
ProxyPassReverse / http://codeability-austria.uibk.ac.at:10080/).Somit sollte das Container immer mit der gleiche URL im Apache Proxy erreichbar sein.
Edited by Daniel Crazzolara
Now it works fine! Thank you.
A runner for FACT and the sharing platform was installed successfully. However, the container registry does not work. Therefore, I think to fix #56 (closed), the same should be done for the port of the container registry. Currently, you cannot log into the container registry
docker login sharing-codeability.uibk.ac.at:5050.mentioned in issue #56 (closed)
-
Hallo Daniel,
Das scheint irgendwie nicht zu funktionieren:
ProxyPass / https://codeability-austria.uibk.ac.at:10083/ ProxyPassReverse / https://codeability-austria.uibk.ac.at:10083/Das Weiterleiten geht, aber man wird immer wieder auf die Login-Maske zurückgewiesen.
Dagegen funktioniert
ProxyPass / https://172.22.0.5:443/ ProxyPassReverse / https://172.22.0.5:443/Können wir irgendwie die IP-Nummer 172.22.0.5 in über ein lokales DNS auflösen? Da scheint es was zu geben: https://medium.com/@huynhquangthao/how-does-the-docker-dns-work-ab69bde4c82a#:~:text=Docker%20containers%20take%20DNS%20IPs,are%20the%20cloud%20provider's%20DNS.
Ich habe mich aber nicht in die Details eingearbeitet.
@Michael.Breu Habe gerade auf codeability-austria probiert ein wget IP zu machen aber scheint leer zu sein..
daniel@codeability-austria:~$ wget https://172.22.0.5:443 --2021-02-26 10:26:40-- https://172.22.0.5/ Connecting to 172.22.0.5:443... failed: Connection timed out. Retrying.Zeigt die IP auf den Gitlab container?
-
@dancraz Das Problem ist in Produktion (sharing-codeability)
michael@sharing-codeability:~$ sudo grep -r 172.22.0. /etc/apache2/ [sudo] password for michael: /etc/apache2/sites-available/default-ssl.conf: ProxyPass / https://172.22.0.5:443/ /etc/apache2/sites-available/default-ssl.conf: ProxyPassReverse / https://172.22.0.5:443/ michael@sharing-codeability:~$ curl --insecure https://172.22.0.5:443 <html><body>You are being <a href="https://172.22.0.5/users/sign_in">redirected</a>.</body></html>michael@sharing-codeability:~$In der Entwicklungsumgebung funktioniert die (sehr ähnliche Konfiguration) Ich habe nochmals rumprobiert. Leider kommt es dabei aber immer wieder zu Betriebsunterbrechungen. Wir müssen die default-ssl.conf von apache in Entwicklung und Prod genau abgleichen.
Ich mache das Ticket hier mal zu.
Michael
mentioned in issue #60 (closed)
