Hi,
Ive been playing around with the SessionDatabase and MaxSession features
and i have a couple of questions:
. Is the SessionDatabase DBM recomended if you have to serve lots of
sessions? I had the problem that the server ate up all the cpu (and started
to ignore requests) once i enabled the MaxSession option on a DBM with
about 1500 entries, and serving about 15 requests/sec
. Is currently any way to make queries to SessionDatabase Internal ? (to
know if a user is currently logged in, etc)
. Using SessionDatabase SQL with mysql i get the following error if an
adminstrator telnets into a USR nas:
Wed Feb 2 14:11:34 2000: ERR: do failed for 'insert into RADONLINE
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP,
FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE) values ('!root',
'200.42.xx.xxx', , '!rootxxxx', 949511494, '', 'Virtual',
'Administrative-User')': You have an error in your SQL syntax near '
'!rootxxxxx', 949511494, '', 'Virtual', 'Administrative-User')' at line 1
. Also i get SQL errors when the server gets 'noisy' requests (with '
chars in the user-name attribute). I have Rewrite rules to get the invalid
characters filtered out from the username, but they dont have effect on
SessionDatabase as the session is verified before the Rewrite rules
tranform the username. We also use the Rewrite rules to get the username
'normalised' (user xxx should be equivalent to [EMAIL PROTECTED]). How can
i get the session verification to be done after the username rewriting rules?
Also I whished to hear some comments from people currently using the
concurrence control features of radiator. How do you have it configured? do
you use the NasType option? do you use dbm or SQL or internal? Im
particulary worried about using NasTypes at the client entries, as any
query to the nas will block radiator up.
Ive been thinking about making a small perl script to make 'asyncronical'
verification of the session at the nas. Suppose radiator receives an auth
request for an user that has too many sessions, then at first refuse the
request but at the same time sends a message (through named pipes, socks,
or simplier but uglier through the logfile) to the verification process to
get the sessions checked by it. If the user is not logged in anymore the
verification program will delete up the entry in the session database, so
the next time the user tries to log in it will be accepted. I hope im not
rambling; please send your comments, if you think its worth the trouble, etc
Regards
Alejandro Dau
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.