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).
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
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.
