Don't use Strato.
At first glance they seem like a good hoster, but they are not. Even if their pricing model seems competitive.
For basic stuff like a single Wordpress or something it might be fine, but I would not entrust them my systems.
I had so many customers throwing Strato out of the window in a fit of rage.
Just my personal opinion based on what I have witnessed.
@fortytwo we haven't done anything on your setup, since we don't even have access to your system. I suspect from the logs that there might have been some initial docker hickup on your server, which was resolved by the reboot.
I did not follow the upgrade tutorial for 16.04 → 18.04 → 20.04 entirely because I have some minor adjustments on the server that were blocking the upgrade. Also, there was a minor issue with docker in the past, where I edited the file /etc/apt/sources.list.d/docker.list so this whole problem was my fault 🙂
@np_cloudron The Cloudron admin credentials and SSH credentials are different. The CLI credentials would have been set when you installed Ubuntu. Not sure where you got the ISO from, but maybe it has some default login?
The enable SSH feature is for Cloudron support team to access your server. You should be able to access your server regardless of that.
@shlomi I assume you mean the web server is installed on another server (and not on the same one as Cloudron). If that's the case, then it's fine. Otherwise, we don't support running additional applications on the same server as Cloudron.
(why is cloudron not using DNS-level validation for SSL so we will not need to open posts if we do not want/need. )
@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.