Forticlient VPN broken dependency

Hi all,

I’m trying to install forticlient (fortinet’s VPN client), but at install time, I get an error about a missing dependency.

  1. add the repo:

❯ sudo zypper repos -u | grep forti
6 | forticlient-yum | forticlient-yum | Yes | ( p) Yes | Yes | https://repo.fortinet.com/repo/forticlient/7.2/centos/8/os/x86_64

  1. refresh repos and install with sudo zypper in forticlient

At this step you will see:

roblem: 1: nothing provides 'libXext' needed by the to be installed forticlient-7.2.7.0905-1.el7.x86_64
 Solution 1: do not install forticlient-7.2.7.0905-1.el7.x86_64
 Solution 2: break forticlient-7.2.7.0905-1.el7.x86_64 by ignoring some of its dependencies

With option 2 it installs as well, but some buttons seem disabled in the UI, and I keep wondering if that’s because of that missing dependency.

In /usr/lib64 I have the following:

image

So I don’t understand why the library is not found.

Any ideas? Thanks

❯ rpm -qp forticlient_vpn_7.4.0.1636_x86_64.rpm --requires
systemd-libs > 0
gtk2 > 0
libXScrnSaver > 0
libXcomposite >= 0.3-1
libXcursor > 1.1.2
libXdamage >= 1.1
libXext
libXfixes >= 5.0
libXrandr >= 1.2.99.3
libXrender
libXtst
libxcb >= 1.6
libsecret >= 0.18.6
yum-utils >= 0
iptables
nss-tools >= 3.44.0
/bin/sh
/bin/sh
/bin/sh
/bin/sh
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1

openSUSE Tumbleweed provides libXext6 whilst forticlient searches for libXext.
But why do you try to this repo? It is not even for the VPN? The VPN has its own rpm on the downloadpage…

Hi, thanks for chiming in.

I need the client with the zero trust fabric agent, which looks like this:

(but just for the sake of completenees, the RPM for the VPN-only software also fails to install for the same reason)

Is there any chance I can install libXext (not 6) on my system without breaking tons of stuff?

EDIT: spun up a fedora VM, there I don’t get any warnings, it installs just fine and also when I enter my invitation code and click on “Connect” a popup appears.

That same popup doesn’t appear on TW (I guess the popup is coded against X11/libXext and that’s why I need it).

The question is, if fedora 40 packages such an old version of libXext, I should be able to get myself the same version and run it alongside libXext6 on my TW install, no?

I mean I would definitely consider copy-pasting .so files from the fedora VM into my TW install, if that can help

Still unclear why Fedora has all the needed dependencies while TW doesn’t. They’re both kind of on the bleeding edge in terms of packages/QT/KDE.

Any ideas?

Thanks

Because different distributions use different naming schemes.

And 3rd party suppliers often only care for one naming…

Yeah, mixing packages from a different distro will typically break things. This is a CentOS repo, not an openSUSE repo.

You can try creating a symlink to the libXext6 libraries (with the appropriate names that it needs) and that might work. Or you can ask Fortinet for a package that works with openSUSE.

Thanks, I did some more testing and I think it’s got nothing to do with the UI.

Turns out I was using the wrong version of forticlient (7.4 or 7.2 instead of 7.0).

With version 7.0 all you have to do is enter the invite code provided by IT, and the client should connect to an endpoint.

This can also be done via CLI, with “forticlient epctrl register <invite_code>” (epctrl stands for endpoint control).

Now here’s where things get ugly on TW, as I’m stuck on “Registering on FortiClient Cloud”, whereas on Fedora a connection is established.

I tried to look a bit into the logs, and I could notice something strange here:

/var/log/forticlient/confighandler.log:

20241227 22:46:17.843 TZ=+0100 [confighandler:EROR] fctconfig_handler:156 Error occurred while polling. [4]

20241227 22:46:17.843 TZ=+0100 [confighandler:INFO] fctconfig_handler:212 Closing confighandler endpoint.

20241227 22:46:17.843 TZ=+0100 [confighandler:INFO] fctconfig_handler:214 Closing sqlite database.

20241227 22:46:17.844 TZ=+0100 [confighandler.log:INFO] main:62 confighandler daemon exiting.

I should avoid this daemon from erroring and exiting (it doesn’t happen on fedora).

Problem is, this crap is closed source, so I guess I’m out of luck :confused: