The user is trying to install Discourse on an intranet environment but encounters a bootstrap failure with exit code 17 during the rebuild process. The error is traced to a bundle install failure due to SSL certificate verification issues with https://rubygems.org/, indicating that the system lacks the necessary CA certificates. peyrusse notes that the intranet blocks external URLs, and even after opening access, the issue persists. pfaffman explains that Discourse requires internet access for SSL certificates and that private intranet setups are unsupported. The user then attempts to bypass this by building an image externally and deploying it on the intranet, but the app remains unreachable via ports 80/443. pfaffman suggests that the issue may stem from missing SSL certificates, as nginx fails without them, even though the Let’s Encrypt template is not enabled. The user clarifies they use a front-end VIP with its own certificate, but the internal container still fails to serve the app. peyrusse confirms the Let’s Encrypt template is not active, implying the problem lies in certificate configuration or proxy setup.
I’m installating Discourse on an Intranet environment. It happens sometimes that i encounter this error during rebuild process :
Pups::ExecError: cd /var/www/discourse && su discourse -c ‘bundle install --retry 3 --jobs 4’ failed with return #<Process::Status: pid 645 exit 17>
Location of failure: /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 ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
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/
This is the problem. It looks like your internet is blocking access to rubygems.
Discourse requires https and the standard install needs to be accessible via public ip to get a certificate. You’ll likely have trouble because of this as well.
If you can’t open the server to all sites then you’ll have to just read the messages yourself and open each site that is loaded one-by-one. With a 6 day turnaround, I’d expect it to take a month or two.
Making Discourse work on a private intranet that can’t access the internet isn’t really supported. You might be able to build an image somewhere else and then attempt to launch it on your intranet. You’ll still have to find your own way to get https certificates.
I have created an image from outside intranet on my PC
I have uploaded it to a repository
I have pulled the image on the VM on Intranet and then started a container ./launcher start app --run-image my image
The container is working fine but it seems port 80/443 are not accessible (i have checked with nmap they are opened!). I can’t reach the app from the browser. When i type : curl -v localhost:80 i got this error.
My guess is I that you don’t have certificates and nginx is failing. Your need to remove the ssl and let’s encrypt templates and build a new image. Then you’ll need a reverse proxy that has a certificate.
You might instead be able to use a certificate that you’ve generated yourself. I think there’s still a topic about how to do that (from before let’s encrypt existed).
I have not activated the letsencrypt template on my app.yml file so i should not be concerned by this removal request, no ? I use a front end VIP with it’s own certificate however.