Bug 7330 - python-ldap for Python 2 missing on modern distributions
Summary: python-ldap for Python 2 missing on modern distributions
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Server OS (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.13.0
Assignee: Linn
Keywords: prosaic, wilsj_tester
: 7510 (view as bug list)
Depends on: 4586
Blocks: 7328
  Show dependency treegraph
Reported: 2019-04-09 11:08 CEST by Peter Åstrand
Modified: 2021-07-14 13:12 CEST (History)
5 users (show)

See Also:
Acceptance Criteria:


Description Peter Åstrand cendio 2019-04-09 11:08:48 CEST
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.
Comment 1 Samuel Mannehed cendio 2019-07-25 11:14:49 CEST
A platform specific note was written for this bug for ThinLinc 4.10.1:


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.
Comment 2 Samuel Mannehed cendio 2019-07-26 16:47:55 CEST
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.
Comment 3 Pierre Ossman cendio 2020-05-27 08:59:47 CEST
python2-ldap3 is now available from EPEL and we've updated the platform specific notes.
Comment 5 quent.haas 2020-10-02 19:09:20 CEST
I could not find a `python2-ldap3` package in EPEL8, only a python3 variant.

Comment 6 Pierre Ossman cendio 2020-10-05 09:45:51 CEST
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:

Comment 7 quent.haas 2020-10-05 14:16:12 CEST
(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
Comment 8 Pierre Ossman cendio 2021-05-28 13:34:00 CEST
*** Bug 7510 has been marked as a duplicate of this bug. ***
Comment 9 Pierre Ossman cendio 2021-05-28 13:34:41 CEST
On Fedora 34 "python-ldap" is now an alias for "python3-ldap" instead of the Python 2 version.
Comment 10 Linn cendio 2021-06-23 16:57:52 CEST
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
Comment 14 Linn cendio 2021-07-07 13:35:13 CEST
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
Comment 25 William Sjöblom cendio 2021-07-12 16:50:42 CEST
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`.
Comment 26 William Sjöblom cendio 2021-07-13 10:54:52 CEST
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.
Comment 28 Linn cendio 2021-07-14 08:32:41 CEST
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
Comment 31 William Sjöblom cendio 2021-07-14 13:12:59 CEST
The problems mentioned in comment 25 have now been retested with Jenkins server build #2224 and works as expected. Marking as closed.

Note You need to log in before you can comment on or make changes to this bug.