> > >There are many arguments on this topic. Anyone like to share there
> > >experience, code etc. to the PM users such the a workable and not too
> > >troublesome solution?
> > >
> > >We do believe that there is a demand but if the supplier cannot give
> > >an solution, the users can seek the best possible solution and share it!
> > >
> > >Any takers?
> > >
> > >Alpha.
> >
> > I use UNET RADIUS, it lets you specify how many simultaneous logins are
> > permitted for each user.
>
> Due to line delays AND server loads we have 4 radius servers running (and
> each portmaster is using 2 of them just in case one dies). We tried virtually
> everything to get them synchronized but it is just impossible to avoid double
> logins with this kind of config. So we just got down to the point of having
> one box here doing nothing but telnetting in every single portmaster doing a
> show users, collecting all the information, figuring out who's on twice (or
> more; record currently is 14 connects in a single minute) and throwing their
> oldest sessions out (very important; throwing the newest out is very annoying
> if a line got stuck) plus sending them a reprimanding email. It's a clumsy
> combination of bash and perl scripts and a C program, the hole thing eats
> resources like hell but ... IT WORKS and after the initial week of battle
> was over it still throws out around 20 users/day.
>
> What I thinks needs to exists is some kind of communication between radius
> servers AND a method for a radius server to contact a client to reset a
> certain connection. Frankly, I do not believe we'll see this working soon :-(
>
> Same problem with the actual accounting; having it distributed we need to
> collect and combine all local data and it's not exactly _consistent_ info.
> Sometimes we got multiple stop records of the same session or a single
> 500000+ second session (not very realistic considering telco lines here)
> without a start record anywhere :-(
>
Regarding accounting..
The way I do this is to store a USER SESSION RECORD in an msql database once the user logs OFF. The RECORD relies on the current time and Acct-Session-Time.
It works out the start time from the epoch like so:
epoch(start time) = epoch(current time) - Acct-Session-Time
This has some benefits:
* When Daylight Saving occurs, if the system clock is +1 or -1 or whatever,
the user still gets recorded as using a "total" time, not reliant on the
start time of the users session. Yes the start time will be wrong
if daylight saving did occur, but this is a smaller price to pay, and
you dont lose any money, or gain any money based on whether the clock went
back an hour or forward an hour.
* When multiple session ID's start popping up, it doesnt care, it does not
use session id's at ALL.
* Mutliple radius daemons can record to the same database, since the msql API
provides functions to connect to msql databases over inet.
* If the msql database happens to be unreachable, it logs the exact sql query
required to a file. This file can then be piped into msql.
Peter Marelas