(RADIATOR) Handling ....
Hugh Irvine
hugh at open.com.au
Wed Jun 30 21:30:45 CDT 2004
Hello Bret, Hello Ingvar, Hello Jaskaran -
The answer is slightly more complex than it would appear at first
glance.
Realms are indeed a sub-class of Handlers, however in many cases they
are to be prefered for performance reasons.
Any situation that deals with many different Realms (read many ISP's)
should use Realms, because the list of Realm clauses is indexed by the
Realm suffix from the username and finding the correct Realm clause
involves a single index lookup (using a Perl hash).
Handlers are indeed much more flexible, but you should avoid using "too
many" Handlers due to the fact that the list of Handlers will be
evaluated one by one in the order they appear in the configuration
file, with each condition checked until a match is found. This is
obviously much more expensive than just doing an index lookup.
I have often found in my consulting work that using different instances
of Radiator can quite often give you the best of both worlds when
dealing with many diverse requirements. Interestingly enough this is
also the approach used by Diameter with the various types of "agents":
proxy, relay, redirect and translation.
Of course you can also take advantage of an SQL database and use the
AuthBy SQLRADIUS clause when dealing with large numbers of Realm-based
targets.
It is our experience that getting started with Realms is usually easier
for most operators, and when they progress to more involved
implementations they usually have enough experience by then to design a
Handler-based configuration successfully. Note that I have seen _many_
more Handler problems than Realm problems, as a cursory perusal of the
mailing list archives will show.
regards
Hugh
On 1 Jul 2004, at 03:06, Bret Jordan wrote:
> That would be better IMHO..
>
> Bret
>
> Jaskaran Singh wrote:
>
>> I agree with that, the docs are a little misleading
>>
>> -----Original Message-----
>> From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au]
>> On
>> Behalf Of Ingvar Berg (LI/EAB)
>> Sent: Wednesday, June 30, 2004 10:19 AM
>> To: radiator at open.com.au
>> Subject: (RADIATOR) Handling ....
>>
>> Wouldn't it be a good idea to adjust the documentation and
>> examples/goodies
>> to use Handlers by default, and just mention that there's a more
>> limited
>> alternative called Realms available? It seems to me that most people
>> start
>> with some simple Realms config and then run into problems when they
>> whant to
>> Handle all those special cases.
>>
>> Just my 2 öre,
>> Ingvar
>>
>>
>>> -----Original Message-----
>>> From: owner-radiator at open.com.au
>>> [mailto:owner-radiator at open.com.au]On
>>> Behalf Of Bret Jordan
>>> Sent: den 24 juni 2004 22:41
>>> Cc: radiator at open.com.au; jsingh at fdu.edu
>>> Subject: Re: (RADIATOR) Handling Accounting Request
>>>
>>>
>>> Yeah, Handlers give you a lot more flexibility and are basically a
>>> drop in replacement for Realms. Just remember to NOT mix Realms and
>>> Handlers in the same config file/server. It is all one way or
>>> another.
>>> Bret
>>>
>>> Terry Simons wrote:
>>>
>>>
>>>> I second that. ;-)
>>>>
>>>> We did the same.
>>>>
>>>> On Jun 24, 2004, at 12:10 PM, Dave Kitabjian wrote:
>>>>
>>>>
>>>>> We got to that point, too, a while ago, and you just have
>>> to bite the
>>>
>>>>> bullet and switch your Realms to Handlers and use Handlers for
>>>>> everything going forward.
>>>>>
>>>>> The good news is that they work great!
>>>>>
>>>>> Dave
>>>>> :)
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jaskaran Singh [mailto:jsingh at fdu.edu]
>>>>>> Sent: Thursday, June 24, 2004 12:46 PM
>>>>>> To: 'Hugh Irvine'
>>>>>> Cc: radiator at open.com.au
>>>>>> Subject: RE: (RADIATOR) Handling Accounting Request
>>>>>>
>>>>>> Hi Hugh
>>>>>> I don't wish to mix handlers and realms in my configuration file
>>>>>>
>>>>> unless
>>>>>
>>>>>
>>>>>> you
>>>>>> advise me to do so, as I am using <Realms> in my
>>> configuration file
>>>
>>>>> and
>>>>>
>>>>>
>>>>>> have
>>>>>> not used any <handler> so far. Is there a separate
>>> approach you can
>>>
>>>>>> advise?
>>>>>> Thanks
>>>>>> Jack
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: owner-radiator at open.com.au
>>> [mailto:owner-radiator at open.com.au]
>>>
>>>>> On
>>>>>
>>>>>
>>>>>> Behalf Of Hugh Irvine
>>>>>> Sent: Tuesday, June 22, 2004 2:02 AM
>>>>>> To: jsingh at fdu.edu
>>>>>> Cc: radiator at open.com.au
>>>>>> Subject: Re: (RADIATOR) Handling Accounting Request
>>>>>>
>>>>>>
>>>>>> Hello Jaskaran -
>>>>>>
>>>>>> The usual way to do this is with Handlers:
>>>>>>
>>>>>> # deal with accounting requests
>>>>>>
>>>>>> <Handler Request-Type = Accounting-Request>
>>>>>> .....
>>>>>> </Handler>
>>>>>>
>>>>>> # deal with authentication requests
>>>>>>
>>>>>> <Handler>
>>>>>> .....
>>>>>> </Handler>
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> Hugh
>>>>>>
>>>>>>
>>>>>> On 22 Jun 2004, at 05:12, Jaskaran Singh wrote:
>>>>>>
>>>>>>
>>>>>>> Hi
>>>>>>> How do you handle just an incoming accounting request from the
>>>>>>> configuration point of view, My point being to
>>> understand that this
>>>
>>>>> is
>>>>>
>>>>>
>>>>>>> just
>>>>>>> an accounting request and logging it in the database?
>>>>>>> thanks
>>>>>>>
>>>>>>> Jaskaran Singh
>>>>>>> University Systems & Security
>>>>>>> Fairleigh Dickinson University
>>>>>>> 1000 River Road, Mail Stop TBH1-01
>>>>>>> Teaneck, NJ 07666
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Archive at http://www.open.com.au/archives/radiator/
>>>>>>> Announcements on radiator-announce at open.com.au
>>>>>>> To unsubscribe, email 'majordomo at open.com.au' with
>>>>>>> 'unsubscribe radiator' in the body of the message.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> NB: have you included a copy of your configuration file
>>> (no secrets),
>>>
>>>>>> together with a trace 4 debug showing what is happening?
>>>>>>
>>>>>> --
>>>>>> Radiator: the most portable, flexible and configurable
>>> RADIUS server
>>>
>>>>>> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
>>>>>> -
>>>>>> Nets: internetwork inventory and management - graphical,
>>> extensible,
>>>
>>>>>> flexible with hardware, software, platform and database
>>> independence.
>>>
>>>>>> -
>>>>>> CATool: Private Certificate Authority for Unix and
>>> Unix-like systems.
>>>
>>>>>> --
>>>>>> Archive at http://www.open.com.au/archives/radiator/
>>>>>> Announcements on radiator-announce at open.com.au
>>>>>> To unsubscribe, email 'majordomo at open.com.au' with
>>>>>> 'unsubscribe radiator' in the body of the message.
>>>>>>
>>>>>> --
>>>>>> Archive at http://www.open.com.au/archives/radiator/
>>>>>> Announcements on radiator-announce at open.com.au
>>>>>> To unsubscribe, email 'majordomo at open.com.au' with
>>>>>> 'unsubscribe radiator' in the body of the message.
>>>>>>
>>>>>
>>>>> --
>>>>> Archive at http://www.open.com.au/archives/radiator/
>>>>> Announcements on radiator-announce at open.com.au
>>>>> To unsubscribe, email 'majordomo at open.com.au' with
>>>>> 'unsubscribe radiator' in the body of the message.
>>>>>
>>>> --
>>>> Archive at http://www.open.com.au/archives/radiator/
>>>> Announcements on radiator-announce at open.com.au
>>>> To unsubscribe, email 'majordomo at open.com.au' with
>>>> 'unsubscribe radiator' in the body of the message.
>>>>
>>>>
>>> --
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Bret Jordan Dean's Office
>>> Director of Networking College of Engineering
>>> 801.585.3765 University of Utah
>>> jordan at coe.utah.edu
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>> --
>>> Archive at http://www.open.com.au/archives/radiator/
>>> Announcements on radiator-announce at open.com.au
>>> To unsubscribe, email 'majordomo at open.com.au' with
>>> 'unsubscribe radiator' in the body of the message.
>>>
>>>
>>
>> --
>> Archive at http://www.open.com.au/archives/radiator/
>> Announcements on radiator-announce at open.com.au
>> To unsubscribe, email 'majordomo at open.com.au' with
>> 'unsubscribe radiator' in the body of the message.
>>
>> --
>> Archive at http://www.open.com.au/archives/radiator/
>> Announcements on radiator-announce at open.com.au
>> To unsubscribe, email 'majordomo at open.com.au' with
>> 'unsubscribe radiator' in the body of the message.
>>
>>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Bret Jordan Dean's Office
> Director of Networking College of Engineering
> 801.585.3765 University of Utah
> jordan at coe.utah.edu
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>
NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list