Re-add "Change the generated image to bci-busybox:15.6 (#252)" with additional fixes

[jiaqiluo]

rancher/rancher#46100

This PR includes:

• All changes from Change the generated image to bci-busybox:15.6 #252
• The fix for the permissions issue that causes node driver downloads to fail. issue

More information about the node-driver-downloading issue:

When provisioning an RKE2/K3s node-driver cluster in Rancher, Rancher deploys a Job that runs the rancher-machine container. This container first downloads the external node driver, then invokes the rancher-machine binary to create the VM in the cloud (code). The container runs with a security context configured as runAsUser: 1000 and runAsGroup: 1000. In the original PR, the Job fails to move the downloaded node driver to /usr/local/bin/ due to a permissions issue.

The fix for this issue involves changing the ownership of /usr/local/bin to the machine user (UID 1000). This allows the running container to move the node driver to /usr/local/bin while being unable to modify any existing binaries which are owned by root. Additionally, the security context set on the container ensures that the process runs as a non-root user.

Dev validate

We can use -e CATTLE_MACHINE_PROVISION_IMAGE=$IMAGE in the docker run command to override the rancher-machine image used by the v1 provisioning framework.

The Docker image built from this PR was tested in Rancher by provisioning a node-driver Linode K3s cluster, and the cluster was successfully provisioned.

Below are the pod logs:

Downloading driver from https://<IP>/assets/docker-machine-driver-linode
Doing /etc/rancher/ssl
docker-machine-driver-linode
docker-machine-driver-linode: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
Running pre-create checks...
(aaaa-jiaqi-ta-qbwvq-vrsrl) Generating a secure disposable linode-root-pass...
Creating machine...
(aaaa-jiaqi-ta-qbwvq-vrsrl) Creating Linode machine instance...
(aaaa-jiaqi-ta-qbwvq-vrsrl) Waiting for Machine Running...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with ubuntu(systemd)...
Provisioning with custom install script via SSH, not installing Docker...

[pjbgf]

A few optional changes, otherwise LGTM.

[jiaqiluo]

Hi @pjbgf, I tested your suggested change but encountered the same issue that the PR aims to address. It turns out that while useradd -m -u 1000 machine does create the /home/machine directory, it is not copied to the final stage of the image. The current approach - manually creating the directory and setting its ownership to machine - appears to be the simplest and most straightforward solution. Please let me know what you think.

[jakefhyde]

@jiaqiluo Just wanted to confirm before you merge, the issues we noticed around not being able to provision are no longer seen, correct? I see that you tested with Linode, could you also confirm that CI works if you run a make provisioning-tests locally from rancher?

[jiaqiluo]

Hi @jakefhyde, could you explain how the rancher-machine is being used in the provisioning test suites? To perform the tests you suggested, do I need to build a rancher-machine Docker image from this PR and use it in rancher/rancher?

[jakefhyde]

Hi @jakefhyde, could you explain how the rancher-machine is being used in the provisioning test suites? To perform the tests you suggested, do I need to build a rancher-machine Docker image from this PR and use it in rancher/rancher?

Yes exactly. Rancher CI uses whatever version of machine is configured in dapper, which is currently v0.15.0-rancher122. I would build a machine image, and then test with that, pointing dapper to use your version and run make provisioning-tests.

[jiaqiluo]

Using a custom Docker image built from this PR branch in rancher/rancher to run the provisioning tests, all tests passed successfully (link), confirming that the PR resolves the issue encountered with the initial fix attempt.