questions about module rlm_perl
Working with version 2.2.6, two questions about rlm_perl, perhaps these belong on the developers list? 1: Why is this module unable to set items on the CONFIG list? Looking in the source code rlm_perl.c at function rlmperl_call, the hashes RAD_REPLY,RAD_CHECK,RAD_CONFIG,RAD_REQUEST,RAD_REQUEST_PROXY and RAD_REQUEST_PROXY_REPLY are all pre-loaded with the value pairs from the corresponding lists before the perl subroutine (e.g. authorize) is called. After the subroutine returns, all of these hashes are examined and the values put back into the radiusd value pairs, except RAD_CONFIG. I have worked around it, but why can't this module do this? 2: The detach subroutine is a placebo. It doesn't get called during SIGHUP processing because in main/modules.c, before reloading a module, the code checks to see if the RLM_TYPE_HUP_SAFE flag is set. rlm_perl.c does not set this flag. There are some sketchy areas of the perl_detach function so maybe this didn't work or caused crashes? Again, I can work around it but it would have been nice to hook SIGHUP and take certain actions, e.g. suppose your Perl module has additional config stuff that needs to be reloaded.
On 19 Feb 2015, at 14:39, HAKNER J <hak@cooper.edu> wrote:
Working with version 2.2.6, two questions about rlm_perl, perhaps these belong on the developers list?
1: Why is this module unable to set items on the CONFIG list? Looking in the source code rlm_perl.c at function rlmperl_call, the hashes RAD_REPLY,RAD_CHECK,RAD_CONFIG,RAD_REQUEST,RAD_REQUEST_PROXY and RAD_REQUEST_PROXY_REPLY are all pre-loaded with the value pairs from the corresponding lists before the perl subroutine (e.g. authorize) is called. After the subroutine returns, all of these hashes are examined and the values put back into the radiusd value pairs, except RAD_CONFIG. I have worked around it, but why can't this module do this?
It does, in v3.0.x.
2: The detach subroutine is a placebo. It doesn't get called during SIGHUP processing because in main/modules.c, before reloading a module, the code checks to see if the RLM_TYPE_HUP_SAFE flag is set. rlm_perl.c does not set this flag. There are some sketchy areas of the perl_detach function so maybe this didn't work or caused crashes? Again, I can work around it but it would have been nice to hook SIGHUP and take certain actions, e.g. suppose your Perl module has additional config stuff that needs to be reloaded.
Sure. Feel free to add the flag and experiment. I recommend working with the v3.0.x branch, as v2.2.x is in permanent feature freeze. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 19-02-15 20:39, HAKNER J wrote:
Working with version 2.2.6, two questions about rlm_perl, perhaps these belong on the developers list?
1: Why is this module unable to set items on the CONFIG list? Looking in the source code rlm_perl.c at function rlmperl_call, the hashes RAD_REPLY,RAD_CHECK,RAD_CONFIG,RAD_REQUEST,RAD_REQUEST_PROXY and RAD_REQUEST_PROXY_REPLY are all pre-loaded with the value pairs from the corresponding lists before the perl subroutine (e.g. authorize) is called. After the subroutine returns, all of these hashes are examined and the values put back into the radiusd value pairs, except RAD_CONFIG. I have worked around it, but why can't this module do this?
The hashes RAD_CONFIG and RAD_CHECK are actually loaded with the same values. from rlm_perl.c: 697: rad_check_hv = get_hv("RAD_CHECK",1); 698: rad_config_hv = get_hv("RAD_CONFIG",1); 705: perl_store_vps(request->config_items, rad_check_hv); 707: perl_store_vps(request->config_items, rad_config_hv); Later in this function, the value of rad_check_hv is written back: 777: if ((get_hv_content(rad_check_hv, &vp)) > 0 ) { 778: pairfree(&request->config_items); 779: request->config_items = vp; But this does not happen with the RAD_CONFIG/rad_config_hv (if that would happen, we'd have the same problem for RAD_CHECK). RAD_CHECK has been removed in master, but hasn't been backported to 3.0.x because it will break compatibility. A short log of the changes can be found at https://github.com/FreeRADIUS/freeradius-server/pull/715 -- Herwin Weststrate
participants (3)
-
Arran Cudbard-Bell -
hak＠cooper.edu -
Herwin Weststrate