How to run Discourse in Apache vhost, not Nginx

I resolved setting app.yml (Discouse) like so:
expose:
- "2045:80" # http
- "8443:443" # https

… and my vhost like so:
<VirtualHost *myhostIP*:443>
ServerName forum.domain.org
ServerAlias forum.domain.org

ProxyAddHeaders Off
ProxyPass / "http://localhost:2045/"
ProxyPassReverse / "http://localhost:2045/"
</VirtualHost>

I hope I didn’t misunderstand your question :blush:

1 Like

@ledimeo That’s what @pfaffman suggested, and what I think would be better in this case, to not break things badly in the future when new versions are released. But it seems that he already uses another nginx at the front as a reverse proxy and don’t want:

That said, I think that proxing apache to nginx (even if it would end up with those 4 layers) would at least be more maintainable than trying to change the way discourse works in the official installation.

For this purpose, you should mostly pretend that nginx is inside the “black box” of the docker container and not concern yourself with it.

So: nginx -> varnish -> apache -> Discourse (comprising nginx and unicorn)

(except for configuring it to trust upstream proxy IPs)

3 Likes

So adding apache as a proxy to the Discourse nginx is definitely an option.

I agree that a pro would be making future upgrades easier, and that’s an important point.

But adding another hop to the architecture would not only make debugging issues in the future more complex – I also have concerns about Apache’s performance as a proxy to a web application that uses long polling, as pointed out by @sam in this post from 2016.

I generally prefer nginx to apache, except when it comes to mod_security. It would be fantastic if the OS repos included packages to enable mod_security in nginx like they do for Apache, but currently enabling mod_security on nginx requires compiling nginx from source in both RHEL/Cent and Debian. And I avoid depending on packages compiled from source on production like the plague…

related: I’ve been poking around with the install-nginx script, and I found a minor logic error: the cleanup line that’s supposed to delete the nginx source from /tmp/ actually doesn’t do anything.

There is no /tmp/nginx/ directory: it’s /tmp/nginx-$VERSION/ (at the moment it’s /tmp/nginx-1.17.4/ and there’s also the tarball /tmp/nginx-1.17.4.tar.gz).

I think you mean this instead:

rm -fr /tmp/nginx-${VERSION}*

Unfortunately, my updated /var/discourse/image/base/install-nginx script does not appear to be executed when I run a /var/discourse/launcher destroy app && /var/discourse/launcher/rebuild app.

Is there any reason this rebuild command would not re-execute the updated install-nginx script?

How are you amending the script after the rebuild? With a hook?

vim /var/discourse/image/base/install-nginx

After a rebuild can you still see your changes? Editing files in the image directly like that won’t work.

You need to use hooks to amend the file from your app.yml

Have you worked with docker before?

1 Like

If you aren’t familiar with Docker this is going to be a hard path…

discourse_docker contains the source code for our base docker image that lives in the public Docker registry, and that will never be run locally and the whole reason is having a reusable image.

1 Like

ok. Well, I lied about vim for simplicity. I’m actually running these commands to idempotently & robustly update the script

cd /var/discourse/image/base
cp install-nginx install-nginx.`date "+%Y%m%d_%H%M%S"`.orig

# add a block to checkout the the modsecurity nginx module just before downloading the nginx source
grep 'ModSecurity' install-nginx || sed -i 's%\(curl.*nginx\.org/download.*\)%# mod_security --maltfield\napt-get install -y libmodsecurity-dev modsecurity-crs\ncd /tmp\ngit clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git\n\n\1%' install-nginx

# update the configure line to include the ModSecurity module checked-out above
sed -i '/ModSecurity/! s%^[^#]*./configure \(.*nginx.*\)%#./configure \1\n./configure \1 --add-module=/tmp/ModSecurity-nginx%' install-nginx

# add a line to cleanup section
grep 'rm -fr /tmp/ModSecurity-nginx' install-nginx || sed -i 's%\(rm -fr.*/tmp/nginx.*\)%rm -fr /tmp/ModSecurity-nginx\n\1%' install-nginx

Where should I put these commands so that the actual install-nginx script used by the container on bootstrap is modified?

The container in the host never runs install-nginx as said above.

I’m not sure this topic is particularly useful.

You dislike the architecture of Discourse, won’t accept the word of the developers on the ways in which the product is optimized, you don’t appear to be familar with Docker and by your own admission are lying in your questions which is wasting our time collectively.

This topic already has an #unsupported-install tag because you’re straying far from the scope of the free support provided to the community. If this stuff really matters to you why not start a topic over on #marketplace - then that way you can invest your own money paying a consultant to educate, rather than our time.

1 Like

I haven’t, sorry. So I need to put the above sed commands in the hooks section of app.yml? Is there an example somewhere for how to do that to modify a file in the docker_discourse repo at bootstrap? Currently that section only has a git clone command for plugins.

I could probably drop those sed commands in a cmd section like the git clone is, but I don’t know which dir where the install-nginx script will live…

Also, where does app.yml live? I couldn’t link to the hooks section above as the containers dir is empty in the repo :confused:

All of the documentation to do these things exists here on meta. We all like to skip reading the manual, but in this case you really should be going back to basics.

You’re going about all of this backwards frankly.

I’m going to point back to the #unsupported-install tag - the expectation is that if you decide to deviate from the standard install you will assume the additional technical burden yourself.

How did you install the instance?

Sorry, but I do make an effort to search for documentation before posting. I’d love a Discourse manual, and I’ve read through many of the topics tagged #howo already. Unfortunately, there doesn’t appear to be a Discourse manual…

I do appreciate your help with this, and I’m sure it will help others in the future who are searching for documentation on how to do these things…

First discourse-setup, which ultimately gave me a broken install. Then manually editing app.yml followed by ./launcher rebuild app

I think this is an interesting discussion, just to get to know Discourse better.

I’d go with nginx, maybe modify the app.yml enough to add the mod_security module in the compiling process, and have my own base image built.

Now, Discourse is a complex piece of software, that runs on Rails that is even more complex to deploy easily and consistently, that’s why the staff has gone the extra mile in the Docker image they make.

The image has a lot of blackmagic happening, with tons and tons of optimizations just to run as good as possible in the supported install.

Knowing that, and being able to get all the pieces of the puzzle figured out (like, the 2-3 repositories needed to have Discourse running). It isn’t impossible to get what you want runnig.

Now, Knowing that your setup is nginx -> varnish -> apache, why don’t you run nginx -> varnish -> Discourse having the mod_security added to the base image and setup with hooks.

The likelihood that mod_security will increase your security is very, very, small. The people who maintain Discourse are very concerned with security, so the things that mod_security is supposed to fix are likely taken care of already. Further, the likelihood that if you were to get mod_security added to your image, it will make Discourse inoperable is significantly greater than zero. If you do install mod_security and find that Discourse won’t work, you’ll then be on your own to modify Discourse to work with mod_security and either convince the discourse maintainers that you have found a legitimate security concern or be forced to maintain your own fork going forward.

No good can come from this. It is highly improbable that any good can come from this.

2 Likes

Agreed, another WAF borders on security by obscurity.

Real proactive efforts to keep discourse secure are being made:

2 Likes

This topic has drifted from the original question of running discourse on apache (as opposed to a proxy back to nginx).

But I think a discussion on putting a WAF (mod_security or otherwise) before Discourse is useful to the community, so I’ve created a distinct topic to specifically discuss Discourse + WAF here: