Bug 1591693

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