YUM will be replaced[1] with DNF from Fedora 22 onwards, which presumably means it will end up in RHEL as well. We should check that the ThinLinc installer plays nicely with this package manager, and that any syntax/behaviour changes[2] are accommodated for. [1] http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF [2] http://akozumpl.github.io/dnf/cli_vs_yum.html
Tried a fresh install of Fedora 22 and yum is indeed gone so tl-setup can no longer provide a smooth installation. Opening for discussion.
One of the effects of this on Fedora 23 is that tl-setup doesn't install all necessary packages. One of these packages is selinux-policy-devel. If the user misses, like I have done a few times, that tl-setup asks you to install this manually, you will not get a very obvious error. The log mentions in that it didn't manage to install a few things, however. The result when you try to login is that the client says there are no working agents. And the following appears in vsmagent.log: > tl-session: tl-xinit exited with status=71 > subprocess: execvp: Permission denied An intermediate solution could perhaps be to give the administrator a warning.
Bug 4208 might be a solution to this.
As a start I've added a platform specific note for Fedora. Will do the same for Ubuntu.
Oops. That comment was for bug 5742, which added a note for both the Python/PyGTK issue, and the DNF issue (which is relevant for this bug).
*** Bug 7296 has been marked as a duplicate of this bug. ***
Bug 7296 has details on the situation for RHEL 8, which has replaced yum with dnf.
On RHEL8 one gets: "ThinLinc requires a few libraries and binaries to work as expected. This system lacks one or more of them and you need to manually install the packages which provides: libutil.so.1, libnspr4.so, libssl3.so, librt.so.1, libz.so.1, libgcc_s.so.1, libcrypt.so.1, libpthread.so.0, libgssapi_krb5.so.2, libnss3.so, libncurses.so.5, libpam.so.0, libm.so.6, libdl.so.2, libX11.so.6, libc.so.6, ss, /usr/sbin/sendmail, gs, pgrep, xauth" Workaround is to run dnf manually: dnf install libutil.so.1 libnspr4.so /usr/lib64/libssl3.so librt.so.1 libz.so.1 libgcc_s.so.1 libcrypt.so.1 libpthread.so.0 libgssapi_krb5.so.2 /usr/lib64/libnss3.so /usr/lib64/libncurses.so.5 libpam.so.0 libm.so.6 libdl.so.2 libX11.so.6 libc.so.6 /usr/sbin/ss /usr/sbin/sendmail /usr/bin/gs /usr/bin/pgrep /usr/bin/xauth Note that /usr/lib64 is required for some libs, or only the i686 version will be installed.
(In reply to comment #8) > On RHEL8 one gets: > > Workaround is to run dnf manually: Also required: # dnf install selinux-policy-devel Also useful: # dnf install cups
dnf does unfortunately not seem to have a "batch" mode where it prints well structured output. It does have an API though that they claim they'll keep stable: https://dnf.readthedocs.io/en/latest/api.html A problem is that it is essentially Python 3 only as that is what dnf uses on both RHEL 8 and current Fedora versions. We could solve this by creating our own "dnf" command that is a front-end for the API, but gives us the structured output we are currently lacking from the normal "dnf".
RHEL 8 also has the fun detail of having their "Platform Python" for system tools like dnf. Right now this is the same as their standard Python 3, but they have indicated that this might change. So to safely access the API we probably need to use the same "Platform Python".
This method seems to work fine. I did find some bugs in the API documentation though: https://bugzilla.redhat.com/show_bug.cgi?id=1709352 https://bugzilla.redhat.com/show_bug.cgi?id=1709783 There are also a few functions that aren't officially part of the API that we'd like to use to get details about the transaction. I've added a request to make these official: https://bugzilla.redhat.com/show_bug.cgi?id=1709359
I did not find an API for locking, unfortunately. This has the potential risk of the system changing between us showing what we intend to do, and actually doing it. I'm not sure if it is worth trying to sort this out. To solve it I guess we would need to make sure the process using the DNF API stays alive and that we have a more active bidirectional communication with it.
Should be done now. Seems to work well on RHEL 8 and Fedora Rawhide.
It was a bit tricky to test on RHEL 8, but with these steps I managed: 1. manually run: "dnf install python2" (bug 7295) 2. to start the installer: "PYTHON=python2 ./install-server" 3. in tl-setup: de-select the options to install python-ldap (7330) and pygtk-libglade (7329) * text-mode works fine, logs errors about python-ldap and pygtk-libglade * GUI-mode is a bit trickier since you have to go back one step and deselect the package installation when python-ldap and libglade fails. This is something our customers might have problems with. * log file looks good * dnfhelper is included in the server bundle, under "sources/thinlinc-tlmisc-open-sources.tar.gz" Looks good.
I'm getting spam in tlsetup.log on systems not running DNF: "Could not import DNF API". Very confusing.
Fixed now
Looks good. Verified that I could also see the problem on Ubuntu 18.04, and that it is now fixed with build 6178.r34322.jenkins1406.
