[PATCH 2/2] Add Dockerfile to ease setup of the SWUpdate project, build, debug and send patches

[Ayoub Zaki]

Signed-off-by: Ayoub Zaki <ayoub...@embetrix.com>
---
Dockerfile | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Dockerfile

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"]
--
2.34.1

[Mark Jonas]

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

[ayoub...@googlemail.com]

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

[Ayoub Zaki]

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

> --
> 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+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/swupdate/e32d2c0f-33b1-4b41-88f4-f99c8bf566e4n%40googlegroups.com.

[Ayoub Zaki]

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

[Mark Jonas]

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.

Cheers,
Mark

[Stefano Babic]

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

[ayoub...@googlemail.com]

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