Both Engine and Vdsm support new and improved TLS protocols as of clusterLevel 4.0. When adding a host to a cluster >= 4.0, Engine should set ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1 in vdsm, to disable these outdated protocols. Ondra Machacek suggested that the patch should go into https://github.com/oVirt/ovirt-engine/tree/master/packaging/playbooks/roles/ovirt-host-deploy and take an action based on host_deploy_cluster_version.
(In reply to Dan Kenigsberg from comment #0) > Both Engine and Vdsm support new and improved TLS protocols as of > clusterLevel 4.0. > > When adding a host to a cluster >= 4.0, Engine should set > > ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1 > > in vdsm, to disable these outdated protocols. > > > Ondra Machacek suggested that the patch should go into > https://github.com/oVirt/ovirt-engine/tree/master/packaging/playbooks/roles/ > ovirt-host-deploy and take an action based on host_deploy_cluster_version. I suppose this won't be merged in any way to mess with env < 4.1.1.3, right? Because if so it would break those envs, as VDSMProtocol = TLSv1.2 seems to be first introduced only in 4.1.1.3 and lower env 4.0/4.1 versions already have cluster == 4.0.
(In reply to Dan Kenigsberg from comment #0) > When adding a host to a cluster >= 4.0, Engine should set host is not being "deployed" to a cluster. Why do you need to differentiate anyway? When exactly do you have to not disable it?
Moving to Martin being this tracked as infra bug.
TLS version available in VDSM is not bound to cluster level, but to VDSM version. From oVirt 4.1.8 (vdsm 4.19.38 BZ1513886) VDSM supports TLSv12, but that host can be part of any cluster. So I suggest to create Ansible role which: 1. Will check VDSM version on all hosts in a cluster 2. If version is always >= 4.19.38, then disable TLSv1 and TLSv11 using 2.a Put host to maintenance 2.b Create /etc/vdsm/vdsm.conf.d/99-restrict-tls.conf containing relevant options 2.c Restart VDSM 2.d Activate host This flow should be performed with one host at a time similar to our cluster-upgrade role.
(In reply to Michal Skrivanek from comment #2) > (In reply to Dan Kenigsberg from comment #0) > > When adding a host to a cluster >= 4.0, Engine should set > > host is not being "deployed" to a cluster. Why do you need to differentiate > anyway? When exactly do you have to not disable it? I thought that setting ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1 might cause a problem with older vdsm that may exist in a 3.6 cluster, but you may be true and we can set it to all newly-installed hosts. This config would be ignored by old vdsm if set on them, and would not harm their communication with hosts that do have vdsm>=4.19. (But this should be verified by QE) (In reply to Martin Perina from comment #4) > TLS version available in VDSM is not bound to cluster level, but to VDSM > version. From oVirt 4.1.8 (vdsm 4.19.38 BZ1513886) VDSM supports TLSv12, but > that host can be part of any cluster. > > So I suggest to create Ansible role which: > > 1. Will check VDSM version on all hosts in a cluster > 2. If version is always >= 4.19.38, then disable TLSv1 and TLSv11 using > 2.a Put host to maintenance > 2.b Create /etc/vdsm/vdsm.conf.d/99-restrict-tls.conf containing > relevant options > 2.c Restart VDSM > 2.d Activate host > > This flow should be performed with one host at a time similar to our > cluster-upgrade role. An upgrade Ansible role is cool to have, but I think it belongs to ANOTHER bz. In this bug I'm referring to clean installation of a new host, not an upgrade of an existing system. When ovirt-engine-4.2 adds a new host, it should set ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1 on it.
Please note that I was not aware of bug 1451297 commit 17 when I filed this bug; yet it show this bug's urgency.
So, right now all VDSM configuration and service status changes are performed in classic host deploy and not in new ansible host-deploy. So to be able to provide easy backport to 4.2.z we need to perform those changes in classic host-deploy, which means that for all host installation or re-installation we will create /etc/vdsm/vdsm.conf.d/10-tls-setup.conf file with following content: ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1
(In reply to Martin Perina from comment #7) > So, right now all VDSM configuration and service status changes are > performed in classic host deploy and not in new ansible host-deploy. So to > be able to provide easy backport to 4.2.z we need to perform those changes > in classic host-deploy, which means that for all host installation or > re-installation we will create /etc/vdsm/vdsm.conf.d/10-tls-setup.conf file > with following content: > > ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1 Correction, we can do above only from cluster levels >= 4.1, because 3.6 and 4.0 hosts still may need TLSv1 to function properly
(In reply to Dan Kenigsberg from comment #6) > Please note that I was not aware of bug 1451297 commit 17 when I filed this > bug; yet it show this bug's urgency. So, aren't the two basically the same and we should duplicate one of them?
(In reply to Marina from comment #9) > (In reply to Dan Kenigsberg from comment #6) > > Please note that I was not aware of bug 1451297 commit 17 when I filed this > > bug; yet it show this bug's urgency. > > So, aren't the two basically the same and we should duplicate one of them? This one is newer and here engine just configures VDSM to disable older TLS versions. BZ1451297 is older, we wanted completely removed older TLS versions (remove even options which could allow TLSv1 and TLSv11), which could be much easier and more consistent when you take a look at supported engine versions and host versions compatibility matrix.
ok, vdsm-4.20.30-1.el7ev.x86_64 ovirt-engine-4.2.4.2-0.1.el7_3.noarch ovirt-host-deploy-1.7.4-1.el7ev.noarch install, host-deploy: under 4.2/4.1 cluster: # cat /etc/vdsm/vdsm.conf [vars] ssl_excludes = OP_NO_TLSv1,OP_NO_TLSv1_1 ssl = true ssl_ciphers = HIGH [addresses] management_port = 54321 under 3.6/4.0 cluster: # rpm -q vdsm vdsm-4.20.30-1.el7ev.x86_64 # cat /etc/vdsm/vdsm.conf [vars] ssl = true [addresses] management_port = 54321
correction, under 4.1 it was: # cat /etc/vdsm/vdsm.conf [vars] ssl_excludes = OP_NO_TLSv1,OP_NO_TLSv1_1 ssl = true [addresses] management_port = 54321 because 4.2 adds ssl_ciphers https://bugzilla.redhat.com/show_bug.cgi?id=1582527
This bugzilla is included in oVirt 4.2.4 release, published on June 26th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.4 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.