Hello, I just subscribed so I won't be able to quote properly but I hope at least the message is associated with the right thread (I found it on the web archive of the mailing list). I've been using FreeRADIUS for about 4 year now and it is a wonderful product - there's no question why you're No 1! For the past years of using and developing rlm_perl modules for FreeRADIUS, I've only been astonished and happy because of the new functionalities etc that the development team have been adding to the new releases. This all ended with this crippling of the rlm_perl module in the new 2.1.4 release (btw I downloaded and compiled from source the 2.1.4 release under CentOS 5.2, but radiusd - v says that the version is 2.1.5...). Here are my thoughts on the matter and quotes of the discussion for clarity:
Apostolos Pantsiopoulos wrote:
I noticed that the following directives : ... for perl were not present in the file after the compiling.
Are these directives obsolete?
Yes. The server already has a thread management system. Adding another one for Perl is unnecessary. Removing something which has been working fine (the rlm_perl thread management system) is not a good thing IMHO. It helped me achieve more flexibility and was really powerful.
Apostolos Pantsiopoulos wrote:
Does this mean that in the new behavior I have one perl instance (thread) shared by all the radius threads? And if so, are all the radius requests being processed sequentially by it? Doesn't this degrade the performance?
Possibly, yes.
Or, the module could be updated to have one
perl interpreter per child thread.
This requires that I alter the rlm_perl module code, right?
Yes. Having only one perl instance will have very bad influence on performance in large integrations. I've experienced what happens in this case - the CPU usage of radiusd is very low (<1%) but requests are waiting each other to finish. This causes huge delays (I've seen 2-3 minutes!) and flooding the NAS's logs with RADIUS Server DEAD... RADIUS Server Alive messages.
I've been happily using multiple perl instances to achieve the functionality that I need (like Apostolos Pantsiopoulos) for years now. In my case, I created several rlm_perl instances, each loading different perl applications to take care of different cases depending on the NAS-IP like this: perl instance1 { # This is a large branch => I put higher values for max_clones, start_clones etc but keeping the pool static to avoid reloading the settings from the DB on module instantiation } perl instance2 { # This is another (slightly modified) script which takes care of special circumstances } # ... and now using the wonderful ulang functionality I do the following in ... say accounting switch "%{NAS-IP-Address}" { case '10.250.15.1' { instance1 } case '10.250.17.192' { instance2 } } As far as I could understand from my brief research with google and reading the mailing list, achieving this is now impossible. And I discover this amidst integration. Correct me if I'm wrong, but I'm left with the impression that doing such configurations now requires modifying the rlm_perl's code etc which is not an option. This leaves me with the options to downgrade the FreeRADIUS version or shoot myself in the head ;-). Anyways IMHO this 2.1.4 release is a huge step back. I certainly don't want to insult anyone but why remove functionality which has been working fine for years forcing people rewrite their code (amidst started integrations and projects) to support the new versions limitations! P.S.: Sorry for sending the previous unfinished message, I pressed the wrong key combination