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

@lonk I see, let me try to understand who WP multi-site works then. I thought we had to auto configure the domains in the package, maybe that's not needed.

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

@staff any chance of getting this added? thanks! 🙂

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.

@girish Yes, I would be good to say have a Minio bucket to which to push backups to on your friends' Cloudrons, and be able to have a backup on each Cloudron. (See diagram below)

4273a466-385d-4ecc-be95-82421765049a-image.png

*Small square is Minio bucket

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?

This is fixed in 6.1 - https://git.cloudron.io/cloudron/box/-/issues/756

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

Just tried pruning my OneDrive backup repo with a newish beta restic-v0.11.0-246-ge1efc193 from https://beta.restic.net: Pruning now took less than 10 Minutes(!) compared to around 48 hours(!) before.

What I use for backing up (daily):

#!/bin/bash d=$(date +%Y-%m-%d) if pidof -o %PPID -x “$0”; then echo “$(date “+%d.%m.%Y %T”) Exit, already running.” exit 1 fi restic -r rclone:onedrive:restic backup /media/Cloudron/snapshot/ -p=resticpw restic -r rclone:onedrive:restic forget --keep-monthly 6 --keep-weekly 4 --keep-daily 7 -p=resticpw

What I use for pruning (once a month):

#!/bin/bash d=$(date +%Y-%m-%d) if pidof -o %PPID -x “$0”; then echo “$(date “+%d.%m.%Y %T”) Exit, already running.” exit 1 fi restic -r rclone:onedrive:restic prune -p=resticpw

Might increase pruning frequency if it proves to be as fast over a longer period...

Ooops, correction, it's €3.99 for 100GB and €19.99 for 1TB, doesn't show you that until you tick the option on the config page. The Unlimited part is just for bandwidth.

OK, So Wasabi still seems cheaper on the backups, with Hetzner Storage Boxes sometimes less if you'd be adding and deleting a lot of files on Wasabi.

In this case, I don't know another need for FTP backups, so defer to others if anyone knows other options, perhaps home-servers with it.

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

@girish Oh, absolutely with a custom app, I mentioned in the original post that I'm going to build my own Wordpress Stack to simply and only add this. But I saw benefit to other user's being able to script something post-update as that's literally the only thing my stack will do differently than the default Wordpress app (I'll have to integrate your updates into my stack manually each time so I still wish there was a way to run an external custom sh script post-installation).

As you can see my custom script simply uses the CLI to upgrade all databases with any new required formatting if and only if any updated Wordpress core or updated plugin require it. When you update from the Cloudron interface, it simply updates all the files and Wordpress has this really annoying tendency to not upgrade the databases post-upgrade invisibly. The script above is the only way to make sure file versions and database versions stay in sync 100% of the time every update.

This becomes nearly unavoidable if you want to support multisite in the future since the problem becomes more convoluted in that installation type so my script detects multisite installations and runs database upgrades accordingly with WP CLI commands or single site only commands if it's a single site.

I actually think the script below should be an optional "automatic upgrade plugin and themes checkbox when updating Wordpress core" option for Wordpress installations as well, here's the WP CLI code for it:

# Plugin updates wp plugin update --all wp plugin update --all --skip-plugins --skip-themes # Theme updates wp theme update --all wp theme update --all --skip-plugins --skip-themes