Hi, Just wondering if someone can confirm something for me. The python module only passes the the request attribute list (not the reply, proxy-reply, control lists) to the python script, is that correct? Would it be possible to modify the module to pass the remaining lists to the python code? Thanks in advance, Duarte
Moreover, the request list is a read only list. I wanted to modify the user-name in the authorization function in python, but you cannot, only rlm_perl is able to do that. Yes, if someone could enhance the rlm_python it will be great. I looked at the rlm_python source code, but it is too complex for me. In general, rlm_python seems not very popular in the freeradius world.. few information.. not sure it is no more experimental, performance ??? Bye. Laurent ----- Mail original ----- De: "Duarte Fonseca" <fonseca.duarte@gmail.com> À: freeradius-users@lists.freeradius.org Envoyé: Mercredi 5 Décembre 2012 17:41:19 Objet: Python access to attribute lists Hi, Just wondering if someone can confirm something for me. The python module only passes the the request attribute list (not the reply, proxy-reply, control lists) to the python script, is that correct? Would it be possible to modify the module to pass the remaining lists to the python code? Thanks in advance, Duarte - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 12/05/2012 05:59 PM, laurent.feron@free.fr wrote:
Moreover, the request list is a read only list. I wanted to modify the user-name in the authorization function in python, but you cannot, only rlm_perl is able to do that. Yes, if someone could enhance the rlm_python it will be great. I looked at the rlm_python source code, but it is too complex for me. In general, rlm_python seems not very popular in the freeradius world.. few information.. not sure it is no more experimental, performance
Bear in mind I'm a big fan of Python... Python doesn't really fit FreeRADIUS well. FreeRADIUS is threaded, and Python has the global interpreter lock, which means it doesn't really do concurrency in threads very well. TBH I don't think any of the rlm_$language modules are *that* widely used - rlm_perl has it's own problems, rlm_ruby is, well... ruby. And unlang or conditional SQL processing solve many of the problems. I wonder if a better option wouldn't be something like "rlm_unixsocket" which passes the request down a unix socket in a standard format, and takes the reply in the same way. Then the various interpreters could run "out-of-process". rlm_rest might be another option. All that said, the rlm_python code could certainly be improved. There's no reason it couldn't present a much more pythonic API (and a much more complete one - it should be easy to expose server innards like paircompare and so forth). I might take a look if I get time, but I've got a lot on my plate...
Hi,
I wonder if a better option wouldn't be something like "rlm_unixsocket" which passes the request down a unix socket in a standard format, and takes the reply in the same way. Then the various interpreters could run "out-of-process".
I was thinking about the same thing the other day after the mumblings about removing rlm_perl from FreeRADIUS.....we dotn need that much really. just a way of passing some details into external code and passing some details back (the external code in our case is PERL as its just so darn flexible and extensible...)..... i was thinking of having the PERL code running as a background process like our other PERL code (which removes a lot of issues and means everything can be nicely threaded etc) with some 'exec'd code to throw the values to it and get an answer back...... rlm_rest might be an alternative as you say. whilst I like omelettes...in our case, we've been simmering a slow-cook stew with our RADIUS configurations/adjustments/changes over the years so a few new broken eggs for a quick snack might not be to everyones taste (basically all our local scripts for various servers would have to be rewritten from almost scratch (the joys of PERL being our local modules/subroutines which can just be dropped into the new handler/code) but a unix socket approach would be far more efficient I feel (cue the screams from people with other ideas! ) likewise too busy with other projects/work/issues alan
participants (4)
-
Alan Buxey -
Duarte Fonseca -
laurent.feron＠free.fr -
Phil Mayers