Cloudron Forum

Where do you set this? "US/Eastern" does not show up in the miniflux settings dropdown for timezone for me. Changing to exisiting timezones like "Europe/Berlin" works fine. The list has "America/New_York" maybe that is how miniflux named the us eastern timezone.

Currently, the URL is fixed which makes it hard to cache when avatar changes and the browser. However since the profile avatar is not a public route, we could look into having that delivered by the backend dynamically based on some hash. That might be a good idea, then we can set the cache to forever basically.

How about using Keycloak for this? Now that Keycloak is in the Cloudron App Store

Yes, I've been doing this for years, you just have to make /app/data friendly enough for apps to find what they need. This generally involves setting a few env variables: HOME PATH (including NODE_PATH avoiding npm i -g) LD_LIBRARY_PATH (less common) other app specific ENVs All of these changes do not affect the running app since it's already running with its own ENVs. So these are great for additional services. Nice work @djxx

If you continue to read the aws-cli docs, you can specify where to install them, ie /app/data It's alsways useful to set the HOME dir variable whenever working with the CLI with export HOME=/app/data

I thought I would ask my favorite AI tool a more practical question (assuming Team Cloudron wanted to move to Podman): "How can Cloudron migrate from a Docker architecture to a Podman architecture"? The answer (https://www.perplexity.ai/search/cloudron-is-based-on-a-docker-EEoZGv7DRaKfZhG21OrgsA) is ugly, and in short order... not going to make sense. Unless Docker became unsustainable from a licensing or cost perspective in the future, the costs and risk are huge and the benefits unclear. And a gradual migration does not seem technically possible/advisable either.

Question: What should be the correct directory ownership and permissions setting for the ollama-home folder on a mounted Volume?

@charlesnw yes, the OP is a recommendation to add this as a health check notification. I don't think it would be practical to try and automate the setup, when a simple notification to advise it is missing and needs the user to setup with their hosting would save from a lot of bounced mail head-scratching. I solved this for myself through accidental discovery. There's no greater crime than wasting someone's time, and any user not knowing this is needed could lose unlimited amounts of time not knowing this is the problem. Basic need. Basic solution. No reason to debate if this is a good idea. Just persuade that it would be a respectful thing to implement. As I say, I'm alright. I'm giving time to this thread to help save others from lost time from not knowing this is their issue.

Seems like a few issues intermixed here. For a start userland proxy in docker should be false. This set however in /etc/systemd/system/docker.service.d/cloudron.conf by the cloudron startup script. On port 172.18.0.1:3003 the Cloudron docker proxy addon would listen, so this also hints at docker having an issue with the network bridge it supposed to have created. Otherwise most likely if you had a disk being 100% full situation, all bets are off, unfortunately. This is not so much related to Cloudron code but other linux services we use like mysql and docker

Unfortunately, I can't quite reproduce this here. Do you have an idea, which plugin/module might be requiring PyQRCode so I could test this further?

@necrevistonnezr uhhhmmm Since I set up everything with ansible, I once found this out, put in my playbook and forgot about it. That it does not exist in the deb doc is questionable.

RAG with documents in a Docker https://github.com/SciPhi-AI/R2R

I tried to drop down to the www-data user but no success. root@b1e03a66-bb9e-4808-aecf-68c518fed0d5:/app/code# ../data/tasks-via-email.sh rake aborted! ArgumentError: Missing `secret_key_base` for 'production' environment, set this string with `bin/rails credentials:edit` (ArgumentError) raise ArgumentError, "Missing `secret_key_base` for '#{Rails.env}' environment, set this string with `bin/rails credentials:edit`" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/application/configuration.rb:519:in `secret_key_base=' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/application/configuration.rb:503:in `secret_key_base' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/application.rb:470:in `secret_key_base' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/application.rb:205:in `block in message_verifiers' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/message_verifiers.rb:132:in `build' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/messages/rotation_coordinator.rb:85:in `block in build_with_rotations' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/messages/rotation_coordinator.rb:85:in `map' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/messages/rotation_coordinator.rb:85:in `build_with_rotations' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/messages/rotation_coordinator.rb:19:in `[]' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/application.rb:232:in `message_verifier' /run/redmine/vendor/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/railtie.rb:355:in `block (3 levels) in <class:Railtie>' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:97:in `class_eval' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:97:in `block in execute_hook' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:87:in `with_execution_control' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:92:in `execute_hook' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:62:in `block in on_load' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:61:in `each' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:61:in `on_load' /run/redmine/vendor/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/railtie.rb:354:in `block (2 levels) in <class:Railtie>' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:94:in `block in execute_hook' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:87:in `with_execution_control' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:92:in `execute_hook' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:78:in `block in run_load_hooks' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:77:in `each' /run/redmine/vendor/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/lazy_load_hooks.rb:77:in `run_load_hooks' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/application/finisher.rb:94:in `block in <module:Finisher>' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/initializable.rb:32:in `instance_exec' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/initializable.rb:32:in `run' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/initializable.rb:61:in `block in run_initializers' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/initializable.rb:60:in `run_initializers' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/application.rb:435:in `initialize!' /app/code/config/environment.rb:16:in `<top (required)>' /run/redmine/vendor/ruby/3.3.0/gems/zeitwerk-2.7.2/lib/zeitwerk/core_ext/kernel.rb:34:in `require' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/application.rb:411:in `require_environment!' /run/redmine/vendor/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/application.rb:559:in `block in run_tasks_blocks' /run/redmine/vendor/ruby/3.3.0/gems/rake-13.2.1/exe/rake:27:in `<top (required)>' /home/cloudron/rbenv/versions/3.3.4/bin/bundle:25:in `load' /home/cloudron/rbenv/versions/3.3.4/bin/bundle:25:in `<main>' Tasks: TOP => redmine:email:receive_imap => environment (See full trace by running task with --trace) root@b1e03a66-bb9e-4808-aecf-68c518fed0d5:/app/code#

@nebulon I’m wondering… since Cloudron depends entirely on Docker networking to function… is there maybe room to improve the IP blocklist checking so that it ignores any entries of the current Docker networking ranges such as 172.18.xxx.xxx addresses? It feels to me like there would never be a use-case to block those, and while we certainly need to use reliable IP lists (lesson learned, haha), I also wonder if this feature should be improved in the future to ignore any private IPs or at least any Docker IPs.

With the hint from the upstream user, we were able to fix the packaging and this should be resolved now.