I've tried to use pgadmin and jupyter notebook under App Proxy today and I can confirm that the issue still exists, since /login/ locations are required by both apps but are also reserved for cloudron. Pretty annoying !
@joseph : this is not solved, can you unmark it?
Hi! Just checking on the status of this issue/improvement. Has it been implemented? I couldn't find any info in the docs.
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.
Any update on this front? LiteLLM is very useful in order to use different cloud backends with OpenWebUI (mistral, anthropic, gemini…). OpenWebUI without LiteLLM only supports local LLMs or OpenAI.
Thanks! I was able to renew certs. I'm backing up stuff and will be updating afterwards. It's a cloudron instance that pertains to my former team, but I'm the only one that has the technical knowledge to do admin stuff. You can guess how well that works 
I have another instance (with a subscription) that runs very smoothly.
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?
Not sure what that means/implies, but looks like you think that'll be the right way to solve this so good enough for me! Should I create a ticket for this change somewhere?
I see, that's a bummer, since the login route isn't configurable by either pgadmin or cloudron. Btw, I wouldn't mind the double login (I just don't want to expose a pgadmin instance publicly, even with auth).
That being said, the reserved /login route may cause trouble down the road as it is a very common route. Maybe consider making it customisable or just change it to /cloudron-login?
Without authentication, it does work as intended (I get the pgadmin login page and can log in).
I'm trying to use the app proxy to proxy to my pgadmin container (which is only available on a private network), but I can't make it work.
Here's the setup:
What happens:
pgadmin4_container | 213.X.Y.186 - - [04/Sep/2023:07:38:42 +0000] "GET / HTTP/1.1" 302 217 "https://pgadmin.domain.net/login?next=%2F" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/117.0"
pgadmin4_container | ::ffff:10.0.C.D - - [04/Sep/2023:07:38:50 +0000] "GET / HTTP/1.1" 302 217 "-" "Mozilla (CloudronHealth)"
Note that hitting directly https://pgadmin.domain.net/login?next=%2F from my browser yields the same behavior (infinite cloudrin login page).
What I was expecting:
It seems related to this, although that's unresolved.
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!
It indeed fails with:
dpkg: dependency problems prevent configuration of linux-image-generic:
linux-image-generic depends on linux-modules-extra-4.15.0-176-generic; however:
Package linux-modules-extra-4.15.0-176-generic is not installed.
dpkg: error processing package linux-image-generic (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-generic:
linux-generic depends on linux-image-generic (= 4.15.0.176.165); however:
Package linux-image-generic is not configured yet.
dpkg: error processing package linux-generic (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
linux-image-generic
linux-generic
What should I do, since the MOTD notes Please do not run apt upgrade manually as it will update packages that Cloudron relies on and may break your installation. Ubuntu security updates are automatically installed on this server every night. ?
Thanks, but the update fails with another error now:
Jan 14 20:43:38 box:tasks startTask - starting task 8390 with options {"timeout":72000000,"nice":15,"memoryLimit":800}. logs at /home/yellowtent/platformdata/logs/tasks/8390.log
Jan 14 20:43:38 box:shell startTask spawn: /usr/bin/sudo -S -E /home/yellowtent/box/src/scripts/starttask.sh 8390 /home/yellowtent/platformdata/logs/tasks/8390.log 15 800
Jan 14 20:43:38 box:shell startTask (stdout): Running as unit: box-task-8390.service
Jan 14 20:43:39 box:shell startTask (stdout): 12004 (process group ID) old priority 0, new priority 15
Jan 14 20:43:40 box:apphealthmonitor app health: 1 alive / 0 dead.
Jan 14 20:43:50 box:apphealthmonitor app health: 1 alive / 0 dead.
Jan 14 20:43:53 box:cloudron Getting logs for box as json
Jan 14 20:44:00 box:apphealthmonitor app health: 1 alive / 0 dead.
Jan 14 20:44:10 box:apphealthmonitor app health: 1 alive / 0 dead.
Jan 14 20:44:20 box:apphealthmonitor app health: 1 alive / 0 dead.
Jan 14 20:44:22 box:shell startTask (stdout): Finished with result: exit-code
processes terminated with: code=exited/status=50
runtime: 44.317s
Jan 14 20:44:22 box:shell startTask code: 50, signal: null
Jan 14 20:44:22 box:tasks startTask: 8390 completed with code 50 and signal null
Jan 14 20:44:22 box:locker Released : box_update
Jan 14 20:44:22 box:updater Update failed with error {
stack: 'BoxError: update exited with code 1 signal null\n' +
' at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:78:17)\n' +
' at ChildProcess.emit (node:events:390:28)\n' +
' at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)',
name: 'BoxError',
reason: 'Spawn Error',
details: {},
message: 'update exited with code 1 signal null',
code: 1,
signal: null
Jan 14 20:44:22 box:tasks startTask: 8390 done. error: [object Object]
Jan 14 20:44:30 box:apphealthmonitor app health: 1 alive / 0 dead.
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?