@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

Yes, you are all correct, I just did Hetzner bucket w/ S3 credentials, backed up to it, and restored the apps from there. Super easy. Thank you.

No SSL Session requires a complete ssl handshake, whenever a new connection is established. Otherwise Chrome will skip the ssl handshake and omit SNI in ClientHello, only providing the session ticket ID, which the proxy has no way of knowing it.

@d19dotca You are right in the aspect of it being a CDN style backup service. It takes your data and splits it up into 64MB segments and disperses it around their different nodes in the world. When you request to download a file from your Storj service, it can rebuild a copy of that file with only 24 of the closest nodes to your location, no matter where you are in the world. Yes, some of those segments will be in Canada.

@Lonkle How'd you do this? I'm running into issues as I have multiple Cloudron servers with custom apps and only the ability to configure a single docker registry