Non-standard port breaks uploads

upload

(Joshua Rosenfeld) #1

Following this guide I setup Discourse alongside multiple existing sites on my server. All the previous sites (as well as Discourse) are able to run, and seem to work fine, but images are broken in Discourse. The images are uploaded to $hostname/uploads, but the correct URL would be $hostname:8888/uploads. I can’t find where in site settings of my yml file to fix this.


(Eli the Bearded) #2

(Joshua Rosenfeld) #3

OK, so if that #howto is not proper practice, do you know how to run Discourse alongside existing Apache sites?


(Eli the Bearded) #4

I don’t think that how-to is by Discourse staff. You could ask in that topic and maybe that would trigger response by the how-to author.


(Rafael dos Santos Silva) #5

From my read of that guide, it uses HAProxy in front of Apache, so Discourse listen on port 80 in the end.


(Joshua Rosenfeld) #6

Then I am obviously doing something wrong…simply loading the hostname puts me at my sites index.html, I have no way of getting to Discourse without a specific port. I must be missing something here…


(Jay Pfaffman) #7

That’s my read too. Discourse is exposed on some other port on the Host, but the proxy needs to map x.example.com to the Discourse instance.

@jomaxro, can you add another domain (like community.example.com) to your config and tell the proxy to proxy requests for community.example.com to localhost:8888? Does that make sense?


(Joshua Rosenfeld) #8

The concept makes sense, but in practice I am lost. Which config am I adding to, apache or haproxy? Also, I don’t have control of the domain, I have xyz.abc.123.edu, and that’s it.


(Jay Pfaffman) #9

It’s in the HAProxy, I believe.

These lines are the magic:

        acl host_discourse hdr(host) -i my_discourse_site.com
        # figure out which one to use
        use_backend discourse_docker if host_discourse

If you have lots of sites, you’ll need to add more acl lines and more use xx if host_yyy lines.


(Joshua Rosenfeld) #10

Here’s my current HAProxy:

        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout http-keep-alive 10s
        timeout check           10s
        maxconn                 3000
frontend http-in
        bind *:80
        default_backend main_apache_sites/html
        # Define hosts
        acl host_discourse hdr(host) -i leet.arc.rpi.edu
        # figure out which one to use
        use_backend discourse_docker if host_discourse

backend main_apache_sites
    server server1 127.0.0.1:8080 cookie A check
backend discourse_docker
    server server2 127.0.0.1:8888 cookie A check

Note, host is not connected to internet, you must be on campus network to connect. All the other (existing) sites are behind Apache, so I don’t think I need more acl lines.


(Jay Pfaffman) #11

I’d be stumped too. :slight_smile:

Oh. Maybe you need to make sure that Apache isn’t doing something to enforce the port mapping? Are you sure that HAProxy and not Apache is what’s answering the door? (Maybe shutdown apache, restart HAPRoxy and then start apache?)


(Matt Palmer) #12

I’m not understanding the root problem. Why would "the correct URL would be $hostname:8888/uploads – all access to the site should be via HAProxy, as I understand it, so why would the correct URL have the port in it?


(Joshua Rosenfeld) #13

I think I’m causing all the confusion here as I’m the one confused. Let me try and clear things up.

##Before Discourse:
3 sites were hosted on a local server, http://leet.arc.rpi.edu. quicklogs, mediawiki, and printers were located at /quicklogs, /wiki, and /printerpicker respectively. There was also an index.html at the root of the server which included links to each of the 3 sites, as well as a few external resourses.

##Discourse Install:
Installed Discourse using the 30-minute guide, then followed above linked guide to put alongside existing sites. End goal is for staff to continue using “leet” as their homepage, and linking to each tool. As such, Discourse would exist (somewhere) and would be linked by the index.html.

##Problem:
Currently I can only access Discourse by adding :8888 to the url. I am unsure how to access it otherwise.


(Matt Palmer) #14

OK, what you need then is not the subdomain install you’re kinda-sorta putting together now, but a subfolder install. Then, it’d probably be best just to throw out haproxy altogether and configure Apache to proxy <Location /forum> to localhost:8888 (or wherever you’ve got Discourse mapped to).


(Joshua Rosenfeld) #15

So just to make sure I am understanding completely, I should do the following:

  1. Remove HAProxy entirely.
  2. Remove Listen commands from Apache config files.
  3. Follow Neil’s guide to put Discourse in a subfolder.
  4. Use apache to proxy to Discourse.

(Matt Palmer) #16

A more generalised step 1+2 would be, “revert everything you’ve done according to the “existing apache sites” howto”. But yes, what you’ve described is what needs to be done.


(Joshua Rosenfeld) #17

Matt, thanks for all your help (and Jay, and Rafael). I was able to successfully get my instance up and running, and have run into no further issues thus far!


(Joshua Rosenfeld) #18

…and it looks like I may have spoken too soon.

Unknown if this is related to subfolder install, discourse being on a custom port and proxied, or an actual bug - but when I went to /admin/upgrade and ran an update, the progress bar never filled nor did anything appear in the console below. After waiting 10 minutes, I reloaded the upgrade page and found that it had in fact upgraded.

Any thoughts?


Notifications got stuck a week ago
(Matt Palmer) #19

I’d have to say that by far the most likely cause of that would be a bug in the upgrade UI not handling subfolders with grace and aplomb. Any of my fellow @team members feel like spinning up a scratch subfolder install and seeing if this sucker’s reproducible?


(Rafael dos Santos Silva) #20

I’m no apache expert, but I remeber sam saying that you need to go an extra mile so it plays well with message_bus too.