ich installiere Discourse in einer Intranet-Umgebung. Manchmal tritt während des Rebuild-Prozesses dieser Fehler auf:
> Pups::ExecError: cd /var/www/discourse && su discourse -c ‘bundle install --retry 3 --jobs 4’ failed with return #<Process::Status: pid 645 exit 17>
Ort des Fehlers: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn’
exec failed with the params {“cd”=>“$home”, “hook”=>“bundle_exec”, “cmd”=>[“su discourse -c ‘bundle config --local deployment true’”, “su discourse -c ‘bundle config --local without \"development test\"’”, “su discourse -c ‘bundle install --retry 3 --jobs 4’”]}
bootstrap failed with exit code 17
** FAILED TO BOOTSTRAP ** bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen, es kann mehr als eine geben.
./discourse-doctor kann helfen, das Problem zu diagnostizieren.
6ef3d42536c82021bdb1f24980cbd860572869f207e4eb2001e59e8923b182cf
root@wpyb3816:/var/discourse# cat /etc/docker/daemon.json
I, [2024-03-29T14:58:21.260866 #1] INFO – :
I, [2024-03-29T14:58:21.261079 #1] INFO – : > su postgres -c ‘createdb discourse’ || true
2024-03-29 14:58:21.298 UTC [55] postgres@postgres ERROR: database “discourse” already exists
2024-03-29 14:58:21.298 UTC [55] postgres@postgres STATEMENT: CREATE DATABASE discourse;
createdb: error: database creation failed: ERROR: database “discourse” already exists
I, [2024-03-29T14:58:21.299606 #1] INFO – :
I, [2024-03-29T14:58:21.299710 #1] INFO – : > su postgres -c ‘psql discourse -c “create user discourse;”’ || true
2024-03-29 14:58:21.334 UTC [59] postgres@discourse ERROR: role “discourse” already exists
2024-03-29 14:58:21.334 UTC [59] postgres@discourse STATEMENT: create user discourse;
ERROR: role “discourse” already exists
and then another error before the crash …
[2024-03-29T14:59:48.410149 #1] INFO – : > cd /var/www/discourse && su discourse -c ‘bundle install --retry 3 --jobs 4’
Retrying fetcher due to error (2/4): Bundler::Fetcher::CertificateFailureError Could not verify the SSL certificate for https://rubygems.org/.
There is a chance you are experiencing a man-in-the-middle attack, but most likely your system doesn’t have the CA certificates needed for verification. For information about OpenSSL certificates, see OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
Retrying fetcher due to error (3/4): Bundler::Fetcher::CertificateFailureError Could not verify the SSL certificate for https://rubygems.org/.
There is a chance you are experiencing a man-in-the-middle attack, but most likely your system doesn’t have the CA certificates needed for verification. For information about OpenSSL certificates, see OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
Retrying fetcher due to error (4/4): Bundler::Fetcher::CertificateFailureError Could not verify the SSL certificate for https://rubygems.org/.
There is a chance you are experiencing a man-in-the-middle attack, but most likely your system doesn’t have the CA certificates needed for verification. For information about OpenSSL certificates, see OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
Could not verify the SSL certificate for https://rubygems.org/.
There is a chance you are experiencing a man-in-the-middle attack, but most
likely your system doesn’t have the CA certificates needed for verification. For
information about OpenSSL certificates, see OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
I, [2024-03-29T14:59:49.328710 #1] INFO – : Fetching source index from https://rubygems.org/
Das ist das Problem. Es sieht so aus, als ob Ihr Internetzugang zu rubygems blockiert wird.
Discourse erfordert https und die Standardinstallation muss über eine öffentliche IP erreichbar sein, um ein Zertifikat zu erhalten. Wahrscheinlich werden Sie auch damit Schwierigkeiten haben.
Wenn Sie den Server nicht für alle Websites öffnen können, müssen Sie die Nachrichten selbst lesen und jede geladene Website einzeln öffnen. Bei einer Bearbeitungszeit von 6 Tagen würde ich erwarten, dass es ein oder zwei Monate dauert.
Die Arbeit mit Discourse in einem privaten Intranet, das keinen Internetzugang hat, wird nicht wirklich unterstützt. Möglicherweise können Sie ein Image woanders erstellen und dann versuchen, es in Ihrem Intranet zu starten. Sie müssen immer noch Ihren eigenen Weg finden, um HTTPS-Zertifikate zu erhalten.
Ich habe ein Image von außerhalb des Intranets auf meinem PC erstellt
Ich habe es in ein Repository hochgeladen
Ich habe das Image auf der VM im Intranet heruntergeladen und dann einen Container gestartet ./launcher start app --run-image mein image
Der Container funktioniert einwandfrei, aber die Ports 80/443 scheinen nicht erreichbar zu sein (ich habe mit nmap überprüft, sie sind geöffnet!). Ich kann die App nicht über den Browser erreichen. Wenn ich eingebe: curl -v localhost:80 erhalte ich diese Fehlermeldung.
* Verwendet Proxy-Umgebungsvariable no_proxy == 'localhost,127.0.0.1,.laposte.fr'
* Versuche 127.0.0.1:80...
* Verbunden mit localhost (127.0.0.1) Port 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.81.0
> Accept: */*
>
* Empfangsfehler: Verbindung vom Peer zurückgesetzt
* Verbindung 0 schließen
curl: (56) Empfangsfehler: Verbindung vom Peer zurückgesetzt
Meine Vermutung ist, dass Sie keine Zertifikate haben und Nginx fehlschlägt. Sie müssen die SSL- und Let’s Encrypt-Vorlagen entfernen und ein neues Image erstellen. Dann benötigen Sie einen Reverse-Proxy mit einem Zertifikat.
Sie könnten stattdessen auch ein selbst generiertes Zertifikat verwenden. Ich glaube, es gibt immer noch ein Thema darüber, wie man das macht (aus der Zeit vor Let’s Encrypt).
Sie können sich die Nginx-Logs ansehen, um die Fehler zu sehen.
Ich habe die Let’s Encrypt-Vorlage nicht in meiner app.yml-Datei aktiviert, daher sollte ich mir keine Sorgen um diese Entfernungsanfrage machen, oder? Ich verwende ein Front-End-VIP mit seinem eigenen Zertifikat.