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
Reproduced the report, investigating.
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.
This is a regression of bug 1246117
*** This bug has been marked as a duplicate of bug 1246117 ***
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?
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?
Fabian, no such issue on the 3.6 build RHEV-H 7.2-20151210.1.el7ev
(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?
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.
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.
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.
Moving 'requires_doc_text' to '-' to match the status of this flag in 1246117.