Perhaps. Perhaps not. It all depends on why rubygems is rate-limiting you, exactly. That’s not something we can help figure out, it’s between you, your hosting provider (AWS), and rubygems.org.
I couldn’t find anything by searching about this problem, and it always shows the HTTP 429 too many requests for the same items, and ends exactly at the discoursebot installation part. I tried using an elastic IP address and it was the same. Is there a way to manually download another way from rubygems? Then upload via ftp or something?
I did happen to see that, but have no idea how to limit how many requests per second when I do rebuild app in the launcher. Is it possible to limit the requests per second?
Have you considered just moving to digital ocean, we have not seen this problem over there. AWS is often an abuser due to autoscaling and other fanciness.
Are you on the latest version of launcher?
cd /var/discourse && git pull latest version needs to pull very few gems if any.
I am fine with AWS right now, and I haven’t budgeted for digital ocean. I do have the latest version of the launcher though. Can I configure the rate of requests to rubygems.org through my SSH console?
One second, are you running on AWS free tier? What kind of AWS instance do you have?
Yes, it’s an AWS free tier instance, t2.micro. Does that make a difference?
Absolutely, I can’t support you here anymore. We do not support the free tier.
So it’s a AWS free tier issue that is causing my upgrade to fail? It worked fine before. What would I have to be on for you to give support for a failed discourse installation then?
I doubt it’s the free tier per se. Mine worked fine this morning when I ran the upgrade.
That’s what I’m thinking too. Do you have free tier also?
Yes. Running since December. Never had a problem with rubygems.org, even when I had 3 free tier instances and I was running rebuilds on all 3 at the same time.
I just created a new t2.micro and went through the 30 minute install. Setup ran without a fault. I took the default 8GB disk for the t2, so I had to increase the volume size before ./launcher rebuild app would complete, but once it had enough space it also ran flawlessly.
Whatever is causing Tim’s problem, it isn’t some software incompatibility between an AWS t2.micro running Ubuntu 16.04 and rubygems.
I didn’t setup with a proper mail server (just my usual smtp.none.com), and I also (obviously) didn’t setup letsencrypt, or https.
Tims problem is a configuration issue.
Thank you Andrew, that what it seemed to me as well. It all started from the one click upgrade which failed initially. I could still use the site at that point. When I went into the SSH and did ./launcher rebuild app, that’s when I couldn’t even access my site, and neither could the users on that site.
Does anyone know how to fix this, it is somewhat urgent as it is connected to my business.
The quick way is moving to another server, on another provider, be it Digital Ocean, Azure, Google Cloud, Vultr, etc.
Without thinking we need to support unsupported configurations… if the problem is an AWS settings config issue, even a restore on to a new instance isn’t going to work.
We confirmed this last night, restore on a new instance doesn’t work. But the weird thing is, if you look at the backup, it contains what appears to be a perfectly normal dump.sql.
You need to talk to rubygems.org, via the means previously provided, about their rate-limiting. This is not a Discourse problem, and short of lucky shots in the dark, nobody here can help you solve the problem.
Strange error during bootstrap (db:migrate) on Mac
That’s alright, I just did a fresh install from a fresh ubuntu instance on AWS. I’m backing up more often now so that doesn’t happen again. I appreciate everyone’s help though!