Cloudron Forum

@fbartels ok, this makes sense, thanks!

@girish I did something slightly different (but maybe not SO uncommon). I created the server and put the clients domain into my own (developer) cloudflare account. After everything worked I created the domain in the client's cloudflare account and changed the NS entries (basically this: https://developers.cloudflare.com/fundamentals/get-started/basic-tasks/manage-domains/move-domain/).

the situation was now, that the API key was still valid but changed the wrong domain entries at cloudflare. so, I imagine cloudron creates the NS entry, checks if this works (which it doesn't) -> brain freeze. Something like this?

@girish thank you! And thank you again for your prompt help!

@nebulon thank you! Guess I missed 7.2.0 & 7.2.1 🙂

@girish gotcha, thanks!

Just to note, it seems it was a timing issue, where the DNS in this case took longer than expected for full propagation.

I would be interested to know if someone does this outside of Cloudron for their existing business/personal use. Seems like a lot of work (and probably just easier to switch out your NS provider if they are flaky). We use route53 for cloudron.io and AFAIK it has never gone down.

@doodlemania2 the 'Custom wildcard certificate' option .. That generates a self-signed cert, if you don't provide one.

@humptydumpty Err, I forgot that I already removed those last week as well - https://git.cloudron.io/cloudron/dashboard/-/commit/72ba61ad91d326c3f287a2f538809cc78afcfdc8 . So, this should be fixed in next release.

Thanks Girish! 🙂

@girish said in Vultr DNS default TTL:

The changelog is not comprehensive, it doesn't have 1-1 relation with all changes since it also goes into the UI. Only way to know is the git log for small changes.

Totally fair. I was surprised to see that one missing since there's a ton of smaller changes still in the changelog in previous versions. I always thought the changelog was quite comprehensive before, but maybe it's geared more high-level now.

Hi Nebulon! 🙂

@nebulon said in Using Cloudron to setup DNS records in new DNS Provider before switching Nameservers on domain. Vanity Nameservers could also be supported if changes made.:

will not allow for adding essentially multiple DNS provider for the same domain

Just to be clear, I'm not looking to store multiple DNS credentials, if I switch it in Cloudron to Vultr from DigitalOcean, I'd assume or expect Cloudron to clear out the old credentials/API keys, so it definitely doesn't need to retain two or more at any given time for a single domain. Hopefully that clarifies that part. Definitely no need to go down the rabbit hole of refactoring, haha.

@nebulon said in Using Cloudron to setup DNS records in new DNS Provider before switching Nameservers on domain. Vanity Nameservers could also be supported if changes made.:

if there would be an option to not resolve DNS records from the Cloudron side, one could change the DNS backend, then hit re-sync DNS in the Cloudron dashboard, then wait for the new nameservers to have all records in-sync and then switch the nameservers for the domain itself.

That's basically what's being asked here... to remove the requirement to double-check the nameservers in the first place before being able to save the API keys on the domain. I understand why Cloudron does it, it's to help avoid DNS propagation issues, however at the end of the day, Cloudron works as a script to populate the DNS records in any provider we give it access to, so it should not be restricted to only doing so if the nameservers are configured correctly. That limitation that exists currently prevents admins from having Cloudron setup the DNS records in the new location first which of course is best practice before switching the nameservers at the domain level, you don't want to be doing it afterwards. 😉 I think a good compromise if Cloudron team feels it's necessary to still check for nameserver pointers, is to warn but allow a user to move past it to freely have Cloudron setup the DNS records where we provide access regardless of nameservers.

Does the above make sense? I can clarify if needed. Basically just hoping that limitation can be removed in the product as it's impeding what I'd think are some important tasks to be able to do before changing nameservers on a domain.

@girish the work around worked perfectly

@timka thanks for verifying 🙂

Just to add, what I ended up doing was just using Surfer and creating an index.html file with this:

<!DOCTYPE html> <html> <head> <title>United Diversity - Together We Have Everything</title> <meta http-equiv = "refresh" content = "0; url = https://my.uniteddiversity.coop/" /> </head> <body> <p>Will redirect shortly to https://my.uniteddiversity.coop/</p> </body> </html>

@LeeW Thanks for trying it and letting us know!

@colonelpanic said in Cloudflare Setup Questions:

I assume that renewing the Let's Encrypt certificate would not be an issue with the proxy turned on because Cloudron is using a DNS challenge instead of HTTP challenge. Is that a true statement?

Yes. Proxying can be left turned on, Cloudron will manage to get certs via DNS challenge.

What would be the benefit of creating a Wildcard Origin Cert on Cloudflare and uploading it instead of using Let's Encrypt?

AFAIK, there is no benefit. I think the wildcard origin cert is intended for cases where one cannot get a valid cert via DNS or HTTP automation (like some intranets that block outbound access).

Okay, this was kinda weird. Did register the domain and added it to CloudFlare. Got the error "invalid domain" while adding it on Cloudron. Got the error while using CloudFlare, but also with wildcard.
As I had some other work to do, didn't really check after my post. As I tried to add it to Cloudron for a screenshot and after that the manual solution, it suddenly worked, while having selected CloudFlare. So maybe there was a problem with resolving the domain before, but it is working now at least.

@mehdi Ohh didn't thought about that ! thanks a lot !

@msbt thanks so much. My interpretation of the fix suggested didn't work. I have posted a follow-up question there.