We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Hi all,
I have configured an fts3 instance (v3.11.0) using docker compose with the following docker images/containers:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 16622c2fd4fb gitlab-registry.cern.ch/fts/fts-monitoring:v3.11.0 "/scripts/startup-ft…" 10 minutes ago Up 10 minutes 0.0.0.0:8449->8449/tcp, :::8449->8449/tcp arendina-fts3-fts-mon-1 682721f923c1 gitlab-registry.cern.ch/fts/fts-rest:v3.11.0 "/scripts/startup-ft…" 10 minutes ago Up 10 minutes 0.0.0.0:8446->8446/tcp, :::8446->8446/tcp arendina-fts3-fts-rest-1 ef5e9f3908cb gitlab-registry.cern.ch/fts/fts3:v3.11.0 "/scripts/startup-ft…" 10 minutes ago Up 10 minutes 2170/tcp arendina-fts3-fts-server-1 06c96e18b270 alpine "sh -c ' apk add --n…" 10 minutes ago Exited (0) 8 minutes ago arendina-fts3-init-db-1 e40216d8bdfc mysql:5 "docker-entrypoint.s…" 10 minutes ago Up 10 minutes 3306/tcp, 33060/tcp arendina-fts3-ftsdb-1 b19f249a04eb indigoiam/egi-trustanchors "/bin/sh -c ' yum in…" 10 minutes ago Exited (0) 8 minutes ago arendina-fts3-trust-1
I have noticed that the fts3 uid is different form the fts3-server to the other two containers as shown below:
# docker compose exec fts-server bash # id fts3 uid=999(fts3) gid=997(fts3) groups=997(fts3) # docker compose exec fts-rest bash # id fts3 uid=1000(fts3) gid=1000(fts3) groups=1000(fts3) # docker compose exec fts-mon bash # id fts3 uid=1000(fts3) gid=1000(fts3) groups=1000(fts3)
This configuration could be the reason of permissions issues or errors. Is this behaviour expected or is it modified in any other fts3 releases?
It seems that this is solved in the v3.12.0, but the last version of the fts-rest is the 3.11.1 and the fts3 uid is still 1000:
# docker run --rm --entrypoint id gitlab-registry.cern.ch/fts/fts3:v3.12.0 fts3 uid=999(fts3) gid=997(fts3) groups=997(fts3) # docker run --rm --entrypoint id gitlab-registry.cern.ch/fts/fts-monitoring:v3.12.0 fts3 uid=999(fts3) gid=997(fts3) groups=997(fts3),48(apache) # docker run --rm --entrypoint id gitlab-registry.cern.ch/fts/fts-rest:v3.11.1 fts3 uid=1000(fts3) gid=1000(fts3) groups=1000(fts3)
Maybe, is it enough to wait the 3.12.0 release of the fts-rest image?
Sorry if I made any mistakes or I was not clear and, please, feel free to move this issue if needed.
Thank you very much! Andrea
The text was updated successfully, but these errors were encountered:
are there any news about this issue? Please, let me know if I have to move it in an other place.
Cheers, Andrea
Sorry, something went wrong.
No branches or pull requests
Hi all,
I have configured an fts3 instance (v3.11.0) using docker compose with the following docker images/containers:
I have noticed that the fts3 uid is different form the fts3-server to the other two containers as shown below:
This configuration could be the reason of permissions issues or errors.
Is this behaviour expected or is it modified in any other fts3 releases?
It seems that this is solved in the v3.12.0, but the last version of the fts-rest is the 3.11.1 and the fts3 uid is still 1000:
Maybe, is it enough to wait the 3.12.0 release of the fts-rest image?
Sorry if I made any mistakes or I was not clear and, please, feel free to move this issue if needed.
Thank you very much!
Andrea
The text was updated successfully, but these errors were encountered: