(RADIATOR) radiator hooks

Hugh Irvine hugh at open.com.au
Fri Jun 10 19:09:45 CDT 2005


Salut Laurent -

I tend to use an Identifier in the Realm or Handler for this sort of  
thing as I find it easier to understand:

<AuthBy RADIUS>
   Host foo_radius
   ReplyHook file:myhook.pl
</AuthBy>

<AuthBy RADIUS>
   Host bar_radius
   ReplyHook file:myhook.pl
</AuthBy>

<Realm foo_realm>
   Identifier foo_realm
   AuthBy foo_client
</Realm>

<Realm bar_realm>
   Identifier bar_realm
   AuthBy bar_client
</Realm>

and then your hook code can check the Identifier in the Realm (or  
Handler) as shown in the examples in "goodies/hooks.txt".

BTW - you can also do lots of these sorts of things with a single  
Handler and a single AuthBy SQLRADIUS clause that gets all of the  
target proxy host information out of an SQL database.

regards

Hugh


On 11 Jun 2005, at 00:13, PREVOSTO, Laurent wrote:

> Bonjour,
>
> Well i have this quite complex hook called myhook.pl
>
> And my conf looks like this
>
> <AuthBy RADIUS>
>   Identifier foo_client
>   Host foo_radius
>   ReplyHook file:myhook.pl
> </AuthBy>
>
> <AuthBy RADIUS>
>   Identifier bar_client
>   Host bar_radius
>   ReplyHook file:myhook.pl
> </AuthBy>
>
> <Realm foo_realm>
>   AuthBy foo_client
> </Realm>
>
> <Realm bar_realm>
>   AuthBy bar_client
> </Realm>
>
> But inside of myhook.pl there is something that depends on the  
> context, (ie the ISP I forward to).
> And since it's quite complex I don't want to have to maintain a  
> foohook.pl, barhook.pl, etc.
> And there are many realms/handlers that can lead to those AuthBy  
> clauses so using User-Name is not a good idea either.
> I know I could use a dumb attribute but I was wondering if there  
> was a cleaner way to do so...
>
>
> Regards
>
> Laurent
>
>
>> -----Message d'origine-----
>> De : Hugh Irvine [mailto:hugh at open.com.au]
>> Envoyé : vendredi 10 juin 2005 03:19
>> À : PREVOSTO, Laurent
>> Cc : radiator at open.com.au
>> Objet : Re: (RADIATOR) radiator hooks
>>
>>
>> Salut Laurent -
>>
>> Not all AuthBy clauses support hooks inside them, and the other hooks
>> are called either before all the AuthBy clauses are called, or after
>> all the AuthBy clauses are called. Note that you could use the
>> "AddToRequest" parameter to add whatever you wish to a request packet
>> as it traverses an AuthBy clause. I have used this approach in the
>> past with great success.
>>
>> What exactly are you wanting to do?
>>
>> hope that helps
>>
>> regards
>>
>> Hugh
>>
>>
>> On 10 Jun 2005, at 02:00, PREVOSTO, Laurent wrote:
>>
>>
>>> Hi,
>>>
>>> All this makes me wondering :
>>> Is there a way to retrieve, inside of a hook, the name of the
>>> AuthBy clause that triggered it, something like $p->{AuthBy}->
>>> {Identifier} ?
>>>
>>> Regards
>>>
>>> laurent
>>>
>>>
>>>
>>>> -----Message d'origine-----
>>>> De : owner-radiator at open.com.au [mailto:owner-
>>>> radiator at open.com.au] De la
>>>> part de Jason Stechschulte
>>>> Envoyé : vendredi 3 juin 2005 01:30
>>>> À : radiator at open.com.au
>>>> Objet : (RADIATOR) radiator hooks
>>>>
>>>> We are getting ready to a sputnik control center system on our
>>>> network,
>>>> and as a result of this, I need to be able to update a user's
>>>> information when an Acct-Status-Type = Stop is received.  Which of
>>>> the
>>>> hooks should I use to accomplish this?
>>>>
>>>> I have tried preauth and postauth.  They seem to run when a stop
>>>> record
>>>> is sent, but I can't get any useful information.  I have even tried
>>>> using excerpts from th examples with no luck.  Right now I have
>>>> this as
>>>> a PostAuthHook:
>>>>
>>>> sub {
>>>>    my $p = ${$_[0]};
>>>>    my $rp = ${$_[1]};
>>>>    my $result = ${$_[2]};
>>>>
>>>>    my $identifier;
>>>>
>>>>    if (($result == $main::ACCEPT) && ($identifier = $p->{Client}-
>>>>
>>>>
>>>>> {Identifier})) {
>>>>>
>>>>>
>>>>       &main::log($main::LOG_DEBUG, "Jason's Client Identifier =
>>>> $identifier");
>>>>    }
>>>>
>>>>    return;
>>>> }
>>>>
>>>>
>>>> This snippet came for the goodies/hooks.txt file.  I'm not seeing
>>>> anything enter the log file even though I have trace set to 5.  Is
>>>> there
>>>> something specific I need to set to be able to write to logs
>>>> within the
>>>> hook?
>>>>
>>>> Instead of having it log, I have tried to just get it to write to
>>>> a file
>>>> in the /tmp dir.  When I do this, It simply writes:
>>>>
>>>> Jason's Client Identifier =
>>>>
>>>> And $identifier is always blank.  I have it simply append to the
>>>> file so
>>>> I can see every time it is ran what the results are, and I'm always
>>>> unsuccessful at filling $identifier.
>>>>
>>>> I'm hoping this is just something simple I'm overlooking.  By  
>>>> the way
>>>> are there any docs that cover writing hooks for radiator?  The only
>>>> thing I have found besides the goodies/hooks.txt file is this:
>>>>
>>>> http://www.open.com.au/radiator/ref.html#pgfId=319543
>>>>
>>>> The examples in goodies/hooks.txt I can't seem to get working  
>>>> and the
>>>> information at the page above doesn't really explain what
>>>> variables are
>>>> available.  Just wondering if there is somewhere that it explains
>>>> it a
>>>> little more in depth.
>>>>
>>>> --
>>>> Jason Stechschulte
>>>> Network Administrator
>>>> West Central Ohio Internet Link
>>>> Lima, OH USA
>>>>
>>>> --
>>>> 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.
>>
>


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