Discourse in a closed intranet

I have been trying to get Discourse running in a closed Intranet. Unfortunately it seems a bit of a futile endeavor. I have got it working in my Lab which does have internet access. But when I move my VM over to my intranet I need to make changes to the app.yml requiring a rebuild. When I do it tries to access github, to pull pups and then fails to bootstrap. Anyway to get Discourse as an offline installer?

I really like Discourse and I would really like to get it to run in my environment. I really don’t want to have to resort to phpBB instead :grimacing:

3 Likes

Running Discourse in production using our recommended docker install requires internet access. If you want to do an offline install, you will have to install it manually.

There doesn’t seem to be any official documentation as to how to do this. Guess I’m on my own? Any hints of some good references to get started, if that is the case? Thanks

Ok, this seems like the starting point I was looking for discourse/DEVELOPER-ADVANCED.md at master · discourse/discourse · GitHub

Just as an aside, you should really consider allowing outbound Internet access from your internal servers, if you can. It’s highly useful for installing the OS updates, NTP time synchronization, etc. that you need to run a secure web server. (Unless you have these resources already mirrored on your local network.)

3 Likes

I wish I could but it is unfortunately it’s a company requirement. They use a GPS based NTP, and mirrored local only repositories. It is a pain… But can’t get around it.

Just hack up the installer scripts to point to your local mirror of github and dockerhub rather than github.com and hub.docker.com.

6 Likes

Okay, was able to get it installing, thanks @mpalmer that was a better solution. Working fine on my test environment (which has internet access). Having an issues with discourse.conf in the docker container in the offline environment. Seems to want to access avatars.discourse.org, getting errors on line 220 of the that config file. Not sure if this is the reason nginx is not answering http requests in my offline docker container. But this is the only error showing in the error.log file. After further analysis the nginx service is not running in the intranet container, but it is working fine in the lab machine with the hacked install script.

A good documentation for this would be a huge win. I think a lot of companies might be interested in Discourse if it was easily able to run in an intranet environment. I’d be highly interested in finding out more

3 Likes

Did some more testing. I seem to have found what may be a bug. It seems that if you have an intranet discourse site, even though it might have internet access, will no longer work if two factors come into play:

  1. Your internet access is down (for whatever reason)
  2. You decide to restart your discourse container during the same period.

If so, you will have a non working discourse site until your internet comes back. This does not seem reasonable, what if it last a few days?

That’s a central service for performance reasons, uncheck external system avatars enabled in site settings to fall back to the old, non-centralized system.

2 Likes

@fefrei any way to disable that in a file or is it stored in the database?

Site settings are stored in the database.

1 Like

This actually did not fix the problem. Inserted the setting in the database and it was still failing. Everything was pointing to an issue with nginx. nginx -t fails if the container cannot access the internet. Changed the discourse.conf file at line 220.

from:

proxy_pass https://avatars.discourse.org/;

to:

proxy_pass https://localhost/;

ran nginx -t and it passed

then sudo service nginx start it started fine.

Intranet site is now up. Gonna test and see if I still have any issues. Thanks for everyones help.

https://meta.discourse.org/t/restarting-container-when-internet-is-down-causes-discourse-to-fail/42615?u=carbo

1 Like

Hi Carbo,

I am trying to accomplish the same thing. Do you still have any notes from your success or any resources that you used? DId you have to crawl every discoursexxx.git file and replace references to outside resources?

What have you tried so far, and in what way did it not work?

I have tried building discourse with docker in an open environment. Running “docker save” of that image and copying it to a closed environment. I then installed docker in the closed environment and ran “docker load” of that image. and "docker commit --change “ENV” to change the Discourse hostname/database/ and other relevant environmental variables to reflect the settings in the closed environment. I think took the updated image and created a new container from it. I ran “docker start new_container” but it only runs for a few minutes and crashes. It trying to contact github.com for the pups.git repo. I then went into the container, changed /pups/.git/config to point towards a local git clone and everything SEEMS to be working but attempts to query the host gets “connection refused” I don’t see anything in the log file. SInce I’m in a closed environment I can’t rebuild the app.

Do I need to copy the /var/discourse and /var/lib/docker directories over to the new server as well along with a copy of the docker.io/discourse/discourse image?

I installed a local git server in the intranet and cloned the repositories on the git server and then modified the install scripts to point to the local git server. This is the best solution I found, and it allows you to rebuild the app if you need to make config changes.

Saving and load the created docker container will not work as you intend. Since all the data is on volumes which are mapped to the container. So you would need to copy all those volumes which will complicate your install immensely. I suggest the local git server. The other option I used before, was to create a VM on a XenServer on my internet environment and configured it completely on that side and then export it. Then import it in my intranet environment. In order to upgrade versions, I would back up the site through the Discourse backup tool. Recreate the VM with the new version of Discourse. Then export, import and restore the backup… Was also a bit messy… Again the git option seems the best.

1 Like

It’s good to know I’m on the right path. That’s exactly what I’m trying to do now. I’m basically crawling through all of the install and Dockerfiles in each file/directory under /var/discourse. It’s tedious since the install pulls from multiple sources, not just github

Did you pull down discourse/discourse:1.3.10 from docker.io and then “docker save” it to be loaded on your closed intranet?

Been a while… Now that you mention it. I actually revamped the DockerFile and maintain my own, I have a local Ubuntu Repo server. I had to modify the launcher to point to my version. Yes, you will need to pull down discourse/discourse:1.3.10 to your server, if you don’t build and maintain your own version. I really need to document all of this :grin: