> > What
> > about when the PM reboots?
>
> 2. delete from table utmp where host = 'crashed host'
> (already running at my site). Smart bumper program also knows
> how to handle this.
>
How did you detect the crash reliably?
> > What about when a RADIUS sever crashes?
>
> 3. Good point. I have implemented a 'loadup' that rebuilds the
> database by querying the running NAS's. I could add this to the /etc/rc
> of each radius server, but I won't bother just yet. Since my radius
> servers have each both been up over 100 days now, I don't think it's a
> huge issue.
>
That must be a lot of fun when the users are trying to get back in while
this occurs.
> > What
> > about network outages or blocks?
>
> 4. Smart bumper program runs external to the radius server. If the network is
> blocked, the user's not going anywhere anyway (can't log in). In any
> case, it doesn't have to be "perfect". It can be a little loose, as
> long as it never kills the current login session. Perfection is not
> required, just pretty good detection and deterrance.
>
It can be a little loose at your site by your decision. Livingston can't
make that decision for everyone. It would do nasty things to their quality
reputation. They may not have every feature you want, but the ones they
do have work.
> > How does it scale to large users with
> > hundreds of PMs and several RADIUS servers?
>
> 5. Ought to scale well. Since it's a shared network database. How many
> of these 'huge' users do you have anyway? The largest providers in the
> northwest (7 - 10K users) have 'only' 45 PM's. (500 - 1000 lines).
> An mSQL query in a database of 1000 is still a sub-second response.
> Sorting and checking for dups takes about 5 seconds (on a slow box).
> That's good enough for me. When/if i get to 100 NAS's, I'll probably
> rewrite mSQL to be faster, or change the database backend altogether.
>
Ha! Perhaps you should look at a larger picture. Livingstons are widely
in use by large NATIONAL providers. Many of them have >=2000 PortMasters.
Also several international sites have large numbers of PMs. It's not likely
that your above concept will scale to that level. Now add in the idea
of something on the order of a 50,000 user or more table of users, and
you're starting to really expand the amount of data your shoving around
the network. The problem with a distributed shared database of this
magnitude is synchronization. RADIUS authentication data can be done
this way, because it doesn't really matter if the data is 10-15 minutes
old. Not so for the multiple login issue.
> > So why aren't you billing them for each simultaneous login? Can be easily
> > done right now with stock RADIUS and many other sites are doing this.
>
> Really. In a competitive flat-rate environment? If we charged by the hour
> this would not even be an issue. Here in Seattle, there is 1, count 'em 1
> hourly provider (of about 70).
>
Sure. How are these related?
> > 'Unlimited use' doesn't mean 'login as many times as you like' - put it
> > right in the contract and start billing.
>
> It is in the contract. Tell me how to detect and bill it in a flat rate
> environment, using radius.
>
Real easy:
Customer further agrees that unlimited use means an unlimited
number of hours may be used by user, but that each simultaneous
connection will be billed as a seperate connection. That is,
if a user is logged in on two lines at the same time, user will
be billed double the normal charge for any month in which that
occurs.
Then, it's fairly easy to parse the accounting records.
> > You might be surprised at how
> > fast people change their passwords when they get huge bills. And if they
> > don't pay they're deadbeats and you shut off access.
>
> I come to Livingston for reliable equipment, not business advice. I'll
> decide how to run my business, thank you.
>
Funny, your note is in response to a thread about solving the multiple-login
problem. This is a viable solution. It may not be the solution you want,
but it is viable.
> The features have taken about 6 hours of my time so far. And yes, I am
> a professional software developer (one of my many hats).
>
So? You've got a solution that:
1. Works in your specific environment.
2. Won't really scale beyond a small-medium size ISP.
3. Has holes in it.
Owen