This is a minor review that adds the following features:
Some sites are still using TLS 1.0 in their web proxies, and flexVDI Client 2.2.57 refuses to use that old version of the protocol. flexVDI Client 2.2.58 tries TLS 1.2, but accepts TLS 1.0 as a fallback.
As always, the latest installer can be downloaded from flexvdi.com
Improves security using TLS 1.2. Also allows connection with new versions of flexVDI webportal, which rejects old TLS versions.
As always, the latest installer can be downloaded from flexvdi.com
This version just fixes running the flexVDI Client in Ubuntu 18.04 and other systems where it could not reliably determine the terminal ID.
Last month, Red Hat Entreprise Linux 7.5 was released, and CentOS 7.5 followed shortly after. We have been working to make sure that our packages install correctly in this new revision of these popular operating systems. In particular, having an easily upgradeable OCFS2 kernel module (kmod) has been problematic, and there are some things you should know before you update your system.
Distributing binary kernel modules in RPM packages has two main problems:
Problem 1 is partially solved by Red Hat in the following way: Each new version of the RHEL operating system comes with a major revision of their base kernel: 3.10.0-514 in RHEL 7.3, -693 in RHEL 7.4, -862 in RHEL 7.5, etc. For each major revision, Red Hat publishes several updates in the form of minor revisions, like 3.10.0-862.2.3, but maintains the same ABI across different minor revisions. This means that a kernel module compiled for 3.10.0-862 will be usable with any minor revision of this kernel (that is, until RHEL 7.6 is released). For this reason, we need to provide an OCFS2 kmod package for each kernel major revision.
Which takes us to problem 2: we can have several kernel packages installed, but only one OCFS2 kmod. Solving this is not trivial. The solution we have adopted is to release a kmod package for each major revision, not with a different version, but with a different name: kmod-ocfs2-flexvdi-k514, kmod-ocfs2-flexvdi-k693, kmod-ocfs2-flexvdi-k862, and so on. In this way, any number of them may be installed at the same time, since they install to different paths and do not conflict with each other.
This solution is no perfect, though: being different packages, yum will not update them automatically. That is, when RHEL / CentOS 7.6 is released, a new major revision XYZ of the base kernel will be published and you will have to install the kmod-ocfs2-flexvdi-kXYZ package manually. The same applies if you are going to update from 7.4 to 7.5 shortly. Luckily, we provide a small hint to help you avoid booting into a kernel without the corresponding OCFS2 module: the flexvdi metapackage conflicts with any kernel version for which a suitable kmod package does not exist yet. Meanwhile, we will keep working on making the upgrade process easier for you.
This new versions make adding nodes to an existing OCFS2 cluster more robust.
Great news! We have improved our Gateway component and WebPortal appliance to make your life easier. Now, you can use your WebPortal as a Gateway for native clients too, besides serving the HTML5 client. In this way, deploying a WebPortal instance in your platform is the easiest and most secure way to provide a single entry point.