Re: (RADIATOR) not appearing to be working...
Hello Jeremy -
There are a few things wrong with the configuration file, but you should be
getting two different logfiles:
/etc/raddb/logfile.testing-normal
and
%D/logfile.testing-adsl
where %D = /etc/raddb
The first one should contain everything, and the second one should contain a
subset corresponding to the .
I have just been testing this here and it works correctly with the
configuration file that I will attach to this mail.
BTW - here is the ls -l log*:
ls -l log*
-rw-r--r--1 root root14994 Apr 29 16:32 logfile
-rw-r--r--1 root root 195 Apr 29 16:31 logfile.testing-adsl
regards
Hugh
On Mon, 29 Apr 2002 15:59, Jeremy Burton wrote:
> Hi All,
> I've just upgraded from Radiator 2.17.1 to Radiator 3.0.
> I am trying to log different parts of the config to different log files,
> and am having no luck at all - everything just ends up in the global
> logfile. Attached is my config file - this isn't actually my main config
> file, but a smaller one which replicates the problem. Also I'll attach the
> default entries for the users.dialup and users.adsl... Basically, anyone
> know why I'm only getting one log file, not two, as i would expect from
> the additional directive?
>
> radius.cfg:
>
> # $Revision: 1.7 $
> # $Date: 2001/06/28 08:31:35 $
> #
> #Foreground
> #LogStdout
> Trace 3
>
> # NOTE: Anywhere that
> # PreHandlerHook sub { ${$_[0]}->add_attr('Client-Port-DNIS', '5550');}
> # appears is so that eXtremes can log onto analogue equipment..
>
> PidFile /etc/raddb/radiusd.testing.pid
> AuthPort 1645
> AcctPort 1646
> LogDir/var/radacct
> LogFile /etc/raddb/logfile.testing-normal
> DbDir /etc/raddb
> DictionaryFile/etc/raddb/dictionary.ascend
>
>
> FramedGroupBaseAddress 10.200.0.0
> Secret X
> DupInterval 10
>
>
>
> # You can group multiple AuthBy methods with AuthBy GROUP
>
> Identifier AdslSystem
> AuthByPolicy ContinueWhileAccept
>
> # AuthSelect with empty string means dont do auth
> AuthSelect SELECT password, radius.check_items_new('%n',
>'%N',
> '%{Client-Port-DNIS}'), radius.reply_items_new('%n', '%N') FROM SA.Clients,
> sa.adsl where username = '%n' and adsl.userid = clients.userid
> AuthColumnDef 0, User-Password, check
> AuthColumnDef 1, GENERIC, check
> AuthColumnDef 2, GENERIC, reply
> DBSourcedbi:Oracle:SOME_SID
> DBUsername SOME_USER
> DBAuth SOME_PASS
> AccountingTable
> Timeout 1
> FailureBackoffTime300
>
>
>
>
>
> # You can group multiple AuthBy methods with AuthBy GROUP
>
> Identifier System
> AuthByPolicy ContinueWhileAccept
>
> UseGetspnam
>
>
> # AuthSelect with empty string means dont do auth
> AuthSelect SELECT radius.check_items_new('%n', '%N',
> '%{Client-Port-DNIS}'), radius.reply_items_new('%n', '%N') FROM SA.Clients
> where username = '%n' AuthColumnDef 0, GENERIC, check
> AuthColumnDef 1, GENERIC, reply
> DBSourcedbi:Oracle:SOME_SID
> DBUsername SOME_USER
> DBAuth SOME_PASS
> AccountingTable
> Timeout 1
> FailureBackoffTime300
>
>
>
>
>
> RejectHasReason
> RewriteUsername s/\@adsl//
> AcctLogFileName %L/adsl/%C/%v%f-%i-%H
> PasswordLogFileName /etc/raddb/password.adsl
>
> AuthByPolicy ContinueWhileAccept
>
> Trace 3
> Filename %D/logfile.testing-adsl
>
>
> NoForwardAuthentication
> Host secondhost.seconddomain.com
> Secret X
>
>
> Filename %D/users.adsl
>
>
>
>
>
> RejectHasReason
> AuthByPolicy ContinueWhileIgnore
> AcctLogFileName %L/%C/%v%f-%i-%H
>
>
> Filename %D/users.check
>
>
> Filename %D/users.dialup
>
>
>
>
> users.dialup:
> DEFAULT Auth-Type = System
>
> users.adsl:
> DEFAULT Auth-Type = AdslSystem
>
> thanks
>
> Jeremy
--
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 mana
Re: (RADIATOR) Suggestions for high volume system
Hello Viraj - On Sun, 28 Apr 2002 23:06, Viraj Alankar wrote: > Hello, > > I am wondering what's the best design for a high volume radius system. We > are looking at on the order of 100-150 requests/second (auth+acct) on > average. Does anyone here have a load balancing system setup? If so, I'd > appreciate any tips on how you set this up. > I will send you a seperate mail containing a copy of a paper I wrote for one of our customers that deals with part of this issue. > After using Radiator for quite awhile, I've found that the main things that > cause slowdowns is database queries or network outages. I've noticed during > network outages, some RASes (we have mostly Ascend) and proxy servers start > flooding the server once the connectivity comes back. These appear to be > queued requests (mostly accounting) on the systems. In this situation it > pretty much kills our radius server (CPU -> 99%) and many times we have to > run Radiator in a very basic configuration (no database, no authentication) > for some time to cool things down. Many times I've even had to go to our > firewall and block some RAS traffic. > You should have a look at a trace 4 debug using the LogMicroseconds parameter (requires Time-HiRes from CPAN). This will tell you how much time each processing step is taking, and in consequence how many requests per second you can deal with. > So I am just looking for some tips on how to setup a scalable system. We > have a test system setup with a Foundry switch load balancing to 2 Radiator > servers via roundrobin. However, in our tests we are noticing that the load > balancing is not even when the source UDP port stays constant, which is for > example when another Radiator is forwarding requests to it. It only seems > to load balance properly when the source ports change. Anyone have any > ideas what could be wrong here? > It sounds like the switch is using address/port pairs to determine how to load share. Radiator has three different load balancing modules that implement different algorithms. The most useful in this respect is usually the AuthBy LOADBALANCE module that distributes requests according to the response time of each target. > What I was thinking was to instead setup one Radiator system that uses the > AuthBy loadbalance clause instead of the Foundry switch. Any thoughts on > this instead of hardware load balancing? > As mentioned above, you should check the switch to see what options you have for selecting the load balancing algorithm. > The next issue is database slowdowns. I am thinking that the best setup > would be for the RASes to go directly to Radiators that do not have any > sort of DB dependency, and instead they proxy to respective servers that do > have DB dependencies. For example: > >A > / \ > / \ > B C >/ \ / \ > D E F G > > A = Radiator doing AuthBy loadbalance to B and C (or hardware switch) > B/C = Radiator with only AuthBy RADIUS clauses > D/E/F/G = Radiator with DB access > > The B and C trees would be identical. Does this sound like a proper setup? > Well the problem here is that you will still have a single throttle point that will result in everything running at the speed of the database. In other words, B and C will still not send a reply to the NAS until the database query(s) complete. > As far as the type of database access, we've mostly seen that accounting is > what causes problems. I believe this is due to our table designs. For > example, we have unique indexes to drop duplicate accounting, indexed on > many fields. At some point when there is alot of data inserts become slow. > I was thinking that Radiator's access to the DB should be made as fast as > possible, and that Radiator should instead use the DB as sort of a log > table for accounting (with no indexes at all), similar to writing to raw > files. Then, periodically, an external process would process this data and > move to the real accounting tables (with indexes, etc). This way, DB query > time is kept to a minimal for accounting. > What you describe is a good solution - keep the processing that Radiator itself does to an absolute minimum. You might also consider running two instances of Radiator on each host - one for authentication and the other for accounting. > Another problem we have is the number of Handlers. We handle requests > depending on the following: > > RAS IP > RAS IP+DNIS > RAS IP+DNIS+Realm > > With all of our devices, the number of handlers is getting quite large. I'm > wondering what would be an upper bound on this and if there is a better way > to handle this. We have almost 500 handlers at this point. > It is difficult to say anything sensible about your setup without seeing the configuration file and understanding your requirements. Note that we do offer consulting and design services on a contract basis and we have done a large number of custom installations all around the world for many of our c
(RADIATOR) not appearing to be working...
Hi All,
I've just upgraded from Radiator 2.17.1 to Radiator 3.0.
I am trying to log different parts of the config to different log files,
and am having no luck at all - everything just ends up in the global
logfile. Attached is my config file - this isn't actually my main config
file, but a smaller one which replicates the problem. Also I'll attach the
default entries for the users.dialup and users.adsl... Basically, anyone
know why I'm only getting one log file, not two, as i would expect from
the additional directive?
radius.cfg:
# $Revision: 1.7 $
# $Date: 2001/06/28 08:31:35 $
#
#Foreground
#LogStdout
Trace 3
# NOTE: Anywhere that
# PreHandlerHook sub { ${$_[0]}->add_attr('Client-Port-DNIS', '5550');}
# appears is so that eXtremes can log onto analogue equipment..
PidFile /etc/raddb/radiusd.testing.pid
AuthPort1645
AcctPort1646
LogDir /var/radacct
LogFile /etc/raddb/logfile.testing-normal
DbDir /etc/raddb
DictionaryFile /etc/raddb/dictionary.ascend
FramedGroupBaseAddress 10.200.0.0
Secret X
DupInterval 10
# You can group multiple AuthBy methods with AuthBy GROUP
Identifier AdslSystem
AuthByPolicy ContinueWhileAccept
# AuthSelect with empty string means dont do auth
AuthSelect SELECT password, radius.check_items_new('%n',
'%N', '%{Client-Port-DNIS}'), radius.reply_items_new('%n', '%N') FROM SA.Clients,
sa.adsl where username = '%n' and adsl.userid = clients.userid
AuthColumnDef 0, User-Password, check
AuthColumnDef 1, GENERIC, check
AuthColumnDef 2, GENERIC, reply
DBSourcedbi:Oracle:SOME_SID
DBUsername SOME_USER
DBAuth SOME_PASS
AccountingTable
Timeout 1
FailureBackoffTime 300
# You can group multiple AuthBy methods with AuthBy GROUP
Identifier System
AuthByPolicy ContinueWhileAccept
UseGetspnam
# AuthSelect with empty string means dont do auth
AuthSelect SELECT radius.check_items_new('%n', '%N',
'%{Client-Port-DNIS}'), radius.reply_items_new('%n', '%N') FROM SA.Clients where
username = '%n'
AuthColumnDef 0, GENERIC, check
AuthColumnDef 1, GENERIC, reply
DBSourcedbi:Oracle:SOME_SID
DBUsername SOME_USER
DBAuth SOME_PASS
AccountingTable
Timeout 1
FailureBackoffTime 300
RejectHasReason
RewriteUsername s/\@adsl//
AcctLogFileName %L/adsl/%C/%v%f-%i-%H
PasswordLogFileName /etc/raddb/password.adsl
AuthByPolicy ContinueWhileAccept
Trace 3
Filename %D/logfile.testing-adsl
NoForwardAuthentication
Host secondhost.seconddomain.com
Secret X
Filename %D/users.adsl
RejectHasReason
AuthByPolicy ContinueWhileIgnore
AcctLogFileName %L/%C/%v%f-%i-%H
Filename %D/users.check
Filename %D/users.dialup
users.dialup:
DEFAULT Auth-Type = System
users.adsl:
DEFAULT Auth-Type = AdslSystem
thanks
Jeremy
--
Jeremy Burton
Database Administrator, Netspace Online Systems
[EMAIL PROTECTED]
[EMAIL PROTECTED]
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging Accounting to SQL without SQL authentication
Hello Dan - The AuthBy SQL clause is designed to do both authentication and accounting (which is how most people use it), however it is flexible enough to be configured in a number of ways including authentication only and accounting only. regards Hugh On Sun, 28 Apr 2002 04:50, Dan Melomedman wrote: > Hugh Irvine writes: > > > > Identifier SQLAccounting > > .. > > AuthSelect > > AccountingTable ACCOUNTING > > AcctColumnDef . > > .. > > > > > > > > AuthByPolicy ContinueAlways > > AuthBy SQLAccounting > > AuthBy CheckLDAP > > . > > > > Thanks. It's great it works, but it's a work around. SQL accounting should > be independent of AuthBy SQL. Next version maybe? :) -- 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) How to get to particular attribute if set multiple times in radius packet
Hello Tim -
For this type of problem you are better off writing a PreClientHook that
walks the attribute list looking for whatever and sets a pseudo-attribute in
the request that you can then process with a Handler.
regards
Hugh
On Sat, 27 Apr 2002 21:53, Timothy G. Wells wrote:
> Hi Hugh,
>
> The handler fails to see because the attribute is set to the last item
> seen. May I suggest it be placed into an array or a string with all items
> separated by a comma?
>
> -- Tim
>
> -Original Message-
>
>>From: "Hugh Irvine"<[EMAIL PROTECTED]>
>>Sent: 4/27/02 4:23:47 AM
>>To: "Timothy G. Wells"<[EMAIL PROTECTED]>,
>> "[EMAIL PROTECTED]"<[EMAIL PROTECTED]> Subject: Re: (RADIATOR)
>> How to get to particular attribute if set multiple times in radius
>> packet
>>
>>Hello Tim -
>>
>>You will have to write a hook that walks the attribute list.
>>
>>What happens if you try the Handler that you describe?
>>
>>regards
>>
>>Hugh
>>
>>On Sat, 27 Apr 2002 13:53, Timothy G. Wells wrote:
>>> Greetings,
>>>
>>> I'm sorry to hit with so many questions but I'm finally getting time
>>> to put in to Radiator. If a radius packet comes to Radiator and it's
>>> name is duplicated, how do I get to a particular part? For instance
>>> if I look at %{Service_info} I would get "TX" where I really wish I
>>> could see "NGood-News-Internet-Service". I want to use this result as
>>> part of a Handler clause.
>>>
>>> Thanks,
>>>
>>> -- Tim
>>>
>>>
>>>
>>> Acct-Input-Packets = 2214545
>>> Acct-Output-Packets = 2439822
>>> Framed-Protocol = PPP
>>> Service-Info = "NGood-News-Internet-Service"
>>> Service-Info = "Urwells"
>>> Service-Info = "TX"
>>> Acct-Delay-Time = 0
>>> Proxy-State = 19c3
>>>
>>> ===
>>> Archive at http://www.open.com.au/archives/radiator/
>>> Announcements on [EMAIL PROTECTED]
>>> To unsubscribe, email '[EMAIL PROTECTED]' 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.
>>===
>>Archive at http://www.open.com.au/archives/radiator/
>>Announcements on [EMAIL PROTECTED]
>>To unsubscribe, email '[EMAIL PROTECTED]' 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.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Suggestions for high volume system
Hello, I am wondering what's the best design for a high volume radius system. We are looking at on the order of 100-150 requests/second (auth+acct) on average. Does anyone here have a load balancing system setup? If so, I'd appreciate any tips on how you set this up. After using Radiator for quite awhile, I've found that the main things that cause slowdowns is database queries or network outages. I've noticed during network outages, some RASes (we have mostly Ascend) and proxy servers start flooding the server once the connectivity comes back. These appear to be queued requests (mostly accounting) on the systems. In this situation it pretty much kills our radius server (CPU -> 99%) and many times we have to run Radiator in a very basic configuration (no database, no authentication) for some time to cool things down. Many times I've even had to go to our firewall and block some RAS traffic. So I am just looking for some tips on how to setup a scalable system. We have a test system setup with a Foundry switch load balancing to 2 Radiator servers via roundrobin. However, in our tests we are noticing that the load balancing is not even when the source UDP port stays constant, which is for example when another Radiator is forwarding requests to it. It only seems to load balance properly when the source ports change. Anyone have any ideas what could be wrong here? What I was thinking was to instead setup one Radiator system that uses the AuthBy loadbalance clause instead of the Foundry switch. Any thoughts on this instead of hardware load balancing? The next issue is database slowdowns. I am thinking that the best setup would be for the RASes to go directly to Radiators that do not have any sort of DB dependency, and instead they proxy to respective servers that do have DB dependencies. For example: A / \ / \ B C / \ / \ D E F G A = Radiator doing AuthBy loadbalance to B and C (or hardware switch) B/C = Radiator with only AuthBy RADIUS clauses D/E/F/G = Radiator with DB access The B and C trees would be identical. Does this sound like a proper setup? As far as the type of database access, we've mostly seen that accounting is what causes problems. I believe this is due to our table designs. For example, we have unique indexes to drop duplicate accounting, indexed on many fields. At some point when there is alot of data inserts become slow. I was thinking that Radiator's access to the DB should be made as fast as possible, and that Radiator should instead use the DB as sort of a log table for accounting (with no indexes at all), similar to writing to raw files. Then, periodically, an external process would process this data and move to the real accounting tables (with indexes, etc). This way, DB query time is kept to a minimal for accounting. Another problem we have is the number of Handlers. We handle requests depending on the following: RAS IP RAS IP+DNIS RAS IP+DNIS+Realm With all of our devices, the number of handlers is getting quite large. I'm wondering what would be an upper bound on this and if there is a better way to handle this. We have almost 500 handlers at this point. Anyhow, I'd appreciate any info or tips anyone has on a large setup like this. Thanks, Viraj. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
