Install Discourse on an isolated CentOS 7 server

@malec today I ran into the same issue, and managed to find a way around it, but as usual it wasn’t pretty.

It looks like the rake task added by @nbianca in PR #7340 checks the modification date on the GeoLite files included in the Discourse base image, and if they’re older than 2 days, will attempt to download them again during bootstrap; see the relevant code here.

The added task could arguably handle failure more gracefully, e.g. by printing a warning and failing back to using the already-present files, but right now it just fails bootstrap.

So here is what I did, hoping it helps you and anyone else stuck with this:

Download the GeoLite2-ASN.mmdb and GeoLite2-City.mmdb files and store them on your Discourse host; I put them under /root/local/maxmind.com.

Map this folder as a Docker volume in your app.yml file, e.g via:

    - volume:
      host: /root/local/maxmind.com
      guest: /local-maxmind.com

Add a bundle_exec hook to your app.yml file, to be run as early as possible:

run:
  - exec:
      cd: $home
      hook: bundle_exec
      cmd:
        - mkdir -p $home/vendor/data
        - ls -la $home/vendor/data
        - cp -rv /local-maxmind.com/*.mmdb $home/vendor/data/
        - ls -la $home/vendor/data

This copies the GeoLite files from your host, overwriting the ones already present in the Discourse base image.

You can verify in the bootstrap log, using the output of the two ls -la statements, whether the files have been overwritten. The first ls -la output will look something like:

I, [2019-05-11T11:06:39.528299 #6]  INFO -- : > cd /var/www/discourse && ls -la /var/www/discourse/vendor/data
I, [2019-05-11T11:06:39.533286 #6]  INFO -- : total 65948
-rw-r--r-- 1 root      root       6473392 Apr 29 10:37 GeoLite2-ASN.mmdb
-rw-r--r-- 1 root      root      61106856 Apr 29 10:37 GeoLite2-City.mmdb

Note that the modification time is Apr 29, i.e. older than 2 days. The rake task would attempt to download these files again.

After overwriting the files, the second ls -la output will instead look something like this:

I, [2019-05-11T11:06:39.533336 #6]  INFO -- : > cd /var/www/discourse && cp -rv /local-maxmind.com/*.mmdb /var/www/discourse/vendor/data/
I, [2019-05-11T11:06:39.604593 #6]  INFO -- : '/local-maxmind.com/GeoLite2-ASN.mmdb' -> '/var/www/discourse/vendor/data/GeoLite2-ASN.mmdb'
'/local-maxmind.com/GeoLite2-City.mmdb' -> '/var/www/discourse/vendor/data/GeoLite2-City.mmdb'

I, [2019-05-11T11:06:39.604695 #6]  INFO -- : > cd /var/www/discourse && ls -la /var/www/discourse/vendor/data
I, [2019-05-11T11:06:39.608645 #6]  INFO -- : total 66028
-rw-r--r--  1 2000 2000  6492486 May 11 10:52 GeoLite2-ASN.mmdb
-rw-r--r--  1 2000 2000 61030828 May 11 10:52 GeoLite2-City.mmdb

The mmdb files are now up-to-date as far as the rake tasks are concerned. This will allow bootstrap to carry on without trying to download them.

Additionally, I also added an environment variable in my app.yml file:

env:
  DISCOURSE_REFRESH_MAXMIND_DB_DURING_PRECOMPILE_DAYS: 3650

I was trying to override the default setting of 2 days for GeoLite checks, but this appeared to not have any effect in my testing. Your mileage may vary.


/cc @sam @nbianca @codinghorror – a better (or at least more graceful) way to handle GeoLite updates, or the ability to disable this during bootstrap would be greatly appreciated. Both GeoLite files are already present in the Discourse base image, and for some use cases (mine is on-premise use in an isolated network environment), fresh copies are really not essential.

It would be really good to have an opt-in bootstrap option to just use the files embedded in the base image, without downloading. Or at least to not fail bootstrap when the GeoLite download fails; printing a warning and continuing with the files in the base image would be, in my mind, better than the current experience.

2 Likes