Cloudron Forum

@james said: demand is not enough for this feature to be put up higher in the prioritisation queue Thanks. I am still interested in the technical part: Would it be possible to route all the traffic of cloudron through a VPN? Probably not, because a server need to be publicly propagated via DNS (IP resolution), right? So just to understand it right: Is the solution for this feature request to 1) "route all traffic to the cloudron VPN endpoint via a third party VPN? Technically the "endpoint" would still "Just arrive within the network of the cloudron server", is it? (I may still have some gaps in understanding the whole VPN/Networking topic)

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.