Cloudron Forum

Hello @nottheend @nottheend said: "route all traffic to the cloudron VPN endpoint via a third party VPN? The idea would be to only allow access to configured apps through the Cloudron VPN app or a custom VPN you can configure.

I'll stick with: @nebulon said: But if this is not a production server, this is probably fine. Added cron job: 0 3 * * 0 curl -fsSL https://ollama.com/install.sh | sh && systemctl restart ollama.service Hoping for native GPU support in the Cloudron Ollama package at some point

@potemkin_ai then it's not clear what you're asking as your statements seem confusing and contradicting. You are not stuck, you have many options. Now what?

@dsp76 thanks ! upcloud also has it by now. The main blocker is that docker does not have any raccoon packages yet.

Hello @anthony-tran Indeed, the IPv6 records exit. dig AAAA change.anthonytran.fr +short 2001:1600:13:101::1e95 dig AAAA my.anthonytran.fr +short 2001:1600:13:101::1e95 So this is some DNS issue. I you run the dig commands from your Cloudron server and from inside the failing apps, do they resolve correctly?

Meilisearch as an addon would make sense and I believe a fair number of already package cloudron apps could benefit from it, such as the following ones to start with: Linkwarden Freescout LibreChat Koel Ghost Wordpress Apache Answers Also OpenArchiver if it ever get packaged. Would be great!

@nebulon said: I added the path info directive to test this, but the result is the same. Can't get past any auth there using the Authorization header. The path info is shown (I think correctly) in the debug logs though: [PATH_INFO] => /accounts/ClientLogin/ I am also no php developer but it seems the auth part of the plugin would be unrelated to that at https://github.com/eric-pierce/freshapi/blob/master/api/greader.php#L39 It's been a while, and Cloudron has updated to Cloudron 9. Any chance that this upgrade makes installing this plugin any easier? I've tried myself, but haven't succeeded, but maybe someone smarter than me might figure out a way? It's still a plugin that would future proof TTRSS and be very useful, I believe. There are setup instructions here: https://github.com/eric-pierce/freshapi#non-official-docker-based-installs and a discussion with a new post on permissions here: https://github.com/eric-pierce/freshapi/issues/7#issuecomment-3328543401 If anyone can solve this, I'll be very happy. Thank you!

It is in its last leg testing wise, will be out soon for new installations.

Not sure how many apps/domains are involved here, but maybe on full dns sync the api gets into some kind of rate-limiting which reports wrongly. Since you mention individual new subdomains work, can you just submit the location form for one of those faulty apps and see if that works out?

@james It is all working now. Many thanks!

@girish Thanks a lot - Much appreciated!

James, I found the solution. I forget to add {} before and after the variable, that makes my config.json error. Now, it's solved. { "signups_allowed": false, "invitations_allowed": true, }

@zigmasdirigeant said: Btw, this shouldn't be inside N8N. This is more a request for an app, not N8N alone. I agree, I'm not even sure how I did that, I tried changing it but couldn't find how.

Hello @leighmhart At this point your Cloudron system has become a black box, and we can not analyse this issue from just forum posts. Since you have run some nft commands, please ensure that the service nftables.service is not enabled or running. systemctl disable --now nftables.service iptables and nftables can be run together, but we do not support this at all and it will cause issues if not done properly. Reboot your system after that. This should ensure that the Cloudron default for iptables is restored. If the issue persists, please report back here.