> > This is your opinion of the situation. I think most of the people
> > complaining would be happy with numeric limits, at least that is the
> > impression I get.
> >
> The difference isn't the limits people want to set. It's how they want to
> enforce said limit. Some want to bill. Some want to nasty-gram.
> Some want an escalating nasty-gram -- nastier-gram -- kill policy.
> Some want to nuke the oldest session. Some want... The list goes
> on.
No, no, no. What you describe goes far beyond what I have seen requested
for Livingston to implement. Disallow and bump are the two requests I
have seen.
> > > We shouldn't. However, it's _EASIER_ to implement this as a local site-
> > > specific solution. If you want to make it _EASY_ do it that way. Otherwise,
> > > accept that it's hard and bill.
> >
> > Easier for whom? Certainly not for me. It has taken me over a week straight
> > *with* consulting from William Bulley(one of the Merit engineers) to get
> > Merit up on my system. Multiple logins were not the only reason for the
> > switch, but hey, it would have been a lot easier to have had this support
> > in Livingstons code, and not to have had to make the switch.
> >
> Hmmm... Well I don't know what was special about your system, but you
> probably could have added this as a hack to the Livingston code in less
> than a week of a consultant's time.
Not a week of consulting, a week for me, with a couple of hours of
consulting time from William. The reason for the switch was functionality
lacking in Livingston's distribution, multiple login prevention only
being a portion of needed functionality.
> > Again, your view of the situation, not mine. Who said anything about a
> > 100 different authentication policies, besides you?
> >
> Don't remember exactly who, but I believe it was actually "100's" rather
> than "a hundred". However, if you just read what people have been asking
> for, you will find at least 5 different ways have been discussed in terms
> of WHAT to do when someone loggs in twice. Setting the limit is one problem.
> Detecting excess or attempted excess is problem two. What you do afterwards
> is problem 3. Problem 3 has a lot of differing opinions running around,
> and depending on your andwer to number 3, it has an impact on what's
> acceptable for 1 and 2.
Disallow and/or bump would seem to be the most portable and widely
desired methods. I haven't seen a bunch of requests for this extraneous
stuff which you mention as if it were requested just as much as disallow
or bump.
> > > provides as such anyway. Thank god you aren't teaching a class on how
> > > to run an ISP.
> >
> > Gee I dunno, "Try to get base code to do what you want," vs. "hack your
> > own, which your vendor is not going to support" seems to be a better
> > method of running an ISP.
> >
> So, tell me, are you running _ALL_ Stock drivers on your UNIX systems?
> You haven't added any third-party drivers to your NT systems (if you have
> any). Etc. Let's face it, I doubt you could effectively run an ISP on
> stock software.
NT? Yeachh. I have added software, I have changed kernel values, but I
haven't changed any drivers. 2000 people seem to think we are running ok.
> > > HA! This is a complicated enough issue that there's no easy way to explain
> > > all the tradeoffs in the different solutions that would have to be
> > > implemented. Sorry, but the way Livingston made their boxes easy to
> > > configure was by making them do a few things very well. RADIUS is not
> > > easy to configure. It's easy to clone RADIUS entries and modify them
> > > using a text editor if you know what you're doing. But Livingston has
> > > not done anything to make RADIUS easy to "configure". Why do you think
> > > this extension would be any different?
> >
> > RADIUS is *hard* to configure!? For whom?
> >
> Compare configuring a new user in RADIUS to adding a USER to the USER table
> using the X version of PMCONSOLE. Which one is easier?
>
>
> Now, take a local high school student who can debug a Windows box
> blindfolded with one hand tied behind his back. Put him in front of
> RADIUS and have him add a bunch of users without substantial training
> or support. Any bets? I bet he could configure a PortMaster easier.
You never said "Harder than XXXX." You stated RADIUS is "not easy to
configure," which, if you read the docs, is.
> > > And I have never disagreed with that. I have said that it should not get
> > > a higher priority than it has. I have never called anyone a luser.
> > > I suspect that your retort suffers from the same problem that my above
> > > statements do. Read enough mail messages about the same topic and you
> > > soon forget exactly who said exactly what.
> >
> > And if you would do the same, you would realize that I never accused you
> > of calling people lusers.
> >
> Huh? This sentence doesn't make sense to me.
>
> 1. I was saying that after so many messages I couldn't remember
> exactly who said exactly what.
Agreed.
>
> 2. I never called anyone a luser.
>
Agreed.
> 3. I never accused you of claiming that I called anyone a luser.
By making the statement that you did not call anyone a luser, and then
stating my arguments seem to suffer from not knowing who said what, it
sure seems that way.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell (510) 943-5769 voice
Systems Administrator (510) 210-2000 modem
Value Net, Inc. (510) 943-1708 fax
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/