Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-15503

python3-freeradius 3.0.21 package not compatible with python 3.8 and higher and RHEL 9.2 has python 3.9

    • Icon: Bug Bug
    • Resolution: Done-Errata
    • Icon: Undefined Undefined
    • rhel-9.4
    • rhel-9.2.0.z, rhel-9.3.0.z, rhel-9.4
    • freeradius
    • None
    • freeradius-3.0.21-39.el9
    • None
    • None
    • ZStream
    • 2
    • rhel-sst-idm-ipa
    • ssg_idm
    • 12
    • 14
    • 1
    • False
    • Hide

      None

      Show
      None
    • No
    • 2023-Q4-Bravo-S4, 2023-Q4-Bravo-S5
    • Approved Blocker
    • None

      What are you experiencing? What are you expecting to happen?

          We have freeradius and python3-freeradius packages installed on the server. Both are version 3.0.21-37.el9 from repository @rhel-9-for-x86_64-appstream-rpms.
           
          When we start the freeradius server in debug mode (radiusd -X) and the python3 module is instantiated, it shows this error:
          # Instantiating module "python3" from file /etc/raddb/mods-enabled/python
          Python version: 3.9.16 (main, Sep 12 2023, 00:00:00)  [GCC 11.3.1 20221121 (Red Hat 11.3.1-4)]
          Failed loading libpython3.9m.so: libpython3.9m.so: cannot open shared object file: No such file or directory
          Failed loading libpython symbols into global symbol table
           
          Freeradius looks for the libpython3.9m.so shared object file but that does not exist. The shared object file provided by Python3.9 is libpython3.9.so. Note that there is no "m" in the filename. Freeradius is looking for the wrong filename.
           
          I found in the github repo of FreeRADIUS that Python version 3.8 and higher no longer uses "m" in the name of the shared object file and this has been fixed in release 3.0.22 of FreeRADIUS.
           
          If you check https://github.com/FreeRADIUS/freeradius-server/compare/release_3_0_21...release_3_0_22 for file src/modules/rlm_python3/rlm_python3.c this is the new code:
          /*
           * Since version 3.8, the "m" suffix is no longer available.
           * https://bugs.python.org/issue36707
           */
          #if PY_MINOR_VERSION >= 8
          #define LIBPYTHON_LINKER_NAME \
                  "libpython" STRINGIFY(PY_MAJOR_VERSION) "." STRINGIFY(PY_MINOR_VERSION) LT_SHREXT
          #else
          #define LIBPYTHON_LINKER_NAME \
                  "libpython" STRINGIFY(PY_MAJOR_VERSION) "." STRINGIFY(PY_MINOR_VERSION) "m" LT_SHREXT
          #endif
           
          The RHEL 9.2 repository @rhel-9-for-x86_64-appstream-rpms ships version 3.0.21-37.el9 of the freeradius and python3-freeradius packages. Our problem would be fixed if the version in the repository would be 3.0.22 or higher.
           
          Although I understand RHEL prefers stability over the latest and greatest versions, version 3.0.21 supplied by the repo dates from 
          Mar 24, 2020. FreeRADIUS  release 3.0.22 is from May 17, 2021.
           
          Please consider updating the repo version to a more recent release of FreeRADIUS to enable customers using the python3-freeradius package to run in on RHEL 9.2.
           
          Define the value or impact to you or the business
          The provided version 3.0.21 of python3-freeradius does not run on RHEL 9.2 because it looks for the wrong Python shared object file. This is fixed in python3-freeradius version 3.0.22, but that version is currently not available in the rhel-9-for-x86_64-appstream-rpms repo.
           
           
          =================================================================
           
          When using a Python module in FreeRADIUS 3.0.21, it looks for a shared object library named libpython3.9m.so in /usr/lib64/.
           
          In version 3.9 of Python, the shared object file is called libpython3.9.so (without the m). Python 3.8 would provide libpython3.8.so (also without m). As far as I understand, only versions up to Python 3.7 provide the m-version of the shared object file (libpython3.7m.so).
           
          The problem I am logging is that the issue is in the FreeRADIUS version currently packaged by Red Hat: 3.0.21. This version looks for libpython3.9m.so but should be looking for libpython3.9.so. In the github repo of FreeRADIUS this problem is acknowledged and it is fixed in version 3.0.22 of FreeRADIUS. See the remark in the source code of version 3.0.22: "Since version 3.8, the "m" suffix is no longer available."
           
          /*
           * Since version 3.8, the "m" suffix is no longer available.
           * https://bugs.python.org/issue36707
           */
          #if PY_MINOR_VERSION >= 8
          #define LIBPYTHON_LINKER_NAME \
              "libpython" STRINGIFY(PY_MAJOR_VERSION) "." STRINGIFY(PY_MINOR_VERSION) LT_SHREXT
          #else
          #define LIBPYTHON_LINKER_NAME \
              "libpython" STRINGIFY(PY_MAJOR_VERSION) "." STRINGIFY(PY_MINOR_VERSION) "m" LT_SHREXT
          #endif
           
          You can verify this at https://github.com/FreeRADIUS/freeradius-server/compare/release_3_0_21...release_3_0_22 for file src/modules/rlm_python3/rlm_python3.c
           
          Currently I can easily fix this by making a symlink from /usr/lib64/libpython3.9.so to /usr/lib64/libpython3.9m.so, then FreeRADIUS starts without the error. But the real fix would be that Red Hat would provide a more recent version of FreeRADIUS than 3.0.21. Version 3.0.21 has the error with Python version 3.8 and higher and RHEL 9.2 ships Python version 3.9. 
           
          The FreeRADIUS version 3.0.21 dates from March 2020. The "fixed for Python 3.8 and higher" version 3.0.22 dates from May 2021.

      PrivateBin - Because ignorance is bliss

      1.5.1

      PrivateBin is a minimalist, open source online pastebin where the server has zero knowledge of pasted data. Data is encrypted/decrypted in the browser using 256 bits AES. More information on the project page. Red Hat Employee Privacy Statement

              antorres@redhat.com Antonio Torres
              rhn-support-ddas Deepak Das
              Antonio Torres Antonio Torres
              Michal Polovka Michal Polovka
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: