Re: (RADIATOR) kill -HUP causes AuthBy clauses Identifiers to be lost?
hello again
I don't have exactly the same setup here, so could you try something for
me
please? In your code (shown below), I would like to know which line is
causing the problem:
if ($code eq 'Access-Request') {
my $authby=Radius::AuthGeneric::find ('ldap_auth_id');
my $ldap_c=$authby-{ld};
Ie. - is the Radius::AuthGeneric::find not returning the correct value?
or is the $authby-{ld} not returning anything (or returning "undef")?
i've tried dumping the structures before and after sending the HUP signal,
at the time the hook is called. after the signal is sent,
Radius::AuthGeneric::find returns a valid hash with similar contents than it
did before but without any "ld" array on it. so I guess "find" is returning
everything OK and the possible problem comes from beyond.
In general, the AuthBy LDAP* clauses open and close the connection to the
LDAP server for every request, so I suspect that is your problem.
You can either use the "HoldServerConnection" parameter in the AuthBy
LDAP2
clause (which I see you are doing), or you can explicitly call
$authby-reconnect(); in your code.
as of now, my setup is using (as requested) something like
my $ldap_c=$authby-{ld};
if (!$ldap_c) {$authby-reconnect();$ldap_c=$authby-{ld};}
it works fine, recconnect is called the first time the hook is called after
a HUP signal is sent... but wasn't this supposed to be implicit by
"HoldServerConnection" and the HUP signal processing?
This behaviour did change some time ago, so if you were using an earlier
version of Radiator previously that may be why you are seeing different
behaviour. There could also be a problem with -HUP processing of course.
Could you also let me know what LDAP server version you are using? And can
you tell me what you did prior to sending the -HUP (ie. what changed?)?
I first noticed this after changing a file i'm including and which contains
client clauses (and then killing -HUP radiator) but I got to the
conclusion that I could replicate it everytime I sent a HUP signal. Our
directory server is Netscape DS 4.12 running on Solaris (radiator host is
RedHat linux running perl 5.6.0. Net::LDAP version is 0.15.
any comments? do you want me to send you the full set of configuration files
?
-Bruno
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Performance with RADIATOR
Hi all, we need to decide which radius server will upgrade our AAA plattform. Our final choice is between Radiator and BSAC. A feature-table has been elaborated and checked during the last months. The last check-item is about performance in resolving radius-clients requests. So the same test was done in the same conditions for BSAC and Radiator: - U420R with 2 processors, 1GB memory (Radius Server) - U220R with 1 processor, 512MG memory (Radius client with radpwtst) A radpwtst request was executed with 250 iterations. The results are: - BSAC finished in 7 sec. - Radiator finished in 23 sec. During the last months we made tunning of Radiator on these points: - hardware - LDAP - MySQL - UDP but it seems like the perl language is the main problem to improve performance. We launch Radiator with "Trace -1" and monitoring it, we noticed that almost all the time the peak of requests per second is 30. so, Anybody can tell us how to improve performace with Radiator? Does exist the posibility of execute a like-compiled instance of Radiator? Do you have in mind to upgrade Radiator to a multithread-compiled release? regards, jules ** Noticia legal Este mensaje electrnico contiene informacin de BT Telecomunicaciones S.A. que es privada y confidencial, siendo para el uso exclusivo de la persona(s) o entidades arriba mencionadas. Si usted no es el destinatario sealado, le informamos que cualquier divulgacin, copia, distribucin o uso de los contenidos est prohibida. Si usted ha recibido este mensaje por error, por favor borre su contenido y comunquenoslo en la direccin [EMAIL PROTECTED] Gracias === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Bad LDAP Result
Hi all,
While I was testing 'searchFilter' function like mentioned last week (Julio
Prada`s posts),
something strange happened and I still don't know what. This was my cfg
file (Radiator 2.17.1):
AuthBy LDAP2
AuthDN ...
AuthPassword ...
BaseDN ...
Host ...
Identifier ID_1
PasswordAttr password
Port ...
SearchFilter ((login=%{User-Name})(callingId=%{Calling-Station-Id}))
UsernameAttr login
/AuthBy
Client localhost
DupInterval 0
Secret ...
StatusServerShowClientDetails
/Client
Realm DEFAULT
AcctLogFileName %L/detail
AuthBy ID_1
PasswordLogFileName %L/password
RejectHasReason
/Realm
I wanted to simulate pre-authentication feature so I sent this
Access-Request
with 'radpwtst' GUI (version 2.18):
Mon Mar 19 16:24:50 2001: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 1025
Code: Access-Request
Identifier: 164
Authentic: 1234567890123456
Attributes:
User-Name = "91291"
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 12345
Called-Station-Id = "91291"
Calling-Station-Id = "94703"
NAS-Port-Type = Async
User-Password = "1874204168187215M20818N222D9%20812"
It worked when the password was true. When wasn`t, this output happened:
Mon Mar 19 16:24:50 2001: DEBUG: Handling request with Handler 'Realm=DEFAULT'
Mon Mar 19 16:24:50 2001: DEBUG: Deleting session for 91291, 203.63.154.1,
12345
Mon Mar 19 16:24:50 2001: DEBUG: Handling with Radius::AuthLDAP2
Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with 91291000
0
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad Password
Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with DEFAULT
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad Password
Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with DEFAULT1
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad Password
Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with DEFAULT2
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad Password
Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with DEFAULT3
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad Password
Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with DEFAULT4
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad Password
Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
[..]
And it grew, grew, grew .
Coud someone explain why?
Thanks in advance...
Daniel Tern.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Apache and Radiator
I'd be interested in hearing from anyone that implemented Radiator password-style access to pay-per-view or secure content on their Apache web server. Did you get it to work with just the stock mod_auth_radius.c file or did you have to write a bunch of other routines to get things going? The accountability and authorization features of Radius make this appealing, and the fact that htpasswd authentication isn't that reliable compared to RADIUS is another reason. Thanks, Chris === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Apache and Radiator
Hello Chris - There is an item in the FAQ here: http://www.open.com.au/radiator/faq.html#63 hth Hugh On Tuesday 20 March 2001 07:50, Chris M wrote: I'd be interested in hearing from anyone that implemented Radiator password-style access to pay-per-view or secure content on their Apache web server. Did you get it to work with just the stock mod_auth_radius.c file or did you have to write a bunch of other routines to get things going? The accountability and authorization features of Radius make this appealing, and the fact that htpasswd authentication isn't that reliable compared to RADIUS is another reason. Thanks, Chris === Archive at http://www.starport.net/~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.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) kill -HUP causes AuthBy clauses Identifiers to be lost?
Hello Bruno -
I have copied this mail to Mike, as there have been some significant changes
in Radiator 2.18 and this problem may be one that we missed.
thanks for letting us know
Hugh
Mike -
Bruno has upgraded to Radiator 2.18, and now after a HUP signal his
PostAuthHook no longer works because the code fragment shown below no longer
has a valid reference in "$authby-{ld}". As a work around I have suggested
he call the "reconnect" routine explicitly, which does work.
thanks
Hugh
On Tuesday 20 March 2001 00:24, Bruno Tiago Rodrigues wrote:
hello again
I don't have exactly the same setup here, so could you try something for
me
please? In your code (shown below), I would like to know which line is
causing the problem:
if ($code eq 'Access-Request') {
my $authby=Radius::AuthGeneric::find ('ldap_auth_id');
my $ldap_c=$authby-{ld};
Ie. - is the Radius::AuthGeneric::find not returning the correct value?
or is the $authby-{ld} not returning anything (or returning "undef")?
i've tried dumping the structures before and after sending the HUP signal,
at the time the hook is called. after the signal is sent,
Radius::AuthGeneric::find returns a valid hash with similar contents than
it did before but without any "ld" array on it. so I guess "find" is
returning everything OK and the possible problem comes from beyond.
In general, the AuthBy LDAP* clauses open and close the connection to the
LDAP server for every request, so I suspect that is your problem.
You can either use the "HoldServerConnection" parameter in the AuthBy
LDAP2
clause (which I see you are doing), or you can explicitly call
$authby-reconnect(); in your code.
as of now, my setup is using (as requested) something like
my $ldap_c=$authby-{ld};
if (!$ldap_c) {$authby-reconnect();$ldap_c=$authby-{ld};}
it works fine, recconnect is called the first time the hook is called after
a HUP signal is sent... but wasn't this supposed to be implicit by
"HoldServerConnection" and the HUP signal processing?
This behaviour did change some time ago, so if you were using an earlier
version of Radiator previously that may be why you are seeing different
behaviour. There could also be a problem with -HUP processing of course.
Could you also let me know what LDAP server version you are using? And
can you tell me what you did prior to sending the -HUP (ie. what
changed?)?
I first noticed this after changing a file i'm including and which contains
client clauses (and then killing -HUP radiator) but I got to the
conclusion that I could replicate it everytime I sent a HUP signal. Our
directory server is Netscape DS 4.12 running on Solaris (radiator host is
RedHat linux running perl 5.6.0. Net::LDAP version is 0.15.
any comments? do you want me to send you the full set of configuration
files ?
-Bruno
===
Archive at http://www.starport.net/~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.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Bad LDAP Result
Hello Daniel -
This is a known problem with LDAP servers that return incorrect results when
Radiator looks for "DEFAULT" users. The best solution if you are not using
DEFAULT's is to configure "NoDefault" in the AuthBy clause.
Have a look at section 6.16.11 in the Radiator 2.18 reference manual.
hth
Hugh
On Tuesday 20 March 2001 02:45, [EMAIL PROTECTED] wrote:
Hi all,
While I was testing 'searchFilter' function like mentioned last week (Julio
Prada`s posts),
something strange happened and I still don't know what. This was my cfg
file (Radiator 2.17.1):
AuthBy LDAP2
AuthDN ...
AuthPassword ...
BaseDN ...
Host ...
Identifier ID_1
PasswordAttr password
Port ...
SearchFilter ((login=%{User-Name})(callingId=%{Calling-Station-Id}))
UsernameAttr login
/AuthBy
Client localhost
DupInterval 0
Secret ...
StatusServerShowClientDetails
/Client
Realm DEFAULT
AcctLogFileName %L/detail
AuthBy ID_1
PasswordLogFileName %L/password
RejectHasReason
/Realm
I wanted to simulate pre-authentication feature so I sent this
Access-Request
with 'radpwtst' GUI (version 2.18):
Mon Mar 19 16:24:50 2001: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 1025
Code: Access-Request
Identifier: 164
Authentic: 1234567890123456
Attributes:
User-Name = "91291"
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 12345
Called-Station-Id = "91291"
Calling-Station-Id = "94703"
NAS-Port-Type = Async
User-Password =
"1874204168187215M20818N222D9%20812"
It worked when the password was true. When wasn`t, this output happened:
Mon Mar 19 16:24:50 2001: DEBUG: Handling request with Handler
'Realm=DEFAULT' Mon Mar 19 16:24:50 2001: DEBUG: Deleting session for
91291, 203.63.154.1, 12345
Mon Mar 19 16:24:50 2001: DEBUG: Handling with Radius::AuthLDAP2
Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with
91291000 0
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad Password
Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with
DEFAULT Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad
Password Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with
DEFAULT1 Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad
Password Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with
DEFAULT2 Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad
Password Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with
DEFAULT3 Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad
Password Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got password: i2p
Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 looks for match with
DEFAULT4 Mon Mar 19 16:24:50 2001: DEBUG: Radius::AuthLDAP2 REJECT: Bad
Password Mon Mar 19 16:24:50 2001: DEBUG: Connecting to ...
Mon Mar 19 16:24:50 2001: DEBUG: LDAP got result for login=91291...
[..]
And it grew, grew, grew .
Coud someone explain why?
Thanks in advance...
Daniel Tern.
===
Archive at http://www.starport.net/~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.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
IMPORTANT - Re: (RADIATOR) Performance with RADIATOR
Hello Julio - On Tuesday 20 March 2001 02:01, [EMAIL PROTECTED] wrote: Hi all, we need to decide which radius server will upgrade our AAA plattform. Our final choice is between Radiator and BSAC. A feature-table has been elaborated and checked during the last months. The last check-item is about performance in resolving radius-clients requests. So the same test was done in the same conditions for BSAC and Radiator: - U420R with 2 processors, 1GB memory (Radius Server) - U220R with 1 processor, 512MG memory (Radius client with radpwtst) A radpwtst request was executed with 250 iterations. The results are: - BSAC finished in 7 sec. - Radiator finished in 23 sec. During the last months we made tunning of Radiator on these points: - hardware - LDAP - MySQL - UDP but it seems like the perl language is the main problem to improve performance. We launch Radiator with "Trace -1" and monitoring it, we noticed that almost all the time the peak of requests per second is 30. so, Anybody can tell us how to improve performace with Radiator? Does exist the posibility of execute a like-compiled instance of Radiator? Do you have in mind to upgrade Radiator to a multithread-compiled release? There are a number of issues to consider regarding Radiator performance, mostly to do with external factors like databases and so on. It is interesting that in recent tests using identical hardware, we initially saw about the same 30 requests per second, also using MySQL. However, we found that there was enormous improvement to be had simply by tuning the database and improving the indexes. In this particular case we saw the number of requests jump from 30 per second to 80 per second with no other changes. I also have some comments about common misunderstandings regarding Perl. First, Perl *is* compiled, but it is compiled at run time, not in some preliminary step prior to execution. Therefore, Radiator takes a few seconds to start up while the code is compiled, but thereafter it is as fast (or faster for some operations) than a compiled language. Performance limitations in our experience with thousands of installations of Radiator has never been due to Perl. Second, multithreading - this comes up from time to time, and yes it is something we are considering once the support for multithreading is certified as "ready for production". Note however that multithreading in and of itself is not a panacea, and we have had comments from users of other products that multithreading can also cause severe problems, like when a database becomes unavailable and all of the process slots are exhausted due to threads waiting for completion. This failure mode is particularily unpleasant, as it generally means that the box is locked up with no way to restart it short of a power cycle. Now, in your situation, I think you should do the following: 1. download and install Radiator 2.18 2. use the new high-resolution timing feature to examine the actual exectution times of your LDAP and SQL queries. See section 6.10.2 in the Radiator 2.18 reference manual 3. use the new indexes and SQL queries for MySQL in Radiator 2.18 4. have your DBA verify what other indexes should be added to your database 5. make sure you use the -notrace option with "radpwtst -notrace ." 6. you should consider running two instances of Radiator, one for authentication and the other for accounting As other contributors to the list have noted, you should be able to get *much* better performance from your system than you are currently seeing. regards Hugh -- 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.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Performance with RADIATOR
At 08:18 PM 3/19/2001 +0100, [EMAIL PROTECTED] wrote: We have gotten over 500 requests per second from Radiator when hitting it with multiple clients. We can do over 200 from a single client. Are you including accounting in your requests or are you purely looking at auths? We send complete requests (auth, acct on, acct off) Sorry, I was really looking at benchmark numbers and not real world usage. The numbers that I was thinking of were related to our benchmarking Radiator with a minimal config and certainly no accounting. This was back when we were determining our hardware requirements for deploying it. What are the specifics of what you are testing? We send a complete request to a Radiator server which has MySQL in local and LDAP in remote server We use Solaris 2.6 and, what do you refer to with 'specifics'? hw? sw? lan? How many requests per second can your DB handle? I don't know how many. It's a MySQL server in the same machine that Radiator (1GB memory, 2 processors) and it only hosts Radiator database I was referring to the MySQL/LDAP part. I am not familiar with LDAP at all so I couldn't offer any advise on it. But, MySQL is VERY fast. We can do almost 2000 lookups per second on our MySQL servers (we do this with Apache querying the DB). The problems come in when you are doing complex or data heavy inserts into MySQL. These are more common in Radius accounting. If you are running into problems with performance you should look into running Radiator and MySQL on different machines. Your DB should certainly be running on RAID disk subsystem. Do U recommend DB tunning?. It is definitely one of the first places to look. I would guess that the LDAP server could be a big question mark as well. Looking at the Radiator reference manual the numbers for LDAP auths per second is significantly less than SQL, although I don't know that these numbers have been updated since a lot of the LDAP changes have been made, you would have to ask Hugh. The first thing I would do is split the auth and acct job between two processes. Then you can get a better idea of where the problem is. You should be spending a lot more time on acct than auth, if you aren't then it is probably and LDAP issue. (This is because acct gets two calls for every auth [start and stop]). Also, as your SQL table gets larger from the accounting records you will want to groom it. I noticed awhile back that someone had described their config where they log to SQL on one machine and then replicate the records to there final home on a seperate DB server, they then remove them from the original log host. This keeps the number of records to a minimum and stops the DB table size from affecting the performance of Radiator. Something to think about: if 10 requests per second isn't enough for your needs you should look into load balancing across multiple Radius servers. Certainly if you have that many requests you should have a second server anyway. Whew, I wrote too much, hope it was at least somewhat helpful. Steve === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Performance with RADIATOR
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: maandag 19 maart 2001 20:19 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: (RADIATOR) Performance with RADIATOR At 04:01 PM 3/19/2001 +0100, [EMAIL PROTECTED] wrote: The results are: - BSAC finished in 7 sec. - Radiator finished in 23 sec. We launch Radiator with "Trace -1" and monitoring it, we noticed that almost all the time the peak of requests per second is 30. We have gotten over 500 requests per second from Radiator when hitting it with multiple clients. We can do over 200 from a single client. Are you including accounting in your requests or are you purely looking at auths? We send complete requests (auth, acct on, acct off) Shouldn't be a problem. What are the specifics of what you are testing? We send a complete request to a Radiator server which has MySQL in local and LDAP in remote server We use Solaris 2.6 and, what do you refer to with 'specifics'? hw? sw? lan? Make sure your radius and your SQL server, is on the same LAN (preferrably even the same switch). How many requests per second can your DB handle? I don't know how many. It's a MySQL server in the same machine that Radiator (1GB memory, 2 processors) and it only hosts Radiator database Do U recommend DB tunning?. Yes, MySQL needs to be tuned, to be able to accept lots of queries, and to make the DB response relatively fast. You should consider, having indeces for every column you plan to search on, raise the amount of maximum concurrent connections, increase the table cache, increase the wait timeout, increase the max connect errors, increase the key buffers, skip name resolving, etc Please refer to the MySQL documentation, to fine-tune your server. -Andy -- Andy De Petter _,'|_.-''``-...___..--'; Skynet Operations /, \'. _..-' , ,--...--''' \ .`--''' ` /| Tel +32 (0)2 7061311 `-,;' ; ; ; Fax +32 (0)2 7061312__...--'' __...--_..' .;.' (,__''' (,..--'' *** DISCLAIMER *** This e-mail and any attachments thereto may contain information, which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Performance with RADIATOR
--- Forwarded mail from [EMAIL PROTECTED] Date: Tue, 20 Mar 2001 17:40:29 +1100 (EST) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: BOUNCE [EMAIL PROTECTED]:Non-member submission from ["Andy De Petter" [EMAIL PROTECTED]] From mikem Tue Mar 20 17:40:23 2001 Received: by oscar.open.com.au (8.9.0/8.9.0) id RAA07771 for [EMAIL PROTECTED]; Tue, 20 Mar 2001 17:40:23 +1100 (EST) Received: from mail.krameria.net (mail.krameria.net [194.78.241.3]) by perki.connect.com.au with ESMTP id RAA27827 (8.8.8/IDA-1.7 for [EMAIL PROTECTED]); Tue, 20 Mar 2001 17:12:24 +1100 (EST) Received: from mail.krameria.net (mail.krameria.net [194.78.241.3]) by perki.connect.com.au with ESMTP id RAA27827 (8.8.8/IDA-1.7 for [EMAIL PROTECTED]); Tue, 20 Mar 2001 17:12:24 +1100 (EST) Received: from warp-core.skynet.be ([195.238.2.25] helo=Sarabi) by mail.krameria.net with asmtp (Exim 3.20 #1) id 14fFPV-0001Of-00; Tue, 20 Mar 2001 07:14:25 +0100 From: "Andy De Petter" [EMAIL PROTECTED] To: "Steve Roderick" [EMAIL PROTECTED] Cc: "Radiator Mailing" [EMAIL PROTECTED] Subject: RE: (RADIATOR) Performance with RADIATOR Date: Tue, 20 Mar 2001 07:12:19 +0100 Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset="us-ascii" I was referring to the MySQL/LDAP part. I am not familiar with LDAP at all so I couldn't offer any advise on it. But, MySQL is VERY fast. We can do almost 2000 lookups per second on our MySQL servers (we do this with Apache querying the DB). The problems come in when you are doing complex or data heavy inserts into MySQL. These are more common in Radius accounting. If you are running into problems with performance you should look into running Radiator and MySQL on different machines. Your DB should certainly be running on RAID disk subsystem. Nothing that works, based on SQL, beats LDAP, in query speed. :) -Andy -- "For nothing can seem foul to those that win." - Henry IV, Pt1, Act 5, Sc 1 ---End of forwarded mail from [EMAIL PROTECTED] -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) (Fwd) BOUNCE radiator@open.com.au: Non-member submission from [Andy De Petter andy@techos.be]
--- Forwarded mail from [EMAIL PROTECTED] Date: Tue, 20 Mar 2001 09:10:23 +1100 (EST) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: BOUNCE [EMAIL PROTECTED]:Non-member submission from ["Andy De Petter" [EMAIL PROTECTED]] From mikem Tue Mar 20 09:10:19 2001 Received: by oscar.open.com.au (8.9.0/8.9.0) id JAA06410 for [EMAIL PROTECTED]; Tue, 20 Mar 2001 09:10:17 +1100 (EST) Received: from mail.krameria.net (mail.krameria.net [194.78.241.3]) by perki.connect.com.au with ESMTP id IAA03044 (8.8.8/IDA-1.7 for [EMAIL PROTECTED]); Tue, 20 Mar 2001 08:49:52 +1100 (EST) Received: from mail.krameria.net (mail.krameria.net [194.78.241.3]) by perki.connect.com.au with ESMTP id IAA03044 (8.8.8/IDA-1.7 for [EMAIL PROTECTED]); Tue, 20 Mar 2001 08:49:52 +1100 (EST) Received: from adsl-64156.turboline.skynet.be ([217.136.122.156] helo=Sarabi) by mail.krameria.net with asmtp (Exim 3.20 #1) id 14f7ZD-00019W-00; Mon, 19 Mar 2001 22:51:56 +0100 From: "Andy De Petter" [EMAIL PROTECTED] To: "Radiator Mailing" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: (RADIATOR) Performance with RADIATOR Date: Mon, 19 Mar 2001 22:49:50 +0100 Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset="iso-8859-1" -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: maandag 19 maart 2001 20:19 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: (RADIATOR) Performance with RADIATOR At 04:01 PM 3/19/2001 +0100, [EMAIL PROTECTED] wrote: The results are: - BSAC finished in 7 sec. - Radiator finished in 23 sec. We launch Radiator with "Trace -1" and monitoring it, we noticed that almost all the time the peak of requests per second is 30. We have gotten over 500 requests per second from Radiator when hitting it with multiple clients. We can do over 200 from a single client. Are you including accounting in your requests or are you purely looking at auths? We send complete requests (auth, acct on, acct off) Shouldn't be a problem. What are the specifics of what you are testing? We send a complete request to a Radiator server which has MySQL in local and LDAP in remote server We use Solaris 2.6 and, what do you refer to with 'specifics'? hw? sw? lan? Make sure your radius and your SQL server, is on the same LAN (preferrably even the same switch). How many requests per second can your DB handle? I don't know how many. It's a MySQL server in the same machine that Radiator (1GB memory, 2 processors) and it only hosts Radiator database Do U recommend DB tunning?. Yes, MySQL needs to be tuned, to be able to accept lots of queries, and to make the DB response relatively fast. You should consider, having indeces for every column you plan to search on, raise the amount of maximum concurrent connections, increase the table cache, increase the wait timeout, increase the max connect errors, increase the key buffers, skip name resolving, etc Please refer to the MySQL documentation, to fine-tune your server. -Andy -- Andy De Petter _,'|_.-''``-...___..--'; Skynet Operations /, \'. _..-' , ,--...--''' \ .`--''' ` /| Tel +32 (0)2 7061311 `-,;' ; ; ; Fax +32 (0)2 7061312__...--'' __...--_..' .;.' (,__''' (,..--'' *** DISCLAIMER *** This e-mail and any attachments thereto may contain information, which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. ---End of forwarded mail from [EMAIL PROTECTED] -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X === Archive at http://www.starport.net/~radiator/ Announcements on
(RADIATOR) Multiple SQL statements in radiator config
--- Forwarded mail from [EMAIL PROTECTED]
Date: Tue, 20 Mar 2001 12:10:44 +1100 (EST)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: BOUNCE [EMAIL PROTECTED]:Non-member submission from [Brett
Murphy [EMAIL PROTECTED]]
From mikem Tue Mar 20 12:10:35 2001
Received: by oscar.open.com.au (8.9.0/8.9.0) id MAA07043
for [EMAIL PROTECTED]; Tue, 20 Mar 2001 12:10:35 +1100 (EST)
Received: from mail.alphalink.com.au (mail.alphalink.com.au [203.24.205.7]) by
perki.connect.com.au with ESMTP id MAA13072
(8.8.8/IDA-1.7 for [EMAIL PROTECTED]); Tue, 20 Mar 2001 12:01:37 +1100
(EST)
Received: from mail.alphalink.com.au (mail.alphalink.com.au [203.24.205.7]) by
perki.connect.com.au with ESMTP id MAA13072
(8.8.8/IDA-1.7 for [EMAIL PROTECTED]); Tue, 20 Mar 2001 12:01:37 +1100
(EST)
Received: from noc.alphalink.com.au (noc.alphalink.com.au [202.161.122.66])
by mail.alphalink.com.au (8.9.3/8.9.3) with ESMTP id MAA01040
for [EMAIL PROTECTED]; Tue, 20 Mar 2001 12:01:29 +1000
Message-Id: [EMAIL PROTECTED]
X-Sender: [EMAIL PROTECTED]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 20 Mar 2001 12:02:04 +1100
To: [EMAIL PROTECTED]
From: Brett Murphy [EMAIL PROTECTED]
Subject: Multiple SQL statements in radiator config
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi,
I have a session time totalling SQL statement I need to be dependant on
whether another INSERT fails or not, how can I issue 2 semi-colon separated
SQL statements in the AcctSQLStatement ??
eg
#accounting first, adds octets and time used to fields in SUBSCRIBERS table
AuthBy SQL
Identifier AcctSTORE_USED
AuthSelect
DBSourcedbi:mysql:blah
DBUsername rad
DBAuth
AccountingStopsOnly
AcctSQLStatement update SUBSCRIBERS SET
inoctets=(inoctets+0%{Acct-Input-Octets}),\
outoctets=(outoctets+0%{Acct-Output-Octets}),\
timeused=(timeused+0%{Acct-Session-Time}),\
peaktimeused=peaktimeused+peaktime(%{Acct-Session-Time}) where
username=(TRIM(LEADING 'P' FROM '%n'))
/AuthBy
# now store the stop record
AuthBy SQL
Identifier Acct_RADLAST
AuthSelect
DBSourcedbi:mysql:blah
DBUsername rad
DBAuth
AcctSQLStatement INSERT DELAYED INTO ACCOUNTING
(USERNAME,TIME_STAMP,ACCTSTATUSTYPE,ACCTDELAYTIME,\
ACCTINPUTOCTETS,ACCTOUTPUTOCTETS,ACCTSESSIONID,ACCTSESSIONTIME,ACCTTERMINATECAUSE,NASIDENTIFIER,\
NASPORT,CALLINGSTATIONID,FRAMEDIPADDRESS,CONNECTSPEED,MODULATIONTYPE,MNPLEVELS,V42BISUSAGE,CALLEDSTATION)
\
VALUES ((TRIM(LEADING 'P' FROM
'%n')),'%b','%{Acct-Status-Type}','%{Acct-Delay-Time}',\
'%{Acct-Input-Octets}','%{Acct-Output-Octets}','%{Acct-Session-Id}','%{Acct-Session-Time}',\
'%{Acct-Terminate-Cause}','%N','%{NAS-Port}','%{Calling-Station-Id}',\
'%{Framed-IP-Address}','%{Connect-Speed}','%{Modulation-Type}','%{Simplified-MNP-Levels}','%{Simplified-V42bis-Usage}',\
'%{Called-Station-Id}')
/AuthBy
The problem I have is when the brain dead NAS sends multiple stop records,
I add the sessiontime and data etc more than once.
I have handled the multiple stop records into the ACCOUNTING table by
setting the index keys appropriately to ignore multiple records.
I am guessing if I can incorporate both SQL functions into one, the second
will be dependant on the first completing successfully
All the best,
Brett Murphy
Director, Alphalink (Australia) PTY LTD
ph: +61 3 9495-9000 fax: +61 3 9486-6822
email: [EMAIL PROTECTED]
The contents of this message may not be quoted,
copied, reproduced or published in part or in whole,
without the written authorization of Brett Murphy,
Director, Alphalink (Australia) Pty Ltd.
---End of forwarded mail from [EMAIL PROTECTED]
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc
on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Multiple SQL statements in radiator config
Hello Brett -
I posted the following on this topic some time ago:
http://www.starport.net/~radiator/2000-11/msg00114.html
If this won't work for you, I suggest you write a Hook which will be *much*
easier to deal with.
hth
Hugh
I have a session time totalling SQL statement I need to be dependant on
whether another INSERT fails or not, how can I issue 2 semi-colon separated
SQL statements in the AcctSQLStatement ??
eg
#accounting first, adds octets and time used to fields in SUBSCRIBERS table
AuthBy SQL
Identifier AcctSTORE_USED
AuthSelect
DBSourcedbi:mysql:blah
DBUsername rad
DBAuth
AccountingStopsOnly
AcctSQLStatement update SUBSCRIBERS SET
inoctets=(inoctets+0%{Acct-Input-Octets}),\
outoctets=(outoctets+0%{Acct-Output-Octets}),\
timeused=(timeused+0%{Acct-Session-Time}),\
peaktimeused=peaktimeused+peaktime(%{Acct-Session-Time}) where
username=(TRIM(LEADING 'P' FROM '%n'))
/AuthBy
# now store the stop record
AuthBy SQL
Identifier Acct_RADLAST
AuthSelect
DBSourcedbi:mysql:blah
DBUsername rad
DBAuth
AcctSQLStatement INSERT DELAYED INTO ACCOUNTING
(USERNAME,TIME_STAMP,ACCTSTATUSTYPE,ACCTDELAYTIME,\
ACCTINPUTOCTETS,ACCTOUTPUTOCTETS,ACCTSESSIONID,ACCTSESSIONTIME,ACCTTERMINAT
ECAUSE,NASIDENTIFIER,\
NASPORT,CALLINGSTATIONID,FRAMEDIPADDRESS,CONNECTSPEED,MODULATIONTYPE,MNPLEV
ELS,V42BISUSAGE,CALLEDSTATION) \
VALUES ((TRIM(LEADING 'P' FROM
'%n')),'%b','%{Acct-Status-Type}','%{Acct-Delay-Time}',\
'%{Acct-Input-Octets}','%{Acct-Output-Octets}','%{Acct-Session-Id}','%{Acct
-Session-Time}',\
'%{Acct-Terminate-Cause}','%N','%{NAS-Port}','%{Calling-Station-Id}',\
'%{Framed-IP-Address}','%{Connect-Speed}','%{Modulation-Type}','%{Simplifie
d-MNP-Levels}','%{Simplified-V42bis-Usage}',\ '%{Called-Station-Id}')
/AuthBy
The problem I have is when the brain dead NAS sends multiple stop records,
I add the sessiontime and data etc more than once.
I have handled the multiple stop records into the ACCOUNTING table by
setting the index keys appropriately to ignore multiple records.
I am guessing if I can incorporate both SQL functions into one, the second
will be dependant on the first completing successfully
All the best,
Brett Murphy
Director, Alphalink (Australia) PTY LTD
ph: +61 3 9495-9000 fax: +61 3 9486-6822
email: [EMAIL PROTECTED]
The contents of this message may not be quoted,
copied, reproduced or published in part or in whole,
without the written authorization of Brett Murphy,
Director, Alphalink (Australia) Pty Ltd.
---End of forwarded mail from [EMAIL PROTECTED]
--
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.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
