Was this ever implemented in any way? I'd like to visit services, system, and settings faster. Oh, and graphs in the app settings. Maybe a shortcut for that too. I have multiple CR's to keep an eye on. Widgets on the dashboard might work too.

@robi fair, yeah, that's a good point about individual app restores.

@makemrproper yeah, and actually it seems I might've been right afterall! I was sure I'd read something about the size... so I just search that thread for size and it is indeed there: Backup integrity - store size and checksum of backups. If they've got the size stored then should be easy to display it somewhere too!

Aha, right. Got it, thanks! @BrutalBirdie! @robi was suggesting just perhaps adding a [image: 1746952270741-e5b7693e-5b34-4b2b-9ec9-640d9ac4756e-image.png]

@joseph Yes

I'm currently doing something similar. I have a Proxmox cluster setup with local and cloud backups. If a server goes down the other 2 take over. I'd have to have a 3 server failure to be offline.

I am also using app proxy,but my question is unrelated to that, nebulon has already noted the intended use Peter (and now I) meant.

I got some mails about this last week and some people wondered what the situation with Cloudron is. I thought I will update it here. Let's Encrypt is discontinuing support for OCSP altogether in the coming weeks - https://letsencrypt.org/2024/12/05/ending-ocsp/ . A brief summary is that OCSP and CRL are two methods a browser can use to check the validity of an already issued certificate. OCSP involves querying a URL and CRL involves downloading a database of revoked certificate serial numbers. OCSP has a big privacy issue - when you visit example.com , the OCSP check can make the CA log the domain + IP (willing or forced by law). The "OCSP Must Staple" was a way to circumvent this but this hasn't gained much traction . As to what this means to Cloudron... nothing really. We did not enable OCSP Must Staple in the first place because nginx required some manual priming and downtime to make it work reliably (a point noted in the above URL).

Currently, the URL is fixed which makes it hard to cache when avatar changes and the browser. However since the profile avatar is not a public route, we could look into having that delivered by the backend dynamically based on some hash. That might be a good idea, then we can set the cache to forever basically.

@charlesnw yes, the OP is a recommendation to add this as a health check notification. I don't think it would be practical to try and automate the setup, when a simple notification to advise it is missing and needs the user to setup with their hosting would save from a lot of bounced mail head-scratching. I solved this for myself through accidental discovery. There's no greater crime than wasting someone's time, and any user not knowing this is needed could lose unlimited amounts of time not knowing this is the problem. Basic need. Basic solution. No reason to debate if this is a good idea. Just persuade that it would be a respectful thing to implement. As I say, I'm alright. I'm giving time to this thread to help save others from lost time from not knowing this is their issue.

@necrevistonnezr uhhhmmm Since I set up everything with ansible, I once found this out, put in my playbook and forgot about it. That it does not exist in the deb doc is questionable.

Indeed, the login view has changed for Cloudron 9, and we will keep that in mind to make it clearer what the app and the auth provider is. @perelin for the OpenID login button in the apps. As far as I am aware, penpot does not have support to customize that, yet. Maybe you can create an upstream feature request with penpot about this.

@JLX89 said in EntraID / AzureAD LDAP wrapper: How about just using an Enterprise App with SCIM Provisioning? That would be great

@girish That sounds great! The last two incidents were this would have helped me were developing over several days (exploding Rocket.Chat logs and syslog.js), so this should be within the necessary precision to prevent this type of situation.

@nebulon Thank you so much. Very helpful and quick.

Amazing that is some very old typo apparently, never noticed either! It is now fixed with https://git.cloudron.io/platform/box/-/commit/f82f3fa8587a99f71d840981d77acb0aca87ac2e

9.2.14 is the latest Manticore version. https://github.com/manticoresoftware/manticoresearch/releases/tag/9.2.14 Here are the improvements since Manticore was first requested: https://github.com/manticoresoftware/manticoresearch/compare/9.2.14...6.0.4

@girish Perhaps the Nextcloud Talk High Performance Backend as well as the Elasticsearch could be installed together onto the same server, somehow. There is also Manticore: https://forum.cloudron.io/topic/9753/manticore-search-oss-fast-database-for-search-alternative-for-elasticsearch