Closed twasink closed 4 years ago
From what I can tell from the docs, if you set the PIPX_BIN_DIR variable as part of doing the various pipx install
steps, you could install the binaries into a path that wasn't in the /root/
dir, and thus into a place readable by non-root users - e.g. /usr/local/bin
or /opt/bin
.
This would avoid the whole "breaking people's workflow" problem.
@twasink thanks, I had no idea ppl were running this as non-root.
I'll look into that pipx option (will probably choose /usr/local/bin) – and may as well install pipx itself there in the first place too, in case non-root users want to use that too
(will get to this in halfa)
This should be fixed now – please give it a shot (and thanks for notifying me of how you're using these images 👍)
That is indeed fixed now. Thank you very much.
As of PR-297 (https://github.com/lambci/docker-lambda/pull/297), you can't use SAM from the docker images if you're using a different user id.
Context:
I've got several Jenkins builds that use the docker images (mostly lambci/lambda:build-nodejs12.x, but we also have a python one). These connect to the image, when started, with a specific user ID and group ID - 1000:1000. This wasn't a problem until PR-297, but is now - because only the root user can see the global python binaries (as they are installed into /root/.local)
Steps to reproduce: connect to a docker image with a non-root user, and try to execute the sam binary:
The workaround, on our end, will be to configure Jenkins to use the root user ID - but I thought I'd let you know that this behaviour has broken one of the more popular CI servers around.