We already implemented a mechanism wherein if the userId and the domain name matches, you will get subscribed to any previously subscription. If you have to change the domain, currently the only way is to contact support and give us the new cloudronId. @dustinddotca I guess you changed the domain name? Can you please send the new cloudronId to support@cloudron.io, will be happy to refund and transfer existing subscription.

@murgero Thanks for reporting, this was indeed a regression. Fixed now for the next release.

The version you are referring to is correct. So far we have stayed in-sync with ubuntu security updates, but probably have to revisit this and see if nginx can and should be indeed updated individually.

@dustinddotca If you add a CNAME record manually from mail.example.com to my.example.com that should work. Your email client might complain about certificate hostname mismatch but this is unlikely.

The app has now moved to stable, so the previous setting to list unstable apps is not needed anymore for WordPress unmanaged.

The tzdata package will fallback to UTC which is correct already, however sudo on scaleway comes pre-installed with a custom sudoers file, which we want to keep. So the fix is pushed via https://git.cloudron.io/cloudron/box/commit/9d237e7bd68f43ae59b4bbc591ef1d7680918567 and will be part of the next release.

Thanks @girish!

I tried to reply via your support email already. The cert on your domain looks valid to me, so please clear your history and cache locally for that domain first.

@girish Just as a quick add-on, if you have Comcast business class, port 25 may be allowed by calling the business support line. Same with ATT.

@doomilation Yes, what you have done should work. You don't have to move out appsdata and platformdata.

Best approach as you already found out is to create multiple VPS on your dedi.

@willywonka You can view the credentials in the Web terminal of the app. Once you open the terminal, you can run a command like below. See https://cloudron.io/developer/addons/ for the meaning of the env vars.

env | grep MYSQL env | grep POSTGRES env | grep MONGO

Is it possible that /mnt/storage/boxdata already exists? If so, please remove it first.

@nebulon Thanks a lot. NextCloud app installed. Now continue testing 🙂

@nebulon a per-app quota would be awesome ! Need feature !

@nebulon Many thanks. You guys are awesome..

Cheers

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.