Instantiation of python module fails on 3.0.21
Hi all! We've been running FreeRADIUS 3.0.20 successfully on several Ubuntu 18.04.4 LTS machines. We make use of the rlm_python module. We compile the packages according to https://wiki.freeradius.org/building/Debian-and-Ubuntu For test purposes we install the packages on the same machine that we compile them on. We've recently built packages for FreeRADIUS 3.0.21, took the sample configuration that comes with it and modified it to our local needs (there were hardly any changes necessary between 3.0.20 and 3.0.21). However, when running version 3.0.21, "freeradius -X" gives us: --------8<--------8<--------8<--------8<--------8<-------- [...] # Instantiating module "python" from file /etc/freeradius/mods-enabled/python Python version: 2.7.17 (default, Nov 7 2019, 10:07:09) [GCC 7.4.0] <type 'exceptions.SystemError'> (null argument to internal routine) /etc/freeradius/mods-enabled/python[9]: Instantiation failed for module "python" --------8<--------8<--------8<--------8<--------8<-------- The python version mentioned is correct. Also, rlm_python.so is properly linked against the correct python version: --------8<--------8<--------8<--------8<--------8<-------- # ldd rlm_python.so linux-vdso.so.1 (0x00007ffd10b5f000) libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007fcefce5e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcefca6d000) /lib64/ld-linux-x86-64.so.2 (0x00007fcefd5e3000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fcefc850000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcefc631000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcefc42d000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fcefc22a000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcefbe8c000) --------8<--------8<--------8<--------8<--------8<-------- To rule out configuration migration problems we installed the configuration that runs with version 3.0.20, tested it with 3.0.20, removed version 3.0.20 and installed packages for 3.0.21 while preserving the configuration that is verified to run. The result is the same, the instantiation of the python module fails for 3.0.21 while it works with the same configuration for 3.0.20. As a workaround I was considering building rlm_python3, however, in the 3.0.21 it's not marked as stable in src/modules/stable and it doesn't build by default in the Debian/Ubuntu package build process without modifications. Would other FreeRADIUS admins recommend using rlm_python3? Please let me know if more debugging info is needed. I ran an "strace" but other than the above error message it doesn't seem to yield more usable information. Thanks for your help! Kind regards, Christian Strauf -- Dipl.-Math. Christian Strauf Head of Network Services Department Clausthal Univ. of Technology E-Mail: strauf@rz.tu-clausthal.de Rechenzentrum Web: www.rz.tu-clausthal.de Erzstraße 18 Tel.: +49-5323-72-2086 Fax: -992086 D-38678 Clausthal-Zellerfeld
Christian, We had some fixes on 3.0.21. btw, you could find official packages in https://packages.networkradius.com/ <https://packages.networkradius.com/> -- Jorge Pereira jpereira@freeradius.org
On 16 Apr 2020, at 03:04, Christian Strauf <strauf@rz.tu-clausthal.de> wrote:
Hi all!
We've been running FreeRADIUS 3.0.20 successfully on several Ubuntu 18.04.4 LTS machines. We make use of the rlm_python module. We compile the packages according to
https://wiki.freeradius.org/building/Debian-and-Ubuntu
For test purposes we install the packages on the same machine that we compile them on. We've recently built packages for FreeRADIUS 3.0.21, took the sample configuration that comes with it and modified it to our local needs (there were hardly any changes necessary between 3.0.20 and 3.0.21). However, when running version 3.0.21, "freeradius -X" gives us:
--------8<--------8<--------8<--------8<--------8<-------- [...] # Instantiating module "python" from file /etc/freeradius/mods-enabled/python Python version: 2.7.17 (default, Nov 7 2019, 10:07:09) [GCC 7.4.0] <type 'exceptions.SystemError'> (null argument to internal routine) /etc/freeradius/mods-enabled/python[9]: Instantiation failed for module "python" --------8<--------8<--------8<--------8<--------8<--------
The python version mentioned is correct. Also, rlm_python.so is properly linked against the correct python version:
--------8<--------8<--------8<--------8<--------8<-------- # ldd rlm_python.so linux-vdso.so.1 (0x00007ffd10b5f000) libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007fcefce5e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcefca6d000) /lib64/ld-linux-x86-64.so.2 (0x00007fcefd5e3000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fcefc850000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcefc631000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcefc42d000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fcefc22a000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcefbe8c000) --------8<--------8<--------8<--------8<--------8<--------
To rule out configuration migration problems we installed the configuration that runs with version 3.0.20, tested it with 3.0.20, removed version 3.0.20 and installed packages for 3.0.21 while preserving the configuration that is verified to run. The result is the same, the instantiation of the python module fails for 3.0.21 while it works with the same configuration for 3.0.20.
As a workaround I was considering building rlm_python3, however, in the 3.0.21 it's not marked as stable in src/modules/stable and it doesn't build by default in the Debian/Ubuntu package build process without modifications. Would other FreeRADIUS admins recommend using rlm_python3?
Please let me know if more debugging info is needed. I ran an "strace" but other than the above error message it doesn't seem to yield more usable information. Thanks for your help!
Kind regards, Christian Strauf -- Dipl.-Math. Christian Strauf Head of Network Services Department Clausthal Univ. of Technology E-Mail: strauf@rz.tu-clausthal.de Rechenzentrum Web: www.rz.tu-clausthal.de Erzstraße 18 Tel.: +49-5323-72-2086 Fax: -992086 D-38678 Clausthal-Zellerfeld
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi Jorge,
We had some fixes on 3.0.21. btw, you could find official packages in https://packages.networkradius.com/ <https://packages.networkradius.com/> thanks for the info. I'll give the official packages a go an let you know whether or not I had any luck. I saw the changes made to rlm_python on github but from what I can tell they were only related to debugging output, weren't they?
Kind regards, Christian Strauf -- Dipl.-Math. Christian Strauf Head of Network Services Department Clausthal Univ. of Technology E-Mail: strauf@rz.tu-clausthal.de Rechenzentrum Web: www.rz.tu-clausthal.de Erzstraße 18 Tel.: +49-5323-72-2086 Fax: -992086 D-38678 Clausthal-Zellerfeld
Hi Jorge!
We had some fixes on 3.0.21. btw, you could find official packages in https://packages.networkradius.com/ <https://packages.networkradius.com/> I installed the official packages and get the exact same error. Does it make sense to open an issue on github for this?
Kind regards, Christian Strauf -- Dipl.-Math. Christian Strauf Head of Network Services Department Clausthal Univ. of Technology E-Mail: strauf@rz.tu-clausthal.de Rechenzentrum Web: www.rz.tu-clausthal.de Erzstraße 18 Tel.: +49-5323-72-2086 Fax: -992086 D-38678 Clausthal-Zellerfeld
Hi Jorge,
We had some fixes on 3.0.21. btw, you could find official packages in https://packages.networkradius.com/ <https://packages.networkradius.com/> I just checked, the problem also exists if you use the unmodified sample configuration.
Christian
Hi Christian, can you make a quick test? Could you install the libpython2-dev and see whether that fixes anything? I saw a similar problem with the python3 module. Cheers, Alex El 17/4/20 a las 8:55, Christian Strauf escribió:
Hi Jorge,
We had some fixes on 3.0.21. btw, you could find official packages in https://packages.networkradius.com/ <https://packages.networkradius.com/> I just checked, the problem also exists if you use the unmodified sample configuration.
Christian
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Alejandro Perez-Mendez Technical Specialist (AAA), Trust & Identity Skype alejandro_perez_mendez jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under company number. 05747339, VAT number GB 197 0632 86. Jisc’s registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice
Hi Alex!
can you make a quick test? Could you install the libpython2-dev and see whether that fixes anything? I saw a similar problem with the python3 module. Thanks for the hint. I just checked, it's already installed (which makes sense since I compiled the Debian packages on the same server). Unfortunately it doesn't help.
Christian
Oh, I see the problem, just make sure you actually have a function enabled for the instantiate call. In other words, make sure that second line is not commented. mod_instantiate = ${.module} func_instantiate = instantiate Cheers, Alex El 17/4/20 a las 10:56, Christian Strauf escribió:
Hi Alex!
can you make a quick test? Could you install the libpython2-dev and see whether that fixes anything? I saw a similar problem with the python3 module. Thanks for the hint. I just checked, it's already installed (which makes sense since I compiled the Debian packages on the same server). Unfortunately it doesn't help.
Christian
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Alejandro Perez-Mendez Technical Specialist (AAA), Trust & Identity Skype alejandro_perez_mendez jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under company number. 05747339, VAT number GB 197 0632 86. Jisc’s registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice
Hi Alex!
just make sure you actually have a function enabled for the instantiate call. In other words, make sure that second line is not commented.
mod_instantiate = ${.module} func_instantiate = instantiate Fantastic hint! This works.
I've added a def instantiate(p): pass to my python script and it works! It's a little odd that this wasn't necessary in 3.0.20. Anyhow, it seems to work now. Thanks for your help! Christian
participants (3)
-
Alejandro Perez-Mendez -
Christian Strauf -
Jorge Pereira