@marcusquinn It's a more general tool as an attempt to fix and replace the issues with Email in general. It does that well. It just needs adoption. https://hacker10.com/computer-security/send-email-with-tor-i2p-and-gpg-using-confidant-mail/ https://privacytools.io has other options too

Maybe one of these? https://phoenixnap.com/blog/docker-container-monitoring-tools I'll look into Zabbix, thanks for the recommendation

@paenzy I read somewhere that adding terms and disclaimers to emails made then "contractual", so in some cases and places it is better not to have them. I'm always interested in what's supposed to be law and what becomes hearsay law because lots of people do it and tell each other it should be done. I don't have experience either way but tend not to use email signatures from both habit and to be personable.

@muewe96 Fwiw, btrfs has been used for / for years now as default on OpenSUSE. This post sheds light on why, with XFS the default for /home, on that distro. I started using the "snapper" snapshot tool on a btrfs / on a desktop machine in daily use just to get used to it, very happy so far - but not a vServer.

Even if we could just get LDAP groups working with Nextcloud that'd be a big win imho given how many of us use Nextcloud (I think I'm correct in assuming it's the 2nd most popular app on Cloudron?)

@girish To that end, perhaps this one is better locked at this point

@girish Oops, I realized just now, that I didn't reply to your question yet. What I changed and maybe has to be protected from being accidentally overwritten is the 'datadirectory' option in /app/data/config/config.php. I changed that path from the default path to '/media/mymountpoint'. I don't remember if I had Nextcloud in maintenance mode or put the app in recovery mode, while I changed that path and moved the files. But it was either of them. However, I had some duplicate storage paths in the database afterwards and I manually updated the oc_storages table as described here and did a files:scan afterwards. But that should not be related to what the code for updates overwrites, I guess.

@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... [image: 1610527791540-schermata-2021-01-13-alle-09.49.21-resized.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.