New user invite links only give ERR_SSL_PROTOCOL_ERROR

ematsen · December 7, 2018, 3:28am

Hello everyone–

Summary

New user invite links give a ERR_SSL_PROTOCOL_ERROR even though the rest of the site works fine.

Context

I’ve been running a completely stock Discourse Docker image for about 5 years with no troubles. About a year ago I moved to https with Let’s Encrypt using this guide.

Since then the site has performed well, and existing users can log in and out.

Problem and troubleshooting

As described, new user invite links give a ERR_SSL_PROTOCOL_ERROR even though the rest of the site works fine.

I have run all of the debugging steps in the Debugging section of the Discourse Let’s Encrypt setup guide. Everything ran fine, and the problem persists.

The logs don’t look perfect, though:

warning: nginx: unable to open supervise/ok: file does not exist
[Wed Dec  5 20:41:53 UTC 2018] Reload error for :
Started runsvdir, PID is 1086
ok: run: redis: (pid 1101) 0s
ok: run: postgres: (pid 1096) 0s
rsyslogd: command 'KLogPermitNonKernelFacility' is currently not permitted - did you already set it via a RainerScript command (v6+ config)? [v8.16.0 try http://www.rsyslog.com/e/2222 ]
Server listening on 0.0.0.0 port 22.
rsyslogd: imklog: cannot open kernel log (/proc/kmsg): Operation not permitted.
rsyslogd: activation of module imklog failed [v8.16.0 try http://www.rsyslog.com/e/2145 ]
Server listening on :: port 22.
rsyslogd: Could not open output pipe '/dev/xconsole':: No such file or directory [v8.16.0 try http://www.rsyslog.com/e/2039 ]
supervisor pid: 1099 unicorn pid: 1125

For the first error, I found this post but I am not using a proxy.

Has anyone else run into this problem? I run another site, started a little later, which does not show this problem.

Thank you!

Erick

ematsen · December 6, 2018, 11:42am

More info!

The invites get sent out with a link like forum.mysite.com:80/invites/... but when one removes the :80 the links don’t have the auth error.

So why are we getting :80 in the links?

Thanks!

codinghorror · December 6, 2018, 11:48am

Sounds like you have a bad configuration? What is in your app.yml as far as domain name?

Discourse does not support being run on alternate ports.

ematsen · December 6, 2018, 11:54am

Well, DISCOURSE_HOSTNAME is exactly the name of the site as it should be.

The only place that 80 appears is in this block:

## which TCP/IP ports should this container expose?
expose:
  - "80:80"   # fwd host port 80   to container port 80 (http)
  - "2222:22" # fwd host port 2222 to container port 22 (ssh)
  - "443:443" # https

Thanks!

ematsen · December 6, 2018, 6:04pm

I found that https://www.phylobabble.org/latest.rss has the :80s in the links, and then looking at the relevant Discourse source code I see that it’s being directly put in the RSS via

    <link><%= @link %></link>

so Discourse definitely thinks that my site ends with :80 as suggested, and it’s not some weird DNS problem or something.

I can’t find anything via grepping in /var/discourse that looks out of order.

metasoarous · December 6, 2018, 7:53pm

I think you may have the wrong line @ematsen. I think the broken link is on a line a bit lower down (#15):

github.com

discourse/discourse/blob/acd1693dac1bff6ff50250d942134bc48a27ff14/app/views/posts/latest.rss.erb#L15


    <% site_email = SiteSetting.find_by_name('contact_email').try(:value) %>
    <title><%= @title %></title>
    <link><%= @link %></link>
    <description><%= @description %></description>
    <% @posts.each do |post| %>
      <% next unless post.user %>
      <item>
        <title><%= post.topic.title %></title>
        <dc:creator><![CDATA[<%= "@#{post.user.username}#{" #{post.user.name}" if (post.user.name.present? && SiteSetting.enable_names?)}" -%>]]></dc:creator>
        <description><![CDATA[ <%= post.cooked.html_safe %> ]]></description>
        <link><%= Discourse.base_url + post.url %></link>
        <pubDate><%= post.created_at.rfc2822 %></pubDate>
        <guid isPermaLink="false"><%= Discourse.current_hostname %>-post-<%= post.id %></guid>
      </item>
    <% end %>
  </channel>
</rss>

Looks like the issue may be Discourse.base_url. @codinghorror Is there somewhere we haven’t looked at wherein that might be getting set/modified?

codinghorror · December 6, 2018, 9:21pm

You should not be explicitly setting a port anywhere, that is for sure.

metasoarous · December 7, 2018, 12:37am

I can’t find anywhere that we might be explicitly setting the port anywhere. And to clarify from Erick’s post above, DISCOURSE_HOSTNAME: www.phylobabble.org, which seems as it should be.

I thought for a while that maybe one of the templates getting loaded might be causing the issue, but these should all be exactly as we found them in the discourse docker. For the sake of thoroughness, here are the templates we’re using, all of which should match those here: GitHub - discourse/discourse_docker: A Docker image for Discourse

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/sshd.template.yml"
  - "templates/web.ssl.template.yml"
  - "templates/web.letsencrypt.ssl.template.yml

I tracked down where this Discourse.base_url that pops up in the RSS feed might be coming from and it looks like it’s defined here:

github.com

discourse/discourse/blob/master/lib/discourse.rb#L266-L268


digest = Digest::MD5.hexdigest(ActionView::Base.assets_manifest.assets.values.sort.join)


channel = "/global/asset-version"

Which is in turn defined based on base_uri, defined here:

github.com

discourse/discourse/blob/master/lib/discourse.rb#L251-L253


    target.nil? ? plugin.directory_name : "#{plugin.directory_name}_#{target}"
  end
end

I can’t figure out how either of these would be coming out wrong though. My next thought is to litter that discourse.rb file with print statements to see what’s going on, but any help you could provide in helping us track how those values are being computed would be helpful in us narrowing in on where things are going wrong.

Thanks in advance

codinghorror · December 7, 2018, 12:58am

You are following our official install guide to the letter, yes? This isn’t a problem we see often (or at all, honestly).

Did you do a developer type install where you explicitly overrode the port? That’s only done on developer installs to my knowledge.

ematsen · December 7, 2018, 1:20am

I did follow the install guide to the letter, and the site’s been running beautifully for many years now (thanks!).

I did the most vanilla type install I could do-- definitely not a developer install.

As a crutch, can you think of a way to forward the problematic phylobabble.org:80 requests to just phylobabble.org? We tried mapping ports like so:

expose:
  - "80:22"

which didn’t make a difference.

Falco · December 7, 2018, 1:35am

Can you share the output of:

cd /var/discourse
./launcher enter app
rails c
SiteSetting.port

ematsen · December 7, 2018, 2:05am

[1] pry(main)> SiteSetting.port
=> "80"

Falco · December 7, 2018, 3:28am

Try to clear it please:

#everything above and then
SiteSetting.port = ''
exit
exit
./launcher restart app

ematsen · December 7, 2018, 3:23am

That did it! Thank you so much, @Falco and @codinghorror. I really have been amazed how smooth the admin process is, and Discourse itself is lovely.

system · January 6, 2019, 3:29am

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.