abra app run escaping and environment issues #790

New Issue

2026-02-25T16:11:20Z

fauno commented

2026-02-25 16:11:20 +00:00

related to coop-cloud/peertube#21 coop-cloud/nextcloud#58

we're running into issues with abra app run because it's inconsistent on escaping shell commands, specially flags (see related issues), but we just ran (!) into an issue where peertube npm run needed access to an environmental secret that was set by the custom entrypoint, but abra app run doesn't use it by default, so with everything combined the command to reset admin password became:

abra app run -u peertube tv.pilmaiken.abyaya.la app /docker-entrypoint.sh npm run reset-password -- -- -u root

related to https://git.coopcloud.tech/coop-cloud/peertube/issues/21 https://git.coopcloud.tech/coop-cloud/nextcloud/issues/58 we're running into issues with `abra app run` because it's inconsistent on escaping shell commands, specially flags (see related issues), but we just ran (!) into an issue where peertube npm run needed access to an environmental secret that was set by the custom entrypoint, but `abra app run` doesn't use it by default, so with everything combined the command to reset admin password became: ```sh abra app run -u peertube tv.pilmaiken.abyaya.la app /docker-entrypoint.sh npm run reset-password -- -- -u root ```

😆 1

decentral1se added the enhancement label 2026-02-27 07:37:04 +00:00

decentral1se commented

2026-02-27 16:51:19 +00:00

That -- -- is killing me 😆

peertube npm run needed access to an environmental secret that was set by the custom entrypoint, but abra app run doesn't use it by default

This is usually solved by migrated the env vars into the abra.sh 👇

		mastodon/abra.sh
		Lines 37 to 49 in 986a780c56
	
				environment() {

				    # for sidekiq service bundle exec env var threading

				    file_env "DB_PASS"

				    file_env "OTP_SECRET"

				    file_env "SECRET_KEY_BASE"

				    file_env "VAPID_PRIVATE_KEY"

				    file_env "AWS_SECRET_ACCESS_KEY"

				    file_env "ACTIVE_RECORD_ENCRYPTION_DETERMINISTIC_KEY"

				    file_env "ACTIVE_RECORD_ENCRYPTION_KEY_DERIVATION_SALT"

				    file_env "ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY"

				    declare -x RAILS_ENV=production

				}

abra app run escaping and environment issues

Uhm, I don't know how to reproduce this issue as it currently stands without deploying peertube which I'm not going to do 😛 Do you have a simple reproduction of this issue that can be run locally? You could re-use https://git.coopcloud.tech/toolshed/abra-test-recipe for this.

It's not exactly clear how we want to improve the situation specifically. Can you go a bit more into detail on how you think this can be made better? Obviously the command you had to run is hilariously wild but it's not obvious to me how to improve it 🙃

That `-- --` is killing me 😆 > peertube npm run needed access to an environmental secret that was set by the custom entrypoint, but abra app run doesn't use it by default This is usually solved by migrated the env vars into the `abra.sh` 👇 https://git.coopcloud.tech/coop-cloud/mastodon/src/commit/986a780c564f1f65f1b0bd4770baf5c8d98671d2/abra.sh#L37-L49 > abra app run escaping and environment issues Uhm, I don't know how to reproduce this issue as it currently stands without deploying peertube which I'm not going to do 😛 Do you have a simple reproduction of this issue that can be run locally? You could re-use https://git.coopcloud.tech/toolshed/abra-test-recipe for this. It's not exactly clear how we want to improve the situation specifically. Can you go a bit more into detail on how you think this can be made better? Obviously the command you had to run is hilariously wild but it's not obvious to me how to improve it 🙃

fauno commented

2026-02-27 17:33:33 +00:00

ah that's nice to know thanks. some ideas:

abra app run sets default user as dockerfile's USER
- so operators don't need to know the internals of recipe containers
- although by looking at peertube's dockerfile the last USER is root
- maybe a variable on abra.sh is ok to set default user?
- this would prevent su -c "$@" user commands that are currently breaking escaping (i'm assuming they're nested sometimes)
  - just found out docker exec has a --user flag
abra app run stops parsing flags after the domain or service name
- so we can avoid using -- (the second one on my example was required by npm)
- or quoting like it happened on nextcloud
abra app run or abra.sh receive env vars by default according to service
- i didn't know about abra.sh's environment function but we already set env vars on .env and several .compose.yml so it feels a bit repetitive / prone to forgetfulness
- this is probably for future brain secret management, but secrets in files that are turned into env vars defeats the purpose of them being files. i wonder why it's not more commonly supported.

also, somewhere here, maybe at yunoesque discussion? mentioned rootless containers, so maybe abra app run is a complete sidecar in the future?

ah that's nice to know thanks. some ideas: * `abra app run` sets default user as dockerfile's `USER` * so operators don't need to know the internals of recipe containers * although by looking at [peertube's dockerfile](https://github.com/Chocobozzz/PeerTube/blob/develop/support/docker/production/Dockerfile#L30) the last `USER` is `root` * maybe a variable on abra.sh is ok to set default user? * this would prevent `su -c "$@" user` commands that are currently breaking escaping (i'm assuming they're nested sometimes) * just found out `docker exec` has a `--user` flag * `abra app run` stops parsing flags after the domain or service name * so we can avoid using `--` (the second one on my example was required by `npm`) * or quoting like it happened on nextcloud * `abra app run` or `abra.sh` receive env vars by default according to service * i didn't know about `abra.sh`'s `environment` function but we already set env vars on `.env` and several `.compose.yml` so it feels a bit repetitive / prone to forgetfulness * this is probably for future brain secret management, but secrets in files that are turned into env vars defeats the purpose of them being files. i wonder why it's not more commonly supported. also, somewhere here, maybe at yunoesque discussion? mentioned rootless containers, so maybe `abra app run` is a complete sidecar in the future?

👀 1

fauno commented

2026-02-27 17:50:52 +00:00

so ideally it would've been like this:

abra app run tv.pilmaiken.abyaya.la npm run reset-password -u root

as in "prefix anything the official docs say with abra app run"

so ideally it would've been like this: ```sh abra app run tv.pilmaiken.abyaya.la npm run reset-password -u root ``` as in "prefix anything the official docs say with abra app run"

👍 1

fauno commented

2026-02-27 17:51:09 +00:00

i saw this yesterday for further inspiration: https://github.com/bibendi/dip

👀 1

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/abra#790