rlm_perl behavior

[Borislav Dimitrov]

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