(RADIATOR) How many <Handlers> do you have?

miko at yournetplus.com miko at yournetplus.com
Thu Jan 13 02:13:33 CST 2005 

Thanks Hugh, and everyone else :) I am taking all of the advice into 
consideration and may very well be contacting you about contracting some 
design assistance...

Thx,
Miko

Hugh Irvine wrote:
> 
> Hello Miko -
> 
> My general approach in my consulting practice is pretty much as Dave and 
> Frank describe, except that I _do_ tend to use multiple instances of 
> Radiator on multiple hosts, as I find it easier to design and implement 
> (and support).
> 
> However, I have also used the PreClientHook approach with great success 
> - it works very well.
> 
> If you are worried about performance, you can also use a StartupHook to 
> read all the relevant data into memory so that the data is cached and 
> your PreClientHook can then just access the cache. There is an example 
> that I wrote showing how to do something similar in "goodies/hooks.txt".
> 
> Finally, if the majority of your processing is explicit Realms, you can 
> mix Realms and Handlers in the same configuration file as long as you 
> realise that Realms are _always_ evaluated before Handlers. Therefore 
> you can do something like this:
> 
> # define explicit Realms
> 
> <Realm aaaa.com>
>     .....
> </Realm>
> 
> <Realm bbbb.com>
>     .....
> </Realm>
> 
> <Realm cccc.com>
>     .....
> </Realm>
> 
> ......
> 
> # now define Handlers that will only be evaluated if the Realm does not 
> match
> 
> <Handler .....>
>     .....
> </Handler>
> 
> <Handler .....>
>     ......
> </Handler>
> 
> # default Handler if required
> 
> <Handler>
>     ......
> </Handler>
> 
> Note that you _cannot_ use a Realm DEFAULT in the above scenario.
> 
> hope that helps
> 
> regards
> 
> Hugh
> 
> 
> On 12 Jan 2005, at 19:59, miko at yournetplus.com wrote:
> 
>> I had thought about that, but it seemed to me that having an extra SQL 
>> Query run on every authentication and accounting packet would cause a 
>> performance hit, plus it would prevent us from being able to handle 
>> proxying requests if the SQL server for whatever reason stopped 
>> responding.
>>
>> -Miko
>>
>> <----- Original Message ----->
>> From: "Marty Maiers" <martym at yournetplus.com>
>> To: miko at yournetplus.com, randy at yournetplus.com, 
>> duane at yournetplus.com, ryan at yournetplus.com, "'Laura'" 
>> <laura at yournetplus.com>
>> Sent: Wednesday, January 12, 2005 9:53:22 PM
>> Subject: Prism/Filtering
>>
>>> Sounds pretty intense.
>>> Without giving it too much thought, I'll share the following comments.
>>> I agree that a separate Handler for each realm is poor both for
>>> performance reasons and for maintainability. You don't want to be
>>> modifying your config file every 10 minutes because a realm is being
>>> added or removed from your system.
>>> Since most of your complexity is from multiple realms, let's get
>>> specific realms out of the config file. Add a PreProcessingHook which
>>> queries a separate SQL database to find out "what to do" with the realm
>>> of the current packet. Based on the results from the database, have the
>>> hook add one (of hopefully only a few) custom RADIUS Attributes to the
>>> request. Then use one default realm handler. In that Handler, you can
>>> decide whether to proxy or whatever based on that attribute.
>>> Then you can just manage the huge list of realms by changes to the SQL
>>> database, and your config file can remain rather static. Thoughts?
>>> Dave
>>>
>>>> -----Original Message-----
>>>> From: miko at yournetplus.com [mailto:miko at yournetplus.com]
>>>> Sent: Wednesday, January 12, 2005 6:33 AM
>>>> To: Frank Danielson
>>>> Cc: radiator at open.com.au
>>>> Subject: Re: (RADIATOR) How many <Handlers> do you have?
>>>>
>>>> Essentially we operate several radius machines that authenticate from
>>>> major backbone carriers. Each of these machines has anywhere from
>>>
>>> eighty
>>>
>>>> to several hundred realms that it auths, many of which operate
>>>
>>> subrealms
>>>
>>>> as I described previously. Our radius boxes handle these realms in
>>>> different fashions, some are proxied to downstreams and others are
>>>
>>> handled
>>>
>>>> in databases, and some are handled using other authby systems.
>>>>
>>>> Our goal is to merge these systems together so that we do not have to
>>>> maintain as many systems, thus we end up having a few thousand realms
>>>> total that need to be handled... We also auth based on not only realm
>>>
>>> but
>>>
>>>> also prefixes of the username being authed, which is what originally
>>>> prompted me to use handlers...
>>>>
>>>> -Miko
>>>>
>>>> <----- Original Message ----->
>>>> From: Frank Danielson <fdanielson at csky.com>
>>>> To: miko at yournetplus.com, radiator at open.com.au
>>>> Sent: Wednesday, January 12, 2005 6:09:30 PM
>>>> Subject: (RADIATOR) How many <Handlers> do you have?
>>>>
>>>>> Hi Miko-
>>>>>
>>>>> What are you planning to do inside all these handlers? Are you
>>>
>>> proxying
>>>
>>>> the
>>>>
>>>>> requests to a downstream server, authorizing against a database, or
>>>>> something else?
>>>>>
>>>>> Since Hugh has already established that 4000 handlers is not a good
>>>
>>> idea
>>>
>>>> and
>>>>
>>>>> you've established that realms probably won't work either, how about
>>>>
>>>>
>>>> giving
>>>>
>>>>> us the whole scenario and maybe someone on the list will have a good
>>>>
>>>>
>>>> idea or
>>>>
>>>>> has already solved a similar problem?
>>>>>
>>>>> -Frank
>>>>>
>>>>> -----Original Message-----
>>>>> From: miko at yournetplus.com [mailto:miko at yournetplus.com]
>>>>> Sent: Wednesday, January 12, 2005 3:29 AM
>>>>> To: Hugh Irvine
>>>>> Cc: radiator at open.com.au
>>>>> Subject: Re: (RADIATOR) How many <Handlers> do you have?
>>>>>
>>>>>
>>>>> Unfortunately we cannot use SQLRadius or Realm clauses because we
>>>
>>> need
>>>
>>>> to
>>>>
>>>>> be able to support other attributes besides the realm and the realms
>>>>
>>>>
>>>> that
>>>>
>>>>> we have must also support subrealms (ie. sub.realm.com) without the
>>>>> configuration knowing what the sub portion of the realm is. At
>>>
>>> present I
>>>
>>>>> only know to that with regular expressions in a Handler clause...
>>>>>
>>>>> -Miko
>>>>>
>>>>> <----- Original Message ----->
>>>>> From: Hugh Irvine <hugh at open.com.au>
>>>>> To: "miko at yournetplus.com" <miko at yournetplus.com>
>>>>> CC: radiator at open.com.au
>>>>> Sent: Wednesday, January 12, 2005 1:10:15 AM
>>>>> Subject: (RADIATOR) How many <Handlers> do you have?
>>>>>
>>>>>
>>>>>> Hello Miko -
>>>>>>
>>>>>> A configuration with 4000-5000 Handlers is not a good idea.
>>>>>>
>>>>>> If you need to do this because of many target radius proxy hosts I
>>>>>> generally recommend a single Handler with an AuthBy SQLRADIUS
>>>
>>> clause.
>>>
>>>>>> If this is to cope with many different Realms then you should just
>>>
>>> use
>>>
>>>>>> Realm clauses which are _much_ faster than Handlers.
>>>>>>
>>>>>> Perhaps if you give me a bit more detail I can try to make some
>>>>>> suggestions.
>>>>>>
>>>>>> Otherwise we are available on a contract basis for design,
>>>
>>> installation
>>>
>>>>>> and training.
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> Hugh
>>>>>>
>>>>>>
>>>>>> On 11 Jan 2005, at 17:01, miko at yournetplus.com wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Has anyone experienced any issue, or can think of any issue with
>>>>>>> running a large # of Handlers in a config file???
>>>>>>>
>>>>>>> At present we have the potential for having about 4000-5000 in a
>>>
>>> new
>>>
>>>>>>> config I am wanting to implement, but I'd like to know that
>>>
>>> Radiator
>>>
>>>>>>> can handle this before I do it...
>>>>>>>
>>>>>>> -Miko
>>>>>>>
>>>>>>> -- 
>>>>>>> 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 read the reference manual ("doc/ref.html")?
>>>>>> Have you searched the mailing list archive
>>>>>> (www.open.com.au/archives/radiator)?
>>>>>> Have you had a quick look on Google (www.google.com)?
>>>>>> Have you included a copy of your configuration file (no secrets),
>>>>>> together with a trace 4 debug showing what is happening?
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> 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.
>>
>>
> 
> NB:
> 
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive 
> (www.open.com.au/archives/radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
> 

--
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