Changing hostname

installation
1

I exported a bit old version of Discourse container and the Discourse docker files from a running instance and imported it on a different server.
I need to change Discourse hostname to match the new server.

  • Is there a way to make the new DISCOURSE_HOSTNAME: effective without a rebuild?
  • If I must rebuild, will that fetch the latest version from main branch and override the current version I have? because I need run exactly the current version.
2

Hi Islam :slight_smile:

Not that I know.

Yes, it will.

You may find related information here for what you want to achieve: Search results for 'install version discourse' - Discourse Meta

3

You’d need to change stuff in the let’s encrypt config, which is (at least part of) why you need to rebuild.

Why not upgrade? That’s what you really need to do. Just how old is it?

But you could contrive to pin discourse_docker (aka /var/discourse and the Discourse version that you’re on. You might also need to pin all of the plugins.

If you’ve got something else doing the https resolution then you might be able to avoid the rebuild and just do the other stuff in Change the domain name or rename your Discourse.

4

I need to have the same version on that instance to test upgrading to the latest version so if succeeded, will preform the upgrade on production.

If you’ve got something else doing the https resolution then you might be able to avoid the rebuild and just do the other stuff in Change the domain name or rename your Discourse.
HTTPS is handled on a load balancer, but that link saying I have to rebuild after modifying app.yml.

  • So if I will pin the versions, for discourse_docker, I should checkout the current commit hash?
  • And for Discourse app inside the container, I should also set it’s current commit hash using version: <commit_hash> in app.yml?
  • What about plugins?
5

It’s a good bet that if you install the current version on the testing server and restore the database to it that you can upgrade the production server.

What you’re proposing is likely several hours of work, has a bunch of confusing little bits that will be very hard to describe in a forum, and isn’t going to prove anything that restoring the production database to the new server isn’t going to do.

Just point the staging server and the production server to the same S3 backup bucket, backup production and restore it to the staging server. Going forward, they’ll be in parity and you can upgrade staging and production in rapid succession.

1 Like
6

I triggered a rebuild but this is what I got:

I, [2023-04-07T19:17:58.707365 #1]  INFO -- : > cd /var/www/discourse && gem install bundler --conservative -v $(awk '/BUNDLED WITH/ { getline; gsub(/ /,""); print $0 }' Gemfile.lock)
ERROR:  Could not find a valid gem 'bundler' (= 2.3.4), here is why:
          Unable to download data from https://rubygems.org/ - Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)

However I can curl rubygems.org from host.

7

Any suggestions on the above error?

8

Did you to a command line rebuild? Is this a standard install?

9

Yes, rebuild command and also initiated upgrade from GUI gave the same error.

Retrying fetcher due to error (4/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/ due to underlying error <Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>

There was an error installing the locked bundler version (2.4.4), rerun with the `--verbose` flag for more details. Going on using bundler 2.3.6.
Fetching source index from https://rubygems.org/

Could not fetch specs from https://rubygems.org/ due to underlying error
<Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>
Docker Manager: FAILED TO UPGRADE