search

balena-io-experimental / browser

A drop-in web browser block
98 stars 75 forks source link

Environment variables not being passed to browser block - `su` session #90

Closed danthegoodman1 closed 2 years ago

danthegoodman1 commented 2 years ago

See linked JF thread, it seems like this change https://github.com/balenablocks/browser/commit/c4d9373eeb4805268ea9adbd581fabf55eb4573d does not pass the environment variables properly according to the testing that has been done in the JF thread cc @phil-d-wilson

jellyfish-bot commented 2 years ago

[danthegoodman1] This issue has attached support thread https://jel.ly.fish/65742dff-d0ce-4ed1-a2b6-0843869dc07d

danthegoodman1 commented 2 years ago

This specifically only seems to be an issue if this repo is cloned and used, rather than included from the balenablocks/browser docker image

kb2ma commented 2 years ago

Looks like the command below is appending an "=" to each environment variable name in the generated list:

$ env | grep -v -w '_' | awk -F: '{ st = index($0,"=");print substr($1,0,st) ","}' | tr -d "\n" SHELL=,SESSION_MANAGER=,QT_ACCESSIBILITY=,COLORTERM=, ...

Changing the argument to awk -F removes the "=":

$ env | grep -v -w '_' | awk -F= '{ st = index($0,"=");print substr($1,0,st) ","}' | tr -d "\n" SHELL,SESSION_MANAGER,QT_ACCESSIBILITY,COLORTERM,

I would think this is the format that su -w requires. Have not confirmed yet with a test.

Edit: the command is in src/start.sh.

kb2ma commented 2 years ago

There is a secondary issue that explains the comment above -- that the issue only occurs when the repo is cloned and used, and not from the balenablocks/browser image on docker. The image on docker identifies as v2.0.5 rather than v2.0.6, which is the version on GitHub master. I have verified that the image on docker shows the LAUNCH_URL as expected.

When I build from v2.0.6, I can recreate the error that the environment variables are not defined and the LAUNCH_URL does not display. I also verified that the fix described above to src/start.sh fixes that problem in current master and LAUNCH_URL displays. It's odd though that v2.0.5 from Docker works because the issue with src/start.sh was added in v2.0.2. I leave it to the project maintainers to explain this surprising result, as they know the background of the code base.