Fixes #37901 - Set root password through Cloudinit deployments

[sayan3296]

When deploying a system via Cloud-init and Userdata, in VMware, the root password set on the deployed system is the same as the root password of the VM template.

Say,

• Root password in VM template is password@123
• When creating the system, I mentioned my root password as qwerty@123 and then submitted the system build.
• Once the system comes up, It will still have the root password set as password@123 but NOT what we expected it to be i.e. qwerty@123

We do change it for other types of deployments i.e. via templates Kickstart Default Finish or Kickstart Default Userdata but not for Cloudinit default e.g.

# grep root_pass app/views/unattended/provisioning_templates/user_data/kickstart_default_user_data.erb -B3 -A1

<%# Cloud instances frequently have incorrect hosts data %>
<%= snippet 'fix_hosts' %>

<% if @host.provision_method == 'image' && root_pass.present? -%>
# Install the root password
echo 'root:<%= root_pass -%>' | /usr/sbin/chpasswd -e
<% end -%>

The same method can be applied for Cloudinit as well

[sayan3296]

Could someone suggest \ help fix the template snapshots issue? I am guessing that some tests are failing due to the same or i can ignore it?

[sayan3296]

Could someone suggest \ help fix the template snapshots issue? I am guessing that some tests are failing due to the same or i can ignore it?

I managed to find out how to do it after checking with one of the developers.

[sayan3296]

Hello @ShimShtein @stejskalleos , Please review and let me know if any concerns

[sayan3296]

With recent changes pushed w.r.t the request done by @ekohl, I had regenerated the snapshots as well, but after adding and amending everything to the existing commit, I don't see any snapshots are added to the commit.

It is probably because earlier an extra -| was getting generated which created a diff but now that does not happen as it relies on the if statement. So the existing content and generated content remains the same.

Please re-review

[ShimShtein]

@sayan3296, can we use the standard chpasswd key, like it is described here: https://cloudinit.readthedocs.io/en/latest/reference/modules.html#set-passwords ?

[sayan3296]

@sayan3296, can we use the standard chpasswd key, like it is described here: https://cloudinit.readthedocs.io/en/latest/reference/modules.html#set-passwords ?

I can try and let you know. But when relying on cloud-init itself and using chpasswd in that template, Do you know if cloud-init will by default honor it or if we will need to declare any relevant module under the specific section of /etc/cloud/cloud.cfg of VM template as well for chpasswd to work ?

[sayan3296]

@sayan3296, can we use the standard chpasswd key, like it is described here: https://cloudinit.readthedocs.io/en/latest/reference/modules.html#set-passwords ?

I can try and let you know. But when relying on cloud-init itself and using chpasswd in that template, Do you know if cloud-init will by default honor it or if we will need to declare any relevant module under the specific section of /etc/cloud/cloud.cfg of VM template as well for chpasswd to work ?

Ok.. So perhaps i know the answer i.e. In the VM template, we would need set_passwords to be declared inside cloud_config_modules part of cloud.cfg .. But none of our existing documentation even suggested doing so, which means, the existing VM template were created without the set_passwords key in cloud.cfg and those users may be impacted and would need to redo their templates, once we use the chpasswd key ..

Let me know @ShimShtein if we still want to do this and then I can test it out. This is the Sat 6.15 doc for your reference of cloud.cfg config file in VM templates.

[sayan3296]

I tested on RHEL 8.10 and 9.4 and can confirm what I said in my comment above i.e. #10343 (comment)
It works provided that I am willing to modify my cloud.cfg on VM template to include set-passwords under cloud_config_modules section ..

Let me know if you want me to push those changes. The concerned part looks something like this i.e.

#cloud-config
hostname: <%= @host.name %>
fqdn: <%= @host %>
manage_etc_hosts: true
users: {}
<% if @host.provision_method == 'image' && root_pass.present? -%>
chpasswd:
  expire: False
  users:
  - {name: root, password: <%= root_pass -%>}
<% end -%>

runcmd:

[ekohl]

• {name: root, password: <%= root_pass -%>}

I'd quote password.

Looking at our docs, we mention cloud.cfg here twice. Once for oVirt and once for VMware. I wonder why they're so different. I think oVirt instructions on changing cloud.cfg are probably sufficient for VMware as well and simplify things.

I also thought we set up the user data as a VMware datasource, but I don't see that in our docs.

Perhaps out of scope here, but if we're reviewing the whole feature I think we should look at it.

[sayan3296]

If you take a look at the Example tab of https://cloudinit.readthedocs.io/en/latest/reference/modules.html#set-passwords , It does not require or suggest the quoting here.

I also thought we set up the user data as a VMware datasource, but I don't see that in our docs.

I might be misunderstanding here but We do use UserData open-vm-tools template to setup the Userdata information.

And as far as the DataSource is concerned, we have always used the NoCloud datasource, since the beginning because of the way cloud-init is configured and calls for the /userdata/ endpoint to get the data.

If we should re-review the whole thing, then perhaps we can try to conclude the root password part here and then separately brainstorm about the current workflow and what improvement can be done there.

[sayan3296]

hello @ShimShtein , I have tested using the chpasswd module of cloud-init and pushed the changes here accordingly.

The only requirement is to have the RedHat doc updated i.e. the step where we suggest a configuration for /etc/cloud/cloud.cfg file, we need to make sure that the cloud_config_modules part looks like this

cloud_config_modules:
 - set_passwords
 - runcmd

[ShimShtein]

@ekohl what do you think about it? IMHO it's an OK solution, and the price of an extra module is worth the standardization of the template.