I don’t think that’s the case anymore.
https://github.com/discourse/discourse_docker/commit/026a664e77844c7b0d67a5609f08e67f1e436d5f
3 Likes
Oh. Sorry. I missed that change.
So if the user does not provide a let’s encrypt notification email address, discourse-setup now blindly enables let’s encrypt without verifying that the domain resolves to the current server. But if you do provide an email address then it does the check. This doesn’t seem like a very good idea.
Why force https when they don’t have a valid domain name? If the plan is to force everyone to use https all the time, then we should test if the domain name is valid and then refuse to run rather than give them a broken install.
The way that it works now, if you don’t provide a let’s encrypt email address and the domain doesn’t resolve to the server then discourse-setup appears to succeed, and it cranks up a web server that won’t accept connections because nginx can’t find a certificate. I think a better thing to do is to not ask for a let’s encrypt email address, use the (first?) developer email for let’s encrypt and still do the DNS test, but now this doesn’t belong in this topic.
2 Likes
No that’s not how let’s encrypt works. The email has nothing to do with domain validation. It’s used to alert the user if their certificate is due to expire and can’t be renewed. Validation is always done by DNS.
Let’s Encrypt can’t issue a certificate for an address which doesn’t meet the requirement for validation. If it did then the whole LE scheme would implode overnight.
4 Likes
No. It’s how discourse-setup works, or used to. It used to protect users from requesting a certificate when it was pretty sure that it would fail. Now, it’ll move ahead, request a certificate when it can’t possibly succeed, and not have any way of reporting to the user that it didn’t work, so it now fails silently with no warning.
1 Like
Again, why would it fail? Email isn’t a requirement for domain verification.
Failure never generated an email either.
The email is only there to tell the user later on if Let’s Encrypt is failing to renew and a cert is due to expire. If the cert renews without problem they’ll never see an email.
I don’t think that was the intent of the change. The intent was to enable SSL regardless of if an email is provided. We should still check the domain resolution cc @Falco
2 Likes
It will fall if the domain name doesn’t resolve to the host. The email address doesn’t matter, but if there is one Discourse setup will warn the user if the address doesn’t resolve.
4 Likes
So I made some changes in a branch. Here is how it is going to work:
Using a wrong hostname:
root@droplet:/var/discourse# ./discourse-setup
Hostname for your Discourse?: bad-domain.com
Checking your domain name . . .
WARNING:: This server does not appear to be accessible at bad-domain.com:443.
A connection to http://bad-domain.com (port 80) also fails.
This suggests that bad-domain.com resolves to the wrong IP address
or that traffic is not being routed to your server.
Google: "open ports YOUR CLOUD SERVICE" for information for resolving this problem.
If you want to proceed anyway, you will need to run cp samples/standalone.yml containers/app.yml
and edit the containers/app.yml file manually.
Using a correct hostname:
root@droplet:/var/discourse# ./discourse-setup
Hostname for your Discourse?: good-domain.com
Checking your domain name . . .
Connection to good-domain.com succeeded.
Email address for admin account(s)? :
Changes are pending at
https://github.com/discourse/discourse_docker/pull/456
Does it looks good @pfaffman @codinghorror ?
3 Likes
Commentary on why this change was needed in the first place
First, I’m surprised that in the nearly 3 months since this has been this way there haven’t been lots of complaints, and even the topic that brought this to my attention wasn’t having trouble because of this change, so maybe it matters much less than I think.
The first thing that I don’t really understand is, you guys really want to make it so that it’s impossible to set up an http-only site with discourse-setup? I guess they have to have done a bunch of DNS stuff to make mail work already, so maybe it’s not that big a problem to have them create the A record too.
Feedback on the change
Unless you made a change that I haven’t noticed, the script creates app.yml before it starts asking questions, so you could just say something like "Discourse installation without DNS configuratoin is not supported. To continue without DNS configuration, edit app.yml to suit your needs and run ./launcher rebuild app" and then quit without bootstrapping.
Also, if you’re going to enforce everyone-has-to-use-let’s-encrypt-and-https, then it might make sense to change standalone.yml and web_only.yml accordingly and then those fiddly sed statements could be removed.
More musings
From the this-is-my-problem department, my current install script runs before people can set up DNS, as I create the droplet for them, set up Discourse, send them an email with DNS instructions, wait for DNS to be set up, and then modifies app.yml to enable the templates and set the let’s encrypt address. But I guess that’s just for historical reasons, what I should do instead is create the droplet, configure mailgun, wait for DNS, then do the installation, that would still let my script use discourse-setup, which I like doing as a frequent test that it’s still working (I don’t think that you guys are doing an automated test of discourse-setup are you?)
2 Likes
Yes.
I have had zero complaints on this change and since it went live I don’t get the lots of HTTP-only Discourse instances because when your say that is something is OPTIONAL everyone skips it without considerations. This is IMO a great change in having safe defaults for Discourse, which is all we are about on the 30 min guide.
Oh that is even better, less instructions needed!
Oh now I understand your hard reaction to this change as it broke your setup, sorry for that.
I would really recommend using the direct yml for anything automated instead of targeting the interactive script.
3 Likes
tl;dr: Yes, with the small language tweak that I recommended, this looks good to me.
Agreed. Zero complaints! Sounds like a win.
No! It didn’t. (!) I only sort-of noticed that the sites weren’t coming up before I did the second stage of the install that enables https. And my setup isn’t your responsibility. (Oh, NOW it’ll break my script, but not doing the installation before DNS is set up will be better anyway. I haven’t done a non-https installation in at least a year.)
The reason that I liked having my script use discourse-setup is that it makes extra-special sure that my install customers are getting a Standard Install, and that when someone says “I did an install and it didn’t work” I can run my script and do exactly what they should have done and say “Well, I just did an install and it worked.” But I don’t think I remember a time in the past 3 years that I found an issue, so perhaps my “testing” isn’t doing anyone any good.
5 Likes
Cool, thanks for the analysis and review!
Merged the PR so we will always validate DNS now.
4 Likes
This topic was automatically closed after 25 hours. New replies are no longer allowed.