G
I have renamed the events to make it clearer.
Delivered -> Sent (external server confirmed that it took the mail from us)
Received -> Saved (this is just to log ack from "dovecot" saying it saved email to the disk)
Queued -> Now displays "Queued for inbound delivery" or "Queued for outbound delivery" depending on the direction of the email .
@mdrockwell that's correct . yes to both .
The two corresponds to how many apps you have installed at that point in time. So, you can install and uninstall apps to be under that count .
@d19dotca right, what I mean is that disabling the rule by setting to 0 for the validity.com rule is the correct approach .
As for caching, you can experiment with custom configs for unbound - https://docs.cloudron.io/networking/#unbound . The default Cloudron config uses cache-max-negative-ttl as 30 and cache-max-ttl as 300 . If you change these, it will have side effects on the DNS propagation checks at app installation time. Maybe unbound has a way to have low ttl for your own domains but not the rest, not sure.
Resolved in support@ . Currently, you have to email us to downgrade to free plan (after cancelling the subscription).
@d19dotca the mail container already uses unbound which is a local caching, non forwarding DNS server. However, the caching is intentionally low so that we can "fresh" results for latest DNS values etc. I don't think there is an easy fix for this. I suggest simply not using their servers .
There's a number of reports of the same issue on the web and some posts even saying validity has gone fully paid (https://lists.apache.org/thread/m4s61n1h7glpjt9nngm3lch9nht026zc). Some bug reports - https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8278 and https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8244 . So, I think disabling the rule by setting it to 0 is the correct approach .
@luckow thanks for reporting, I think https://git.cloudron.io/packages/n8n-app/-/merge_requests/64 should fix it
The correct fix needs to come from n8n - https://github.com/n8n-io/n8n/issues/14546#issuecomment-2858048370 . I guess if they don't fix it upstream , the package can bundle it's own nginx as a workaround .
@d19dotca said in Shouldn't we get an alert when a service container fails / is unhealthy?:
checking so that it ignores any entries of the current Docker networking ranges such as 172.18.xxx.xxx addresses
For the moment, I have added validation to not accept such addresses . Ignoring this properly is more complicated (since we have to filter it at apply time) but atleast it won't let you save the blocklist easily .
Package is now migrated - https://forum.cloudron.io/topic/13717/trilium-package-migrated-to-triliumnext
The original Trilium project is in maintenance mode
The package has been migrated to use TriliumNext . As for Migration - There are no special migration steps to migrate from a zadam/Trilium instance to a TriliumNext/Notes instance. Simply install TriliumNext/Notes as usual and it will use your existing database.
Thanks @Gengar . I have put it in the code - https://git.cloudron.io/platform/box/-/commit/7f87af5a0827af431a3ecb8bfca4bc693c3707b0
Our beloved FilePizza is back 
They made a new v2 version and the package is now updated.
From https://github.com/kern/filepizza?tab=readme-ov-file#whats-new-with-filepizza-v2
What's new with FilePizza v2
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).
@charlesnw said in What's coming in Cloudron 9:
Can you expand on this a bit? The current backup UI shows the progress.
We want to show a proper percent as well as time when uploading/downloading . The code does not know the size of the backups and thus cannot accurately guess how much time based on the upload/download speed. The end result will be "5 mins remaining..." like progress.
As in per application?
yes, that's the plan!
@zonzonzon are you able to try just the below instead of adding /mcp route ? This is more generic and I hope it works across all routes.
# compression chunking logic will interfere with SSE packet flushing
gzip_disable "text/event-stream";
# what responses are proxied
gzip_proxied no-cache no-store private expired auth;
@potemkin_ai not 100% sure what the exact question is. The translations in weblate contains Cloudron in it. The json files are downloaded directly from weblate. The email is generated by search/replace of the keys in the ejs file with the translations in the json .