> On 8. 9. 2021, at 20:48, Milan Zamazal <mzamazal(a)redhat.com&gt; wrote: > > Hi, > > we had to disable VNC OST test some time ago because it started failing. > I looked at why it fails and the reason provided by > ovirt-websocket-proxy is > > do_vencrypt_handshake:187 Server supports the following subtypes: 263 263 is VNC_AUTH_VENCRYPT_X509SASL because with fips we change libvirt configuration to SASL?

> Server does not support X509VNC. OvirtProxy only supports X509VNC > > This happens only when FIPS is enabled and is reproducible outside OST. > The only thing that seems to have influence on whether it works or not > is the value of `fips' kernel command line parameter -- when it's > changed to fips=0 then noVNC console works without any other changes. > > So it looks like some change in QEMU. I'm not an expert in this area > and don't know what those protocols are about, why the proxy supports > only X509VNC and why the mismatch in expectations on both the ends > happens when FIPS is enabled. Can anybody help clarify it and provide > an idea how to resolve the problem? > > Thanks, > Milan > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/S6MCLJV2QMQ...

On 14. 9. 2021, at 13:45, Michal Skrivanek <michal.skrivanek(a)redhat.com&gt; wrote: > On 10. 9. 2021, at 20:06, Milan Zamazal <mzamazal(a)redhat.com&gt; wrote: > > Michal Skrivanek <michal.skrivanek(a)redhat.com&gt; writes: > >>> On 8. 9. 2021, at 20:48, Milan Zamazal <mzamazal(a)redhat.com&gt; wrote: >>> >>> Hi, >>> >>> we had to disable VNC OST test some time ago because it started failing. >>> I looked at why it fails and the reason provided by >>> ovirt-websocket-proxy is >>> >>> do_vencrypt_handshake:187 Server supports the following subtypes: 263 >> >> 263 is VNC_AUTH_VENCRYPT_X509SASL >> because with fips we change libvirt configuration to SASL? > > libvirt configuration is the same whether we boot with fips=0 or fips=1 > (and disable/enable FIPS for the cluster accordingly). And the proxy > works with fips=0 even when auth_unix_rw="sasl" is set in the libvirt > configuration. it could be qemu’s decision to enforce only this one when FIPS enabled > > So should we add VENCRYPT_X509SASL support to the proxy? yes, I do not see any other way when this is the only supported connection type

> >>> Server does not support X509VNC. OvirtProxy only supports X509VNC >>> >>> This happens only when FIPS is enabled and is reproducible outside OST. >>> The only thing that seems to have influence on whether it works or not >>> is the value of `fips' kernel command line parameter -- when it's >>> changed to fips=0 then noVNC console works without any other changes. >>> >>> So it looks like some change in QEMU. I'm not an expert in this area >>> and don't know what those protocols are about, why the proxy supports >>> only X509VNC and why the mismatch in expectations on both the ends >>> happens when FIPS is enabled. Can anybody help clarify it and provide >>> an idea how to resolve the problem? >>> >>> Thanks, >>> Milan >>> _______________________________________________ >>> Devel mailing list -- devel(a)ovirt.org >>> To unsubscribe send an email to devel-leave(a)ovirt.org >>> Privacy Statement: https://www.ovirt.org/privacy-policy.html >>> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ >>> List Archives: >>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/S6MCLJV2QMQ... >