Hello Alejandro -
On Thu, 03 Feb 2000, Alejandro Dau wrote:
> 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
>
What version of Radiator are you running? And what hardware/software
platform? We have recently had problems with DBM session databases on
Solaris. There was also a fix to the session database code in Radiator 2.14
(from history.html):
Fixed a problem in the internal SessionDatabase, where it would
ask
all the NAS ports for all users to double check apparent logins.
And this in Radiator 2.13:
Improved robstness of the session databases in the face of lost stop packets. Now a
stop packet will always remove any previous session that we thought was on that
NAS/Port combination. This will make the session database "self-healing". Your
existing DBM session database will have to be deleted: the database format for
DBM is changed. The table format for the SQL session
database is the same, but the indexes have changed: you should probably
recreate them if you are using SQL. Also changed radwho.cgi
to be compatible with new DBM database format.
> . Is currently any way to make queries to SessionDatabase Internal ? (to
> know if a user is currently logged in, etc)
>
No - this is in memory inside Perl.
> . 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?
>
This is because of the illegal characters in the strings.
You should probably set up a special Handler to trap these bogus packets. You
can do this be specifying an INTERNAL sessiondatabase with an Identifier and
using it for this Handler. This has been discussed on the list previously, have
a look at:
http://www.thesite.com.au/~radiator/
and do a search on "sessiondatabase internal".
>
> 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.
>
This depends on whether or not you want to do strict simultaneous-use checking.
If your sessiondatabase is accurate, then you don't need to check the NAS. If
on the other hand your sessiondatabase is often wrong, then it can make sense
to enable NasType for your Clients. Note that you don't have to specify NasType
for all your clients - if you have just one or two that have problems, then
just enable NasType for those ones.
> 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
>
Keep in mind that Radiator does quite a bit of this already. Any NAS
that restarts and sends an Accounting-On request will clear the session
database of all entries for that NAS. Also, any Access-Request will cause an
existing session in the session database for that Nas-Port combination to be
deleted (because we can't receive a new call on a port that is in use).
So although you could do what you describe above, I'm not sure how much it is
going to buy you.
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
NT, Rhapsody
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
