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

Hugh Irvine hugh at open.com.au
Wed Jan 12 22:08:28 CST 2005 

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?

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