@kdev Indeed as @scooke mentioned it seems that docker is already installed on the server. Can you uninstall it and try again? In general, Cloudron must be installed on a fresh Ubuntu 20.04 without docker etc.
@girish Thanks for that command. It is indeed strange and I haven't seen it on other Cloudrons, so something must have got stuck with this one. Not a big deal, but it's nice to have that message not displaying any more.
I suppose each Cloudron needs a unique domain name because of the DNS records that are being created when installing a Cloudron: DKIM, SPF, DMARC?
Yes, and also because we need a unique location to access the dashboard.
what if the domain that's being used for a Cloudron already has e-mail related DNS records, for example when it's already configured for use with G Suite or Office 365? Will Cloudron modify those records, override them or just ignore them?
If you have an existing DMARC, it don't touch it. Otherwise, it will put the default strict DMARC policy. DKIM uses a unique selector domain, so it won't affect other DKIM entries. The SPF is modified with "a: my.<domain.com" into the existing SPF.
@jakobgreenfeld Oh I missed the bit where theres only a txt record. Add an A record pointing my.domain.com to your IP. I've had nothing but trouble with Namecheap's API for configuring everything so I've started doing this:
@zjuhasz1 Right, this is also fixed. The packages were installed because we use apt without --no-install-recommends. You can remove those gnome packages by hand for now if it bothers you but it doesn't run any daemons, so it's mostly harmless.
I think we won't change the minimum requirement tested for in the cloudron-setup script for now. It seem quite the edge case to have that little storage available, however it is good that we know there is a possible workaround for those cases.
@robi Installing apps from the store en masse can't be common. I think rn it's flow is best for an average user, but it could be a little more mobile app store like with an "installing" progress bar while you discover other apps, and then it pops up with "installed, click to open" or something via Notifications. I could see it, but again - installing apps isn't common enough I don't think to worry about this since installing is a one-time task.
But I'm glad you brought it up because it would add a bit of polish to have a more "app store" feel to it. Still allowing app discovery while an app's installing. I think Cloudron should be able to do that one day even if it doesn't feel like a priority rn.
As @scooke and @mehdi already mentioned, the sole reason to support only one distribution is the reduced complexity by having to deal with only a single well known system. Even different ubuntu versions require quite a lot of testing and different code. Sometimes package names change for example. We essentially just settled on Ubuntu 16.04 initially since that was available on basically every VPS provider. Really that is the main concern for us. Naturally for security updates we then progressed to 18.04 and will soon hopefully support 20.04. Other distros with even other package managers are simply just overhead and cause trouble to users. In the end from what Cloudron requires, there will hardly be any noticeable difference in speed or resources use between any of the distros, so we lean towards stability here.
I'm not sure about how the loop back pinning support plays into this, but I'd run through the checklist again to make sure nothing was missed.
1) Verify that you can ping both your static public IP, and the private LAN IP of your Cloudron server. Just to make sure you have connectivity to both.
This is just a sanity check to make sure there isn't some bigger problem.
2) Correct IP in Gandi Dashboard
Just double deck that this is your static IP.
3) DNS propagation (ping from desktop or whatever and make sure the DNS resolves to the correct IP)
Double check that Gandi has passed your DNS/IP settings to other name servers.