| Message ID | 20240405134232.5406-1-ayoub.zaki@embetrix.com |
|---|---|
| State | New |
| Delegated to: | Stefano Babic |
| Headers | show |
| Series | [1/2] CI: use parallel build for a faster setup | expand |
Hi Ayoub, > --- /dev/null > +++ b/Dockerfile > @@ -0,0 +1,23 @@ > +FROM ubuntu:jammy [..] > +# Add swupdate user > +RUN useradd -ms /bin/bash swupdate > +RUN echo "swupdate ALL=(ALL) NOPASSWD: ALL" | tee -a /etc/sudoers > +USER swupdate > +WORKDIR /home/swupdate > + > +CMD ["/bin/bash"] I think adding a Dockerfile is good. Yet, I think your proposal has a flaw for non-ephemeral CI or developers who are using the machine: All files created insided the cotainer are owned by a likely unknown or foreign UID outside of the container (on the Docker host). So unless one does "sudo rm" you cannot delete them on the host. This is not good. My solution to this problem is a "fancy" entrypoint which gives the user inside the container the same UID / GID as the owner of the working dir on the host. https://gitlab.com/toertel/docker-image-swupdate-contribute/-/blob/master/entrypoint.sh I recommend going forward with such a solution. Cheers, Mark
Hello Mark, I sent a further patch to integrate Docker with VSCode, The UID/GUID Mapping are then performed automatically. The goal is that a beginner with no Docker background can set up the project very quickly and start building Swupdate without worrying about missing dependencies. Best On Wednesday, April 17, 2024 at 9:11:21 AM UTC+2 Mark Jonas wrote: > Hi Ayoub, > > > --- /dev/null > > +++ b/Dockerfile > > @@ -0,0 +1,23 @@ > > +FROM ubuntu:jammy > > [..] > > > +# Add swupdate user > > +RUN useradd -ms /bin/bash swupdate > > +RUN echo "swupdate ALL=(ALL) NOPASSWD: ALL" | tee -a /etc/sudoers > > +USER swupdate > > +WORKDIR /home/swupdate > > + > > +CMD ["/bin/bash"] > > I think adding a Dockerfile is good. Yet, I think your proposal has a > flaw for non-ephemeral CI or developers who are using the machine: All > files created insided the cotainer are owned by a likely unknown or > foreign UID outside of the container (on the Docker host). So unless > one does "sudo rm" you cannot delete them on the host. This is not > good. > > My solution to this problem is a "fancy" entrypoint which gives the > user inside the container the same UID / GID as the owner of the > working dir on the host. > > > https://gitlab.com/toertel/docker-image-swupdate-contribute/-/blob/master/entrypoint.sh > > I recommend going forward with such a solution. > > Cheers, > Mark >
Hi, If no user is specified in VSCode devcontainer configuration the default one configured in Dockerfile is used, in this case swupdate User. UID/GID is mapped to the host User. Cheers On Fri, Apr 19, 2024, 07:15 Mark Jonas <toertel@gmail.com> wrote: > Hi Ayoub, > > > I sent a further patch to integrate Docker with VSCode, The UID/GUID > Mapping are then performed automatically. > > The goal is that a beginner with no Docker background can set up the > project very quickly and start building Swupdate without worrying about > missing dependencies. > > Yes, I saw that. > > I found the following VSCode documentation about non-root users in > devcontainers. > > https://code.visualstudio.com/remote/advancedcontainers/add-nonroot-user > > I neither see remoteUser nor containerUser used in your setup - or I > am overlooking it. How does it work in your patch? > > Wouldn't it still be desirable for non-VSCode users to get the build > artifacts with the right file ownership? > > Cheers, > Mark > > > On Wednesday, April 17, 2024 at 9:11:21 AM UTC+2 Mark Jonas wrote: > >> > >> Hi Ayoub, > >> > >> > --- /dev/null > >> > +++ b/Dockerfile > >> > @@ -0,0 +1,23 @@ > >> > +FROM ubuntu:jammy > >> > >> [..] > >> > >> > +# Add swupdate user > >> > +RUN useradd -ms /bin/bash swupdate > >> > +RUN echo "swupdate ALL=(ALL) NOPASSWD: ALL" | tee -a /etc/sudoers > >> > +USER swupdate > >> > +WORKDIR /home/swupdate > >> > + > >> > +CMD ["/bin/bash"] > >> > >> I think adding a Dockerfile is good. Yet, I think your proposal has a > >> flaw for non-ephemeral CI or developers who are using the machine: All > >> files created insided the cotainer are owned by a likely unknown or > >> foreign UID outside of the container (on the Docker host). So unless > >> one does "sudo rm" you cannot delete them on the host. This is not > >> good. > >> > >> My solution to this problem is a "fancy" entrypoint which gives the > >> user inside the container the same UID / GID as the owner of the > >> working dir on the host. > >> > >> > https://gitlab.com/toertel/docker-image-swupdate-contribute/-/blob/master/entrypoint.sh > >> > >> I recommend going forward with such a solution. > >> > >> Cheers, > >> Mark > > > > -- > > You received this message because you are subscribed to the Google > Groups "swupdate" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to swupdate+unsubscribe@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/swupdate/e32d2c0f-33b1-4b41-88f4-f99c8bf566e4n%40googlegroups.com > . >
without VSCode, the mapping of user UID/GID is straight forward using -u option e.g something like : cd /path/to/swupdate docker run -ti --rm -v $(pwd):/home/swupdate -u $(id -u):$(id -g) 3635fcf3184e On Fri, Apr 19, 2024 at 3:22 PM Ayoub Zaki <ayoub.zaki@googlemail.com> wrote: > Hi, > > If no user is specified in VSCode devcontainer configuration the default > one configured in Dockerfile is used, in this case swupdate User. > > UID/GID is mapped to the host User. > > Cheers > > On Fri, Apr 19, 2024, 07:15 Mark Jonas <toertel@gmail.com> wrote: > >> Hi Ayoub, >> >> > I sent a further patch to integrate Docker with VSCode, The UID/GUID >> Mapping are then performed automatically. >> > The goal is that a beginner with no Docker background can set up the >> project very quickly and start building Swupdate without worrying about >> missing dependencies. >> >> Yes, I saw that. >> >> I found the following VSCode documentation about non-root users in >> devcontainers. >> >> https://code.visualstudio.com/remote/advancedcontainers/add-nonroot-user >> >> I neither see remoteUser nor containerUser used in your setup - or I >> am overlooking it. How does it work in your patch? >> >> Wouldn't it still be desirable for non-VSCode users to get the build >> artifacts with the right file ownership? >> >> Cheers, >> Mark >> >> > On Wednesday, April 17, 2024 at 9:11:21 AM UTC+2 Mark Jonas wrote: >> >> >> >> Hi Ayoub, >> >> >> >> > --- /dev/null >> >> > +++ b/Dockerfile >> >> > @@ -0,0 +1,23 @@ >> >> > +FROM ubuntu:jammy >> >> >> >> [..] >> >> >> >> > +# Add swupdate user >> >> > +RUN useradd -ms /bin/bash swupdate >> >> > +RUN echo "swupdate ALL=(ALL) NOPASSWD: ALL" | tee -a /etc/sudoers >> >> > +USER swupdate >> >> > +WORKDIR /home/swupdate >> >> > + >> >> > +CMD ["/bin/bash"] >> >> >> >> I think adding a Dockerfile is good. Yet, I think your proposal has a >> >> flaw for non-ephemeral CI or developers who are using the machine: All >> >> files created insided the cotainer are owned by a likely unknown or >> >> foreign UID outside of the container (on the Docker host). So unless >> >> one does "sudo rm" you cannot delete them on the host. This is not >> >> good. >> >> >> >> My solution to this problem is a "fancy" entrypoint which gives the >> >> user inside the container the same UID / GID as the owner of the >> >> working dir on the host. >> >> >> >> >> https://gitlab.com/toertel/docker-image-swupdate-contribute/-/blob/master/entrypoint.sh >> >> >> >> I recommend going forward with such a solution. >> >> >> >> Cheers, >> >> Mark >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "swupdate" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to swupdate+unsubscribe@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/swupdate/e32d2c0f-33b1-4b41-88f4-f99c8bf566e4n%40googlegroups.com >> . >> >
Hi Ayoub, I have difficulties posting to the swupdate mailing list. I am subscribed, still Google considers me as a bulk sender and claims to drop my emails. So most likely only your replies will make it to the list. > without VSCode, the mapping of user UID/GID is straight forward using -u option e.g something like : > > cd /path/to/swupdate > docker run -ti --rm -v $(pwd):/home/swupdate -u $(id -u):$(id -g) 3635fcf3184e In your previous mail I understood that VSCode in the background sets the user and group to the person running VSCode (?). Here, you show that otherwise it needs to be done manually. With my proposal using a clever entrypoint of the Container which sets UID and GID according to the working directory it would be nice and smooth everywhere. I think our arguments are exchanged. Let's see what Stefano wants. > On Fri, Apr 19, 2024 at 3:22 PM Ayoub Zaki <ayoub.zaki@googlemail.com> wrote: >> >> Hi, >> >> If no user is specified in VSCode devcontainer configuration the default one configured in Dockerfile is used, in this case swupdate User. >> >> UID/GID is mapped to the host User. >> >> Cheers >> >> On Fri, Apr 19, 2024, 07:15 Mark Jonas <toertel@gmail.com> wrote: >>> >>> Hi Ayoub, >>> >>> > I sent a further patch to integrate Docker with VSCode, The UID/GUID Mapping are then performed automatically. >>> > The goal is that a beginner with no Docker background can set up the project very quickly and start building Swupdate without worrying about missing dependencies. >>> >>> Yes, I saw that. >>> >>> I found the following VSCode documentation about non-root users in >>> devcontainers. >>> >>> https://code.visualstudio.com/remote/advancedcontainers/add-nonroot-user >>> >>> I neither see remoteUser nor containerUser used in your setup - or I >>> am overlooking it. How does it work in your patch? >>> >>> Wouldn't it still be desirable for non-VSCode users to get the build >>> artifacts with the right file ownership? >>> >>> Cheers, >>> Mark >>> >>> > On Wednesday, April 17, 2024 at 9:11:21 AM UTC+2 Mark Jonas wrote: >>> >> >>> >> Hi Ayoub, >>> >> >>> >> > --- /dev/null >>> >> > +++ b/Dockerfile >>> >> > @@ -0,0 +1,23 @@ >>> >> > +FROM ubuntu:jammy >>> >> >>> >> [..] >>> >> >>> >> > +# Add swupdate user >>> >> > +RUN useradd -ms /bin/bash swupdate >>> >> > +RUN echo "swupdate ALL=(ALL) NOPASSWD: ALL" | tee -a /etc/sudoers >>> >> > +USER swupdate >>> >> > +WORKDIR /home/swupdate >>> >> > + >>> >> > +CMD ["/bin/bash"] >>> >> >>> >> I think adding a Dockerfile is good. Yet, I think your proposal has a >>> >> flaw for non-ephemeral CI or developers who are using the machine: All >>> >> files created insided the cotainer are owned by a likely unknown or >>> >> foreign UID outside of the container (on the Docker host). So unless >>> >> one does "sudo rm" you cannot delete them on the host. This is not >>> >> good. >>> >> >>> >> My solution to this problem is a "fancy" entrypoint which gives the >>> >> user inside the container the same UID / GID as the owner of the >>> >> working dir on the host. >>> >> >>> >> https://gitlab.com/toertel/docker-image-swupdate-contribute/-/blob/master/entrypoint.sh >>> >> >>> >> I recommend going forward with such a solution. >>> >> >>> >> Cheers, >>> >> Mark Cheers, Mark
Hi, On 21.04.24 11:01, Mark Jonas wrote: > Hi Ayoub, > > I have difficulties posting to the swupdate mailing list. I am > subscribed, still Google considers me as a bulk sender and claims to > drop my emails. So most likely only your replies will make it to the > list. > >> without VSCode, the mapping of user UID/GID is straight forward using -u option e.g something like : >> >> cd /path/to/swupdate >> docker run -ti --rm -v $(pwd):/home/swupdate -u $(id -u):$(id -g) 3635fcf3184e > > In your previous mail I understood that VSCode in the background sets > the user and group to the person running VSCode (?). Here, you show > that otherwise it needs to be done manually. > > With my proposal using a clever entrypoint of the Container which sets > UID and GID according to the working directory it would be nice and > smooth everywhere. > > I think our arguments are exchanged. Let's see what Stefano wants. > IMHO it is ok to add support for an editor like VSCode, but docker setup is orthogonal. I would prefer Mark's proposal, so that even no VSCode users have a container without bothering with the parameters to be passed. As goal for this patch is to provide a ready to use container for Docker beginner, this seems to be the best approach. Best regards, Stefano >> On Fri, Apr 19, 2024 at 3:22 PM Ayoub Zaki <ayoub.zaki@googlemail.com> wrote: >>> >>> Hi, >>> >>> If no user is specified in VSCode devcontainer configuration the default one configured in Dockerfile is used, in this case swupdate User. >>> >>> UID/GID is mapped to the host User. >>> >>> Cheers >>> >>> On Fri, Apr 19, 2024, 07:15 Mark Jonas <toertel@gmail.com> wrote: >>>> >>>> Hi Ayoub, >>>> >>>>> I sent a further patch to integrate Docker with VSCode, The UID/GUID Mapping are then performed automatically. >>>>> The goal is that a beginner with no Docker background can set up the project very quickly and start building Swupdate without worrying about missing dependencies. >>>> >>>> Yes, I saw that. >>>> >>>> I found the following VSCode documentation about non-root users in >>>> devcontainers. >>>> >>>> https://code.visualstudio.com/remote/advancedcontainers/add-nonroot-user >>>> >>>> I neither see remoteUser nor containerUser used in your setup - or I >>>> am overlooking it. How does it work in your patch? >>>> >>>> Wouldn't it still be desirable for non-VSCode users to get the build >>>> artifacts with the right file ownership? >>>> >>>> Cheers, >>>> Mark >>>> >>>>> On Wednesday, April 17, 2024 at 9:11:21 AM UTC+2 Mark Jonas wrote: >>>>>> >>>>>> Hi Ayoub, >>>>>> >>>>>>> --- /dev/null >>>>>>> +++ b/Dockerfile >>>>>>> @@ -0,0 +1,23 @@ >>>>>>> +FROM ubuntu:jammy >>>>>> >>>>>> [..] >>>>>> >>>>>>> +# Add swupdate user >>>>>>> +RUN useradd -ms /bin/bash swupdate >>>>>>> +RUN echo "swupdate ALL=(ALL) NOPASSWD: ALL" | tee -a /etc/sudoers >>>>>>> +USER swupdate >>>>>>> +WORKDIR /home/swupdate >>>>>>> + >>>>>>> +CMD ["/bin/bash"] >>>>>> >>>>>> I think adding a Dockerfile is good. Yet, I think your proposal has a >>>>>> flaw for non-ephemeral CI or developers who are using the machine: All >>>>>> files created insided the cotainer are owned by a likely unknown or >>>>>> foreign UID outside of the container (on the Docker host). So unless >>>>>> one does "sudo rm" you cannot delete them on the host. This is not >>>>>> good. >>>>>> >>>>>> My solution to this problem is a "fancy" entrypoint which gives the >>>>>> user inside the container the same UID / GID as the owner of the >>>>>> working dir on the host. >>>>>> >>>>>> https://gitlab.com/toertel/docker-image-swupdate-contribute/-/blob/master/entrypoint.sh >>>>>> >>>>>> I recommend going forward with such a solution. >>>>>> >>>>>> Cheers, >>>>>> Mark > > Cheers, > Mark >
Hi Stefano, the Docker Entrypoint to setup UID/GID is working only if deployed on same machine/user used to build the Dockerfile, so this not a silver bullet even worst since it will have the wrong setup if deployed in different environment. whereas the docker -u is more flexible and do not care where the docker was built. IMHO a Docker beginner should start with VSCode which setup everything correctly without even know he is using docker (Purpose of this Patch after all). Best regards On Wednesday, April 24, 2024 at 12:13:24 AM UTC+2 Stefano Babic wrote: > Hi, > > On 21.04.24 11:01, Mark Jonas wrote: > > Hi Ayoub, > > > > I have difficulties posting to the swupdate mailing list. I am > > subscribed, still Google considers me as a bulk sender and claims to > > drop my emails. So most likely only your replies will make it to the > > list. > > > >> without VSCode, the mapping of user UID/GID is straight forward using > -u option e.g something like : > >> > >> cd /path/to/swupdate > >> docker run -ti --rm -v $(pwd):/home/swupdate -u $(id -u):$(id -g) > 3635fcf3184e > > > > In your previous mail I understood that VSCode in the background sets > > the user and group to the person running VSCode (?). Here, you show > > that otherwise it needs to be done manually. > > > > With my proposal using a clever entrypoint of the Container which sets > > UID and GID according to the working directory it would be nice and > > smooth everywhere. > > > > I think our arguments are exchanged. Let's see what Stefano wants. > > > > IMHO it is ok to add support for an editor like VSCode, but docker setup > is orthogonal. I would prefer Mark's proposal, so that even no VSCode > users have a container without bothering with the parameters to be > passed. As goal for this patch is to provide a ready to use container > for Docker beginner, this seems to be the best approach. > > Best regards, > Stefano > > >> On Fri, Apr 19, 2024 at 3:22 PM Ayoub Zaki <ayoub...@googlemail.com> > wrote: > >>> > >>> Hi, > >>> > >>> If no user is specified in VSCode devcontainer configuration the > default one configured in Dockerfile is used, in this case swupdate User. > >>> > >>> UID/GID is mapped to the host User. > >>> > >>> Cheers > >>> > >>> On Fri, Apr 19, 2024, 07:15 Mark Jonas <toe...@gmail.com> wrote: > >>>> > >>>> Hi Ayoub, > >>>> > >>>>> I sent a further patch to integrate Docker with VSCode, The UID/GUID > Mapping are then performed automatically. > >>>>> The goal is that a beginner with no Docker background can set up the > project very quickly and start building Swupdate without worrying about > missing dependencies. > >>>> > >>>> Yes, I saw that. > >>>> > >>>> I found the following VSCode documentation about non-root users in > >>>> devcontainers. > >>>> > >>>> > https://code.visualstudio.com/remote/advancedcontainers/add-nonroot-user > >>>> > >>>> I neither see remoteUser nor containerUser used in your setup - or I > >>>> am overlooking it. How does it work in your patch? > >>>> > >>>> Wouldn't it still be desirable for non-VSCode users to get the build > >>>> artifacts with the right file ownership? > >>>> > >>>> Cheers, > >>>> Mark > >>>> > >>>>> On Wednesday, April 17, 2024 at 9:11:21 AM UTC+2 Mark Jonas wrote: > >>>>>> > >>>>>> Hi Ayoub, > >>>>>> > >>>>>>> --- /dev/null > >>>>>>> +++ b/Dockerfile > >>>>>>> @@ -0,0 +1,23 @@ > >>>>>>> +FROM ubuntu:jammy > >>>>>> > >>>>>> [..] > >>>>>> > >>>>>>> +# Add swupdate user > >>>>>>> +RUN useradd -ms /bin/bash swupdate > >>>>>>> +RUN echo "swupdate ALL=(ALL) NOPASSWD: ALL" | tee -a /etc/sudoers > >>>>>>> +USER swupdate > >>>>>>> +WORKDIR /home/swupdate > >>>>>>> + > >>>>>>> +CMD ["/bin/bash"] > >>>>>> > >>>>>> I think adding a Dockerfile is good. Yet, I think your proposal has > a > >>>>>> flaw for non-ephemeral CI or developers who are using the machine: > All > >>>>>> files created insided the cotainer are owned by a likely unknown or > >>>>>> foreign UID outside of the container (on the Docker host). So unless > >>>>>> one does "sudo rm" you cannot delete them on the host. This is not > >>>>>> good. > >>>>>> > >>>>>> My solution to this problem is a "fancy" entrypoint which gives the > >>>>>> user inside the container the same UID / GID as the owner of the > >>>>>> working dir on the host. > >>>>>> > >>>>>> > https://gitlab.com/toertel/docker-image-swupdate-contribute/-/blob/master/entrypoint.sh > >>>>>> > >>>>>> I recommend going forward with such a solution. > >>>>>> > >>>>>> Cheers, > >>>>>> Mark > > > > Cheers, > > Mark > > >
diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 0000000..2537da2 --- /dev/null +++ b/Dockerfile @@ -0,0 +1,23 @@ +FROM ubuntu:jammy + +COPY ci/setup.sh /tmp/setup.sh +COPY ci/install-src-deps.sh /tmp/install-src-deps.sh +RUN chmod +x /tmp/setup.sh +RUN chmod +x /tmp/install-src-deps.sh + +RUN /tmp/setup.sh +RUN /tmp/install-src-deps.sh + +# Aditional development tools +RUN apt-get install -y \ + git-core git-man git-email \ + gcc-multilib g++-multilib gdb-multiarch \ + sudo nano vim openssh-client bash-completion + +# Add swupdate user +RUN useradd -ms /bin/bash swupdate +RUN echo "swupdate ALL=(ALL) NOPASSWD: ALL" | tee -a /etc/sudoers +USER swupdate +WORKDIR /home/swupdate + +CMD ["/bin/bash"]
Signed-off-by: Ayoub Zaki <ayoub.zaki@embetrix.com> --- Dockerfile | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Dockerfile