-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Patch plumbing of docker-compose UID/GID build args #4527
Conversation
Great description |
shell usually has let's add
How do you think? |
Thanks for the quick review. I will try your suggestions tomorrow. Hiking today. ⛰️ |
Looks great. |
Ok, so here's what I ended up doing since first commit:
I went heavy on comments throughout everywhere because this stuff is so easy to get wrong and the file permissions are usually pretty opaque error messages if you're not experienced. Have dealt with this exact issue multiple times across several professional/personal projects now that I favor docker. |
I am actually not sure this is the correct decision. What if the caller is not the There can be three user/hosts pairs involved:
both the I do prefer it this way. I think I would need a bit more convincing to change it based on above reasoning. |
Can you trigger the CI again when you get a chance? I think I patched it. Thank you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- make erigon doesn't work on MacOS. It doesn't store user in /etc/passwd https://superuser.com/questions/191330/users-dont-appear-in-etc-passwd-on-mac-os-x
- CI also red by some reason: https://github.com/ledgerwatch/erigon/runs/7104458854?check_suite_focus=true#step:3:13
- Maybe build on hub.docker.com will also fail, maybe need define DOCKER_UID in ./hooks/build
Ok thanks, I will fix MacOS. I know we can add MacOS as a github runner too. Will try to get it working via my own repo so I don't need to keep triggering failed runs here. |
Ok, I have added fixes and then updated the README again to reflect the changes:
I tested the CI on my own fork repo, so it should work if we try running it. |
looks great. I will run test on hub.docker.com then merge |
I see that it failed. If you can share the logs with me, I can try to patch it. (there was a login prompt so I'm assuming I don't have permissions) I have also pushed one more change needed to make some README changes I made play nice together even when the env vars aren't setup yet. This doesn't affect the existing CI, just the new targets I made for helping create the "erigon" user. |
from hub.docker.com
|
Ok thank you, I need to handle the |
Updated:
Notably, on my local workspace, when calling - @git submodule sync --quiet --recursive
+ @git submodule sync --quiet --recursive || true This case was not hit on Docker Hub since I believe the repo gets checked out with root file permissions. This case was not hit in CI because the docker builds were ran as non-root user. With these changes, |
I think the CI that failed is nondeterministic / inconsistent and unrelated to these changes. If you re-run the one job, I'd expect it to work. I notice that a couple times on my own fork. Thanks for your help. |
Also getting this on my server while on root.
|
@0xakihiko Looks like you're running your build as root. Specify You can see an example of this in the That said, we could patch the Dockerfile "RUN adduser ..." layer so it gracefully ignore creating the user if both are passed in as |
May
Yeah this makes sense. |
@stoooops I suggest bringing back default values for |
I think it make sense to return 1000 as default for backward compatibility. done by: #4702 |
I think there is something missing in the readme. My setup: When I run: I get the following error/issue. I am supposed to type in a password for erigon. But the password is disabled.
Any ideas? |
Issue
The UID/GID docker build args are only partially plumbed. For docker-compose build flow, they were hard-coded to 1000/1000 in multiple places.
Expected Behavior
I can use a dedicated user with UID != 1000 and/or GID != 1000 without permissions errors in any service defined in docker-compose.yml
Symptoms
At least 3 docker services fail to come up if you use a user with UID != 1000 or GID != 1000. The services that fail are rpcdaemon, prometheus, and grafana (file permissions).
Fix
services > erigon > build > args
in thedocker-compose.yml
, so the args are passed in to the docker process from docker-compose at build time.env.example
with${DOCKER_UID}
and${DOCKER_GID}
specified${DOCKER_UID}
and${DOCKER_GID}
for prometheus, grafana servicesThese fixes allow me to use a user on my host OS with UID != 1000 and/or GID != 1000 without the docker-compose bringup failing.
Nice-to-have
Improved debugging for future users:
PUID
/PGID
toDOCKER_UID
/DOCKER_GID
(on host OS) andUID/GID
(in Dockerfile)Author
Patched written by cory.eth (Cory Gabrielsen) (@cory_eth).