I’d rather not have nginx → varnish → apache → nginx
To be clear: do you think it would be safer for me to update the ‘image/base/install-nginx’ script to compile nginx on the Discourse docker container with mod_security support rather than update the container to run the Discourse vhost behind apache (as opposed to Nginx)? If so, what are the risks of me modifying the install-nginx script? How could it break my Discourse install in the future?
PSA: Everything you are proposing to do, while technically feasible is completely unsupported. We can’t reasonably support every possible combination people come up with to serve Discourse on the web. So the support here on this forums are restricted to installs following the https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md guide.
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>
@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.
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).
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?
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.
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 actualinstall-nginx script used by the container on bootstrap is modified?
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.
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
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.
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