@girish ah alright, was moving some LAMP 7.2 and 7.3 to 7.4., clone does not work in that scenario 😉

This is a feature; it was recently reported broken: https://forum.cloudron.io/post/24231 which was confirmed to be a bug: https://forum.cloudron.io/post/24232 due to be fixed soon

App names are whited out in this screenshot, but the display looks like this: https://forum.cloudron.io/post/23597 when it's working

I recall we had an idea of remote listing of the backups in the storage and showing a UI to restore apps from the backups. Essentially, we need a "import UI" over existing backups.

So, maybe in the Backups UI, we have a way to view the remote backups (shouldn't use our backup table but do remote listing), click on a backup and we should be able to restore. User is then insulated from app package version, app id and all those complications.

@cbeams I agree it's great for testing. FWIW, One can already do cloudron install --appstore-id foo@1.3.2 to install any package. Also, Cloudron only supports rolling updates, which means that version numbers are mostly just an implementation detail for us and ideally the user should now know about it.

Also see https://forum.cloudron.io/topic/4306/provide-ui-support-for-choosing-app-package-version-during-installation

Seems like more of a build toolchain thing, which would sort of put it up to those of us packaging apps and/or perhaps the build service to pick up as a feature. Intriguing, but strikes me as high-effort for middling (at best) reward at first blush.

I think this feature makes sense. Just like we can restrict app passwords to specific apps, we want to extend the functionality to restrict to specific mailboxes.

@girish said in LDAP + 2FA support for Cloudron Apps:

Making baby steps here.
🦾 Almost a slow walk 😉🙏

@ruihildt app is down emails go brrrrr 🤣

@girish It will be perfect,
It will be easy for me to work with freelancers, outsources, give them a limited access to a specific app "Container"...

@robi Wow Robi, this is a great feature request!!! Just yesterday one of my Cloudron instances got a lot of traffic to email for a bruteforce attack.

@girish I think this feature have to put on the top of the list to improve safety but also to reduce workload of instances and network traffic...

Schermata 2021-01-13 alle 09.49.21.png

This is a statping how network performances was impacted before and later bruteforce.

Also, need a robust alert system - email or other - to let us know that something is happens.

I have to try myself, since such a symlink would reach out of the document root and thus could be a security issue (although since there are no secrets and the code is read-only probably not)

@girish having a email manager for a user would be allready great idea. So a user could control his own email adresses.

I totally on the other hand support the idea of a dimain admin, where users could control their apos and settinfs of the domain.

Hetzner Cloud snapshoot can be an additional measure in case of total backup failover, but as @fbartels said, snapshoot could have inconsistent data and generate corrupted instance when recovery-restart.

Snapshotting an instance can be an extreme way to recovery data. Of course, cannot be the first and the right way to make a restore. If you use that feature to make it cheaper I think is not a good way to approach problem.

As @jdaviescoates said, you can purchase a Box from Hetzner and configure an extra backup, mounting CIFS directory. But also this procedure can have some risks in case of a total failover of Hetzner datacenter or connection. Best practice is to use a different provider or datacenter.

(Now I'm testing Wasabi and seems to be fast, stable and reliable, but I'm scared about privacy policy management: maybe for some configuration mistake data directory can be exposed).

Question is: @mikulabc why you want to use Snapshotting feature? To be cheap?

Fixed this for 6.1. https://git.cloudron.io/cloudron/box/-/commit/353369c1e9ffc70a53eeea0cb99019a1b5f98f27

@tamayers This would be nice to have, for sure.

For the most part though, the domain registrar will handle that part of forwarding a full domain to another if you use their own DNS servers, etc. I have done that for a couple of my own domains that I had registered a long time ago for 10 years, but no longer use them so wanted to just forward them to my current ones instead.

It would certainly be convenient for Cloudron admins if Cloudron did this too though. One example I can think of... I have two vanity URLs purchased by two different clients of mine where they want me hosting their email but for the website they want it going to their realtor agency website (for example) which is outside of my control, and would be convenient to set it all in the same space instead of a mix of domain registrar and Cloudron.

Also noted a request for a List view here: https://forum.cloudron.io/topic/3465/dashboard-customize-buttons-on-the-sides-of-apps/4?_=1608519749716

@Mario I actually ran into this myself and had to combine my two private registries into one to work with Cloudron.