See below. It can more than likely do with more indexes though. I'm at
this stage obviously only experimenting... I'm still checking, but I'm
*baffled* as to why the rlm_sqlippool won't reconnect to the database
then!
As you said, it uses the SQL driver, whether it's PostGRE, mySQL, MSSQL,
Oracle, surely, the reconnections are handled in the sql driver itself
and
not the module... Alan, anything I can look at perhaps???
I am not sure of the status of that. Reconnect may not be working at
present.
We manage our database fairly carefully on a dedicated system so it
_never_
goes down :-)
This, is weird. I'll have to dig and test here. I had a error in one of my
queries (only saw it now after I posted my queries in the email). It
*seems* that if the DB Handle is down and it tries to execute a incorrect
query when reconnecting, the driver stalls. I fixed my error in my query,
and am running at 12,800 successfull authentications using rlm_sqlippool,
without a single problem. The main thing with my test rig is that it's not
busy. Part of managing a database is killing idle connections :-) That's
why radius needs to reconnect the whole time...
I'm not sure now whether the above should be seen as a possible bug in
rlm_sql, or in rlm_sqlippool, or whether it should be seen as a bug at all.
IMHO however, the handles should reconnect and the radius server should not
'stall' as such nevermind what happens. It creates a major backlog of
queries and no other requests can be processed untill the timeout occured
(not tested in a threaded environment).
So far, it shows that IP addresses are also allocated correctly, as as it is
supposed to by the queries, and specifically, the WHERE clauses.... So it
seems all is well. Provided enough attention is given and you have your
thinking cap on, I'm pretty much happy to say that this works with mySQL as
well then...
+-------------------+----------------------------+
| CallingStationID | INET_NTOA(FramedIPAddress) |
+-------------------+----------------------------+
| 00:01:4A:5E:86:80 | 198.19.240.2 |
| 00:0F:EA:61:0F:B3 | 198.19.240.1 |
+-------------------+----------------------------+
2 rows in set (0.01 sec)
My structures below should be quick and easy to understand. I'm sure
there's mistakes in it as well (which I hope will be pointed out to me),
and I hope other SQL servers will support INET_ATON() and INET_NTOA.
Perhaps add these as variables in FreeRadius (Alan?). Considering pools
are moving to SQL as well now - which is VERY good IMHO, I think it's a
major waiste of space to allocate a VARCHAR(16) (at the minimum) to hold
a
IP Address in a database, when we can do it as a integer...
Actually, they ip_address file should be of type INET. I will make the
change
this week after testing it.
Is that supported on all database platforms though? As a 'default'
configuration shipping with the FreeRadius distribution, I just feel that
whatever is created / decided should be made generic enough so that it will
work 'out of the box' so to speak..
Regards,
Chris.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
