@nebulon Had to wait a few days to execute on moved cloudron server. all resolved now. Thank you for this.

@neweconomy I think this is similar to https://forum.cloudron.io/topic/6509/unable-to-log-into-the-app-store . Can you go to Services view and check if unbound is running ? Can you restart it if it is not running ? After that you should be able to login .

Here's the debian bug for unbound - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989959

@ei8fdb I delete the dump file, then decide to backup from that's date - restore will fail? No, a copy a the postgresql file is in the backup. The file at /home/yellowtent/platformdata/<appid>/postgresqldump is a temporary file. When we want to backup an app, we create a dump from postgresql and save it to that file. Then we upload that file to wherever the backup is located . After the backup is done, that file has no real use but we just keep it around because in some rare cases where you don't have backups it can help in recovery. So, to summarize: Safe to delete /home/yellowtent/appsdata/app-container-id/postgresqldump . But this will be created as part of the backup process, so it's going to be a pain. You have to delete this file everyday. Your final backup location will have a copy of the above file. Under <timestamp>/appid/postgresqldump . This is your backup, don't delete this file!

Generally, we are able to manage posts which have spam content. Most existing users, they are quite benign. I think we are lucky so far with that we do little to no moderation (maybe only fixing some typos and moving to the right category) In this specific case, the issue was the profile page had spam content. This is a bit more elaborate and I am not sure how @SPRADEEP even came across it. I think if we have a script to clean up profiles which are over 2 weeks old and have not posted anything and have some junk profile, we can delete them. I can't imagine it's hard to spot junk in profiles with some basic word matching.

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