[RFE] warn when creating RHEL for Edge Installer image reusing existing blueprint

[miabbott]

When a user follows the workflow to create a RHEL for Edge Installer image, it is easy to end up with a non-working ISO by reusing the same blueprint.

Given the following blueprint:

name = "first-time-user"
description = ""
version = "0.0.0"
packages = []
modules = []
groups = []
distro = ""

[customizations]

[[customizations.user]]
name = "core"
password = "<hashed password>"
key = "ssh-rsa AAA....
groups = ["wheel"]

If I create an ostree commit with that blueprint, then create the installer ISO with the same blueprint, the installation will fail with the following message from Anaconda: dasbus.error.DBusError: set_user_ssh_key: user core does not exist

This is incredibly frustrating as an end user because the blueprint contains customizations that define a user and so my expectation is that the user does exist.

I feel like there is some room for improvement here because the limitation about reusing the same blueprint is not obvious.

Perhaps this is something that could be done on the web UI and harder to do from the CLI, but it seems worth exploring.

[achilleas-k]

My recommendation would be to block user creation in ostree commits completely. It's generally not a good idea to bake users into ostree commits since they can never be removed or modified. Also, there seems to be an issue more recently that breaks authentication for users defined in the base commit, but I haven't had time to look into it.

[miabbott]

My recommendation would be to block user creation in ostree commits completely.

That seems to be a reasonable compromise to me.

As noted in Slack, the trade-off then becomes that the end user has to remember to add a user customization as part of the install image blueprint. Otherwise you have to configure the user interactively via Anaconda.

[ondrejbudai]

I wonder what's the correct solution:

1. Make a user in a commit a hard error - basically don't accept such a request.
2. Keep the behavior as it is, add a warning to the clients that this is something strongly discouraged.

@runcom any ideas?

[teg]

I wonder what's the correct solution:

1. Make a user in a commit a hard error - basically don't accept such a request.
2. Keep the behavior as it is, add a warning to the clients that this is something strongly discouraged.

@runcom any ideas?

I think the only reason we didn't do 1 so far was for backwards compatibility.

cc @gicmo

[ondrejbudai]

That's my gut feeling. On the other hand, removing stuff that's basically broken doesn't sound that bad.

[runcom]

My recommendation would be to block user creation in ostree commits completely.

agreed on this in general

Keep the behavior as it is, add a warning to the clients that this is something strongly discouraged.

I'd start with a release with this - then at the next just drop support so everybody is aware of the breaking change - also, since we have FDO and soon-ignition, adding a user for simplified installer is also possible so this is just a sane exercise of deprecating something