Open mhulse opened 9 years ago
Would be good to setup new subdomain today. Anyone opposed to the subdomain name of:
election.rg.com
Or 2014.rg.com
election14.rg.com
If we use election.rg.com we can reuse next time.
Thoughts?
Election.rg.com sounds good to me.
Rob Denton
On Fri, Oct 31, 2014 at 11:32 AM, Micky Hulse notifications@github.com wrote:
Would be good to setup new subdomain today. Anyone opposed to the subdomain name of: election.rg.com Or 2014.rg.com election14.rg.com If we use election.rg.com we can reuse next time.
Thoughts?
Reply to this email directly or view it on GitHub: https://github.com/rgpages/election-2014-general/issues/42#issuecomment-61307457
After talking to j, We're going to go with vote.registerguard.com. J is going to ask Hamp and David to do this, copying the same setup as Zeppelin.rg.com
Just for my own edification, how does having a CNAME pointing to GitHub result in being able to serve from an Amazon bucket?
I had the same question...
Rob Denton
On Fri, Oct 31, 2014 at 3:54 PM, John Heasly notifications@github.com wrote:
Just for my own edification, how does having a CNAME pointing to GitHub result in being able to serve from an Amazon bucket?
Reply to this email directly or view it on GitHub: https://github.com/rgpages/election-2014-general/issues/42#issuecomment-61341516
Scenario:
GitHub network slow or throttles connection.
Solution:
We point vote.registerguard.com to a backup install of page that lives in an S3 bucket named:
vote.registerguard.com
The only drawback is the propagation time.
So, instead of us linking to pages.registerguard.com/election-2014-general, we point all links to vote.registerguard.com. If shit goes sideways, we move the subdomain "vote" instead of "pages", because "pages" hosts other things that we don't want to move. By CNAMEing just vote, then we can move just that content to any other location without having to worry abut breaking other things, and all of the links we put out there (like, via social media) will not break.
Hope that makes sense. :+1:
Ah, yeah that does. So, to make sure I understand, if things go sideways we'd need to redirect the CNAME to the bucket. I take it that that is more or less instantaneous (as opposed to having to wait for the CNAME to propagate out to all the DNS servers out in Internet land)?
FWIK, when creating a CNAME (or A-RECORD) for first time, that's usually pretty quick. If it's an existing name/record, then that could take time to re-propagate. It's not optimal because there will be a lag, but it's better than the alternatives. :)
Just to clarify:
When I typically update DNS ("A" records) I will allow for an extended period of time for the changes to propagate throughout the root nameservers.
Do I need to make this same allowance for updates and changes to CNAME records?
No you don't because DNS records don't propagate. What you do need to allow for is for any cached records to expire, based on the TTL of the record in question.
If this is a new record, no caching can have occurred so the new record should be available and should resolve immediately.
Yeah, that makes sense to me, the difference between the A records and CNAMES, cause it seems to me as long as "registerguard.com" isn't moving around, resolving/re-resolving subdomains should be pretty quick.
It's nice to have the "detachment point"/subdomain ready to go ...
Subdomain is setup.
Just need to figure out best way to auto-push to a bucket.
Alternative could be post-commit hook to a git-powered vhost on our servers.
Question: Should we need it, will we need someone from IS to make the subdomain switch?
Question: Should we need it, will we need someone from IS to make the subdomain switch?
Yes. Should be able to do that remotely though. Will confirm on Monday.
I'll setup alternative hosting location ahead of time. I'm thinking a folder on our static server would be the easiest.
Suh-weetness, all around.
Suh-weetness, all around.
Fo shizzle!
We're looking good at this point. I just have to finish #20 tomorrow and then Monday should be minor adjustments and #35 for cross-browser testing. Nice!
David setup testvote.registerguard.com; need to pull a backup there and do quick testing.
Should we just use our servers for this?
Meant to say: have this also hosted in an S3 bucket. Cname the project for easy pointing to diff host.
elec2014 as subdomain?