Closes #614 by creating a FORCE_USER_CREATION flag to be set in config

[gromain]

This deactivates the export-image/01-user-rename/01-run.sh script when the DISABLE_FIRST_BOOT_USER_RENAME flag is set to 1.
Closes #614.

[XECDesign]

FIRST_USER_NAME is not unset by default and gets created in either case.

DISABLE_USER_RENAME might be a better name than FORCE_USER_CREATION

DISABLE_USER_RENAME should default to 0 and the test should check whether it's "1".

Since DISABLE_USER_RENAME makes no sense without FIRST_USER_PASS and vice-vera, it should probably error out at the start with an appropriate message that the options should be combined together and a warning about the system being open to hackers.

[gromain]

FIRST_USER_NAME is not unset by default and gets created in either case.

I wanted to document the fact that FIRST_USER_NAME only exists during the image creation. Once the image is created, this user is "replaced" during the first boot (when the user is renamed). So from the user and image creator point of view, this user never exists in the image (if not "forced" or not renamed) and thus by default, is unset. This was the root of my previous comments on FIRST_USER_NAME and FIRST_USER_PASS being useless in the config if there is no way to "force" their existence.

DISABLE_USER_RENAME might be a better name than FORCE_USER_CREATION

I changed the name because I felt FORCE_USER_CREATION represent more faithfully what's happening from the image creator point of view.

DISABLE_USER_RENAME rest on the fact that we assume that the image creator has the knowledge that the user is renamed at some point in the image creation (which is not documented properly for now). This is different from the behavior of other distribution creation tools (see Buildroot and Yocto). In those, when a username and a password are configured, they directly appear in the final image without the need for an extra configuration step (those tools don't even create another user than root - with no password so possible connection - if not explicitly told to do so). The user being for to be renamed on first boot is definitely not something standard in the industry and this is why I wanted to insist on this.

Maybe something like KEEP_DEFAULT_USER instead of FORCE_USER_CREATION would be even better?

DISABLE_USER_RENAME should default to 0 and the test should check whether it's "1".

Since DISABLE_USER_RENAME makes no sense without FIRST_USER_PASS and vice-vera, it should probably error out at the start with an appropriate message that the options should be combined together and a warning about the system being open to hackers.

Both requests makes sense to me. I was wondering about forcing a check to make sure FIRST_USER_NAME and FIRST_USER_PASS are set, so this confirms the behavior. I'll change that.

Should it also enforce FIRST_USER_NAME to be something else than pi? This would force users to choose a different base username (and think about the risks associated with this).

[XECDesign]

Should it also enforce FIRST_USER_NAME to be something else than pi? This would force users to choose a different base username (and think about the risks associated with this).

I think it's fine to allow pi as a default username.

DISABLE_USER_RENAME rest on the fact that we assume that the image creator has the knowledge that the user is renamed at some point in the image creation (which is not documented properly for now).

I think the documentation and variable names should reflect what's actually happening. Trying to reframe it as something else, just makes it harder to understand the underlying mechanism.

[gromain]

OK, I'll update the documentation too to show this in a more complete way.

What about DISABLE_FIRST_BOOT_USER_RENAME as name then? It's a bit long, but I feel it's quite self-explanatory on what exactly is going to be deactivated and when this happens (the rename happens during the first boot, not during the image build).

[XECDesign]

Yeah, makes sense.

[sailoog]

Hi @XECDesign,

Will this be added to the arm64 branch?