Venv issue access with when using docker image indico v3.3.10 and above

Administrators
1

Dear indico team,
we have gone through long process of deploying indico in kubernetes.
We have been testing indico v3.3.9 but when decided to upgrade and use newer version of docker images e.g. v3.3.10 and above we started facing unusual issue due to permissions in venv, at least this is what is reported by logs in pod, as result indico application fails to run.

Our kyverno policies does not allow changes directly in filesystem when for example using runasuser:0

we compared directory permissions in older and newer indico images and they seem same, yet we are not sure what is causing following which does seem to be related with new indico images coming from upstream. We get same symptoms when used tag v3.3.10, 3.3.12 and latest.

k logs -f indico-56d9fbd944-k4ds2

/bin/bash: line 1: /opt/indico/.venv/bin/activate: Permission denied

We appreciate if you could give as some guidance as we are not able to move forward with migration of indico for production purpose.
thank in advance for you help!!

2

I don’t think we can really help you there… nothing really changed on our side, the switch to debian trixie as the base image was shortly before the v3.3.9 release so that’s not the cause either.

3

everything is owned by user indico (id 995), so you probably need to run it as that user.

And as is usual wiht python venv, activate is not executable, it needs to be sourced, so if you want to activate it you need to use:

. /opt/indico/.venv/bin/activate

(dot space /opt/indico…) e.g. in your startup scripts.

4

Thanks for your reply, you were correct, we also did notice by looking into docker image directory that indico ID has changed from 999 to 995. Changing this in all the yml files it recovered the application.

Any idea why the indico id keep changing as this may cause us issues when running docker image in production and it requires debugging time. Something maybe indico team can answer? and is there a page we can follow those changes? thanks

5

We didn’t actively change it… but we’re also not setting a fixed one, so maybe it changed when we changed from Debian Bullseye to Debian Bookworm?

6

ok it looks like this only happened in the 3.3.12 image:

$ podman run -it --rm ghcr.io/indico/indico:3.3.9 id
uid=999(indico) gid=999(indico) groups=999(indico)
$ podman run -it --rm ghcr.io/indico/indico:3.3.10 id
uid=999(indico) gid=999(indico) groups=999(indico)
$ podman run -it --rm ghcr.io/indico/indico:3.3.11 id
uid=999(indico) gid=999(indico) groups=999(indico)
$ podman run -it --rm ghcr.io/indico/indico:3.3.12 id
uid=995(indico) gid=995(indico) groups=995(indico)

We’ll fix it and re-publish that image w/ the old 999 uid.

7

Done, the new 3.3.12 image is now on GHCR and Docker Hub.