Description of problem: During the installation, if a user selects security profile as "STIG for Red Hat Virtualization Hypervisor", it will disable the ssh root login by adding "PermitRootLogin No" in the sshd_config. In such a host, the deployment will fail while it tries to add the host in the manager since it uses "root ssh" login. Currently, there is no way to use any user other than root while adding the host in the manager. Version-Release number of selected component (if applicable): ovirt-hosted-engine-setup-2.2.20 How reproducible: 100% Steps to Reproduce: 1. Select "security profile" as "STIG for Red Hat Virtualization Hypervisor" while installing RHV-H. 2. The installation will fail at the stage "Wait for the host to be up" Actual results: Hosted engine deployment is failing on STIG profile applied RHV-H Expected results: Hosted engine deployment should work on STIG profile applied RHV-H Additional info:
This is probably to be considered a tracker bug. It will require changes in several places.
It's probably not just for HE, perhaps this should change to "Add support for STIG compliant RHV hosts" to be more general.
If I enable the root login and continue HE installation, it will fail at the final stage when it starts the HE VM in the shared storage. === 2018-06-25 18:44:11,676+0530 ERROR (vm/065bd33f) [virt.vm] (vmId='065bd33f-f7e4-48ae-9f13-97b6225ef051') The vm start process failed (vm:943) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in _startUnderlyingVm self._run() File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2872, in _run dom.createWithFlags(flags) File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", line 130, in wrapper ret = f(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in wrapper return func(inst, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in createWithFlags if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self) libvirtError: internal error: process exited while connecting to monitor: 2018-06-25T13:14:10.726153Z qemu-kvm: warning: All CPU(s) up to maxcpus should be described in NUMA config, ability to start up with partial NUMA mappings is obsoleted and will be removed in future 2018-06-25T13:14:10.761515Z qemu-kvm: -vnc 10.65.177.137:0,password: Failed to start VNC server: VNC password auth disabled due to FIPS mode, consider using the VeNCrypt or SASL authentication methods as an alternative ==== Do we need to open a new bug?
Ouch, looks like vnc can't work in fips mode, so yes, I think it's worth tracking - does it work without vnc ?
(In reply to Yuval Turgeman from comment #4) > Ouch, looks like vnc can't work in fips mode, so yes, I think it's worth > tracking - does it work without vnc ? VNC can work, only with SASL auth....
(In reply to Yuval Turgeman from comment #4) > Ouch, looks like vnc can't work in fips mode, so yes, I think it's worth > tracking - does it work without vnc ? I have opened bug 1595536 for VNC issue on a FIPS enabled hypervisor. Also, the issue is not specific with HE VM and the normal VMs will also fail with same error. Spice will work fine though. Current HE deployment is creating HE VM with both spice and vnc display. I can't find any option to select _only_ spice during the deployment other than editing the ansible playbook directly. So deployment will always fail on a fips compliant hypervisor.
(In reply to nijin ashok from comment #7) > (In reply to Yuval Turgeman from comment #4) > > Ouch, looks like vnc can't work in fips mode, so yes, I think it's worth > > tracking - does it work without vnc ? > > I have opened bug 1595536 for VNC issue on a FIPS enabled hypervisor. Also, > the issue is not specific with HE VM and the normal VMs will also fail with > same error. Spice will work fine though. > > Current HE deployment is creating HE VM with both spice and vnc display. I > can't find any option to select _only_ spice during the deployment other > than editing the ansible playbook directly. So deployment will always fail > on a fips compliant hypervisor. hm, that's a nice use case for a headless HE deployment. We should consider that . I suggest to open a HE bug on that as well, separately to the question of secured VNC
(In reply to Michal Skrivanek from comment #8) > (In reply to nijin ashok from comment #7) > > (In reply to Yuval Turgeman from comment #4) > > > Ouch, looks like vnc can't work in fips mode, so yes, I think it's worth > > > tracking - does it work without vnc ? > > > > I have opened bug 1595536 for VNC issue on a FIPS enabled hypervisor. Also, > > the issue is not specific with HE VM and the normal VMs will also fail with > > same error. Spice will work fine though. > > > > Current HE deployment is creating HE VM with both spice and vnc display. I > > can't find any option to select _only_ spice during the deployment other > > than editing the ansible playbook directly. So deployment will always fail > > on a fips compliant hypervisor. > > hm, that's a nice use case for a headless HE deployment. We should consider > that . I suggest to open a HE bug on that as well, separately to the > question of secured VNC And if we implement a feature to open its console from the local (or not) Cockpit of the host...
Test Version RHVH-4.3-20181210.0-RHVH-x86_64-dvd1.iso ovirt-hosted-engine-setup-2.3.0-0.1.alpha.gitd1b8dbb.el7ev.noarch Steps: 1. Clean install RHVH-4.3-20181210.0-RHVH-x86_64-dvd1.iso 2. Select "security profile" as "STIG for Red Hat Virtualization Hypervisor" while installing RHV-H. 3. Check the "PermitRootLogin" value in the sshd_config. 4. Deploy hosted-engine via cockpit UI Result: The "PermitRootLogin" value is "No" in the sshd_config and the deployment will fail at the stage "Wait for the host to be up" More info: If I enable the root login, the same issue in comment #3 will be reproduced QE can reproduce this bug, flag qa_ack changes to "+"
re-targeting to 4.3.1 since this BZ has not been proposed as blocker for 4.3.0. If you think this bug should block 4.3.0 please re-target and set blocker flag.
We're using spice only in fips mode for now
Retest with build RHVH-4.3-20190328.0-RHVH-x86_64-dvd1.iso, new bug https://bugzilla.redhat.com/show_bug.cgi?id=1694034 blocks this issue When bug 1694034 fixed, QE will verify this bug.
Test Version RHVH-4.3-20190404.1-RHVH-x86_64-dvd1.iso cockpit-system-176-4.el7.noarch cockpit-ws-176-4.el7.x86_64 cockpit-bridge-176-4.el7.x86_64 cockpit-storaged-176-4.el7.noarch cockpit-ovirt-dashboard-0.12.7-1.el7ev.noarch cockpit-machines-ovirt-176-4.el7.noarch cockpit-dashboard-176-4.el7.x86_64 cockpit-176-4.el7.x86_64 ovirt-hosted-engine-ha-2.3.1-1.el7ev.noarch ovirt-hosted-engine-setup-2.3.7-1.el7ev.noarch rhvm-appliance-4.3-20190404.1.el7.x86_64 Test Steps: According to comment 10 Result: 1. PermitRootLogin sets to yes installed RHVH security profile is selected STIG. 2. Hosted engine deploy successfully. Bug is fixed, move it to "VERIFIED"
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:1053