just to not miss this, have you tried to set the cache retention lower first? https://docs.cloudron.io/packages/mastodon#cache-retention-days That has drastically reduced the amount to backup for my instance. Worst case my instance just has to refetch when scolling the timeline

Thanks! One data point from today's restore: the time was driven by the number of files, not their size. The ~100k small thumbnails took most of it, since every file costs a round trip over sshfs, so skipping unchanged small files would help just as much. A quick size + mtime check before hashing would probably keep the CPU side cheap too.

@girish thanks, yeah that's what I've done, I was just not sure if you would consider that best practice of if it gets overridden at some point by some other setting in the platform-code

CR > Email > Mailboxes > Forwarding: Could this be related? Is this the preferred method of forwarding mail now? I have mail forwarded using rules in Roundcube.

The report itself is correct. I think the main issue is that Cloudron doesn't know the old IP address and even if it did it cannot remove it without user consent. Maybe user is re-using the IP for some other stuff and legitimately put it there.

„ It's like he skipped GPT 2 - 5.4 And now he just found out but hasn't figured out the downside and awful architecture it comes up with“ I agree with this position and would vote against that feature request for now.

Interesting report. Another quirk of community packages. I wrote the whole backup logic with the assumption that backup fail was something we should fix. If the did fail, either it was some platform error or some external backup service error

@girish thank you so much. Excited to see what you find.

Hello @loudlemur @LoudLemur said: Sorry for the noise, twice in one thread. No problem and I don't mind it at all. It is always good to exchange thoughts which leads to more knowledge for everyone and this also creates better and more stable software.

I guess we can check for .docker.com and .docker.io instead. Would that work @andreasdueren ?

I presume you noticed, but, 18 is not 19 that's sadly true. 19 will be released... soon this autumn (also, I haven't tested that change yet, only have that from the docs)

Good idea, will add to the Cloudron 10.1 list to investigate @andreasdueren . We added a concept of Default apps in Cloudron 10 (which is still "experimental") . Maybe that is a fit for this too cc @nebulon

Is now a better time to revisit this?

@girish said: Fixed. We display inactive users separately now at the bottom of the users list. What does "inactive" mean here? Edit: Ah, presumably it means this box in the edit user view is unchecked: [image: image.jpeg]

Platform wise we could support this, however since nearly all apps manage their own login sessions after the Cloudron OpenID login, there is little on the platform side we can do. The centralized logout can be done in the apps we write and provide but only because there we reevaluate the login session/tokens against the OpenID auth provider all the time.

I converted it to a feature request for Cloudron itself since it is backend related.

Good idea, but password complexity is not measured with characters list or types but with entropy. You can have good password with 7 characters and bad password with 10 characters. An example to understand. I used KeePassXC password generator to measure these passwords entropy: This is 7 characters password: ⊌ӊ⇊ٳ➟⋋О Entropy: 116 bits. Only "special characters". No length, No Alphanumeric, no mixed case. This is 15 characters password: 8&w^3fck%NdMh4W Entropy: 94 bits Length, Alphanumeric, Special characters, Mixed case. The first one only respect one requirement asked but is better than the second that respect all. The difference is huge if try with only 12 characters: gx@V5iZLfuN7 Entropy: 65 bits. All requirements mets as the previous one, and it's not the worst i can have with 12 characters. As it's common mistakes about password complexity, i think Cloudron should never allow to require characters list/types. Instead, password complexity requirements should be technically measured with true entropy/bits algorithm as in KeePassXC that way good password will be allowed based on real complexity not on arbitrary rules. The settings can always be displayed simple in settings with "Weak", "Average", "Good", "Excellent", etc... instead of entropy bits. Finally, asking password to have specific characters list or type will break auto-generated password by password manager because websites has not all the same rules and password generators not the same default settings. I hope this will help.

@nichu42 said: I have an 8 Core Intel(R) Xeon(R) Gold 6142 CPU @ 2.60GHz VPS. My Mastodon app data directory has ~ 450,000 files. FYI my yellowtent folder has ~ 250.000 files on an SSD - just to give you perspective on the benchmarks.

Hello @andreasdueren I have merged the topics.