Right I think for this we should rather adjust the package to enable the optionalSso flag, otherwise this can have unexpected side-effects, if the app state assumes Cloudron OIDC and thus ensures that on startup, while the user overwrites some related env vars for custom use. This will especially become an issue if env vars change in the future.
On a brand new DO Ubuntu server, the first pull fails.
root@my:~# TOKEN=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token)
curl --head -H "Authorization: Bearer $TOKEN" https://registry-1.docker.io/v2/ratelimitpreview/test/manifests/latest
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5429 0 5429 0 0 17471 0 --:--:-- --:--:-- --:--:-- 17512
HTTP/1.1 200 OK
content-length: 527
content-type: application/vnd.docker.distribution.manifest.v2+json
docker-content-digest: sha256:c2d41d2ba6d8b7b4a3ffec621578eb4d9a0909df29dfa2f6fd8a2e5fd0836aed
docker-distribution-api-version: registry/2.0
etag: "sha256:c2d41d2ba6d8b7b4a3ffec621578eb4d9a0909df29dfa2f6fd8a2e5fd0836aed"
date: Sat, 14 Dec 2024 15:41:35 GMT
strict-transport-security: max-age=31536000
ratelimit-limit: 100;w=21600
ratelimit-remaining: 0;w=21600
docker-ratelimit-source: 2604:a880:2:d1::
@vladimir-d In the future, I believe we should let the app handle most of it's configuration, environment-wise.
Variables such as RAG_EMBEDDING_MODEL, etc. are all set via the application UI and saved in the config.json file.
Now, for the initial issue of this topic, I've solved it by resetting the embedding model engine.
as @jdaviescoates notes, the SSO setting generally is only during install time, as changing auth backends later causes usually issues within the app and user mapping.
I guess the placeholder text is not ideal for that textarea but the default is to allow the app iteself to respond to the robots request. The docs state this more clearer https://docs.cloudron.io/apps/#robotstxt
"By default, Cloudron does not setup a robots.txt for apps. When unset, the app is free to provide it's own robots.txt."
So the default basically is not to allow all but to let the app handle it.
Can't wait to get this on the store. We need a nice rounded set of AI Apps on Cloudron, now that AI is exploding with hundreds of wrappers and apps...
As well as OpenAI's next 12 days!
Hi @Lanhild sorry to hijack this thread, but can you please have a look at packaging LiteLLM please?
LiteLLM already has Langfuse built in, so this might be interesting to you.
Link to App Wishlist: https://forum.cloudron.io/topic/13141/litellm-openrouter-self-hosted-alternative-proxy-provides-access-to-openai-bedrock-anthropic-gemini-etc?_=1737171723819
They also have a binary pgadmin4-web, used to install the web version on debian, red-hat based, etc.
The tricky part for Cloudron is the setup, there is a setup-web.sh script that needs to be executed to setup (and start?) the app that seemingly needs access to read-only paths.
Other than that, seems pretty straightforward and easily configurable through environment variables.
@girish
To make it more clear, I have made a template repository with all the files and scripts I usually use for my Cloudron apps.
In the future, we might benefit from adopting such a strategy for the Cloudron CLI init script by using these files as a template/starter Cloudron app project. It'd make maintenance easier, more uniform, and make the process less daunting for new app devs.
https://github.com/Lanhild/starter-cloudron
L
