now all my apps are using backblaze as storage, Cloudflare only as DNS (CNAME → test001-b2.test.com → f002.backblazeb2.com)
now I want to migrate storage from backblaze to Cloudflare R2 softly, without app upgrade. (I already sync data between two cloud storages, now need to change DNS CNAME record) Here softly, I mean no 404 or other non-200 response status code. I find change the subdomain dns record to backblaze to Cloudflare r2, I have to delete existed dns record, and add Cloudflare r2 custom domain, during the operation time gap, live app sounds like cannot fetch resource, and return 404. How to resolve it, to make the migration softly, no influence to my online users?
test001-b2.test.com - ❌ → backblaze
- ✅ → cloudflare R2
thanks
Related
My domain analogue.design is using Cloudflare's name servers, and caching the A record of analogue.design.
Will that prevent AutoSSL from running in cPanel?
Currently I receive an error in AutoSSL:
DNS DCV: The DNS query to “_cpanel-dcv-test-record.analogue.design”
for the DCV challenge returned no “TXT” record that matches the value
“_cpanel-dcv-test-record=4INs3KmEtlH8IwIA2C3vjAbfrkrmLisoUQomsJJ19oPnm23SdoHHnWeFd5AgbU2M”.;
HTTP DCV: “cPanel (powered by Sectigo)” forbids DCV HTTP redirections.
However, the A records for:
autodiscover.analogue.design
_cpanel-dcv-test-record.analogue.design
are not being cached, they are DNS only.
Help appreciated.
Yes,
If you are using cloudflare as proxy server and if you want to install Autossl Certificate on your server, then you have to pause the cloudflare for your server.
To pause click on overview on the bottom right corner you can see pause cloudflare,
then go to ssl in cpanel, install the certificate using AutoSSL,
it will install the certificate , then again go to cloudflare and run it back
I believe you are adding those records as A record entry and not as txt record with the values provided against them in cloudflare.
Manually check using mxtool or some other online tool available if those needed records are reflecting or not. ( https://mxtoolbox.com/SuperTool.aspx?action=mx%3aanalogue.design&run=toolpage) , it also says not found.
Usually adding those records works for renewing the SSL via autoSSL in cPanel for cloudflare based websites, so probably you are doing something wrong while adding those txt records as explained above.
Quick way would be turn off orange cloud to grey and run the autoSSL, however, you will need to repeat this after every months so not a suggested solution.
On Cloudflare temporarily disable "Always Use HTTPS" in "SSL/TLS" > "Edge Certificates". Then Run AutoSSL. This is happening on cPanel when using Cloudflare, but not DirectAdmin from my experience.
I'm trying to set up https on my backend app on heroku as a subdomain like this (for example):
https://api.mydomain.com
and I'm really confused by all the conflicting online docs I've found. Also, I'm rather green on all this SSL stuff. This app will be a backend for just data serving. My front end right now is https on OpenShift under my domain and it's working fine. Here is what I've done:
I have a "hobby" dyno ($7/month) on my heroku app, which I read that I need to
enable this stuff.
I have a cloudflare account which serves up my domain for the openshift front-end on https.
I bought my domain from GoDaddy -- so right now it simply points to the cloudflare name servers.
I setup the subdomain: api.mydomain.com on heroku (settings tab). It came back and said that my "DNS Target" is api.mydomain.com.herokudns.com. It also says "Domain: Your app can be found at http://api.mydomain.com".
I clicked "Configure SSL" > "Automatically configure using Automated Certificate Management" and it comes back saying to:
"update your DNS settings to our secure domain"
Not really sure what that means, to be honest. I tried to go back to cloudflare and add a DNS Record (DNS tab). Like so:
Type: CNAME
Name: api <--is this right?
Value: api.mydomain.com.herokudns.com <-- what do I put here?
But this doesn't work. How do I know? I type
heroku certs:auto and it comes back 'failing'. Also tried value: mydomain.com.herokudns.com without the 'api' in front. I'm really confused and the docs aren't much help. Can anybody help me?
I have found a simpler solution. The fix was mentionned in Cloudflare's tutorial.
The trick is to take your standard heroku app address (ex: myapp.herokuapp.com) INSTEAD of the xxx.herokudns.com displayed in heroku's SSL interface
Then, to make your custom subdomain (ex: api.foodomain.com) point to it, simply add a CNAME record in Cloudflare's DNS
CNAME api myapp.herokuapp.com
And it should work (it did for my case).
OK, in case some other poor tired programmer comes here.
Cloudflare and Heroku don't get along. Use your SSL from cloudflare. Here's how:
disable automatic certification on heroku: heroku
certs:auto:disable
Delete your domain on heroku and start over
Add the (sub) domain again on heroku
type heroku domains to see what the REAL domain is now -- without ACM enabled it will probably go back to ...herokuapp.com instead of ...herokudns.com
Set that one up in cloudflare (DNS tab) under CNAME like so:
CNAME | yoursubdomainname | yourdomainname.com.herokuapp.com
set up Page Rules in cloudflare to be like so:
http://yourdomainname.com/ => Always use https
on Crypto tab use Full SSL.
Wait an hour or so to make sure these all take effect.
Hope that helps someone.
I want to move my website to my new virtual server that I bought from another service provider.
I installed Apache Webserver, created a virtuzal host for the website and I changed the DNS in my actual service provider's admin panel pointing to the new server's IP address.
I then realized that I can't access mysql to export my database and I disabled the domain on the new server, changed the DNS back in my old admin, but now I get a ERR_CONNECTION_REFUSED when I try to call the website.
I don't find anything on Google, because everybody wants me to delete browser cookies (which I did), but that doesn't help.
What can I do for getting back the old website and being able to export my MySQL database?
It may well be that your DNS records are still propagating and you need to wait. Try adding an entry in your hosts file to point to the "old" site URL and hit it in your browser. If it works then it's the DNS not completed propagating. Otherwise your error looks like an Apache issue not a MySQL issue.
I simply deleted the virtual host on the new server for the domain and I was able to access the "old" site immediately.
It's still possible, that the DNS just finished propagating, like #George said, but it's very unlikely.
I'm having an issue with setting up my Google Apps account.
I believe that my S3 bucket is causing the problem.
I configure the MX records like Google asked me to and today mij DNS providers acknowledged that the records where propagated.
Now when I try to continue the setup of my Google Apps account it's stuck and doesn't provide any info. I have hosted a a static website on a Amazon S3 Bucket.
Trying to see if the MX records are available I used this tool MX Toolbox
to see if my MX records where available but they weren't. Anybody with the same problem or some professional advice?
BTW: the domain name is xntriek.be
What I suspect you will have to do is as follows:
1.) change the settings at your DNS registrar to use a different name server. For my registrar, namecheap, I go to manage -> transfer Name Server to 3rd party (or some variant) -> (leave this screen up - there should be a set of 5+ blank records)
2.) Set up Amazon Route 53.
3.) "Create Hosted Zone" for your domain name in the Route 53 console
4.) This hosted zone should be associated with a "Delegation Set" (right side of R53 console) - 4 records which you will paste into the screen you found in (1) above.
5.) Save that, and configure Route 53 as you would have configured records with your DNS provider. (CNAME aliasing and mx forwarding)
The reason this must be done in R53 and not at the Registrar is that setting the cname record alias to, say, www.yourdomain.com.aws.us-east.amazon blah blah blah tells mx traffic to go to amazon for instructions about what to do. Of course, there are no further instructions for that traffic if you have not set up Route 53.
I hope this helps!
My client is seeing a different version of the website on his computers then what I am seeing on mine. He claims to be deleting the cache. I'm using Safari with the cache disabled via the Develop menu and I see the correct version of the site.
Is it possible that the website is somehow cached by my client's ISP or something along those lines?
Update:
I think I need to describe the problem better:
My client has a web hosting package where he has his domains and email accounts. somedomain.com has it's A record changed to point to Behance's ProSite hosted service.
The problem is that when he goes to somedomain.com he gets the index.html that's sitting in his web server's public_html directory, and not his ProSite. Using the same domain I see the ProSite. He has cleared his cache and tried on a computer at home with the same result. This is what lead me to believe that there is some sort of caching issue somewhere along the line with his ISP(s).
Is there anything I can do about this?
Proxy servers at the ISP or even the client's site might do this. Or even network-compressors in some (mal)configurations.
Depending on the site you might also be seeing actually a different site. e.g. Google redirects to different servers using DNS load balancing.
Yes, you're right. To improve performance and the speed in loading page from the same request modern browser seem to great at caching. I myself have the same problem as well. To resolve this problem You should tag version of your projects whenever you deploy them to production.
Based on the update, the problem was with DNS cache.
DNS can be cached at the following levels:
browser
operation system
router
DNS provider
And each of them has its own way to flush DNS cache. Except DNS provider where the only thing you can is to wait for cache invalidation. Though you can replace your current DNS provider with another one who won't have your domain in his cache. You have all the chances to find such if your domain isn't popular.