Hallo Community, ich bin dabei Gitlab (self-managed) auf meinem Server (Debian GNU/Linux 11 bullseye) zu installieren. Dabei gehe ich nach den 'install instructions' von Gitlab vor: https://about.gitlab.com/install/#debian Beim 2. Punkt (Add the GitLab package repository) wird der folgende Befehl ausgeführt: curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash Dabei kommt es zu einer Fehlermeldung: curl: (60) SSL certificate problem: self signed certificate in certificate chain Weiß jemand von euch was der Hintergrund der Fehlermeldung ist bzw. wie lässt sich das Problem lösen? Ich habe bereits mit 'google' nach einer möglichen Lösung gesucht, bin bisher jedoch auf keine Lösung gestoßen. Danke im Voraus! Gruß Flo
Hast du die aktuellen Zertifizierungsstellen im System installiert? gitlab.com sollte eigentlich nicht als selbst signiert erkannt werden. Evtl. brauchst du also: https://packages.debian.org/bullseye/ca-certificates
Hallo Andre, Danke für deine Antwort. Ich habe mittels des Befehls "dpkg -s ca-certificates" überprüft, ob das Paket installiert ist und es ist installiert. Gibt es hier einen Unterschied zu dem was du geschrieben hast? https://packages.debian.org/bullseye/ca-certificates Eigentlich nicht, oder? Ich habe auch nochmals den Befehl "apt install ca-certificates" ausgeführt, jedoch mit dem gleichen Ergebnis. Ich weiß leider nicht, was ich übersehen habe oder was der Grund ist. Gruß Flo
Wenn ich die Liste unter folgendem Link mir anschaue, https://packages.debian.org/bullseye/all/ca-certificates/filelist dann sind die Dateien unter dem folgenden Verzeichnis gelistet: /usr/share/ca-certificates/ Dieses Verzeichnis existiert jedoch nicht auf meinem Debian Server, obwohl ich den Befehl "apt install ca-certificates" ausgeführt habe. Gruß Flo
Flo schrieb: > curl: (60) SSL certificate problem: self signed certificate in > certificate chain Kuck dir die Zertifikatkette doch mal mit einem Browser an. [Bin grad auf Android, sonst würd ich selbst mal kucken.] LG, Sebastian
Flo schrieb: > curl: (60) SSL certificate problem: self signed certificate in > certificate chain Das klingt für mich nach einem Firmenproxy welcher sich als "man in the middle" aufspielt. Das entsprechende Zertifikat ist im Browser hinterlegt, nicht aber bei curl/Debian. Du könntest jetzt dieses Zertifikat deinem Debian System hinzufügen, davon würde ich aber abraten aus Sicherheitsgründen. Weil das Zertifikat der eigentlichen Seite ist von Cloudflare signiert.
Flo schrieb: > /usr/share/ca-certificates/ > > Dieses Verzeichnis existiert jedoch nicht auf meinem Debian Server, > obwohl ich den Befehl "apt install ca-certificates" ausgeführt habe. Auf meinem PC ist es, da ist vermutlich etwas auf deinem System kaputt gegangen. Mache erstmal ein fsck auf das Laufwerk, um zu sehen, ob das Dateisystem noch in ordnung ist, und es gegebenenfalls zu reparieren. Dann würde ich schauen, bei welchen Paketen noch so Dateien fehlen. (Folgendes muss als root laufen, sonst gibt's false-positives, wobei ich auch so noch 1 false positive habe, sollte aber gut genug sein).
1 | export LC_ALL=C.UTF-8 |
2 | dpkg --get-selections | |
3 | while read package _ |
4 | do |
5 | dpkg-query -L "$package" | |
6 | grep -v 'diverted by' | |
7 | grep -v 'package diverts others to: ' | |
8 | while read file |
9 | do |
10 | if ! [ -h "$file" ] && ! [ -e "$file" ] |
11 | then echo "$package" |
12 | fi |
13 | done |
14 | done | uniq >broken.txt |
15 | cat broken.txt |
Danach würde ich die nochmal neu installieren:
1 | apt-get install --reinstall $(<broken.txt) |
Hallo, Danke für eure Antworten und Lösungsvorschläge. Ich möchte euch eine Rückmeldung geben, dass das Problem inzwischen gelöst ist. Der Tipp von "Klaus Klaut" und dem Firmenproxy brachte mich auf die richtige Spur. Das Problem bestand darin, dass die Firewall alle https Requests von diesem Server blockiert hatte. Nachdem die Einstellungen in der Firewall angepasst wurden, funktionierte die komplette Installation einwandfrei. Danke und Gruß Flo
Hi, unabhängig davon würde ich in Betracht ziehen solche Serverdienste per Docker aufzusetzen. Das ist in der Regel einfacher, aber vor allem leichter zu Warten. https://docs.gitlab.com/ee/install/docker.html Gruß, Thomas
Thomas-jhfd schrieb: > unabhängig davon würde ich in Betracht ziehen solche Serverdienste per > Docker aufzusetzen. > Das ist in der Regel einfacher, aber vor allem leichter zu Warten. Dann darf man den Inhalt des Containers pflegen und zusätzlich sich mit dem Performance Verlust durch Docker beschäftigen, insbesondere hinsichtlich Netzwerk ist das nicht sonderlich toll. Flo schrieb: > dass die Firewall alle https > Requests von diesem Server blockiert hatte. Den Fall gar nicht berücksichtigt, das wird dann ein art Captive Portal mit der Meldung gewesen sein. Dass sowas über HTTPS ausgeliefert wird ist etwas ungünstig...
Thomas-jhfd schrieb: > solche Serverdienste per > Docker aufzusetzen. > Das ist in der Regel einfacher, aber vor allem leichter zu Warten. Das klingt hier aber anders https://about.gitlab.com/install/#debian Recommended installation method Official Linux package This is the recommended method for getting started. The Linux packages are mature, scalable, and are used today on GitLab.com. ... Linux installation is quicker to install, easier to upgrade and contains features to enhance reliability not found in other methods. I
Flo schrieb: > https://packages.debian.org/bullseye/all/ca-certificates/filelist Mit
1 | dpkg -L ca-certificates |
kannst Du auch einfach mal schauen, welche Dateien in dem installierten Paket enthalten sind.
Klaus Klaut schrieb: > Thomas-jhfd schrieb: >> unabhängig davon würde ich in Betracht ziehen solche Serverdienste per >> Docker aufzusetzen. >> Das ist in der Regel einfacher, aber vor allem leichter zu Warten. > > > Dann darf man den Inhalt des Containers pflegen Nein, das ist ja gerade der Trick an der Sache. Man zieht einfach das aktuelle Image, stoppt den alten Container und startet mit dem aktuellen Image einen neuen Container, fertig. Andersherum ist die Pflege einer manuellen Installation WESENTLICH aufwändiger -- sogar dann, wenn man sie automatisiert hat. > und zusätzlich sich mit > dem Performance Verlust durch Docker beschäftigen, insbesondere > hinsichtlich Netzwerk ist das nicht sonderlich toll. Der Performance-Verlust geht im statistischen Rauschen unter.
Karl Käfer schrieb: > Nein, das ist ja gerade der Trick an der Sache. Man zieht einfach das > aktuelle Image, stoppt den alten Container und startet mit dem aktuellen > Image einen neuen Container, fertig. > Andersherum ist die Pflege einer manuellen Installation WESENTLICH > aufwändiger -- sogar dann, wenn man sie automatisiert hat. Blablabla. Wir sprechen über Gitlab. Da hat man eh mehrere Instanzen. Da wird Docker wieder interessant... Unattended Upgrades kann auch eine Installation unter z.B. Ubuntu mit dem offiziellen Repository problemlos aktualisieren. Karl Käfer schrieb: > Der Performance-Verlust geht im statistischen Rauschen unter. Hahahaha. Sicher, du wirst in deinem Heimnetzwerk den Unterschied nicht merken mit deinen 10Mbit/s Token Ring Halb Duplex Netzwerk, aber im Büro mit 10GE merkt man den Unterschied.
Wenn die Distribution das gut unterstützt mag das Ok sein. Aber spätestens wenn weitere Dienste dazu kommen möchte ich eine saubere Abstraktion nicht mehr missen. Die Compose Files liegen in Github und die Volumes werden regelmäßig mittels Borgbackup verschlüsselt in die Cloud gesichert. So lässt sich das überall wo Docker läuft mit wenig Handgriffen innerhalb kurzer Zeit wiederherstellen. Super. Die Images werden in der Regel direkt von den Entwicklern gepflegt. In den Conatinern fummel ich da gar nichts rum. Performanceverlust ist sicher deutlich messbar, kann nicht entscheident sein, denn das wird genau so auch bei den großen Enterprise Anbietern gehostet (mit Kubernetes für Load Balancing und hohe Verfügbarkeit). Für mich überwiegen die Vorteile deutlich.
Thomas-jhfd schrieb: > Performanceverlust ist sicher deutlich messbar Innerhalb und ausserhalb eine Containers ist man im kernel auf exakt der gleichen Abstraktionsebene, es gibt immer einen mount namespace, einen pid namespace, einen netzwerk namespace, etc. Ok, docker packt noch eine bridge rein, und verwendet overlays. Aber dank cacheing und zero copy zeug, dürfte der overhead heute insgesamt ziemlich gegen 0 gehen.
Klaus Klaut schrieb: > Blablabla. Ach, Hans, VMFreak, Laurenz, CISO, hast Du schon wieder einen neuen Nick? > Karl Käfer schrieb: >> Der Performance-Verlust geht im statistischen Rauschen unter. > > Hahahaha. Sicher, du wirst in deinem Heimnetzwerk den Unterschied nicht > merken mit deinen 10Mbit/s Token Ring Halb Duplex Netzwerk, aber im Büro > mit 10GE merkt man den Unterschied. Mit einem Redis-Cluster in gebondeten 2x100GbE merk ich nix davon.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.