Bug 1251867

Summary: Failed to reset the initial password after RHEV-H automatic installation
Product: Red Hat Enterprise Virtualization Manager Reporter: Chaofeng Wu <cwu>
Component: ovirt-nodeAssignee: Fabian Deutsch <fdeutsch>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 3.5.4CC: adahms, cshao, dougsland, ecohen, fdeutsch, gklein, huiwa, huzhao, lbopf, lsurette, mgoldboi, yaniwang, ycui
Target Milestone: ovirt-3.5.6   
Target Release: 3.5.6   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: node
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-07 14:09:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Node RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
sosreport none

Description Chaofeng Wu 2015-08-10 07:52:10 UTC
Created attachment 1060961 [details]
sosreport

Description of problem:
After RHEV-H automatic installation, reset the initial password successful with new password, then reboot the system. The new password does not work, RHEV-H still ask the initial password.


Version-Release number of selected component (if applicable):
rhev-hypervisor6-6.7-20150804.0.iso


How reproducible:
100%


Steps to Reproduce:
1. PXE install rhev-hypervisor6-6.7-20150804.0.iso with arguments:
management_server=192.168.20.134 ip=192.168.20.173 hostname=node1.node.com gateway=192.168.20.2 netmask=255.255.255.0 BOOTIF=eth0 adminpw=OKr05SbCu3D3g storage_init=/dev/sda reinstall ssh_pwauth=1
2. After the system install successful, approve the system on RHEV-M and the system status is up.
3. Input the initial UNIX password and set the new password successful, and login the TUI successful, reboot the system.
4. In the login session, input the new password, then fail to login the TUI, input the initial UNIX password, RHEV-H ask you to reset the password again.


Actual results:
In step4, fail to login the TUI with the new password. Input the initial password, RHEV-H ask you to set the password again.


Expected results:
In step4, can login with the new password


Additional info:
It seem that new password write into /etc/shadow files, but does not persist and copy to /config/etc/shadow. After the system boot up the /config/etc/shadow does not bind mount to /etc/shadow. Find the details:
[root@node1 admin]# cat /etc/shadow
tcpdump:!!:16651::::::
admin:$6$J7ZU2lUT$6spGeDu5B435HhBSjXhkn9BE.3YIs5sZfk6bgUOWujYcJBp/QpnXPdUYqYwJGc9CNM6EZOiVIYHm9Q8G6x5wO0:16654:0:99999:7:::

[root@node1 admin]# ls -Z /etc/shadow
----------. root root system_u:object_r:shadow_t:s0    /etc/shadow

[root@node1 admin]# cat /config/etc/shadow
tcpdump:!!:16651::::::
admin:OKr05SbCu3D3g:0:0:99999:7:::

[root@node1 admin]# ls -Z /config/etc/shadow
----------. root root system_u:object_r:shadow_t:s0    /config/etc/shadow

[root@node1 admin]# cat /config/files | grep shadow
/etc/shadow

[root@node1 admin]# cat /proc/self/mountinfo | grep shadow   # output nothing

[root@node1 admin]# cat /proc/self/mountinfo | grep passwd
86 47 253:2 /etc/libvirt/passwd.db /etc/libvirt/passwd.db rw,noatime - ext4 /dev/mapper/HostVG-Config rw,seclabel,barrier=1,data=ordere

Comment 1 Douglas Schilling Landgraf 2015-08-11 01:23:27 UTC
Reproduced the report, investigating.

Comment 4 Chaofeng Wu 2015-08-28 08:54:30 UTC
If consumers want to changed the password for admin, here is a workaround:
Consumers need login RHEV-H and change password in "Security" TUI.

Hi Fabian,

I think we need add the doc to log this issue and provide the workaround to the consumers, if we do not fix this issue in this phase.

Comment 6 Fabian Deutsch 2015-09-17 14:04:15 UTC
This is a regression of bug 1246117

Comment 7 Fabian Deutsch 2015-10-07 14:09:17 UTC

*** This bug has been marked as a duplicate of bug 1246117 ***

Comment 8 Huijuan Zhao 2015-12-17 06:13:15 UTC
This issue still exists on the latest rhevh 3.5.z el6 and el7 build RHEV-H 7.2-20151129.1.el7ev (7.2 for 3.5.6 GA).

Test version:
RHEV-H 7.2-20151129.1.el7ev (7.2 for 3.5.6 GA)

Test Steps:
1. PXE install RHEV-H 7.2-20151129.1.el7ev with arguments:
management_server=10.66.107.27 BOOTIF=em1 adminpw=OKr05SbCu3D3g storage_init=/dev/sda reinstall ssh_pwauth=1
2. After the system install successful, input the initial UNIX password and set the new password successful, and login the TUI successful.
3. Approve the system on RHEV-M and the system status is up.
4. Reboot the system.
5. In the login session, input the new password, then fail to login the TUI, input the initial UNIX password, RHEV-H ask you to reset the password again.


Actual results:
In step5, fail to login the TUI with the new password. Input the initial password, RHEV-H ask you to set the password again.


Expected results:
In step5, can login with the new password


So this issue is not fix in RHEV-H 7.2-20151129.1.el7ev.

Fabian, did you missed some patches backport to 3.5.z?

Comment 9 Fabian Deutsch 2015-12-17 07:26:21 UTC
No, I am not aware that any patch was missed. Maybe it is a new issue related to what we also see in bug 1263648.

Does this bug also exist on the 3.6 builds?

Comment 10 Huijuan Zhao 2015-12-17 07:36:44 UTC
Fabian, no such issue on the 3.6 build RHEV-H 7.2-20151210.1.el7ev

Comment 11 Ying Cui 2015-12-17 09:17:56 UTC
(In reply to Fabian Deutsch from comment #9)
> No, I am not aware that any patch was missed. Maybe it is a new issue
> related to what we also see in bug 1263648.

Fabian, https://gerrit.ovirt.org/#/c/46186/ 
do we need this patch into 3.5.z?

Comment 12 Fabian Deutsch 2015-12-17 09:38:45 UTC
Well, yes and no, there is this and another patch related to this change (changing the persistence).

The patches are touching a fundamental parts of Node (persistence), there were no urgent needs to pick such an risky change into 3.5.z, thus they were not picked.

Comment 13 Ying Cui 2015-12-17 09:58:54 UTC
Fabian, we still encountered this issue on 3.5.z, we need to reopen or new one bug on 3.5.z to trace this issue getting fix. thanks.

Comment 14 Fabian Deutsch 2015-12-17 10:39:23 UTC
As said, it's a risky patch (even that it now got tested in 3.6), I would not pull it in for this fix. And we have not seen customer issues around this. So for now I'd not open a new bug.

Comment 15 Lucy Bopf 2016-02-19 07:04:38 UTC
Moving 'requires_doc_text' to '-' to match the status of this flag in 1246117.