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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
