After spending a week finding a solution to installing Discourse alongside Apache, I’m begrudgingly asking for advice on my next steps because it appears that activating an SSL for Discourse behind Apache is virtually impossible given Discourse’s Nginx-biased design.
Current structure of my hosting environment:
Digital Ocean $10 droplet
Ubuntu 18.04
Apache w/ Let’s Encrypt SSL for HTML frontpage
PHP, MySQL, and phpMyAdmin
Webmin (no SSL)
Discourse
I’d like to retain the flexibility of installing WordPress so I’m not convinced Nginx is the route to go as I’ve read Apache maintains better compatibility with WordPress.
My goal: activate an SSL across my entire domain, Discourse included, without needing to branch Discourse off onto it’s own droplet. If this requires limited use of Nginx, fine. I just need an idea of which tutorials to look at to sort this mess.
I am seeking something similar but your are ahead in the process. A few questions that I am not sure about in your configuration if you don’t mind answering.
Do you have a reverse proxy?
Is the reverse proxy doing SSL?
Are the other servers not doing SSL and relying on the reverse proxy to do the the SSL, or are you doing defense in depth with each server doing SSL?
Is communication between reverse proxy and servers done exclusively as sockets and not ports?
FWIW, I have done extensive testing with both Apache2 and nginx as reverse proxies in front of Discourse in production (using unix sockets) and nginx is not “much faster” .
In this configuration, nginx is “slightly faster” and the speed diff is not noticeable to the user.
In addition, Google pagespeed tests in webmaster tools (lightspeed), averaged over time, do not show any significant differences between the two reverse proxies.
This FWIW comment is not based on theory or repeating what others have written; it is based on real world production tests.
We run all our Discourse instances behind Apache2 reverse proxies (originally they were nginx reverse proxies) because we like running many web sites (virtual hosts) on our servers where we have LAMP apps already hosted.
Anyone and everyone who want to use Apache2 as a reverse proxy instead of nginx will be just fine! This fact makes Discourse easily available to a wide base of users / hosts (Apache2 and nginx).
@fzngagan I’m not starting over and that tutorial is for CentOS, when I clearly stated in my post that I’m using Ubuntu.
@EricGT Check out the solution I shared to my own thread because finding support if you use anything other than Nginx or CentOS is virtually impossible — as evidenced by this thread where I’ve received no answers to my question but instead an off-topic debate about Apache-v-Nginx.
That very well may be the case but Apache is more widely supported. Discourse is the only forum software that essentially forces Nginx upon its users. This is why I’d prefer to stick with Apache because it’s more common, easier for new users, and support will be much easier to find. “Tuning” isn’t something I’m interested in.
Yet the Discourse community actively discourages it and refuses to provide support for people who want to do that, with the exception of linking to unsupported tutorials. I’ve created multiple threads and asked even more questions but you’re the only one who has come remotely close to providing support (in a different thread) by sharing your configuration and as a novice I was expected to decipher and apply it to my own. Everything else has been “check out this outdated tutorial” or off-topic banter.
Well, as we clearly state multiple times, there’s a limit to what we can support for free here due to time and sanity constraints. That’s why we have a standardized install which works well for 95% of the people that try it, and we fully support that.
If you’d like to look into paid support options for customized installs, I recommend #marketplace.
This forum is largely peer-to-peer so your statement doesn’t make any sense whatsoever. Furthermore, I’ve yet to ask a complex question, just clarification or an update to existing tutorials that are continuously linked to despite being outdated or incorrect. I had get assistance from DigitalOcean, a hosting provider, to get a proper reverse proxy. That’s mind-blowing, even for open-source software.
Your response gives me the impression that “support” here is merely an upselling charade.
First of all, we use Discourse in production behind an Apache2 reverse proxy (in more than one instance) and we had zero problems setting it up; other than the normal “Google when you need help” which everyone does without hesitation.
Second, I have never asked the Discourse team or anyone on meta to support Apache2 as our reverse proxies because this configuration is not officially supported. Discourse does not (to my knowledge) “officially” support multi-container configurations, reverse proxies (Apache2), Kubernetes, Docker Swarm, and a nearly infinite number of other configurations. It is understandable and correct that the Discourse team, who gives this great software away for free and open sources all the code, every commit on Github, to limit their “officially supported configurations.” I thought Jeff summarized this nicely and very correctly:
Well, as we clearly state multiple times, there’s a limit to what we can support for free here due to time and sanity constraints. - Jeff A.
Third, Discourse does provide a number of tutorials for “unsupported” configurations, like for Apache2 as a reverse proxy; however, setting up a reverse proxy is not a “Discourse task” per se. Setting up a reverse proxy is a “generic sys admin task” which is basically the same task for any back-end app, including Discourse.
We run Apache as a reverse proxy in front of a number of web applications including Discourse, Docker Registry, and other Docker containers and apps. The use of Apache2 (or nginx) as a reverse proxy is not germane to Discourse. It is a generic sys admin task.
Fourth. There is a wealth of information on the net about how to set up Apache2 as a reverse proxy for an application. It is totally unnecessary nor useful to your cause, to bully the Discourse team over this issue. Bullying people and using terms like “charade” is both inaccurate and not helpful to your cause (or to anyone here).
So, to summary for you @OrbitStorm (this is my last post on your topic, so please read carefully) what has been said before, including the kind and patient words of J. A., you have many choices.
You can easily go to the net and learn how to set up Apache2 as a reverse proxy (this is what we did), and it’s fun and free for you to learn to do this generic sys admin task.
You can hire someone to do this for you if you are unwilling to learn, or cannot “figure it out” on your own or do not have the time.
You can post here and rant and rave, calling meta and this forum a “charade” and hurling insults at everyone to try to bully them to support you personally in an unsupported configuration.
I strongly recommend, as a Discourse user and many decades sys admin, you not choose #3 (the bullying and intimidation is not going to work with the meta team, this I can assure you); and to consider #1 if you don’t want to spend any money for help.
Setting up Apache2 as a reverse proxy for Discourse is really quite easy. There are some Discourse meta posts on this (some current, some dated) and there are countless tutorials on the net about how to set up Apache2 as a reverse proxy for a web app. The technique is the same. I recommend exposing a unix socket when running in reverse proxy mode.
Honestly, It is fun to set up Apache2 as a virtual host reverse proxy to Discourse. Why make it stressful and post insults at the guys who created this great software and give it away for free? Discourse is a free gift! If you want to configure Discourse other than the officially supported configurations, no one is going to stop you!
In closing @OrbitStorm, I strongly advise you (speaking as a Discourse user, not a team member), to change your approach of bullying on meta for support. Like I said, I run Discourse in “not officially supported” configurations and have posted updates and code here to help others (giving back to this great community). I have already posted working code which is easy to follow to setup Apache2 as a reverse proxy, as have others before me.
Kindly choose either #1 (do it yourself) or #2 (hire someone to do it); and please drop your current approach of #3 (intimidating, bullying and insulting the meta team). If you want to choose #3, go post over at our unix and linux forums and you can bully me over there if you want, all you want
You put together this wall of text in response without ever actually addressing the original topic, in some vain effort to white-knight something that isn’t even being attacked. You actually labeled me a “bully” (lol?) because I responded to off-topic gibberish from a guy who peppered me with ad hominem about intelligence and made this thread his soapbox for Nginx (comments that have been conveniently deleted to bury evidence of the toxic nature this forum breeds toward new users). Your first post was not much different as it answered my question without actually answering it. You’re part of the problem.
You keep speaking of obligation yet, here you are, persistently responding to my threads just to be argumentative (as Stephen had). I wasn’t aware that a rule existed prohibiting me from asking for support for a popular hosting configuration (W3Techs was cited earlier and it shows 67% share for Apache). You could have simply left my threads unanswered if you didn’t approve but you chose to be belligerent and derail the conversation.
You’re intentionally misrepresenting my words because I’m not conforming to the status quo of accepting an outdated tutorial and then never returning — a factor in why virtually all of the threads regarding this setup are left unresolved (i.e. bullying from guys like you). Do you really think I didn’t do my due diligence before posting? I accepted what I knew was coming but hoped that others who may be in my position (like EricGT) could offer something of value before it could be steamrolled into oblivion with pompous “answers”.
I’ve been in game development for 16 years and have never experienced such an insane level of unprofessionalism and pettiness as I have here in just five short days. This is some Reddit-level corniness; an absolute joke.
I fail to see why the ssl configuration has to do with the apps behind the proxy ,
as long as the ssl template is disable in the app.yml ? nginx or apache or haproxy or traefik, they all have the same snippet/serverblock/virtualhost concept where basically you specify ssl on, then where your certificates are located on your host and a few ssl parameters, here be dragons maybe?
I think the solution you are looking for in not discourse related but apache related, and I believe that any out off the box working ssl apache config with virtual host will work fine with discourse, as it has worked with others reverse proxies, but I might be a bit optimistic .
Though I remember having an issue with the ciphers maybe, you want to be sure to copy/paste carefully (the line is very long) those in use within the docker container.
About this slippery slope, i think it’s kind of skiing off-track, it’s great but it’s very frowned upon by the mountain rescue, and I admit reasonably differently when you fall in a ravine while still learning whether being an accomplish skier.
Please, professional or not, be kind to the
,
.