(RADIATOR) %{Handler:name}

Mariano Absatz radiator at lists.com.ar
Fri Sep 13 13:00:07 CDT 2002 

El 13 Sep 2002 a las 8:35, Hugh Irvine escribió:

> 
> Hello Mariano -
> 
> As mentioned in my previous mail, the prefered way to deal with large 
> numbers of proxy targets is with the AuthBy SQLRADIUS clause.
I had read that... I have a couple of "buts"... this is a front-end used, 
among other things, to profit from <AuthBy RADIUS> & friends' non-
blockingness, so I'm a bit unwilling to SQL here... besides, <AuthBy 
SQLRADIUS> doesn't seem to support volume-balance or load-balance... I didn't 
read the sources, but that would be a nice 3.2 addition, wouldn't it Mike?

> 
> Otherwise, if you want to do fancy things such as you show below, you 
> should use a hook (examples in "goodies/hooks.txt"). And it would 
> probably be best to set a pseudo-attribute in the request packet that 
> would then be used in the AuthBy clause.
Can't I do it via an "AddToRequest" in the <Handler>? 
(http://www.open.com.au/radiator/ref.html#pgfId=428093) I can Perl, but, 
especially when it is for a customer, I'd rather do it cleanly in the config 
file...

> 
> GlobalVars as the name implies are Global parameters that are set at the 
> top level of the configuration file (or on the command line at run 
> time). They should be used for static data only.
OK.

> 
> regards
> 
> Hugh
> 
> 
> On Thursday, September 12, 2002, at 11:30 PM, Mariano Absatz wrote:
> 
>> El 10 Sep 2002 a las 9:27, Hugh Irvine escribió:
>>
>>>
>>> Hello Mariano -
>>>
>>> The way that Radiator is designed allows you to specify a single AuthBy
>>> clause and call it from multiple Handlers, using special characters for
>>> the parameters, rather than specifying many different AuthBy clauses.
>>> The special characters most often used are GlobalVars that have been
>>> defined in the configuration file itself, or passed in from the command
>>> line.
>> But how could I parametrize them on a handler by handler basis within 
>> the
>> same config file...
>>
>> As far as I see, the "AuthBy <Identifier-name>" doesn't allow any 
>> parameters
>> to be passed from the <Handler> to the <AuthBy>... or does it?
>>
>> What else (besides "Identifier") can I use in a %{Handler:name} within 
>> an
>> AuthBy?
>>
>> What is the "scope" of GlobalVar and when are they set?
>>
>> That is, if I have the following:
>> ======================================================
>> <Handler xxxx>
>> 	Identifier foo
>> 	DefineFormattedGlobalVar host abc
>> 	AuthBy MyAuthby
>> </Handler>
>>
>> <Handler yyyy>
>> 	Identifier bar
>> 	DefineFormattedGlobalVar host xyz
>> 	AuthBy MyAuthby
>> </Handler>
>>
>> <AuthBy Radius>
>> 	Identifier MyAuthby
>> 	Host %{GlobalVar:host}
>> </AuthBy>
>> ======================================================
>> Will it proxy to host abc if it comes from handler xxxx and to host xyz 
>> if it
>> comes from handler yyyy?
>>
>>>
>>> Note that for proxy radius targets, Radiator now supports the AuthBy
>>> SQLRADIUS clause that allows you to maintain your target hosts in an 
>>> SQL
>>> database.
>>>
>>> regards
>>>
>>> Hugh
>>>
>>>
>>> On Tuesday, September 10, 2002, at 06:16 AM, Mariano Absatz wrote:
>>>
>>>> El 6 Sep 2002 a las 9:42, Hugh Irvine escribió:
>>>>
>>>>>
>>>>> Hello Mariano -
>>>>>
>>>>> I'm afraid I dont quite understand what you are wanting to do.
>>>>>
>>>>> Could you give me a bit more detail?
>>>> Yup.
>>>>
>>>> I'm trying to generalize the way I write very similar proxies where
>>>> maybe the only thing that
>>>> changes is the proxied hosts/ports and where I log accounting
>>>> failures...
>>>>
>>>> Since this stuff goes in a different <AuthBy Radius> (or <AuthBy
>>>> LOADBALANCE> for that
>>>> matter), I want to name (via "Identifier") each AuthBy and be able to
>>>> recall that name within
>>>> the AuthBy...
>>>>
>>>> In the manual 
>>>> (http://www.open.com.au/radiator/ref.html#pgfId=291148) I
>>>> see that I can find
>>>> out which client triggered a clause (%{Client:name}) and which handler
>>>> did so
>>>> (%{Handler:name}), but I might have several clients and several
>>>> handlers going to the same
>>>> AuthBy and the AuthBy itself would be the selector.
>>>>
>>>> Let's go by example...
>>>>
>>>> Suppose I currently have the following in my config file:
>>>>
>>>> =======================START OF (portion of)
>>>> RADIUS.CFG======================
>>>> <AuthBy LOADBALANCE>
>>>> 	Identifier Kind01
>>>>
>>>> 	Retries 1
>>>>         <Host 22.33.44.55>
>>>> 		Secret aaaa
>>>> 		AuthPort 1111
>>>> 		AcctPort 2222
>>>> 	</Host>
>>>> 	<Host 22.33.44.66>
>>>> 		Secret asdf
>>>> 		AuthPort 2321
>>>> 		AcctPort 1234
>>>> 	</Host>
>>>>
>>>> 	AcctFailedLogFileName %L/ACCT-LOST/Kind01/%Y-%m-%d.log
>>>> </AuthBy>
>>>>
>>>> <AuthBy LOADBALANCE>
>>>> 	Identifier Kind02
>>>>
>>>> 	Retries 3
>>>>         <Host 22.33.44.55>
>>>> 		Secret bbbb
>>>> 		AuthPort 2231
>>>> 		AcctPort 2311
>>>> 	</Host>
>>>> 	<Host 22.33.44.66>
>>>> 		Secret qwert
>>>> 		AuthPort 3333
>>>> 		AcctPort 4444
>>>> 	</Host>
>>>>
>>>> 	AcctFailedLogFileName %L/ACCT-LOST/Kind02/%Y-%m-%d.log
>>>> </AuthBy>
>>>> ========================END OF (portion of)
>>>> RADIUS.CFG=======================
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I would like to change this to:
>>>>
>>>>
>>>> ======================START OF (portion of)
>>>> NEWRADIUS.CFG====================
>>>> <AuthBy LOADBALANCE>
>>>> 	Identifier Kind01
>>>>
>>>> 	include %D/Retries%{AuthName:Identifier}.cfg
>>>> 	include %D/Hosts%{AuthName:Identifier}.cfg
>>>>
>>>> 	AcctFailedLogFileName %L/ACCT-
>>>> LOST/%{AuthName:Identifier}/%Y-%m-%d.log
>>>> </AuthBy>
>>>>
>>>> <AuthBy LOADBALANCE>
>>>> 	Identifier Kind02
>>>>
>>>> 	include %D/Retries%{AuthName:Identifier}.cfg
>>>> 	include %D/Hosts%{AuthName:Identifier}.cfg
>>>>
>>>> 	AcctFailedLogFileName %L/ACCT-
>>>> LOST/%{AuthName:Identifier}/%Y-%m-%d.log
>>>> </AuthBy>
>>>> =======================END OF (portion of)
>>>> NEWRADIUS.CFG=====================
>>>>
>>>> ======================START OF RetriesKind01.cfg====================
>>>> Retries 1
>>>> =======================END OF RetriesKind01.cfg=====================
>>>>
>>>> ======================START OF HostsKind01.cfg====================
>>>> <Host 22.33.44.55>
>>>> 	Secret aaaa
>>>> 	AuthPort 1111
>>>> 	AcctPort 2222
>>>> </Host>
>>>> <Host 22.33.44.66>
>>>> 	Secret asdf
>>>> 	AuthPort 2321
>>>> 	AcctPort 1234
>>>> </Host>
>>>> =======================END OF HostsKind01.cfg=====================
>>>>
>>>> ======================START OF RetriesKind02.cfg====================
>>>> Retries 3
>>>> =======================END OF RetriesKind02.cfg=====================
>>>>
>>>> ======================START OF HostsKind02.cfg====================
>>>> <Host 22.33.44.55>
>>>> 	Secret bbbb
>>>> 	AuthPort 2231
>>>> 	AcctPort 2311
>>>> </Host>
>>>> <Host 22.33.44.66>
>>>> 	Secret qwert
>>>> 	AuthPort 3333
>>>> 	AcctPort 4444
>>>> </Host>
>>>> =======================END OF HostsKind02.cfg=====================
>>>>
>>>>
>>>>
>>>> Although this leads to a profussion of files, they are all parsed at
>>>> startup and this allows
>>>> me to modify things on a per AuthBy basis and keep it clean... Maybe
>>>> give some people the
>>>> possibility to edit some files and other people to edit other files...
>>>>
>>>> I might be dumb or crazy... but this kind of things helped me a lot in
>>>> the past for keeping
>>>> config files clean and ordered...
>>>>
>>>>>
>>>>> thanks
>>>>>
>>>>> Hugh
>>>>>
>>>>>
>>>>> On Friday, September 6, 2002, at 07:26 AM, Mariano Absatz wrote:
>>>>>
>>>>>> Hi Hugh, long time no see...
>>>>>>
>>>>>> I'm planning an installation with a bunch of front-end Radiator
>>>>>> proxies
>>>>>> (using <AuthBy LOADBALANCE>) to an(other) bunch of Radiator back-end
>>>>>> servers
>>>>>> that do the actual authentication against SQL servers.
>>>>>>
>>>>>> Now, the front-end farm has the "dispatching" intelligence and the
>>>>>> back-end,
>>>>>> the authentication intelligence...
>>>>>>
>>>>>> By "dispatching" I mean:
>>>>>> "if it comes from such and such a NAS authenticate using of these
>>>>>> back-end
>>>>>> servers"
>>>>>> "if the realm matches xxx authenticate against these bunch of
>>>>>> back-ends"
>>>>>> etc...
>>>>>>
>>>>>> I'm trying to generalize as much as possible and want to have short
>>>>>> and
>>>>>> easily manteinable config files, so I'm doing a bunch of identfied
>>>>>> AuthBy's
>>>>>> like this:
>>>>>>
>>>>>> <AuthBy LOADBALANCE>
>>>>>> 	Identifier Kind01
>>>>>>
>>>>>> 	include %{GlobalVar:ConfigDir}/RetriesKind01.cfg
>>>>>> 	include %{GlobalVar:ConfigDir}/HostsKind01.cfg
>>>>>>
>>>>>> 	AcctFailedLogFileName %L/ACCT-LOST/Kind01/%Y-%m-%d.log
>>>>>> </AuthBy>
>>>>>>
>>>>>> This would be the AuthBy to use for the "Kind01" kind of handlers...
>>>>>>
>>>>>> Is there a way to have a "per AuthBy" special that has the "AuthBy"
>>>>>> Identfier? That is... a kind of "%{LocalVar:xxxx}" where the 
>>>>>> locality
>>>>>> is wrt
>>>>>> the AuthBy...
>>>>>>
>>>>>> Would %{Handler:Identifier} do that? or that would give me the
>>>>>> Identifier of
>>>>>> the Handler that called this AuthBy?
>>>>>>
>>>>>> Otherwise, would something along the lines of this work?:
>>>>>>
>>>>>> <AuthBy LOADBALANCE>
>>>>>> 	DefineFormattedGlobalVar KIND Kind01
>>>>>> 	Identifier %{GlobalVar:KIND}
>>>>>>
>>>>>> 	include %{GlobalVar:ConfigDir}/Retries%{GlobalVar:KIND}.cfg
>>>>>> 	include %{GlobalVar:ConfigDir}/Hosts%{GlobalVar:KIND}.cfg
>>>>>>
>>>>>> 	AcctFailedLogFileName %L/ACCT-LOST/%{GlobalVar:KIND}/%Y-%m-%d.log
>>>>>> </AuthBy>
>>>>>>
>>>>>> <AuthBy LOADBALANCE>
>>>>>> 	DefineFormattedGlobalVar KIND Kind02
>>>>>> 	Identifier %{GlobalVar:KIND}
>>>>>>
>>>>>> 	include %{GlobalVar:ConfigDir}/Retries%{GlobalVar:KIND}.cfg
>>>>>> 	include %{GlobalVar:ConfigDir}/Hosts%{GlobalVar:KIND}.cfg
>>>>>>
>>>>>> 	AcctFailedLogFileName %L/ACCT-LOST/%{GlobalVar:KIND}/%Y-%m-%d.log
>>>>>> </AuthBy>
>>>>>>
>>>>>>
>>>>>> TIA.


--
Mariano Absatz
El Baby
----------------------------------------------------------
Pentiums melt in your PC, not in your hand. 


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