Cloudron Forum

@jdaviescoates Says me, since www. tells people to expect the main brand website. naked doesn't tell them anything, eg: SaaS apps often use naked for their login, and www. for the marketing site. Check out pretty much any big brand you can think of that ought to know, www.google.com etc. I'm sure I read a deeper article on the whys somewhere, but I was in your shorter is better camp for a long time until I realised there were good reasons for the www. being the destination. Cookies containment from subdomains and use of CDNs are a couple of reasons I remember off the top of my head. I'm sure there's others.

@girish The terminal command comes back correctly. I don't have time right now to upload a file. But I did upload a test index.html file the other day and it worked fine. I added my app locations to the child nameservers page and I'm not getting the TXT file download anymore. I'm only seeing the characters included in the app browser address if I am in the settings section of the apps. I am still getting issues loading pages if I just type in my regular domain and I get the untrusted certificate warning.

@fisi I think @nebulon responded to your ticket from support. If this is the same support ticket, the reason is that your server has 2 NICs and connected to the internal and external network. This is not a problem but the routes are set up incorrectly in ubuntu. The default route is going via the internal gateway. I think you have to adjust the netplan to fix the routing situation . (I hope I am replying about the correct tickte ! )

@luckow yes. See this comment - https://forum.cloudron.io/post/83868 https://git.cloudron.io/cloudron/box/-/commit/0dfadc59228978f82ae3aa2ba4be2b421e785e02 was the fix . You can always apply it locally in /home/yellowtent/box/src/dns/digitalocean.js . Then, systemctl restart box and renew all certs.

@matix131997 This was a bug in the UI code (setupdns view code). Fixed in https://git.cloudron.io/cloudron/box/-/commit/003bc457bf95a5b555a83d76b36199f3acec8ece As a workaround: Setup the DNS as manual or wildcard for a start Then, after you setup admin etc, go to Domains View and change it to Bunny. This view does not have this bug.

it just went away, i think the router had a DNS cache thats flushed now. It's no longer being set as the DNS server via DHCP, so I think its resolved.

Thank you all, I can finally acess my app.

Please update to Cloudron 7.6.4 where it is fixed already. The DigitalOcean API behavior had changed recently.

@sixfold_distract said in Link subdomain on squarespace to Cloudron: questions: So, scenario 1 is just a simple, case-by-case subdomain like mail.example.com or forum.example.com. Can I even do this via Cloudron? yes, of course. Just choose the Manual DNS provider. You can just set up normal A/AAAA records for the apps. For the email server, if you go to the Status section, it will tell you what DNS records to set up.

@alphy Is there a way for us to access the server? Not sure why unbound is not resolving but that's the root of the problem. If it's possible to access it, please send us info at support@cloudron.io and we can debug further.

Thanks @girish for the quick reply. I'm getting there.

@girish You're right, I think not. Currently the app is NOT in a 'Running' state if any failures occur. An alternate method would be to bring up the app anyway (as long as the primary subdomain is up, and continue to resolve the failed API calls until some 'threshold' (then alert) or it succeeds and all is well. No need to ignore the failed ones, they just try again async as with your API rate backoff code, or at the next addition of a new sub if you want to be less proactive and more lazy. (The non working subs, if used will draw attention back to the app anyway.)

Yeah, the access key is what is going to check if the domain is there. I think "Skip nameserver validation for custom Route53 NS names" would get me there And all of the DNS and Email stuff...I totally understand how difficult it is to give less technical users the ability to even USE this stuff, as well as support slightly more advanced users. You're doing a great job!

@pixeltablet as long as the DNS settings are copied over to cloudflare, everything will continue to work. You can also make Cloudron add the DNS entries into Cloudflare by first switching to cloudflare and then sync DNS - https://docs.cloudron.io/domains/#sync-dns . Just so you don't hit any DNS issues, you can add the 'my' subdomain record manually into Cloudflare.

@grimreaper said in cPanel DNS: Wow, what is his problem? I know it is unrelated but since @mhgcic brought it up is Lamp easier than cPanel to use? is there a GUI for it? Cloudron does all that cPanel does and more. There's no need for cPanel with Cloudron. Yes, with GUI when necessary. Basically, your cPanel account comes empty just as a LAMP installation is.

Not sure if relevant to your situation, but to bypass specific DNS entries you can also do: local-zone: example.com typetransparent local-data: "my.example.com A 172.18.0.1"

@scooke said in Why is netcups DNS so slow?: Wildcard I'm using the programmable DNS (CF and Bunny). Maybe that's why it's faster.