On RHEL8, python-ldap is only available for Python 3: # dnf search 'python*ldap' ... python3-ldap.x86_64 : An object-oriented API to access LDAP directory servers This means that tl-ldap-certalias will not work.
A platform specific note was written for this bug for ThinLinc 4.10.1: https://www.cendio.com/thinlinc/docs/platforms/redhat The package python-ldap is available in rhel-7-server-rpms on RHEL7, and a python2-ldap3 is available in EPEL 7. Hopefully something will be available in EPEL 8.
As an unexpected side-effect, I believe that the fact that as of implementing dnf support in bug 5202 we made the process a bit more confusing for the administrator with regards to this bug. I noticed the difference when working around stuff in order to get ThinLinc 4.10.0 to install on RHEL 8. The 4.10.0 tl-setup will just say: > The Python LDAP module is required for LDAP integration tools. Your > system does not have this installed and we strongly suggest that you > install these dependencies if you plan to use ThinLinc provided LDAP > tools. > > Most modern distributions include a python-ldap package. For more > information on this software, see http://python-ldap.sourceforge.net/. > > Press Enter to continue... While 4.10.1 tl-setup will ask you to continue attempting to install python-ldap. This will cause tl-setup to fail since python-ldap isn't available on RHEL 8.
python2-ldap3 is now available from EPEL and we've updated the platform specific notes.
I could not find a `python2-ldap3` package in EPEL8, only a python3 variant. http://mirror.math.princeton.edu/pub/epel/8/Everything/x86_64/Packages/p/
That's odd. I wonder if it was a mistake or if they changed their minds. It can still be found on their build server here: https://koji.fedoraproject.org/koji/buildinfo?buildID=1397620
(In reply to Pierre Ossman from comment #6) > It can still be found on their build server here: Submitted a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1885204
*** Bug 7510 has been marked as a duplicate of this bug. ***
On Fedora 34 "python-ldap" is now an alias for "python3-ldap" instead of the Python 2 version.
I've examined what the python3-ldap package is called on the different distributions. As can be seen below, the name is 'python3-ldap' for all distributions except RHEL 7. Further, the python3-ldap package is not available on SLES 12. RHEL 7: python36-ldap* RHEL 8: python3-ldap Fedora 34: python3-ldap CentOS 8: python3-ldap Ubuntu 18.04: python3-ldap Ubuntu 20.04: python3-ldap SLES 12: not available SLES 14: python3-ldap * Available through EPEL
I have tested that the script runs correctly in Python 3 through the smart cart tests we have available. I also tested that python3-ldap was installed correctly on the following distributions, and checked that the logs looked good. ✓ RHEL 7 ✓ RHEL 8 ✓ Fedora 34 ✓ CentOS 8 ✓ Ubuntu 18.04 ✓ Ubuntu 20.04 ✓ SLES 12 ✓ SLES 14
Running `tl-ldap-certalias -d` on a machine using Latin-1 against an LDAP server containing usernames with characters outside the Latin-1 range results in the following stack trace: > Traceback (most recent call last): > File "/opt/thinlinc/sbin/tl-ldap-certalias", line 1287, in <module> > OoO00 = OOo0o00o ( ) > File "/opt/thinlinc/sbin/tl-ldap-certalias", line 819, in OOo0o00o > iIIiii1iI ( "Found user %s" % o0OoiI1II1i1i1 ) > File "/opt/thinlinc/sbin/tl-ldap-certalias", line 85, in iIIiii1iI > print ( "tl-ldap-certalias: DEBUG:" , s ) > UnicodeEncodeError: 'latin-1' codec can't encode character '\u20ac' in position 17: ordinal not in range(256) By visual inspection, it seems like this is not the only place where we assume that usernames stored in the LDAP server can be encoded in system locale. An example that will not require the `-d` flag is if the `userCertificate` attribute of the user could not be loaded. Steps to reproduce: 1. Create a user with UID 10001 in the LDAP database with a username containing €. 2. Create a local user on the Latin-1 machine running the thinlinc server with UID 10001. 3. Run `tl-ldap-certalias -d`.
Apart from the problem mentioned in comment 25, the below test cases all work as expected: - [X] Installs correct LDAP package - [X] RHEL7 - [X] RHEL8 - [X] Fedora 33 - [X] Debian 10 - [X] Ubuntu 18.04 - [X] Ubuntu 20.04 - [X] SLES15 - [X] Dockerized tests - [X] `tl-ldap-certalias` against dockerized infrastructure - [X] RHEL7 - [X] RHEL8 - [X] Debian 10 - [X] Ubuntu 18 - [X] SLES15 - [X] Running `tl-ldap-certalias` on a Latin-1 system against a CA server with non-Latin-1 certificates. - [X] Running `tl-ldap-certalias` on a Latin-1 system with user home directories locally set to a non-Latin-1 path (letting `tl-ldap-certalias` create said homedirs). Regarding the "dockerized infrastructure", we run the same `tl-ldap-certalias` tests as in the dockerized tests, with the difference that these tests are run on a VM. This VM is configured to connect to the LDAP/CA running in the docker container used for the dockerized tests.
Tested, and the code now replaces any character unavailable in the system's locale with a '?' during prints. Setup the needed environment by following these steps (from comment 25): > 1. Create a user with UID 10001 in the LDAP database with a username containing €. > 2. Create a local user on the Latin-1 machine running the thinlinc server with UID 10001. Should be tested for 2 scenarios: A) Run tl-ldap-certalias -d - Make sure prints with DEBUG tag replaces invalid characters B) User have invalid certificate - The easiest way to simulate an invalid cert is by replacing libexec/tl-certtool with a symlink to e.g. ls. - Make sure prints with ERROR tag replaces invalid characters
The problems mentioned in comment 25 have now been retested with Jenkins server build #2224 and works as expected. Marking as closed.
