What @d19dotca mentioned is correct, the next release will solve this issue and the current warning can be safely ignored for now.

@WiseMetalhead yep, that's exactly what I was looking for, thanks! I thought I typically keep up with recent posts on the forums but somehow missed that one. Looks like all is well and will be resolved with the next Cloudron release!

@girish Thanks for responding so quickly! I'll need to revisit my DNS knowledge to get that up and running. Doesn't seem too crazy to do. Thanks for the link, and also for actually trying to answer Daniel's question inside your link. Too many times people say "just don't do that" or, "do this other thing instead". Drives me insane

Okay, this was kinda weird. Did register the domain and added it to CloudFlare. Got the error "invalid domain" while adding it on Cloudron. Got the error while using CloudFlare, but also with wildcard. As I had some other work to do, didn't really check after my post. As I tried to add it to Cloudron for a screenshot and after that the manual solution, it suddenly worked, while having selected CloudFlare. So maybe there was a problem with resolving the domain before, but it is working now at least.

Ok, finally sorted after stopping queries that were locking old txnids and then doing a full vacuum. I suppose restarting the postgres container could have done that. This was useful to find blocking queries, in addition to pg_terminate_backend: SELECT pid, datname, usename, state, backend_xmin, query FROM pg_stat_activity WHERE backend_xmin IS NOT NULL ORDER BY age(backend_xmin) DESC; Went from 88% full to 38% full in about 10 minutes.

@colonelpanic said in Cloudflare Setup Questions: I assume that renewing the Let's Encrypt certificate would not be an issue with the proxy turned on because Cloudron is using a DNS challenge instead of HTTP challenge. Is that a true statement? Yes. Proxying can be left turned on, Cloudron will manage to get certs via DNS challenge. What would be the benefit of creating a Wildcard Origin Cert on Cloudflare and uploading it instead of using Let's Encrypt? AFAIK, there is no benefit. I think the wildcard origin cert is intended for cases where one cannot get a valid cert via DNS or HTTP automation (like some intranets that block outbound access).

@fbartels Thanks for the already asked link. The solution worked from the link: sudo growpart /dev/sda 3 sudo resize2fs /dev/sda3

yeah, I am not sure what changed on Cloudflare side, but we had to do this on our servers as well.

@hollosch

@mehdi Ohh didn't thought about that ! thanks a lot !

I was able to reproduce both issues, thanks for reporting! The proxy auth cookie secret is not persisted. It's stored in platform runtime data. I have migrated this into the database. Redirection logic was incorrect when the token is invalid. This is also fixed.

@robi I guess it could but the app doesn't (maybe for privacy reasons).

@solarsimon said in how extensive are backups?: I am sure you can make my worries disappear... @mehdi said in how extensive are backups?: @solarsimon Dumb question but ... have you tried in another browser, just to make sure it's not a cache problem ? no words. It had to be that simple. solved, or better erase

@msbt thanks so much. My interpretation of the fix suggested didn't work. I have posted a follow-up question there.

For future reference i managed to clear it up by using a slightly modified version of Girish's search command. It seems like the length limit applies to path length not just the filename length find . -type f -print|awk '{print length($0), $0}' | sort -n Went into the web interface and deleted / renamed files longer than 156 bytes and finally cleared trashbin/versioned files (wipes all deleted / old versions of files - careful): sudo -u www-data php -f /app/code/occ versions:cleanup sudo -u www-data php -f /app/code/occ trashbin:cleanup @robi @girish agreed it would be awesome if there was an automated way to handle this in the future

@msbt Thank you, that makes sense!

Amazing, and makes all the difference!

@mehdi this was indeed a bug in the restore code path. the setupToken, as you guessed, should be sent in the top level object and not as part of the backupConfig . Fixed now.