Add forced HTTPS support to obofoundry.org using GitHub pages; cleanup

[nlharris]

http://obofoundry.org works; https just spins. @ddooley noted, "It would be web-consistent to put ssl cert on there." @cmungall said, "We should definitely do this.. we are stuck in a weird space as the URL is partly owned by Barry but haven’t been able to transfer it over (not due to any desire not to relinquish, it’s a technical thing)."

[cmungall]

@kltm do we have a ticket somewhere else for transferring obofoundry.org DNS entry from Barry to route53?

once this is done https support is trivial we just map this directly to github pages as we do for other sites

[cmungall]

This is the ticket for the handover: #393

[nlharris]

@cmungall are you sure that's the right ticket? it doesn't seem obviously related.

[kltm]

Hm. While it would be good to transfer the domain's ownership for a lot of reasons, I don't believe that getting HTTPS/TLS working is related. The server that hosts the site should be otherwise under independent control.

[kltm]

Clarifying the actions here:

• [x] getting control of the domain
  ~https://github.com/OBOFoundry/purl.obolibrary.org/issues/393~
  ownership is not necessary
• [x] directing to github
• [x] enabling https with GH domain controls
• [x] deactivate (now unneeded?) apache server
• [ ] get rid of the AWS EC2 proxy (should let it idle for a while as backup before finally destroying it)

[kltm]

Also see https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1204

[kltm]

Assuming that what is desired is a forced for all traffic (i.e. all http -> https). @cmungall @nlharris

[kltm]

@cmungall Noting that A record TTL in Route 53 is already low (300), so we can commence experiments with minimal downtime whenever we want, assuming that the proxypass /ontologies -> http://www.berkeleybop.org/ontologies is no longer needed.

[cmungall]

let's do it, we don't need the forward

[kltm]

Okay, I believe I've switched over the domain A record to be directly pointed at GH servers after setting up the domain in Pages, following https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site#configuring-an-apex-domain HTTPS does not yet seem to be available as an option; maybe need to wait a little: https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/troubleshooting-custom-domains-and-github-pages#https-errors If anybody is seeing issues or regressions, please let me know ASAP.

[nlharris]

https://obofoundry.org/ gave a warning, but when I said "do it anyway", it worked! Thank you, Seth! 🙌

[kltm]

It is not forced yet, as some of the cert stuff is apparently in process, but forced upgrade should be available soon.

[kltm]

@cmungall @nlharris I've now turned on enforcement and it seems to work after a little testing. I will keep the old instance up as a backup for a little, but have deactivated the apache server to test what we have. If we don't run into any problems, I'll bring down and destroy the instance, completing the final item on the list https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1674#issuecomment-984035637

[ddooley]

works for me flawlessly now, from http:// to https:// ... glad that worked so smoothly, and a fast issue to resolve!

[nlharris]

Ha, maybe it appeared fast, but you didn't see all the work @kltm had to do behind the scenes!

[nlharris]

@kltm no pressure just wondering if there's any update on this

[kltm]

@nlharris The action list is here https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1674#issuecomment-984035637 The single remaining item is destroying the VM. As it does no harm and acts a a backup, it's has been pushed down the list of priorities for the moment.

[kltm]

This machine has not been stopped; things look fine. Looking at all the other things we have stopped but not terminated, we probably need to do a general cleaning. That said, I think this is far enough along to close.