(RADIATOR) creative AUTHBY SQLRADIUS?
Hugh Irvine
hugh at open.com.au
Mon Apr 15 19:16:26 CDT 2002
Hello Steve -
There are some extensions to the AuthBy SQLRADIUS clause in Radiator 3.0
which should support your requirements. However, as mentioned in my previous
mail, I would prefer to see the results of your testing using a simple
default setup before going any further down this path. I think you will agree
that if the results of a simple test are slower than what you are doing
currently there is no point in pursuing this avenue.
regards
Hugh
On Tue, 16 Apr 2002 00:35, Steve Katen wrote:
> Hugh,
>
> I apologize. I did not type my request correctly. I wanted to speed up
> the evaluation of a long list of Handlers. So yes, you are correct.
>
> So what about the below two questions? If I can't dynamically load IP
> Adresses or AllowInReply and AddToReply then this is not a feasible
> option. So if I am going to test I would like to get those working
> correctly before testing. So how would I get those two as part of an
> AUTHBY SQLRADIUS.
>
> 2) Dynamically load the IP address that is allocated based on the
> replyHook? Currently the IP address is allocated via the Handler. I need
> a way to pick the IP address out of different pools in the AUTHBY
> SQLRADIUS. The table that I am reading everything from the HostSelect has
> a field called POOL which has the POOL name and reference to a
> PoolHint. How do I link those together?
>
> 3) Dynamically load the AllowInReply and AddToReply attributes? As you see
> in the first AUTHBY RADIUS the attributes are there. However, in the
> AUTHBY SQLRADIUS they are not. They would need tobe assigned by the
> DNIS. The table that I am reading everything from the HostSelect has a
> field called FILTER which has the AllowInReply and AddToReply
> attributes. How do I link those together?
>
>
> katen
>
> At 12:30 PM 4/13/2002 +1000, Hugh Irvine wrote:
> >Hello Steve -
> >
> >I think you have misunderstood my suggestion. Using an AuthBy SQLRADIUS
> >clause will not speed up proxy operation - this is determined by the
> > length of time a given proxy target takes to respond. You question was
> > whether there was some way to speed up the evaluation of a long list of
> > Handlers based on Called-Station-Id, and my suggestions were to
> > investigate either the AuthBy SQLRADIUS clause, or the CalledStationId.pm
> > module (contained in the goodies directory). You will have to do some
> > testing to ascertain whether or not either of these will speed up the
> > overall operation. I suggest you try a simple example using the default
> > configuration to see how long it takes compared to your current setup.
> >
> >In answer to your questions below,
> >
> >1. you can specify a default host in the AuthBy SQLRADIUS clause - this is
> >just a warning, not an error
> >
> >yes you need to specify the database with the usual DBSource, DBUsername
> > and DBSource lines
> >
> >For the other questions, I think you need to do the testing described
> > above first to see whether or not the idea is worth pursuing.
> >
> >regards
> >
> >Hugh
> >
> >On Sat, 13 Apr 2002 02:11, Steve Katen wrote:
> > > maybe this isn't that creative, but i cannot seem to get the logic to
> > > work. I have an AUTHBY RADIUS that works perfectly. However, it is
> > > too slow. To make it faster Hugh told me to try the AUTHBY SQLRADIUS
> > > idea, and so here I am.
> > >
> > > I need an AUTHBY SQLRADIUDS / HostSelect that will be able to handle
> > > the AUTHBY RADIUS below:
> > >
> > > <AuthBy RADIUS>
> > > Identifier CheckRemoteRadius
> > > IgnoreAccounting
> > > IgnoreReplySignature
> > > ServerHasBrokenAddresses
> > > RejectEmptyPassword
> > > NoForwardAccounting
> > > NoDefault
> > >
> > > #USERNAME = username
> > > #PASSWORD = password
> > > <Host xxx.xxx.xxx.xxx>
> > > Secret xxxx
> > > AuthPort 1812
> > > Retries 3
> > > RetryTimeout 20
> > > </Host>
> > > # FAILOVER SERVER
> > > <Host xxx.xxx.xxx.xxx>
> > > Secret xxxx
> > > AuthPort 1812
> > > Retries 3
> > > RetryTimeout 20
> > > </Host>
> > > ReplyHook
> > > file:"/usr/local/radiator/hooks/AllocateIPAddressOnReplyFromProxy" #
> > > FILTER NAME: STATIC-ALLOW
> > > AllowInReply
> > > Framed-IP-Address,Session-Timeout,Ascend-Data-Filter,Idle-Timeout
> > > AddToReply
> > > Service-Type=Framed-User,Framed-Protocol=PPP,Framed-Netmask=255.255.255
> > >.255 </AuthBy>
> > >
> > > I have been able to get some information from the radiator
> > > documentation and I have gotten this far:
> > >
> > > <AuthBy SQLRADIUS>
> > > Identifier CheckRemoteRadius
> > > IgnoreAccounting
> > > IgnoreReplySignature
> > > ServerHasBrokenAddresses
> > > RejectEmptyPassword
> > > NoForwardAccounting
> > > NoDefault
> > > NumHosts 4
> > > HostSelect select TARGET_%0_AUTH, SHARED_SECRET, PORT,
> > > RETRIES, TIMEOUT from PROXY2 where TARGET_%0_AUTH<>"" and DNIS=
> > > substring('%{Called-Station-Id',7,4) and REALM='' and STATUS=1;
> > > replyHook
> > > file:"/usr/local/radiator/hooks/AllocateIPAddressOnReplyFromProxy"
> > > </AuthBy>
> > >
> > > However, I run across a couple problems:
> > > 1) When I restart radius I get this error: WARNING: No Hosts defined
> > > for Radius::AuthSQLRADIUS at /etc/radius.cfg line 120. Did I forget
> > > something? I am assuming I Need to tell the AUTHBY SQLRADIUS what
> > > database to use...
> > > 2) Can I dynamically load the IP address that is allocated based on the
> > > replyHook? Currently the IP address is allocated via the Handler. I
> > > need a way to pick the IP address out of different pools in the AUTHBY
> > > SQLRADIUS. 3) Can I dynamically load the AllowInReply and AddToReply
> > > attributes? As you see in the first AUTHBY RADIUS the attributes are
> > > there. However, in the AUTHBY SQLRADIUS they are not. They would need
> > > to be assigned by the DNIS.
> > >
> > > Any help would be greatly appreciated.
> > >
> > > katen
> > >
> > >
> > > ===
> > > 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.
> >
> >--
> >Radiator: the most portable, flexible and configurable RADIUS server
> >anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> >-
> >Nets: internetwork inventory and management - graphical, extensible,
> >flexible with hardware, software, platform and database independence.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
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