Many thanks for the answers. I'll just blacklist IP ranges and leave my instance on public IPv4; that seems to be the easiest way to go, even though I'll always worry about it a bit.
It would be nice if the VPN could be the only part of Cloudron that's exposed, and also handle serving the certificates for self-signed certs on local domains.
LiteLLM is getting fairly mainstream imo (although things are moving very fast) and does more stuff than just accessing other models (load balancing, logging, spending checks…) so have a LiteLLM process started besides OpenWebUI would be useful.
In the meantime, I've followed this specific comment (https://github.com/open-webui/open-webui/issues/3288#issuecomment-2219524566) from the thread and I was able to get the anthropic/claude models with just configuration of openwebui, so that's already a bit of a win.
So I've googled the error and ran apt --fix-broken install. I think it broke because I had ran out of space a while ago.
Anyway, I was able to update to v7.2.2 and then to v7.2.5 (but it did not offer to upgrade to v7.2.5 directly).
Everything looks good now, thanks!
I'd like to use my cloudron as an intranet (like this). As of now, I'm using the VPN and my cloudron is exposed on its public IP, not its internal IP. But I think I'm facing a chicken and egg problem: if I switch couldron to listen to the internal IP, the VPN server will not be reachable from outside…
Is there a recommended way to do that?
BTW, the docs says:
In an intranet setup, Cloudron has no way to get Let's Encrypt certificates without a programmatic DNS provider.
I'm not sure how that helps? Let's encrypt can never generated certificates for myinternaldomain.lan, can it?
Hi there,
I'm running cloudron v7.1.4 and would like to upgrade to the latest version (my instance believes it is v7.2.2). Unfortunately, the update fails with:
{
"taskId": "8358",
"errorMessage": "Failed to download https://s3.amazonaws.com/prod-cloudron-releases/versions.json: downloadUrl exited with code 22 signal null",
"timedOut": false
}
The URL in the message indeed 403's, so either the resource should be available and I just have to wait for it to be available again or I'll have to change something on my end.
Any advice?
Hi there,
I'm using cloudron 7.4.3 and I cannot renew my certs.
I'm using digitalocean. Given the logs, the issue does not seem to come from the API connection.
What's weird is this line, given that the challenges are actually matching.
Feb 23 16:02:27 box:dns/waitfordns isChangeSynced: _acme-challenge.domain.fun (TXT) was resolved to "JD5vLWoK0g0EkM5_OJV51UHXDzUUJFbpwIxVCfxWQQY" at NS ns2.digitalocean.com (173.245.59.41). Expecting JD5vLWoK0g0EkM5_OJV51UHXDzUUJFbpwIxVCfxWQQY. Match false
I get this:
Feb 23 16:02:26 box:cert/acme2 prepareDnsChallenge: update _acme-challenge with JD5vLWoK0g0EkM5_OJV51UHXDzUUJFbpwIxVCfxWQQY
Feb 23 16:02:26 box:dns upsertDNSRecord: location _acme-challenge on domain domain.fun of type TXT with values ["\"JD5vLWoK0g0EkM5_OJV51UHXDzUUJFbpwIxVCfxWQQY\""]
Feb 23 16:02:26 box:dns/digitalocean upsert: _acme-challenge for zone domain.fun of type TXT with values ["\"JD5vLWoK0g0EkM5_OJV51UHXDzUUJFbpwIxVCfxWQQY\""]
Feb 23 16:02:26 box:dns/digitalocean getInternal: getting dns records of domain.fun with _acme-challenge and type TXT
Feb 23 16:02:26 box:dns/digitalocean upsert: completed with recordIds:[null]
Feb 23 16:02:26 box:dns/waitfordns waitForDns: waiting for _acme-challenge.domain.fun to be JD5vLWoK0g0EkM5_OJV51UHXDzUUJFbpwIxVCfxWQQY in zone domain.fun
Feb 23 16:02:27 box:dns/waitfordns waitForDns: nameservers are ["ns2.digitalocean.com","ns3.digitalocean.com","ns1.digitalocean.com"]
Feb 23 16:02:27 box:dns/waitfordns isChangeSynced: _acme-challenge.domain.fun (TXT) was resolved to "JD5vLWoK0g0EkM5_OJV51UHXDzUUJFbpwIxVCfxWQQY" at NS ns2.digitalocean.com (173.245.59.41). Expecting JD5vLWoK0g0EkM5_OJV51UHXDzUUJFbpwIxVCfxWQQY. Match false
Feb 23 16:02:27 box:dns/waitfordns waitForDns: _acme-challenge.domain.fun at ns ns2.digitalocean.com: not done
Feb 23 16:02:27 box:dns/waitfordns Attempt 1 failed. Will retry: ETRYAGAIN
[later attempts fail the same way]
Any ideas?