Sto installando Discourse in un ambiente Intranet. A volte riscontro questo errore durante il processo di rebuild:
Pups::ExecError: cd /var/www/discourse & su discourse -c ‘bundle install --retry 3 --jobs 4’ è fallito con ritorno #<Process::Status: pid 645 exit 17>
Posizione del fallimento: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn’
exec è fallito con i parametri {“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 fallito con codice di uscita 17
** FAILED TO BOOTSTRAP ** si prega di scorrere verso l’alto e cercare messaggi di errore precedenti, potrebbero essercene più di uno.
./discourse-doctor può aiutare a diagnosticare il problema.
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/
Questo è il problema. Sembra che la tua connessione Internet stia bloccando l’accesso a rubygems.
Discourse richiede https e l’installazione standard deve essere accessibile tramite IP pubblico per ottenere un certificato. Probabilmente avrai problemi anche per questo motivo.
Se non riesci ad aprire il server a tutti i siti, dovrai leggere tu stesso i messaggi e aprire ogni sito caricato uno per uno. Con un ciclo di 6 giorni, mi aspetterei che ci vogliano uno o due mesi.
Far funzionare Discourse su una intranet privata che non può accedere a Internet non è realmente supportato. Potresti essere in grado di creare un’immagine altrove e quindi tentare di avviarla sulla tua intranet. Dovrai comunque trovare il tuo modo per ottenere certificati https.
Ho creato un’immagine dall’esterno della intranet sul mio PC
L’ho caricata in un repository
Ho scaricato l’immagine sulla VM nella Intranet e poi ho avviato un container ./launcher start app --run-image my image
Il container funziona correttamente ma sembra che le porte 80/443 non siano accessibili (ho controllato con nmap, sono aperte!). Non riesco a raggiungere l’app dal browser. Quando digito: curl -v localhost:80 ottengo questo errore.
* Usa la variabile d'ambiente proxy no_proxy == 'localhost,127.0.0.1,.laposte.fr'
* Tentativo di connessione a 127.0.0.1:80...
* Connesso a localhost (127.0.0.1) sulla porta 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.81.0
> Accept: */*
>
* Fallimento ricezione: Connessione resettata dal peer
* Chiusura connessione 0
curl: (56) Fallimento ricezione: Connessione resettata dal peer
La mia ipotesi è che tu non abbia certificati e che nginx stia fallendo. Devi rimuovere i template ssl e let’s encrypt e creare una nuova immagine. Poi avrai bisogno di un reverse proxy che abbia un certificato.
In alternativa, potresti essere in grado di utilizzare un certificato che hai generato tu stesso. Penso che ci sia ancora un argomento su come farlo (da prima che esistesse let’s encrypt).
Puoi controllare i log di nginx per vedere gli errori.
Non ho attivato il template letsencrypt nel mio file app.yml, quindi non dovrei essere preoccupato da questa richiesta di rimozione, vero? Uso un VIP front-end con il suo certificato.