fix(raspberry-pi-os): Fix user creation to allow for a preseeded user

[paulober]

Proposed Commit Message

fix(raspberry-pi-os): Fix user creation to allow for a preseeded user

Updates user creation on rpios to support renaming existing users
for the first user to create and after that default to GNU tools.

Additional Context

Test Steps

Updated the unit-tests to cover the changes.

Merge type

• [x] Squash merge using "Proposed Commit Message"
• [ ] Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)

@tdewey-rpi

[dermotbradley]

Updates user creation on rpios to support renaming existing users for the first user to create and after that default to GNU tools.

I'm a little confused as to exactly what this is trying to achieve.

The current cloud-init default configuration for RPI defines a default user "pi" for cloud-init to create: https://github.com/canonical/cloud-init/blob/main/config/cloud.cfg.tmpl#L29

If someone wants a differently named user to be created by cloud-init then there are different existing ways to achieve this, depending on "who" wants to change it - (a) RPIOS themselves (i.e you) can simple changed the above mentioned definition in cloud.cfg.tmpl from "pi" to something else; (b) someone creating specific RPI disk images could add/modify vendor-data in their disk image to specify an alternative user to be created without also specifying "- default" in the "users:" section and so only the new user would be created; or (c) the person deploying a RPIOS disk image could specify an alternative user to be created without also specifying "- default" in the "users:" section of the supplied user-data.

However looking at your PR I'm guessing that you rather want to rename an existing "pi" user that RPIOS itself already comes with. Looking at this PR I'm confused, it appears that when add_user() is called that it wants to rename whichever pre-existing username has UID 1000 to the new (cloud-init default) username passed to add_user(). However if someone supplies user-data that defines one (or more) users to be created but does not specify that the default cloud-init user should be created then a pre-existing username with UID 1000 will be renamed to whatever the name of the 1st username is specified in the user-data (rather than the "pi" cloud-init default).

[paulober]

@dermotbradley We need a preseeded user in the image and cloud-init currently doesn't support renaming existing users. This is a workaround we'll apply downstream and it would be great to also have that upstream.

This allows us to keep the preinstalled user for the image and keep the dependency on cloud-init low.

[github-actions[bot]]

Hello! Thank you for this proposed change to cloud-init. This pull request is now marked as stale as it has not seen any activity in 14 days. If no activity occurs within the next 7 days, this pull request will automatically close.

If you are waiting for code review and you are seeing this message, apologies! Please reply, tagging blackboxsw, and he will ensure that someone takes a look soon.

(If the pull request is closed and you would like to continue working on it, please do tag blackboxsw to reopen it.)

[paulober]

Hello! Thank you for this proposed change to cloud-init. This pull request is now marked as stale as it has not seen any activity in 14 days. If no activity occurs within the next 7 days, this pull request will automatically close.

If you are waiting for code review and you are seeing this message, apologies! Please reply, tagging blackboxsw, and he will ensure that someone takes a look soon.

(If the pull request is closed and you would like to continue working on it, please do tag blackboxsw to reopen it.)

@blackboxsw

[paulober]

Thanks for this proposal @paulober. I included some questions inline.

Also, currently cloud-init's userdata defines a set of actions to take not necessarily and end state to achieve. Notice that there are two hostname modules, for example.

This proposal changes the semantics of the expected behavior significantly - so documentation about users being added will be incorrect, even if that is the expected user interface for users to use.

@blackboxsw

Previously, I had proposed a separate key and module for creating a user on RPi OS, but that approach wasn’t accepted. The current approach is simpler for users and has the benefit of allowing userdata to be transferred from one cloud-init instance to another (including RPi OS) without modification.

I understand that overriding behavior in the distro class is not how most other users are created, but from the RPi OS user’s perspective, this aligns with the experience they had before cloud-init was introduced.

[paulober]

@blackboxsw

[paulober]

Hello! Thank you for this proposed change to cloud-init. This pull request is now marked as stale as it has not seen any activity in 14 days. If no activity occurs within the next 7 days, this pull request will automatically close.

If you are waiting for code review and you are seeing this message, apologies! Please reply, tagging blackboxsw, and he will ensure that someone takes a look soon.

(If the pull request is closed and you would like to continue working on it, please do tag blackboxsw to reopen it.)

@blackboxsw

[paulober]

@blackboxsw Please unmark as stale. These changes are required for the upstream cloud-init to be able to correctly create users on Raspberry Pi OS again and it's already deployed in the current images without issues.