Bug 2072196

Summary: The root_password of the deployed systems remains same as the VM template when using Image Based Deployment on VMware via Red Hat Satellite 6
Product: Red Hat Satellite Reporter: Sayan Das <saydas>
Component: Provisioning TemplatesAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED MIGRATED QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.10.0CC: lstejska, mhulan, sganar
Target Milestone: UnspecifiedKeywords: MigratedToJIRA, Triaged
Target Release: Unused   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-06-06 12:20:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sayan Das 2022-04-05 18:52:28 UTC
Description of problem:

The root_password of the deployed systems remains same as the VM template when using Image Based Deployment on VMware via Red Hat Satellite 6. 

The root password being defined at HostGroup\Host\Satellite settings are not at all used\honored in this specific build process. 


Version-Release number of selected component (if applicable):

Satellite 6.10  [ Satellite 6.9 and 6.8 and 7.0\6.11 as well ]


How reproducible:

Always

Steps to Reproduce:
1. Create a VM, set "password@123" as its root password, and do the necessary steps to configure it as a VM template that can be used to deploy VMs. 

   Follow the "Preparing an Image to use the cloud-init Template" segment from https://access.redhat.com/documentation/en-us/red_hat_satellite/6.10/html-single/provisioning_guide/index#Provisioning_Virtual_Machines_in_VMware_vSphere-Provisioning_with_cloudinit_and_userdata_templates .

2. Import the same VM template as an USerdata enabled Image inside the Vmware compute resource of satellite and mention the password "password@123" during the same as well.

3. Now once the satellite is configured to deploy systems on Vmware as per the doc, Deploy a system using the Image-Based method by selecting the same Userdata enabled Image but On the "Operating Systems" tab mention the "Root Password *" as "Planetearth@123" and then submit the build.



Actual results:

Once the system build gets completed, The SSH to the root user of the system will only be happening via "password@123" password which is the password set in the OS template of VMWare.


Expected results:

As part of the system build process, The "Planetearth@123" password should be updated as the root password instead which was defined in the Operating Systems tab. 


Additional info:

When i look into "Cloudinit default" or "UserData open-vm-tools" templates in Satellite UI, I see no code or snippet present that handles the root password change. 

Our documentation also does not says, that users should not expect to see a change of root password, instead, they should use the root password of the template itself. 

So based on these facts, I think the "Cloudinit default" should be updated to handle the root password modification as per the end-user's choice. 

A viable workaround would be to have the following lines added just before the phone_home section at the end, after cloning the "Cloudinit default" template. 


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



So it will look something like:



<% if @host.provision_method == 'image' && @host.root_pass.present? -%>
- |
  echo 'root:<%= @host.root_pass -%>' | /usr/sbin/chpasswd -e
<% end -%>
phone_home:
  url: <%= foreman_url('built') %>
  post: []
  tries: 10



And needless to say that this new template should be associated with the right OS and selected as the Cloud-Init template to use during build as well.

Comment 2 Brad Buckingham 2023-10-04 21:43:14 UTC
Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Comment 4 Brad Buckingham 2023-11-02 17:01:35 UTC
Based upon feedback during auto-closure, leaving this bugzilla open a while longer for additional investigation; however, it may be closed in a future iteration.

Comment 5 Eric Helms 2024-06-06 12:20:53 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.