For info, I had to run systemctl restart box on the system, which brought the apps alive.

BUMP: I resolved this issue. It was a specific container (custom made by me, not supported by cloudron) issue is resolved.

@nebulon Would a simple Cloudron app with just the nginx reverse proxy configuration work?

@micmc Whoops, it seems we missed those mails somehow! I will reply to your email shortly.

Hi, can you send an email to support@cloudron.io with the link produced by running the cloudron-support script on your server?

@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.

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?

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