Cloudron Forum

Indeed those leftovers should have been purged. Maybe some bug somewhere then. Do you have a way to reproduce this?

The app package passed CI tests and is out by now.

Might be a good idea to disable automatic updates for the app if you don't want Mattermost 10 . But we have no idea how long MM 9 will continue to be supported.

So wildcard is only for subdomains of a domain. The domain.com record is not covered by wildcard.
But yes the instructions probably sound like both *.domain.com and domain.com are in fact managed by Coudron, but all I can tell you that unless an app is using a domain, the certs will not be renewed. Maybe we can be smarter about this in the future, but to solve your problem this is what is required.

Note a redirect to an existing app will also work.

@shrey said in Native (email) Auth doesn't seem to work out-of-box:

Recommendation: have the above config set by default, particularly in the cases where the admin selects "User Management by app", when installing the app.

Those variables are always set already. See https://git.cloudron.io/cloudron/typebot-app/-/blob/main/start.sh?ref_type=heads#L31 . Or maybe you are suggesting that we should put this in /app/data/env.sh so that the user can see them?

@nebulon Thanks! Got it working finally

@girish Thanks for the quick resolution!

@shrey I think it might be better to just set the data directory and just disable backups for immich instead. As you know, it's still in active development and moving around files will cause things to go out of sync with the database. This will just cause unnecessary headaches if we make this configurable. It is similar to nextcloud in this aspect (whose data directory can also not be configured in Cloudron package)

@AmbroiseUnly
Great, this helps me finally 😉

this should be fixed with the latest package now.

As far as I understood, those are all optional and you can set them as you like. However one storage related change was required and I've put that into the start.sh to get added.

This should be fixed in the latest package.

Update is out now.

Seems to fine here atleast. And we are not seeing any outages at https://status.cloudron.io/ either . Please re-open this if this is still a problem.

@shrey This is interesting. I hadn't noticed before that you had a complete different way of authorization. That's why I made an edit to the post and gave you the exact instruction, which is already implemented as standard.

@shrey The fix didn't make it to Cloudron 8, but will be in Cloudron 9 (2 months or so from now). I can post a link to the patch when I push it and you can give it a try.

@shrey it's out now

This should be fixed now with latest package. Unfortunately I found that if a previous extension installation failed, the database would contain that info, making it impossible to install the same extension again. So you may have to manually delete records from the database to get over this 😕

@girish Thanks, that helped!

@zonzonzon apparently, we added these manually when we installed EspoCRM.

@shrey I have added a doc note for the fix - https://docs.cloudron.io/apps/espocrm/#cron-jobs