Created attachment 1187432 [details] screenshot of cockpit login page Description of problem: Upgrade RHVH, boot to new build, access cockpit via "ip:9090", login page can not display account input box, there is error: Authentication failed: no results Version-Release number of selected component (if applicable): redhat-virtualization-host-4.0-20160803.3 imgbased-0.7.4-0.1.el7ev.noarch cockpit-0.114-2.el7.x86_64 cockpit-ovirt-dashboard-0.10.6-1.3.4.el7ev.noarch redhat-virtualization-host-image-update-placeholder-4.0-0.26.el7.noarch How reproducible: 80% Steps to Reproduce: 1. Install redhat-virtualization-host-4.0-20160727.1 2. Login RHVH and setup local repos 3. Login cockpit via "ip:9090" 4. Upgrade RHVH: # yum update 5. Reboot and login new build redhat-virtualization-host-4.0-20160803.3 6. Login cockpit via "ip:9090" Actual results: 1. After step3, cockpit display normal, can login cockpit successful 2. After step6, cockpit login page display error, can not display account input box Expected results: 2. After step6, cockpit login page should display normal, can login cockpit successful Additional info:
Created attachment 1187433 [details] All logs
We consider it is blocker, need to pay more attention on it.
Form journal: # systemctl status cockpit ● cockpit.service - Cockpit Web Service Loaded: loaded (/usr/lib/systemd/system/cockpit.service; static; vendor preset: disabled) Active: inactive (dead) since Do 2016-08-04 09:05:18 EDT; 57s ago Docs: man:cockpit-ws(8) Process: 7904 ExecStart=/usr/libexec/cockpit-ws (code=exited, status=0/SUCCESS) Process: 7901 ExecStartPre=/usr/sbin/remotectl certificate --ensure --user=root --group=cockpit-ws --selinux-type=etc_t (code=exited, status=0/SUCCESS) Main PID: 7904 (code=exited, status=0/SUCCESS) Aug 04 09:03:48 dhcp-10-16.nay.redhat.com systemd[1]: Starting Cockpit Web Service... Aug 04 09:03:48 dhcp-10-16.nay.redhat.com systemd[1]: Started Cockpit Web Service. Aug 04 09:03:48 dhcp-10-16.nay.redhat.com cockpit-ws[7904]: Using certificate: /etc/cockpit/ws-certs.d/0-self-signed.cert Aug 04 09:03:51 dhcp-10-16.nay.redhat.com cockpit-ws[7904]: couldn't parse /usr/libexec/cockpit-session auth output: JSON data was empty Aug 04 09:04:21 dhcp-10-16.nay.redhat.com cockpit-ws[7904]: couldn't parse /usr/libexec/cockpit-session auth output: JSON data was empty Aug 04 09:05:02 dhcp-10-16.nay.redhat.com cockpit-ws[7904]: couldn't parse /usr/libexec/cockpit-session auth output: JSON data was empty Stef, have you seen this before? Could it be a regression of the last update?Th eupdate was: -cockpit-ovirt-dashboard-0.10.6-1.3.3.el7ev.noarch +cockpit-ovirt-dashboard-0.10.6-1.3.4.el7ev.noarch -dbus-1.6.12-13.el7.x86_64 +dbus-1.6.12-14.el7_2.x86_64 -dbus-libs-1.6.12-13.el7.x86_64 +dbus-libs-1.6.12-14.el7_2.x86_64 There are no denials
I'm (mostly on) PTO. In order to diagnose provide a downloadable reproducible image where this functionality manifests itself. Alternatively, complete, step by step, instructions from install, channel, repo, all the way through to the bug.
Thanks Stef - This is on RHVH where we just replace one image with the other. Raising the urgency, because cockpit can not be accessed after updates anymore.
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Manually running cockpit-ws works: $ systemctl stop cockpit.socket $ systemctl stop cockpit.service $ /usr/libexec/cockpit-ws Now access and authentication to HOST:9090 works. Going by to use the service results in this bug again. The systemd differences between the working nad non-working setup are: -systemd-219-19.el7_2.11.x86_64 -systemd-libs-219-19.el7_2.11.x86_64 -systemd-python-219-19.el7_2.11.x86_64 -systemd-sysv-219-19.el7_2.11.x86_64 +systemd-219-19.el7_2.12.x86_64 +systemd-libs-219-19.el7_2.12.x86_64 +systemd-python-219-19.el7_2.12.x86_64 +systemd-sysv-219-19.el7_2.12.x86_64
On the test system i was given access to the setuid flags and group owner of cockpit-session were incorrect. Removing cockpit-ws, and reinstalling the cockpit-ws-0.114-2.el7.x86_64.rpm fixed things. I'm not sure how those permissions got changed.
(In reply to Fabian Deutsch from comment #5) > Thanks Stef - This is on RHVH where we just replace one image with the other. > > Raising the urgency, because cockpit can not be accessed after updates > anymore. Thanks Fabian and Stef, please contact with me if need other more detailed info.
Okay, it looks like an uid-drift issue: # ls -shal {/,l,l2}/usr/libexec/cockpit-session 28K -rwsr-x---. 1 root input 28K 15. Jul 11:13 l2/usr/libexec/cockpit-session 28K -rwsr-x---. 1 root cockpit-ws 28K 15. Jul 11:13 l/usr/libexec/cockpit-session 28K -rwsr-x---. 1 root input 28K 15. Jul 11:13 //usr/libexec/cockpit-session (l is the prev image, l2 the current). The uid is different between the images, thus the uid drift fix failed.
Please try to update to redhat-virtualization-host-image-update-4.0-20160810.0
(In reply to Fabian Deutsch from comment #11) > Please try to update to > redhat-virtualization-host-image-update-4.0-20160810.0 Hi Fabian, still no boot entry for new imgbased, so can not check cockpit for new imgbased, and there is some fail info during update. I keeped the RHVH env, and send email to you for the env info.
Still encounter this issue same as comment 0 with build redhat-virtualization-host-image-update-4.0-20160810.1.el7_2.noarch.rpm
Still encounter this issue on redhat-virtualization-host-image-update-4.0-20160811.0, same as comment 0. How reproducible: 80% Test version: redhat-virtualization-host-4.0-20160811.0 imgbased-0.8.4-1.el7ev.noarch cockpit-ws-0.114-2.el7.x86_64 cockpit-ovirt-dashboard-0.10.6-1.3.6.el7ev.noarch redhat-virtualization-host-image-update-placeholder-4.0-1.el7.noarch So I have to change the status to ASSIGNED. ENV: 10.66.148.10, pw:redhat, you can access host if needed.
Thanks for testing. I don't need a test environment, but I am curious whether the environment used for testing differed each time (or a reliable method to reproduce). I tested this 6 times today, and never encountered a reproducer after the patch. Was a clean installation performed each time, then upgraded? Or was the upgrade rolled back? Can you provide the results of "rpm --verify cockpit-ws"?
1. In the host after update: # rpm --verify cockpit-ws ......G.. /usr/libexec/cockpit-session 2. Yes, we used different ENVs to test, and clean install with kickstart file, attachment is the kickstart file. After update, can rollback to old imgbase successful, and can access cockpit in old imgbase. 3. But there is no such update issue from redhat-virtualization-host-4.0-20160810.1 to redhat-virtualization-host-4.0-20160811.0
Created attachment 1190257 [details] kickstart file
Sorry, I'm unclear on #3. This is not reproducible from 20160810.1 when upgraded to 20160811.0? Only from 20160803?
Yes, this is not reproducible from 20160810.1 when upgraded to 20160811.0. But can reproduce from redhat-virtualization-host-4.0-20160727.1 when upgraded to 20160811.0. I did not try from 20160803, let me try it now.
Don't worry about it -- the UID/gid drifted after 20160727, I was just curious which image you upgraded from. I tested from 20160803, but I'll try 20160727 tomorrow.
ok, thank you Ryan for your testing, good night. Yes, you are right, can not reproduce from 20160803. I would like to summary our testing: 1. Can reproduce from 20160727 2. Can not reproduce from 20160803 and 20160810.1
There was a problem with the spec, fixed, now: # rpm -e redhat-virtualization-host-image-update-4.0-20160811.0.el7_2.noarch # rpm -ivh redhat-virtualization-host-image-update-4.0-20160811.0.el7_2.noarch.rpm Vorbereiten... ################################# [100%] Aktualisierung/ Installation... 1:redhat-virtualization-host-image-################################# [100%] # mount /dev/mapper/r4b_dell--pet105--02-rhvh--4.0--0.20160811.0+1 l # chroot l # ls -shalr /usr/libexec/cockpit-* 268K -rwxr-xr-x. 1 root root 265K 15. Jul 11:13 /usr/libexec/cockpit-ws 304K -rwxr-xr-x. 1 root root 303K 15. Jul 11:13 /usr/libexec/cockpit-stub 28K -rwsr-x---. 1 root cockpit-ws 28K 15. Jul 11:13 /usr/libexec/cockpit-session 24K -rwsr-xr-x. 1 root root 24K 15. Jul 11:13 /usr/libexec/cockpit-polkit cockpit ws is right.
This issue is fixed in redhat-virtualization-host-4.0-20160812.0, below is detailed testing info: Test version: redhat-virtualization-host-4.0-20160812.0 imgbased-0.8.4-1.el7ev.noarch cockpit-ws-0.114-2.el7.x86_64 cockpit-ovirt-dashboard-0.10.6-1.3.6.el7ev.noarch redhat-virtualization-host-image-update-placeholder-4.0-1.el7.noarch Test Steps: 1. Install redhat-virtualization-host-4.0-20160727.1 2. Login RHVH and setup local repos 3. Login cockpit via "ip:9090" 4. Upgrade RHVH: # yum update 5. Reboot and login new build redhat-virtualization-host-4.0-20160803.3 6. Login cockpit via "ip:9090" Test results: After step6, cockpit login page should display normal, can login cockpit successful I will change the status to VERIFIED when the status changes to ON_QA
VERIFIED according to comment 23