image build fails when localEnv:USER is nil

[behrica]

First tme I used teh tmaplte I had a failing build of the image, due to localEnv:USER not set

https://github.com/scicloj/devcontainer-templates/blob/46b290418a7349bb4f83ed2bde619be148d7c6da/src/basecloj/.devcontainer/devcontainer.json#L9

[Netz00]

I had to remove the following lines from devcontainer.json to resolve the issue.

        "args": {
            "BASE_IMAGE": "${templateOption:imageTag}",
            "USERNAME": "${localEnv:USER}"
        }

[behrica]

Thanks for reporting

@marcitqualab I was never sure, whats the best approach for a generic setting of the container user is.

In my own devcontainer files, I did not touch it or tried to match it with the current user of the host. So it ended often being "vscode", the kind of default for most (all ?) devcontainer base images

[behrica]

I think we could write: ${localEnv:USER:VSCODE}

to make it default to VSCODE. @Netz00 , could you please try this for your case .

[Netz00]

Now it also works, and the user inside the container is VSCODE.

        "args": {
            "USERNAME": "${localEnv:USER:VSCODE}"
        }

I'm not sure why all these options and additional args are used for the configuration, but great job!

[marcitqualab]

First tme I used teh tmaplte I had a failing build of the image, due to localEnv:USER not set

https://github.com/scicloj/devcontainer-templates/blob/46b290418a7349bb4f83ed2bde619be148d7c6da/src/basecloj/.devcontainer/devcontainer.json#L9

Sorry I did not get notified about this issue until yesterday.

This is strange as the USERNAME is just an argument with default value as "vscode" is the docker file. https://github.com/scicloj/devcontainer-templates/blob/46b290418a7349bb4f83ed2bde619be148d7c6da/src/basecloj/.devcontainer/Dockerfile#L4 If you can provide more details of the error I might take a look.

[marcitqualab]

Sorry I did not get notified about this issue until yesterday.

Sorry I did not get notified about this issue until yesterday.

Those lines are just optional as the docker file has default values for those arguments. The localEnv:USER should get the USER var env of the host machine. I think that the USER var env is generally available to all main linux distros. The line ""BASE_IMAGE": "${templateOption:imageTag}"," is there in case the user selects another base image while using the dev container wizard, at least in VScode. I am not sure how removing those lines will actually fix anything. If you can post some error logs I might be able to take a look.

[marcitqualab]

Thanks for reporting

@marcitqualab I was never sure, whats the best approach for a generic setting of the container user is.

In my own devcontainer files, I did not touch it or tried to match it with the current user of the host. So it ended often being "vscode", the kind of default for most (all ?) devcontainer base images

The main point to run de dev container with your user home is to avoid permission issues. If the container runs as root or as another user the files created inside the container will not have the same user, owner and permissions as the user on the host machine. Therefore, you might get some issues while working. While using vscode as user name is just a default, and might not be major issues if the host machine user has another name. By default the docker file uses the user 'vscode', but the important thing is the user id that is set to the default '1000' like the default user on ubuntu. The base images used in this template come with a default non root user with id 1000. If the user with id 1000 does not exists in the docker image, then the only way that I have found so far is to create a new user in the docker file with the same user id as the user in the host machine. In summary, to avoid permission problems, the username is quite optional, but the user id needs to be the same in the host machine user an in the container user.

[marcitqualab]

Now it also works, and the user inside the container is VSCODE.

        "args": {
            "USERNAME": "${localEnv:USER:VSCODE}"
        }

I'm not sure why all these options and additional args are used for the configuration, but great job!

The docker file has already a 'vscode' value for the user name if the arg username is not provided. https://github.com/scicloj/devcontainer-templates/blob/46b290418a7349bb4f83ed2bde619be148d7c6da/src/basecloj/.devcontainer/Dockerfile#L4 I am not sure why or how this extra default value would help, but I would be interested to learn more about the issues that you get. Please share more log traces or fork this repo and share the link with us so we can reproduce the issues. Also provide more information about the host OS and your user name and id.

[Netz00]

I was using Windows 10, which is why I removed it initially to make it work and ended up with the user from the Dockerfile, as expected: vscode. The extra value in ${localEnv:USER:VSCODE} is a nice hack to support both OS.

${localEnv:USER:VSCODE} retrieves the USER environment variable, and if the USER environment variable is not set or available, it falls back to VSCODE instead of returning undefined

If you'd like, I can share the log traces, but I think it's resolved now.

[behrica]

I am aware of the initial Issue of Docker and user ids /permissions. But I was under the impression devcontainer solved it largely by default. It does some magic itself. But probably not in all cases.

Marc Andreu @.***> schrieb am Di., 10. Sept. 2024, 16:17:

Thanks for reporting

@marcitqualab https://github.com/marcitqualab I was never sure, whats the best approach for a generic setting of the container user is.

In my own devcontainer files, I did not touch it or tried to match it with the current user of the host. So it ended often being "vscode", the kind of default for most (all ?) devcontainer base images

The main point to run de dev container with your user home is to avoid permission issues. If the container runs as root or as another user the files created inside the container will not have the same user, owner and permissions as the user on the host machine. Therefore, you might get some issues while working. By default the docker file uses the user 'vscode', but the important thing is the user id that is set to the default '1000' like the default user on ubuntu. If you have permissions problems you might need to sync the user name and user id with your host user.

— Reply to this email directly, view it on GitHub https://github.com/scicloj/devcontainer-templates/issues/27#issuecomment-2340960429, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA7DAJCEFMXT7FWVETEDC3ZV35ONAVCNFSM6AAAAABJXUI4OSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBQHE3DANBSHE . You are receiving this because you authored the thread.Message ID: @.***>

[Netz00]

This commit should patch the Windows issue. The log traces show that the build failed after the following command tried to execute with an empty string value for the $USERNAME variable. https://github.com/scicloj/devcontainer-templates/blob/54b42e7c933092d1e20303a6ace74df2005c3336/src/basecloj/.devcontainer/Dockerfile#L9

Log trace

``` [2024-09-10T19:34:33.451Z] [+] Building 1.7s (10/18) docker:desktop-linux => [internal] load build definition from Dockerfile-with-features 0.0s => => transferring dockerfile: 2.87kB 0.0s => resolve image config for docker-image://docker.io/docker/dockerfile:1 1.1s => [auth] docker/dockerfile:pull token for registry-1.docker.io 0.0s => CACHED docker-image://docker.io/docker/dockerfile:1.4@sha256:9ba7531b 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/clojure:temurin-21-too 0.0s => [context dev_containers_feature_content_source] load .dockerignore 0.0s => => transferring dev_containers_feature_content_source: 2B 0.0s => CACHED [dev_container_auto_added_stage_label 1/4] FROM docker.io/libr 0.0s => [context dev_containers_feature_content_source] load from client 0.0s => => transferring dev_containers_feature_content_source: 22.91kB 0.0s => ERROR [dev_container_auto_added_stage_label 2/4] RUN groupadd --gid 1 0.3s ------ > [dev_container_auto_added_stage_label 2/4] RUN groupadd --gid 1000 && us eradd --uid 1000 --gid 1000 -m && apt-get update && apt-get install -y sudo && echo ALL=(root) NOPASSWD:ALL > /etc/sudoers.d/ && chmod 0440 /e tc/sudoers.d/: 0.248 Usage: groupadd [options] GROUP 0.248 0.248 Options: 0.248 -f, --force exit successfully if the group already exi sts, 0.248 and cancel -g if the GID is already used 0.248 -g, --gid GID use GID for the new group 0.248 -h, --help display this help message and exit 0.248 -K, --key KEY=VALUE override /etc/login.defs defaults 0.248 -o, --non-unique allow to create groups with duplicate [2024-09-10T19:34:33.480Z] 0.248 (non-unique) GID 0.248 -p, --password PASSWORD use this encrypted password for the new gr oup 0.248 -r, --system create a system account 0.248 -R, --root CHROOT_DIR directory to chroot into 0.248 -P, --prefix PREFIX_DIR directory prefix 0.248 --extrausers Use the extra users database 0.248 ------ Dockerfile-with-features:11 -------------------- 10 | # Create the user 11 | >>> RUN groupadd --gid $USER_GID $USERNAME \ 12 | >>> && useradd --uid $USER_UID --gid $USER_GID -m $USERNAME \ 13 | >>> # 14 | >>> # [Optional] Add sudo support. Omit if you don't need to install software after connecting. 15 | >>> && apt-get update \ 16 | >>> && apt-get install -y sudo \ 17 | >>> && echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USE RNAME \ 18 | >>> && chmod 0440 /etc/sudoers.d/$USERNAME 19 | -------------------- ERROR: failed to solve: process "/bin/sh -c groupadd --gid $USER_GID $USERNAME && useradd --uid $USER_UID --gid $USER_GID -m $USERNAME && apt-get update && apt-get install -y sudo && echo $USERNAME ALL=\\(root\\) NOPASSWD:AL L > /etc/sudoers.d/$USERNAME && chmod 0440 /etc/sudoers.d/$USERNAME" did not complete successfully: exit code: 2 ```

[marcitqualab]

Netz00/devcontainer-templates

Yes the commit looks ok, and I think that you need to create a PR against the scicloj repository so that the change could be merged to the main branch.