J’installe Discourse dans un environnement Intranet. Il m’arrive parfois de rencontrer cette erreur lors du processus de reconstruction :
Pups::ExecError: cd /var/www/discourse & su discourse -c ‘bundle install --retry 3 --jobs 4’ a échoué avec le retour #<Process::Status: pid 645 exit 17>
Emplacement de l’échec : /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn’
exec a échoué avec les paramètres {“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 a échoué avec le code de sortie 17
** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d’erreur précédents, il peut y en avoir plus d’un.
./discourse-doctor peut aider à diagnostiquer le problème.
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: la base de données « discourse » existe déjà
2024-03-29 14:58:21.298 UTC [55] postgres@postgres STATEMENT: CREATE DATABASE discourse;
createdb: error: la création de la base de données a échoué : ERROR: la base de données « discourse » existe déjà
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: le rôle « discourse » existe déjà
2024-03-29 14:58:21.334 UTC [59] postgres@discourse STATEMENT: create user discourse;
ERROR: le rôle « discourse » existe déjà
et puis une autre erreur avant le 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 Impossible de vérifier le certificat SSL pour https://rubygems.org/.
Il est possible que vous subissiez une attaque de type man-in-the-middle, mais il est plus probable que votre système ne dispose pas des certificats CA nécessaires à la vérification. Pour plus d’informations sur les certificats OpenSSL, consultez OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
Retrying fetcher due to error (3/4): Bundler::Fetcher::CertificateFailureError Impossible de vérifier le certificat SSL pour https://rubygems.org/.
Il est possible que vous subissiez une attaque de type man-in-the-middle, mais il est plus probable que votre système ne dispose pas des certificats CA nécessaires à la vérification. Pour plus d’informations sur les certificats OpenSSL, consultez OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
Retrying fetcher due to error (4/4): Bundler::Fetcher::CertificateFailureError Impossible de vérifier le certificat SSL pour https://rubygems.org/.
Il est possible que vous subissiez une attaque de type man-in-the-middle, mais il est plus probable que votre système ne dispose pas des certificats CA nécessaires à la vérification. Pour plus d’informations sur les certificats OpenSSL, consultez OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
Impossible de vérifier le certificat SSL pour https://rubygems.org/.
Il est possible que vous subissiez une attaque de type man-in-the-middle, mais il est plus
probable que votre système ne dispose pas des certificats CA nécessaires à la vérification. Pour
plus d’informations sur les certificats OpenSSL, consultez OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
I, [2024-03-29T14:59:49.328710 #1] INFO – : Récupération de l’index des sources depuis https://rubygems.org/
C’est le problème. Il semble que votre connexion Internet bloque l’accès à rubygems.
Discourse nécessite https et l’installation standard doit être accessible via une IP publique pour obtenir un certificat. Vous aurez probablement des problèmes à cause de cela également.
Si vous ne pouvez pas ouvrir le serveur à tous les sites, vous devrez lire les messages vous-même et ouvrir chaque site chargé un par un. Avec un délai de 6 jours, je m’attendrais à ce que cela prenne un mois ou deux.
Faire fonctionner Discourse sur un intranet privé qui ne peut pas accéder à Internet n’est pas vraiment pris en charge. Vous pourriez être en mesure de construire une image ailleurs, puis d’essayer de la lancer sur votre intranet. Vous devrez toujours trouver votre propre moyen d’obtenir des certificats https.
J’ai créé une image depuis l’extérieur de l’intranet sur mon PC
Je l’ai téléchargée dans un dépôt
J’ai récupéré l’image sur la VM dans l’intranet, puis j’ai démarré un conteneur ./launcher start app --run-image my image
Le conteneur fonctionne bien, mais il semble que les ports 80/443 ne soient pas accessibles (j’ai vérifié avec nmap, ils sont ouverts !). Je ne peux pas accéder à l’application depuis le navigateur. Lorsque je tape : curl -v localhost:80, j’obtiens cette erreur.
* Utilise la variable d'environnement proxy no_proxy == 'localhost,127.0.0.1,.laposte.fr'
* Tentative de connexion à 127.0.0.1:80...
* Connecté à localhost (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.81.0
> Accept: */*
>
* Échec de réception : Connexion réinitialisée par l'homologue
* Fermeture de la connexion 0
curl: (56) Échec de réception : Connexion réinitialisée par l'homologue
Ma supposition est que vous n’avez pas de certificats et que nginx échoue. Vous devez supprimer les modèles ssl et let’s encrypt et construire une nouvelle image. Ensuite, vous aurez besoin d’un proxy inverse qui a un certificat.
Vous pourriez plutôt être en mesure d’utiliser un certificat que vous avez généré vous-même. Je pense qu’il y a toujours un sujet sur la façon de le faire (d’avant l’existence de let’s encrypt).
Vous pouvez consulter les journaux nginx pour voir les erreurs.
Je n’ai pas activé le modèle letsencrypt dans mon fichier app.yml, donc je ne devrais pas être concerné par cette demande de suppression, n’est-ce pas ? J’utilise un VIP frontal avec son propre certificat.