@murgero Yes, agreed. Starting coming Cloudron 4 release, this will happen automatically as long as the same cloudron.io user registers a cloudron with the same domain name.

There are trade-offs with every solution though.

With LDAP, 2FA needs to be built out in each application or added via some form of LDAP proxy (I think this was discussed on GitLab or Rocket.Chat somewhere). With OAuth, the provider can handle that.

Also, OAuth only requires access via HTTP(S). I would like to use Cloudron as a single source for my identity, but that's impossible today since I can't use it as an OAuth provider or securely access LDAP from any other server.

I totally understand a preference towards LDAP, if available, but removing the option for OAuth does impose limitations.

A while back I started working towards my own workaround by building a Cloudron app that provides a VPN interface and proxy to the Cloudron LDAP server. I decided against that and to instead just host an instance of Authelia from within Cloudron, but I've since run into a wall there as well.

I'm not dead set on any particular solution, but would be great to have some mechanism to use Cloudron as SSO for all my services.

From what I understand, the device you are trying to connect from does not support any of the ciphers which Cloudron is requesting. We are following the security guidelines of the following communities:

https://bettercrypto.org/static/applied-crypto-hardening.pdf https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://cipherli.st/ https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

So we likely won't support outdated or insecure ciphers from the platform side.

Is this still an issue? Otherwise I will close this thread.

This is indeed also a common case to have the email not hosted on Cloudron. However Cloudron will still want to send out emails for this domain. There are two components doing so:

the system as such which would send out with no-reply@domain.com the apps, if they need to send out app specific notifications. In such a case the address is dynamically generated depending on the app and which domain it is installed on

Currently none of those can be changed to use some customer email address to send out as.

Regarding the DMARC issue, just to be sure, did you check the mail status tab in the Cloudron dashboard for this domain? The UI will attempt to provide guidance or show issues with email related DNS records there.

Another option is to simply Disable mail and then Enable mail for the domain. This will effectively end up copying the certs.

Had this happen as well. Thanks for fixing in future versions.

@subven As it was not in the production list, I thought it was not supported. But I will try the generic option. Thanks for the PS, I will look into that 🙂

@nebulon said in entered Cloudron.io email incorrect:

@necrevistonnezr it is possible to change the cloudron.io account email, but only by us, since we haven't added the ui bits for that. Just drop an email at support@cloudron.io with your current email and the one you want to have it changed to and we will take care of that.

Thanks, done.

Not at this time. Install the LAMP app and manually install Wordpress in a folder there.

Yes, there is no need to restart after that.

@rfg This was a bug in our previous version. You can fix this by going to services -> mail -> restart. You have to do this only once, future certificates will be setup correctly.

@necrevistonnezr Thanks for helping debug this further!

For the rest: The issue is that there are a large number of files (> 400k) getting backed up and the syncer code is running out of memory since it loads all those filenames in memory. I will get this fixed in the next version. For now, disable automatic backups for nextcloud.

Generally doing any additional system configuration or removing/adding other ubuntu packages to the system is not supported, since we cannot test such variations for updates.

Cloudron already only installs signed packages. Enabling livepatch should be ok to do.

For all the other things happening through that ansible role, we would have to go through them one by one and test accordingly. We will not support running such hardening scripts automatically, there are too many of these out there. So if there are really good reasons to disable/configure system components for security we can investigate. Often security roles don't even apply to Cloudron if the corresponding components are not even used.

Hi there, if you haven't already rebooted the server in an attempt to restart the addon services freshly, maybe you can try that, otherwise can you enable remote SSH https://cloudron.io/documentation/support/#remote-support and send us an email with your Cloudron domain to support@cloudron.io then we can take a look.

@RoboMod Are you able to ping me on our chat so we can debug this together?

Hi,

can you try to run curl -v https://registry-1.docker.io/v2/ from that server? It should return a 401 Unauthorized status code if the connection as such succeeds.

If this this works, can you try reinstalling the app, maybe there was a temporary issue with the connection. Otherwise is that server behind some firewall blocking connections to the docker registry?

I have opened https://git.cloudron.io/cloudron/box/issues/622

This is fixed in 3.5.4

OK, I have fixed the code as well, so it will part of next update (3.6). Until then please update file.

@ReadyTransport4 Glad you got it working 🙂

@redponey Did your problem get sorted out?

Fixed it for next release.

From what you wrote, are you running the server behind your home server in a NAT by any chance?

Yes indeed.

@uiharu Does host cloudflare.com 127.0.0.1 work?

I'll update later

@girish Thanks!

@relink Cloudron does not work without a domain name. Many features like DNS integration, certificate management, reverse proxy setup etc all require a domain name.

Maybe you can try a setup like this:

Pick an imaginary domain name like relink.home Choose the noop (only for development) DNS provider. In Advanced section, choose Self signed certificates

In your router/DNS, just add entries for *.relink.home and relink.home to the server's IP. Alternately, add those entires to the /etc/hosts of your PC. You should then be able to reach, my.relink.home and install apps.

@supervacuo Thanks for the report. I have fixed it for the next patch release. The max password length in the backend is 256 but the UI had a bug limiting it to 30.