Bug 1251867 - Failed to reset the initial password after RHEV-H automatic installation
Failed to reset the initial password after RHEV-H automatic installation
Status: CLOSED DUPLICATE of bug 1246117
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-node (Show other bugs)
3.5.4
Unspecified Unspecified
high Severity high
: ovirt-3.5.6
: 3.5.6
Assigned To: Fabian Deutsch
Virtualization Bugs
node
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-10 03:52 EDT by Chaofeng Wu
Modified: 2016-03-03 02:01 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-07 10:09:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Node
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sosreport (6.82 MB, application/x-xz)
2015-08-10 03:52 EDT, Chaofeng Wu
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 44727 ovirt-3.5 ABANDONED Config.exists: fix exists method Never
oVirt gerrit 46186 master MERGED fs: Config.exist() now also checks the file contents Never

  None (edit)
Description Chaofeng Wu 2015-08-10 03:52:10 EDT
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-10 21:23:27 EDT
Reproduced the report, investigating.
Comment 4 Chaofeng Wu 2015-08-28 04:54:30 EDT
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 10:04:15 EDT
This is a regression of bug 1246117
Comment 7 Fabian Deutsch 2015-10-07 10:09:17 EDT

*** This bug has been marked as a duplicate of bug 1246117 ***
Comment 8 Huijuan Zhao 2015-12-17 01:13:15 EST
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 02:26:21 EST
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 02:36:44 EST
Fabian, no such issue on the 3.6 build RHEV-H 7.2-20151210.1.el7ev
Comment 11 Ying Cui 2015-12-17 04:17:56 EST
(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 04:38:45 EST
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 04:58:54 EST
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 05:39:23 EST
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 02:04:38 EST
Moving 'requires_doc_text' to '-' to match the status of this flag in 1246117.

Note You need to log in before you can comment on or make changes to this bug.