Good morning, I was wondering if anyone has successfully integrated LUA with Redis in freeRADIUS. I am trying to build in a LUA function in /etc/freeradius/mods-enabled/redis that calls for a result from a redis db but I get a syntax error in my LUA {} code :- /etc/freeradius/mods-enabled/redis[108]: Expecting section start brace '{' after "local imei" This is my code block:- lua { function imei_locking { local imei = redis.call('HGET',KEYS[1],'imei') local result = 'false' if imei == ARGV[1] then result = 'true' end return result } } The idea is to reject connections based on the result returned from the LUA call in the authorize {} section. Hope I'm making sense. If anyone can share their ideas, I'd appreciate it. Regards, Gabriel
On Nov 20, 2024, at 1:00 AM, Gabriel Marais <gabriel.j.marais@gmail.com> wrote: I was wondering if anyone has successfully integrated LUA with Redis in freeRADIUS. I am trying to build in a LUA function in /etc/freeradius/mods-enabled/redis
The documentation doesn't say that the redis module supports in-line lug.
that calls for a result from a redis db but I get a syntax error in my LUA {} code :- /etc/freeradius/mods-enabled/redis[108]: Expecting section start brace '{' after "local imei"
This is my code block:-
lua {
Yeah, you can't just invent syntax and have it do what you want. The lua scripts have to be on the redis server before FreeRADIUS can use them. Then, just use normal Redis queries from FreeRADIUS to run the scripts. Alan DeKok.
Hi, On Wed, Nov 20, 2024 at 06:47:15AM -0500, Alan DeKok wrote:
On Nov 20, 2024, at 1:00 AM, Gabriel Marais <gabriel.j.marais@gmail.com> wrote: I was wondering if anyone has successfully integrated LUA with Redis in freeRADIUS. ... The documentation doesn't say that the redis module supports in-line lug.
I needed to extend some of the lua scripts provided in the freeradius source code and used the python3 module for that. So if there is interest, I can provide a stripped down version version how this can be done. There are pitfalls, as with 3.2.x a config reload is not working due to some threading stuff.
The lua scripts have to be on the redis server before FreeRADIUS can use them. Then, just use normal Redis queries from FreeRADIUS to run the scripts.
Ok, there are other ways to do this... Greetings Hermann
On 19/11/2024 08:48, Francis Augusto Medeiros-Logeay via Freeradius-Users wrote:
I think there were some updates on our RHEL 9 machine where I test frreeradius, and now radiusd refuses to run:
radiusd -X Error : tls - libssl version mismatch. built: 30000070 linked: 30200020
I upgraded to 3.2.6, and it didn’t seem to fix.
Hmm, looks like they bumped OpenSSL from 3.0.7 up to 3.2.2 in RHEL 9.5. We build on Rocky9 (latest Docker image is 9.3) which still has 3.0.7.
According to Rocky's release schedule version 9.5 should arrive in November, so when that's out we can rebuild packages against OpenSSL 3.2.
Maybe consider using AlmaLinux images instead? They are pretty quick with official docker images for each minor version. 9.5 is already available.
Any clues on how to fix this?
For the time being, roll back to before the update.
Rolling back wasn’t really an option for us. We have downgraded openssl-libs and the dependencies to the 9.4 versions instead, running for our AlmaLinux servers: # dnf downgrade https://repo.almalinux.org/almalinux/9.4/BaseOS/x86_64/os/Packages/openssl-l... \ https://repo.almalinux.org/almalinux/9.4/BaseOS/x86_64/os/Packages/openssl-3... \ https://repo.almalinux.org/almalinux/9.4/BaseOS/x86_64/os/Packages/libcurl-7... \ https://repo.almalinux.org/almalinux/9.4/BaseOS/x86_64/os/Packages/curl-7.76... \ https://repo.almalinux.org/almalinux/9.4/BaseOS/x86_64/os/Packages/cryptsetu... \ https://repo.almalinux.org/almalinux/9.4/AppStream/x86_64/os/Packages/perl-N... It seems to be working just fine for the moment. p
On 19/11/2024 08:48, Francis Augusto Medeiros-Logeay via Freeradius-Users wrote:
I think there were some updates on our RHEL 9 machine where I test frreeradius, and now radiusd refuses to run:
radiusd -X Error : tls - libssl version mismatch. built: 30000070 linked: 30200020
I upgraded to 3.2.6, and it didn’t seem to fix.
Hmm, looks like they bumped OpenSSL from 3.0.7 up to 3.2.2 in RHEL 9.5. We build on Rocky9 (latest Docker image is 9.3) which still has 3.0.7.
According to Rocky's release schedule version 9.5 should arrive in November, so when that's out we can rebuild packages against OpenSSL 3.2.
Maybe consider using AlmaLinux images instead? They are pretty quick with official docker images for each minor version. 9.5 is already available.
Any clues on how to fix this?
For the time being, roll back to before the update.
Rolling back wasn’t really an option for us. We have downgraded openssl-libs and the dependencies to the 9.4 versions instead, running for our AlmaLinux servers: # dnf downgrade https://repo.almalinux.org/almalinux/9.4/BaseOS/x86_64/os/Packages/openssl-l... \ https://repo.almalinux.org/almalinux/9.4/BaseOS/x86_64/os/Packages/openssl-3... \ https://repo.almalinux.org/almalinux/9.4/BaseOS/x86_64/os/Packages/libcurl-7... \ https://repo.almalinux.org/almalinux/9.4/BaseOS/x86_64/os/Packages/curl-7.76... \ https://repo.almalinux.org/almalinux/9.4/BaseOS/x86_64/os/Packages/cryptsetu... \ https://repo.almalinux.org/almalinux/9.4/AppStream/x86_64/os/Packages/perl-N... It seems to be working just fine for the moment. p
On Thu, 21 Nov 2024, glances.swamp0r--- via Freeradius-Users wrote:
On 19/11/2024 08:48, Francis Augusto Medeiros-Logeay via Freeradius-Users wrote:
I think there were some updates on our RHEL 9 machine where I test frreeradius, and now radiusd refuses to run:
radiusd -X Error : tls - libssl version mismatch. built: 30000070 linked: 30200020
I upgraded to 3.2.6, and it didn’t seem to fix.
Hmm, looks like they bumped OpenSSL from 3.0.7 up to 3.2.2 in RHEL 9.5. We build on Rocky9 (latest Docker image is 9.3) which still has 3.0.7.
According to Rocky's release schedule version 9.5 should arrive in November, so when that's out we can rebuild packages against OpenSSL 3.2.
Maybe consider using AlmaLinux images instead? They are pretty quick with official docker images for each minor version. 9.5 is already available.
Any clues on how to fix this?
For the time being, roll back to before the update.
Or... download the FR kit and build it yourself. Then you're guaranteed to have a version that matches your system and you might even learn something in the process. Some of us have been doing that for over 20 years. -- Dave Funk University of Iowa <dbfunk (at) engineering.uiowa.edu> College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include <std_disclaimer.h> Better is not better, 'standard' is better. B{
In the mods-config/python3 file there is this commented line with no doc. # python_interpreter = "/etc/raddb/bin/python3" I'm not clear whether to ignore it or uncomment it. Is this present to indicate that it is possible to change the default? --------------------------------------------------------- Dan Mullen ---------------------------------------------------------------------- This message, and any attachment(s), is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/electronic-disclaimer. If you are not the intended recipient, please delete this message. For more information about how Bank of America protects your privacy, including specific rights that may apply, please visit the following pages: https://business.bofa.com/en-us/content/global-privacy-notices.html (which includes global privacy notices) and https://www.bankofamerica.com/security-center/privacy-overview/ (which includes US State specific privacy notices such as the http://www.bankofamerica.com/ccpa-notice).
On Nov 21, 2024, at 2:17 PM, Mullen, Daniel J via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
In the mods-config/python3 file there is this commented line with no doc.
# python_interpreter = "/etc/raddb/bin/python3"
I'm not clear whether to ignore it or uncomment it. Is this present to indicate that it is possible to change the default?
There's no mods-config/python3 file in the default distribution. Nothing in the source ever refers to a "python_interpreter" configuration item. Alan DeKok.
On Nov 21, 2024, at 2:17 PM, Mullen, Daniel J via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
In the mods-config/python3 file there is this commented line with no doc.
The correct file is mods-available/python3 Can't imagine anyone added this line post install. It's too specific.
# python_interpreter = "/etc/raddb/bin/python3"
I'm not clear whether to ignore it or uncomment it. Is this present to indicate that it is possible to change the default?
There's no mods-config/python3 file in the default distribution.
Nothing in the source ever refers to a "python_interpreter" configuration item.
Alan DeKok.
--------------------------------------------------------- Dan Mullen ---------------------------------------------------------------------- This message, and any attachment(s), is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/electronic-disclaimer. If you are not the intended recipient, please delete this message. For more information about how Bank of America protects your privacy, including specific rights that may apply, please visit the following pages: https://business.bofa.com/en-us/content/global-privacy-notices.html (which includes global privacy notices) and https://www.bankofamerica.com/security-center/privacy-overview/ (which includes US State specific privacy notices such as the http://www.bankofamerica.com/ccpa-notice).
With FR 3.0.x and Python2, the python module didn't automatically register any system libraries. In 3.2.6 with Python 3.9 (on RHEL9) the python3 module seems to automatically add the sys.path And at the front of the path. These first for are nowhere in my configuration but at runtime, that’s what the app reports as the path. /usr/lib64/python39.zip /usr/lib64/python3.9/lib-dynload /usr/lib64/python3.9/site-packages /usr/lib/python3.9/site-packages # our code /etc/raddb/mods-config/python3 # application specific packages /etc/raddb/lib/python3.9/site-packages And indeed, FR is using the packages out the the /usr/lig64 Is there a way to force the old behavior? Namely that only the paths declared in python_path are included and in the order specified. --------------------------------------------------------- Dan Mullen ---------------------------------------------------------------------- This message, and any attachment(s), is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/electronic-disclaimer. If you are not the intended recipient, please delete this message. For more information about how Bank of America protects your privacy, including specific rights that may apply, please visit the following pages: https://business.bofa.com/en-us/content/global-privacy-notices.html (which includes global privacy notices) and https://www.bankofamerica.com/security-center/privacy-overview/ (which includes US State specific privacy notices such as the http://www.bankofamerica.com/ccpa-notice).
On Nov 22, 2024, at 1:28 AM, Mullen, Daniel J via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
With FR 3.0.x and Python2, the python module didn't automatically register any system libraries.
In 3.2.6 with Python 3.9 (on RHEL9) the python3 module seems to automatically add the sys.path And at the front of the path. These first for are nowhere in my configuration but at runtime, that’s what the app reports as the path.
/usr/lib64/python39.zip /usr/lib64/python3.9/lib-dynload /usr/lib64/python3.9/site-packages /usr/lib/python3.9/site-packages # our code /etc/raddb/mods-config/python3 # application specific packages /etc/raddb/lib/python3.9/site-packages
And indeed, FR is using the packages out the the /usr/lig64
Is there a way to force the old behavior? Namely that only the paths declared in python_path are included and in the order specified.
Hmm... it looks like the python_path is used only if an undocumented "cext_compat = no" flag is set. I don't know enough about the python3 module to say more, tho. But the source code is available, and you can walk through it to see when it sets python_path. Alan DeKok.
On Nov 21, 2024, at 4:08 AM, Hermann.Lauer@uni-heidelberg.de wrote:
I needed to extend some of the lua scripts provided in the freeradius source code
What lua scripts? v3 doesn't come with any lua scripts.
and used the python3 module for that. So if there is interest, I can provide a stripped down version version how this can be done. There are pitfalls, as with 3.2.x a config reload is not working due to some threading stuff.
Configuration reload in v3 only works for a very limited subset of the configuration. Doing reloads is hard. Alan DeKok.
Hi Alan, On Thu, Nov 21, 2024 at 08:06:13AM -0500, Alan DeKok wrote:
On Nov 21, 2024, at 4:08 AM, Hermann.Lauer@uni-heidelberg.de wrote:
I needed to extend some of the lua scripts provided in the freeradius source code
What lua scripts? v3 doesn't come with any lua scripts.
got them from the "master" git branch more than a year ago, where they are embedded in the files src/modules/rlm_redis_ippool/rlm_redis_ippool* in C.
and used the python3 module for that. So if there is interest, I can provide a stripped down version version how this can be done. There are pitfalls, as with 3.2.x a config reload is not working due to some threading stuff.
Configuration reload in v3 only works for a very limited subset of the configuration. Doing reloads is hard.
Yes, so I'm eager to see if and how this will be handled in v4. Thanks a lot and greetings Hermann
participants (6)
-
Alan DeKok -
Dave Funk -
Gabriel Marais -
glances.swamp0r＠icloud.com -
Hermann.Lauer＠uni-heidelberg.de -
Mullen, Daniel J