Public beta of RHEL9 is out, let's check how it works. Tested with ThinLinc 4.13.0 ✓ Basic function (Graphics, Mouse, Keyboard) CHECK ✓ Network transport ✓ Server installation (and setup) CHECK. No extra repos where needed. ✓ Session startup CHECK ✓ Sound redirection Input (mic) and output working.thin ✓ Drive redirection CHECK ✓ Printer redirection CHECK ✓ Web integration CHECK ✓ OpenGL CHECK ✓ Basic function (Graphics, Mouse, Keyboard) ✓ Network transport ✓ Server installation (and setup) ✓ Session startup Not tested yet * Nearest printer * Access control * Restriced shell (thinlinc-login) * Restricting SSH Daemon Port Forwarding ("PermitOpen") * Smart card redirection * Authentication * Interactive (password, OTP) Password tested. * Public key CHECK * Smart card * Kerberos * Smart card management (tl-ldap-certalias & friends)
Verified and tested: ✓ Smart card authentication ✓ Smart card redirection
Verified and tested: ✓ Kerberos
There seem to be issues with building SELinux modules on RHEL9 Beta. It seems to be dependant on what package versions we're using. A newly installed RHEL 9 beta, that doesn't have any updates installed (didn't run dnf upgrade) tl-setup complains a bit with a large number of lines like these: > /usr/share/selinux/devel/include/services/container.if:13: Error: duplicate definition of container_runtime_domtrans(). Original definition on 13. However, we can still build our SELinux module successfully. After running "dnf upgrade" we can no longer build our own SELinux module: > Failed to resolve allow statement at /var/lib/selinux/targeted/tmp/modules/200/container/cil:373 > Failed to resolve AST > /usr/sbin/semodule: Failed! We don't seem to be the only ones with this issue though: https://bugzilla.redhat.com/show_bug.cgi?id=2051012
I'm also seeing this SELinux issue on my workstation after upgrading to Fedora 36.
Final release is out, let's see how things work there.
The SELinux issue on Fedora 36 could be fixed like this for me: sudo dnf remove thinlinc-server -y sudo semodule -X200 -r container -X400 -r thinlinc sudo dnf reinstall -y container-selinux sudo server-bundle/install-server ... Note that in the semodule command above you need to remove the "container" and "thinlinc" modules in the same transaction, otherwise, one will always block the other. According to this Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=2056303, this issue only applies to upgraded installations of Fedora 36, not fresh installations.
Tested the following on RHEL9 using ThinLinc server 4.14.0 without any issues: ✓ Basic function (Graphics, Mouse, Keyboard) ✓ Server installation
(In reply to William Sjöblom from comment #7) Note that the workaround posted in our Platform Specific Notes for bug 7933 was required during the setup process, even on a fully updated system.
Tested with tl-4.14.0 - Redhat 9 GA Deployed from template - dnf groupinstall workstation - $ sudo update-crypto-policies --set DEFAULT:SHA1 - $ sudo reboot Functional areas to test: ✓ ✓ Basic function (Graphics, Mouse, Keyboard) ✓ Network transport ✓ Server installation (and setup) ✓ Session startup ✓ Sound redirection ✓ Drive redirection ✓ Printer redirection ✓ Web integration ✓ OpenGL ✓ Basic function (Graphics, Mouse, Keyboard) ✓ ThinLocal printing ✓ Smart card redirection Authentication ✓ Interactive (password, OTP) ✓ Public key ✓ Smart card ✓ Kerberos Not tested Nearest printer Access control Restriced shell (thinlinc-login) Restricting SSH Daemon Port Forwarding ("PermitOpen") Smart card management (tl-ldap-certalias & friends)
I think we have enough coverage to feel confident in RHEL 9: (In reply to Martin Östlund from comment #9) > > Not tested > Nearest printer > Access control thinlocal has been tested, and CUPS is not seeing many changes these days. I think the odds of something specific to nearest are very low. > Restriced shell (thinlinc-login) > Restricting SSH Daemon Port Forwarding ("PermitOpen") > Smart card management (tl-ldap-certalias & friends) Niche functionality, and in stable areas. So I don't think it is worth verifying them for explicitly RHEL 9.