https? #50
Comments
|
The build server could do that, and it would be easy to set up over the weekend. I would need xoft to change the DNS though. |
|
Ok. Slightly off topic: I'm somewhat confused about the server topology. How many servers does the project have currently? And where is the new forum hosted? |
|
Oh, and the book too. |
|
I have no idea about the new forum. We have the build server, the forum server, xoft's docs server, and the book + newsletter on shared hosting. |
|
I may have missed a few actually. |
|
Name: forum.cuberite.org Name: builds.cuberite.org Name: book.cuberite.org Name: api-docs.cuberite.org |
|
The book and newsletter are hosted on NearlyFreeSpeech.NET, the buildserver on Kimsufi, and the others IDK. |
|
The new forum is hosted on SphinxC0re's VPS, and the API Docs on http://www.savana.cz/. |
|
I'm hosting the forum at the moment |
|
Any progress? |
|
@madmaxoft is working on transferring the domain I think, but there isn't an easy way from his host's control panel. |
|
Why is an ownership transfer needed? He'd just need to set the IP to direct to the buildserver. (or wherever you're planning to host the reverse proxy) |
|
I think there was a reason, I can't remember what though. It would certainly be easier though. |
|
Perhaps it was the support E-mail setup. |
|
Yes, the transfer might be needed for #43, however, this issue can be resolved without a transfer. |
|
Yep, that was it. I can't do it right now, but I can set up the buildserver as a proxy over the weekend, and test it. |
|
IF you want to USE SSL use https://letsencrypt.org/ |
|
@alwaysontop617 That's what we're planning to do. |
|
You will use lets encrypt? If so, great. |
|
We're already using Let's Encrypt on most of our platforms. The webadmin and the website are the only platforms missing |
|
Would it be much trouble to host the actual main page somewhere else (perhaps at the build server?) and have it build the site from the GitHub repo whenever a new commit was pushed to it? Basically this would mean setting up the same engine that GitHub uses to generate the pages, plus a commit hook for the repo. Then we could drop the github redirection. I have a feeling that even the emails would start working then, I suspect they're not working because of the domain redirect at the top level. |
|
Sounds like a very good idea. @bearbin? |
|
Kk Why when I go to https://cuberite.org I see this: |
|
@alwaysontop617 HTTPS isn't set up yet. |
|
Ill work on it |
|
The thing is, we need to move the site from Github first before we can set up Let's Encrypt. |
|
KK Good News, I'll Host it for you FREE, do you want me to host it? |
|
Sorry, but we're not "giving away" our main assets to someone who just joined, no matter how enthusiastic they may be. We need someone whom we know is reliable and we can trust them. We already have a buildserver hosted, it should be possible to host the main page there as well. |
|
No, GH pages do not yet support HTTPS with a custom domain. |
|
A recent change by Github: When the CNAME file is removed, it is possible to enforce HTTPS on cuberite.github.io. The option is available in the settings of this repo. No support for custom domains though, so we still have to use the reverse proxy method. |
|
I think I'd prefer a real web server running HTTPS on the cuberite.org domain, rather than a proxy. At least if I understand correctly, the proxy works by providing HTTPS access to another HTTP server, so when the browser makes an HTTPS request to the proxy, it makes a request on behalf of the browser to the original HTTP server - but there's no protection there, anyone can attack this plain connection. This sounds very dangerous to me, because we'd basically be hiding potential malicious attack surface behind our own cert and we'll pretend that it's secure, when in fact it is not. |
|
The proxy would be connecting to the GitHub server over HTTPS so it would be secure. |
|
Since we're talking about proxies, here's an even easier way (with no dependency on bearbin :P): https://kloudsec.com/github-pages/new |
|
So you run it through a third party who see all of people's traffic. NSA must be really happy about such a service :P |
The site uses Jekyll. It should be simple to setup a real web server which fetches the repo every once in a while, runs Jekyll to generate the static content, and serves it. It's only slightly harder than the reverse proxy method, I think. |
If the NSA starts intercepting traffic, it should be a cause for celebration! It must mean we're getting really popular. |
|
The website is really well protected from downtime because we're not hosting it ourselves. I'm fine with @tigerw's solution, so let's use kloudsec |
|
I would much rather not use kloudsec. Ignoring security for the time being (although that is a major consideration), one has to consider the increased downtime caused by the system, the possibility of it going away (very likely for a free service), and a lack of configurability as to what options we want. |
As Bearbin already mentioned, our server would connect to the Github server over a secure connection. It's a hack; The browser cannot connect securely to Github via the
Note that a proxy with a long cache is effectively a real web server. If 1000 users connect in an instant, only 1 request will be made upstream to Github. No further upstream requests would be made till the cache times out, and then another 1 request would be made. |
|
If you're talking about downtime, well, does bearbin provide availability guarantees? Without getting into yet another disagreement, companies do have better teams compared to individual people, generally. |
|
The buildserver has an excellent track record though. Is Bearbin's server availability a real concern? It's practically 100%, is it not? |
|
@tigerw I would in fact argue the opposite - as you get larger reliability decreases. It is only the extraordinarily large providers who have excellent uptime. More infrastructure, more layers, more complexity, all cause more downtime unless you have a team of 20 SREs working around the clock. It's not a major issue in the scheme of things though, more the stress of it disappearing one day and having to change everything over, with no notice. (which tends to happen for things you don't pay with aquihires etc) |
|
...what if bearbin disappears one day..? He does have the keys to the kingdom, so to speak. :D ANYWAYS, as I said, just a thought. |
Lol. I suppose that's a problem anyways. The disappearance of the DNS holder would be a problem, Kloudsec or not. |
|
The domain is finally transferred. HTTPS should be up tomorrow. |
|
HTTPS is now completed. Test it out :) |
|
Thanks! Can you enforce HTTPS on cuberite.github.io just in case? There's an option in the repository settings. |
|
@mathias-github done. |
|
Which method was used, eventually? If it's the proxy method, you should make sure caching is working as expected to minimize latency. |
|
The proxy method was done, but I haven't enabled caching yet. I will do that soon. |
|
Alright. Enabling caching with nginx should be a rather trivial config change. |
|
I enabled caching yesterday, but I didn't notice any difference in response time, still a very reasonable 320ms (time to last byte for homepage HTML) for me. |
|
@LogicParrot Caching is verified enabled, is it all good now? |
|
We can undoubtably tell that the cache is working by doing this:
|
|
@LogicParrot It is working, I enabled the debug messages and tested. |
|
We made the right choice. https://kloudsec.com is offline, and the certificate on https://blog.kloudsec.com/ expired on July 27. Edit: Yes, it shut down. https://www.reddit.com/r/webdev/comments/4s3kmf/got_an_email_saying_that_kloudsec_will_be/ |
|
LOL. I guess so. |
I was wondering if it would be possible to convert cuberite.org into https.
I know there's a technical difficulty since the site is actually hosted on Github and a cert would cause trouble. But it can be resolved:
The text was updated successfully, but these errors were encountered: